- From: Graham Klyne <GK@ninebynine.org>
- Date: Mon, 26 Nov 2001 16:59:11 +0000
- 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. [...] >Axiom >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 >of >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. #g ------------ Graham Klyne GK@NineByNine.org
Received on Monday, 26 November 2001 12:12:02 UTC