Bootstrapping the Web


Part 1: On Issues Regarding the Use of Namespaces of Identifiers in Network-Based Applications

Part 2: A Proposal for Representing Resource Identifiers in the OpenURL Framework on the Web


Tony Hammond
Elsevier Ltd, Advanced Technology Group,
32 Jamestown Road, London, NW1 7BY, UK


Herbert Van de Sompel
Los Alamos National Laboratory, Research Library, MS-P362, PO Box 1663, Los Alamos, NM 87545-1362, USA

 

 

 

 

 

 

 

 

Disclaimer - The views and opinions of the authors of this paper do not necessarily state or reflect those of their respective organizations.

 

 

 

 


Part 1: On Issues Regarding the Use of Namespaces of Identifiers in Network-Based Applications

In the conclusion of the third D-Lib Magazine paper on the SFX research on context-sensitive linking [1] the authors wrote:

 

Also, a standardization of a local redirection URL – like the SFX-URL – and of vendorId, databaseId and nameSpace values is required. Such a standardization will also be valuable for other ongoing work in the digital library environment.

 

The above-mentioned SFX-URL became de-facto standardized through the publication in 2000 of the draft OpenURL (now referred to as OpenURL 0.1) [2], and its fast acceptance in the scholarly information industry.  NISO Committee AX recently released a two-part document entitled The OpenURL Framework for Context-Sensitive Services [3] that defines core components required to allow the implementation of context-sensitive service-environments in the scholarly information Community, as well as in potentially any other network-based information Community.  Amongst other things, the document addresses, in a general manner, the elements that require standardization as per the above quote.

 

Of special importance is the issue referred to as nameSpace values, which is about the identification of resources in the OpenURL Framework by means of Identifiers in Namespaces.  OpenURL 0.1 hardwired some Namespaces that are important for the scholarly information Community bibcode, doi, oai, pmid into the specification.  It is interesting to note that none of the above-mentioned Namespaces have an official status in the Internet infrastructure, that is, they are not registered as URI Schemes or as URN Namespaces.  Yet they are commonly used in networked scholarly information applications.  Also interesting to note is that some of the above-mentioned Namespaces are well-specified in dedicated documents created for public use, while the specification of others may be embedded in descriptions of broader information systems, or may not necessarily be easy to discover, or may even not exist.  For example, it seems that no public specification of the pmid Namespace of PubMed Identifiers exists – yet that Namespace forms the basis of many networked applications.

 

When generalizing the OpenURL Framework beyond the scholarly information environment, NISO AX recognized that hardwiring Namespaces into a specification was not a viable option.  Therefore, it introduced the notion of a Registry that amongst others lists Namespaces that can be used to identify resources in OpenURL Frameworkbased context-sensitive service environments.  NISO AX also recognized that the aforementioned existence of popular Namespaces without legitimate status in the Internet infrastructure, or without rigorous definitions, is not exclusive to the scholarly information environment.  For example, Vehicle Identification Numbers (VIN) are commonly used in network-applications in the US-based car-selling Community, yet there exists no VIN URI Scheme or URN Namespace. US ZIP codes, and D&N DUNS numbers (EDI applications) are other examples given in the Bison-Fut paper [4] that provided inspiration for the work of NISO AX.  Many other such Namespaces exist.

 

As a result of the above considerations, NISO AX introduced the concept of Naming Environments, to facilitate the usage of different types of Namespaces in the context of OpenURL Framework applications.  A Naming Environment bundles Namespaces of the same type. It can be considered to be a namespace of namespaces.  The OpenURL Framework documents recognize three such Naming Environments:

 

      The URI Naming Environment  This Naming Environment encompasses all Namespaces listed in the IANA Registries for URI Schemes, including the Registry for URN Namespaces.  As a result of the introduction of this Naming Environment, the OpenURL Framework allows for the identification of resources by means of URIs or URNs.  For example, in OpenURL Framework applications, uri:mailto:herbertv@lanl.gov is an Identifier in the URI Naming Environment that uses the mailto URI Scheme.

 

      The ORI Naming Environment  This Naming Environment encompasses Namespaces that are registered by (or on behalf of) information Communities in the OpenURL Registry.  The registration mechanism is intended to be lightweight, allowing for a fast track mechanism to facilitate the use of popular/public Namespaces in OpenURL Framework applications. As a result of the introduction of this Naming Environment, the OpenURL Framework allows for the identification of resources by means of  registered ORI Namespaces.  For example, in OpenURL Framework applications, ori:uszip:87501 could be an Identifier in the ORI Naming Environment that builds on the (fictionally) registered uszip Identifier Scheme.

 

      The XRI Naming Environment  This Naming Environment is introduced to facilitate the usage of private Namespaces, for which no need for public recognition exists.  Typically, this Naming Environment will be used to identify resources in local applications, or in applications that include parties that operate on the basis of prior, not publicly disclosed agreements.  For example, xri:ASIN:83920393 could be an Identifier in the XRI Naming Environment used by Amazon.com in communications between internal systems.

 

