- From: Pat Hayes <phayes@ai.uwf.edu>
- Date: Fri, 15 Feb 2002 16:53:45 -0500
- To: Aaron Swartz <me@aaronsw.com>
- Cc: 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. Wait a minute. Are you saying that every 'genuine' resource must be an document?? And that part of a document cannot be a resource??? That is an impossibly narrow view of 'resource'. >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. RDF hasn't done it. The entire SW effort needs this. DAML and OWL need this. We all need this. >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. This is an impossibly narrow HTML-centric view of the world. There are more things on the Web than just DOCUMENTS. Pat -- --------------------------------------------------------------------- IHMC (850)434 8903 home 40 South Alcaniz St. (850)202 4416 office Pensacola, FL 32501 (850)202 4440 fax phayes@ai.uwf.edu http://www.coginst.uwf.edu/~phayes
Received on Friday, 15 February 2002 16:53:43 UTC