W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > November 2002

Re: Datatype test cases: important ones (please have a look)

From: Jan Grant <Jan.Grant@bristol.ac.uk>
Date: Mon, 25 Nov 2002 15:13:46 +0000 (GMT)
To: Graham Klyne <GK@NineByNine.org>
cc: RDFCore Working Group <w3c-rdfcore-wg@w3.org>
Message-ID: <Pine.GSO.4.44.0211251512440.12073-100000@mail.ilrt.bris.ac.uk>

On Mon, 25 Nov 2002, Graham Klyne wrote:

> [Catching up...]
> I find this a little confusing:
> At 02:49 PM 11/20/02 +0000, Jan Grant wrote:
> >A "negative entailment test" passes if:
> >
> >         - P has no valid interpretations (contains a semantic error) OR
> >         - P is ok but does not entail C.
> In that if P has no valid interpretations I'd expect the entailment to pass
> for any consequence.
> Would it not be clearer to split this into two kinds of test:
> (a) a semantic invalidity test, in which we can assert that some expression
> has no valid interpretations, and
> (b) a negative entailment test:  P has valid interpretations and does not
> entail C.
> Or, maybe it's too late to go here?

It is probably worthwhile creating such a test type; however, due to the
way the MT handles DT interpretations of illegal literals, we don't need
this at the moment.

> Looking ahead, I see:
> >D2 has semantic errors (encoded by -ve ent test, D2 -/-> E)
> This seems unexpected on two counts (E is always true, surely?).
> I note your desire to avoid a notional always-false document F - I think I
> would prefer that approach rather than  the modified notion of entailment
> you use (but don't feel strongly enough to argue about it).  I guess your
> concern is that there is no way within the stated semantic constraints for
> RDF to construct a document that is false under every possible interpretation?

That's the problem I had, yes.

jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/
Tel +44(0)117 9287088 Fax +44 (0)117 9287112 http://ioctl.org/jan/
Hang on, wasn't he holding a wooden parrot? No! It was a porcelain owl.
Received on Monday, 25 November 2002 10:14:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:24:18 UTC