RE: RDF query and Rules - my two cents

Ok, I disagree on several of the details in your last response, but I won't
quibble. I think the list of 4 server requirements you gave (below) are the
key, and they do nobble the mimetype approach as a general solution. A good
set of gauntlets for any other proposals to run.

This is of course assuming the transport of a description in the form you
describe is as important as you suggest. It (or something similar) would
certainly make a lot of operations a lot easier, and oil the cogs.

I still hold out hope that additional engineering of web servers won't be
necessary (and rather we didn't just drop into tunnelling the simpler
queries). But failing that I look forward to your instructions for deploying
URIQA ;-)

Cheers,
Danny.

...
> > That's a debatable point. The Concise Bounded Resource Description of a
> > resource could be seen as simply just another representation of that
> > resource.
> >
>
> Yes. And I point that out in the URIQA spec.
>
> But the semantics of interacting with descriptions is specialized
> and different in significant ways from the semantics of interacting
> with arbitrary representations.
>
> When communicating with a server:
>
> 1. One must be able to indicate to the server that the request concerns
>     a description and not a(nother form of) representation.
>
> 2. One must be able to ensure that if the server has no clue what a
>     description is, that it won't do something to a(nother form of)
>     representation.
>
> Furthermore,
>
> 3. A description is an abstraction for which one should
> be able to use the full richness of web functionality, e.g. content
> negotiation, etc. in conjunction with whatever SW extensions are
> deployed.
>
> 4. The distinction to be made in #1 above should not depend on
>     any part of the URI itself (i.e. no special suffixes, etc.)
>
> Thus, #2 above rules out headers with PUT/DELETE, and #3 rules out
> using MIME types or similar hacks.
...
> In short: URIQA and the RDF Net API are two different kinds of
> protocols.
> Both are needed.