Re: issues list separated from BRQL spec

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)

     http://www.swed.org.uk/swed/index.html

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.

	Andy

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