RE: The OpenURL - A Distinguished URI?

Stuart;

I agree with pretty much everything you write, but I have one additional 
suggestion for your consideration.  Would it make sense to say something 
along the lines of: 

"As described in draft Tag finding "The Use of Metadata in URIs"[1]:

"However, if the authority also publishes the syntax and semantics of the 
query parameters that it uses, 3rd parties may independently construct URI 
with particular semantic intent. 3rd parties that find such constructed 
URI useful will create content and applications that depend upon their 
structure. This will then either limit the freedom for the assignment 
authorities to evolve there site (modulo 'Cool URI's don't Change' 
[CoolURI]) without causing breakages elsewhere or it places a maintainence 
burden on the dependent applications and content."

"and perhaps more importantly:

"People and software using URIs assigned outside of their own authority 
should make as few inferences as possible about a resource based on its 
identity and inferences arising from delegated authority. The more 
dependencies a piece of software has on particular constraints and 
inferences, the more fragile it becomes to change and the lower its 
generic utility."

"Use of query string conventions such as OpenURL does not change these 
fundamental characteristics of the Web architecture.  The availability of 
a good, common convention for structuring query strings may be an 
important aid to those publishing authorities and clients who have good 
reason to explicitly manipulate or inspect the content of query strings; 
the availability of OpenURL should not in general encourage others to 
become dependent on the content or structure of particular URLs."

I think it might be appropriate to say something along these lines.  Thank 
you!

Noah

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

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------







"Williams, Stuart" <skw@hp.com>
Sent by: www-tag-request@w3.org
09/03/2003 12:05 PM

 
        To:     "'Hammond, Tony (ELSLON)'" <T.Hammond@elsevier.com>, www-tag@w3.org
        cc:     uri@w3.org, (bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        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 14:39:21 UTC