- From: Mark Baker <distobj@acm.org>
- Date: Thu, 4 Nov 2004 12:37:07 -0500
- To: David Orchard <dorchard@bea.com>
- Cc: public-ws-addressing@w3.org
Hi David, On Thu, Nov 04, 2004 at 09:07:23AM -0800, David Orchard wrote: > > Mark, > > There's a big difference between GETting the state of a resource (which > may or may not be a metadata resource), GETting the metadata of a > resource (which may or may not be a metadata resource), and GETting the > state of a metadata resource. Well, as you've done there, all are expressable in terms of "GET". There are differences certainly, but I don't see why those differences must be manifested in the interface ... > There are only 2 solutions to GET > metadata about a resource that you don't know is a metadata resource: > either have 2 different operations (GET state and GETMETADATA state) or > have mechanism to convert an identifier into a metadata URI (URI += > "?WSDL" ? ). I count at least four. Add; - enable a representation of a resource to tell you that it's the metadata for some other resource - enable a representation of a resource to tell you that some other resource is its metadata resource I was talking about the latter when I suggested a standardized "metadata" term, but the former may also have value. I don't believe either of those two options you outlined are particularly attractive because I don't believe the "meta" relationship is special. Consider that WebDAV once thought that "properties" were special and so minted a new HTTP method called PROPFIND. But that's now generally regarded as a mistake, and that GET should have been used instead. > To a great deal, http-range-14 is TimBL's attempt to make all http: > resources into metadata so as to avoid the 2 verb problem for the > semantic web. Interesting perspective, but I disagree. Tim's very much a proponent of a single "gimme data" method, and I never saw that questioned during the httpRange-14 debates. Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca
Received on Thursday, 4 November 2004 17:35:02 UTC