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

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

No, anything entails the empty graph since it is always true.

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

Why not just have some test cases that say of some triples: these are 
inconsistent, ie cannot be satisfied in any interpretation. Then we 
can say (independently) that engines which find inconsistencies MAY 
flag errors, barf, etc., and that although inconsistencies formally 
entail anything, engines SHOULD NOT publish conclusions derived 
'trivially' from inconsistencies. I can say that in the semantics doc 
if you like. Nothing under the radar, that way.

Pat

-- 
---------------------------------------------------------------------
IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola              			(850)202 4440   fax
FL 32501           				(850)291 0667    cell
phayes@ai.uwf.edu	          http://www.coginst.uwf.edu/~phayes
s.pam@ai.uwf.edu   for spam

Received on Wednesday, 20 November 2002 16:41:41 UTC