W3C home > Mailing lists > Public > uri@w3.org > March 2011

Re: [urn] fragment identifiers

From: Graham Klyne <GK-lists@ninebynine.org>
Date: Fri, 11 Mar 2011 10:40:18 +0000
Message-ID: <4D79FC12.8060307@ninebynine.org>
To: Peter Saint-Andre <stpeter@stpeter.im>
CC: Julian Reschke <julian.reschke@gmx.de>, Juha Hakala <juha.hakala@helsinki.fi>, urn@ietf.org, "uri@w3.org" <uri@w3.org>
Peter Saint-Andre wrote:
>> "The semantics of a fragment identifier are defined by the set of
>> representations that might result from a retrieval action on the primary
>> resource. The fragment's format and resolution is therefore dependent on
>> the media type [RFC2046] of a potentially retrieved representation, even
>> though such a retrieval is only performed if the URI is dereferenced. If
>> no such representation exists, then the semantics of the fragment are
>> considered unknown and are effectively unconstrained. Fragment
>> identifier semantics are independent of the URI scheme and thus cannot
>> be redefined by scheme specifications."
>> I think this is pretty clear -- if you *can* have representations,
>> you're constrained by the media types that are used as representations.
>> There's no way avoiding that if you want to stay aligned with the URI spec.
> Another way to put it is that you can have representations or free-form
> semantics, but not both (because along with representations come the
> constraints of media types, according to RFC 3986).

I suppose it depends on what you mean by "free-form semantics".  For RDF, we 
weasel-worded our way out of this by linking the semantics of the 
URI-with-fragment to the RDF representation associated with the URI.

-- http://www.w3.org/TR/rdf-concepts/#section-fragID

So this is a form of semantics that is quite generic in its applicability, but 
it may not be what you mean by "free form", since it is bound to the semantics 
of RDF (http://www.w3.org/TR/rdf-mt/).

There's also some interesting W3C TAG discussion nearby...

... etc.

Received on Friday, 11 March 2011 14:20:58 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:14 UTC