Re: Indicating query type

On 5/30/06, Leigh Dodds <leigh@ldodds.com> wrote:
> Danny Ayers wrote:
>
> > But a puzzle I've got is how best to indicate up front whether the
> > query is a SELECT, CONSTRUCT, ASK or DESCRIBE. At least I'm assuming
> > this is the right way to go - the different query types are quite
> > different, from the agent viewpoint presumably they'd correspond to
> > different performatives, from the HTTP point of view they're only a
> > teeny bit below GET, PUT etc. So I reckon it would make sense to lift
> > the query type out of the content somehow (and it should be helpful to
> > be able to dispatch at HTTPrequest time, prior to parsing).
>
> Mark Baker made some similar comments:
>
> http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2005Jul/0066
> http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2005Sep/0013

Thank Leigh. I now remember Mark's comments, they make a lot more
sense now I'm looking to implement stuff :-)

> However I don't see any reason why one couldn't implement a specific
> endpoint for each query form (e.g. /ask, /construct) and have that
> endpoint reject any "inappropriate" queries.
>
> I don't believe there's anything in the protocol spec which stops a
> processor rejecting queries based on type.
>
> This would address your requirement without having to use a custom
> header.

Right, yep, this does sound like it'd be friendlier to the web at
large. I suppose a 501 Not Implemented is pretty close to what's
needed for inappropriate queries. Bah, does call for a bit of extra
implementation work (maybe I can get this down to snagging ARQ
exceptions and responding generically with the 501).

> You could even implement an "ordinary" SPARQL endpoint which simply
> sniffs the incoming query and redirects to the more specific endpoint
> as appropriate. Again, from my reading, the protocol spec licenses
> this kind of usage as the HTTP binding allows for relatively free
> use of HTTP response codes.

Sounds reasonable, though it's exactly that sniffing I was trying to avoid.

Cheers,
Danny.

-- 

http://dannyayers.com

Received on Tuesday, 30 May 2006 11:08:01 UTC