Re: [urn] fragment identifiers

On 3/11/11 3:40 AM, Graham Klyne wrote:
> 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/).

Yes, that makes sense. And clearly the semantics of fragment identifiers
in other technologies (e.g., HTML) are rather loose.

So perhaps one question to ask of the folks working in the URN space is:
what are the semantics of your manifest files (or whatever else might be
returned upon resolution of your URNs)?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/