Re: First order logic and SPARQL

Hi Juan,

The most obvious difference is that in logic, the AND operator is
> commutative, while in SPARQL, the
> order of conjuncts in an AND (a ".") makes a difference -- commute them,
> and you sometimes change the
> result/meaning of the query.
>

Really???

Yes, really.  It sounds very much like you have defined/referenced a
cleaned-up version of SPARQL which
unfortunately does not reflect the real-world semantics.

The problem with SPARQL stems from the OPTIONAL operator.  A mantra of RDF
has been that it
has open world semantics.  The OPTIONAL operator is inherently
non-monotonic.  A few of us devised
a closed-world semantics for OPTIONAL, but the open-world advocates rejected
the notion, favoring instead
a procedural semantics.  Not only are arguments to OPTIONAL defined to be
order-dependent (analogous to a series
of if-then-else clauses), but the SPARQL AND operator became polluted as
well -- changing the order of conjuncts
that contain OPTIONALs can change the semantics of a SPARQL query.  I don't
have examples available
on the tip of my tongue, but a talk I gave a year ago at SEMTECH had an
example, and there are many
others out there who should be able to furnish examples.

It would be a great service to the RDF community if you or someone would
propose a semantically
well-founded variant of SPARQL (call it SPARQLL for "logical SPARQL", or
whatever).  It would necessarily
have closed-world semantics (as does Datalog).  If the major triple/quad
store vendors were to support
SPARQLL, that would be a significant step forward.  We could then, for
example, invent a negation operator
that would be semantically consistent with the language, and that ordinary
users would be able to fathom.
At the moment, we observe postings every few months of another hapless soul
who can't figure out how
to express a simple negation in SPARQL and has to be bailed out by Lee
Feigenbaum (I'd insert a smiley
here if it weren't so tragic).

Regards,
Bob

Received on Sunday, 5 September 2010 01:29:37 UTC