Re: construct starting to feel like a separate interface

Dan Connolly wrote:
> I'm working on sparcli.py , playing with various
> services out there; one of the options is...
> 
>     elif '--sparqlette' in sys.argv:
>         BG='data'
>         svcAddr =
> 'http://www.wasab.dk/morten/2005/04/sparqlette/?format=xml&'
> 
> i.e. I'm trying to look at the SPARQL interface as something
> that doesn't have a format= param, but sparqlette has
> a format param, so I'm trying to "hide" it in the service
> address.

Could do - there is also format information using the "accept".

> 
> That works for SELECT and ASK, but not for CONSTRUCT.
> 
> I'm starting to wonder if ?query=... should be
> separated into ?select=... and ?construct=... or
> something.
> 
> And the special-case for ASK in the results format
> feels wierd. I'd rather use the degenerate form of
> the general case: zero results for false, and
> one result with zero bindings for true. But I guess
> we're decided on that (indeed...
> http://www.w3.org/2001/sw/DataAccess/ftf4.html#item11 )
> and I don't have much in the way of new information.
> 
> Just thinking out loud.
> 
> for ref...
> http://www.w3.org/2001/sw/DataAccess/proto-wd/sparcli.py
> 1.5 now
> 

There is a tradeoff for simple clients.  If there are separate interfaces for 
different operations, then it requires the client library to send different 
things for the various result forms - and so the client library needs to know 
at the point the request is made.  So it needs to understand SPARQL query 
strings (at some level - need not be complete parsing) or it would require the 
API to get the application to tell the client library what to do.

With one interface, a simple client could written that does not need to parse 
the query string.  The most basic is send query string to a service.  It's the 
results that need the information - our result form, for example, enumerates 
the variables in the header making subsequent parsing streamable.  Works if 
you can tell RDF/XML from XML result sets, like "accept" processing.

	Andy

Received on Sunday, 15 May 2005 17:22:12 UTC