W3C home > Mailing lists > Public > www-rdf-interest@w3.org > September 2004

RE: web proper names redux

From: Hammond, Tony <T.Hammond@nature.com>
Date: Tue, 28 Sep 2004 11:11:42 +0100
Message-ID: <125F7834E11A5741A7D79412EE3504F90CE55950@UK1APPS2.nature.com>
To: "'Thomas B. Passin'" <tpassin@comcast.net>, www-rdf-interest@w3.org
Cc: ht@inf.ed.ac.uk

Hi Tom:

Yes, I may have shot the original mail off too quickly as I see Patrick's
MT qualifier now. However, I am still at a loss to know as to where in MT
there is any mention of URI opacity (or not) - I just checked. (BTW, why are
we talking about MT? Surely this doc has been superseded by the new crop of
recs earlier this year?)

My point anyway is not that a generic RDF processor should be able to
interpret URI structure (apart from validating that it is a URI, of course)
but rather to say that certain URIs besides exposing the generic URI syntax
can also expose public data if there is a standard public specification for
the URI syntax. Applications - RDF or otherwise - are free to interpret this
data as they so choose.

I still don't buy the notion that URI's are fully opaque wrt their
structure. (They are of course opaque wrt network endpoints.)

Cheers,

Tony

> -----Original Message-----
> From: www-rdf-interest-request@w3.org 
> [mailto:www-rdf-interest-request@w3.org] On Behalf Of Thomas B. Passin
> Sent: 28 September 2004 01:19
> To: www-rdf-interest@w3.org
> Cc: ht@inf.ed.ac.uk
> Subject: Re: web proper names redux
> 
> 
> 
> Hammond, Tony wrote:
> >>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
> 
> Patrick specifically qualified the remark you quoted above by 
> restricting it to the RDF Recs.  Any parsing of URLs is above 
> and beyond 
> what a conformant RDF processor is required to do.  There is 
> nothing to 
> prevent you from parsing out a uri and using the results to 
> add triples, 
> and it might even be very useful sometimes, but it's not 
> provided for by 
> RDF.  And why should it be?  At present, RDF has no mechanism to 
> incorporate any specific uri into itself, no matter how 
> useful it might 
> be.  I don't see a good reason to integrate in a specific uri scheme 
> that can be parsed, when we can't integrate any uris, period.
> 
> Cheers,
> 
> Tom P
> 
> -- 
> Thomas B. Passin
> Explorer's Guide to the Semantic Web (Manning Books) 
> http://www.manning.com/catalog/view.php?book=passin
> 



********************************************************************************
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 Tuesday, 28 September 2004 10:12:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:52:09 GMT