On 5 Sep 2010, at 02:29, Bob MacGregor wrote:
[snip]
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.
http://www.w3.org/TR/rdf-sparql-query/#sparqlDefinition
The semantics of (a good chunk) of the algebra is in terms of the
relational algebra.
The formalization is based on this paper:
http://arxiv.org/pdf/cs/0605124v1
I wouldn't conflated declarative (or formal) semantics with model
theoretic.
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.
?? I don't think so. I'd be interested in a reference.
Note that non-communitivity doesn't imply non-monotinicity. After all,
implication is non-communitive. Optional is defined in terms of left-
outer join.
A few of us devised
a closed-world semantics for OPTIONAL, but the open-world advocates
rejected the notion, favoring instead
a procedural semantics.
The meaning is the meaning, regardless of the presentation of that
semantics.
Not only are arguments to OPTIONAL defined to be order-dependent
(analogous to a series
of if-then-else clauses),
Like implications in first order logic.
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.
Can we dig this out?
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).
I think that's called SPARQL/1.0.
It would necessarily
have closed-world semantics (as does Datalog).
Well, unbound requires epistemic reflection, but I don't think
OPTIONAL does per se.
There's a lot of tricky parts of any query language because of e.g.,
the need to report and control answers. It's perfectly reasonable to
quarrel with choices you don't like, but I think we should be a bit
more careful about the source of the problems. SPARQL/1.0 has a pretty
reasonable and standard formalization.
Cheers,
Bijan.
