RE: URN as namespace URI for RDF Schema

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 Monday, 4 October 2004 19:54:24 UTC