Re: [urn] fragment identifiers

On 3/10/11 7:12 AM, Julian Reschke wrote:
> On 10.03.2011 15:04, Juha Hakala wrote:
>> Hello,
>>
>> Julian Reschke wrote:
>>> On 10.03.2011 13:28, Juha Hakala wrote:
>>>> ...
>>>> Persistent identifiers will be used for multiple purposes, and by the
>>>> time we assign e.g. a URN to a resource, we have no idea which
>>>> resolution services will be needed in the (distant) future. Lifetime of
>>>> a PID may be centuries; applications and the functionality they offer
>>>> will change many times during such a period. And eventually even the
>>>> copyright protection of a document will expire ;-).
>>>> ...
>>>
>>> I think that statement in itself rules out use of fragment
>>> identifiers. At least if you want to stay in sync with the URI spec
>>> (RFC 3986).
>>
>> Can you explain why this would be the case? Please see below why I find
>> it difficult to agree.
>> ...
> 
> <http://greenbytes.de/tech/webdav/rfc3986.html#rfc.section.3.5>:
> 
> "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).

Peter

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