The introductory quote from 1999 suggested that the standardization of nameSpace values could be valuable for other ongoing work in the digital library environment.  Likewise, today it is felt that the Naming Environment concept, and especially the introduction of a low-barrier mechanism to facilitate the registration of public Namespaces, may be valuable well beyond OpenURL Framework applications, and might provide a generic mechanism to bootstrap popular Namespaces for use in web-based services.

 

Not surprisingly, the release for Public Comment of the OpenURL Framework documents immediately led to comments from interested parties as to why does the OpenURL Framework not make use of URI schemes, and on a related vein why do its Naming Environments conflict with potential URI schemes.

 

The first of these comments is the more substantial. As has been noted above the OpenURL Framework has adopted an independent system of tiered Naming Environments URI/ORI/XRI which allows for a comprehensive treatment of all Identifiers. The OpenURL Framework Naming Environments are orthogonal to the Internet URI Schemes and remain independent of any current or future assignations under that domain. They provide an immediate and coherent solution to the problem of referencing resources in a networked environment

 

This first public comment proffered as a solution that the OpenURL Framework register either a new URI scheme for the ORI Naming Environment or a new URN Namespace ID, and make use of the reserved experimental URI Scheme prefix (x-) for the XRI Naming Environment, while representing the URI Naming Environment names natively as URIs. In other words, a hybrid solution.  At first glance this may appear reasonable but in fact it is riddled with difficulties. Registering a new URI Scheme/URN Namespace ID is by no means a guaranteed process. As an illustrative example, the DOI Community have been endeavoring to register doi as a URI Scheme for some 12 months now and have already issued two Internet Drafts – a third is now being issued. This Community has an installed base of over 7 million identifiers deployed but with (as yet) no official Internet recognition. Another URI Scheme in the wings is the tag proposal which has now been 24 months in review. Obviously, to wait for a period of months or even years to complete such a registration process before the OpenURL Framework can be out to Trial Use is untenable.

 

Another suggestion was made that a URN Namespace ID registration could be a more straightforward process, but here again there are difficulties. URN has the intent that the Identifiers will be persistent. This may not be something that the OpenURL Framework would want to guarantee for Namespaces subsumed under the ORI Naming Environment. The problem is that registered Namespaces are third party Namespaces and OpenURL Framework Communities – as registration agents – are not in a position to determine the intent of those Namespaces. There may also be expectations of resolution behavior for URNs – again something that the OpenURL Framework would not be in a position to guarantee.

 

As to the idea of using the reserved experimental URI Scheme prefix (x-) for the XRI Naming Environment, again there is a problem of intent. Names under the XRI Naming Environment are not (necessarily) experimental in any way, but instead are specific to the Referrer environment. There is also no guarantee of uniqueness as there is no assigned naming authority for such URI Schemes. And lastly there is some confusion between the naming practice for URI alternative trees – RFC 2717 uses a hyphen to delimit the prefix, while a later W3C Note (21-9-2001) uses a period. Further, this W3C Note goes on to say that no alternative trees have been registered to date, although RFC 1738 does indeed reserve the set of trees beginning with x- for experimental use.

 

