RE: The OpenURL - A Distinguished URI?

Tony,

> 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.

I am taking a look over the OpenURL material, but have by no-means completed
that task. I'd offer the following thoughts based on the mention of "the
payload of an 'http' URI querystring".

I don't see the "direct opposition" that you claim. Under the http: URI
scheme authority to assign URI is delegated to the 'owner' of a particular
DNS domain name. That authority (which is generally not the ANSI/NIST spec
you are working on) may have an assignment policy for the way that it uses
query strings on some or all of the URI that it publishes. It may or may not
publish that policy. Published or not, that policy may make reference to a
pattern established in another specification (such as "The OpenURL
Framework"). Subscribing to the pattern of the OpenURL framework is a
voluntary act on the part of a URI assignment authority (the domain name
owner). Publishing an assignment policy which states that some or all of the
URI/resources published by that authority use a pattern such as the "The
OpenURL Framework" is another voluntary act by the assignment authority. The
caveat above is about the stability of a stated assignment policy within the
scope of a given URI assignment authority. It is not about the stability of
the specifications associated with "The OpenURL Framework", that is for
ANSI/NIST to state.

ANSI/NIST cannot state the meaning of an http: scheme URI query string
independent of the associated assignment authority. ie. it cannot 'usurp'
the meaning of query strings conforming to a pattern established in the
OpenURL framework across all http scheme URI assignment authorities. It can
put in place a pattern that they can, as a matter of policy, subscribe to.
But that assignment policy is not subject to standardisation by anybody - it
is at the sole discretion of the assignment authority what that policy is
and whether or not they publish it and what commitments they make to its
stability - modulo of course, "Cool URI's don't change".

IF OpenURL establish/register its own URI scheme, the assignment authority
for URI within that scheme is delegated from the URI spec to that scheme
specification. That scheme specification may retain assignment authority
itself or further delegate it as appropriate to fulfil the needs of the
scheme. The http URI scheme already exists. Assignment authority has been
delegated and I believe it has been delegated beyond the ability of any
other spec. from ANSI, ISO, IETF or W3C to cease authority back again, even
over some narrow subset of the URI administer by an http scheme URI
assignment authority. This is also the subject of siteData-36 [1].

Please let me know whether you still think that the caveat and the OpenURL
Framework remain in "direct opposition".

Many thanks,

Stuart Williams
--
[1] http://www.w3.org/2001/tag/ilist#siteData-36

> -----Original Message-----
> From: Hammond, Tony (ELSLON) [mailto:T.Hammond@elsevier.com] 
> Sent: 27 August 2003 12:48
> To: www-tag@w3.org
> Cc: uri@w3.org
> Subject: 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
> [2] http://www2.elsevier.co.uk/~tony/spec/rss/mod_context.html 
> [3] 
> http://library.caltech.edu/openurl/PubComDocs/StdDocs/Part1-PC
-20030513.pdf
[4]
http://library.caltech.edu/openurl/PubComDocs/StdDocs/Part2-PC-20030513.pdf
[5] 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>
<tel:+44-20-7424-4445>

Received on Wednesday, 3 September 2003 12:53:20 UTC