- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Fri, 6 May 2005 18:43:39 -0700
- To: Harry Halpin <hhalpin@ibiblio.org>
- Cc: W3C TAG <www-tag@w3.org>
On May 6, 2005, at 5:19 PM, Harry Halpin wrote: > First, yes - information resources can be ambiguous on some level. > I think many people would argue that they are representations encoded > as bits (information resources) are *less ambiguous* than URIs that > I belive represent Tim Bray, but when I go to that URI I get either > his blog or a 404 error. I am having trouble parsing those sentences. Representations are usually encoded as bits, which doesn't say anything about how the resource is implemented. "ongoing" is encoded as HTML and at least one RSS, neither of which says anything about what "ongoing" is really about (the content as written over time). It will still be "ongoing" when Tim adds an Atom 1.0 feed. The only way that an observer is going to know what "ongoing" actually identifies is if additional information is given, such as additional assertions, english descriptions, rumors obtained from other sources, etc. A computer cannot simply perform a GET and assume that what it got back is wholly descriptive of the resource -- it almost never is for websites, so why should that be any different for non-information resources? > If I want to share the information resource, then I just tell my > friend the URI, and if he has any questions about it, he HTTP GETs a > representation of it. The question I believe is what to do when > there's no obvious representation of the resource at hand. All you did was share a reference to the resource. You can do that just as easily with people by giving a contextually sufficient name (e.g, "Tim Bray" is sufficiently unique for this forum) or any URI with an N:1 mapping to that resource (e.g., "http://www.tbray.org/ongoing/misc/Tim") provided that the statement you make clarifies whether you are referring to Tim, Tim's page, Tim's image on that page, or perhaps even a google advert placed on Tim's page. The same disambiguation is needed for references to "http://www.tbray.org/ongoing" when people make statements about the blog, the HTML page version of the blog, the blog as it appeared on 20040630T1900, the random image selected for one day of the blog, etc. Each of those things are individual resources that could have their own URI, but people are going to use the "http" URI to refer to them because that is the most useful and permanent link that they know. > The key sentence you said is that: >> on the Web. Those people are wrong -- there are millions of >> abstractions represented on the Web right now and they aren't >> going to go away just to make it easier for computers to do AI. > That's the point: these *abstractions* are being *represented*. The > question is not *are* they being represented, the question is *how*. Why is that any of our business? > Right now there are virtually little to no guidelines in this area. > If I have a SemWeb ontology and I want to refer to "Tim Bray" qua > person, > I can pick a http:// URI and just do make my statements about that URI. > However, should I take his photo and put it at that URI? Leave that URI > empty and get a 404 error? Or should I using content-negotiation serve > RDF? Or should I just point that URI to his blog? And how does someone > or a machine besides me, perhaps someone with less statements about > that URI in RDF, know what the heck that URI means? This are not > insufficient solutions, but actual questions the TAG could answer. The same way it finds out what any URI means. You cannot discover meaning by performing a GET on a URI. You need to be able to read what the provider promises, assume via its context, gather from its use by other link authors, or (if you are very lucky) read what the owner asserts about the URI in RDF, N3, OWL, etc. That is true of any resource. People who simply perform a GET on a resource don't discover its meaning -- they only discover a snapshot in time. The most important characteristic of a resource is its future behavior. > Getting to the heart of this would allow people to do *exactly* what > you describe: >> My personal favorite is to make the relations specific about >> whether they refer to the resource or a set of representations, >> which is something that can be done in a definitional sense >> without changing any of the technology [though it would help a >> great deal if the technology supported temporally-qualified >> assertions]. That way, people and machines don't need to >> create ambiguous assertions in the first place. > > That is what some people are advocating, and only some are advocating > changing a URI scheme or adding hashes. Personally, my > favorite is to settle for a standard XHTML human readable > representation (ala RDDL) for the non-information resource, and then > use content negotiation to serve RDF/XML. This not only makes the > relations specific, but does so in a human and machine-readable > manner. I don't see how > this breaks http, and perhaps you could convice me that this does. Content negotiation on every resource is not a viable solution because it interferes with caches. All you need is a link from any given resource to the resource that describes it. A simple hypertext relationship, like any other, that can be defined either internally (HTTP header fields) or externally (linkbases, metadata stores, RDF worlds, etc.). The resource that describes it can be represented by any appropriate data format of its own, and it too may have link(s) to other resources that describe it. ....Roy
Received on Saturday, 7 May 2005 01:43:56 UTC