Re: [urn] Finalizing items from IETF 83

I think the goal is for URIs of the form urn:x#fragid to also have
URN-like properties, just as urn:x does., i.e. name-like and
persistent. RIght? And this appears to be in conflict with the fact
that the semantics of such URIs is determined by 3986, not by the URI
scheme registration.

I offer (again) the following compromise for your consideration; I
have no dog in this race:

If those registering namespaces want to constrain the semantics of
urn: URIs with fragment identifiers, it would be possible to do so
indirectly, by constraining the possible representations yielded by
URN resolver infrastructure.  E.g. if urn:x#part1 was supposed to name
part 1 of <urn:x>, then the registration could say (or imply) that a
resolver MUST only yield representations in which #part1 names part 1.

Or perhaps it would be OK to yield some representations in which
#part1 did not name anything at all. Then you would say: A resolver
MUST NOT yield a representation in which the semantics of #part1 is
inconsistent with  urn:x#part1 being a name for (whatever). Whether
this would work in one of the many unclear aspects of fragment
identifier semantics (see
http://www.w3.org/2001/tag/doc/mimeTypesAndFragids-2012-05-28.html ).

That is, per 3986, fragment id semantics depends on media types, so if
a spec wants to constrain fragment id semantics, its only option is to
do so indirectly, by constraining the representations to which the URN
resolves.

A weakness of this approach would be differentiating between
persistent fragment identifiers and ephemeral ones. If someone gets a
representation, and discovers a fragment identifier definition inside
it, they will have no way of knowing the persistence commitment of
that fragment identifier.

Best
Jonathan

On Fri, Jun 29, 2012 at 6:17 AM, "Martin J. Dürst"
<duerst@it.aoyama.ac.jp> wrote:
> On 2012/06/28 20:52, Juha Hakala wrote:
>
>> On 28.6.2012 13:01, Julian Reschke wrote:
>
>
>>> Namespace specifications define the namespace-specific part; nothing
>>> else. Fragment syntax and semantics are defined by RFC 3986.
>>>
>>> A spec *can* point out that the URN does not identify something from
>>> which a payload + media type can be retrieved, in which fragment
>>> identifiers are not applicable. But that's different from disallowing
>>> them.
>>
>>
>> OK. It should be possible to adjust the text in rfc2141bis to say that
>> there are namespaces in which fragment usage is not applicable since the
>> resources which can be identified within than namespace - say, textual
>> works as abstract entities in URN:ISTC - will not have fragments in the
>> RFC 3986 sense of the word.
>
>
> Strictly speaking, that's not true. It's perfectly possible to imagine (and
> even to set up, although that will require quite a bit of coordination) to
> have an identifier for "Much Ado about Nothing" and have fragment
> identifiers e.g. for Act I, II, III, IV, and V. These may not work with all
> resolution systems, or all representations, but that's not a problem. If a
> fragment identifier cannot be resolved, we just get the whole work. The only
> problem is when a fragment identifier leads to obviously different pieces in
> different representations (e.g. Act I in an XML representation and Act V in
> a mobi representation,...).
>
> All this isn't new for URNs, it's exactly the same as for content-negotiated
> HTTP resources (different languages, HTML vs. XML vs. SVG vs. JSON vs. RDF,
> just to name a few).
>
>
>
>> As far as I am concerned, it does no harm if the namespace registration
>> request confirms that it is possible to use fragment to augment the
>> functionality of the URNs from that particular namespace. For instance,
>> I asked a permission from the ISBN Registration Authority to use
>> fragments in the URN:ISBN namespace. Since this point will be made in
>> the namespace registration request the national ISBN agencies and other
>> ISBN users do not need to ask if fragments are allowed.
>
>
> Nobody should have to ask. If it works, you can use it. If you can't make it
> work, it's a bad idea.
>
>
>> And while some
>> examples could be given in the namespace registration request it is
>> definitely up to the URI Generic Syntax and other relevant technical
>> documents to provide the necessary details for each document format.
>
>
> Yes indeed.
>
> Regards,    Martin.
>
> _______________________________________________
> urn mailing list
> urn@ietf.org
> https://www.ietf.org/mailman/listinfo/urn