RE: URN as namespace URI for RDF Schema

Well, Michael, it certinly is a tricky one. I take Graham's point about '#'
not being part of any URI scheme *as far as RFC 2396 is concerned*. RFC 2396
supported this view in distinguishing between 'URI-references' and 'URIs':

	URI-reference = [ absoluteURI | relativeURI ] [ "#" fragment ]

In fact, you might be surprised to learn that there was/is no single
production for a generic URI! Instead RFC 2396 deferred to URI schemes to
specify which components would be available to them. Although it did not
provide a URI production the closest it got to defining a generic URI syntax
was the following:

   This "generic URI" syntax consists of a sequence of four main components:

      <scheme>://<authority><path>?<query>

   each of which, except <scheme>, may be absent from a particular URI.

So clearly in RFC 2396 terms fragment does not belong to URI but to
URI-reference.

Now, however, the revision of this RFC (2396bis, currently verion -07 and
close to final call), see

	
ftp://ftp.ietf.org/internet-drafts/draft-fielding-uri-rfc2396bis-07.txt

normalizes these various constructs and does provide for a single, generic
URI production

	URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]

As you can see a fragment is an optional but integral component of all URI
schemes. The URN scheme as currently stands does not support either '/' or
'#' - although there's no reason not to now seek for a revision on that.
Note that we have been pursuing registration of a new URI scheme - INFO (see
http://info-uri.info/) - which is a kind of URN lite and that does allow for
both '/' and '#' characters - one of the shortcomings IMO of URNs. Of
course, one could just go ahead and use the URN for an RDF namespace without
the '/' or '#' chars.

Cheers,

Tony
 


> -----Original Message-----
> From: Michael Steidl/MDir IPTC [mailto:mdirector@iptc.org] 
> Sent: 05 October 2004 05:48
> To: www-rdf-interest@w3.org
> Cc: Graham Klyne; Hammond, Tony
> Subject: 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
> > 
> > 
> 
> 



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

Received on Tuesday, 5 October 2004 09:21:26 UTC