URNs and fragments (was: URN as namespace URI for RDF Schema)

[Moved to URI list, since this is not really an RDF issue.  To URI list 
members who haven't seen the earlier discussion, it's to do with fragment 
identifiers and URNs. #g]

I think the new URI spec is pretty clear on this.  It think it might be 
worth clarifying the URN scheme syntax spec if/when it comes round for 
revision.

#g
--

At 06:48 05/10/04 +0200, Michael Steidl/MDir IPTC wrote:
>Graham, Tony,
>
>good to see that this fragment identifier issue is ambiguous not only for us.
>Would strongly support to have this clarified at the level of 
>specifications -
>not only as "best practice".
>
>Michael
>
>On 4 Oct 2004 at 20:54  Graham Klyne wrote:
>
> > Tony,
> >
> > Thanks for pointing that out.
> >
> > My immediate thought is that RFC2141 is "exceeding its authority" as a URI
> > scheme definition, but, IIRC, that RFC was written before the general
> > consensus (as I perceive it) emerged that URNs are just another kind of 
> URI.
> >
> > I guess this is something that should probably be clarified in the wake of
> > the revised URI specification [1] that's about to be (or is being) 
> last-called.
> >
> > Another way of looking at this is that an (unescaped) '#' cannot be a part
> > of *any* URI scheme, so in that respect there's nothing special about
> > URNs.  I think I prefer that view.
> >
> > #g
> > --
> >
> > [1] http://gbiv.com/protocols/uri/rev-2002/rfc2396bis.html:
> >
> > (Note the final sentence below...)
> >
> > [[
> > 3.5 Fragment
> >
> > The fragment identifier component of a URI allows indirect identification
> > of a secondary resource by reference to a primary resource and additional
> > identifying information. The identified secondary resource may be some
> > portion or subset of the primary resource, some view on representations of
> > the primary resource, or some other resource defined or described by those
> > representations. A fragment identifier component is indicated by the
> > presence of a number sign ("#") character and terminated by the end of 
> the URI.
> >
> >     fragment    = *( pchar / "/" / "?" )
> >
> > 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, effectively, unconstrained. Fragment identifier
> > semantics are independent of the URI scheme and thus cannot be 
> redefined by
> > scheme specifications.
> > ]]
> >
> >
> > At 17:30 04/10/04 +0100, Hammond, Tony wrote:
> >
> > >Hi Graham:
> > >
> > > > It's true that URN's don't (strictly) allow '/' signs, but
> > > > they do not
> > > > prohibit '#' signs, as the fragment is not part of the main URI.  See
> > > > http://www.w3.org/DesignIssues/Model.html for some
> > > > discussion.  You could
> > > > include an escaped (using %hh) '/' in a URN.
> > > >
> > >
> > >This from RFC 2141 (both "/" and "#" are reserved chars):
> > >
> > >http://www.ietf.org/rfc/rfc2141.txt
> > >
> > >2.3.2 The other reserved characters
> > >
> > >    RFC 1630 [2] reserves the characters "/", "?", and "#" for particular
> > >    purposes. The URN-WG has not yet debated the applicability and
> > >    precise semantics of those purposes as applied to URNs. Therefore,
> > >    these characters are RESERVED for future developments.  Namespace
> > >    developers SHOULD NOT use these characters in unencoded form, but
> > >    rather use the appropriate %-encoding for each character.
> > >
> > >Cheers,
> > >
> > >Tony
> > >
> > >
> > >
> > >*********************************************************************** 
> *********
> > >DISCLAIMER: This e-mail is confidential and should not be used by anyone
> > >who is not the original intended recipient. If you have received this
> > >e-mail in error please inform the sender and delete it from your mailbox
> > >or any other storage mechanism. Neither Macmillan Publishers Limited nor
> > >any of its agents accept liability for any statements made which are
> > >clearly the sender's own and not expressly made on behalf of Macmillan
> > >Publishers Limited or one of its agents. Please note that neither
> > >Macmillan Publishers Limited nor any of its agents accept any
> > >responsibility for viruses that may be contained in this e-mail or its
> > >attachments and it is your responsibility to scan the e-mail and
> > >attachments (if any). No contracts may be concluded on behalf of 
> Macmillan
> > >Publishers Limited or its agents by means of e-mail communication.
> > >Macmillan Publishers Limited Registered in England and Wales with
> > >registered number 785998 Registered Office Brunel Road, Houndmills,
> > >Basingstoke RG21 6XS
> > >*********************************************************************** 
> *********
> >
> > ------------
> > Graham Klyne
> > For email:
> > http://www.ninebynine.org/#Contact
> >
> >

------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact

Received on Tuesday, 5 October 2004 10:04:53 UTC