W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2004

Re: ACTION: discuss & promote union query (Was: ACTION: a replacement for 4.5 focussed on union query)

From: Steve Harris <S.W.Harris@ecs.soton.ac.uk>
Date: Tue, 24 Aug 2004 17:59:20 +0100
To: RDF Data Access Working Group <public-rdf-dawg@w3.org>
Message-ID: <20040824165920.GL22252@login.ecs.soton.ac.uk>

On Tue, Aug 24, 2004 at 09:24:14AM -0700, Rob Shearer wrote:
> > [[
> > 4.5 Querying multiple sources
> > 
> > It should be possible for a query to specify which of the 
> > available RDF 
> > graphs it is to be executed against.  If more than one RDF graph is 
> > specified, the result is as it the query had been executed 
> > against the 
> > merge[1] of the specified RDF graphs.
> 
> I continue to feel that this feature, and beyond this objective the
> specific approach taken by BRQL, do more harm than good. Unlike SQL
> data, RDF is not segmented into tables and thus within a particular
> server there is absolutely no need to target a particular "piece" of
> RDF. It makes sense to me for source selection to be performed at a
> different level than the query language, such as the network protocol.
> 
> More importantly, the ability to aggregate graphs seems quite orthogonal
> to the ability to query an RDF graph. RDF aggregators will undoubtedly
> be important RDF applications, but in general I expect far more servers
> to only support queries against their one and only RDF store. Adding the
> feature can only hurt the development of truly general aggregation
> functionality.

OK, so I have an agregator (a single store containing multiple RDF files,
to be clear), now how do I query it without loosing the source
information?

I think you will find that a sustantial number of RDF stores keep and use
SOURCE information.

The queries tend to be fairly trivial ("I need to refresh all the files
written by John", "What file says that my name is '$firstname $surname'")
but they are important.

- Steve
Received on Tuesday, 24 August 2004 16:59:25 GMT

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