  
|
Search Guidelines
Contact Us
Members Only
|
|
About the DOI System
Frequently Asked Questions
International DOI Foundation
Activities
Resources
IDF Members Only
|
|
Home > Frequently Asked Questions
Frequently Asked Questions about the DOI® System
These "Frequently Asked Questions" about the DOI System and DOI® names are not meant to take the place of the fuller information available in the DOI® Handbook; where possible, we provide pointers to the relevant section of the Handbook. If you have a question that you think should be added to this list, or is not satisfactorily answered, please feel free to contact us at contact@doi.org.
See also the DOI Handbook Glossary for definitions of related terms.
See also the Handle System® FAQs about the underlying handle resolution technology.
1. What is a DOI® name?
A DOI name - a digital identifier for any object of intellectual property. A DOI name provides a means of persistently identifying a piece of intellectual property on a digital network and associating it with related current data in a structured extensible way.
A DOI name can apply to any form of intellectual property expressed in any digital environment. DOI names have been called "the bar code for intellectual property": like the physical bar code, they are enabling tools for use all through the supply chain to add value and save cost.
A DOI name differs from commonly used internet pointers to material such as the URL because it identifies an object as a first-class entity, not simply the place where the object is located. The DOI name identifies an entity directly, not some attribute of an object (an address is an attribute of a thing, whereas the thing itself is a first class object).
A DOI name also differs from commonly used identifiers of intellectual property such as standard bibliographic and related identifiers (ISBN, ISRC, etc) because it can be associated with defined services and is immediately actionable on a network.
A DOI name is an implementation of the Internet concepts of Uniform Resource Name and Universal Resource Identifier. A DOI name differs from abstract naming specifications such as URI in that it is a defined implementation complete with social and technical infrastructure, ready to use.
For more on this topic, see the DOI Handbook chapters Introduction and Numbering.
2. What can be identified by a DOI name?
A DOI name can be used to identify any resource involved in an intellectual property transaction. Intellectual property includes both physical and digital manifestations, performances and abstract works. An entity can be identified at any arbitrary level of granularity. DOI names can be used to identify, for example, text, audio, images, software, etc; and in future could be used to identify the agreements and parties involved. While the scope of intellectual property transactions is quite broad, it is unlikely that DOI names would be appropriate for identifying entities such as people or natural objects or trucks unless they are involved in such a transaction. Intellectual property transactions don't necessarily involve money: DOI names can be used to identify free materials and transactions as well as entities of commercial value.
A DOI name is an implementation of URI (Uniform Resource Identifier, sometimes called Universal Resource Identifier, IETF RFC 2396). It uses the Handle System® for resolution of the identifier, and the indecs framework for metadata description. The syntax of the DOI name is specified by a NISO standard, (ANSI/NISO Z39.84).
While a DOI name can therefore be used like any other URI to identify "anything that has identity", the DOI® System is a combination of components (identification, resolution, data model and policies) devised with the specific primary aim of identifying any "intellectual property entity". The initial focus of DOI System applications was "Creations" -- that is, resources made by human beings, rather than other types of resource (natural objects, people, places, events, etc). However these other types of resource are also necessarily involved in intellectual property transactions, and so may be identified by DOI names where appropriate. As an example, the initial aim of DOI names was not to be used to identify natural objects (e.g. specimens in a natural history museum, or natural substances used in pharmaceutical research): but if these were involved in intellectual property interactions there may be an application of DOI names to museum artifacts or pharmaceutical components which would be appropriate. Similarly, a DOI name was not initially an identifier for agreements or licences, but implementers may find it useful to identify these with DOI names alongside the intellectual property that they govern.
Formally, DOI® scope is defined in terms of the indecs analysis: a DOI name can be assigned to any entity which is a Resource within the indecs model of e-commerce. This means the type of entity must be described in terms of attributes in the dictionary (e.g., media, mode, content, subject), and become an entry in the indecs Data Dictionary used by the DOI System. The practical outcome of this is important and provides a pragmatic functional specification: a DOI name can identify any Resource, but the DOI System requires that the Resource is defined (technically and hence precisely) in terms of agreed public (iDD) attributes. This is one role of the DOI® Data Model.
Within the world of intellectual property entities as resources, the primary focus of the DOI System has been on the identification of a Creation. The Data Model component of the DOI System uses the concept of a Kernel set of metadata. The kernel metadata as currently defined relates only to Creations, and a different kernel will need to be defined for fundamentally different Resources or entities such as parties, places or agreements. There is no problem in principle in doing this as the concepts are analogous; it may be a logical and necessary step (e.g. if a Registration Agency wishes to use DOI names to identify individual licence agreements, authors, consumers, etc).
For more on this topic, see the DOI Handbook chapter Introduction.
3. How do I assign a DOI name?
A DOI name prefix (for example, 10.1000/) enables a registrant to assign many DOI names, by building on the prefix to construct a range of unique identifiers (10.1000/abc, etc). To obtain a prefix, you need to work with a Registration Agency (RA) or, for exceptional experimental or prototype purposes, with the International DOI Foundation.
DOI name prefixes can only be assigned by an authorised DOI Registration Agency (RA); there are three ways you can do this:
The point about commitment is the key here. Many people like the idea of a persistent identifier; however there is no point in having a persistent identifier unless you are going to use it in a service -- such as citation matching -- so the way to proceed is to look for an appropriate service offered by an RA. Whilst everyone has the intention to maintain persistent identifiers, sadly experience shows that this is not always possible -- people move on, organisations and institutions change. That is why the DOI System requires a formal commitment to persistence. Working with a Registration Agency brings with it this formal commitment by participation in a defined DOI System application with others. Several Registration Agencies have been appointed, and additional Registration Agencies will be appointed.
For more on this topic, see the DOI Handbook chapter Registration Agencies.
4. How much does it cost to assign a DOI name?
Registration Agencies (RAs) are free to set fees independently of the IDF. This allows a range of pricing and business models using third part registration agencies, in recognition of the fact that a simple model is not a "one size fits all" solution. Many RAs will be assigning DOI names as part of a wider service offering to customers in which DOI name registration may not be a separately specified item. Registration Agencies participate in the DOI System by paying fees (of the order of a few cents per DOI name) to support central activities of the IDF.
There is no limitation placed on the number of DOI name prefixes that any organization may choose to apply for. DOI name prefixes will only be issued using the direct route at the discretion of the IDF.
For more on this topic, see the DOI Handbook chapters IDF and Registration Agencies.
5. Why do I need a Registration Agency to assign DOI names?
Registration Agencies (RAs) are established to provide services on behalf of specific user communities. CrossRef, for example, is providing citation-linking services for the scientific publishing sector, so publishers will choose CrossRef as their Registration Agency if they wish to use the specific service or services offered by CrossRef. Choosing an appropriate RA will give you access to DOI System services and implementations offered by the RA for that community.
RAs may offer sectoral specialisms of this kind, which may have global application; or may offer regionally based services such as local language support. The smooth running of the DOI System requires close collaboration between different RAs so that registrants can avail themselves of the full range of services that are offered.
If you cannot identify an appropriate Registration Agency able to meet your specific needs please contact us. The IDF will act as a "default" Registration Agency for the foreseeable future, to host registration of such DOI names until an appropriate Registration Agency can take over. IDF can also form working groups of like-minded organisations who may wish to establish a collaborative activity to form an RA, and stimulate the development of business opportunities. It will not compete with RAs that have an established market position.
For more on this topic, see the DOI Handbook chapter Registration Agencies.
6. Do I have to be a member of the IDF to assign DOI names?
No. Membership of the IDF is not associated with assignment or use of a DOI name. Membership supports the aims of the IDF and finances development work.
To assign DOI names, work via a Registration Agency. See also FAQ 3 - "How do I assign a DOI Name?" and FAQ 5 - "Why do I need a Registration Agency to assign DOI names?".
For IDF membership information, see FAQ 7 - "How do I become a member of the International DOI Foundation?".
7. How do I become a member of the International DOI Foundation?
Members of the DOI Foundation are organizations (not usually individuals). Membership requires payment of an annual subscription, which varies by category of membership. The International DOI Foundation is similar in some ways to other development organisations such as the World Wide Web consortium.
For more on this topic, see the DOI Handbook chapter The International DOI Foundation, in particular Section 7.13, Membership of the International DOI Foundation.
8. How do I work on a practical development to use the DOI® System?
The IDF finances all the central, communal infrastructure and architecture work described in the DOI Handbook and fact sheets on our web site. The entry price we ask for using that work in collaboration with us is that interested parties become a member of the IDF or work with an existing member. As a member, you can get a DOI name prefix for experimental purposes: we require that this will be limited in use and not used in a production environment. You can work alone, or with an existing Registration Agency.
IDF cannot design a solution to your specific problems: only you know what it is you want to achieve. We can however discuss your ideas and issues, either in confidence with IDF technical staff (under NDA if requested); or with other RAs in the open working groups (such as the RA Working group -- mainly business and policy issues -- and the Technical Working Group). The individual work necessary to build on top of the common infrastructure is done and financed by you, or in collaboration with anyone else you wish. How much work is needed depends on what you want to do. The main tools we have available are (1) handle resolution, and (2) semantic interoperability (metadata). The two tools are the data model framework, which defines the multiple resolution; and the data dictionary, which defines the metadata in application profiles. Both are outsourced to experts. The Data Model framework is dealt with primarily by our colleagues at CNRI (i.e., the Handle System). The metadata in APs is dealt with by our colleagues at Rightscom to whom we outsource the (developing) dictionary work.
Depending on the depth of work needed, involvement with these technical experts is either free or by arrangement with them under IDF auspices. Rightscom have been -- and continue to be -- involved in work on behalf of RAs. Some of these (like Journal RMD -- see below) involve consortial developments in which the IDF are also involved. Others involve work for individual RAs. Some of this work contributes to the developing central data dictionary (iDD) in the form of mappings. The cost of these has been charged to RAs at an agreed "IDF" consultancy rate. Where work is limited solely to the mapping and maintenance of an RA's terms to the iDD, Rightscom provides a service at a standard rate for RAs. However, it is common for an RA's iDD-related work and other ontology work to be highly integrated, and where this occurs no clear separation of the activity, or a standard rate pricing, is possible as other commercial constraints may apply.
An exemplar application was developed by IDF and some RAs. This is the Journal-RMD ("Resource Metadata Declaration"), an XSLT stylesheet designed to support the interchange of journal metadata between RAs, based on the existing schemas and requirements of three RAs. Its semantics are integrated with the iDD and it is proposed as a model for data interchange among RAs with other "RMDs" in future. Its development has been paid for by IDF and the participating RAs, and it is wholly owned by the IDF and its RAs.
9. What is resolution and why is it important?
The process in which an identifier is the input (a request) to a network service to receive in return a specific output of one or more pieces of current information (state data) related to the identified entity: e.g. a location (such as URL) where the object can be found. A name (or unique identifier) for a digital object enables that name to be resolved to one (or many) of several different pieces of data which may be associated with the digital object. Such pieces of data can be locations of the object, or services about the object, or any other defined piece of data. Resolution enables a single name (the identifier, DOI name) to be used persistently to manage the object, even if any of those pieces of data (like location) change. Resolution therefore (a) enables persistence and (b) enables multiple services to be directly associated with the DOI name.
For more on this topic, see the DOI Handbook chapter Resolution.
10. What is the DOI® Data Model and why is it important?
The DOI Data Model comprises an interoperable structured data dictionary: the indecs Data dictionary (iDD) 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 System Application Profiles) so that certain types of DOI names all behave predictable in an application through association with specified Services, This provides a means of integrating the features of Handle resolution with a structured data approach. DOI names need not make use of this data model, but it is envisaged that many will: any DOI name intended to allow interoperability (i.e. which has the possibility of use in services outside of the direct control of the issuing Registration Agency) is subject to DOI System Metadata policy, which is based on the registration of terms in the iDD.
The DOI Data Model uses the concept of a Kernel set of metadata which is related data about the object. Identifiers are simply names -- names that follow a strict convention and are unique if properly applied, but names just the same. Unique identifiers are particularly valuable in machine-mediated commercial environments, where unambiguous identification is crucial.
Some identifiers tell you something about the thing that they identify -- for example, since "ISBN" is the acronym of "International Standard Book Number", the identifier "ISBN 1-900512-44-0" can reasonably safely be assumed to identify a book (always assuming that ISBN rules have been correctly followed, which is not universally the case). However, to find out which book it identifies, it is necessary to consult metadata -- the identifier links the metadata with the entity it identifies and with other metadata about the same entity. The Data Model is an integral part of making the identifier useful. Further, to be useful in the widest sense that metadata must be interoperable with other schemes.
The Data Model approach used by the DOI System has no inherent commercial model. We take the view that a broad ontology supporting rights expressions must be able to support any kind of expression of any kind of right, agreement or license or any terms or none.
For more on this topic, see the DOI Handbook chapter Metadata.
11. Who is using the DOI System today?
Several hundred different registrant organizations have so far allocated several million DOI names. Because the origins of the DOI System were in the text sector, an initial large implementation covering half of these registrants was from traditional print-publishing companies that have already established major online publishing programs.
However the fundamental design of the system is applicable to any media or content. The IDF is working closely with many businesses in other sectors of the "content industries" to extend the application of DOI names to many other types of intellectual property.
For more on this topic, see the DOI Handbook chapter Registration Agencies.
12. What is the role of the International DOI Foundation?
The IDF governs the DOI System, to ensure that all applications follow common rules. The system itself has several components: the technology is based on open agreed standards, while the infrastructure is defined by agreements between the various organisations which run the system, such as the Registration Agencies and the technology providers. Each Registration Agency is autonomous and the IDF has no role in determining an RAs business model or governance.
The Foundation was created in 1998 and supports the needs of the intellectual property community in the digital environment, by the development and promotion of the Digital Object Identifier system as a common infrastructure for content management. The Foundation is a registered not-for-profit organization, controlled by an Executive Board elected by the members of the Foundation. Membership is open to all organizations with an interest in the management of information on digital networks.
For more on this topic, see the DOI Handbook chapter The International DOI Foundation.
13. Are there any guidelines on how to make up the DOI name?
The DOI name syntax is a NISO standard, but allows the incorporation of any form of existing identifier. The DOI name suffix can be any alphanumeric string that the Registrant chooses. This can simply be a sequential number, or it can make use of an existing (legacy) identifier. The latter may often be administratively convenient for the Registrant.
For more on this topic, see the DOI Handbook chapter
Numbering.
14. Does a DOI name include a check digit?
A check digit is not compulsory or necessary, but may be included. Identifiers such as URL and URI specifications, deriving from an Internet environment, do not have check digits: the underlying TCP/IP protocol they use has an error-correction component. Identifiers such as ISBN and similar bibliographic or documentation identifiers do have check digits: these act as aids to readability or keyboard data entry in the absence of any automated protocol correction.
A DOI name is deliberately designed as an opaque string, so that it is suitable for any use. The DOI System does not itself make use of check digits. However, other applications may: so if you wish to incorporate a checksum digit into a DOI name, you may. This could be useful for some other application. You may use as the suffix an existing string with a checksum (e.g. ISBN). You can also calculate the checksum across the whole DOI name if you wish (that would be akin to what the EAN/UPC does when it encapsulates an ISBN). Such a use of checksums in a particular DOI System Application could be a rule of the DOI System Application Profile concerned: "your DOI names must include a checksum".
For more on this topic, see the DOI Handbook chapter Numbering.
15. How does a DOI name compare to other common identifier strings for intellectual property like ISBN etc?
The International Standard Book Number (ISBN), in use by the book publishing industry for many years, is an example of a string of numbers that uniquely labels something. A DOI name Internet-enables such a string (Internet enabling in this context means resolution and then linkage to metadata). In effect the DOI System tackles two problems at once: (1) providing a label string if things don't have a common system right now; and (2) providing internet resolution for any label string at all. Although a DOI name is usually considered to be "An identifier (not a location) on digital networks for an entity", it in full is "a system for persistent and actionable identification and interoperable exchange of managed information on digital networks". So it's not only an identifier string for an object which may not have an existing identifier string; one could also have a DOI name which includes an ISTC, or an ISBN, or a GTIN, or anything else that is an existing identifier string or label or name for the entity. Early uses of DOI names have been for articles, chapters etc, but could be a lot more.
In those areas where there isn't already a commonly accepted identifier string, one can create one from the outset as a DOI name. For example, CrossRef does that for scientific articles (some of the publishers in CrossRef create DOI names from SICIs, PIIs, or simply publishers' internal production identifiers. What CrossRef have in effect done is internet-enable the previously non-interoperable SICI, PII, etc.)
So a DOI name isn't the "same sort of thing" as an ISBN, etc. A DOI name can take an identification string (ISBN, IPI, SAN, anything else) and potentially Internet-enable it. For all of the identifiers (strings) on the intellectual property roadmap, DOI names could provide persistent links to metadata and, where appropriate, to the identified object (entity) itself.
It's often difficult to explain this because the word "identifier" is now used in several ways which are actually different things -- label strings like ISBN, specifications like URI, and actual systems like DOI System and EAN bar codes. This is explained in detail elsewhere. (See http://www.doi.org/topics/drm_paskin_20030113_b1.pdf.)
16. What is the relationship between a DOI name and other development efforts?
The International DOI Foundation is a member of some standards organizations, and maintains a number of liaisons or alliances through memberships and/or exchange of information with others, which allow us to act as a collaborative interface in discussions on standards and infrastructure development across the spectrum of intellectual property and technology communities. This provides advantages both to members of the Foundation (who may otherwise not be able to participate in all of these discussions) and to the strategic partners (who deal with IDF as a common voice for the intellectual property community in this area).
The IDF participates in the management and governance of two technology development activities where it is a major user: the Handle System, and the indecs framework.
In addition the IDF has a number of other relationships with significant development and standards activities in many areas of intellectual property and technology. Some of these are specific to particular application areas, and are undertaken in order to seed activities and outreach from the DOI System to potential implementations. This list is expanding and we welcome expressions of interest from organizations who wish to establish such a relationship.
For more on this topic, see the DOI Handbook chapter The International DOI Foundation.
17. What is the relationship between the DOI System and the Handle System?
The DOI System is an application of the Handle System (a resolution system) to intellectual property. It is more than the Handle System: it adds to the Handle System an approach based on structured associated metadata, policies, procedures, business models and application tools. Initial implementations are now being supplemented by increasingly sophisticated value-added tools for metadata management and content management, which will use the Handle System multiple resolution function. The IDF participates in the management and governance of the Handle System, together with other stakeholders.
For more on this topic, see the DOI Handbook chapter Resolution.
Additional Handle System FAQs can be found on the Handle System Web site.
18. What is the relationship between the DOI System and the indecs framework?
The DOI System is an implementation of the indecs metadata framework. In addition, IDF participates in the management and governance of the indecs framework, together with other stakeholders. IDF is one of the organisations which developed the original indecs framework and is now developing it further. The indecs approach is fundamental to the DOI System's design.
For more on this topic, see the DOI Handbook chapters Metadata and The International DOI Foundation.
19. How do I participate in DOI System development?
Options include: working with a Registration Agency and obtaining a DOI name prefix and assigning DOI names on an experimental basis; joining an IDF working group to work with others in a defined problem area; or joining the IDF as a full member, with rights to participate in all working groups.
For more on this topic, see the DOI Handbook chapters The International DOI Foundation and Registration Agencies.
20. Is the DOI System relevant to rights transactions?
Yes. Fundamental to rights transactions are the concepts of unique identification and appropriate structured metadata. DOI System implements the indecs approach, which has at its heart the concept of rights management. IDF has introduced the concepts of the DOI System and indecs into many digital rights management activities such as MPEG-21, OEBF, TV-Anytime, etc.
For more on this topic, see the DOI Handbook chapters Metadata and The International DOI Foundation.
21. How do I develop a DOI System application?
Applications can range from DOI names being a persistent redirection to a single URL (which is easily accomplished) to advanced applications and services. Multiple resolution and defined metadata related through the DOI System data model ensure interoperability; the starting point for such advanced applications is the registration of a set of metadata appropriate to the particular community use being conceived. The DOI System does not mandate a single metadata standard; you may use any existing metadata standard; it does however require that for full interoperability the metadata set be mapped to the indecs Data Dictionary.
For more on this topic, see the DOI Handbook chapters Metadata and Applications.
22. Does the IDF intend to restrict in any way the usage of the DOI System?
There are very few restrictions placed on DOI System applications. However they must abide by the rules of the IDF, and must be applications which respect appropriate legal frameworks of intellectual property such as those of the World Intellectual Property Organisation.
Some restrictions have been placed temporarily, designed to ensure that the system expands in a controlled way: for example, initial applications were restricted to single point resolution (this restriction has now been lifted); DOI names are currently applied to any creation, but not yet to entities such as people and agreements. The concept could be applied to any such entity but our initial applications were confined to describing the intellectual property rather than its users or uses as this area is the best developed and the one where most need has been demonstrated.
Registration Agencies and registrants abide by rules of the system, which are intended solely to maintain a level playing field. These mandate policy rules -- for example that no consolidated data about use of a specific DOI name is made public or available to other than the registrant. They also mandate rules as to syntax and services.
For more on this topic, see the DOI Handbook chapter Policy.
23. How is DOI used in web applications?
The DOI System is as independent as possible from specific technology
implementations. For web applications, the DOI name may be expressed as a
HTTP URI. The method for doing so is simply to prepend the DOI with
http://dx.doi.org/ and (where necessary) use the hexadecimal (%) encoding required for URLs or URNs.
For further information on the use of this web resolution of DOI names, see the DOI Handbook chapter Resolution.
For information on tools to facilitate this, see DOI Tools.
For information on DOI as a URI, see Overview, the infoURI specification.
For information on DOI in relation to Internet identifier specifications, see the DOI System Factsheet
DOI System and Internet Identifier Specifications.
24. I'm not an original publisher or producer of information: can I use the DOI System?
Yes: DOI names can be used by anyone, independent of the applications that may have been originally devised by the registrant. Particular communities may develop applications which involve assigning DOI names not by the original publisher but by other parties appropriate to that sector of interest. DOI name users can be at any point in an information chain -- intermediary, retailer, user, producer, agent, etc, in the same way as the physical bar code is useful to (and used by) a range of retailers, logistics companies, re-sellers etc even though the code is originally assigned by a manufacturer.
Of course, we need to ensure that we don't get every party in the supply chain assigning their own DOI names to the same entity, which would be inefficient. This is obvious in the case of existing identifiers (for example, ISBNs are assigned to books by the publisher, using the ISBN agency, not by authors, booksellers, wholesalers or libraries). But it may not be obvious in the case of new areas where the supply chain rules have yet to evolve: here there may need to be some discussions and agreement in the community about what identifiers are allocated by who. Even in traditional supply chains, there may be other related and relevant identifiers used by people other than the DOI name assigner (like stock-keeping units (SKU) identifiers, pallet identifiers, publisher identifiers, library catalogue numbers, etc. New linkages may also arise between these, and they can be carried out through DOI names.
The DOI System can help to ensure smooth operation in these supply chains by defining business rules for a particular DOI® Application Profile. These can state who in the supply chain is responsible for assigning a DOI name in that particular application: rules agreed and defined by the user community, not by the IDF. The DOI System can also help by creating automated links: if there are related DOI names in other Application Profiles a link can be made using multiple resolution; if there are other forms of identifiers not in the form of DOI names, like SKUs, these can be carried as part of the metadata.
For more on this topic, see the DOI Handbook chapters Numbering and Resolution.
25. How does DOI System metadata relate to the Dublin Core Metadata Initiative?
Dublin Core aims to be an easy-to-create and maintain descriptive format to facilitate cross-domain resource discovery on the Web. "Qualified Dublin Core" supports the use of DC elements as the basis for extended but simple statements about resources, rather than as a foundation for more descriptive clauses. Complex descriptions may be necessary for some Web resources and for some purposes, such as administration, preservation, and reference linking. However, complex descriptions require more expressive data models that differentiate between agents, documents, contexts, events, and the like. This is achieved through the indecs model. While DC starts from a small group of "core" elements, and DOI Application Profiles include a small group of "kernel" elements, the two do not serve the same purpose. The kernel is derived from a comprehensive data model and has strict rules for mandating implementation. The Resource Metadata Declaration provides a tool set for extending metadata declarations to any desired set of entities, comparable therefore to DC-qualified but with the significant difference of a basis in an underlying comprehensive semantics to ensure consistency of all declarations for any purpose.
Any DC scheme may be used as the basis for developing a DOI Application Profile, though the DC metadata may need to be supplemented or further defined in the mapping to the indecs Data Dictionary, depending on the precision with which the DC term has been defined.
The DOI Data Model enables semantic interoperability between APs devised for any purpose (not only simple description but more complex events), so that "cross-domain" tools and applications (those which reference DOI names across more than one AP) can do so consistently and effectively. Such semantic interoperability will be required for widespread digital use of information from multiple sources.
For more on this topic, see the DOI Handbook chapter Metadata.
26. Where do you put a DOI name and what does it look like to a user?
You may put a DOI name anywhere you like. A DOI name may be printed or made explicit within a digital object; or it may be hidden by e.g. underlying a hyperlink. Therefore it can either appear as a DOI name, or the user may never know that a DOI name has been used to "power" her transaction.
For more on this topic, see the DOI Handbook chapter Numbering.
27. How do I use a DOI name in a Web Browser?
Applications using DOI names can be constructed on a web site with full functionality behind the scenes. For some applications, this may require additional functionality such as that supplied in the Handle System. DOI names are URIs (URNs) not URLs: they are names, not locations. Most web browsers support locations (URLs) but have limited functionality for names, though this is expected to improve substantially in the near future. However, DOI names are useable with browsers immediately.
Users may resolve DOI names that are structured to use a DOI System proxy server (http://dx.doi.org), which "translates" a name using URL syntax. The resolution of the DOI name in this case depends on the use of URL syntax: for example doi:10.1000/123 would be resolved from the address: "http://dx.doi.org/10.1000/123". Any standard browser encountering a DOI name in this form will be able to resolve it.
Many browsers, such as IE6, support URNs as bookmarks, so DOI names can be saved in that form.
For more on this topic, see the DOI Handbook chapter Resolution.
28. What is the relationship between DOI names and XML?
The DOI System makes use of XML (eXtensible Markup Language), and XML is entirely compatible with DOI names. The expression of metadata in XML is recommended both for kernel metadata and for DOI Application Profile metadata extended from the kernel. The indecs data dictionary and the DOI® Resource Metadata declaration both allow the use of XML expressions, commonly used for metadata transport and messaging.
It seems likely that the relationship between DOI names and XML will grow over time. One obvious link is in developing DOI Application Profiles for the various emerging XML schemas for industry-specific uses, such as NewsML: when such a scheme has been developed, DOI names provide an obvious way of adding functionality (persistent identification, interoperable metadata mappings, multiple resolution framework, etc.) to that schema for practical uses.
The linking of entities in XML is very different to the linking of entities with DOI names, as the two serve different, complementary purposes. XML entity resolution is concerned with the construction of an XML document or message; it exists to support the assembly of XML documents from components. DOI name resolution, on the other hand, deals with information about an identified entity and linkage of intellectual property entities and information about those entities. DOI names may of course be used to identify entities which are "marked up" in an XML schema; but not every tagged entity in an XML schema may merit a DOI name, unless there is a need for separate management of that entity (functional granularity).
Several languages have been constructed using XML that support functions complementary to DOI name: e.g. XLink is a language that allows XML elements to be made into links, which specify relationship types and behaviour characteristics between sets of resources; the Resource Description Framework is another language that can be expressed in XML and allows properties of an identified resource to be described. Although neither of these technologies are yet mainstream, they have similar characteristics to, and can be used with, DOI names. The IDF is actively pursuing such usages and monitors XML developments closely.
For more on this topic, see the DOI Handbook chapter Metadata.
29. How can the DOI name be used to locate my specific local copy, which may have different access rights?
The DOI System is for resolution of identifiers to global services. However it can be used with other complementary technologies, such as OpenURL, to allow the contextualization of requests to those services to local requirements.
Registration Agencies such as CrossRef offer practical implementation of the DOI System with such local linking technology. A typical example is that a library may well wish to resolve to a specific instance of a content item -- such as a cached copy which it has access rights to -- rather than a publisher-held "generic" copy. It is appropriate to split this into separate global and subsequent delegated local resolution steps, since a globally-maintained database is clearly the wrong place to hold information on every local collection.
Basic OpenURL write up can be found at http://www.crossref.org/03libraries/16openurl.html.
It is also possible to deal even with individual copies by identifying them by DOI names, though it may not always be appropriate. DOI names can be used to identify any resource: in CrossRef for example, the DOI name is allocated to the abstraction representing the article work (that is, different formats etc such as pdf versus Word are not separately identified: we can think of the DOI name as identifying the class of all formats and copies). In other applications, different DOI names might be allocated to different formats, or even to individual instances.
For more on this topic, see the DOI Handbook chapter Resolution.
30. "Persistent identification" is an accepted concept:
what does the DOI System add to this?
The need for persistent identifiers is well recognised in many areas (particularly from the library, archives, and government communities), but the next step (adopting a practical implementation such as DOI names) is not yet so readily comprehended. There is a fundamental difference between recognising the need for persistent identifiers through a technical scheme (like URN), and the practical implementation of this (which inevitably has associated costs but also associated added value: a DOI name is a URN and URI implementation). The key point is not about DOI name "versus" an alternative scheme; it is about technical versus business infrastructure, and the need for additional implementation work for the use of any persistent identifier.
The implementation of persistent identifiers adds value, but necessarily incurs some costs (in number registration, infrastructure maintenance, and governance). There is a widespread recognition of the advantages of assigning identifiers; and a widespread misconception that an abstract specification (like a URN or URI) actually delivers a working system rather than a namespace that still needs to be populated and managed. A common misperception is that one can have such a system at no cost. It is inescapable that a cost is associated with managing persistence and assigning identifiers and data to the standards needed to ensure long-term stability.
If adding a URL "costs nothing" (which itself ignores some infrastructure costs), why should assigning a name? It is indeed possible to use any string, assigned by anyone, as a name -- but to be useful and reliable any name must be supported by a social as well as technical infrastructure that defines its properties and utilities. URLs for example have a clear technical infrastructure (standards for how they are made), but a very loose social infrastructure (anyone can create them, with the result that they are unreliable alone for long term preservation use as they have no guarantee of stability let alone associated structured metadata). Product bar codes, Visa numbers, and DOI names have a tighter social (business) infrastructure, with rules and regulations, costs of maintaining and policing data -- and corresponding benefits of quality and reliability.
Like any other piece of infrastructure, an identifier system (especially one which adds much value like metadata and resolution) must be paid for eventually by someone. The DOI name is designed to work with any business model, ranging from free assignment to assignment on a commercial basis.
For more on this topic, see the DOI Handbook chapters Introduction and Policy.
31. What data is associated with a DOI name?
The simplest DOI names (such as those in the earliest implementations of the DOI System) are essentially redirection from a persistent name (the DOI name) to a changeable URL. The information associated with the DOI name in the DOI System is therefore simply the URL and relevant administrative information for managing the DOI name. These are now known as DOI names of the Zero Application Profile.
However, in more sophisticated applications, a DOI name has additional associated data which help characterise the identified entity and which can be used to build services related to the identified entity. The Application Profile (AP) is a key example of such additional data. APs are used to group sets of DOI names which have similar characteristics, such as the same metadata schemas and business rules for DOI name assignment. Thus, discovering that a given DOI name is a member of a given AP is a shortcut to knowing what metadata elements can be found for the DOI name, for knowing who is responsible for maintaining the DOI name, and for any other characteristic that is common to the set of DOI names which are of that AP.
Data which is not common to all members of an AP is associated with an individual DOI name on a one-to-one basis. All Application Profiles beyond Zero contain a minimum of some publicly declared metadata (the kernel metadata) which is sufficient to provide users and applications with a basic description of the entity identified with a DOI name.
The indecs metadata framework is the basis for normalizing across different metadata schemas used by different communities, enabling communities to build schemas which meet their needs. Application Profiles bring together a number of things, all along the lines of classing DOI names for convenience in dealing with large numbers of them while still allowing for individual differences. That includes metadata, policies, and services.
Application Profiles are articulated by defining a data type within the DOI name handle record. The resolution system is able to retrieve this data; clients (such as that implemented in the DOI System Adobe plug-in) know how to parse that data; in the case of a defined AP the client finds first the reference to the application profile data type, and then keeps looking and finds some URI referenced by the AP definition. The job of the DOI name (handle) client library is to go off and get the data, wherever it lives. Then it hands that data off to whatever asked it to do that (the client such as the DOI System Adobe plug in) in the first place.
For more on this topic, see the DOI Handbook chapter Applications.
32. What is an Application Profile and what data does it associate with a DOI name?
Every DOI name is associated with one or more Application Profiles (APs). APs, which will themselves be identified by DOI names, are abstractions used to group DOI names into sets in which all DOI names of the given set, or AP, share a metadata schema, business rules for DOI name assignment, and other common characteristics. An AP consists of at least a set of structured metadata elements, plus some rules (policy, business and procedural rules, not all necessarily automated). AP metadata, business rules, and other specifics will be determined by the community defining the AP; in practice this is likely to be, or to closely involve, the RA concerned.
APs are an aid to using DOI names, enabling all DOI names assigned to e.g. journal articles to behave in a consistent and predictable fashion, that would necessarily differ from the characteristics and behaviour of DOI names assigned to e.g. recorded music. For example, if one intended use of DOI names is to lead to metadata for the identified entity and the metadata for journal articles and recorded music, outside of a small common kernel, will be quite different. This is only one example: in fact the data structures and potential services associated with DOI names by their assignors will not only depend upon the type of entity being identified but also by the intended usage of the DOI name. An Application Profile groups together characteristics not only of the type of identified entity (roughly what has been called the "genre") but also the intended usage, or application, of the DOI name.
The core elements of an AP will be a metadata schema and various business and procedural rules. The business and procedural rules will cover such policies as "who can assign a DOI name within this AP" and "what elements of metadata are public in this AP" and so on. The metadata elements common to all members of an AP will be defined through the use of the DOI Data Dictionary, which is an implementation of the indecs data dictionary developed as part of the ISO MPEG-21 process. Entities within this data dictionary will be assigned a unique iid (indecs identifier). In the DOI System implementation of the data dictionary, each iid will also be a DOI name (DOI.iid). This standardization of elements will allow developers, using a planned registry of APs, to know which elements are shared by which APs. Beyond metadata and business rules, APs may also include standard services, e.g., any DOI name of AP X may be sent as an http query to location Y in order to request rights information. The use of DOI names to identify APs brings the standard benefits of indirection, that is, location Y in the above example can change without affecting the millions of DOI name records that might reference AP X.
The DOI name/AP relationship can be in one of three states:
APs are intended, as are the other mechanisms, to serve as infrastructure for the coherent management and use of intellectual property. While they will be defined and maintained by communities of interest, probably as represented by IDF Registration Agencies, they may also serve as convenient mechanisms for associating third party services with classes of DOI names. Registries will be established for this purpose. The specific rules and procedures for relating a given AP to third party services will be determined by the creators of that AP. To the extent that an AP is public, of course, anyone may operate a service applicable to that set of DOI names.
New APs must be approved by the IDF and centrally registered, to minimise duplication of effort and maximise interoperability. Defined APs will be made available to others who wish to construct new APs or re-use existing APs.
Registration Agencies add value at various levels by offering services to registrants. These services can include the definition of APs, and the one-off mappings needed in creating these from metadata sets already in use in the particular community concerned. There are two mandatory requirements for an RA using the DOI Data Model:
Once an AP is defined, RAs can offer services in allocating DOI names within this AP, ensuring the AP information is completed, populating the DOI System with allocated DOI names, maintaining up to date records, etc. Consultancy on implementation, design of new applications, etc are other obvious areas for business development by RAs.
For more on this topic, see the DOI Handbook chapter Applications.
33. What data is held in the resolution system and associated
with a DOI name?
The core resolution system for all DOI names is the Handle System. Each DOI name is registered as a handle in the Handle System and associated with a set of typed values. These values are returned in response to a resolution request for a given DOI name. The values can be changed while the DOI name remains constant, giving the DOI name its basic qualities of being both actionable and persistent.
DOI names, with the exception of certain special cases, are registered with a minimum of one value, of the type "URL". This can generally be thought of as 'location' but it really functions as the default value of the DOI name in the context of the web and may not actually be the location of the identified entity. For anything beyond the simplest DOI name, the declaration of an AP is an additional value within the handle record, with its own data type. The kernel metadata has as one element, "DOI ApplicationProfile," which will reference this same data.
The association of an AP with a DOI name may be sufficient, or may require additional data within the handle record. If services are associated with a given AP, for example, but the location of the service varies with DOI name, then the declaration of the AP may need to be accompanied by the location of the service specific to that DOI name. Similarly, two Registration Agencies (RAs) could share an AP but, in order to determine which RA had registered a given DOI name, the AP declaration would have to be accompanied by an indication of RA. The precise mechanisms for accomplishing these tasks will be defined by the AP. At a certain level of variability across DOI names within an AP, of course, it may be better to create an additional AP rather than stretch one to cover too many different cases. Functional requirements will determine which is the case.
Additional data, beyond APs and any DOI name-specific AP data, can be associated with a DOI name as it is found useful. While the association of services and DOI names can be done through the AP mechanism, it may be that some services are best associated with each individual DOI name and not through an already related AP. If this additional data is related using the Handle System, new data types can be created, as the Handle System typing mechanism is extensible. As with APs, data types must be approved and centrally registered, with the aim of minimising duplication and maximising interoperability.
Where data types require entities which are already defined within the DOI System Data Dictionary, the DOI.iid will be referenced. Data types will also be identified by means of DOI names.
The combination of data typing through the resolution system, and interoperable metadata accessed through an Application Profile, provides a powerful set of tools for the creation of DOI System services.
For more on this topic, see the DOI Handbook chapter Applications.
34. The DOI System stresses interoperability, resolution and metadata -- how
do they relate to each other?
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. This provides a means of integrating the features of Handle resolution with a structured data approach. DOI names need not make use of this data model, but it is envisaged that many will: any DOI name intended to allow interoperability (i.e. which has the possibility of use in services outside of the direct control of the issuing Registration Agency) is subject to DOI System Metadata policy, which is based on the registration of terms in the iDD.
DOI name resolution allows identifier interoperability - e.g. you can encapsulate an ISBN or other identifier as a DOI name and then resolve it to any current state data. An Application Profile -- a key concept of the DOI Data Model -- is the hook into metadata semantic interoperability -- i.e. you can use whatever metadata schema your community finds useful with your DOI name, but mapping through the AP provides a way of talking (semantically interoperating) with other objects that are encoded in different schema). The AP approach is built on indecs principles also adopted elsewhere such as ISO MPEG 21.
DOI names resolve to one or more typed values in the Handle System and it is these typed values that determine client behavior. The predominant client at the moment is a proxy, or gateway, at dx.doi.org that takes normal http GETs, e.g., http://dx.doi.org/10.123/456 where the DOI name is 10.123/456, resolves the DOI name in the Handle System looking for URLs and returns those URLs to the originating web browser as http re-directs. This is how most DOI names currently implement a single level of indirection. Using a dedicated client, such as a plug-in for Acrobat, opens this up considerably, letting us use different data types for different purposes.
For more on this topic, see the DOI Handbook chapter Applications.
35. What is a "DOI System Service"?
A defined result from a defined action i.e., do X and the result will be Y. DOI System services perform specific functions when presented with data from Application Profiles. Services exchange data, share tasks, and automate processes over the Internet by using the information associated with a DOI name. The term was coined in analogy to "Web services": for DOI System applications on the Web, DOI System services would be Web Services. As a new class of Internet-native applications, web services promise to increase interoperability and lower the costs of software integration and data interchange: these aims are clearly identical to those of DOI name (and its underlying tools of resolution -- Handle System -- and metadata -- indecs framework). Based on unambiguous rules, DOI System services make it possible for computer programs to communicate directly with one another and exchange data about intellectual property entities regardless of location, operating systems, or languages.
The combination of data typing through the resolution system, and interoperable metadata accessed through an Application Profile, provides a powerful set of tools for the creation of DOI System services.
For more on this topic, see the DOI Handbook chapter Applications.
36. What information about a DOI name is publicly available?
Once a DOI name is assigned, anyone may resolve that DOI name without charge. At least some information will always be available on resolution.
The information available on resolution depends on the Application Profile (AP) of the DOI name. DOI names can be associated with one of three categories of AP Public availability of information is as follows:
As the DOI System evolves, it is gradually moving from zero to full APs.
Uses of the DOI System which are restricted and not public (either permanently or temporarily) require special declarations and treatment. Private use of the DOI System may have advantages either in conferring on a private scheme the benefits of interoperability, persistence, well-formed data structures, and governance structure; and in allowing the subsequent migration of private identifiers into the public realm without having to reassign identifiers with a policy or technical change which allows them to be private (and potentially switched to public) if desired.
For more on this topic, see the DOI Handbook chapters Applications and Policy.
37. What are the benefits of the DOI System for Publishers, Intermediaries, and users?
The DOI System offers a unique set of functionality:
For users, these features provide the ability to:
For more on this topic, see the DOI Handbook chapter Introduction.
38. How do I apply to become a Registration Agency?
Any organization that can represent a defined "community of interest" for allocating DOI name prefixes to DOI System Registrants can apply to IDF to become an agency. Registrants can be any individual or organization that wishes to uniquely identify intellectual property entities using the DOI System. They may be existing businesses, or new organizations; they may be large or small.
For more on this topic, see the DOI Handbook chapter Registration Agencies.
39. How does the DOI System relate to DNS?
The most common mechanism for resolution on the Internet is the Domain Name System (DNS): http as used in URL is a use of DNS.
URLs are grouped by domain name and then by some hierarchical structure, originally based on file trees, now possibly unconnected from that but still a hierarchy. DOI names offer a more finely grained approach to naming where each name stands on its own, unconnected to any DNS or other hierarchy. This offers beneficial flexibility, especially over time, as the document origins reflected in that hierarchy lose meaning, such as a change in ownership which is reflected in DNS. In order to manage DOI names we have created tools that allow more flexible management of sets of DOI names, in a more useful way than as a fixed sub-domain: a DOI name, DOI Application Profile and services can all be thought of as layers of abstraction which allow this.
Functionality such as URL partial redirection and relative URLs (which assume as "known" or inherited a part of a URL / domain name address) make a lot of sense in the context of URLs. However since DOI names/Handles deliberately have a more finely grained approach to naming things, functionality such as partial redirection is dealt with through tools which capitalise on the finer granularity made available through DOI names.
For more on this topic, see the DOI Handbook chapter Resolution.
40. How does the DOI System relate to physical identifier systems like RFID tags?
Electronic product codes are identifiers which are articulated through Radio-Frequency Identifier tags or other means, and are assigned to physical goods; increasingly there are proposed applications which would relate such tags to digital networks for the look-up of associated data, such as the "internet of things" envisaged in the Auto-ID project. By definition, RFID tags are assigned to individual physical instances; in specifying intellectual property with a DOI name, it is essential to be able to interoperably name not only such physical manifestations but also digital manifestations and the underlying abstractions which they express.
DOI names allow an object to be uniquely, persistently identified and current state data about that object to be obtained on the internet. The DOI System's area of application is intellectual property -- in any form. We are agnostic as to other uses of the identifier -- product codes, bar codes, RFIDs, IP addresses, etc; the system is designed to offer persistence and interoperability for multiple functionality. Thus DOI names can work with physical identifier strings, either by encapsulating the identifier string in some way or in conjunction with proposed specific identifier resolution mechanisms.
To be useful, electronic product codes will increasingly also be concerned with associated metadata, in product information databases. The principles of DOI System Data Model techniques are equally relevant to considerations of such associated data. Thus DOI names offer a way of articulating specific electronic product codes in a way that is interoperable with other systems.
41. My community wants to develop an identification scheme for our material. How can we make use of the DOI System?
Joining the International DOI Foundation community allows you to instantly leverage years of intelligent policies, standards development and other value-adds, yet not limit in any way your own autonomy or ability to organise/create your own activities. Our framework is open enough to leave tremendous room for a community's own autonomy, activities, and control. Working together rather than dividing efforts is a sensible way forward. We welcome discussion with any community.
Each DOI name user organisations can do whatever it wishes. The DOI System allows for DOI names to be assigned by Registration Agencies (RAs); each RA is autonomous in its business model -- the usual analogy is that the RAs collectively set the rules of the road re resolution etc but do not specify the route to be taken, the vehicle to be driven on the road, or the date, time or purpose of the journey of each RA. There's an equal, small, fee for participation in the system to all users; we have no say whatsoever in how they generate that fee. Rather than IDF exerting control on RAs, RAs exert an influence on IDF: RAs may have seats on the Board of the IDF (whereas IDF is not on their board) and representation on the working groups of the IDF. Ultimately the RAs will wholly control IDF as a federation. This structure means that every RAs has a say in managing the common infrastructure of many applications; which is our aim. The more RAs, the more valuable such collaboration will be.
If a community develops an RA, or endorses a separate entity as an RA, it is free to set up any service and business model it wishes. It is also be able to take advantage of the existing work and common infrastructure to save time and money and ensure future interoperability. Finally, it would have far more influence than if it developed its own "island of interoperability" by developing a separate scheme which would require gateways to other systems.
For more on this topic, see the DOI Handbook chapter The International DOI Foundation.
42. Why do you claim copyright and trademark on the DOI System?
Persistence is a function of organizations not technology. Hence in building a persistent identifier system, we needed to design a model for a persistent organization. The principle concern of a persistent organization is of continuing funding; hence the model selected for a long-term position was a body that is not reliant on external sources, such as funding or membership, but a self-funding system that can be supported in perpetuity from its own resources.
The implementation of the DOI System adds value, but necessarily incurs some resource costs: in data management, infrastructure provision and governance, all of which contribute to persistence. The mechanism chosen to recoup those costs in a self-funding business model, as used by the physical bar code UCC/EAN system, and other proven systems, is a fee for allocation of an identifier but not for its use once issued.
To make such a system work effectively requires protection of the assets within the system (1) from illicit exploitation, and (2) for assured quality control. Illicit exploitation would include someone calling something a DOI name when it is not part of the official system; this could be damaging to either or both the financial health (avoiding payment of an issuing fee) or the quality of the system (poor quality data). To prevent this requires the availability of legal remedies: specifically, the DOI System relies on copyright and trademark law to protect the DOI System brand and reputation. The DOI System is not a patented system; the IDF has not developed any patent claims on the DOI System and does not rely on patent law for remedy.
The underlying technologies used by the DOI System also have similar considerations. The Handle System is used by IDF under license from the Corporation for National Research Initiatives, who have certain intellectual property claims to protect the misuse of the Handle System; indecs intellectual property (IP) is assigned to, jointly and solely, IDF and EDItEUR and made available freely but under stated terms to others (an example being the indecs RDD work contributed to MPEG 21).
For more on this topic, see the DOI Handbook chapter The International DOI Foundation.
43. Can an assigner of a DOI name specify which format is resolved to from the DOI name registry? For example, do I have a choice in whether I direct referrals to the Abstract, HTML or PDF version of an article?
The short answer is yes, an assigner determines what a DOI name is resolved to. However, this needs a little more explanation. DOI names are assigned through Registration Agencies (RAs), and the RA does so in order to provide a service or application through persistent identification (e.g., CrossRef's reference linking service). Each RA will have its rules about what is resolved to from each DOI name its clients assign, in order to furnish that service.
For uses which are truly interoperable, it is recommended that the assigner of a DOI name must specify precisely what is being identified. Precisely here means through well-formed metadata. We have a mechanism, the DOI Application Profile, to do this. Not many RAs yet make use of this.
What is being identified need not be the same as what is resolved to (for example, if I assign a DOI name to a physical book, I cannot resolve to that, but I can resolve to, e.g., an Amazon page or a MARC bibliographic record).
There can be no general rule which applies to all cases and each must be treated in context. Two digital entities are never the same in any absolute sense and can be considered copies of each other (the same) only in the context of some defined purpose. For a more detailed explanation of this fundamental topic, see the article "On Making and Identifying a Copy" by Norman Paskin, D-Lib Magazine, January 2003.
For more on this topic, see the DOI Handbook chapter Introduction, (e.g., 1.4.4 Identifying at the appropriate level).
44. Are DOI names appropriate for use with non-public material such as a report that may never be published?
Yes. The DOI System is designed principally for interoperability, which implies use by many users who aren't intimately connected (many organizations assign URLs to their internal documents for similar reasons). The key functionalities of the DOI System (persistence, interoperability, extensibility, efficiency, dynamic updating) may well be useful for internal systems. If you're going to manage information, then some level of identification and metadata is going to be necessary. Use of the DOI System can offer an off-the-shelf means of doing so by removing the need to develop a one-off solution which would not necessarily integrate with other systems, and make it very easy to make the document public later if this is appropriate.
DOI "Restricted" Application Profiles are designed for applications where even the basic kernel is of a much restricted visibility and not for use outside of that application (e.g. applications in the defense and pharmaceutical research sector for example).
Bill Rosenblatt's White Paper "Enterprise Content Integration with the Digital Object Identifier: A Business Case for Information Publishers", discusses further aspects of internal enterprise use of DOI names.
45. What's the right object identifier(s) to use internally in internal filing systems so that the migration to DOI names can be reasonably painless?
A DOI name can incorporate any existing identifier as its suffix, so you can adopt anything you like. But that's only part of the question to ask. In any consistent information management scheme, you have to also answer the question of what precisely is being identified. To do that you have to assign some metadata. If the metadata is not consistent, then you will have problems later. Use of DOI names will enforce a consistent approach to identification and metadata and is another benefit of using DOI names even for material which is not public.
46. Can I allocate 2 DOI names to the same article?
It is the intention that wherever practical only one DOI name should be assigned to a specified entity. However it is not impossible that multiple DOI names may be assigned. DOI names are assigned not by the IDF but by independent Registration Agencies operating under agreement with the IDF (see Registration Agencies). Each RA assigns DOI names for a specific application. In the case of CrossRef for example (http://www.crossref.org/) DOI names are assigned to journal articles: CrossRef rules provide that only one DOI name is assigned per article in the CrossRef system. However it is logically possible that if the same material is used in a different application by a second RA (e.g. a learning object package), and the second RA is not aware that a DOI name has already been assigned (by, in this case, CrossRef), a new one might be assigned by the second RA. Thus it is possible that two DOI names could be assigned to the same material if that material is used in two different applications and the first DOI name is not known at the time the second is assigned. Such assignments are therefore not technically impossible but are deprecated. The two DOI names could, if it becomes known that they each refer to the same item, be linked by having one resolve to the other as an alias.
Note that to make such an alias link it is imperative to ascertain that the DOI names do indeed refer to precisely the same entity. This can only be done by having the DOI name associated with appropriate declared metadata in a DOI Application Profile. Otherwise there is a risk that the two assigners intend (but have not made clear) the identifier to reference different entities: for example, the CrossRef DOI name referencing an article in abstract form, whereas a learning object application might reference a specific manifestation in one particular format. These are NOT the same entity.
47. Is there a master database of DOI System assigned content that is searchable across all registration agencies?
No. The fundamental resolution of DOI name to content is the main role of the DOI System. Any DOI name may be resolved through the system, irrespective of its origin. Individual applications, maintained by individual Registration Agencies (RAs), may provide the so-called "reverse look up" (from content to DOI name). Since DOI names may be assigned to a wide variety of content (data, text, audio, etc), it is impractical to arrange a federation of services for such reverse-look up; we would ultimately be running one of the biggest databases in the world, with a huge variety of metadata and terms. For that reason we have determined that such look-up is best provided by those RAs which are close to the community of interest, who can provide tailored, appropriate servcies.
In addition,
(a) existing search services are encouraged to work with DOI names: hence CrossRef's work with Google Scholar, Windows Live, etc (a bibliographic search on Google already gives quite a good CrossRef match); and (b) to encourage some RAs in areas where cross-searching may be needed to collaborate using our tools: a current example is the ELEONET (European Learning Object Network) project in which three RAs will collaborate.
An additional step is the implementation of the DOI Data Model, with accompanying metadata describing the entity which a DOI name references. This aids potential future interoperability; its use has been developing more slowly than originally envisaged, and we encourage more users to adopt it where possible.
Updated 18 October 2010
DOI®, DOI.ORG®, and doi>® are registered trademarks, and shortDOI™ is a trademark, of the International DOI Foundation. Other trademarks may be the property of their respective owners. |
|