Re: [Handle-info] [news] W3C TAG publishes "finding" on Metadata in URIs (w3.org)

["Hammond, Tony" <t.hammond@nature.com>]

Thanks for posting this Tag Finding on "The Use of Metadata in URIs", John.
(Am taking the liberty of CC'ing this to the OpenURL mailing list as it will
be of interest to that community as well.)

Let's hope that the TAG will catch up (eventually) to the wider world which
incorporates libraries and publishers.

This from AWWW, Sec. 2.5:
http://www.w3.org/TR/webarch/#uri-opacity

"Some URI assignment authorities document and publish their URI assignment
policies. For more information about URI opacity, see TAG issues
metaDataInURI-31 and siteData-36."

There are already published information standards (well, at least one) on
minting URIs with explicit metadata encoded in the URI string, see the US
information standard ANSI/NISO Z39.88-2004 on the OpenURL Framework:

    http://www.niso.org/standards/resources/Z39_88_2004.pdf

And note that this transcends individual assignment authorities but rather
sets out a standardized prescription for producing and consuming URIs with
metadata payloads (or at least URI querystring components). It is very
unfortunate that the TAG is either not aware of this work, or else chooses
not to acknowledge it.

Also, this phrase in the current TAG Finding document caught my eye:

    "The first question is primarily of concern to URI assignment
authorities, who must choose a suitable URI for each resource they
control."

This would seem to indicate some kind of confusion between resources and
representations. There is no requirement that a URI assignment authority
"control" the resources that they identify. See e.g. this:

W3C Recommendation, RDF Primer, Sec. 2.1
http://www.w3.org/TR/rdf-primer/

    "In fact, a URI can be created to refer to anything that needs to be
referred to in a statement, including

    * network-accessible things, such as an electronic document, an image, a
service (e.g., "today's weather report for Los Angeles"), or a group of
other resources.
    * things that are not network-accessible, such as human beings,
corporations, and bound books in a library.
    * abstract concepts that do not physically exist, such as the concept of
a "creator"."

And also this:

RFC 3986 - URI Generic Syntax, Sec. 1.2.2
http://www.ietf.org/rfc/rfc3986.txt

    "Although many URI schemes are named after protocols, this does not
   imply that use of these URIs will result in access to the resource
   via the named protocol.  URIs are often used simply for the sake of
   identification.  Even when a URI is used to retrieve a representation
   of a resource, that access might be through gateways, proxies,
   caches, and name resolution services that are independent of the
   protocol associated with the scheme name."

I do hope especially that users of OpenURL will spread the news of the
Z39.88-2004 information standard ever wider so that others may become aware
of this work and its relevance to the wider web architecture.

Cheers,

Tony




On 4/1/07 17:27, "John Erickson" <john.erickson@hp.com> wrote:4/1/07 17:27

> See: http://tinyurl.com/ydd9yf (w3.org)
> 
> The use of Metadata in URIs
> TAG Finding 2 January 2007
> 
> This finding addresses several questions regarding Uniform Resource
> Identifiers (URIs). Specifically, what information about a resource can
> or should be embedded in its URI? What metadata can be reliably
> determined from a URI, and in what circumstances is it appropriate to
> rely on the correctness of such information? In what circumstances is it
> appropriate to use information from a URI as a hint as to the nature of
> a resource or its representations? Simple examples are used to explain
> the tradeoffs involved in employing such metadata in URIs...
> 
> :
> 
> The first question is primarily of concern to URI assignment
> authorities, who must choose a suitable URI for each resource they
> control. The other questions are focused on people and software making
> use of URIs, whether at the resource authority or elsewhere. Of course,
> the questions are related insofar as one reason for an authority to
> encode metadata is for the benefit of resource users.
> 
> The TAG has earlier published a finding Authoritative Metadata
> [AUTHMETA], which explains how to determine correct metadata in cases
> where conflicting information has been provided. This finding is
> concerned with just one possible means of determining resource metadata,
> i.e. from the URI itself. The TAG publication [AWWW] discusses related
> issues under the heading of URI Opacity; this finding provides
> additional detail and guidance on the encoding of metadata into URIs,
> and on when it is or isn't appropriate to attempt to infer metadata from
> a URI...
> 
> 
> _______________________________________________
> Handle-Info mailing list
> Handle-Info@cnri.reston.va.us
> http://www.handle.net/mailman/listinfo/handle-info

********************************************************************************   
DISCLAIMER: This e-mail is confidential and should not be used by anyone who is
not the original intended recipient. If you have received this e-mail in error
please inform the sender and delete it from your mailbox or any other storage
mechanism. Neither Macmillan Publishers Limited nor any of its agents accept
liability for any statements made which are clearly the sender's own and not
expressly made on behalf of Macmillan Publishers Limited or one of its agents.
Please note that neither Macmillan Publishers Limited nor any of its agents
accept any responsibility for viruses that may be contained in this e-mail or
its attachments and it is your responsibility to scan the e-mail and 
attachments (if any). No contracts may be concluded on behalf of Macmillan 
Publishers Limited or its agents by means of e-mail communication. Macmillan 
Publishers Limited Registered in England and Wales with registered number 785998 
Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS   
********************************************************************************

_______________________________________________
Handle-Info mailing list
Handle-Info@cnri.reston.va.us
http://www.handle.net/mailman/listinfo/handle-info