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

Re: Optional triples and may-bind variables

From: Eric Prud'hommeaux <eric@w3.org>
Date: Fri, 14 May 2004 04:23:54 +0900
To: "Seaborne, Andy" <andy.seaborne@hp.com>
Cc: 'Rob Shearer' <Rob.Shearer@networkinference.com>, 'RDF Data Access Working Group' <public-rdf-dawg@w3.org>, 'Pat Hayes' <phayes@ihmc.us>
Message-ID: <20040513192354.GA5133@w3.org>

On Thu, May 13, 2004 at 11:25:17AM +0100, Seaborne, Andy wrote:
> -------- Original Message --------
> > From: public-rdf-dawg-request@w3.org <>
> > Date: 11 May 2004 18:33
> > 
> > The way requirement 3.6 is written suggests that one may
> > encode parts of the query which may be completely ignored if
> > necessary--they don't impose any constraints at all. I read
> > that requirement as the ability to say "get me all the
> > people, and their email addresses if they have one, but it's
> > all right if they don't have one".
> Good example - that's exactly the sort of thing that is requested.   It is
> one of the top three feature requests from users that I get.  The top 3 are:
> optional triples, nested queries, distinct/sort/groups results (unordered
> list); I would suggest these are expectations created by analogy with SQL.
> >  That is quite contrary to
> > my understanding of how Pat's implementation works, and I'm
> > curious whether there is any implementation experience for
> > such a feature.
> Yes, there is.  SeRQL [1] implements optional triples.  The semantics are
> that the mandatory matching is done first; then any optional path
> expresssions are applied.  The approach copudl be added to RDQL or pattern
> matching scheme.  The RDQL implementers (noying that Sesame imp,ents both
> RDQL and SeRQL) had a email discussion about it awhile ago.

Two more that I know of, XUL [2] and Algae [3]. Did Libby's Squish-
SQL translator support optional triples?

Implementing optional arcs in the algae in-memory and SQL triple
stores was pretty strait forward. The translation to normalized
relations (regular old SQL tables) meant that if one attribute in a
tuple was optional, they all were.

> [[It makes a difference as to the evaluation order because the case of just
> not even trying to match an optional triple is not allowed so the eval order
> changes the flow of bound variable from one mandatory component to another.
> There is also a test case was produced by Jeremy Carroll where two optional
> triples share a variable which can't be bound consistently.]]

Algae doesn't order mandatory matches before optional matches, but I
haven't tried Jeremy's test case. pointer?

> Outside the RDF world, SQL has OUTER joins which are similar although not
> RDF. 
> > 
> > The feature effectively amounts to saying "P AND (Q OR
> > true)", with the condition that you're not allowed to
> > optimize Q away despite it being irrelevent. The implications
> > of this feature for both the query language and
> > implementations of that language are unclear and a bit worrying.
> [1] http://www.openrdf.org/doc/users/ch05.html
[2] http://www.mozilla.org/xpfe/xulrdf.htm
[3] http://www.w3.org/2004/05/06-Algae/#ex_optionalTerms

> PS I have found the SQL tutorials at (there are many others)
> http://www.1keydata.com/sql/
> http://www.w3schools.com/sql/
> very useful in recalling terminology and what SQL actually does.

and another monolithic one:

office: +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA
cell:   +1.857.222.5741

Feel free to forward this message to any list for any purpose other than
email address distribution.
Received on Thursday, 13 May 2004 15:26:09 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:00:26 UTC