Re: Test case document, simple entailment: preferred option.

One final option has occurred to me, which may have merit.

Currently the reason that there may be multiple entailmentRules
specified for an entailment test case is to allude (strongly) to the
idea that support for different styles of reasoner as one "moves up the
stack" can be built by adding additional sets of axioms on top of
previous layers.

That may or may not actually be the case; however, for the purposes of a
test case manifest, we need only a single "constant" value to indicate
(via indirection) _all_ the entailment rules that should be held to be
in force.

That is, currently an RDFS-entailment test is expressed by saying
(effectively) that both the rdf- and rdfs-entailment axioms are
in effect.

This idea is perhaps past its prime; thus, for the purposes of
selecting entailment rules, the cardinality of test:entailmentRules
should be exactly one, to choose between entailment tests that are:
simple, rdf, rdfs, or datatype-aware (which implies rdfs entailment).

The point about datatype selection in the last case being closed-world
is still true. To really deal with that, the expression of
"supported datatypes" should be done using a parseType=collection-style
rdf:List.


Again, this involves some changes to the test case document, together
with changes to manifest files. The largest changes are to the
descriptions of datatype-aware test cases. It is "correct" in that it
still does away with the closed-world clunkiness of the previous format;
for the purposes of selection of test cases of a particular type, a test
case harness that's built around an rdf graph will require fewer
changes.

Looking at the WebOnt test cases for impact:

- WebOnt don't use test:entailmentRules, they utilise their own "level"
property (with values "Lite", "DL", "Full"); therefore a change to this
property will have no effect. (This applies to all options).

- WebOnt use a simple (non-List) format for datatype suport
declarations. This property is defined by WebOnt's test case format
without reference to the RDF Test case schema, so would also be
unaffected. (This applies to all options).


In summary, there are a number of options to attempt to fix the
"closed-worldness" of the test case manifest format. Alternatively, the
"minimal" change would be to disregard DanC/Sandro's closed-world
issue. (It perhaps behooves the WG to not put its name to a document
which adopts a worldview antithetical to RDF.)

The test cases themselves would remain essentially unchanged. The
description of those test cases is moved towards being a more "correct"
application of RDF.

In any case, I can only apologise to the WG that this has arisen as an
issue so late in the day; I resisted my urge to put such a change on the
agenda for a long time because the authors of test case harnesses
appeared happy with the status quo, and I didn't want to spring extra
effort on them while they were doing such an ace job of running our
tests :-(

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/
stty intr ^m

Received on Friday, 7 November 2003 17:14:09 UTC