RE: web proper names redux [Mea culpal]

Hi:

Apologies - I see that I should retract the first quote I provided. The URI
Opacity section in AWWW is concerned primarily with inferring
characteristics of the resource from the URI syntax. This is true.

What I was attempting (clumsily) to address was that one can meaningfully
interpret information embedded within a URI string - if there is a public
specification for so doing. Hence a URI need not be opaque with regard to
information transfer, although it remains opaque with regard to any
representations that it can be dereferenced to.

Tony

> -----Original Message-----
> From: www-rdf-interest-request@w3.org 
> [mailto:www-rdf-interest-request@w3.org] On Behalf Of Hammond, Tony
> Sent: 27 September 2004 15:05
> To: 'Patrick.Stickler@nokia.com'; hhalpin@ibiblio.org; 
> www-rdf-interest@w3.org
> Cc: ht@inf.ed.ac.uk
> Subject: RE: web proper names redux
> 
> 
> 
> > This isn't really a "solution" at the RDF level, since URIs
> > are fully opaque, and thus, one is not licensed to examine 
> > the URI scheme to make decisions regarding the meaning of a 
> > given URI, insofar as the RDF MT is concerned. True, some 
> > people do that, but that is non-conformant and potentially 
> > dangerous behavior for a SW client.
> 
> This actually should not go unchallenged - it is simply 
> incorrect - see 
> 
> 	http://w3.org/TR/webarch/#uri-opacity
> 
> 	"Good practice: URI opacity
> 
> 	Agents making use of URIs SHOULD NOT attempt to infer 
> properties of the referenced resource except as specified by 
> relevant specifications."
> 
> and
> 
> 	"Some URI assignment authorities document and publish 
> their URI assignment policies."
> 
> A good example of this is "The OpenURL Framework" which is 
> (proposed) ANSI/NISO information standard Z39.88, see
> 
> 	http://library.caltech.edu/openurl/Standard.htm
> 
> This defines a public data model in support of 
> context-sensitive services and a public registry for core 
> components used by the data model (e.g. identifier 
> namespaces, metadata formats, etc.). Two serializations are 
> defined by the draft standard - an HTTP(S) URI querystring, 
> and an XML document. (Other serializations for the data model 
> - eg RDF/XML - are possible. An RSS 1.0 module 'mod_context' 
> has alreay been published.) The
> (proposed) standard thus provides a public prescription for 
> building HTTP(S) URI querytrings. An OpenURL in the wild can 
> be recognized by a defined token, and further can be 
> validated to prove conformancy with the data model.
> 
> Thus an OpenURL (i.e. in URI form) is not opaque at the 
> querystring level since there is a relevant public 
> specification - Z39.88.
> 
> Cheers,
> 
> Tony
> 
> 
> Tony Hammond
> 
> New Technology, Nature Publishing Group
> 4 Crinan Street, London N1 9XW, UK 
> 
> tel:+44-20-7843-4659
> mailto:t.hammond@nature.com
> 
> 
> 
> 
> 
> 
> **************************************************************
> ******************
> 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
> **************************************************************
> ******************
> 
>

Received on Monday, 27 September 2004 15:13:29 UTC