RE: 3.6 Optional Match

I'm responding to the general optional match issue, rather than
to the particulars in the last message I saw:

Why do we need optional match?  Suppose you want to retrieve
all books (or whatever) with some properties, and want to print
out what there is to know about each book.  In BRQL, you can
use DESCRIBE, but then what you get back and what you
don't appears to be at the mercy of the query engine.  If you
want control over what attributes you want back, then you
need an optional match.

Suppose you want attributes title, publisher, and creator to
be printed (whenever they are present for a given book).
 'publisher' and 'creator' are likely to return URIs,
so what you would like is to ask for specific attributes about
them as well.  These also need to be handled with optional
matches, but now the matches are nested inside of the
original optional match.

Databases get the effect of optional matches using two distinct
mechanisms.  Null values in columns correspond to top-level
optional matches.  Outer joins provide a second mechanism.
If you have a left join, and the right table in the left join has
a column containing null values, then you are automatically getting
the equivalent of a nested optional match.  So, nested optional
matches are in fact quite common place in the database world.

BRQL should be commended in adding the OPTIONAL
clause.  However, I see two problems.  First is that it doesn't
support nested optional matches (their document acknowledges
this issue).  Second, BRQL makes a distinction between
WHERE and AND restrictions.  Both of these should be
allowable in the OPTIONAL clause, but they aren't (as far
as I can tell). 

BTW, the distinction between WHERE and AND restrictions
may appear to be well-motivated, but its not.  In logic systems,
its perfectly legal to assert triples having predicates like GREATER-THAN
and LESS-THAN.  That we don't do this commonly in RDF is
an artifact of its youth -- when it gets more sophisticated, with rule-based
inference becoming common place, then there won't be a distinction
between computed and asserted predicates.
So the right fix to the second of the problems
I just mentioned is to eliminate the AND clause in BRQL.

The database community spent a cycle producing large numbers of
different kinds of null values.  Eventually, they had so many that it became
obvious that they were making a mistake.  Inventing a new kind of NULL
to mean "missing value" is probably starting all over again on that mistaken
path.  We need one kind of NULL, and that's what a variable should
bind to when there is no value for it in an optional match.

Cheers, Bob

Received on Wednesday, 4 August 2004 12:54:26 UTC