Re: [urn] fragment identifiers

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...

http://www.w3.org/TR/webarch/#fragid
http://www.w3.org/2001/tag/doc/abstractComponentRefs
http://lists.w3.org/Archives/Public/www-tag/2010Nov/0000.html
... etc.

#g

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