MGET and machine processing

I just reread URIQA - it had been a while since I had last read it.

On Fri, Nov 21, 2003 at 10:23:24AM +0200, Patrick Stickler wrote:
> > Hey, if you're arguing for the need for query capabilities, you're
> > preaching to the choir.  But let me query with GET, please.
> >
> 
> GET is fine, and optimal, and correct for general querying to a known
> service, and that's what we use and what I advocate.
> 
> But there remains the issue of bootstrapping. What does one do when
> one has a URI *and nothing else*?

Without any other information, one can only safely GET it.  That's part
of the reason why there should only be one method to "retrieve stuff",
as any other method provides a choice which create a separate
information space (e.g. OPTIONS, PROPFIND).  A universal information
space *requires* a single "give me your data" operation, which is why
the TAG says stuff like;

"Use GET if [...] The interaction is more like a question"
 -- http://www.w3.org/2001/tag/doc/whenToUseGet.html#checklist

In URIQA, you claim;

"However, semantic web agents (at present at least) are not able to deal as well with the broad range of possible representations which might be associated with a resource; and in nearly all cases, are unable to make any use of such representations, as they are typically intended for human rather than machine consumption."

Most URIs dereference to HTML today, granted, but that's not an
architectural failing, it's just common practice.  To "remedy" it, we
don't need new HTTP methods (which are very expensive to deploy, as you
acknowledge), we need more machine readable content.  Your approach
requires both, while mine only requires the latter.

> Why should a SW agent not be able to obtain a description of the
> denoted resource *as easily as* a web agent can obtain a representation?

It should!

GET the-uri HTTP/1.1
Accept: application/rdf+xml

I claim that using GET is easier than using MGET, because the world
already knows what GET means.  And though the Accept header can be
silently ignored by the server, the Content-Type returned in the
response will indicate to the agent whether it can process it or not.

FWIW, I've got some conneged HTML/RDF content you can look at if you
like; http://www.markbaker.ca/2003/rdfforms/

> I've already conceded that one should add new methods rarely, if
> at all -- just as with new URI schemes -- yet have also argued, from
> real world implementational experience, that the new methods are
> necessary.  If you can prove otherwise, fine, I'm all ears. But I
> fail to understand your opposition to solutions such as URIQA in
> the absence of either solid arguments/evidence that such solutions are
> not needed or that better solutions to the same problems exist.

How's that then?

FWIW, I like the "URIQA-uri" header. 8-)  It addresses the
self-descriptive problem with people using fragids on URIs to identify
resources, in much the same way that the Host header solved the
self-descriptive problem of partial URIs in the request line.
I haven't fully thought through the implications though.  I'd prefer
that folks simply stopped identifying resources using fragids.  But
that's another (perma) thread. 8-)

Mark.
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

Received on Friday, 21 November 2003 10:11:35 UTC