Re: fromUnionQuery

On Thu, 07 Apr 2005 12:18:03 -0500, Dan Connolly <connolly@w3.org> wrote:

> On Thu, 2005-04-07 at 16:33 +0100, Dave Beckett wrote:
> > My opinion on this issue is that the query language should allow
> > construction of whatever RDF dataset design we give.
> > 
> > This would be in addition to the SPARQL protocol. WSDL1/2 may be a
> > solution for some people but I can't see using it anytime soon.
> 
> Regardless of whether it's described in WSDL or prose,
> what do you want the protocol to look like? Got a
> concrete design in mind? Please share it if so.

If you want a protocol design, here's mine in a screenful:

http://example.org?query=sparql-query&query-lang=sparql&data=uri1&data=uri2&format=rdfxml&output-xslt=uri&limit=10

Parameter      Value (allowed count)
  query        sparql query string (1)
  query-lang   "sparql" [default?] or ... (1)
  data         URI/name of a data graph (0+)
  format       "rdfxml", "xml", "turtle", "ntriples" ... [defaults vary] (1)
  output-xslt  URI of xslt document to apply on XML output (0-1)
  limit        integer decimal 0+ (0-1)

... means system defined

(could also have a parameter query-uri with value "URI of a sparql query")

This doesn't mean I don't want FROM, LIMIT in the query language also
to create canned queries such as the "first 10" from some query
result of an aggregation (leaving apart the sorting discussion).
Protocol-like parts such as format, output-xslt would be nice in the
query language but not critical.


> 
> > I want to construct the dataset in two ways
> > 
> > 1. inside the programming API
> >   This would be used inside running programs and for implementing
> >   web interfaces where the URIs given of the graphs can be checked
> >   for denial of service, size, etc. issues before loading into the
> >   system.
> 
> I don't expect that we'll get into APIs, except inasmuch as
> a WSDL description can used as an API in some dev platforms.
> 
> > 2. inside the query language.
> >   This would be when "just running" a query, such as a stock one
> >   ("this one gives you the answer") against a well known or standard
> >   data source.  At this point you trust the query. 
> 
> I think we considered that argument before making our
> decision to take LOAD/FROM out of the QL.
> http://www.w3.org/2001/sw/DataAccess/ftf5-bos.html#item_03
> 
> >   It also allows easy chaining of queries, using an RDF/XML output of
> >   one query via http protocol made with CONSTRUCT/DESCRIBE as a data
> >   source for later queries.
> 
> Chaining seems just as easy to do if LOAD/FROM appears
> as their own parameters rather than in the SPARQL query parameter.

Yeah, I think Alberto had this case worked out but I can't remember
the details.

> > 3. on the command line
> >   Either of #1 and #2 enable SPARQL to work on the (unix) command
> >   line allowing RDF to enter the processing data pipeline but #2 also
> >   allows easier data integration (fan-in) which is rather more clumsy
> >   to do with lots of -d URI command parameters.  This is a weaker
> >   reason I admit.
> 
> Again, command line args seem an awful lot like protocol parameters.
> 
> A WSDL description is just a way of saying "you can put these
> in an API, or on a command line, or in a network protocol,
> but this is the information that goes in a request, for this
> interface".
> 
> > I have implemented and am already all of #1, #2 and #3
> 
> Got some example command lines? I expect they correspond neatly
> to GET requests.

They do.  For command-line or URI users that's all ok until the
parameters, such as number of data graphs starts to rise.  It takes
only a few URIs before the GET request or command line becomes huge
and unwieldly. In that case it makes more sense to put them inside
the query document.


If in some chain of processing, SPARQL queries are being generated,
it would be easier if it was documents all the way through.  For
example:

   XML document
     - XSLT processor ->
   SPARQL query document with data uris
     - SPARQL query engine ->
   SPARQL result (xml)
     - XSLT processor ->
   ... more XML ...

The alternative is application-specific for each application, how to
create the dataset and apply it to a query engine rather than just
*execute this sparql query document* which should work across all
sparql query engines.

I remember a similar style problem when applying some xslt processing
in a system and had to work out how to externally set some xslt
parameters - it was not making chaining the XML easy.


> > Without the WITH/FROM equivalent it makes the language much less
> > interesting and useful to me and rather too statically designed for
> > what I've always thought of as a dynamic web query language - working
> > on demand.
> 
> I don't hear anybody arguing to have no WITH/FROM equivalent.
> What will move us forward is a specific proposal for what they
> should look like on the wire.

I've given one wire approach.   I just don't want to be required to
have to use it.  My 3 examples above have no protocol.

Dave

Received on Monday, 11 April 2005 10:35:01 UTC