- From: Aaron Swartz <me@aaronsw.com>
- Date: Thu, 14 Feb 2002 20:26:29 -0600
- To: Dan Connolly <connolly@w3.org>
- CC: RDF Core <w3c-rdfcore-wg@w3.org>
On 2002-02-14 3:08 PM, "Dan Connolly" <connolly@w3.org> wrote: >> I really can't agree with this. It's our problem that RDF uses this >> non-standard piece of Web architecture, and in doing so has incurred all >> sorts of problems. If we're going to be the Resource Description Framework, >> we need we're actually describing resources. My ideal resolution would look >> like: >> >> o The WG resolves that the use of absolute URIs with fragment IDs is a >> to identify Web resources is relatively incompatible with current Web >> architecture. > > ????? > > Er.. it's the very heart of web architecture: > > The principle that anything, absolutely anything, "on the Web" > should identified distinctly by an otherwise opaque string > of characters (A URI and possibly a fragment identifier) is > core to the universality. > > -- http://www.w3.org/DesignIssues/Architecture RFC2396 would agree with you except for the "and possibly a fragment identifier" bit. Same with Roy Fielding's dissertation (which clearly explains the reasons why this was an explicity design decision) and probably the many people who have invested in URI syntax, and don't want to go back and fix their HTTP clients, proxies, servers or other software (and maybe hardware) to support this addition of fragment identifiers. >> o We recommend that RDF users refrain from using '#' in their Resource >> identifiers and namespaces. RDF developers and tool creators may present >> a warning to the user when using resource identifiers with '#' in them. > > Why? rdf:type has a # in it, after all. How can they avoid it? > Why would they? Perhaps I wasn't clear. I meant ones that they were creating (like if I wanted to come up with a namespace for my new vocabulary set, or my poodle). > I don't see any explanation of a problem here. We've discussed it several times on and off list, but I could reitierate it for you. The issue is that: a) In the REST architectural model (which the TAG seems to be agreeing about) fragment identifiers only make sense within the context of an HTTP response (a bag of bits). They identify parts of a document, not general Resources like full URIs. b) Deployed code doesn't support fragment identifiers as first-class objects -- I can't ask an HTTP proxy about them, I can't query an HTTP server about them, etc. And this is by design... <MikeM> fragmetns are client side thing..... - in #rdfig Exactly! RDF has created this problem by taking what in Web Architecture is designed to be a client-side thing, the last step of resolution. TimBL explained this at the first W3C technical plenary: "[an HTTP client] puts the fragment ID in its pocket". Also, in his Axioms of Web Architecture: The Web Model[1], Tim explains how a client holds on to the fragment ID so that it can pass it to the presentation object. [1] http://www.w3.org/DesignIssues/Model He's even got a nice diagram to explain it. I'm not sure how much clearer it can be that a fragment only makes sense in the context of presenting a document. >> b) maintaining backwards-compatibility but >> c) lay the ground work for future WGs to fix this bug > What bug? The bug that RDF is incompatible with Web Architecture, as explained above. <MikeM> seriously, RDF's use of frags has caused so many problems.. If RDF needs something like it that badly then make it a new URI scheme that does it _right_ -- [ "Aaron Swartz" ; <mailto:me@aaronsw.com> ; <http://www.aaronsw.com/> ]
Received on Thursday, 14 February 2002 21:26:35 UTC