W3C home > Mailing lists > Public > public-sparql-dev@w3.org > April to June 2006

Re: Indicating query type

From: Danny Ayers <danny.ayers@gmail.com>
Date: Tue, 30 May 2006 13:07:56 +0200
Message-ID: <1f2ed5cd0605300407k6d005472o7c70f0bd4f16023c@mail.gmail.com>
To: "Leigh Dodds" <leigh@ldodds.com>
Cc: public-sparql-dev@w3.org, distobj@acm.org

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.



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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:15:49 UTC