Paul Gearon wrote:
Thanks Andy, this does clear up a number of things for me.
On Tue, Jul 29, 2008 at 11:33 AM, Seaborne, Andy <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
<snip/>
Most of the SPARQL filters require value space comparison. The
definition of "=" allows extensibility by causing a type error if
two terms might be the same value but the processor does not know.
(Aside two literals are definitely equal if they are the same
lexical form and same datatype, for any datatype whether anything
else if know to the processor about it, because the lexical to value
space mapping of the datatype is functional.)
This reminds me... exactly what is meant by "type error" here? The first
time I worked on this I threw an exception, but obviously that wasn't a
good idea and I fixed it. :-) At the moment, a "type error" is
effectively the same as not equals, which works, but has me
uncomfortable since I'm ignoring the distinction. (Actually, I'm still
using the exception internally, but I catch it and continue as if there
was no match)
(This was an area of teh spec that EricP did)
SPARQL defines a 3-state logic for evaluation. True, False and Error.
Errors propagate so for almost everything "something(error)" is error.
The exceptions are && and || so e.g. "true || error" is true and
"error&&false" is false and not(false&&error) is true.
Eric put the truth table in sec 11.2
http://www.w3.org/TR/rdf-sparql-query/#evaluation
At the top-most level, FILTER (..error..) excludes the solution tested
so error becomes false if you like as the 3-state logic collapses to a
2-state logic.
sameTerm works on the definition of equality from RDF Concepts so no
D-entailment. [B] But SPARQL does not prescribe what is "in" the
store - there is dataset that is queried. Especially in the case
where the dataset comes from execution context (no FROM etc, no
protocol parameter), SPARQL says nothing about how that dataset came
to be. It just is. So if you load RDF that has "+1"^^xsd:int,
whether the store preserves the exact lexical form, or it's
datatype, is a feature of the store. SPARQL does not cover this
step. If you load "+1"^^xsd:integer and "01"^^xsd:byte, it's a
store decision whether there are two terms or one, or whether what
is stored and returned is "1"^^xsd:integer which wasn't directly
mentioned (or even "1"^^xsd:decimal as the primitive XSD type that
they are all derived from).
This was my understanding of how things work, though this implementation
decision for Mulgara was made by others. I'm glad to see that the
decision wasn't based on a misunderstanding. However, it *is* causing
problems for the test suite.... as you get to below.
<snip/>
The test suite is a slightly different case: it is providing tests
for a specific set of choices. The tests do label what the
assumptions are. Some tests are labelled as making more than just
basic assumptions (e.g language tags).
This is where we are coming unstuck. The tests are being treated as an
absolute, meaning that if we don't get exact correspondence in the
results we fail. Even if Mulgara is prepared to accept this, many
potential users are not. In our current scenario, Sesame is expecting
exact compliance with the tests as they are, and our current
architecture (storing values for known types, rather than lexical
representations) does not work here.
When the data is loaded from the manifest with qt:data etc, the file is
assumed to be used as is. Just basic simple entailment level - you have
to start somewhere. Tests are supposed to be annotated with mf:requires
where they make assumptions. Since adding triples is monotoinic :-)
presumably anyone can add more to the test suite manifests at any time!
Seriously though - if theyare not labelled appropriately, could you at
least email the dawg-comments list with a list of the tests in question
and maybe something can be done (errata?). At least if its on the
mailing list then its somewhere other implementers can see it and any
future WG can pick it up.
Andy
I guess our problem comes down to the test suite being treated as a de
facto part of the standard.
Paul
--
Hewlett-Packard Limited
Registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England
