RE: Unbound vars as blank nodes

I like the idea of using a bnode and actually use it since few weeks.
One can always describe it as [ a q:NULL ].

-- 
Jos De Roo, AGFA http://www.agfa.com/w3c/jdroo/




"Geoff Chappell" <geoff@sover.net>
Sent by: public-rdf-dawg-comments-request@w3.org
23/03/2005 13:22

 
        To:     "'Arjohn Kampman'" <arjohn.kampman@aduna.biz>
        cc:     <public-rdf-dawg-comments@w3.org>, (bcc: Jos 
De_Roo/AMDUS/MOR/Agfa-NV/BE/BAYER)
        Subject:        RE: Unbound vars as blank nodes





> -----Original Message-----
> From: Arjohn Kampman [mailto:arjohn.kampman@aduna.biz]
> Sent: Wednesday, March 23, 2005 5:52 AM
> To: Geoff Chappell
> Cc: public-rdf-dawg-comments@w3.org
> Subject: Re: Unbound vars as blank nodes
> 
[...]
> > SELECT ?x ?y
> >    WHERE  { ?book dc10:title ?x }
> >
> > Logically speaking projection vars are existentially quantified, 
right?
> And
> > that's what a blank node is, so it seems logically correct to return:
> >
> >              ?x="Moby Dick", ?y=_:b1.
> >
> > I.e. the sentence:
> >              There exists ?x,?y such that ?x is the title of something
> > essentially becomes:
> >              There exists ?y such that "Moby Dick" is the title of BK1
> 
> Yikes! Apart from the fact that the above query should be flagged as
> illegal (see my previous posting to this list), generating new bnodes
> for unbound variables will make the QL even more complex than it already
> is. Developers have learned to live with NULL values in the context of
> SQL, so why would this be problematic for SPARQL?

I'm not sure I buy the complexity argument... do you mean complex for the
implementor or complex for the user? Either way, it doesn't strike me as 
too
much of a burden. And I think the SQL/SPARQL analogies only get you so 
far.
E.g. wrt to this issue, RDF has a built-in way to represent variables in
results, SQL doesn't. Plus, NULLs carry their own load of controversy and
confusion in the SQL world.

That's not to say NULLs won't work. I think a perfectly workable solution 
is
to require that all vars mentioned in a pattern element are bound to
something by that pattern element -- if not to an actual value, then to 
NULL
-- and that NULL != NULL. IMHO that would resolve the current execution
ordering mess (I've heard statements to the contrary but I've never seen a
counter example). The current approach to specifying preferred execution
orders is just too fragile. It will be a major obstruction to future
versions of the language - e.g. good luck using sparql (squint and 
construct
looks like a rule construction) as any sort of a rule language with all of
these ordering dependencies built-in.

> [...]
> > Now for optionals....
> >
> > SELECT ?x ?y
> >    WHERE  { ?book dc10:title ?x. OPTIONAL  ?book ex:author ?y.}
> >
> > The result:
> >
> >              ?x="Moby Dick"                  ?y=_:b1
> >
> > seems reasonable - i.e. we know the book has an author (that's what
> we've
> > implied by using optional) we just don't know what it is.
> 
> This is not true: the optional implies that the book can have an author,
> not that it actually has one. From a developer POV, it's important to
> make this distinction. Returning bnodes for unbound variables suggests
> that it actually was bound.

Well, I guess I'd say that optional implies whatever optional is specified
to imply. But I'll agree it's a weakness of this approach that a user
couldn't necessarily distinguish between a "real" and an "artificial" 
value.


- Geoff

Received on Wednesday, 23 March 2005 12:33:06 UTC