Robot peppers, monkey gland sauce, and go well—Say again? reviewed

The previous post about TDDonto2 had as toy example a pool braai, which does exist in South Africa at least, but perhaps also elsewhere under a different name: the braai is the ‘South African English’ (SAE) for the barbecue. There are more such words and phrases peculiar to SAE, and after the paper deadline last week, I did finish reading the book Say again? The other side of South African English by Jean Branford and Malcolm Venter (published earlier this year) that has many more examples of SAE and a bit of sociolinguistics and some etymology of that. Anyone visiting South Africa will encounter at least several of the words and sentence constructions that are SAE, but probably would raise eyebrows elsewhere. Let me start with some examples.

Besides the braai, one certainly will encounter the robot, which is a traffic light (automating the human police officer). A minor extension to that term can be found in the supermarket (see figure on the right): robot peppers, being a bag of three peppers in the colours of red, yellow, and green—no vegetable AI, sorry.

How familiar the other ones discussed in the book are, depends on how much you interact with South Africans, where you stay(ed), and how much you read and knew about the country before visiting it, I suppose. For instance, when I visited Pretoria in 2008, I had not come across the bunny, but did so upon my first visit in Durban in 2010 (it’s a hollowed-out half a loaf of bread, filled with a curry) and bush college upon starting to work at a university (UKZN) here in 2011. The latter is a derogatory term that was used for universities for non-white students in the Apartheid era, with the non-white being its own loaded term from the same regime. (It’s better not to use it—all terms for classifying people one way or another are a bit of a mine field, whose nuances I’m still trying to figure out; the book didn’t help with that).

Then there’s the category of words one may know from ‘general English’, but are by the authors claimed to have a different meaning here. One is the sell-outs, which is “to apply particularly to black people who were thought to have betrayed their people” (p143), though I have the impression it can be applied generally. Another is townhouse, which supposedly has narrowed its meaning cf. British English (p155), but from having lived on the isles some years ago, it was used in the very same way as it is here; the book’s authors just stick to its older meaning and assume the British and Irish do so too (they don’t, though). One that indeed does fall in the category ‘meaning restriction’ is transformation (an explanation of the narrower sense will take up too much space). While I’ve learned a bunch of the ‘unusual’ usual words in the meantime I’ve worked here, there were others that I still did wonder about. For instance, the lay-bye, which the book explained to be the situation when the shop sets aside a product the customer wants, and the customer pays the price in instalments until it is fully paid before taking the product home. The monkey gland sauce one can buy in the supermarket is another, which is a sauce based on ketchup and onion with some chutney in it—no monkeys and no glands—but, I’ll readily admit, I still have not tried it due to its awful name.

There are many more terms described and discussed in the book, and it has a useful index at the end, especially given that it gives the impression to be a very popsci-like book. The content is very nicely typesetted, with news item snippets and aside-boxes and such. Overall, though, while it’s ok to read in the gym on the bicycle for a foreigner who sometimes wonders about certain terms and constructions, it is rather uni-dimensional from a British White South African perspective and the authors are clearly Cape Town-based, with the majority of examples from SA media from Cape Town’s news outlets. They take a heavily Afrikaans-influence-only bias, with, iirc, only four examples of the influence of, e.g., isiZulu on SAE (e.g., the ‘go well’ literal translation of isiZulu’s hamba kahle), which is a missed opportunity. A quick online search reveals quite a list of words from indigenous languages that have been adopted (and more here and here and here and here) such as muti (medicine; from the isiZulu umuthi) and maas (thick sour milk; from the isiZulu amasi) and dagga (marijuana; from the Khoe daxa-b), not to mention the many loan words, such as indaba (conference; isiZulu) and ubuntu (the concept, not the operating system—which the authors seem to be a bit short of, given the near blind spot on import of words with a local origin). If that does not make you hesitant to read it, then let me illustrate some more inaccuracies beyond the aforementioned townhouse squabble, which results in having to take the book’s contents probably with a grain of salt and heavily contextualise it, and/or at least fact-check it yourself. They fall in at least three categories: vocabulary, grammar, and etymology.

To quote: “This came about because the Dutch term tijger means either tiger or leopard” (p219): no, we do have a word for leopard: luipaard. That word is included even in a pocket-size Prisma English-Dutch dictionary or any online EN-NL dictionary, so a simple look-up to fact-check would have sufficed (and it existed already in Dutch before a bunch of them started colonising South Africa in 1652; originating from old French in ~1200). Not having done so smells of either sloppiness or arrogance. And I’m not so sure about the widespread use of pavement special (stray or mongrel dogs or cats), as my backyard neighbours use just stray for ‘my’ stray cat (whom they want to sterilise because he meows in the morning). It is a fun term, though.

Then there’s stunted etymology of words. The coconut is not a term that emerged in the “new South Africa” (pp145-146), but is transferred from the Americas where it was already in use for at least since the 1970s to denote the same concept (in short: a brown skinned person who is White on the inside) but then applied to some people from Central and South America [Latino/Hispanic; take your pick].

Extending the criticism also to the grammar explanations, the “with” aside box on pp203-204 is wrong as well, though perhaps not as blatantly obvious as the leopard and coconut ones. The authors stipulate that phrases like “Is So-and-So coming with?” (p203) is Afrikaans influence of kom saam “where saam sounds like ‘with’” (p203) (uh, no, it doesn’t), and as more guessing they drag a bit of German influence in US English into it. This use, and the related examples like the “…I have to take all my food with” (p204) is the same construction and similar word order for the Dutch adverb mee ‘with’ (and German mit), such as in the infinitives meekomen ‘to come with’ (komen = to come), meenemen ‘to take with’, meebrengen ‘to bring with’, and meegaan ‘to go with’. In a sentence, the mee may be separated from the rest of the verb and put somewhere, including at the end of the sentence, like in ik neem mijn eten mee ‘I take my food with’ (word-by-word translated) en komt d’n dieje mee? ‘comes so-and-so with?’ (word-by-word translated, with a bit of ABB in the Dutch). German has similar infinitives—mitkommen, mitnehmen, mitbringen, and mitgehen, respectively—sure, but the grammar construction the book’s authors highlight is so much more likely to come from Dutch as first step of tracing it back, given that Afrikaans is a ‘simplified’ version of Dutch, not of German. (My guess would be that the Dutch mee- can be traced back, in turn, to the German mit, as Dutch is a sort of ‘simplified’ German, but that’s a separate story.)

In closing, I could go on with examples and corrections, and maybe I should, but I think I made the point clear. The book didn’t read as badly as it may seem from this review, but writing the review required me to fact-check a few things, rather than taking most of it at face value, which made it turn out more and more mediocre than the couple of irritations I had whilst reading it.

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

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

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

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

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:

This 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:

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.

 

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.