The other major public comment received mentioned a conflict of interest between work currently going on in the Oasis TC on XRI and the use of XRI in the OpenURL Framework. In fact there is no conflict because – as stated above –  the OpenURL Framework Naming Environments are orthogonal to the URI Schemes and operate within their own context, and so can never collide with them. This could be made immediately obvious by the simple device of rooting the OpenURL Framework Namespaces – by preceding each with a colon, e.g. :xri:, the Namespaces cannot be mistaken for URI Schemes which strangely remain unrooted.

 

It is recommended that a small group of experts assembled by NISO consider along with representatives from the IETF and W3C Communities how best to integrate the OpenURL Framework Naming Environments with the URI system. There are several factors that need to be considered: choice of URI scheme(s), transform methodologies, character encodings, naming authorities, and dereference expectations, to mention but a few. A successful outcome from this endeavor would lead to nothing more than a general means to bootstrap common namespaces onto the public Internet.

 

References

[1] Van de Sompel, Herbert and Patrick Hochstenbach. Reference Linking in a Hybrid Libary Environment, Part 3: Generalizing the SFX solution in the SFX@Ghent & SFX@LANL experiment. 1999. D-Lib Magazine. <http://www.dlib.org/dlib/october99/van_de_sompel/10van_de_sompel.html>

[2] The OpenURL, v.0.1. Editors: Herbert Van de Sompel, Patrick Hochstenbach and Oren Beit-Arie. 2000.  <http://www.sfxit.com/openurl/openurl.html>

[3] The OpenURL Framework for Context-Sensitive Services.  NISO AX. <http://library.caltech.edu/openurl/Public_Comments.htm>

[4] Van de Sompel, Herbert and Beit-Arie, Oren. Generalizing the OpenURL Framework beyond References to Scholarly Works: the Bison-Fut model. 2001. D-Lib Magazine. <http://www.dlib.org/dlib/july01/vandesompel/07vandesompel.html>

 


Part 2: A Proposal for Representing Resource Identifiers in the OpenURL Framework on the Web

This proposal presents alternate methods for presenting OpenURL Framework resource identifiers as URIs with a critique of the various approaches. A review of the current OpenURL Framework Naming Environments is presented first.

 

Review of OpenURL Framework Naming Environments

To allow the extensible description of OpenURL Framework ContextObject Entities by means of Identifiers, the concept of a Naming Environment is introduced. A Naming Environment is simply a namespace of namespaces of Identifiers. The OpenURL Framework introduces a tiered Naming Environment system – URI, ORI, XRI – each serving a specific purpose. We can characterize these use cases as: church, street, home.

The URI Naming Environment reflects the broad church of URI adherents who believe in having a uniform naming scheme across the Web. This common approach is obviously key to establishing a general naming interoperability and is strongly advocated by the W3C.

However, out on the streeets, there are multiple other information identifier schemes in common use which are not represented under URI schemes. The ORI Naming Environment reflects the reality that online communities often trade in specific identifier schemes known across industry verticals.

But this is still not enough. Other local identifier schemes are spoken at home and may be shared in restricted B2B or B2C contexts. This is the domain of the XRI Naming Environment.

The OpenURL Framework naming practice offers an immediate and coherent pragmatic solution to referencing resources in a networked environment. The naming system is self-contained and is best regarded as being orthogonal to the Web (defined here as the set of all URIs). By mapping OpenURL Framework resource identifiers onto URIs we have a general bootstrapping mechanism to promote namespaces onto the Web.

 

In Church – The Uniform Resource Identifier (URI) Naming Environment

The Uniform Resource Identifier (URI) Naming Environment contains all URI schemes registered with IANAhttp://www.iana.org/assignments/uri-schemes including the registered URN Namespace Identifiers.

Registries on which the URI Naming Environment is based:

       IANA URI scheme registry:
http://www.iana.org/assignments/uri-schemes

       IANA URN Namespace Identifiers:
http://www.iana.org/assignments/urn-namespaces

These registries are an essential part of the Internet infrastructure.  Therefore, Identifiers in the URI Naming Environment are globally understood.

Within the OpenURL Framework naming system Identifier Namespaces from this Naming Environment are referenced by means of the URI Namespace uri, which qualifies an Identifier from a URI scheme namespace.

       uri:urn:ISBN:0262011808

       uri:mailto:jane.doe@caltech.edu

       uri:http://www.sciencedirect.com

 

