The OpenURL - A Distinguished URI?

Apropos the recent Draft TAG Finding 'The Use of Metadata in URIs' of July
8, 2003 [1], we would like to draw attention to the ANSI/NISO Draft Standard
on 'The OpenURL Framework for Context-Sensitive Services'. This Draft
Standard defines two things: 1) a data structure termed the ContextObject,
and 2) a Registry mechanism for information components to build the
ContextObject. This ContextObject can be serialized into multiple formats.
Specifically of interest here a Key/Encoded-Value format is defined for
serializing the ContextObject onto an 'http' URI querystring - the so-called
OpenURL.

 

The OpenURL querystring provides a unique signature token for the parameter
key 'ver_id' - the ANSI/NISO standard number 'Z39.88-2003' (although the
actual year signifier may result as '2004' instead of '2003'). The
Key/Encoded-Value format is defined in the Draft Standard and is a
registered information component. This means that the payload of an 'http'
URI querystring can be deconstructed and validated as being a conformant
ContextObject within the OpenURL Framework. 

 

The combination of a unique signature token and a defined public data
structure means that OpenURLs are distinguished URIs and can be both
recognized and validated as such. OpenURLs challenge the notion of
authority-specific URI structures by providing public vehicles for the
exchange of metadata. Note that this is in direct opposition to the caveat
raised by the TAG Finding:

 

"However, observers are cautioned that assignment policies are not generally
subjected to standardization and may be changed by the relevant authority at
any time."

 

The OpenURL by contrast will be subject to such standardization and software
programmed on the basis of the OpenURL Framework specification will be
robust.

 

The ContextObject data structure is a simple Entity/Descriptor matrix. Six
Entities are defined in the ContextObject: 

 

* the Referent - the subject of the ContextObject 

* the ReferringEntity - a resource that references the subject 

* the Requester - the agent requesting services about the subject 

* the ServiceType - the type of service to be provided 

* the Resolver - the network service component that delivers services 

* the Referrer - the host platform which generated the ContextObject 

 

The Referent is the only mandatory Entity.

 

To describe these Entities four types of Descriptor are defined: 

 

* an Identifier type 

* a Metadata (By-Value) type 

* a Metadata (By-Reference) type 

* a Private Data type

 

Descriptors are not exclusive but may be used together, i.e. an Entity may
be described by a combination of mulitple identifiers and multiple metadata
terms.

 

Some simple examples of OpenURLs can be found in a recent submission to
rss-dev of the 'mod_context' module, which defines a serialization of the
ContextObject as an RSS 1.0 module, see [2]. In these examples, an OpenURL
is used as a public query API to network service components which return
context-sensitive RSS 1.0 feeds. 

 

For further information on the OpenURL Framework see the Draft Standard
documents Part 1 [3] and Part 2 [4] on the ANIS/NISO AX website [5]. 

 

We hope that the use of OpenURL as a public data structure for the exchange
of metadata will be of interest to the URI community in general and invite
feedback [6].

 

Regards,

Tony

 

[1] http://www.w3.org/2001/tag/doc/metaDataInURI-31.html
<http://www.w3.org/2001/tag/doc/metaDataInURI-31.html> 

[2] http://www2.elsevier.co.uk/~tony/spec/rss/mod_context.html
<http://www2.elsevier.co.uk/~tony/spec/rss/mod_context.html>  

[3]
http://library.caltech.edu/openurl/PubComDocs/StdDocs/Part1-PC-20030513.pdf
<http://library.caltech.edu/openurl/PubComDocs/StdDocs/Part1-PC-20030513.pdf
> 

[4]
http://library.caltech.edu/openurl/PubComDocs/StdDocs/Part2-PC-20030513.pdf
<http://library.caltech.edu/openurl/PubComDocs/StdDocs/Part2-PC-20030513.pdf
> 

[5] http://library.caltech.edu/openurl/Public_Comments.htm
<http://library.caltech.edu/openurl/Public_Comments.htm> 

[6] mailto:openurl.comment@library.caltech.edu

 

 

Tony Hammond

Advanced Technology Group, Elsevier

32 Jamestown Road, London NW1 7BY, UK

<mailto:t.hammond@elsevier.com <mailto:t.hammond@elsevier.com> >

<tel:+44-20-7424-4445>