- From: Ralph R. Swick <swick@w3.org>
- Date: Mon, 27 Jun 2005 12:57:51 -0400
- To: Phil Tetlow <philip.tetlow@uk.ibm.com>
- Cc: SWBPD list <public-swbp-wg@w3.org>
At 11:35 AM 6/27/2005 +0100, Phil Tetlow wrote: >... If a URI contains # then >the producer/author absolutely expects the consumer to accept an >abstraction break at document level, And what's more, the HTTP specification says that there's abstraction boundary at '#' -- the document content type (aka MIME type) is the authority for instructing the consumer about the interpretation of the fragment identification (or sometimes known as "view"). >and so deliberately wants to convey a >document centric view of his/her world. I don't follow this particular point. For "information resources" of type application/rdf+xml, we SemWeb folk are free to specify [1] that fragment ids are one way of crossing the abstraction boundary from documents to arbitrary things, concepts, RDF Resources. But I don't follow how that implies that RDF has a "document centric" view of a world. [1] http://www.ietf.org/rfc/rfc3870.txt > If its slashes all the way then the >concept of document has deliberately been dispensed with, whether >information if dished up in the form of a document or not. But this should >be obvious. Not obvious to me at all. Indeed quite the opposite; the naive view feels more likely to me to be that slashes represent directories (or "folders" for the more-recently-innoculated) thus reinforcing a document orientation. But perhaps you mean to point out the trailing slash case, which would seem to more likely denote the contents of a folder (of documents), even to those who've never administered an apache server. > Situations where duality of definition and purpose exists are >more troubling ... where sometimes a >resource should be interpreted as a document and others merely as an >aggregate of useful information fragments. I think there's broader agreement on the inadvisability of multiple interpretations that you seem to feel. The TAG's current resolution appears to find a navigable path between a URI that names an information resource and a URI that does not -- but that never the less is still useful _in the deployed Web_ to return to the consumer some useful information. >So, if for no other reason than mediation and in the spirit of crazy ideas, >how about the notion of using a third URI constructor [to] explicitly denote the >situation outlined above, where the producer/author deliberately does not >need/want the consumer to take a particular view on the resource being >published. I'm somewhat uncomfortable with the higher level of abstraction to which you're attempting to take us here. I think it is important that some part of an author's intent be manifest -- and that the consumer thereby be able to hold an author/publisher accountable for it. However, I am _very_ concerned about the practical deployment issues of your abstraction in the Web. It seems to me that where there are architecturally acceptable solutions that work with today's deployed Web we should give those solutions much higher preference. -Ralph
Received on Monday, 27 June 2005 16:58:06 UTC