[ View/Print a PDF Version of this document.]

The DOI System is complementary to, not in competition with, any "identifier" scheme that provides an accepted numbering syntax for a particular community or area of interest. Such numbering schemes may be official standards such as ISBN, ISTC, etc., or could be accepted community practice. Any existing numbering schemes can be used within the DOI System: DOI^® names can add value to any accepted current numbering scheme.

The word "identifier" is used to mean several different things [1]. To avoid confusion, this document avoids conflation by referring instead to:

• "Numbering scheme" (NS): consistent syntax for generating a series of unique labels denoting and distinguishing separate members of a class of entities. Common examples are the ISO series of "identification and description" standards [2] (e.g. ISBN), schemes from other standards bodies (e.g. SICI), less formal community standards (e.g. PII), or consistent internal numbering schemes.
• "DOI^® System": comprising syntax, resolution, data model and policy components; providing functions of persistence and semantic interoperability for identified entities.

The functions of NS and the DOI System differ but are complementary and mutually supportive.

• The function of a NS is to provide a consistent syntax for naming members of a class of entities. The entities have some common characteristic, typically that of product form (e.g. ISBN is used to number book editions). To number another form, another NS is used (e.g. SICI for numbering articles), which need have no explicit formal relationship with other NS.
• The function of the DOI System is to provide persistent identification through a packaged service of resolution, semantic interoperability, common tools and policies. It may be applied to any named entities, across all NS populations. All entities are assigned a unique DOI name and function within the one DOI System.
• A NS may be used within a DOI name syntax. Doing so adds the function of the DOI System to the function of the NS. This is sometimes called making the [NS] identifier "actionable".
• A DOI name requires a process for enumerating members of the class of entities identified: an appropriate NS can provide this.

The numbering scheme of the DOI System takes the form prefix/suffix (e.g. 10.1000/123456 - in this example, the prefix is "10.1000" and the suffix is "123456"). The prefix is determined by the DOI System; the suffix is determined by the registrant and may be a number determined by an existing NS.

• All DOI names are opaque strings for the purposes of the DOI System. When a NS identifier is incorporated into the DOI name as a suffix, the DOI System treats this as the same as any other identifier. The suffix can retain significance to other (non DOI System) systems that may parse the DOI name (knowing its construction to derive the NS) or use the NS alone.
• The DOI System does not mandate the form in which the NS is used as suffix, e.g. each of the following would be valid as DOI names:
  
  10.1000/1047935X
  10.1000/ISSN1047-935X
  
  However, it is recommended (to assist in parsing for non DOI System uses) that a DOI name registrant explicitly using one NS should use only one consistent format, and make this format a requirement of that particular DOI System application. (Note that the two examples above are different opaque strings and hence different DOI names.)
• If a specific NS is adopted as the means of generating the DOI name suffix, then the governance and control of that NS remains with its owner; the DOI name numbering syntax simply inherits the result of the scheme.
• If there is no current NS used to identify the entities at present, the DOI name may become the numbering scheme de novo. In that case, the registrant community will need to adopt or devise a suffix scheme: this could simply be a sequential assignment number or a more sophisticated scheme. This in turn may assist in the adoption of that suffix scheme as a new NS by the community.

• Where multiple NS are already in use in a sector, use of a DOI name obviates the need to agree on one single NS for a community for the purposes of DOI System functionality, since the DOI System creates DOI naming interoperability across diverse NS. An example is the use of DOI names in identifying articles in CrossRef. Publishers use many different schemes which all form DOI names that can then be used together: e.g.:
  
  Registrant A uses PII: S1384107697000225
  Registrant B uses SICI: 0361-9230(1997)42:<OaEoSR>2.0.TX;2-B
  Registrant C uses internal scheme: JoesPaper56
  
  These three schemes are not at all interoperable, but become so in the DOI System as respectively:
  
  doi:10.2345/S1384107697000225
  doi:10.4567/0361-9230(1997)42:<OaEoSR>2.0.TX;2-B
  doi:10.6789/JoesPaper56
  
  
• The DOI System places no requirements on the use of a single NS in a given community. But since numbering schemes, once adopted, are likely to be re-used across applications, it is recommended that the registrant community, working through a Registration Agency, consider whether one or more specific NS is appropriate for a DOI System application. It is likely that this choice will be determined by how widely the NS is used in (non DOI System) systems and hence the likelihood of DOI names being parsed for non DOI System uses, or the suffix being used alone outside the DOI System.

If the NS also mandates the registration of associated metadata with an identifier, this metadata may also be used within the DOI System.

• The NS retains its own metadata scheme and values if used in a DOI name. The DOI System uses an interoperable structured data dictionary: the indecs Data Dictionary (iDD). The DOI^® Data Model embraces both this data dictionary and a framework for applying it. The data dictionary component is designed to ensure maximum interoperability with existing metadata element sets; the framework allows the terms to be grouped in meaningful ways (DOI^®Application Profiles) so that certain types of DOI names all behave predictably in an application through association with specified Services. Registration in a DOI Application Profile (DOI^® AP) and indecs Data Dictionary (iDD) enables semantic interoperability with any other schemes used by other users.
• Use of DOI names does not require the adoption of a new metadata scheme, merely the optional mapping of the existing scheme into the DOI System to aid semantic interoperability. Mandatory requirements for DOI name registration using metadata in a DOI AP are (1) to make available a standard Kernel Metadata Declaration for every entity; (2) to register all terms used in metadata declarations for DOI APs in the iDD.
• Registrants may continue to provide metadata in any format according to the needs of their user community.
• If the NS has associated metadata but it is not well-formed [3], the mapping process to iDD may assist in the development of rules for more structured metadata within the NS, which will assist both in automated use of the NS and in further developments of the NS.
• If there is no current NS used to identify the entities of interest at present, defining a specification for the entities through the iDD may assist in the creation of well-formed metadata by the user community.

