W3C home > Mailing lists > Public > www-rdf-interest@w3.org > October 2004

RE: URN as namespace URI for RDF Schema

From: Michael Steidl/MDir IPTC <mdirector@iptc.org>
Date: Tue, 05 Oct 2004 06:48:27 +0200
To: www-rdf-interest@w3.org
CC: Graham Klyne <GK@ninebynine.org>, "Hammond, Tony" <T.Hammond@nature.com>
Message-ID: <416243BB.884.1A91E1@localhost>

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:52:09 GMT