Re: URI for abstract concepts (domain, host, origin, site, etc.)

Dan Brickley wrote:
> On 26/6/09 18:54, Larry Masinter wrote:
>   
>> # They aren't being treated differently. The normal syntax for naming
>> # something in RDF is a URI reference with a fragid attached. The use of
>> # a fragID cancels any assumptions that the URIreference denotes
>> something connected with the HTTP protocol.
>>
>> How does it do that?
>>
>> # This is how RDF manages to
>> # refer to galaxies, chemical elements, people, etc..
>>
>> Sounds like this is only in the context of RDF.
>>     
>
> Yes and no.
>
>
> Here's the "Yes": the idea is that if content is served as 
> application/rdf+xml then the meaning of #foo is delegated to the 
> relevant spec (http://www.w3.org/2001/sw/RDFCore/mediatype-registration 
> ? humm that's expired). The RDF mediatype doc says
>
> """Section 4.1 of the URI specification [6] notes that the semantics
>     of a fragment identifier (part of a URI after a "#") is a property of
>     the data resulting from a retrieval action, and that the format and
>     interpretation of fragment identifiers is dependent on the media type
>     of the retrieval result.
>
>     However, in RDF, the thing identified by a URI with fragment
>     identifier does not bear any particular relationship to the thing
>     identified by the URI alone.  This differs from some readings of the
>     URI specification [6], so attention is recommended when creating new
>     RDF terms which use fragment identifiers."""
>
> Here the "No": A URI that points to an RDF document constructed in this 
> fashion, is (according to those persuaded this story works) supposed to 
> be a URI for whatever galaxy, chemical element, person etc. the RDF is 
> structured to represent.
>
> In this way, http://danbri.org/foaf.rdf#danbri is a URI for me. Not just 
> for RDF applications, but for any applications that care about the idea 
> of URIs being URIs *for* things. The media-type registration that makes 
> this so RDF-specific (RDF/XML-specific even) but the URI is supposed to 
> be a URI for me, full stop, rather than "a URI for me, in RDF applications".
>   
I don't think an RDF node is determined by the fragment identifier but 
rather by the entire URI.  The case for other mime-types are different. 

Hence, all RDF parsers have, in fact, not using the intended meaning of 
a URI by a URI owner as it is defined because I do not think they can 
manipulate a person.  What they can manipulate is an RDF node with that 
person's name.  This is an ambiguity issue that has not been brought 
into light because of the implicit context.  But once someone intends to 
describe the inner working of an RDF parser, I think the issue is bound 
to show up. 
> At this point people normally bring up the possibility of clashes across 
> content-negotiated representations served at the same URI. The usual 
> answer offered by return is "if that hurts, don't do it".
>   
There should not be.  I have trying this many times.  A URI, fragmented 
or not, denotes one thing and its returned representations another.  The 
former is the content of the later.  The remedy is to define a URI 
syntax for representation. 

A syntax that I have proposed is to insert a (mime-type) after the # sign.

Thus,

"http://danbri.org/foaf.rdf#danbri" denotes a person.
"http://danbri.org/foaf.rdf#(application/rdf+xml)danbri" denotes an RDF 
node.
"http://danbri.org/foaf.rdf#(application/xhtml+xml)danbri" denotes an 
HTML element ided "danbri

When a URI owner uses content negotiation, they should make the content 
of each representation consistent.  Of course, there could be 
inconsistencies if a user is not careful.  But it is no different from 
the case when someonelse makes an inconsistent statement about 
"http://danbri.org/foaf.rdf#danbri".  Inconsistent resources (whether it 
is caused by the same root-URI owner or not) will simply not be used 
(i.e., linked) by others, hence eventually die of isolation. 

This is the same old story from the httpRange-14.  Once we straighten 
that out, all other problems are very easy to answer.

Xiaoshu

Received on Friday, 26 June 2009 18:50:13 UTC