Re: Using fragment identifiers with URNs

On Thu, Sep 27, 2001 at 01:10:23PM +1200, Stephen Cranefield wrote:
> Roy Fielding wrote:
> 
> > It is possible to use a URN to perform a retrieval action, so I don't
> > follow your argument.  Just because the action isn't implied 
> > doesn't mean
> > that the identifier can't be used in performing the action explicitly.
> 
> Yes, but that would be making an application-level assumption, whereas
> the generic syntax and meaning of URIs and URI references should be
> independent of any particular application.  Basically, my point is that
> perhaps the definition of URI references should be updated to explicitly
> state that the notion of retrieval is specific to the URI scheme, and
> that URN schemes are not required to have any retrieval mechanism defined.

The notion of retrieval is not in any way specific to the URI scheme --
there is a paragraph in RFC 2396 that says exactly that, regardless of
whether it is a locator or a name.  The scheme only defines a namespace.
And a URN can be used for retrieval and thus can be used with a fragment.
However, the fragment is NOT part of the URN -- it is a separate name.

> To add a fragment identifier to a URN that represents an abstract name
> would be misleading - it would be making an assumption that there *is* some
> retrieval mechanism defined for that URN scheme.

The retrieval mechanism is defined by the application, in all cases,
regardless of URI scheme.

> To clarify my previous post, consider two different types of URN.
> First, consider Digital Object Identifiers (which will
> presumably one day become a registered type of URN):
> 
>   The DOI .... is simply one element of a complex system. ...
>   A user can use a DOI to do something. The simplest action that a user
>   can perform using a DOI is to locate the entity that it identifies.  
>   (From http://www.doi.org/handbook_2000/what_is_a_doi.html)
> 
> URLs have this property too: they are defined in the context of a
> distributed system architecture (the infrastructure of the Web) which
> defines what it means to retrieve information using a URL.
> 
> Now, suppose I develop a URN scheme that I intend to use for naming
> classes and properties in an RDF schema, and I intend URIs in this
> scheme to be unique identifiers of concepts, but not references to
> their definition in a schema (I can use rdfs:isDefinedBy to convey that
> information).  Given the current definition of a fragment identifier,
> it would not be appropriate to use a fragment identifier with one of
> these URNs.  The very use of a fragment identifier is making an
> assumption that the URN is intended as a reference that can be used
> for retrieval - which is not true in this case.

Yes.  So don't use a fragment in those cases.  There is no reason to change
the protocol element just because it might be used in an illogical fashion.
There are millions of other variations on the URI syntax which wouldn't make
sense in that situation either.

Someone else has requested an additional protocol element for "possibly
relative URI reference without fragment", which I imagine will be added to
the next revision just to make it easier for protocol authors to pick and
choose what parts of the BNF they want to reuse in other specs.  But I assume
that is not what you want for this case.

> I am not denying that the URI reference syntax is convenient
> and could be usefully extended to apply to names as well as
> locators, but that would require broadening the current definition.

The syntax applies to names already -- I doubt that it can get any broader.

....Roy

Received on Wednesday, 26 September 2001 21:36:40 UTC