Ensure test file generation is consistent

[phillord]

Previously, test files were generated in a variety of different ways, both manually and using bubo; it was often unclear why files were generated like this. Where it is possible to do, test files are now generated using bubo consistently.

An upper level make file has been added for convenience, and a README file which documents the generation of these files.

DataUnionOf constructs are now supported, and the erroneous test file that was hiding this breakage has been updated.

[althonos]

Any way to avoid the whitespaces and comments in the OWL Functional files? This is gonna be a bit more tedious for roundtripping...

[phillord]

Hmmm. Not straight-forwardly. The files are written by the OWL API and I don't control the whitespace (unless it is configurable in the OWL API).

What is the problem with roundtripping? Are you not comparing the semantics?

Getting horned-owl to be compatible with the OWL API white space is going to be a pain.

[althonos]

No, the roundtripping is comparing the result of the serializer after parsing, so I'm also comparing syntax, that's why I had the OWL functional files formatted that way. I could probably add support for writing comments in a very weird and broken way buy I don't think we should be testing that, in theory the OWL Functional syntax does not even need to have newlines between the different axioms...

[phillord]

I use multi-tripping -- read an ontology, save it, read the saved version, the compare the semantics of the original to the generated.

It has it's flaws - errors paired in parser and renderer are missed, but it does seem to mostly work. For the rest, I put in specific checks of semantics into the rust test files.

I did used to keep a file that I have generated using horned and then parse that which was useful in the early days, but this patch actually removes it. That is also a possibility -- we could generate four or five functional files, using horned, put them into the manual directory and not autogenerate them. This way you could be testing horned files against horned files, so the white space should be consistent.

[althonos]

Ok that works, I'll use the multi-tripping for testing 👍

[phillord]

The other thing that I do is check that the reader works by checking that the ontology from an RDF file is the same as the ontology from an XML file.

With this new directory structure, actually, it is now clear which files should be semantically identical because they are autogenerated. So, I could simplify the test structure in both XML reader and writer by autogenerating all of the tests with a macro maybe.

That would mean that all of the tests of specific semantics could be in one place (the XML reader probably). Any other reader/writer would only need to write syntax specific tests.

[filippodebortoli]

The other thing that I do is check that the reader works by checking that the ontology from an RDF file is the same as the ontology from an XML file.

With this new directory structure, actually, it is now clear which files should be semantically identical because they are autogenerated. So, I could simplify the test structure in both XML reader and writer by autogenerating all of the tests with a macro maybe.

That would mean that all of the tests of specific semantics could be in one place (the XML reader probably). Any other reader/writer would only need to write syntax specific tests.

Could it make sense to have these compatibility tests sitting in io/mod.rs, having a io::test module?

For the test files that are generated using bubo, there could be a unique test that loops over the files contained in ont/bubo and for each entry picks up the generated files, parses them and compares the obtained ontologies. With this approach we avoid writing declarative macros, and we should still be able to pinpoint a failure in the test to a specific .clj file and related serializations in other formats.

[phillord]

Yes, we could move everything to mod.rs. That would make more sense and would cover everything. We can then document which is the "primary" format that we care about where we run the semantic tests -- this is XML at the moment because it is the one I wrote first.

I thought about having a single loop which tests all the files. But this is clunky from the test side, blocks parallelization and earlier failures mask later ones. There is https://github.com/frehberg/test-generator which seems to be aimed at exactly this problem.

[phillord]

If everyone one is happy, I will merge this to devel. Future enhancements, like automating the test can go into another PR.

[filippodebortoli]

If everyone one is happy, I will merge this to devel. Future enhancements, like automating the test can go into another PR.

I have nothing against you merging onto devel. 👍

[althonos]

@phillord : Just realized that this produces invalid IRIs in the prefixes:

Prefix(:=<o>)

In here <o> is a quoted IRI but o is not a valid IRI as per RFC 3987.

[phillord]

Now that is strange. It should be showing

o:=http://www.example.com

This looks like an OWL API bug, though. Can you create the same ontology in the OWL API (or protege) and see what that produces?

[phillord]

@ignazio1977 Do you know about this one? Is the OWL API generating the right thing here?

[ignazio1977]

@phillord is there a small example that shows what's going on?

[phillord]

Yes. Compare:

https://github.com/phillord/horned-owl/blob/devel/src/ont/owl-functional/and.ofn

to:

https://github.com/phillord/horned-owl/blob/devel/src/ont/owl-xml/and.owx

Both are generated from the same OWL API model.

[ignazio1977]

Interesting - the prefix isn't actually used in the ontologies, if I'm not mistaken.

[phillord]

The URL for the prefix is the default namespace, so the prefix itself isn't used no.

This is generated by Tawny-OWL, so it's built on version 4 of the OWL API. I need to switch at some point, but it will need time.