 |
Previous Chapter: 2 Numbering Next Chapter: 4 DOI® Data Model
3 Resolution
This chapter explains the first main technical component of the DOI® System, resolution,
and its ability to provide persistent association of the identifier and related data. Readers
are advised to consult the Glossary of Terms at the start of the Handbook in conjunction with
this chapter. The chapter describes in outline the Handle System® used for DOI name resolution,
and also discusses related technologies.
© International DOI Foundation 2006
3.1 What is resolution?
3.2 Simple resolution
3.3 Multiple resolution
3.4 Handle System® technology
3.4.1 Overview
3.4.2 Technical support of DOI® name resolution
3.4.3 Software support for use of DOI names
3.4.4 Handle System RFCs
3.5 The DOI® System and other actionable systems
3.5.1 Relationship between the DOI System and the Handle System
3.5.2 Relationship between the DOI System and other "actionable identifier" systems
3.6 The resolution interface with Handle System technology
3.6.1 Native resolver
3.6.2 Proxy server
3.6.3 Other mechanisms
3.7 The maintenance of DOI name "state data"
3.8 The development of services
3.9 The DOI System and OpenURL
3.10 The DOI System and Persistent URLs (PURLs)
3.11 The DOI System and the Domain Name System (DNS)
3.1 What is resolution?
A DOI® name is an identifier for an entity in a network environment. Entities identified by a DOI name may be of any form, including abstractions (e.g. as identified by ISTC). Resolution is the process of submitting an identifier [of an entity] to a network service and receiving in return one or more pieces of current information related to the identified entity. In the case of the Domain Name System (DNS), as an example, the resolution is from domain name, e.g., www.doi.org, to a single IP address, e.g., 132.151.1.146, which is then used to communicate with that Internet host. In the case of the DOI® System, using the Handle System® as a reference implementation, the resolution is from a DOI name, e.g., 10.1000/140, to one or more [hence "multiple"] pieces of typed data: e.g. URLs representing instances of (manifestations of) the object, or services such as email, or one or more items of metadata. Resolution can be considered as a mechanism for maintaining a relationship between two data entities; an item of metadata is a relationship that someone claims exists between two entities: therefore, such metadata relationships between entities may be articulated and automated by resolution.
Using multiple resolution, a DOI name can be resolved to an arbitrary number of different associated values: multiple URLs, other DOI names, or other data types representing items of metadata. Resolution requests may return all associated values of current information, or all values of one data type; these returned values might then be further processed in a specific "client" software application. At its simplest, the user may be provided with a list of options; more sophisticated automated processes would allow for the automated choice of an appropriate value for further processing.
3.2 Simple resolution
The lack of persistence in identification of entities on the Internet is a commonplace. Even the most inexperienced of users of the World Wide Web rapidly becomes familiar with the "Error 404" message that means that a specified Web address cannot be found -- the URL for that web page cannot be resolved.
A DOI name persistently identifies a specific intellectual property entity, which may or may not be an Internet-accessible file. The URL identifies a specific address on the Internet. These applications of identification are completely different. One identifies an entity; the other identifies a location (where a specific entity may or may not be found). The analogy is with the ISBN (which identifies the book) and the shelf-mark (which identifies the place where the book is to be found). When the location changes, the shelf mark changes -- but the ISBN does not.
The earliest application of the DOI System was for simple, single point resolution. Each DOI name had a single URL to which is could resolve. This allows the location of an entity to be changed while maintaining the name of the entity as an actionable identifier.
The DOI System is not alone in providing a solution to this problem. Certainly, other applications, for example PURLs (or Persistent URLs), can provide this simple level of resolution. It has been argued that URLs can (in theory) themselves be used as a persistent identifier -- that their use as a transient identifier is a social, not a technological, problem.
However, this lack of persistence of the URL is only the first -- and the simplest -- challenge that the DOI System was designed to manage.
3.3 Multiple resolution
Multiple resolution allows one entity to be resolved to multiple other entities; it can be used to embody e.g a parent-children relationship, or any other relationship. This is a feature of the Handle System technology, but the Handle System per se (deliberately) has no pre-existing constraints to make a useful framework (think of it as like spreadsheet software): the DOI System is an application of the Handle System which adds this constraint (think of it as like a spreadsheet application already written for you to add data to). In the DOI System the constraints come from the metadata which defines the entities, which is the data dictionary approach: hence our role in MPEG-21 RDD and the indecs Data Dictionary. That enables one to express relationships.
The solution to these challenges lies in automated "multiple resolution". A DOI name can be resolved to an arbitrary number of different points on the Internet: multiple URLs, other DOI names, and other data types. 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.
The multiple resolution capability of the DOI System, using Handle System technology, provides a platform on which applications of great complexity and sophistication can be built.
3.4 Handle System® technology
Handle System technology, developed by Corporation for National Research Initiatives, was selected for the resolution task within the DOI System because it offered a number of real advantages over other available technologies:
- Multiple resolution capability
- Scalability
- Reliability
- Resolution speed
- Proven usage in several digital library projects
- Already implemented and supported in several practical systems
- A commitment by its developers to open standards, and
- A commitment to further development
The DOI System is one implementation of the Handle System; DOI names are a subtype of "handle", but not the only one. DOI names are distinguished from other handles by the totality of the DOI System described in this Handbook.
The Handle System is made up of local handle services. A local handle service (LHS) is made up of one or more sites, and a site is made up of one or more handle servers. Handle servers store handles. One local handle service is unique, the Global Handle Registry®: the handles it stores, which are the "prefix" handles, makes it the LHS to query to find out which services store all the other handles.
For further information on the Handle System, we also recommend consulting the General and Technical FAQs about the Handle System and the HANDLE.NET Software.
3.4.2 Technical support of DOI® name resolution
CNRI continue to provide technical and operational support for the DOI System as a contractor. The following is a summary of the relevant technical and operational support which IDF guarantees through such contracts, and in turn is able to offer as a basis for Registration Agency operations. Further details of the relevant Agreement for Technical Services are available to potential and current Registration Agencies.
1. Technical and Operational Oversight
- Monitor and advise on core DOI System technical infrastructure configuration and performance.
- Monitor research and commercial computing and networking developments that could enhance or limit the use of the DOI System.
- Recommend, help initiate, and guide new prototypes to evolve the utility and expansion of DOI System usage, excluding production-level support when prototypes transition into operational mode.
- Represent the DOI System in technical meetings and fora.
- Manage and/or make significant contributions to technical working groups in the formation of IDF technical policy and the creation of IDF technical resources, such as specifications, code or demonstrations, as required.
- Contribute to DOI System technical documentation and provide editorial support as required, including technical and general editing of articles, handbooks and the preparation of briefing materials.
2. Management of DOI® Directory Infrastructure
- Provision of 24x7 commercial hosting and secure facilities, back-up and disaster recovery, etc.
- Operational Management of the DOI System Service (DOI System Primary server (DOI System Local Handle Service); Mirror (secondary) of the DOI System Primary server; multiple proxy servers (dx.doi.org); related management tools).
- DOI® Directory Custom Services.
3. IDF Central Registration Agency (Directory Manager)
- Prefix administration/creation and DOI name registration to requesters who are associated directly with the IDF and not with an IDF RA.
- Create and allocate Prefixes to IDF RAs. This includes discussing and implementing the process by which their requests will be submitted and how the Prefixes and related information will be provided to the IDF RAs.
- Configure the Prefixes so the Handle System knows which service is responsible for the DOI names under the Prefix ( "homing").
- Technical guidance and general assistance for Prefix owners, including guidance on use of administrative forms and batch loading, as well as status reports on their DOI name deposits.
- Administration tools to manage Prefix inventory.
- Statistical analysis reporting.
- Technical Consultation.
4. Analysis and Communications Services
- DOI.ORG® web site and mailing list infrastructures.
3.4.3 Software support for use of DOI names
There are a few servlets and tools that some users and programmers may find useful. (Contact the Handle System Administrator at hdladmin@cnri.reston.va.us for information) These include:
net.handle.batch.DOIBatch
A batch loader for DOI names.
net.handle.apps.admin_servlets
The servlets used for administering handles via the web, useful if you'd like to allow DOI name administration from a local web server.
net.handle.apps.simple
If you do decide to roll your own handle software, this package has a number of examples of how to use the handle client library.
net.handle.apps.tools, net.handle.apps.site_tool
A number of utilities for low-level maintenance of a handle server. Make sure to check there before writing anything along these lines yourself.
Application Programming Interfaces (APIs)
In addition to Java, libraries are available for Python, Perl, and C. DOI System specific libraries are being developed for the Acrobat/DOI System services prototype.
Please pass on any unfulfilled needs you have for supporting software. We are always looking ways to make handles and DOI names easier to use.
Here is a link to the current Handle System RFCs:
http://www.handle.net/rfcs.html
3.5 The DOI® System and other actionable systems
3.5.1 Relationship between the DOI System and the Handle System
The DOI System is an implementation (application) of the Handle System, which adds other features and functions, notably metadata, policy, and business rules.
The Handle System is a protocol specification (plus a reference implementation), not fundamentally a commercial application -- anymore than DNS or any other low level network infrastructure is, and it is useful to think of it as analogous. As a result the Handle System does not offer commercial-level technical support from its originators CNRI, or anyone else, other than specific contractual arrangements with CNRI or other entities that may build on the base of this published standard protocol (the IDF has such arrangements which also cover its registration agencies). Applications may be built on top of the Handle System, but it does not provide sophisticated applications "out of the box", by design. Commercial licensing of the protocol may result in some possible offerings of this form (akin to DNS in routers, etc.).
The DOI System is an application of the Handle System to intellectual property. (The DOI® Handbook is a starting point for information.) 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. It is being developed by the International DOI Foundation. Initial implementations are now being supplemented by increasingly sophisticated value-added tools for metadata management and content management through the Handle System multiple resolution function.
The DOI System is also not fundamentally a commercial software offering, but is intended to be a community effort to provide enabling technology which others may build on. However we are building a self-funding system, based on a network of registration agencies who offer operational DOI name registration services and applications in exchange for a fee paid to support the development of the Foundation. As a result of this there is a fee obligation for participation as a DOI name registrant; in return the IDF provides tools (e.g., The DOI® Handbook) to support system use, which offer added value. Additional information such as metadata guidelines (application profiles) is offered, and administrative tools for registrants are being further developed. A major advantage of the DOI System is that our structured data model ensures ready interoperability between applications, which is of increasing importance. For this reason we are already in early discussions with some other Handle System applications about how we can encourage convergence of our approaches using the Handle System.
3.5.2 Relationship between the DOI System and other "actionable identifier" systems
The relationship between the DOI System and non-actionable identifier systems such as standard numbering systems, and the relationship with standard protocols such as URI and URN are discussed in Chapter 2 Numbering. This section is concerned with other actionable systems, i.e. systems which set out to deliver some or all of the functionality intended by the DOI System. Some of these may make use of the Handle System.
In considering how the DOI System relates to any other naming/resolution/metadata system, we might consider a decomposition of the DOI System into its four principle components:
- identifier (enumeration, and syntax)
- resolution of the identifier (using the Handle System)
- data model associated with the identified entity (based on indecs analysis)
- policy (implementation and deployment of the complete DOI System)
It is then useful to consider which of these components are common and which are different in the case of the DOI System and XID (a notional other system, "X identifiers"). The more components are shared, the more easily interoperability can be achieved:
- No common elements (competing, alternative, or complementary systems). Note that minimal interoperability can of course be conferred by including XID as the DOI® Kernel element "OtherIdentifier".
- Common use of identifiers and resolution system.
- Common use of metadata, in addition to identifiers and resolution system.
- Common policy, in addition to data model, identifiers and resolution system.
We assume an interest in using common components. Most commonly, the following considerations arise; these are orthogonal, i.e. one is not dependent on another and any combination is possible:
- DOI® Application Profiles
DOI names, whatever their naming authority, could use a specific DOI-AP used by XID; that is, XID could define and make use of a DOI-AP.
- Prefixes
Each registered handle type in the Handle System is itself represented by a handle of the form 0.TYPE/XYZ, where 0 is a prefix (also referred to as a naming authority) reserved for identifying system components, 0.TYPE is the prefix for handle types, and XYZ is the character string of the type itself. The type "NA" is reserved for "Naming Authority": hence the Global Handle Registry® contains handles of the form 0.NA/10.1080 which resolve to "where do I find 10.1080"? Local Handle Services then consist of handles in the form 10.1080/456 which resolve to information about that specific handle.
It is logically possible to envisage that e.g. "XIDs are DOI names in the form of a separate prefix". Note that there is no difference between X being allocated prefixes 10.XXXX, 10.100.XXXX or 20.XXXX; all HDL naming authorities are "peers". 10.100 is not a hierarchy below 10, all NAs are opaque. A handle client would just know which LHS 10.100 belonged in. However they look different (20.XXX looks very different from 10.4567) -- which could offer an opportunity of "branding" with true interoperability within the same LHS. The prefix issue is largely a business policy decision.
- Local Handle Service (LHS) usage
The question of where the NA information lives. The mapping of NA to LHS is most efficient if done one-to-one (1 LHS to many NAs is allowable; 1 NA to many LHS is not recommended). Hence it is possible that XIDs could live in a different LHS. This seems to be largely a function of network topology issues, not business: the principle to be followed is "do not unnecessarily proliferate local services". The Handle System provides interoperability across all handles, at least for anything that involves resolution and administration: the consequences are performance, especially for administration, which is different than interoperability. So we would probably not want a LHS at every RA in the USA, but e.g. one in Asia might be justified (and might be used by any Asian DOI name users). Whereas DOI-AP and NA issues are a matter for IDF and X, the LHS issue should involve the Handle System Advisory Committee too (as it involves other, non-DOI System, applications issues).
3.6 The resolution interface with Handle System technology
Current Web browser technology requires additional functionality to allow the browser to deal with names of objects, rather than simple locations (a fact common to any approach to naming on the Web). Hence, in order to make full use of DOI name resolution functionality, additional browser features are necessary. It is anticipated that features supporting resolution will commonly be built into browsers in future, and the IDF is in active discussion to encourage this. The required functionality is currently provided in a number of ways.
A "resolver plug-in" was developed by CNRI to enable a browser to resolve a DOI name in the form "doi:10.123/456" without using a proxy server. The user simply downloaded and installed the plug-in and then "clicked" on the DOI name (or typed the DOI name into the address line in their browser) and the DOI name was resolved directly. The resolver plug-in is currently being re-engineered and will be made freely available once again when the new version is complete. Software developers are encouraged to use the Handle System client library to develop their own custom client resolution software.
Alternatively, without the need to extend their web browsers' capability, users may resolve DOI names that are structured to use the DOI System proxy server (http://dx.doi.org). The resolution of the DOI name in this case depends on the use of URL syntax: the example DOI name we have been using (doi:10.10.123/456) would be resolved from the address: "http://dx.doi.org/10.123/456". Any standard browser encountering a DOI name in this form will be able to resolve it.
The use of the proxy server and an unextended browser provides the more common user interface to the DOI System today. However, it has significant disadvantages when compared with native handle resolution. The disadvantages include both performance and functionality. Inevitably, direct resolution will often be quicker than resolution using a proxy server. Furthermore, the development of additional services which depend on utilizing the full multiple resolution potential of the DOI System (and the Handle System technology) will necessitate the user being able to manage DOI name resolution directly.
The use of the proxy server (the gateway between the Handle System and HTTP) does not interfere with the HTTP referrer field (that is, the source of the link is maintained, it does not appear as though the user is coming from dx.doi.org instead of from the source). Nothing goes "through" that proxy server: it sends a redirect back to the original client with the current URL or other information relating to the handle resolution, and the final HTTP GET request comes from the user's client just as it otherwise would.
DOI names used through a HTTP proxy server (in the "http://dx.doi.org" formulation as a URL) will continue to be persistent. As long as (1) the core DOI System is maintained, that is, as long as a given DOI name (10.123/456) can be resolved using the Handle System, and (2) as long as the proxy server named dx.doi.org is kept running, and (3) as long as the core network services that enable the http-based web to function remain in place, then a DOI name (http://dx.doi.org/10.123/456) referenced through that proxy will remain persistent. The key to understanding why this is so is modularity. The core DOI name resolution service is used by the proxy but is not constrained by the proxy. Additional gateways could be built and additional methods could be used to access the core DOI name resolution system without interfering in any way with the ongoing operation of the dx.doi.org proxy.
Having created and advocated the use of the proxy, CNRI and IDF are committed to maintaining it in perpetuity, as it will be an essential component to maintaining the integrity of the millions of instances of DOI name-based web links. Maintaining the utility of those links over time will require maintaining both the core DOI System and the specific gateway service, dx.doi.org, that those links reference and so use to gain access to the core DOI System. This, of course, is not at all unique and is just another variation on the Internet theme of layering services on top of one another. dx.doi.org is itself dependent on the Domain Name System (DNS), which is itself dependent on IP addressing and routing, etc. This picture will probably grow more complex as time goes on (we hope it does), with the core DOI name resolution facilities used in multiple ways and by multiple services. OpenURL resolvers, for example, will find DOI names in their "raw" form, e.g., id=doi:10.123/456, and so could choose among using the dx.doi.org proxy, or setting up their own web-to-DOI name proxy server(s), or using the handle protocol to query the DOI System directly.
It is also possible to conceive of the required functionality being delivered to a browser by means of a scripting feature, such as JavaScript. However, to date we have not encouraged this as a key component of any long range DOI System/Handle System strategy. Reliance on scripting is unlikely to be assured of support by browsers in the medium to long term; for example, many security specialists are currently urging computer users to turn off JavaScript in their e-mail system preferences.
3.7 The maintenance of DOI name "state data"
The effective operation of the DOI System depends on accurate resolution of a DOI name to the appropriate URL or other data type.
The maintenance of the "state data" is an essential element of the responsibility of the Registrant of the DOI name. Currently, only the Registrant or a service organization acting with the authority of the Registrant is permitted to maintain state data. More sophisticated models of permissions and access to DOI name state data records within a DOI name record are conceivable and the requirements for these are currently being investigated by the IDF.
The data types to which a DOI name can resolve are fully extensible within the Handle System, to permit the DOI name to resolve to any data that is accessible on the Internet.
For use with the data type URL (currently the most common application) we recommend that DOI name data be entered as a full path (e.g. http://www.somepublisher.com/photo/photo#1.gif), rather than a relative reference. Whilst a relative link could be used as the DOI name data, we cannot predict the context in which the DOI name will be resolved, i.e. what the current base html reference will be.
A DOI name could resolve to a Java applet or a CGI script or other dynamic mechanism.
3.8 The development of services
The development of services that make use of the potential of the DOI System and multiple resolution will be the responsibility of commercial organizations that can identify appropriate business opportunities. We would anticipate that this development is likely to involve both suppliers of technology (including Registration Agencies -- see Chapter 8 Registration Agencies) and groupings of registrant organizations that recognize a common need.
The IDF is keen to encourage the early implementation of many services that fully utilize the DOI System and Handle System technology; it sees itself primarily as a catalyst, bringing together organizations that may have a common interest and actively championing and facilitating the development of useful applications.
3.9 The DOI System and OpenURL
"When you don't have decent metadata, it's hard to provide decent services. That's why I am an enormous fan of unique identifiers for objects, and systems that allow you to obtain well-structured metadata by using those identifiers. For me the big deal of the DOI/CrossRef framework is not necessarily the links they provide, because that might be done in other ways. The crucial importance of that work is in the mere fact that objects are being identified, and that identifiers can lead to metadata about objects. That changes the whole game."
Herbert Van de Sompel, Creator of OpenURL/SFX, in an interview with Dennis Brunning, The Charleston Advisor, Volume 4, Number 4, April 2003.
OpenURL is a NISO standard syntax for transporting information (metadata and identifiers) about one or multiple resources within URLs. OpenURL provides a syntax for encoding metadata (but not a source of it), restricted to the world of URLs (unlike the DOI System's wider application). This interface can be used to tie together otherwise disparate services such as centralized resolution systems and local knowledge of available resources.
The DOI System is a system for resolution of identifiers to global services. OpenURL is syntax allowing the contextualization of requests to those services to local requirements. OpenURL can be used together with DOI names to provide a richer user experience that incorporates both the global and the local requirements of the user. A key issue in the OpenURL world is the transformation of a generic link, say to a publisher's online copy of a journal, into an OpenURL pointing to the right server for the given user, which must also carry the id and metadata needed to create the contextually appropriate extended service links as described above. In the current deployment this is only being done by the resource pointed at by the URL that the user initially encounters. So in the example of a link to the publishers copy of a journal, the publisher must 1) agree to redirect that http request to the user's local OpenURL-aware server, when appropriate, 2) must add information to the link as needed for the local server to do its job, and 3) must know the location of the local server.
The logically centralized resolution service maintained by the content producers for DOI names has no way to resolve a DOI name to a locally held copy of the identified entity. So the synergy between the DOI System and OpenURL is clear: OpenURL needs a source of identifiers and authoritative metadata; the DOI System provides a single point in the network for the creation and subsequent redirection of OpenURLs, which is more manageable than asking every content provider to enable this facility. Solving the appropriate copy problem is a significant accomplishment in and of itself, but there are many opportunities for productive collaboration beyond that.
OpenURL is both a syntax and a system. The OpenURL system is not defined -- anything that uses the OpenURL transferred data could be said to provide an OpenURL System. In practice the OpenURL transferred data is being used with information about the context of a user interested in a particular resource. This user-contextual information is not part of the OpenURL syntax but is instead supplied through other information supplied when the URL is activated (such as HTTP header information, a digital certificate, cookies or some other identification process).
An OpenURL consists of a base URL followed by a query for one or more objects. So: http://resolver.local.org/getlocal?author=Shelley sends an OpenURL compliant request to a receiving service provided by getlocal at the location specified with a query with the parameter author and the value Shelley. What is not seen in the syntax is that the service will also receive any information about the user that may be sent along by default with the request as part of any authentication that has taken place between the users client and the server. The local service can then decide, based on the metadata sent and what the server knows of the user's credentials, how to respond to the request.
DOI names can be used within the OpenURL syntax to query local services about availability of resources at a local level, e.g. the following could be used to see if a local copy of a resource were available: http://resolver.local.org/resolutionservice?id=doi:10.1045/1. The local service could have a list of DOI names that it has a local service for and offer that alongside the global information services obtained by resolving the DOI name through the Global Handle Registry. OpenURL also allows more complex constructs that those illustrated above.
In order to allow for the delivery of context-sensitive services information, recipients of an OpenURL must implement a technique to determine the difference between a user who has access to a service component that can deliver context-sensitive services and a user that does not. The mechanism used to determine a user's membership of a particular group could be cookies, digital certificates, part of a user's stored profile in an information service, an IP address range, or something else. This user recognition is not a part of the OpenURL syntax and is separate to OpenURL. Several library service vendors provide such functionality. If the user is a bona fide member of a group, the local resolution service will be available to that user.
Once an OpenURL is embedded in a resource it is fixed, and the service provider that it relies upon is explicitly specified by way of the pre-parameter part of the URL (hence an OpenURL has all the properties of any other URL). This provides an alternative resolution to the DOI names (provided by OpenURL-compliant service components) that can operate in a context-sensitive manner. The persistence of OpenURL is dependent on the availability of the service that is encoded in the OpenURL. The OpenURL once distributed cannot be modified except at each localised service. Where a DOI name is used as the embedded metadata, it is possible that a user may be rejected from accessing local resources: in which case deference to a global resolution system should be supported. The OpenURL intentionally embeds intelligence in a string that is supplied to a particular service -- as a means to explicitly describe resources to attempt to provide a particular service based on that description.
The comparison of OpenURL enabled systems with the DOI System is straightforward: the DOI System is a global system; all information about a resource is the same in the global system wherever the DOI name is resolved from; the data that is associated with a DOI name can be modified, and extended, and is not locked into embedded implementations. Even if an OpenURL carried all data that could be obtained from a DOI name at a particular point in time, it would be static when used as a pointer in a document. Thus the DOI System provides an authoritative centralized resolution system with careful control of the results of the resolution process. Additionally this identifier can be resolved to multiple pieces of information, including pointers to well-structured metadata.
A project to use OpenURL to address the 'appropriate copy' problem was undertaken in 2001 with participation from CrossRef and organizations in the Digital Library Federation. This has now been developed further into an active production level service used by CrossRef and a number of library service vendors to deploy localisation of DOI names referencing articles. For further information, see "OpenURL and CrossRef".
3.10 The DOI System and Persistent URLs (PURLs)
A PURL is a Persistent Uniform Resource Locator. Functionally, a PURL is a URL. However, instead of pointing directly to the location of an Internet resource, a PURL points to an intermediate resolution service. The PURL resolution service associates the PURL with the actual URL and returns that URL to the client as a standard HTTP redirect. The OCLC PURL Service has been strongly influenced by the active participation of OCLC's Office of Research in the Internet Engineering Task Force Uniform Resource Identifier working groups. PURLs are an approach to fixing the problem of unstable URLs. The 2002 OCLC Web Survey includes measurement of percent of IP addresses identifying a Web site in Year A also identifying a Web site in Year B: almost half of web addresses registered in one year are no longer reachable after one year. As time goes on this compounds: only 13% of the web addresses registered in 1998 were still around in 2002 (19% of the sites created in 1999 survived to 2002, as did 33% of the 2000 ones and 51% of those from 2001). The folly of relying on URLs alone for persistence is dramatically brought home by this statistic.
PURLs are all http and inherit both the strength and weakness of that approach. PURLs provide one level of indirection, just like a single value DOI name, but all contained within a single server and that single server is permanently attached to a specific domain name. PURL servers don't know about each other. The redirection is functionally equivalent to the way the DOI System uses a proxy server, dx.doi.org, which re-interprets DOI name queries into http. PURL is equivalent to a local DOI name which never goes beyond the proxy server approach and never makes use of the multiple resolutions and data types, metadata approach, and enforced common policy. The DOI System also provides a centrally managed redirection service rather than local purl server management.
We recommend that interested parties refer to independent comparisons e.g.: "To attach truly archival, long-lived names to network-accessible resources, I think PURLs should not be considered. My primary objection is that PURLs rely on DNS for labelling namespaces, which has at least two problems in the long run: DNS names are controlled by outside agencies at many levels (i.e. not just local administrators, but our ".EDU" parent domain is subject to the Internet governing bodies). Also, I believe the entire DNS naming system will be revised within the next 100 years, which is probably shorter than the range MIT Archives routinely anticipates. Although the Handle System currently needs the crutch of HTTP proxies which have the same DNS naming problem, it is inherently free of the domain name system and even the current Internet implementation. The handle namespace is not connected to any other protocol or standard, because it was properly designed to persist as a meaningful, resolvable naming system well into the foreseeable future." (http://web.mit.edu/handle/www/purl-eval.html)
The DOI System sits on top of a system explicitly designed to name digital objects on networks. This system, the Handle System, can provide the web-centric functions of a PURL through the use of a proxy server that returns a PURL-like single redirection. But underneath that is a much more extensive set of functionality that can be used as needed now or in the future.
A PURL can be resolved only by its designated PURL server. A DOI name can be separated into resolver and identifier. A given DOI name can be resolved by any handle resolver. A counter-argument involves the use of PURL partial redirects which can allow, for example, the single server at purl.org to route to what might be considered PURL subdomains to other PURL servers and to change this routing over time. But this puts the purl.org server in the middle of PURL resolutions forever. The dx.doi.org server could serve that same function and also be subject to the same problems, but it is only one way into the DOI System. dx.doi.org is just as deployed as purl.org and adds a more robust underlying system.
A PURL-based Object Identifier (POI) is a simple specification for resource identifiers based on the PURL system. The use of the POI is closely related to the use of the Open Archives Initiative Protocol for Metadata Harvesting and with the OAI identifier format used within that protocol. The main argument for POIs seems to be that they fit with OAI-compliant repositories. As described in the POI Resolver Guidelines, POIs are not explicitly assigned to resources -- they are implied by the existence of an OAI metadata 'item' with an identifier that can be mapped to a POI. There are a number of assumptions: that an oai metadata item will correspond to an available Resource; that resource will be available through a URL that can be derived from the oai-identifier; that identifier will work because the right kind of PURL partial redirect has been made. This can be contrasted with DOI names, which are not considered to exist before being explicitly registered and once registered are by definition part of the resolution system. Any implementation of persistent identifiers using existing material must accommodate DOI names, unless it plans to ignore the great bulk of scholarly journal literature.
The partial redirection rules that PURL uses to map OAI identifiers to POIs are simple and result in web redirections with a large degree of granularity. Currently POIs can only partially redirect OAI identifiers based on its namespace-identifier to a specific web server. Although this is not necessarily an issue, it does pose long term-collection management issues. This high level granularity is however not an intrinsic limitation of PURLs, indeed, PURL servers could use more sophisticated partial redirection algorithms and obtain a much finer level of redirection. This would however require PURL servers to have a mechanism for expressing complex redirection mechanisms and the ability to promptly and accurately distribute them across all PURL servers. The partial redirection lets you move entire sub-trees from one location to another but doesn't let you rearrange the trees. This requires, as noted in the POI Resolver Guidelines, that the URLs are used in a consistent manner or at least that the base URL apply to all POIs in a given namespace. The registration of a separate PURL for each POI, which is the only way to begin to introduce the same level of flexibility given by the simplest use of DOI names, is given as a last resort case and recommended only for small numbers of POIs. One of the advertised strengths of POIs, that you don't have to register each one, also has the usual weakness of deriving identifiers from some aspect of the resource: defining who owns it and where it fits in their organization of resources. The DOI System policies and social engineering aspect we have referred to elsewhere (DOI names are backed by an organization dedicated to their growth and survival) add value as well as functionality to the DOI System.
3.11 The DOI System and the Domain Name System (DNS)
DOI name resolution in native resolver form does not require the use of the DNS (Domain Name System), though does of course when used with the proxy resolver. The Handle System is more appropriate for large numbers of digital objects than DNS, and the DNS administrative model argues against using it as a general-purpose name system (DNS administration typically requires a network administrator, and has no provision for administration per name by anyone other than a network administrator). DNS also has well-recognised problems of security and updating which suggest that it will not be sufficient to assume that existing DNS technology should be adapted to deal with new requirements, rather than inventing something new: peer-to-peer networks already presage this.
URLs are grouped by domain name and then by some sort of 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. A DOI name, DOI Application Profile and DOI System services are layers of abstraction which allow more flexible management of sets of DOI names, in a more useful way than as a fixed sub-domain.
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 a detailed analysis, see the article cited in the bibliography: "Online Registries: The DNS and Beyond...", Release 1.0, September 2003. [ doi:10.1340/309registries ]
Previous Chapter: 2 Numbering Next Chapter: 4 DOI® Data Model