Re: fromUnionQuery

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.


> 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.

> 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.

> 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'm not stuck on the names WITH/FROM, or even the background/named
> graph split.  I'm happy with just a set of named graphs.
> 
> Dave
-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E

Received on Thursday, 7 April 2005 17:18:25 UTC