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

On Wed, 20 Nov 2002, Brian McBride wrote:

>
> Well done Jan.  Good to see this moving forward.
>
> test1: rdf is not well formed xml.
>    xml:lang="fr">10</eg:bar> should be xml:lang="fr">10</eg:baz>
>
> language-important-for-non-dt-entailment-1
>
> this is not what I expected
>
> [[# Language doesn't affect the semantic equivalence of some datatypes,
> # when doing a DT-entailment. However, it represents a difference
> # when doing DT-unaware entailment.]]
>
> We know that:
>
>   <a> <b> "foo"@@en#<datatype> .
>   <c> <d> "foo"@@fr#<datatype> .
>
> entails
>
>   <a> <b> _:l .
>   <c> <d> _:l .
>
> for all datatypes except rdf:XMLLiteral.

It does? Doh. I still think that's broken; but I'll fix the test case.
Basically these cases outline the various issues - I'll correct them as
appropriate.

> It is not necessary to be datatype aware to figure out this entailment.  I
> suppose there is always the possibility that someone has given a different
> URI for rdf:XMLLiteral.  Hmm, that's a shame.  Its only true if we know
> datatype is distinct from rdf:XMLLiteral.
>
> This feels a bit shady, but I guess you are right.
>
> non-well-formed-literal-2
>
> The representation of a semantic error is that the erroneous triple entails
> the empty graph.  I'm not sure this captures it. Any graph entail the empty
> graph, right?  I remember something in the model theory about a bad literal
> denoting something, just not a datatype.  If I remember rightly we would
> have a negative entailment:

NO. This is related to what Pat was complaining about. Basically, a
"Positive entailment test" with premise document P and consequent
document C passes if:

	- P has an interpretation (ie, contains no semantic errors
	  wrt the constraints imposed by the interpretation rules used
	  for the test case) AND
	- P entails C.

A "negative entailment test" passes if:

	- P has no valid interpretations (contains a semantic error) OR
	- P is ok but does not entail C.

The reason for this is to permit the following tests to be expressed:
these are all the scenarios we want to be able to test (I think) -

Document D1, semantically ok (wrt some interpretation constraints, let's
say, rdf+rdfs+dt[xsd:integer] ).
Document D2, contains semantic errors wrt the same interpretation
constraints (the MT makes it always come out false).
Document D3, a well-formed entailment of D1.
Document D4, a well-formed document that is not entailed by D1.

With the current test definitions, these can be expressed naturally by
introducing an empty document, E. Then

D1 is semantically ok (+ve ent test, D1 -> E)

D2 has semantic errors (encoded by -ve ent test, D2 -/-> E)

The relationship between D1 and D3 is captured by
	(+ve ent test, D1 -> D3)

The relationship between D1 and D4 is captured by
	(+ve ent test, D1 -> E)
	(+ve ent test, D4 -> E)
	(-ve ent test, D1 -/-> D4)


If you want to use straightforward _entailment_ (not this modified
notion used for the test cases) then you can do so BUT this requires you
to come up with a URI for a document that is abosultely false - ie,
unsatisfiable under any set of constraints. While such a document, F,
might be handy, it seems a bit beyond the scope of a test case document
to slip it under the radar. It also means that most of the scenarios
outlined above require multiple test cases to encode. It seemed simplest
to avoid the need for F and to leave test cases captured using the
current constructs.

I'm happy to revise this if you think it's necessary.

jan



-- 
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/
Semantic rules, OK?

Received on Wednesday, 20 November 2002 09:51:23 UTC