- From: Leigh Dodds <leigh@ldodds.com>
- Date: Tue, 30 May 2006 11:45:09 +0100
- To: Danny Ayers <danny.ayers@gmail.com>
- CC: public-sparql-dev@w3.org
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 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. 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. Cheers, L. -- Home: http://www.ldodds.com | "Simplicity is the ultimate Blog: http://www.ldodds.com/blog | sophistication" -- Leonardo da Vinci
Received on Tuesday, 30 May 2006 10:45:34 UTC