RE: The OpenURL - A Distinguished URI?

just a note- it's NISO, not NIST!

"direct opposition" is probably the wrong term to use. It's more of 
an "orthogonal opposition", if such a thing is possible.

Eric


At 5:05 PM +0100 9/3/03, Williams, Stuart wrote:
>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>
>
>


-- 

Eric Hellman, President                            Openly Informatics, Inc.
eric@openly.com                                    2 Broad St., 2nd Floor
tel 1-973-509-7800 fax 1-734-468-6216              Bloomfield, NJ 07003
http://www.openly.com/1cate/      1 Click Access To Everything

Received on Wednesday, 3 September 2003 15:09:13 UTC