multiple resolution

Recipes for structuring a DOI

Currently one URL can be associated with one DOI. The concept of multiple resolution has been discussed for time by the International DOI Foundation (see "From one to many" doi:10.1000/190). CrossRef has added preliminary support for multiple resolution in its new XML Schema (v2.0.4). This page demos some simple use cases for structuring a DOI for multiple resolution. Consistently structured DOIs are a prerequisite for the development of DOI Services (multiple resolution is really away to enable DOI Services). These examples conform to the new CrossRef XML Schema (v2.0.4) and show how multiple resolution information can be deposited with CrossRef. Additions, comments and feedback welcome at Recipes.

Use Case

Example

Links

Alternate Locations Co-Hosting Article
Mirror Sites (DLib) Article
Alternate Manifestations Formats (HTML/PDF,...) Article (with format links)
Article (with format info)
Significant "Others" Article/Erratum Article and its Erratum
Article/Suppl. Material
Article/Journal
Article Version Chain
Multi-Homing
Article and its Suppl. Material
Article and its Journal
Article, Next Version and Latest Version
??

Technical Notes: For legibility, only the XML for the <doi_data> element is listed - the enveloping XML with the associated metadata is understood to be present. Likewise, the optional <timestamp> under the <doi_data> element is omitted. The samples should be renderable directly by IE5 or greater - otherwise you may need to save them to disk.

In the samples above, rather than following the CrossRef XML Schema provision, in which descriptive properties can be attached directly to the toplevel <collection> element, we choose to follow a convention in which properties attached to an empty <resource> element are attributable to the complete resource description. This keeps the resource description self-contained. (Note: The <collection> descriptions presented here are deliberately verbose for demo purposes and may be omitted in deployed instances.)

Also, for ease of access, resources of URI scheme "data:" are represented here in unencoded format (ie not Base64 encoded). Resources of URI scheme "data:" are essentially inline resources and do not need to be network dereferenceable (ie they are "by value" rather than "by reference").

copyright 2002, pila, inc. all rights reserved