 |
Previous Chapter: 8 Registration Agencies Next Chapter: Appendix 1 ANSI/NISO Z39.84-2000 Syntax for the Digital Object Identifier
9 Operating procedures
This Chapter summarises common procedures and rules for the registration and
maintenance of DOI® names and associated metadata. Registration Agencies will adopt their own
detailed operating procedures and these should be consulted in addition to this general
guide.
©International DOI Foundation 2006
9.1 Registering a DOI name with associated metadata
9.2 Prefix assignment
9.3 Transferring DOI names from one Registrant to another
9.4 Handle System® policies and procedures
9.4.1 Overview
9.4.2 Policies and Procedures
9.4.3 Requirements for Administrators of Resolution Services
9.4.4 Protocols and Interfaces
9.5 DOI® System error messages
9.1 Registering a DOI name with associated metadata
Registration Agencies support registration of DOI names with associated metadata declaration, i.e. using a DOI® Application Profile. Individual Registration Agencies will develop their own workflow and procedures for the management of DOI name registration, and metadata deposit and maintenance. Registration Agencies will provide their own information to their community of registrants.
Registering DOI names (Example): The following procedure is as an example of the current process followed by an individual Registration Agency for the registration of a DOI name with declared metadata.
This procedure allows for the batch registration of DOI names and associated metadata records into a DOI System Central Metadata Directory run by the Registration Agency; this directory can subsequently be queried. The batch file format currently in use is XML as defined by a specific XML Schema, and submission is via HTTP POST. Security is HTTP basic authentication; PGP encryption will be added later. Batch receipt is confirmed to the sender via email.
Metadata Creation: The Registrant prepares XML batch files in accordance with the Schema; these are further constrained by a set of rules for the data, which define the expected content of each metadata element. An XML batch may contain metadata for hundreds of DOI names.
The development and implementation of quality control measures used to ensure the validity of the metadata content are the responsibility of the Registrant. Quality control and data checking can be assisted by processes put in place in the RA's metadata collection process.
Metadata Collection: The XML is validated upon receipt against the Schema. If the XML does not parse, the batch is refused; the Registrant must correct the XML and resubmit the batch.
XML batches are submitted to a named HTTP server via HTTP POST to a Java "servlet", which parses and validates the XML file, and notifies the Registrant in real time whether or not the XML is valid and has been accepted. The submission process captures and verifies a DOI System prefix holder login and password prior to validating the XML. The XML files themselves contain timestamps used as identifiers of the batch; should the Registrant so wish, each DOI name record may have its own timestamp.
DOI Name Deposit: The servlet then deposits each DOI name and its corresponding URL into the DOI System, adding timestamp data value. If the DOI name is not new and therefore already exists in the DOI System, the timestamp is key to determining whether the DOI name data being contributed is newer than the data that is already in the system; if so, the existing DOI name data is updated. A log file also written in XML is created for each batch, indicating the total number of DOI name records in the batch, the number of successful deposits into the DOI System, and the number of failures. For each failure, the DOI name is provided, along with the reason for the failure. While DOI System failures may be the result of system errors, they are most typically caused by an attempt to overwrite existing DOI name data with older data.
Metadata Database Record Generation: The original XML batch files, along with the log files for the batches, are made available daily to the metadata database deposit process, where they are indexed and then made available for searching. A final XML log file is generated to indicate the success of the database deposit (again, failures are due primarily to network or system errors) combined with those from the DOI name deposit process, and this combined XML batch diagnostic is emailed to the Registrant.
The entire metadata collection process is expected to be completed and reported to the Registrant in as close to real time as possible; 24 hours is currently seen as a reasonable target time. However, when Registrants initially make deposits, there are large amounts of legacy material and coordination is needed on when the legacy batches are deposited or system performance can be affected.
Data Querying: The metadata database (MDDB) may be queried by submitting a batch file of known metadata fields in a specified format, currently pure ASCII text on separate lines, with fields delimited by vertical bars. The batch interface will query the database and return the corresponding DOI names (if known), or a diagnostic message. Batch query files are submitted by HTTP POST to a named HTTP server.
9.2 Prefix assignment
All RAs will receive a document entitled "Obtaining DOI Name Prefixes". This document gives instructions on prefix allocation and administration which is provided by the Directory Manager (jeuler@cnri.reston.va.us).
9.3 Transferring DOI names from one Registrant to another
If a compilation of multiple assigned DOI names (for example, a journal containing a collection of articles; an imprint; a recording catalogue; etc) is transferred from one registrant to another the DOI names within that compilation are transferred as well. For DOI names registered via the IDF the following guidelines apply. Each RA will develop appropriate procedures for this as well. For clarity, in the following we assume the transfer is a sale and refer to "seller" for the original registrant and "purchaser" for the new registrant; however transfer can cover any form of transfer, commercial or otherwise. If the purchaser is not already a DOI name registrant, special arrangements may have to be made appropriate to the case; consult the IDF for guidance if necessary. The following assumes that the purchaser is already a DOI name registrant.
The individual DOI names stay the same i.e. what the DOI name identifies is not changed: this is a fundamental requirement. The DOI name prefix does NOT change (recall that a prefix is not meaningful, but is initially assigned to a registrant for convenience in generating DOI names only; no reverse look-up can be inferred to a prefix). The administrative value is changed in order for the new owner to modify its data values (most likely the URL value). Both registrants (seller and purchaser) involved in the transfer need to send email to the Directory Manager at jeuler@cnri.reston.va.us giving permission for the transfer. As a follow-up, a letter from the registrant making the sale needs to be sent directly to the IDF as well. The email and letter should state the two registrants, with a contact person and email address, the entity (e.g. journal titles) and both registrants prefixes.
The DOI Directory Manager will request a list of the DOI names (text format, one DOI name on each line) from the selling registrant. The Directory Manager will modify the DOI names in the batch so that the purchasing registrant can update them.
Each DOI name has its own administrative value and that value refers to a list of administrators (a group) within the prefix record in the Global Handle Registry®.
Here is an example of a transfer between DOI names that begin with 10.1000 to the administrator of prefix 10.1200:
The Prefix record on global looks like this:
100 HS_ADMIN 0.NA/10.1000
200 HS_VLIST 0.NA/10.1000 (admin users listed here such as 'jUser')
Each DOI name that is created has as its admin value a reference to the HS_VLIST record in the prefix. In order to change administrators, the batch file will have to ADD VALUE (for the HS_VLIST reference to the new administrator) and then DELETE VALUE(to delete the existing HS_VLIST reference).
The values of a DOI name look like this:
1 URL http://www.doi.org
100 HS_ADMIN 0.NA/10.1000 index 200
The NEW values will look like this:
1 URL http://www.doi.org
101 HS_ADMIN 0.NA/10.1200 index 200
The Directory Manager will notify the purchasing registrant when the DOI names are modified. The new registrant owner can then use the UPDATE batch function from the java client or administration forms to modify the URL data of their newly acquired DOI names.
9.4 Handle System® policies and procedures
As the DOI System uses the Handle System, it inherits the underlying policies and procedures of that System. These are summarized as follows.
9.4.1 Overview
The Handle System® is a component of the Digital Object Architecture developed by CNRI. It provides a means for uniquely identifying Digital Objects ("DOs") and other network resources and for using the identifiers, known as handles, to store and retrieve records containing state information about the DOs. It also provides an administrative mechanism for managing identifiers over time.
The term Digital Object is used to denote structured data in the form of a set of bit sequences that can be interpreted by a computer or other computational facility. Each sequence consists of a type-value pair, at least one of which is the handle for the DO. The sequences need not all be stored in one place, or stored at all, but if they are stored, they are generally assumed to be accessible from one or more known locations.
One form of state information is the location(s) of the DO. Another form is selected metadata about the DO, generally known as key metadata. Type information is an example of key metadata. Type information itself is stored as DOs and can be retrieved by a formula that converts type strings into handles. Types used in handle records must be resolvable in the Global Handle Registry® ("GHR"). The types intended for general use by the public are stored in the GHR, but may also be stored at the Local Handle Service ("LHS") level, if desired.
Each handle consists of a prefix (which determines who can administer the handle record) and a suffix separated from the prefix by a slash "/". The prefix, which is not permitted to contain a slash, is maintained as unique by the Handle System; and the suffix may be any string selected by the Administrator for that prefix. A prefix without a suffix is also a handle.
The top level of the Handle System is the Global Handle Registry, which contains all the prefixes, and may contain all, some or none of the handle records associated with each prefix. The handle records not stored in the GHR would be retained in Local Handle Services and resolved from those services. Handle records may be stored in both the GHR and in LHSs.
The GHR has been designed as a flat, scalable system and is currently optimized for resolution performance. Administration of handles may also be done online over the net by the Administrator for the handle(s).
CNRI is making the Handle System Technology, specifically the HANDLE.NET® Software, available on a cost recovery basis to organizations and individuals for provision of handle resolution services. This will be done in such as way as to maintain the integrity of the system, while supporting the overall Handle System operation. All individuals and organizations that wish to provide resolution services using the Handle System technology must register as administrators and enter into an agreement with CNRI for this purpose. In most cases, this can be accomplished over the Internet.
The Handle System Forum, when established, will provide advice and guidance to CNRI, or an organization licensed by CNRI to manage the Handle System, on the development of criteria to apply in setting the terms and conditions for operating resolution services using Handle System technology, as well as other matters relating to the system such as the operation of the Global Handle Registry. Administrators of resolution services will be eligible for membership in the Handle System Forum. Pending establishment of the Forum, the Handle System Advisory Committee ("HSAC") will perform this advisory function.
9.4.2 Policies and Procedures
Maintaining overall integrity of the Handle System entails ensuring that each of the following conditions is met by Local Handle Service (LHS) administrators, who must agree to operate their resolution services during the period while the authorization is in effect. The term "system" as used below refers to those LHS components run by each LHS administrator, and the interaction of these components with the GHR and the users of the LHS.
- Compatibility and smooth interaction among system components;
- Consistency and reliability in service performance;
- Proper system management and performance tracking;
- Non-interrupted access to the GHR; and
- Overall system security
9.4.3 Requirements for Administrators of Resolution Services
(i) Compatibility Test Suite Compliance (under development) covering:
- Performance requirements;
- Security requirements (proper updating, GHR service information, proper management of public key pair, proper implementation of security protocol and support of security algorithms); and
- Operational requirements.
(ii) Registration Requirements:
- All prefixes must be registered in the GHR, including the designation of an Administrator for each prefix;
- In those cases where resolution of all prefixes derived from a primary prefix is stated by the Administrator to occur at the same site as the primary prefix, the GHR will record that default site and that Administrator for all their prefixes.
- Secure maintenance of Private Keys by each Administrator; and
- Timely report by the Administrator of service configuration changes, such as a list of prefixes and the current type descriptions in accordance with the Handle-based typing framework ("HTF").
9.4.4 Protocols and Interfaces
An organization or individual developing Handle System client components is encouraged to use the CNRI client software and the standard interfaces supplied with it, and, in particular, shall not interfere with the normal operation of a Local Handle Service or other client applications in interacting with the Handle System client software or the Global Handle Registry. In the event an organization or individual wishes to use its own interface software, it is their responsibility to ensure that these interfaces remain compatible with the then current Handle System interface specification, which may evolve over time, as posted at the Handle System Internet site, http://www.handle.net/.
9.5 DOI System® error messages
It is inevitable that in adoption of DOI System technology, some mistakes or misunderstandings will occur. This may include actions which result in an attempted resolution not being successful; it is very important that such errors are detected and corrected. Automated procedures for common errors may be possible in some cases, but in the first instance a simple procedural agreement has been implemented. The following procedure is now in place: it is likely that for now the bulk of the error reports will go to RAs which represent the majority of deposits -- the current wording therefore reflects typical message, but other RAs will probably use similar procedures:
(1) Resolving (via the proxy) a DOI name that's not in the system returns a "DOI Name Not Found" error page to the user. You can view the page with the following: http://dx.doi.org/10.1000/8888. The page requests that users report errors to a special DOI System address (doi-help@doi.org.) There will be several staff monitoring the address.
(2) CNRI will do a preliminary check to rule out a system problem. If the problem is with the Handle System, CNRI responds to the sender appropriately. If the DOI name is not found, receipt of the error message is acknowledged with the following:
"Thank you for reporting this error. It has been forwarded to the appropriate DOI name registrant contact for action. Note that if the item the DOI name identifies is new the DOI name may have been unintentionally made public before being registered with the DOI System and may be available later".
(3) CNRI will forward the sender's message to the RA. If the DOI name belongs to a "default RA" owner, CNRI will report the error to the owner and follow up.
(4) The RA will take appropriate action, and see that the sender and CNRI (via cc's to the doi-help@doi.org address) are kept informed of the action taken. This is meant to be informative and, at least for now, the IDF, via CNRI, will not try to put in place any kind of system to guarantee that the RA takes the appropriate action.
Previous Chapter: 8 Registration Agencies Next Chapter: Appendix 1 ANSI/NISO Z39.84-2000 Syntax for the Digital Object Identifier