Re: SPARQL and RDF Forms

Hi Leigh,

I assume you won't mind if I CC www-archive ...

On Thu, Oct 06, 2005 at 09:48:47AM +0100, Leigh Dodds wrote:
> Hi Mark,
> 
> Can I ask a few questions about your SPARQL RDF Forms
> issue/proposal?
> 
> I can see the benefit of being able to map, on the
> client side a given SPARQL query to an existing HTML form
> action. Very powerful!
> 
> I *think* can also see why you prefer the /select, etc endpoints
> in terms of RESTful API design.
> 
> I had questions about that design myself, but this alternative
> never occured to me. Personally I was considering merits
> of say:
> 
> /graph/uri?query=
> 
> i.e. pass the query as a parameter to the URI of the graph.
> Initially this seemed "better" as it was clearer that I was
> querying a graph. But obviously its limited in applicability when
> working with multiple graphs, and perhaps when defining
> an abstract protocol.
> 
> Any thoughts on that?

You mean that the "/graph/uri" part would be important to the client?
If so, I don't think that's such a good idea for opacity reasons.

If you don't mean that, then I'm not sure what you mean since what
you describe is status quo with the SPARQL protocol and its use of GET.

> The bit I'm slightly confused over are the implications for
> GET/POST. To quote your dawg-comments email:
> 
> "Instead of POSTing a
> SPARQL query that consists of an embedded operation, the query (without
> the operation) would be POSTed to one of the aforementioned four query
> processors."
> 
> So a POST to /select wouldn't include the SELECT keyword? Shouldn't
> GET operate the same?

Yes to both.  That's why my comment on the DAWG comments list
(linked from the discussion) was titled "Query forms should be
resources not operations".

Cheers,

Mark.
-- 
Mark Baker.  Ottawa, Ontario, CANADA.          http://www.markbaker.ca
Coactus; Web-inspired integration strategies   http://www.coactus.com

Received on Thursday, 6 October 2005 13:01:14 UTC