- From: Geoff Chappell <geoff@sover.net>
- Date: Thu, 24 Feb 2005 09:11:06 -0500
- To: "'Jeen Broekstra'" <jeen@aduna.biz>, <public-rdf-dawg-comments@w3.org>
- Cc: "'Andy Seaborne'" <andy_seaborne@hplb.hpl.hp.com>
> -----Original Message----- > From: Jeen Broekstra [mailto:jeen@aduna.biz] > Sent: Thursday, February 24, 2005 6:00 AM > To: public-rdf-dawg-comments@w3.org > Cc: Andy Seaborne; geoff@sover.net > Subject: more on optionals > > > DAWG'ers, > > following up on a discussion with Andy and Dave on irc about Geoff > Chappell's example query, I briefly wanted to share how SeRQL[1] deals > with optional clauses, in hope that it will be useful. > > The example query in Geoff Chappell's earlier mail would translate to > SeRQL as follows (added the mbox variable to the projection for clarity): > > select > x, name, y, mbox > from > {x} foaf:name {name}; > [foaf:mbox {mbox}], > {y} foaf:mbox {mbox} > using namespace > foaf = <http://xmlns.com/foaf/0.1/> > > The result on the example data in SeRQL is: > > x name y mbox > _:node1 "Alice" _:node2 mailto:bob@work.example > _:node1 "Alice" _:node3 mailto:noname@work.example.org > _:node2 "Bob" _:node2 mailto:bob@work.example > _:node2 "Bob" _:node3 mailto:noname@work.example.org > > regardless of path expression order in the query. > > Like SPARQL, SeRQL is a declarative language (see [2] for a draft > set-based formal interpretation), in which conceptually NULL is > treated as a special case: variables that are assigned NULL by an > optional pattern can be 'overruled' by a fixed pattern to take a > 'real' value. > > In the implementation of the language, we have made the decision to > always evaluate optional patterns _after_ all the fixed patterns have > been evaluated. This makes sure the engine behaves consistently over > cases such as the example of Geoff (and other such cases), and is > consistent with the intended meaning of optional patterns: given that > we _know_ a certain x, we want to know additional properties of that > x, but not fail if no such additional properties exist. To know x, we > first have to bind a value to x, before we can evaluate its additional > properties. That seems like a reasonable approach - not unlike stratification in a deductive database to deal with negation or aggregation. Of course stratification has its problems - e.g. with negated recursion (which, BTW, drove us to move from a stratification approach to WFS w/RDF Gateway). Does this approach have any such problems - i.e. are there any queries that it can't handle and so rejects as invalid? > Sesame implements this by representing path expressions as a nested > list structure. Each path expression in the from clause is an item in > that list, an optional path expression is represented by a having a > new list object (with that optional in it) as a member of that list. > Evaluation takes place in a breadth-first fashion. > > Anyway, sorry for the monologue, I hope this will be useful. > > Regards, > > Jeen > > [1] http://www.openrdf.org/doc/SeRQLmanual.html > [2] http://www.cs.vu.nl/~jbroeks/papers/SeRQL.pdf > -- > Jeen Broekstra Aduna BV > Knowledge Engineer Julianaplein 14b, 3817 CS Amersfoort > http://aduna.biz The Netherlands > tel. +31(0)33 46599877 fax. +31(0)33 46599877 - Geoff
Received on Thursday, 24 February 2005 14:11:19 UTC