W3C home > Mailing lists > Public > public-sparql-dev@w3.org > July to September 2008

Re: Mulgara and sameTerm

From: Paul Gearon <gearon@ieee.org>
Date: Wed, 30 Jul 2008 12:25:53 -0500
Message-ID: <a25ac1f0807301025r7335aa6bj75bdeb3699018986@mail.gmail.com>
To: "Seaborne, Andy" <andy.seaborne@hp.com>
Cc: "public-sparql-dev@w3.org" <public-sparql-dev@w3.org>, "Arjohn Kampman" <arjohn@aduna-software.com>, "Andrae Muys" <andrae@netymon.com>, "James Leigh" <james-nospam@leighnet.ca>

On Wed, Jul 30, 2008 at 3:54 AM, Seaborne, Andy <andy.seaborne@hp.com> wrote:
>> 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.

Yup, followed that truth table (it's one that I've seen time and again
in different contexts). So my catching the exception and filtering out
that result was the correct thing to do. Thanks.


> 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.

Since we don't (yet) have a protocol implementation I've been relying
on the SAIL API to run the test suite, since SAIL is set up for this.
That means I've let James do the testing for me and I've addressed
issues he reported without looking too carefully at the tests myself.
We've discussed having an option to ignore known data types and
instead store things lexically, so we can enable this option for those
tests that are suitably annotated. If we find a problem with this I'll
pass it on.

Received on Wednesday, 30 July 2008 17:26:32 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:15:50 UTC