• By associating relevant metadata with each entity DOI name which explicitly denotes related entities; and/or
• By using the resolution component of the DOI System to resolve from one entity to a related entity (including one-to-many relationships and one-to-self relationships i.e., aliases)

• A specific DOI System application constrains the scope of the application by defining an Application Profile (AP). This AP consists of both technical and business rules and may be chosen so as to coincide with the scope of an existing NS: this will be particularly useful if the intention is that a specific NS is adopted as the means of generating the DOI name suffix.
• A DOI name is an object identifier designed for use on digital networks ("digital" refers to the network use, not the object)
• The objects identified by a DOI name may be any entity type: digital, physical, or abstract. DOI names can be used to make actionable within a single system entities encompassed by many different NS schemes.
• Although DOI names have initially been used to identify content resources, it is possible to extend its use to organizations, licences etc.

• For example, ISBNs define books, not chapters (exceptions may occur in practice, and a few NS allow arbitrary granularity); DOI names may be applied to both ISBNs and chapter identifiers.
• The use of well-formed metadata through a DOI AP enables the precise formal specification of the granularity of the entities together with an explicit structured relationship between entities.
• Granularity relationships such as parent-child may be expressed as DOI name relationships.

Technology independence

DOI names, and most NS schemes of interest, are abstract specifications, which are then implemented in a technology though not dependent on that specific technology.

• The principles of:
• naming behind the DOI name syntax structure;
• ontology behind the indecs Data Dictionary, and
• digital object architecture behind the Handle System
are all abstract frameworks.
• Although these are implemented in reference and practical DOI System technologies (e.g. metadata declarations as XML) the DOI System may migrate to other technologies as and when these become available and appropriate.
• DOI names are independent of technology and protocols. They may be applied to any network structure. They are specifically not restricted to use within Web or other specific environments.

• NS may already provide one or more of these components in addition to the numbering scheme: commonly they mandate a registration authority, maintenance authority, rules of application, and simple metadata but not resolution.
• In theory, tools for specification, syntax, metadata declaration and resolution could be chosen from a variety of independent sources (without using the DOI System); however such separate components are not readily interchangeable: there is no guarantee of technical interoperability, with no overall architecture and no single means of governance.
• A common single system enables the development of common services.
• A multitude of systems, each assembled from different components, has significant implementation barriers compared to a single system.
• Additional functions beyond the DOI System may be needed for specific application areas, such as rights negotiation and exchange, access control, etc: the DOI System deliberately does not include these but provides a coherent framework on which they may be built. Some other initiatives may wish to make use of the DOI System as a component within such wider systems or architectures, e.g. proprietary Digital Rights Management systems, multimedia frameworks such as ISO MPEG21, etc.

• The DOI name syntax is a NISO standard, Z39.84-2005 [4]
• DOI System resolution uses the Handle System documented in IETF RFCs [5]
• DOI Data Model tools are based on the indecs framework, now developed as the ISO/IEC MPEG-21 Rights Data Dictionary [6]
• Policy implementation and deployment rules of the complete DOI System, governance, registration authority, business models and other aspects are governed by the independent International DOI Foundation.

Notes

[1] These range from label numbering schemes (like ISBN) through technical infrastructure specifications (like Uniform Resource Identifier, and Extensible Resource Identifier), to implemented systems of identification (like EAN bar codes, the ISBN system, and the DOI System) -- even within one of these categories, two "identifiers" may not be directly comparable.

[2] ISO TC 46/SC 9 Information and Documentation - Identification and Description, [ http://www.iso.org/iso/standards_development/technical_committees/list_of_is o_technical_committees/iso_technical_committee.htm?commid=48836 ].

[3] Uniform and unambiguous, mapped through an ontology to derive an explicit formal specification of how to represent the entities that are assumed to exist in the area of interest of the NS, and the relationships that hold among them.

[4] ANSI/NISO Z39.84-2005 Syntax for the Digital Object Identifier, [ http://www.niso.org/standards/ ].

[5] Sun, Sam; Lannom, Larry; Boesch, Brian. "Handle System Overview". RFC 3650, November 2003. [ http://hdl.handle.net/4263537/4069 ]; Sun, Sam; Reilly, Sean; Lannom, Larry. "Handle System Namespace and Service Definition". RFC 3651, November 2003, [ http://hdl.handle.net/4263537/4068 ]; and Sun, Sam; Reilly, Sean; Lannom, Larry; Petrone, Jason. "Handle System Protocol (Ver 2.1) Specification". RFC 3652, November 2003. [ http://hdl.handle.net/4263537/4086 ].

[6] ISO/IEC 21000-6:2004 Information technology -- Multimedia framework (MPEG-21) Part 6: Rights Data Dictionary [ http://www.iso.org ].

[ View/Print a PDF Version of this document.]