RE: more on optionals

> -----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