- From: Richard Cyganiak <richard@cyganiak.de>
- Date: Mon, 1 Jan 2007 17:22:49 +0100
- To: Frank Manola <fmanola@acm.org>
- Cc: SWIG <semantic-web@w3.org>
Frank, On 30 Dec 2006, at 18:48, Frank Manola wrote: >> On 29 Dec 2006, at 18:15, Frank Manola wrote: >>> It seems to me that whether or not one feels that httpRange-14 >>> adequately addresses the general disambiguation issue, this >>> approach encodes useful metadata about the resource (an opinion >>> as to whether all the essential characteristics of this resource >>> can be encoded in a message that we can send over the network) in >>> a server response, rather than declaratively (e.g., in OWL). >> >> First, your claim that this is non-declarative is silly. I'm sure >> you know this and were just sloppy in your choice of terms. > > Well, possibly silly or sloppy, but I'm always willing to > learn :-) Certainly if you have to invoke a procedure (in this > case, to dereference the URI) and evaluate the response, it doesn't > seem "declarative" in the same sense as simply having an OWL > statement to the effect that the URI does or doesn't have certain > characteristics. Nah, I'm not convinced. Are you really simply "having" OWL statements? Or do you actually have to invoke a procedure (an API call or triple store lookup or even -- gasp -- an HTTP request) to get hold of the statement? I think we lack a clear definition of what "declarative" means ... It's a bit of a weasel word. Just like "semantic". >> Second, arguably this bit of metadata is exactly where it should >> be. It is transfer metadata after all. The distinction between >> information resources and non-information resources is not >> relevant to most application domains, but is relevant to the >> question of moving representations over the network. > > I agree with your "arguably"! My main point is that, whatever you > think about httpRange-14, there's no reason to not also have that > same kind of metadata available in OWL. For me, parsimony would be a reason. > For one thing, if they find it useful people will develop their own > OWL to record it anyway, along with various amplifications that > have been suggested (e.g., imaginary resources, if that's a > distinction you're concerned about). > > But I also think you're taking a rather strict interpretation of > the distinction between information resources and non-information > resources as being only a transfer-layer issue about moving > representations over the network in considering the significance of > this. That is, if I remember correctly, the original issue was > about determining whether a URI named a car or a document about the > car (for example). The idea of an information resource was > introduced to help in this disambiguation. So now http can tell me > whether I'm directly referring to an information resource, or > whether I'm possibly referring to something else. And now this may > sound like a strictly transfer-layer distinction. But it seems to > me I may well be interested at higher layers in what this > distinction is (or at least may be) encoding (does this URI name > the W3C, or its web page?). Does this URI name the W3C, or its web page? That's a really fundamental question on the transfer layer. But on the data layer, it's just one of any number of distinctions. Does this URI name the W3C, or its director? RDF already provides everything you need to deal with all these distinctions. My point, I guess, is that the transfer layer is lower than RDF, and therefore a different mechanism is needed if the distinction matters in the general web architecture. In the general case, the 303 issue can be handled within the transfer layer, and the data layer can be kept free of all those weird esoteric issues like info vs. non-info resources, HTTP status codes and so on. I think that many developers would be rather happy if this was handled transparently at a lower layer. That's my motivation really -- keeping a low-level issue from leaking into the RDF/OWL. (But of course you might reasonably *want* to know the low-level things in RDF/OWL; I don't want to stop you from doing that, so we don't really disagree.) Richard > > Cheers. > > --Frank > > > > >
Received on Monday, 1 January 2007 16:23:03 UTC