W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > April to June 2005

Re: fromUnionQuery

From: Seaborne, Andy <andy.seaborne@hp.com>
Date: Wed, 13 Apr 2005 15:41:46 +0100
Message-ID: <425D2FAA.7090706@hp.com>
To: Dave Beckett <dave.beckett@bristol.ac.uk>
CC: public-rdf-dawg@w3.org



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.
> 
> 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.
> 
> 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. 
> 
>   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.
> 
> 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.
> 
> I have implemented and am already all of #1, #2 and #3
> 
> 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'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
> 

Following the telcon decision on fromUnionQuery, and the advice to get something 
done quickly, I have added a section that has some material for this.  It's 
"section N" for now, between 8 and 9.

I have only allowed a single URI for the graph for the background graph.  This 
puts all matters to do with combining graphs by merging/unioning to make another 
graph outside the spec.

Outline:
FROM - one URI, identifies the backgrapound/default graph, does not name it.
        can use once per query
FROM NAMED - one URI, identifies a named graph
        can have several per query

The grammar is fixed as well.

Details in rq23 v1.298 and later

	Andy
Received on Wednesday, 13 April 2005 14:42:09 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:23 GMT