On the Street – The Open Resource Identifier (ORI) Naming Environment

Many commonly used, community-specific schemes for the identification of resources are not part of the Internet infrastructure.  To support such schemes the OpenURL Framework creates a Registry for namespace identifiers.  The Open Resource Identifier (ORI) Naming Environment contains namespaces that are registered in the Registry for namespace identifiers.

Registry on which the ORI Naming Environment is based:

       The OpenURL registry:
http://openurl.info/registry/

This Registry is public.  Therefore, Identifiers in the ORI Naming Environment are globally understood.

Identifier namespaces from this Naming Environment are referenced by means of the ORI Namespace ori, which qualifies an Identifier from a registered namespace.

       ori:pmid:9036860

       ori:doi:10.1126/science.275.5304.1320

       ori:rfr:oclc.org:Inspec

 

At Home – The Private Resource Identifier (XRI) Naming Environment

Some identifier schemes are specific to a given information resource; there may be no need for them to be understood globally.  The Private Resource Identifier (XRI) Naming Environment contains namespaces that are specific to Referrer environments.

There are no global mechanisms available that facilitate interpreting an Identifier namespace from this Naming Environment, as opposed to the URI and ORI Naming Environments.  Without such global mechanisms, interpretation of an identifier in the XRI Naming Environment by the Resolver most likely requires a prior understanding between the Referrer and the Resolver. 

Identifiers under this Naming Environment are referenced by means of the XRI Namespace xri, which qualifies an Identifier from a Referrer-specific namespace.

       xri:my-service:addToCart

       xri:ERL:MX01:123059849

 

Syntax

The general syntax of OpenURL Framework resource identifiers is that of a hierarchical colon-delimited string. The topmost (i.e. leftmost) component is uri for URI Naming Environment, ori for ORI Naming Environment, and xri for XRI Naming Environment.

 

Proposal – Examples

We shall consider the following application Identifiers from each of the three OpenURL Framework Naming Environments for the sake of example:

       uri:http://www.example.org/abcde

       ori:pmid:9036860

       xri:my-service:addToCart

We shall also consider an example of a registered ORI Identifier which shows an extended hierarchy:

       ori:fmt:xml:xsd:book


Proposal – Methods

Currently, as of March 2003 there are some 38 registered URI schemes under IANA and 3 reserved schemes. Not all schemes are equally valid being bound to specific protocols (sometimes moribund) or having a specific intent.

There are two main approaches: We either wrap OpenURL Framework resource identifiers under a single URI scheme – this is the case for ORI/XRI identifiers and may also be done for URI identifiers when a common handling is desired. The other approach is to promote OpenURL Framework resource identifiers to multiple URI schemes – a hybrid method.

This leads to 7 candidate methods for mapping OpenURL Framework resource identifiers onto URIs proceeding from esatblished URI schemes first:

       Method 1 – http:

       Method 2 – data:

       Method 3 – tag:

       Method 4 – x-open: *

       Method 5 – open: *

       Method 6 – urn:open: *

       Method 7 – Hybrid

* The term open is just a working term.


Method 1 – Use of the http: URI scheme

Status – RFC 2616

The most obvious way to present OpenURL Framework resource identifiers as URIs is to make them available under the mother of all URI schemes – the http: scheme. This can be done by representing URI and ORI identifiers under the OpenURL domain (openurl.info) and XRI identifiers either under the OpenURL domain, or under the OpenURL domain and introduce a Referrer-specific qualification.

We can either treat the identifiers as opaque strings or reflect the natural hierarchy of an http-based URI.

As opaque strings, the URI and ORI identifiers could be presented as

       http://openurl.info/uri/uri:http://www.example.org/abcde

       http://openurl.info/ori/ori:pmid:9036860

       http://openurl.info/ori/ori:fmt:xml:xsd:book


while an XRI identifier could be presented variously as

       http://openurl.info/xri/xri:my-service:addToCart

       http://openurl.info/xri/xri:my-service:addToCart@example.com

 

