RE: URN as namespace URI for RDF Schema

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
> 
>

Received on Tuesday, 5 October 2004 04:48:11 UTC