Re: TEST: LC plan

Yes we really need more help on this!

After making some changes to our inference rules
to support the positive entailment tests and the
inconsistency tests (not the negative entailment
tests and consistency tests) we found out that we
can't prove anymore following APPROVED testcases:

Maybe the group should have another look at them...
(plus also the APPROVED negative entailment tests
and consistency tests)

On the other hand we were able to prove

so those are proposed to be APPROVED

I haven't been succeeding with the testcases in

(and certainly not with the negative entailment
tests and consistency tests in there)

-- ,
Jos De Roo, AGFA

                    Jeremy Carroll                                                                                     
                    <>         To:                                              
                    Sent by:                 cc:                                                                       
                    www-webont-wg-requ       Subject:     TEST: LC plan                                                
                    2003-04-10 08:54                                                                                   

I was asked to draft a plan for getting Test to LC

I am particularly eager to hear DanC's comments on this plan.

I ask for help in:
- reviewing/running tests
- fixing bugs in tests
- xslt to multipart doc (see end of msg, optional)


+ Defects with current draft
+ Entry criteria for LC doc
+ Plan for meeting entry criteria
+ Non-objectives and plans for dealing with them
+ Help items

Defects with current draft

The current WD has three principle defects:
- many tests do not conform with resolution of OWL DL Syntax issue
- many tests are proposed and not approved
- many tests are missing

Another must fix defect is the treatment of tests with datatypes (2hrs)

A further nice-to-have is a true multipart document format.

Entry Criteria for LC doc
Fix the known bugs in the tests, so that, to the best of our knowledge the
approved tests reflect the state of the other LC WDs.

1) Build an OWL Syntax checker based on triple tables (1 week)
(probably glossing over owl:equivalentClass and maybe owl:disjointWith,
not checking these absolutely thoroughly)
2) Integrate that with the test document build environment (1 day)
3) generate editors drfat with lots of defects highlighted (20 mins)
4) fix defects (1 week)

The times are amount of work rather than elapsed time.
Item (1) I can double count as working on Jena.

I suspect four weeks (May 8) is a realistic goal, it might all get done in
three. (May 1) I do need to spend some time on RDF Core work.


Approving proposed tests
The SOTD can say that the WG has approved some tests which it believes
with the other LC drafts; other proposed tests are also believed, by the
editors, to conform with the other LC drafts.

Missing Tests
The SOTD indicates that more tests are being generated, and to point the
reader at the editors draft for the latest view.

Conformance with LC decisions, closing of LC issues
The goal is for a document that would have been right on the 31st March.
Points where decisions made by the WG since then, or defects which have
surfaced in the mailing lists since then, may be indicated in an appendix.
indicates a bug with approved test
indicates that it may be a bug with S&AS.
Thus I am likely to demote the test to status proposed and put a link to
thread in an appendix to the document.

Help Items

Running the tests and reporting results.
I am particularly keen to get syntax results.
I am also keen to get results for the harder DL tests (which Euler cannot
We should be able to approve a good many more of the tests before LC if
implementors can give positive data.

Fixing bugs
Appendices D.2, D.3, D.4 in the current draft list known bugs
there will be more.
I am not going to fix them right now, anyone who cares to could do so.
It is probably easiest to do so using the test editing environment

The current XXL version
has absolutely everything in it.
It could be passed through an XSLT transform splitting into:
+  everything up to section 6 inclusive
+ 7.1
+ 7.2
+ appendix A and B
+ C.1
+ C.2
+ C.3.1
+ C.3.2
+ C.3.3
+ C.3.4
+ C.3.4
+ C.4.1
+ C.4.4
+ C.5.1
+ D, references

If anyone wishes to have a go at this I would be pleased. AN XSLT program
could easily be integrated into the test document creation environment so
that the transform gets run automatically.

It would be easy enough to add some extra tags to help in this process.*,access*
lists the source jsps for the tests
tests4.jsp corresponds to a single test
tests3.jsp does the content of the bottom level sections e.g. C.3.4
tests2a.jsp does the heading of the same (the whole of C.3 for example)
test2.jsp does 7.1 7.2 C.1 C.2

Received on Monday, 14 April 2003 19:30:06 UTC