Requirements for DOI-Based Applications and Services

A DOI Discussion Paper: Revised January 30, 1998

John Erickson <>

This discussion paper argues that persistent, unambiguous naming must be backed by consistent and standardized responses in order to facilitate the delivery of DOI-based publishing services. I touch upon many issues (and assume several outcomes!) that are the focus of other NISO working groups; in such cases I’ve made very little attempt to deal with those issues here, but I do hope that some of the arguments presented here may influence those discussions.

1. Introduction

Organizations that service the publishing industry realize that the appearance of the DOI naming 'standard' is simply the beginning of the discussion. The relief brought on by the DOI announcement in Frankfurt was soon followed by a resounding 'und jetzt?' (and now?) To answer that question, NISO realizes that if the DOI is to become a framework for information creation, production and distribution, a litany of associated 'child' standards will likely need to be generated. To have any value, these standards discussions must be driven by an understanding of the problems that need to be solved — by the applications and services that we intend to build upon this framework that set the requirements.

By now we are all quite familiar with the story of the birth of the DOI — how the need for a persistent, unambiguous identifier for digital objects emerged from Chris Burns' study of the publishing industry's rights management concerns, in light of the emerging Internet. The resulting DOI is a 'dumb' identifier that is whatever one makes it, which is recognized to be both a blessing and a curse. While it is true that the DOI implemented as a redirected link may be crafted to do just about anything we ask, solutions that will be acceptable to the publishing industry — especially those involving any sort of end user participation — require consistent, dependable responses.

2. Objects Beget Services

Every digital object must be viewed as having the potential to offer a world of services to its community of users, whatever segment those users may come from. In addition to the obvious and intended end use (such as reading or viewing), every object may serve as a portal to a variety of available secondary services, including bibliographic information, production credits, content management services, rights management and license administration. Every object is also typically a container for a hierarchy of constituent objects, each of which may also expose its own selection of services to the user.

The actual instance of the object has little to do with the delivery of most of these services. To find the object, only the object's unique identifier is absolutely essential. To be truly useful, the identifier must be backed up with a set of services that are based on appropriate business logic and a rich metadata store housing the data required to implement these services. The instance of the object, the service logic and the metadata warehouse need not reside at the same host, since they are uniquely and persistently linked by the identifier.
3. Sensible Access to Services

In today’s Web-based environment, access to services is largely about supplying a ‘noun’ or ‘operand,’ disguised as a URL, to the browser, which retrieves what you have explicitly asked for. If you have the URL for a photograph and you want that photograph, this is great. But given the URL for a photograph, how would you use that to obtain rich information about that photograph? How would you license various use rights to that photograph? How would you determine if your university has a license in place covering limited site usage of that photograph? Or that technical article I downloaded last week — how can I obtain permission to use particular components (e.g. ‘Figure 5’ or ‘Table 3.1’) for a university class?

Today there is no useful identifier that allows the user to reliably access content-related services directly from the identifier itself. Certainly not the URL. Not the URN. And not the DOI. But the DOI has the opportunity to be the basis for such identifier-driven service access. Given a scalable, extensible schema for registering, identifying and accessing services that may be associated with an object — a schema that allows an entire open service universe to be constructed around an object — the DOI quickly becomes quite powerful.

4. Introducing the DOI Method

One way to accommodate both extensibility and scalability is to allow arbitrary methods (variously called options or arguments in previous discussions) to be registered in the DOI directory. In this model, every DOI would have zero or more arbitrary methods related to it; associated with each method would be the resolved network address of the service, or perhaps another DOI. The DOI directory works as before, with no operation other than lookup and redirection actually happening there. Services based on the use of DOI methods could be completely orthogonal and separately administered, enabling one service provider to supply bibliographic information services for the object while another could supply rights management services.

In this model the DOI Directory would respond to all method-appended DOI requests in a uniform way, redirecting the client to the appropriate target of record for that method. Publishers or their agents who wanted to provide enhanced services for their content would ensure that service-appropriate methods were implemented — for example, registering their content with a rights management service and ensuring that the document-specific entry point to the service was registered in the DOI directory.

In order to facilitate the use and proliferation of this system of methods, one can imagine a reserved method that would provide a list of registered methods to the user. Thus by appending the DOI with a well-known method (examples include ‘list,’ ‘index,’ ‘menu’ or ‘services’), the user would be able to identify available services.

5. Standard and Expected Methods

If service providers can be completely arbitrary in their method naming, then it would seem that we are merely adding to the confusion. NISO can ease this immensely by suggesting a range of "standard" methods that anticipate categories of services. Examples could include ‘rights,’ ‘biblio,’ ‘toc,’ ‘abstract,’ ‘credits,’ ‘manifest,’ etc. The quality of service delivered in response to a particular method query would of course vary according to vendor, but the scope would be uniform — rights responses must pertain to rights administration, for example. It is even possible to imagine a small number of ‘required’ methods, pertaining to identification information, for example.

An open set of methods associated with each DOI would facilitate a scalable services market. In the rights space, one publisher would be free to implement a rights response as a simple copyright statement, perhaps with contact information, while another might choose to link their rights method to a third-party rights management service. In either case, the query made to the DOI system is ‘rights,’ and the expected response begins a rights dialog between the user and the publisher or designated administrator.

6. Are DOI Methods really Handle System Modifiers?

