W3C home > Mailing lists > Public > www-rdf-interest@w3.org > November 2001

Re: Namespaces wihtout "#" Was: Few CWM Bugs

From: Graham Klyne <GK@ninebynine.org>
Date: Mon, 26 Nov 2001 16:59:11 +0000
Message-Id: <>
To: "Tim Berners-Lee" <timbl@w3.org>
Cc: <www-rdf-interest@w3.org>
At 10:39 AM 11/26/01 -0500, Tim Berners-Lee wrote:
>Fortunately, the fragment ID allows us to refer to something defined
>or described by the document, and that can be quite abstract.

Hmmm... this feels like an uncomfortable overloading of fragment identifier.

Before responding to this, I checked out your 
http://www.w3.org/DesignIssues/Fragment.html (which, BTW, has been updated 
recently but there's no record of the update)...

[Remaining quotes are from: http://www.w3.org/DesignIssues/Fragment.html]

>The fragment identifier is a string at the end of a URI which identifies,
>within a Web document, a part or view to which one refers.


>The significance of the fragment identifier is a function of
>the MIME type of the object

>Fragment identifiers for RDF identify concepts
>The semantic web has information about anything. The fragment identifier on
>an RDF (or N3) document identifies not a part of the document, but whatever
>thing, abstract or concrete, animate or innanimate, the document describes as
>having that identifier.

I have a couple of problems with this:
(a) this is rather at odds with the earlier definition of identifying 
something "within a web document".

(b) It's not clear to me that RDF is unequivocally associated with a MIME 
type.   What's the MIME type of RDF embedded in an XHTML document?

>It is important, on the  Semantic Web, to be clear about what is
>identified. An http: URI (without fragment identifier)
>necessarily identifies a generic document. This is
>because the HTTP server response about a URI can deleiver a rendition of (or
>location of, or apologies for) a document which is identified by the URI 
>requested.  A client which understands the http: protocol can immediately
>conclude that the fragementid-less URI is a generic document.  This is true
>even if the publisher (owner of the DNS name) has decided not to run a server.
>Even if it just records the fact that the document is not available online,
>still a client knows it refers to a document.  This means that identifiers for
>arbitrary RDF concepts should have fragment identifiers.  This in term means
>that RDF namespaces should end with "#".

[Aside:  this last bit is new new me;  it's very disconcerting when these 
ideas seem to pop out of the woodwork.]

>User awareness of the form of a reference
>Clearly when a fragment ID is generated and associated with a URI which is
>generic in any way (language, version, etc as well as content-type), then
>there is a possible failure of the fragment-id refers to something which is
>not defined in any specific instance.  It would be appropriate for a client,
>when generating a link (or bookmark, etc) to provide the user with a choice
>A bookmark to the whole living document, or
>A bookmark to a specific part of a "dead" version;
>Intermediate combinations.
>As both these options are meaningful and useful, they will have to surface
>at the user interface level.

Maybe this last point indicates part of the confusion I feel here:  with 
RDF, I think it's fair to say that that which is referenced does *not* have 
to surface at the UI level -- it's part of an identifier that may be 
exchanged between systems without regard for user presentation or 
containing document.

It seems to me that RDF uses fragment identifiers in a different way than 
web retrieval applications.  Is it really harmful to just say that RDF is 
different in this respect?  I can't help feeling that this attempt to fit 
RDF interpretation into some variant of the web browsing mould will 
generate more confusion than clarity.


Graham Klyne
Received on Monday, 26 November 2001 12:12:02 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:07:38 UTC