W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > February 2005

more on optionals

From: Jeen Broekstra <jeen@aduna.biz>
Date: Thu, 24 Feb 2005 11:59:45 +0100
Message-ID: <421DB3A1.7030905@aduna.biz>
To: public-rdf-dawg-comments@w3.org
Cc: Andy Seaborne <andy_seaborne@hplb.hpl.hp.com>, geoff@sover.net


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.

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
Received on Thursday, 24 February 2005 10:58:30 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:14:47 GMT