Note that in the first case, there is no authority component and thus no guarantee of uniqueness, whereas in the second case an authority component is used to qualify the XRI identifier (here using a mail address like syntax) and thus there is no collision between Identifiers from different Referrer environments. We also suggest to locate the identifiers under the relative URI paths /uri,  /ori and /xri in order to better manage the domain.

As hierarchical strings, the URI and ORI identifiers could be presented as

       http://openurl.info/uri/http///www.example.org/abcde

       http://openurl.info/ori/pmid/9036860

       http://openurl.info/ori/fmt/xml/xsd/book


while an XRI identifier could be presented variously as

       http://openurl.info/xri/my-service:addToCart

       http://openurl.info/xri/my-service:addToCart@example.com

 

In this case, there is no need to introduce relative URI paths as the mapping naturally provides such paths.

Note that URI identifiers can also be expressed natively as a URI by simply removing the URI Naming Environment prefix uri::

       http://www.example.org/abcde

 

Pros:

The main advantage of using the http URI scheme is its widespread familiarity and the general level of support – i.e. dereference capabilities – by Internet software components. Also use of the OpenURL domain (openurl.info) provides a single authority component for all the OpenURL Framework resource identifiers.

 

Cons:

A disadvantage of presenting OpenURL Framework resource identifiers as http URIs is the general expectation that http URIs are derefenceable, which may not be the case here. One device for making such identifiers dereferenceable would be to establish service components located at the relative URI paths /uri,  /ori and /xri which could return meaningful representations based on the subsequent path available from the <pathinfo> environment variable. (This is also another reason to locate the opaque identifier strings under relative URI paths.)

 

It must also be pointed out that the http URI scheme is intended for documents which are retrieved using the HTTP network protocol. This may not apply to OpenURL Framework resource identifiers.


Method 2 – Use of the data: URI scheme

Status – RFC 2397

Another method to presenting OpenURL Framework Identifiers as URIs is to make them available under the data immediate addressing URI scheme. The data URI scheme allows an arbitrary text representation to be presented within a URI.  The URI syntax is

data:[<mediatype>][;base64],<data>

where the <mediatype> defaults to plain/text. Since we are only concerned with plain text we omit the optional parameters and can present the OpenURL Framework resource identifiers as URIs by treating them as opaque strings and prepending the data: URI scheme as follows:

       data:,uri:http://www.example.org/abcde

       data:,ori:pmid:9036860

       data:,ori:fmt:xml:xsd:book

       data:,xri:my-service:addToCart

 


Note that URI identifiers can also be expressed natively as a URI by simply removing the URI Naming Environment prefix
uri::

       http://www.example.org/abcde

 

Pros:

The advantage of using the data URI scheme is that we present the OpenURL identifiers as simple data strings and make no attempt to interpret them within the URI context. A further advantage is that we do not require any authority component, eg a DNS name.

 

Cons:

A disadvantage of using the data URI scheme is its relative unfamiliarity. A further disadvantage is that we do not require any authority component, eg a DNS name.

 

Another disadvantage is the relative unfamiliarity of the data URI scheme and the fact that there are no dereference capabilities available

 


Method 3 – Use of the tag: URI scheme

Status – Internet Draft: draft-kindberg-tag-uri-04.txt (Expired)

An alternative way to present OpenURL Framework resource identifiers as URIs is to make them available under the proposed tag URI scheme. The tag URI scheme allows us to present identifiers within a URI that are globally unique across space and time.  The URI syntax is

tag:<authorityName>,<date>:[<specific>]

where <authorityName> is either the DNS name or email address of the authority, and <date> is the date. By using the canonical DNS name openurl.info for the <authorityName>, the current year as <date>, we can present the OpenURL Framework resource identifiers as URIs by treating them as opaque strings and prepending the tag URI scheme as follows:

       tag:openurl.info,2003:uri:http://www.example.org/abcde

       tag:openurl.info,2003:ori:pmid:9036860

       tag:openurl.info,2003:ori:fmt:xml:xsd:book

       tag:openurl.info,2003:xri:my-service:addToCart

 


The URI identifier can be expressed natively as a URI by removing the URI Naming Environment prefix
uri::

       http://www.example.org/abcde

 

Pros:

The advantage of using the tag URI scheme is that we present the OpenURL resource identifiers as simple data strings under an authority component comprising a DNS name and a date pair.

 

