The Handle Service is an ARDC product that provides cost free creation (called minting) and support for users updating of persistent identifiers for the Australian research and cultural collections sectors.
The Handle Service includes three related services:
Bulk Minting service, which accessible only through ARDC Services and is available to eligible institutions who have made prior arrangement with ARDC. Access to this service shall be approved,by ARDC.
ARDC does not impose a large number of policy constraints on users of Handle Service ; instead, appropriate management policies need to be considered and implemented by the projects and institutions who create and maintain the identifiers.
It is critical for users of the Handle Service to understand that ARDC does not manage persistent identifiers; it only provides the infrastructure to allow minting, resolution and updating of identifiers. Processes and policies need to be put in place by those utilising the product to ensure that appropriate maintenance practices underpin persistence.
The ARDC Handle Service is a persistent identifier service. The underlying service functionality is based on the Handle system. More information on handles can be found at Handle.Net Registry.
A handle consists of two parts: a naming authority and a label unique within that naming authority. The two parts are separated by a forward slash ('/'). Naming authorities themselves can consist of different parts, separated by dots ('.'); unlike Domain Name Systems (DNS), this does not imply a hierarchical structure of authorities.
Handle technology allows specific handle names to be requested and allocated. The ARDC Handle Service product allocates handle names on behalf of the user.
The ARDC Handle namespace is 102.100.100. Handles allocated by ARDC are numerical values in sequence within this namespace. ARDC handles therefore look like '102.100.100/76908'. A resolvable URL for an ARDC Handle looks like http://hdl.handle.net/102.100.100/76908
All interactions with the ARDC Handle server will either take place via a proxy server ('resolver') such as hdl.handle.net, or through the ARDC Persistent Identifier web service.
Handle Servers do not come with a web interface. A specialised application is required to enable users to interact with them. Two such applications (one command-line, one Java GUI) are included with the Handle Server software, and libraries exist to allow other applications to be written.
Handles minted using the online option can only be updated using the online interface and the user ID which minted the handle. Handles minted using web services can only be updated using web services and the trusted application which minted the handles. In the event a trusted application is decommissioned, management rights for handles will need to be transferred from one trusted application to another.
ARDC offers an online service (ARDC Self-Service Identifiers) and a set of web services which interact with the Handle System (ARDC Handle web service).
ARDC does not provide a Handle proxy server. Instead, ARDC utilises hdl.handle.net as the preferred resolver for persistent identifiers. ARDC handles can therefore be cited as 'http://hdl.handle.net/102.100.100/10'.
ARDC will endeavour to ensure the services underpinning the Handle Service are highly available. However, occasional maintenance outages are inevitable.
Users of the Handle Service product should ensure that software being integrated with this product is designed to cope with Handle service unavailability.
Labels for persistent identifiers can allow a user to infer things about the object being identified from the label itself. This can make the identifier easier to remember, easier to enter without error and easier to communicate to others. However, meaningful labels are usually based on attributes of the objects identified that are less likely to persist than the object itself. Meaningful labels then become misleading or possibly broken.
The ARDC Handle Service product allocates non-meaningful numeric identifiers within the 102.100.100 namespace.
Persistent identifiers are often used as part of URLs.
They should therefore not contain characters which need encoding to be embedded safely in URLs, such as '&' or space: such conversion can confuse users as to whether the encoded or the unencoded label is the 'real' label. For example, 'a&b', when URL-encoded, becomes 'a%26b'.
The ARDC Handle Service product always generates URL-safe identifiers.
Persistent identifier labels with multiple possible variant forms should be avoided, as users (or systems) risk assuming that the variants are distinct after all. Case sensitivity should be avoided, as should visually confusable characters (1 I l, 0 O), as humans risk failing to distinguish them.
The ARDC Handle Service product does not generate labels which can be confused within the American Standard Code for Information Interchange (ASCII), as it uses numeric labels exclusively.
Labels will likely be delimited by punctuation, both when cited in running text, and when embedded within URLs or other identifiers. Consequently, punctuation should be avoided in labels.
The ARDC Handle Service product does not use punctuation within labels.
As labels will sometimes need to be written down or manually entered into a system, they need to be short enough to write down or to type.
The ARDC Handle Service product uses short numeric labels.
As ARDC handles are intended as part of the data fabric for Australian research, online resolvability is critical.
ARDC recommends citing identifiers uniformly as HTTP URIs, using the default Handle resolver, e.g. as 'http://hdl.handle.net/102.100.100/10'.
Keeping identifiers persistent consumes resources, and should not be undertaken lightly. Data managers need to prioritise what to identify persistently in their domain. Those decisions depend in turn on an information model of the domain of objects that may potentially be identified: persistent identifiers will only be assigned to a subset of those objects. Drawing up such an information model can help anticipate how identifiers are likely to be used and adjusting the information model can capture explicitly what the changes in those expectations are.
ARDC recommends that data managers considering an implementation of the Handle Service undertake an upfront information modelling exercise.
ARDC recommends that data managers considering an implementation of the Handle Service undertake an upfront process modelling exercise including allocation of responsibility for the identifier manager role.
ARDC recommends that data managers considering an implementation of the Handle Service for use with objects which have not crossed the curation boundary or objects which will not become public ensure there is a sound rationale for the use of persistent identifiers with these objects.
As the persistent identifier and the object identified are discrete digital objects, management of the timing of the creation and public release of the two digital objects needs to be coordinated. A digital object should not be published before its persistent identifier is published. Otherwise, the digital object's non-persistent URL could end up cited instead of its persistent identifier; once third parties start using a particular identifier, it is difficult to achieve a switch to another identifier.
ARDC recommends association of the name (of the object) with the object in the identifier record, before either is published. If necessary, the name can be published before the object is accessible, on the understanding that it will fail to retrieve the thing in the short term.
ARDC recommends that an identifier, once issued, should always resolve to something, even if that is a notice of unavailability of content.
ARDC recommends that data managers implementing the ARDC Handle Service product determine an appropriate persistence period for the identifiers they intend to mint and undertake to put policies and processes in place to support that persistence period. This intended persistence period should be discoverable by identifier users.
Authority metadata is information about who has (and has had) responsibility for managing the identified object. Adding this type of information to the description (DESC) fields associated with a handle enables interested parties to make contact with a responsible data manager in the event that a handle fails to resolve.
ARDC recommends that contact information is recorded with the handle for each handle minted. Contact information should itself be reasonably persistent; for example the maintainer should be identified by role and not as an individual and contact mechanisms should be generic rather than particular (i.e. switch board telephone numbers and general enquiries mailboxes).
Because authority metadata is used when things go wrong, its availability should not be reliant on external systems; failure to access an external system may be why things have gone wrong to begin with. Contact data should therefore be stored directly in the identifier record, rather than linked through some external database.
Note: ARDC does not store contact information for the individuals or systems who use the Handle Service. Responsibility for providing interested parties with assistance in the event of an identifier failing to resolve rests with the person or organisation who minted (or maintains) the handle.