Yes, the title almost sounds like a silly washing powder ad, but version 2 of TDDonto really does more than the TDDonto tool for Test-Driven Development of ontologies [1,2] that was introduced earlier this year. There are two principal novelties, largely thanks to Kieren Davies (also at UCT): more types of axioms are supported—arbitrary class expressions on both sides of the inclusion and ABox assertions—and differentiated test feedback beyond just pass/fail/unknown. TDDonto2 obviously still uses a test-first approach rather than test-last for ontology authoring, i.e., checking whether the axiom is already entailed in the ontology or would cause problems before actually adding it, saving yourself a lot of classification time overhead in the ontology authoring process.
On the first item, TDDonto (or TawnyOwl or Scone) could not handle, e.g., or some domain restriction , or whether some individual is different/same from another. TDDonto2 can. This required a new set of algorithms, some nifty orchestration of several functions offered by an automated reasoned (of the DL/OWL variety), and extending the Protégé 5 functionality with parsing Manchester syntax keyword constructs for individuals as well (another 3600 lines of code). The Protégé 5 plugin works. Correctness of those algorithms has been proven, so you can rely on it just like you can with the test-last approach of add-axiom-and-then-run-the-reasoner (I’ll save you from those details).
On the second item (and also beyond the current TDD tools): now it can tell you not only just ‘pass’ (i.e., the axiom is entailed), but the ‘failed’ has been refined into the various possible cases: that adding the axiom to the ontology would cause the ontology to become inconsistent, or that it would cause a class to become unsatisfiable (incoherent), or it may be neither of the three (absent) so it would be ‘safe’ to add the axiom under test to the ontology (that is: at least not cause inconsistency, incoherence, or redundancy). Further, we’ve added ‘pre-real TDD unit test’ checks: if the ontology is already inconsistent, there’s no point in testing the axiom; if the ontology already has unsatisfiable classes, then one should fix that first; and if there is an entity in the test axiom that is not in the ontology, then it should be added first.
The remainder of the post mainly just shows off some of the functionality. Put the JAR file in the plugins directory, and then put it somewhere via Window – Views – Ontology views – TDDonto2. As toy ontology, I tend to end up with examples of the African Wildlife Ontology, which I use for exercises in my Ontology Engineering course, but as it is almost summer holiday here, I’ve conjured up a different example. That test ontology contains the following knowledge at the start:
The first test is to see whether , to show that TDDonto2 can handle class expressions on the left-hand side of the inclusion axiom. It can, and it is clearly absent from the toy ontology; see screenshot below, first line in the middle section. Likewise for the second and third test, where a typical novice ontology authoring mixup is made between ‘and’ and ‘or’, which different test results: one is absent, the other entailed.
Then some more fun: the pool braai. First of all, PoolBraai is not in our ontology, so TDDonto2 returns an error: it can be seen from Protégé’s handling (red dotted line below PoolBraai and red-lined text box in the screenshot above), and TDDonto2 will not let you add it to the set of tests (pop-up box, not shown). After adding it and testing “PoolBraai SubClassOf: Pool and Braai”, then if we were to add that axiom to the ontology, it will be incoherent (because Pool and Braai are disjoint):
That is, we failed a precondition, because PoolBraai is unsatisfiable, so no tests are being executed until this is fixed. Did I make this up just to have a silly toy ontology example? No, the pool braai does exist, in South Africa at least: it is a stainless steel barbecue table-set that one can place in a small backyard pool. So, we remove from the ontology and add , so that we can do a few more tests.
Let’s assume we want to explore more about accommodations and their facilities, and add some knowledge about that (tests 5-7):
Finally, let’s check something about any instances in the ontology. First, whether LagoonBeach is a hotel “LagoonBeach Type: Hotel”, which it is (with a view on Table Mountain), and whether it also could be a B&B, which it cannot be, because hotel and B&B are disjoint. Adding another individual to the ontology for the sake of example, SinCity (an owl:Thing), we want to know whether SinCity can be the same as LagoonBeach, or asserted as different (the last two test in the list): the tests return absent, i.e., they can be either, for nothing is known about SinCity.
Now let’s remove a selection of the tests because they would cause problems in the ontology, and add the remaining five in one go:
And, finally, a few arbitrary ones that are ontologically a bit off, but they show that yes, something arbitrary both on the left-hand side and right-hand side of the inclusion (or equivalence) works (first test, below), disjointness still works (test 2) and now also with arbitrary class expressions (test 5), and the same/different individuals can take more than two arguments (tests 3 and 4).
The source code and JAR file are freely available (GPL licence) to use, examine, or extend. A paper with the details has been submitted, so you’ll have to make do with just the tool for the moment. If you have any feedback on the tool, please let us know.
 Keet, C.M., Lawrynowicz, A. Test-Driven Development of Ontologies. 13th Extended Semantic Web Conference (ESWC’16). H. Sack et al. (Eds.). Springer LNCS vol. 9678, pp642-657. 29 May – 2 June, 2016, Crete, Greece.
 Lawrynowicz, A., Keet, C.M. The TDDonto Tool for Test-Driven Development of DL Knowledge bases. 29th International Workshop on Description Logics (DL’16). April 22-25, Cape Town, South Africa. CEUR WS vol. 1577.