- From: Williams, Stuart <skw@hp.com>
- Date: Wed, 3 Sep 2003 17:05:50 +0100
- To: "'Hammond, Tony (ELSLON)'" <T.Hammond@elsevier.com>, www-tag@w3.org
- Cc: uri@w3.org
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:19 UTC