Cons:

The main disadvantage of using the tag URI scheme is the fact that its current status is unclear after passing through four Internet Drafts (24 months), the last having just expired on March 1, 2003. At this time it cannot be recognized as a valid URI scheme. Another disadvantage is its relative unfamiliarity and the fact that there are no dereference capabilities available.


Method 4 – Use of the reserved x-open: URI schemes

Status – RFC 1738

RFC 1738 reserves URI schemes beginning with x-  for experimental use. This presents another straightforward way to present OpenURL Framework Identifiers as URIs by using a reserved URI scheme, x-open say:

x-open:<?ri-id>

where <?ri-id> is the OpenURL Framework resource identifier appended as an opaque string. By simply prepending the reserved x-open URI scheme, we can present the OpenURL Framework resource identifiers as follows:

       x-open:uri:http://www.example.org/abcde

       x-open:ori:pmid:9036860

       x-open:ori:fmt:xml:xsd:book

       x-open:xri:my-service:addToCart

 


The URI identifier can be expressed natively as a URI by removing the URI Naming Environment prefix
uri::

       http://www.example.org/abcde

 

Pros:

The main advantage of using the x-open URI scheme is that we can immediately present the OpenURL Framework resource identifiers as simple data strings. There is no need for URI scheme registration and no confusion with transport protocol.

 

Cons:

The disadvantage of using the x-open URI scheme is that there is no naming authority and thus no guarantee that the URIs so minted will remain unique. Further while no transport protocol is implied by the x-open URI scheme, there is still the intent that these are for experimental use which does not accord with the general intent of the OpenURL Framework resource identifiers.

 

There is also some confusion between the naming practice for URI alternative trees – RFC 2717 uses a hyphen to delimit the prefix, while a later W3C Note (21-9-2001) uses a period. Further, this W3C Note goes on to say that no alternative trees have been registered to date, although RFC 1738 does indeed reserve the set of trees beginning with x- for experimental use.

 

Another disadvantage is the relative unfamiliarity of x- URI schemes and the fact that there are no dereference capabilities available.


Method 5 – Use of a dedicated open: URI scheme

Status – None at this time

A practical way to present OpenURL Framework resource identifiers as URIs is to make them available under a dedicated URI scheme, open say. The open URI scheme would have the following syntax:

open:<?ri-id>

where <?ri-id> is the OpenURL Framework resource identifier appended as an opaque string. By simply prepending the open URI scheme, we can present the OpenURL Framework resource identifiers as follows:

       open:uri:http://www.example.org/abcde

       open:ori:pmid:9036860

       open:ori:fmt:xml:xsd:book

       open:xri:my-service:addToCart

 


The URI identifier can be expressed natively as a URI by removing the URI Naming Environment prefix
uri::

       http://www.example.org/abcde

 

Pros:

The advantage of using the open URI scheme is that we present the OpenURL Framework Identifiers as simple data strings under a dedicated URI scheme which serves as an authority component.

 

Cons:

The disadvantage of using a dedicated open URI scheme is that the whole process of registering a new RFC would have to be started up by submitting an Internet Draft. There is no notion of how long this process would take and no guarantees at all that it would be approved by the IESG and so at this time such a dedicated scheme cannot be recognized as a valid URI scheme.  (Note that the proposed doi URI scheme is still awaiting approval 12 months after originally being submitted – although lately we hear encouraging signals that there may be some movement in the near future, and the proposed tag URI scheme has been awaiting approval for 24 months – the last version just expired March 1, 2003.)


Method 6 – Use of a dedicated open: URN Namespace ID under the urn: URI scheme

Status – None at this time

A straightforward way to present OpenURL Framework resource identifiers as URIs is to make them available under a dedicated URN Namespace ID, open say, under the urn URI scheme. The open URI scheme would have the following syntax:

urn:open:<?ri-id>

where <?ri-id> is the OpenURL Framework resource identifier appended as an opaque string. By simply prepending the open URI scheme, we can present the ORI/XRI identifiers as follows:

       urn:open:uri:http://www.example.org/abcde

       urn:open:ori:pmid:9036860

       urn:open:ori:fmt:xml:xsd:book

       urn:open:xri:my-service:addToCart

 