It is well known that the DOI System is an implementation of CNRI’s Handle System [see Sam Sun, Handle System: A Persistent Global Naming Service Overview and Syntax, Internet Draft, 17 November 1997]. It is natural then to look to the Handle System for a solution. The Handle System does provide a promising means for specifying operations on the underlying object, as indicated in this excerpt from the Internet Draft:

    "It will be useful in some contexts (for example, when used in URL) to specify operations, or service requests, on the objects named by handles, e.g., designating a fragment. There will be various approaches to this, depending on context, but one that is compatible with many current Internet applications and which influences syntax is to associate a modifier string directly with a handle string. For this we specify placing the modifier before the handle and using the "@" character as delimiter…"
Following this syntax, a suspiciously DOI-like handle with a modifier might look like:
Are the Handle System’s modifiers the solution to DOI methods? Apparently not! The Internet Draft goes on to specifically state that modifiers are not part of the handle resolution process — that the implementation and interpretation of modifiers are left to client software. While it is not impossible to provide services from the object’s handle given this limitation, it would seem to exclude layers of independent networked services such as those I have described. Indeed, this would seem to restrict services to smart clients, fed by metadata encapsulated purely within the object. This is clearly not as flexible as a network of distributed services, fed by distributed metadata warehouses, linked by the DOI of the base object.
7. Are DOI Methods really MetaObjects?

Anyone who has followed the course of NISO DOI discussions might recognize DOI method-based responses as a form of metadata object, or metaobject. Briefly, Mark Bide and Norman Paskin have introduced the metaobject as a (possibly) DOI-identified object whose content reflects the metadata of a DOI-named object [see ‘Some thoughts on scope and syntax,’ posted by Norman Paskin to the niso-doi listserv on 1/19/98]. Indeed, we can think of a method-appended DOI as merely a service-specific metaobject. Why bother with this system of methods at all? Why not just create a DOI for each service, or simply use conventional location mechanisms to access the services?

The answer is, neither solution leads to consistency from the user’s perspective. If a metaobject is derived from a DOI-named object, then the service identifiers should logically extend from that base identifier. The use of DOI methods should not preclude the use of unique DOIs for the actual delivery of services, although the use of unique DOIs for metaobjects is a matter of debate. Secondly, conventional location mechanisms such as URLs will likely be the way that services are accessed; DOI methods provide a consistent and centralized means of tying those conventional access mechanisms to the base DOI itself.

8. The Role of a Standard Metadata Framework

This paper has focused on extending the DOI syntax to achieve consistent access to services. My explicit assumptions through have been that (a) certain classes of services will emerge as producers respond to their users’ demand for more value from the objects they obtain, and (b) there will be rich metadata sets available upon which to base these services. For these assumptions to prevail on an industry-wide basis, content producers and administrators must have a framework available that facilitates metadata collection at various stages of the production process, as well as post-production maintenance. This framework would establish essential (or "standard") metadata elements upon which services are based, with each class of service having its own requisite set of elements. To allow for differentiation in quality of service between providers, the framework must also allow for the introduction of unique or value-added metadata.

A point of useful discussion in the future should concern what metadata is proprietary, what should be left 'open' for universal exchange, and how do we implement protocols for metadata exchange. This latter discussion has in fact begun, as the W3C takes up work on a resource description framework (RDF) based on XML [see the W3C's Resource Description Framework (RDF) Model & Syntax,]

This metadata framework must also introduce a standard format or protocol for requesting and exchanging metadata elements. This is quite different than the service responses described above; the exchange format is actually a specific subset of the stored metadata, encoded in an intermediate format for appropriate processing. Ideally, this format should express metadata and relationships by way of a combinatorial language that would enable services to receive and process orderly packets of metadata. To allow for differentiation and extension, this format should allow for self-describing elements; implemented services would then deal with elements to the extent that they have the logic to process them. In this world, classes of services would be defined by the minimum subset of pertinent elements that they can process.

Such a DOI metadata exchange format might look like Mark Stefik's Digital Property Rights Language (DPRL) [see the Scientific American SPECIAL REPORT: Trusted Systems (March 1997)], but it has yet to be determined if DPRL is extensible enough for the broad range of metadata exchange we need for the services proposed earlier. Perhaps a more general alternative, the XML language provides some exciting possibilities in this area — its extensibility allows for the expression of arbitrary metadata sets. This is essential for a broader application of metadata exchange, a two-way flow that includes both the down-stream sourcing of data (our usual focus), coupled with the up-stream specification of intended and requested use, context, etc. that is used for decision making on the server side of the transaction.

More recently, a W3C 'Note' was published introducing XML-Data, 'an XML vocabulary for schemas, that is, for defining and documenting object classes.' [see XML-Data, W3C Note 05 Jan 1998,] XML-Data is an XML document type (an XML DTD) that can be used for classes which are syntactic (like XML) or which indicate concepts and relations among concepts (like relational databases and RDF).

In expressing metadata, our goal is to represent the conceptual relationship between data elements. According to the W3C Note, XML-Data schemas have been designed to describe these conceptual relationships. And given that our metadata will be generally be housed in relational databases as we implement services, it is gratifying to hear that XML-Data schemas can describe the row types and key relationships within such databases.

9. Summary

Under the guise of considering DOI-based services and applications, this paper has introduced a pandora’s box of issues concerning DOI syntax and scope, as well as DOI-driven metadata element standards and exchange formats. These are problems that will be solved as independent providers work to develop services based on the DOI. My hope is that the NISO DOI group can take the lead in establishing the frameworks for development in these areas, allowing publishers access to a rich set of services that will maximize their DOI investment.