Improved! TDDonto v2—more types of axioms supported and better feedback

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., Carnivore \sqcup Herbivore \sqsubseteq Animal or some domain restriction \forall eats.Animal \sqsubseteq Carnivore , 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 in text and with screenshots (UPDATE 13-3-2017: we now also have a screencast tutorial [177MB mov file]). 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:

ServiceObject \equiv Facility \sqcup Attraction

Pool \sqsubseteq Facility

Braai \sqsubseteq Facility

Pool \sqcap Braai \sqsubseteq \bot

Hotel \sqsubseteq Accommodation

BedAndBreakfast \sqsubseteq Accommodation

BedAndBreakfast \sqcap Hotel \sqsubseteq \bot

Facility \sqsubseteq \exists offeredBy.Accommodation

Hotel \sqsubseteq =1 offers.Pool

Hotel(LagoonBeach)

The first test is to see whether \exists offeredBy.Accommodation \sqsubseteq Facility , 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.

poolbraaimissingThen 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):

poolbraaiwillbeincoherentDoing this nonetheless by selecting the axiom and adding it to our ontology by pressing the “Add selected to ontology”:

poolbraaiaddedand running all tests again by pressing the “Evaluate all” button (or select it and click “Evaluate selected”), the results look like this:

poolbraaifailedpreconditionThat 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 PoolBraai \sqsubseteq Pool \sqcap Braai from the ontology and add PoolBraai \sqsubseteq Braai , 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):

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

instances

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:

5addedThis change requires one to classify the ontology, and subsequently you’re expected to run all the tests again to check that they are all entailed and do not cause some new problem, which they don’t:

testagain

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

extras

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.

 

References

[1] 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.

[2] 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.

Advertisements

2 responses to “Improved! TDDonto v2—more types of axioms supported and better feedback

  1. Pingback: Robot peppers, monkey gland sauce, and go well—Say again? reviewed | Keet blog

  2. Pingback: Our ESWC17 demos: TDDonto2 and an OWL verbaliser for isiZulu | Keet blog

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s