The URI identifier can be expressed natively as a URI by removing the URI Naming Environment prefix
uri::

       http://www.example.org/abcde

 

 

Pros:

The advantage of using the open URN Namepsace ID is that we present the OpenURL Framework Identifiers as simple data strings under a dedicated URN Namespace ID which serves as an authority component.

 

Cons:

The disadvantage of using a dedicated open URN Namespace ID is that the whole process of registering a new RFC would have to be started up by submitting an Internet Draft. There is no notion of how long this process would take if a formal URN Namespace ID were requested and no guarantees at all that it would be approved by the IESG and so at this time such a dedicated scheme cannot be recognized as a valid URN Namespace ID.

 

Another disadvantage is that URN has the intent that the Identifiers will be persistent. This may not be something that the OpenURL Framework would want to guarantee for Namespaces subsumed under the ORI Naming Environment. The problem is that registered Namespaces are third party Namespaces and OpenURL Framework Communities – as registration agents – are not in a position to determine the intent of those Namespaces. There may also be expectations of resolution behavior for URNs – again something that the OpenURL Framework would not be in a position to guarantee.

 

Also URN has a specific requirement for enabliing location independent identification of a resource. Again this cannot be assumed to be true for all OpenURL Framework resource identifiers. A case in point is the Handle System (ori:hdl:) where a given handle defines a location within the global handle space, i.e. the Handle naming authority is directly equivalent to a DNS name.


Method 7 – Use of a hybrid mapping

Status – Mixed

From a URI perspective the OpenURL Framework resource identifiers could be accomodated as URIs by adopting a hybrid approach. For example, the following choices could be made – other choices may be possible.

URI resource dentifiers could be expressed natively as a URI by removing the URI Naming Environment prefix uri::

       http://www.example.org/abcde

 

ORI resource identifiers could be expressed by registering a new URI scheme or a registering a new URN Namespace ID:

       open:ori:pmid:9036860

       open:ori:fmt:xml:xsd:book

 

       urn:open:ori:pmid:9036860

       urn:open:ori:fmt:xml:xsd:book

 

XRI resource identifiers could be represented under an experimental URI scheme:

       x-open:xri:my-service:addToCart

 

Pros:

The advantage of using a hybrid approach is that we reaffirm the primacy of the URI schemes and seek to minimize disruptions to existing scheme registrations.

 

Cons:

The disadvantage of using a hybrid approach is that we deny the unity of the OpenURL Framework Naming Environments and we lose the identity of representing those Naming Environments as URIs. We still have the problem of how to adequately represent the ORI/XRI Naming Environments. And if we contemplate the need to register a URI scheme or URN Namespace ID for the ORI Naming Environment we have already impacted on the Web without retaining a common approach to mapping names.


Summary and Recommendations

By rejecting any hybrid approach in mapping OpenURL resource identifiers to URIs we maintain the essential unity of the OpenURL Framework Naming Environments and also the identity of those Naming Environments.

 

On balance the two best approaches would seem to be:

       Method 1 – http:

       Method 5 – open: (possibly prefigured by Method 4 – x-open:)

 

The first has all the merits of familiarity and dereference capabilities and can be immediately deployed but has the demerits of appositeness of scheme. The second has the merit of exclusivity but the demerits of postponed deployment (possibly indefinitely) and lack of dereference capabilities. To allow immediate deployment the experimental x-open: scheme could be used as a placeholder for a future registered open: scheme.

 

A third way may be to consider the adoption of both mappings http: for dereference and open: for canonical reference. Semantic languages such as OWL could always be employed to assert equivalence between individual URIs, i.e.

 

<!—- OpenURL Framework ":ori:pmid:9036860" -->

<Open rdf:about="open:ori:pmid:9036860">

  <owl:sameAs rdf:resource=http://openurl.info/ori/pmid/9036860"/>

</Open>

 

 

One specific recommendation for OpenURL Framework resource identifiers is that they be rooted by preceding the identifier with a colon (:) so that there is no possibility of ever being mistaken for a URI, i.e. instead of

    ori:pmid:9036860

prefer

    :ori:pmid:9036860