Old page wikitext, before the edit (old_wikitext) | 'In information technology, the '''Handle System''' is a distributed computer system for assigning [[persistent identifier]]s, or [[Handle (computing)|handle]]s, to information resources, and for resolving those handles to provide users with the means to locate, access, or make use of the resources.
As with handles used elsewhere in computing, Handle System handles are opaque, and encode no information about the underlying resource, being bound only to [[metadata]] regarding the resource. Consequently, the handles are not rendered invalid by changes to the metadata. The system provides specifications and reference implementations for the servers and protocols for obtaining the metadata bound to a handle, and for resolving the metadata into access to, and provision of, the resource.
The system was developed by [[Bob Kahn]] at the [[Corporation for National Research Initiatives]] (CNRI). The original work was funded by the [[Defense Advanced Research Projects Agency]] (DARPA) between 1992 and 1996, as part a wider framework for distributed digital object services,<ref>{{cite web|url=http://www.cnri.reston.va.us/k-w.html |title=Kahn/Wilensky Architecture |publisher=Cnri.reston.va.us |date=1995-05-13 |accessdate=2013-03-13}}</ref> and was thus somewhat contemporaneous with the early deployment of the [[World Wide Web]], with similar goals.
The Handle System was first implemented in autumn 1994, and continues to be maintained and operated by CNRI, currently providing the underlying infrastructure for such handle-based systems as [[Digital Object Identifiers]] and [[DSpace]], which are mainly used to provide access to scholarly, professional and government literature and documents.
==Specifications==
The Handle System is defined in informational [[Request for Comments|RFCs]] 3650,<ref>http://www.rfc-editor.org/rfc/rfc3650.txt</ref> 3651<ref>http://www.rfc-editor.org/rfc/rfc3651.txt</ref> and 3652<ref>http://www.rfc-editor.org/rfc/rfc3652.txt</ref> of the [[Internet Engineering Task Force|Internet Engineering Task Force (IETF)]]; it includes an open set of protocols, a namespace, and a reference implementation of the protocols. Documentation, software, and related information is provided by CNRI on a dedicated website<ref>{{cite web|url=http://www.handle.net |title=handle.net |publisher=handle.net |date= |accessdate=2013-03-13}}</ref>
Handles consist of a prefix which identifies a "naming authority" and a suffix which gives the "local name" of a resource. Similar to domain names, prefixes are issued to naming authorities by a registry operated by CNRI upon payment of a fee, which must be renewed annually. The naming authorities may create any number of handles with different "local names" within their assigned prefixes. An example of a handle is:
:<code>20.1000/100</code>
In this example, <code>20.1000</code> is the prefix assigned to the naming authority (in this case, Handle.net itself) and <code>100</code> is the local name within that namespace. The local name may consist of any characters from the [[Unicode]] [[UCS-2]] character set. The prefix also consists of any UCS-2 characters, other than "/". As with other uses of [[handle (computing)|handle]]s in computing, the handle is opaque; that is, it encodes no information about the underlying resource and provides only the means to retrieve metadata about the resource.
This may be contrasted with a [[Uniform Resource Locator]] (URL), which may encode within the identifier such attributes of the resource as the protocol to be used to access the server holding the resource, the server host name and port number, and perhaps even location specifics such as the name of a file in the server file system containing the resource. In the Handle System, these specifics are not encoded in the handle, but are found in the metadata to which the handle is bound.
The metadata may include many attributes of the information resource, such as its locations, the forms in which it is available, the types of access (e.g. "free" versus "paid") offered, and to whom. The processing of the metadata to determine how and where the resource should be accessed, and the provision of the resource to the user, are performed in a separate step, called "resolution", using a Resolver, a server which may be different than the ones involved in exchanging the handle for the metadata. Unlike URLs, which may become invalid if the metadata embedded within them becomes invalid, handles do not become invalid and do not need to change when locations or other metadata attributes change. This helps to prevent [[link rot]], as changes in the information resource (such as location) need only be reflected in changes to
the metadata, rather than in changes in every reference to the resource.
Each handle may have its own administrator(s) and administration of the handles can be done in a distributed environment, similar to DNS domain names. The name-to-value bindings may also be secured, both via signatures to verify the data and via challenge response to verify the transmission of the data, allowing handles to be used in trust management applications.
It is possible for the same underlying information resource to be associated with multiple handles, as when two university libraries
generate handles (and therefore possibly different sets of metadata) for the same book.
The Handle System is compatible with the [[Domain Name System]] (DNS), but does not require it, unlike persistent identifiers such as [[Persistent Uniform Resource Locator|PURLs]] or [[Archival Resource Key|ARKs]], which are similar to handles, but which utilise domain names. However, unlike these domain-name based approaches, handles do require a separate prefix registration process and handle servers separate from the domain name servers.
Handles can be used natively, or expressed as [[Uniform Resource Identifier|Uniform Resource Identifiers (URIs)]] through a namespace within the [[info URI scheme]]; <ref>{{cite web|url=http://info-uri.info/registry/docs/misc/faq.html |title=About "info" URIs - Frequently Asked Questions |publisher=Info-uri.info |date= |accessdate=2013-03-13}}</ref><ref>{{cite web|url=http://www.rfc-editor.org/rfc/rfc4452.txt|title=RFC 4452}}</ref> for example, <code>20.1000/100</code> may be written as the URI, <code>info:hdl/20.1000/100</code>. Handles may also be expressed as Uniform Resource Locators (URLs) through the use of a [[HTTP]] [[proxy server]],<ref>{{cite web|url=http://www.handle.net/proxy.html |title=HDL.NET Services: Proxy Server System |publisher=Handle.net |date= |accessdate=2013-03-13}}</ref> such as <code>http://hdl.handle.net/20.1000/100</code> or <code>https://doi.org/20.1000/100</code>
==Implementation==
Implementation of the Handle System consists of Local Handle Services, each of which is made up of one or more sites that provide the servers that store specific handles. The Global Handle Registry is a unique Local Handle Service which stores information on the prefixes (also known as naming authorities) within the Handle System and can be queried to find out where specific handles are stored on other Local Handle Services within this distributed system.
The Handle System website provides a series of implementation tools, notably the HANDLE.NET Software<ref>{{cite web|url=http://www.handle.net/download.html |title=HS Software Download |publisher=Handle.net |date= |accessdate=2013-03-13}}</ref> and HANDLE.NET Client Libraries.<ref>{{cite web|url=http://www.handle.net/client_download.html |title=Software Client Libraries |publisher=Handle.net |date= |accessdate=2013-03-13}}</ref> Handle clients can be embedded in end user software (e.g., a web browser) or in server software (e.g., a web server) and extensions are already available for [[Adobe Acrobat]]<ref>{{cite web|url=http://www.handle.net/hs-tools/adobe/ |title=HDL Plug-in for Adobe Acrobat and Acrobat Reader |publisher=Handle.net |date= |accessdate=2013-03-13}}</ref> and [[Firefox]].<ref>[http://www.handle.net/hs-tools/extensions/firefox_hdlclient.html ] {{webarchive |url=https://web.archive.org/web/20150905092651/http://www.handle.net/hs-tools/extensions/firefox_hdlclient.html |date=September 5, 2015 }}</ref>
Handle client software libraries are available in both C and Java. Some applications have developed specific add-on tools, e.g., for the DOI System.<ref>{{cite web|url=http://www.doi.org/tools.html |title=DOI System Tools |publisher=Doi.org |date=2012-07-12 |accessdate=2013-03-13}}</ref>
The interoperable network of distributed handle resolver servers (also known as the Proxy Server System) are linked through a Global Resolver (which is one logical entity though physically decentralised and mirrored). Users of Handle System technology obtain a handle prefix created in the Global Handle Registry. The Global Handle Registry maintains and resolves the prefixes of locally maintained handle services. Any local handle service can, therefore, resolve any handle through the Global Resolver.
Handles (identifiers) are passed by a client, as a query of the naming authority/prefix, to the Handle System's Global Handle Registry (GHR). The GHR responds by sending the client the location information for the relevant Local Handle Service (which may consist of multiple servers in multiple sites); a query is then sent to the relevant server within the Local Handle Service. The Local Handle Service returns the information needed to acquire the resource, e.g., a URL which can then be turned into an HTTP re-direct. (Note: if the client already has information on the appropriate LHS to query, the initial query to GHR is omitted)
Though the original model from which the Handle System derives dealt with management of digital objects, the Handle System does not mandate any particular model of relationships between the identified entities, nor is it limited to identifying only digital objects: non-digital entities may be represented as a corresponding digital object for the purposes of digital object management. Some care is needed in the definition of such objects and how they relate to non-digital entities; there are established models that can aid in such definitions (e.g., [[Functional Requirements for Bibliographic Records|Functional Requirements for Bibliographic Records (FRBR)]], [[CIDOC CRM]], and [[indecs Content Model|indecs content model]]. Some applications have found it helpful to marry such a framework to the handle application: for example, the Advanced Distributed Learning (ADL) Initiative<ref>{{cite web|url=http://www.adlnet.gov/ |title=adlnet.gov |publisher=adlnet.gov |date= |accessdate=2013-03-13}}</ref> brings together Handle System application with existing standards for distributed learning content, using a Shareable Content Object Reference Model (SCORM),<ref>{{cite web|url=http://www.adlnet.gov/scorm/index.aspx|archiveurl=http://www.webcitation.org/5YNNKTrTx|archivedate=2008-06-06|title=SCORM|work=adlnet.gov}}</ref> and the [[Digital Object Identifier|Digital Object Identifier (DOI) system]] implementation of the Handle System has adopted it together with the [[indecs Content Model|indecs]] framework to deal with [[semantic interoperability]].
The Handle System also makes explicit the importance of organizational commitment to a persistent identifier scheme, but does not mandate one model for ensuring such commitment. Individual applications may choose to establish their own sets of rules and social infrastructure to ensure persistence (e.g., when used in the [[DSpace]] application, and the DOI application).<ref>{{cite web|url=http://www.doi.org |title=doi.org |publisher=doi.org |date=2013-01-08 |accessdate=2013-03-13}}</ref>
==Design principles==
The Handle system is designed to meet the following requirements to contribute to persistence<ref name="ref3">{{cite web|url=http://www.oscars.org/science-technology/council/projects/metadata-symposium/webcasts.html|archiveurl=https://web.archive.org/web/20130330170608/http://www.oscars.org/science-technology/council/projects/metadata-symposium/webcasts.html|archivedate=2013-03-30 |title=Identifier Systems in Network Architecture, Laurence Lannom, CNRI. Video of presentation (or presentation PDF only) from the Digital Motion Picture Metadata Symposium, Science & Technology Council, Academy of Motion Picture Arts & Sciences, 11 June 2009 |publisher=Oscars.org |date=2012-08-24 |accessdate=2013-03-13}}</ref>
The identifier string:
* is not based on any changeable attributes of the entity (location, ownership, or any other attribute that may change without changing the referent’s identity);
* is opaque (preferably a ‘dumb number’: a well known pattern invites assumptions that may be misleading, and meaningful semantics may not translate across languages and may cause trademark conflicts);
* is unique within the system (to avoid collisions and referential uncertainty);
* has optional, but nice to have, features that should be supported (human-readable,cut-and-paste-able, embeddable; fits common systems, e.g., URI specification).
The identifier resolution mechanism:
* is reliable (using redundancy, no single points of failure, and fast enough to not appear broken);
* is scalable (higher loads simply managed with more computers);
* is flexible (can adapt to changing computing environments; useful to new applications):
* is trusted (both resolution and administration have technical trust methods; an operating organization is committed to the long term);
* builds on open architecture (encouraging the leverage efforts of a community in building applications on the infrastructure);
* is transparent (users need not know the infrastructure details).
==Applications==
Among the objects that are currently identified by handles are journal articles, technical reports, books, theses and dissertations, government documents, metadata, distributed learning content, and data sets. Handles are being used in digital watermarking applications, GRID applications, repositories, and more. Although individual users may download and use the HANDLE.NET software independently, many users have found it beneficial to collaborate in developing applications in a federation, using common policy or additional technology to provide shared services. As one of the first persistent identifier schemes, the Handle System has been widely adopted by public and private institutions and proven over several years. (See Paradigm, Persistent identifiers.)<ref>{{cite web|url=http://www.paradigm.ac.uk/workbook/metadata/pids-handle.html |title=workbook on digital private papers | administrative and preservation metadata | persistent identifiers |publisher=paradigm |date=2008-01-02 |accessdate=2013-03-13}}</ref>
Handle System applications may use handles as simple persistent identifiers (as most commonly used, to resolve to the current URL of an object), or may choose to take advantage of other features. Its support for the simultaneous return as output of multiple pieces of current information related to the object, in defined data structures, enables priorities to be established for the order in which the multiple resolutions will be used. Handles can, therefore, resolve to different digital versions of the same content, to mirror sites, or to different business models (pay vs. free, secure vs. open, public vs. private). They can also resolve to different digital versions of differing content, such as a mix of objects required for a distance-learning course.
There are thousands of handle services running today, located in 71 countries, on 6 continents; over 1000 of them run at universities and libraries. Handle services are being run by user federations, national laboratories, universities, computing centers, libraries (national and local), government agencies, contractors, corporations, and research groups. Major publishers use the Handle System for persistent identification of commercially traded and Open Access content through its implementation with the [[Digital Object Identifier|Digital Object Identifier (DOI) system]].
The number of prefixes, which allow users to assign handles, is growing and stands at over 12,000 as of early 2014. There are six top-level Global Handle Registry servers that receive (on average) 68 million resolution requests per month. Proxy servers known to CNRI, passing requests to the system on the Web, receive (on average) 200 million resolution requests per month. (Statistics from Handle Quick Facts.)
In 2010, CNRI and [[ITU]] (International Telecommunication Union) entered into an agreement to collaborate on use of the Handle System (and the Digital Object Architecture more generally) and are working on the specific details of that collaboration; in April 2009 ITU listed the Handle System as an "emerging trend".<ref>{{cite web |url=http://www.itu.int/osg/csd/emerging_trends/handle_system/index.html |title=Handle System |publisher=Itu.int |date=2010-04-16 |accessdate=2013-03-13}}</ref>
==Licences and use policy==
Handle System, HANDLE.NET and Global Handle Registry are trademarks of the [[Corporation for National Research Initiatives]] (CNRI), a non-profit research and development corporation in the USA. The Handle System is the subject of patents by CNRI, which licenses its Handle System technology through a public license,<ref>http://www.handle.net/HSj/hdlnet-2-LICENSE.pdf</ref> similar to an open source license, in order to enable broader use of the technology. Handle System infrastructure is supported by prefix registration and service fees, with the majority coming from single prefix holders. The largest current single contributor is the [[International DOI Foundation]]. The Public License allows commercial and non-commercial use at low cost of both its patented technology and the reference implementation of the software, and allows the software to be freely embedded in other systems and products. A Service Agreement<ref>http://www.handle.net/service_agreement.html</ref> is also available for users who intend to provide identifier and/or resolution services using the Handle System technology under the Handle System public license.
==Related technologies==
{{Update-section|date=August 2016}}
The Handle System is the first piece of a long-term digital object architecture. In January 2010 CNRI released its general-purpose Digital Object Repository software,<ref>{{cite web|url=http://www.dorepository.org |title=dorepository.org |publisher=dorepository.org |date=2013-01-08 |accessdate=2013-03-13}}</ref> which is the second major component of this architecture. More information<ref>{{cite web|url=http://www.dlib.org/dlib/january10/reilly/01reilly.html |title=Digital Object Repository Server: A Component of the Digital Object Architecture |publisher=Dlib.org |date=2010-02-04 |accessdate=2013-03-13}}</ref> about the release, including protocol specification, source code and ready-to-use system, clients and utilities, is available.<ref>{{cite web|url=http://www.dorepository.org/documentation.html |title=DO Repository |doi=10.1045/january2010-reilly |publisher=DO Repository |date= |accessdate=2013-03-13}}</ref> The third and final piece, the Digital Object Registry, has not yet been released.
==See also==
*[[Hypertext]]
*[[Linked Data]]
*[[Digital Library]]
*[[Resource Description Framework]]
*[[Semantic Web]]
*[[OpenURL]]
*[[Permalink]]
*[[Uniform Resource Name]]
*[[Uniform Resource Identifier]]
*[[Archival Resource Key]]
*[[Persistent URL]]
*[[Link rot]]
*[[Institutional Repository]]
==References==
{{reflist|colwidth=30em}}
==External links==
* {{Official website|http://www.handle.net }}
* [http://www.paradigm.ac.uk/workbook/metadata/pids.html Persistent identifiers] project at [http://www.paradigm.ac.uk/about Paradigm]
[[Category:Internet protocols]]
[[Category:Identifiers]]' |
New page wikitext, after the edit (new_wikitext) | 'In information technology, the '''Handle System''' is a distributed computer system for assigning [[persistent identifier]]s, or [[Handle (computing)|handle]]s, to information resources, and for resolving those handles to provide users with the means to locate, access, or make use of the resources.
As with handles used elsewhere in computing, Handle System handles are opaque, and encode no information about the underlying resource, being bound only to [[metadata]] regarding the resource. Consequently, the handles are not rendered invalid by changes to the metadata. The system provides specifications and reference implementations for the servers and protocols for obtaining the metadata bound to a handle, and for resolving the metadata into access to, and provision of, the resource.
The system was developed by [[Bob Kahn]] at the [[Corporation for National Research Initiatives]] (CNRI). The original work was funded by the [[Defense Advanced Research Projects Agency]] (DARPA) between 1992 and 1996, as part a wider framework for distributed digital object services,<ref>{{cite web|url=http://www.cnri.reston.va.us/k-w.html |title=Kahn/Wilensky Architecture |publisher=Cnri.reston.va.us |date=1995-05-13 |accessdate=2013-03-13}}</ref> and was thus somewhat contemporaneous with the early deployment of the [[World Wide Web]], with similar goals.
The Handle System was first implemented in autumn 1994, and continues to be maintained and operated by CNRI, currently providing the underlying infrastructure for such handle-based systems as [[Digital Object Identifiers]] and [[DSpace]], which are mainly used to provide access to scholarly, professional and government literature and documents.
Thousands of handle services are currently running. Over 1000 of these are at universities and libraries, but they are also in use at national laboratories, research groups, government agencies, and commercial enterprises.
==Specifications==
The Handle System is defined in informational [[Request for Comments|RFCs]] 3650,<ref>http://www.rfc-editor.org/rfc/rfc3650.txt</ref> 3651<ref>http://www.rfc-editor.org/rfc/rfc3651.txt</ref> and 3652<ref>http://www.rfc-editor.org/rfc/rfc3652.txt</ref> of the [[Internet Engineering Task Force|Internet Engineering Task Force (IETF)]]; it includes an open set of protocols, a namespace, and a reference implementation of the protocols. Documentation, software, and related information is provided by CNRI on a dedicated website<ref>{{cite web|url=http://www.handle.net |title=handle.net |publisher=handle.net |date= |accessdate=2013-03-13}}</ref>
Handles consist of a prefix which identifies a "naming authority" and a suffix which gives the "local name" of a resource. Similar to domain names, prefixes are issued to naming authorities by a registry operated by CNRI upon payment of a fee, which must be renewed annually. The naming authorities may create any number of handles with different "local names" within their assigned prefixes. An example of a handle is:
:<code>20.1000/100</code>
In this example, <code>20.1000</code> is the prefix assigned to the naming authority (in this case, Handle.net itself) and <code>100</code> is the local name within that namespace. The local name may consist of any characters from the [[Unicode]] [[UCS-2]] character set. The prefix also consists of any UCS-2 characters, other than "/". As with other uses of [[handle (computing)|handle]]s in computing, the handle is opaque; that is, it encodes no information about the underlying resource and provides only the means to retrieve metadata about the resource.
This may be contrasted with a [[Uniform Resource Locator]] (URL), which may encode within the identifier such attributes of the resource as the protocol to be used to access the server holding the resource, the server host name and port number, and perhaps even location specifics such as the name of a file in the server file system containing the resource. In the Handle System, these specifics are not encoded in the handle, but are found in the metadata to which the handle is bound.
The metadata may include many attributes of the information resource, such as its locations, the forms in which it is available, the types of access (e.g. "free" versus "paid") offered, and to whom. The processing of the metadata to determine how and where the resource should be accessed, and the provision of the resource to the user, are performed in a separate step, called "resolution", using a Resolver, a server which may be different than the ones involved in exchanging the handle for the metadata. Unlike URLs, which may become invalid if the metadata embedded within them becomes invalid, handles do not become invalid and do not need to change when locations or other metadata attributes change. This helps to prevent [[link rot]], as changes in the information resource (such as location) need only be reflected in changes to
the metadata, rather than in changes in every reference to the resource.
Each handle may have its own administrator(s) and administration of the handles can be done in a distributed environment, similar to DNS domain names. The name-to-value bindings may also be secured, both via signatures to verify the data and via challenge response to verify the transmission of the data, allowing handles to be used in trust management applications.
It is possible for the same underlying information resource to be associated with multiple handles, as when two university libraries
generate handles (and therefore possibly different sets of metadata) for the same book.
The Handle System is compatible with the [[Domain Name System]] (DNS), but does not require it, unlike persistent identifiers such as [[Persistent Uniform Resource Locator|PURLs]] or [[Archival Resource Key|ARKs]], which are similar to handles, but which utilise domain names. However, unlike these domain-name based approaches, handles do require a separate prefix registration process and handle servers separate from the domain name servers.
Handles can be used natively, or expressed as [[Uniform Resource Identifier|Uniform Resource Identifiers (URIs)]] through a namespace within the [[info URI scheme]]; <ref>{{cite web|url=http://info-uri.info/registry/docs/misc/faq.html |title=About "info" URIs - Frequently Asked Questions |publisher=Info-uri.info |date= |accessdate=2013-03-13}}</ref><ref>{{cite web|url=http://www.rfc-editor.org/rfc/rfc4452.txt|title=RFC 4452}}</ref> for example, <code>20.1000/100</code> may be written as the URI, <code>info:hdl/20.1000/100</code>. Handles may also be expressed as Uniform Resource Locators (URLs) through the use of a [[HTTP]] [[proxy server]],<ref>{{cite web|url=http://www.handle.net/proxy.html |title=HDL.NET Services: Proxy Server System |publisher=Handle.net |date= |accessdate=2013-03-13}}</ref> such as <code>http://hdl.handle.net/20.1000/100</code> or <code>https://doi.org/20.1000/100</code>
==Implementation==
Implementation of the Handle System consists of Local Handle Services, each of which is made up of one or more sites that provide the servers that store specific handles. The Global Handle Registry is a unique Local Handle Service which stores information on the prefixes (also known as naming authorities) within the Handle System and can be queried to find out where specific handles are stored on other Local Handle Services within this distributed system.
The Handle System website provides a series of implementation tools, notably the HANDLE.NET Software<ref>{{cite web|url=http://www.handle.net/download.html |title=HS Software Download |publisher=Handle.net |date= |accessdate=2013-03-13}}</ref> and HANDLE.NET Client Libraries.<ref>{{cite web|url=http://www.handle.net/client_download.html |title=Software Client Libraries |publisher=Handle.net |date= |accessdate=2013-03-13}}</ref> Handle clients can be embedded in end user software (e.g., a web browser) or in server software (e.g., a web server) and extensions are already available for [[Adobe Acrobat]]<ref>{{cite web|url=http://www.handle.net/hs-tools/adobe/ |title=HDL Plug-in for Adobe Acrobat and Acrobat Reader |publisher=Handle.net |date= |accessdate=2013-03-13}}</ref> and [[Firefox]].<ref>[http://www.handle.net/hs-tools/extensions/firefox_hdlclient.html ] {{webarchive |url=https://web.archive.org/web/20150905092651/http://www.handle.net/hs-tools/extensions/firefox_hdlclient.html |date=September 5, 2015 }}</ref>
Handle client software libraries are available in both C and Java. Some applications have developed specific add-on tools, e.g., for the DOI System.<ref>{{cite web|url=http://www.doi.org/tools.html |title=DOI System Tools |publisher=Doi.org |date=2012-07-12 |accessdate=2013-03-13}}</ref>
The interoperable network of distributed handle resolver servers (also known as the Proxy Server System) are linked through a Global Resolver (which is one logical entity though physically decentralised and mirrored). Users of Handle System technology obtain a handle prefix created in the Global Handle Registry. The Global Handle Registry maintains and resolves the prefixes of locally maintained handle services. Any local handle service can, therefore, resolve any handle through the Global Resolver.
Handles (identifiers) are passed by a client, as a query of the naming authority/prefix, to the Handle System's Global Handle Registry (GHR). The GHR responds by sending the client the location information for the relevant Local Handle Service (which may consist of multiple servers in multiple sites); a query is then sent to the relevant server within the Local Handle Service. The Local Handle Service returns the information needed to acquire the resource, e.g., a URL which can then be turned into an HTTP re-direct. (Note: if the client already has information on the appropriate LHS to query, the initial query to GHR is omitted)
Though the original model from which the Handle System derives dealt with management of digital objects, the Handle System does not mandate any particular model of relationships between the identified entities, nor is it limited to identifying only digital objects: non-digital entities may be represented as a corresponding digital object for the purposes of digital object management. Some care is needed in the definition of such objects and how they relate to non-digital entities; there are established models that can aid in such definitions (e.g., [[Functional Requirements for Bibliographic Records|Functional Requirements for Bibliographic Records (FRBR)]], [[CIDOC CRM]], and [[indecs Content Model|indecs content model]]. Some applications have found it helpful to marry such a framework to the handle application: for example, the Advanced Distributed Learning (ADL) Initiative<ref>{{cite web|url=http://www.adlnet.gov/ |title=adlnet.gov |publisher=adlnet.gov |date= |accessdate=2013-03-13}}</ref> brings together Handle System application with existing standards for distributed learning content, using a Shareable Content Object Reference Model (SCORM),<ref>{{cite web|url=http://www.adlnet.gov/scorm/index.aspx|archiveurl=http://www.webcitation.org/5YNNKTrTx|archivedate=2008-06-06|title=SCORM|work=adlnet.gov}}</ref> and the [[Digital Object Identifier|Digital Object Identifier (DOI) system]] implementation of the Handle System has adopted it together with the [[indecs Content Model|indecs]] framework to deal with [[semantic interoperability]].
The Handle System also makes explicit the importance of organizational commitment to a persistent identifier scheme, but does not mandate one model for ensuring such commitment. Individual applications may choose to establish their own sets of rules and social infrastructure to ensure persistence (e.g., when used in the [[DSpace]] application, and the DOI application).<ref>{{cite web|url=http://www.doi.org |title=doi.org |publisher=doi.org |date=2013-01-08 |accessdate=2013-03-13}}</ref>
==Design principles==
The Handle system is designed to meet the following requirements to contribute to persistence<ref name="ref3">{{cite web|url=http://www.oscars.org/science-technology/council/projects/metadata-symposium/webcasts.html|archiveurl=https://web.archive.org/web/20130330170608/http://www.oscars.org/science-technology/council/projects/metadata-symposium/webcasts.html|archivedate=2013-03-30 |title=Identifier Systems in Network Architecture, Laurence Lannom, CNRI. Video of presentation (or presentation PDF only) from the Digital Motion Picture Metadata Symposium, Science & Technology Council, Academy of Motion Picture Arts & Sciences, 11 June 2009 |publisher=Oscars.org |date=2012-08-24 |accessdate=2013-03-13}}</ref>
The identifier string:
* is not based on any changeable attributes of the entity (location, ownership, or any other attribute that may change without changing the referent’s identity);
* is opaque (preferably a ‘dumb number’: a well known pattern invites assumptions that may be misleading, and meaningful semantics may not translate across languages and may cause trademark conflicts);
* is unique within the system (to avoid collisions and referential uncertainty);
* has optional, but nice to have, features that should be supported (human-readable,cut-and-paste-able, embeddable; fits common systems, e.g., URI specification).
The identifier resolution mechanism:
* is reliable (using redundancy, no single points of failure, and fast enough to not appear broken);
* is scalable (higher loads simply managed with more computers);
* is flexible (can adapt to changing computing environments; useful to new applications):
* is trusted (both resolution and administration have technical trust methods; an operating organization is committed to the long term);
* builds on open architecture (encouraging the leverage efforts of a community in building applications on the infrastructure);
* is transparent (users need not know the infrastructure details).
==Applications==
Among the objects that are currently identified by handles are journal articles, technical reports, books, theses and dissertations, government documents, metadata, distributed learning content, and data sets. Handles are being used in digital watermarking applications, GRID applications, repositories, and more. Although individual users may download and use the HANDLE.NET software independently, many users have found it beneficial to collaborate in developing applications in a federation, using common policy or additional technology to provide shared services. As one of the first persistent identifier schemes, the Handle System has been widely adopted by public and private institutions and proven over several years. (See Paradigm, Persistent identifiers.)<ref>{{cite web|url=http://www.paradigm.ac.uk/workbook/metadata/pids-handle.html |title=workbook on digital private papers | administrative and preservation metadata | persistent identifiers |publisher=paradigm |date=2008-01-02 |accessdate=2013-03-13}}</ref>
Handle System applications may use handles as simple persistent identifiers (as most commonly used, to resolve to the current URL of an object), or may choose to take advantage of other features. Its support for the simultaneous return as output of multiple pieces of current information related to the object, in defined data structures, enables priorities to be established for the order in which the multiple resolutions will be used. Handles can, therefore, resolve to different digital versions of the same content, to mirror sites, or to different business models (pay vs. free, secure vs. open, public vs. private). They can also resolve to different digital versions of differing content, such as a mix of objects required for a distance-learning course.
There are thousands of handle services running today, located in 71 countries, on 6 continents; over 1000 of them run at universities and libraries. Handle services are being run by user federations, national laboratories, universities, computing centers, libraries (national and local), government agencies, contractors, corporations, and research groups. Major publishers use the Handle System for persistent identification of commercially traded and Open Access content through its implementation with the [[Digital Object Identifier|Digital Object Identifier (DOI) system]].
The number of prefixes, which allow users to assign handles, is growing and stands at over 12,000 as of early 2014. There are six top-level Global Handle Registry servers that receive (on average) 68 million resolution requests per month. Proxy servers known to CNRI, passing requests to the system on the Web, receive (on average) 200 million resolution requests per month. (Statistics from Handle Quick Facts.)
In 2010, CNRI and [[ITU]] (International Telecommunication Union) entered into an agreement to collaborate on use of the Handle System (and the Digital Object Architecture more generally) and are working on the specific details of that collaboration; in April 2009 ITU listed the Handle System as an "emerging trend".<ref>{{cite web |url=http://www.itu.int/osg/csd/emerging_trends/handle_system/index.html |title=Handle System |publisher=Itu.int |date=2010-04-16 |accessdate=2013-03-13}}</ref>
==Licences and use policy==
Handle System, HANDLE.NET and Global Handle Registry are trademarks of the [[Corporation for National Research Initiatives]] (CNRI), a non-profit research and development corporation in the USA. The Handle System is the subject of patents by CNRI, which licenses its Handle System technology through a public license,<ref>http://www.handle.net/HSj/hdlnet-2-LICENSE.pdf</ref> similar to an open source license, in order to enable broader use of the technology. Handle System infrastructure is supported by prefix registration and service fees, with the majority coming from single prefix holders. The largest current single contributor is the [[International DOI Foundation]]. The Public License allows commercial and non-commercial use at low cost of both its patented technology and the reference implementation of the software, and allows the software to be freely embedded in other systems and products. A Service Agreement<ref>http://www.handle.net/service_agreement.html</ref> is also available for users who intend to provide identifier and/or resolution services using the Handle System technology under the Handle System public license.
==Related technologies==
{{Update-section|date=August 2016}}
The Handle System is the first piece of a long-term digital object architecture. In January 2010 CNRI released its general-purpose Digital Object Repository software,<ref>{{cite web|url=http://www.dorepository.org |title=dorepository.org |publisher=dorepository.org |date=2013-01-08 |accessdate=2013-03-13}}</ref> which is the second major component of this architecture. More information<ref>{{cite web|url=http://www.dlib.org/dlib/january10/reilly/01reilly.html |title=Digital Object Repository Server: A Component of the Digital Object Architecture |publisher=Dlib.org |date=2010-02-04 |accessdate=2013-03-13}}</ref> about the release, including protocol specification, source code and ready-to-use system, clients and utilities, is available.<ref>{{cite web|url=http://www.dorepository.org/documentation.html |title=DO Repository |doi=10.1045/january2010-reilly |publisher=DO Repository |date= |accessdate=2013-03-13}}</ref> The third and final piece, the Digital Object Registry, has not yet been released.
==See also==
*[[Hypertext]]
*[[Linked Data]]
*[[Digital Library]]
*[[Resource Description Framework]]
*[[Semantic Web]]
*[[OpenURL]]
*[[Permalink]]
*[[Uniform Resource Name]]
*[[Uniform Resource Identifier]]
*[[Archival Resource Key]]
*[[Persistent URL]]
*[[Link rot]]
*[[Institutional Repository]]
==References==
{{reflist|colwidth=30em}}
==External links==
* {{Official website|http://www.handle.net }}
* [http://www.paradigm.ac.uk/workbook/metadata/pids.html Persistent identifiers] project at [http://www.paradigm.ac.uk/about Paradigm]
[[Category:Internet protocols]]
[[Category:Identifiers]]' |
