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

Re: issues list separated from BRQL spec

From: Seaborne, Andy <andy.seaborne@hp.com>
Date: Thu, 09 Sep 2004 10:02:18 +0100
Message-ID: <41401C1A.9070200@hp.com>
To: kendall@monkeyfist.com
CC: Dave Beckett <dave.beckett@bristol.ac.uk>, Dan Connolly <connolly@w3.org>, RDF Data Access Working Group <public-rdf-dawg@w3.org>

Kendall Clark wrote:

> On Wed, Sep 08, 2004 at 10:25:45PM +0100, Dave Beckett wrote:
>>My issue is described as "SOURCE premature stdization" to
>>which my answer is "no it isn't premature", as at least 3 members
>>of the WG have already reported that they implement and want such
>>tracking.  @semantics in rdfstore, Southampton in 3store, me
>>in redland (tucana in kowari maybe also).  I assume the WG
>>generally knows this.
> Mindlab wants and uses a tool, rdflib, that supports it. For the
> record.
> Kendall

We've (Dave Reynolds, Damian Steer) implemented in the SWAD-e 
demonstrator SWED (Semantic Web Environment Directory)


The design concept is like the "named containers" outline. Quads is one 
possible implementation, so is a union of RDF graphs (i.e. held 
separately with a code layer to get the semantics right).  Which is 
better (faster) depends on what you want to do with it.

I have tried SOURCE as named containers in my prototype BRQL (as of 
yesterday!) and it looks OK.  Specifically, it does not require quads 
and a quadded implementation has the same kinds of tradoffs.  If its an 
ad hoc aggregation keeping them separate is probably better, if its used 
over many queries, its probably not.

I did find that if the SOURCE (ORIGIN) statement has a constrained 
variable (it has a value at the point of execution time with the overall 
query execution) then its neutral to quads vs named union; if its 
unconstrained - has not yet got a value -

SOURCE ?src { .... pattern ... }

then ?src needs to loop over the distinct values of the ORIGIN slot.
Query reordering to make sure its bound woudl be good.

Received on Thursday, 9 September 2004 09:03:44 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:45 UTC