ISO CD 26324 - I’ve blogged here before about the ISO standardization of DOI which is now available as a Committee Draft. Multiple resolution is specifically mentioned in Sects. 3.2 and 6.2 and discussed in Sect. 6.1. From Sect. 3 “Terms and definitions” we have this definition:
“Multiple resolution is the simultaneous return as output of several pieces of current information related to the object, in defined data structures.”
And then Section 6 “Resolution of DOI name” goes on to say this:
_“DOI resolution records may include one or more URLs, where the object may be located, and other
information provided about the entity to which a DOI name has been assigned, optionally including but not restricted to: names, identifiers, descriptions, types, classifications, locations, times, measurements, and relationships to other entities.”_
Crossref - In the help page Multiple Resolution Intro there is this:
“As of May 2008 the Crossref main system will support assigning more than one URL to a single DOI, a concept known as multiple resolution (MR). “
The intro goes on to talk about the two pilot forms of multiple resolution service that have been trialled: a) interim page, and b) menu pop-up. The pop-up service is no longer supported. Only the interim page is currently offered as a production service. The help page Interim Page multiple resolution overview leads off thus:
“Crossref’s MR service provides an interim page solution which presents a list of link choices to the end user. Each choice represents a location at which the item may be obtained and are commonly services that are co-hosting the content under agreement with the content’s Copyright holder.”
So, there it is. That’s DOI multiple resolution. The real important thing to note is that the official DOI position (IDF, ISO) is invitingly open while both the Crossref implementation and the description of multiple resolution itself is unduly restrictive. Multiple resolution as described by Crossref is essentially the deposition of additional URLs (pointing to copies of the same resource) for alternate routing (for geographical reasons, co-hosting arrangements, etc.) with a service presentation of alternate locations for user selection.
Multiple resolution proper (as per the DOI Handbook and ISO draft) is the deposition of arbitrary data values and return of same with no particular services implied. Use cases for multiple resolution include the addition of URLs for referencing different (but related) network objects, e.g. a metadata record, or other resources such as supplementary information, datasets, etc. Deposit of arbitrary data types is not yet catered for by Crossref. There could, I would suggest, at least be some rudimentary provision for depositing vanilla type/value pairs (subject to policy constraints). (There is currently some work under way in defining handle data types but this need not be any showstopper to depositing new data types as any type management system will likely need to evolve over time.)
An obvious use case for multiple resolution (to me, anyway) would be the registration of a second URL which would point not onto a copy of the resource but onto a public metadata record. (I have earlier posted here about architectures and options for exposing public data.)
With more than one data value in a resolution record, the process of resolving such a record is potentially complicated. As the ISO CD says in Sect. 62f:
“Resolution requests should be capable of returning all associated values of current information, individual values, or all values of one data type.”
The DOI Handbook itself recognizes the problems that multiple resolution may present.
“If the DOI name can point to many different possible “resolutions”, how is the choice made between different options? At its simplest, the user may be provided with a list from which to make a manual choice. However, this is not a scalable solution for an increasingly complex and automated environment. The DOI name will increasingly depend on automation of “service requests”, through which users (and, more importantly, users’ application software) can be passed seamlessly from a DOI name to the specific service that they require.”
Indeed, services like OpenHandle will make it much easier to programmatically access data stored in the handle record associated with a DOI name. (I have blogged previously about the OpenHandle project and its languages support.) Note that presentation of data values to a human user may be a non-issue for mediated services.
And talking of computer languages it may be amusing to ruminate briefly on their own built-in support for multiple return values. Perhaps unsurprisingly, of the dominant languages Java has no such support as this recent post addresses:
“Today was one of those days when I wished Java would support multiple return values… but Java allows you to return only one value either an object or a primitive type.”
By contrast, languages such as Common Lisp do have support for multiple return values. See this post for some gory details and insights. Interesting also to reflect that as in the world of computing languages where there is a decided tilt towards a mainstream family of languages based on (or derived from) C, there may be dominant protocols at large on the Internet but no single “winner takes all”.
