Re: Query forms should be resources, not operations

Hi Kendall,

On Tue, Aug 02, 2005 at 12:30:11PM -0400, Kendall Clark wrote:
> On Thu, Jul 28, 2005 at 03:00:12PM -0400, Mark Baker wrote:
> 
> > the same arguments with different operations).  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.
> 
> Mark,
> 
> I'm not entirely sure what the import of yr comment is. Can I ask for
> clarification?
> 
> For example, the present design motivates an implementation like this:
> 
> GET /sparql/?[query & dataset]
> 
> or
> 
> POST [query & dataset] /sparql
> 
> Where "query" is "SELECT ?a ?b ..." or  "CONSTRUCT ..." or "DESCRIBE
> <uri>..." or "ASK ..."
> 
> Yr suggested design, insofar as I understand it, motivates an implementation
> like this:
> 
> GET /construct?[query & dataset]
> GET /select?[query & dataset]
> GET /ask?[query & dataset]
> GET /describe?[query & dataset]
> 
> or
> 
> POST [query & dataset] /construct
> POST [query & dataset] /select
> POST [query & dataset] /ask
> POST [query & dataset] /describe
> 
> Where "query" is similar to the pseudo-queries above, but with the query
> form productions removed. Thus, for example, instead of "SELECT ?a ?b WHERE
> {<foo> ?a ?b}", the on-the-wire query would be "?a ?b WHERE {<foo> ?a ?b}".
> 
> Is that what yr suggesting?

That's exactly right.  Nicely summarized.

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

Received on Tuesday, 2 August 2005 22:03:02 UTC