https://keet.wordpress.com/feed

If it were a LinkedIn post, I suppose I’d be expected to write what I’ve learned, how it made me a better person, give advice for newbies, and how humbled I am with the continued support from the subscribers and casual readers alike. Probably,and I did so before. It’s also my soapbox, and science communication and self-promotion tool. Did I intend and plan any of it 20 years ago? Well…

On plans and intentions

Once upon a time, in the distant past of 2006 when I was a PhD student in a fairly dull and sleepy provincial town, after the dot-com bubble had burst but before the ‘great recession’ of 2007-2009 hit, when Facebook hired its first intern and had yet to open to the public, Amazon commenced with its Cloud and Nintendo launched the Wii, Instagram and WhatsApp didn’t exist yet, and at the height of the Semantic Web …

I didn’t intend to learn to write better, yet it happened along the way.

I didn’t plan to write a textbook, yet the seeds were planted with a couple of blog post.

I didn’t intend or plan to pick up varied knowledge along the way, yet I did, from culinary evolution in the early days, among many topics, to recent digging into the fruit vs vegetable debate when I tried to make ontology more accessible. Adapting posts for general public articles came along the way as well, on the ontology of pandemic and on NLP for isiZulu and isiXhosa, which is not bad for science and teaching communication as a hobby of sorts. I doubt all that would have happened without the blog, and I hope you think that the time reading the posts with the preliminary content was spent well.

What did I intend? I looked up my first post: “that the information I add to the huge pile may occasionally be of some use to somebody, somewhere, some time.” and, with blogs being different from static webpages that were the norm at the time, that it “enables m:n interaction with comments and even discussions.”. The latter happened in the early years, but blogs gradually were sidelined due to the rise of the walled gardens of social media apps, and the potential issues with, and therefore increased avoidance of, leaving behind too many digital breadcrumbs didn’t help either. I do receive feedback offline, and it ticks off the first reason.

What did I plan? The first post is just as illuminating: “I’m giving it a try and see where it ends up.”, or: not much of a plan. And yet, here we are. I didn’t entirely muddle along. The posts’ topics followed career progression: they went from a variety of topics including my research areas, to more about my own research and some teaching, to a mix of own research and teaching and reading/writing and a bit of ethics, all sprinkled with unvarnished opinions across the years. Writing posts has become a habit, if not a compulsion.

I still read many posts, too, and principally those that have something to say. Last month alone included posts over at Where’s your Ed at by Ed Zitron on the AI bubble, Sam Bent’s post tracing the age verification in Linux, and LSE book review of ‘dark academia: how universities die’. I even visited Substack, because David Happe’s tale of the disconcerting “after you’re gone” patent to Meta just had to be read as well, and I looked up stuff for last month’s post, which landed me on posts like this and that one, among others. They deserve mention for the same selflessness of looking up information, writing about it, and making it available, like I do, and linking still counts in the blogosphere even when we don’t make a single cent with it.

I do have ideas, plans, and drafts for more posts than that I end up posting, which fizzled out mostly due to time constraints caused by other activities with a higher priority. The graveyard of unfinished posts and abandoned ideas is littered more with additional topics that piqued my interest than with half-baked drafts about the papers I co-authored and tools I co-developed. Also, I’m aware I largely missed the popularity window of AI and ethics posting, where I easily could have written many posts if only I hadn’t been teaching and doing research and admin and management and service to the community as much as I did.

Anyone who’ll tell you blogging is easy to do and takes little time when you write every word yourself, is either lying or only goes as far as superficial drivel. Even after all these years, I write and rewrite, and review and rewrite and review and format, and try to find or make some attention-catching images to brighten up a post, and apply other finishing touches. And still I flinch scanning over some of the older posts.

Memory lane of blogging

The blog is that old that we can look back on looking back, for what it’s worth it. There’s my 5-years celebration blog post, with as opening lines: “Was it worth the effort? Yes, for two reasons.”, and one after 8 years. At the 10-year mark looking back, I decided I had extensive experience blogging and wrote a list of pros and caveats of blogging, which actually still holds. I skipped the 15th year mark – that April was a hectic month in COVID times – but assessed statistics and wrote reflections ‘nearing 16’, and posted a one-liner on mastodon about turning 18 years when WordPress notified me I had published a whopping 364 317 words by then.

Here are a few screenshots thanks to the wayback machine that, at times, preserved the chosen theme, and at times, not. I didn’t pick them on purpose, but selected randomly and waited patiently for each page to load. The awful layout of the images is due to WP, not me; I tried for 30 minutes to get it right and overrule their ‘second-guessing’, but alas.

Now I really have to write something again, because it turns out that there are remarkably few blogs that have survived this long. Is it the oldest continuously running blog? No, that honour goes to Justin Hall’s blog, which runs since 1994 or since 1993 on the cusp of 1994 (with screenshots). PR Tech lists Instapundit (since 1998? since 2001?) and Weblogs Inc. as a platform for blogs (since 1999, but 2024 saw a shake-up of the handful remaining ones) as deserving the claim for second-longest running blogs. Blogger with blogspot started in 1999, WordPress in 2003. They were the two main options when I started in 2006. Blogspot was whimsical and unserious, and seems to have fizzled out in the meantime; WordPress hosted somewhat more serious and professional blogs, and has evolved into a major website hosting platform.

WordPress is ok-ish, with some nuisances of occasional changes at the back-end and especially on taking away the control of layout, and I still wish they’d offer the option to pay a yearly fee to have it ad-free without the need to also change the URL. I hate the ads. But losing the URL of 20 years is also undesirable, and so I’m still stuck here in this way. I can’t even make money with those irrelevant ads WordPress pushes on the dot-com instance nor can I opt for even more ads to ‘start making money with your blog’, because WordPress uses Stripe and Stripe doesn’t like South Africa. I added a ‘donate’ button a while ago, but no-one donated a single cent. No doubt OpenAI and other LLM data munchers ingested my posts and they ought to pay me something for providing content, and even that damage payout would be too little, because just that I provide content for free for people to read doesn’t entail I gave permission to have it all used by irresponsible LLM tool developers and users.

Some statistics

On the bright side, let’s look at some numbers and put them in context:

• I wrote 382 posts and there are a total of 356 comments.
• Number of words: it was 364 317 in April 2024 already, when the blog turned 18, so about 400K words now. That’s equivalent to about 4 romance/mystery/thriller/crime novels, 3-4 ScFi books, 2-3 Harry Potter books, roughly one of George Martin’s GoT books, or heading towards the length of Gone with the wind. For non-fiction book estimates: the number of words amounts to some 7-8 self-help books, 6 business books, or 4-8 ‘big idea’ books.
• The XML export of just the posts (without images or comments): a 6.3 MB file.
• Top-3 most visited posts of all time:
  • https://keet.wordpress.com/2011/04/20/google-searches-sneaky-academia-edu-and-data-duplication/ (unvarnished opinion)
  • https://keet.wordpress.com/2009/11/20/72010-semwebtech-lectures-34-ontology-engineering-top-down-and-bottom-up/ (one of the seeds that evolved into two chapters in the ontology engineering textbook)
  • https://keet.wordpress.com/2014/06/28/acm-icpc-2014-solution-to-problem-a-baggage/ (related to teaching, when I was coach of the UCT team that went to the ICPC world finals in team programming)
• Most visitors per month: 2.2K in March 2025, mainly thanks to assessing whether developing an ontology from an LLM is really feasible (I think not)
• Most shares: on Facebook, then Reddit as distant second
• Most popular time: Wednesday

WordPress will have more statistics, but these are the interesting titbits I had access to.

Final remarks

My 10 years and nearing-16 years reviews summed up the blogging insights already and rest me to add that this blog apparently is now one of the remarkable ones among the continuously operating blogs. That doesn’t make me an ou tannie; it illustrates how transient blogs, websites, and the Web at large can be.

If you’re fence-sitting and even if you wouldn’t want to post your posts publicly, I can recommend giving it a try: it might just work out somehow. On your own instance; not LinkedIn (it has multiple issues), nor Substack (issues with content and funding) or Medium (a list of issues). There are plenty of ISPs that offer cheap combos of domain name + blogging software to get you started. Moreover, [if/assuming] it is not your work and you want your blogging to last, write what you want to write about, not what you feel you have to write about, nor waste time second-guessing the potential reader’s interests (though I do look into it sometimes).

My lower bound of at least one post per month on average is sustainable and I’m still not bored with writing short pieces, so more post will appear at least in the near future. There are passing moments where I’d like to receive more visitors, likes, shares, and comments, just like everyone else would, but not receiving a whole lot of responses won’t stop me from writing.

Thank you all for the ride so far!

We’ve been working on devising a generic system that can generate educational questions, answers, and explanatory feedback from ontologies. Not tailored to only one ontology, but feeding it any ontology and still obtain decent output, and not MCQs, but other sorts of questions, like Yes/No, true/false, short answer, and so on, for type-level questions. It sounded like a doable problem to solve when we started out: select a few types of questions, add clever templates, define which axiom types each type of question requires, and voilà. Not quite.

A few problems

We first tried to improve the output by adding some guidance from a foundational ontology and by adding additional NLP support to improve question and answer generation – the latter approach won in the comparison [1], although the output still isn’t perfect because of so many corner cases and suboptimal naming of vocabulary. For instance, a human reading the label “American” as subclass of “Pizza” in the Protégé GUI will get the intention of that subclass, but question generation can lift classes out of their context and so a sentence “Does an American have cheese as topping?” will raise the eyebrows of a human evaluator.

More problematic was that the question, answer, and feedback management ended up a bit messy and ad hoc, and retrieving the axioms matching the respective axiom patterns was of the brute-force variety, i.e., slow, and therefore it didn’t scale well to large ontologies. Alternatives, such as using SPARQL queries or SWRL rules for generating questions, have their own issues, primarily of reusability and expressiveness. Relaxing the search or generating every possible sentence from the ontology has as downside that it requires a technique to filter out irrelevant questions, answers, and feedback, which is also a non-trivial problem to solve, and also still faces the scalability problem. Limiting expressiveness to gain performance has as downside that it reduces the type of questions that can be asked and feedback generated to very simple knowledge recall and trivial feedback only.

In contrast, consider the simple-looking question “Does each bicycle have some spokes as parts?”. It requires existential quantification and transitivity of hasPart to be able to generate the question and answer it with ‘yes’, based on the axioms (simplifying the notation) Bicycle hasPart some Wheel, Wheel hasPart some Spoke and Transitive(hasPart), which instantiate the prerequisites, specified as an axiom pattern set consisting of {C R some D, D R some E, Transitive(R)}. The question sentence structure needs some sort of template or grammar for it to be generated in the proper way, like a “Does each [C] some [R] [E]?”, as would a pattern for feedback beyond a mere ‘yes’, such as “Yes, because [C] some [R] [D] and [D] some [R] [E] and since [R] is transitive, [C] some [R] [E] is true.”. The sentences can vary, too, so as not to make them stale and repetitive, like another template that generates the same question worded differently: “Do all bicycles have at least one spoke as part?”. And questions that will return ‘no’ or ‘false’, where the transitivity statement is missing in the ontology, or either of the other two prerequisites. And so on and so forth, keeping track of them all, and doing that efficiently. We initially tried to scope the question and answer management components and interactions with “question cards” and a basic overall architecture of such as system [2], but that missed details the feedback part, it didn’t take full advantage of the logic and automated reasoning, and efficient content selection was out of scope.

Our solution

To do the question, answer, and feedback management with the axioms systematically and rigorously, we – mostly my PhD student Toky Raboanary, to be honest – developed a question, answer, and feedback framework together with an efficient content selection algorithm to get the job done. Those details and the evaluation thereof are described in the ESWC 2026 research paper entitled “Ontology-Mediated Framework for Generating Answerable Questions and Feedback from Ontologies” [3].

How does it work? This is summarised in the following figure. We take the ontology as content, and out comes a guaranteed to be semantically correct question, answer, and feedback. Well, semantically correct according to the knowledge represented in the ontology. If your ontology contains mistakes, they’ll propagate, but that’s a different sort of problem (and I have a few suggestions for that, too).

Let’s explain it forwards, from what you can squeeze out of the ontology:

1. We have an ontology; say, the African Wildlife Ontology, and it has a bunch of axioms; among others, there’s Lion eats some Impala, Lion is-a Carnivore, Carnivore is disjoint from Herbivore, Impala is-a Animal and so on all the way up to exploiting all the SROIQ/OWL 2 DL language features.

2. We have types of educational questions; for instance, Yes/No questions. (We have 10 types of educational questions, actually, and the framework should work with other types of questions as well.)

3. To be able to generate a Yes/No question from the ontology, the ontology needs to have certain content, and not all Yes/No questions are the same. For instance a “Is a lion a herbivore?” versus “Do lions eat impalas?”: the former requires a simple subsumption axiom between two atomic classes, whereas the latter requires a class expression with an object property. This gives rise to the notion of prerequisites for the presence of certain axioms in an ontology for each question type, and therefore certain types of axioms. The former needs the C⊑DC \sqsubseteq D pattern and the latter needs the C⊑∃R.DC \sqsubseteq\exists R.D pattern. We also need this for the answer, and, if such a system is to be educational, feedback or an explanation of why the answer is right.

4. Feedback generation will have its own set of patterns to be able to generate it, well beyond the simple ‘yes’ or ‘no’ for answer. For instance, to generate “No, a lion is not a herbivore: it can’t be, because a lion eats impalas and impalas are animals. Herbivores eat only plants, and plants are not animals.”, it needs not only that C⊑DC \sqsubseteq D (to generate the question, to find that lion is a carnivore and that impalas are animals), but also a disjointness C⊑¬DC \sqsubseteq \neg D (a herbivore not being a carnivore, plants not being animals), and axioms matching the C⊑∃R.DC \sqsubseteq\exists R.D pattern (lions eating impalas). It also needs some sort of template or other mechanism to realise the sentence from the relevant set of axioms it will extract from the ontology.

Obviously, both the question and the feedback can reappear in other contexts all the same, or reworded into different types of questions where merely the surface rendering changes, such as “Lions are herbivores. True of false?”, or demand more from the ontology’s content with a “Fill in the blank: lions are …. [choose from: carnivore, herbivore, omnivore].”. The fill-in-the-blank needs to have extracted from the ontology those classes that are disjoint from carnivore.

Systematising declaring all this information is governed by the framework described in the paper, whose metamodel itself is formalised in OWL 2 DL, so that it can call upon the automated reasoner to check whether you’ve declared your model right, or at least have not made contradicting statements in specifying question and feedback patterns. Each set of patterns of questions, feedback, and prerequisites amounts to a particular model.

5. This model is then given to an optimised ontology content selection algorithm that we developed (see paper for details) that is also fed the ontology from which you want to generate the questions. The output of that step are the axioms extracted from the ontology that all match. With our African Wildlife Ontology, it will not only find all the axioms for lions eating impalas and being carnivores, but also giraffes eating twigs and leaves and being herbivores, and likewise for the elephants and warthogs. If we’d specified 3 types of questions and feedback, we’d obtain the content for 12 question and feedback. If each type of question was linked to two surface renderings (e.g., in the singular and in the plural, to prevent rote learning), the output would be good for 24 questions. It escalates quickly.

For our bicycle with its spokes, the ontology needs to have content to satisfy all three axiom patterns. If it doesn’t (e.g., it is an ontology in OWL 2 QL), then that type of question with feedback cannot be generated. If there’s no disjointness, it won’t be able to generate the fill-in-the-blank with answer options. Conversely, if the ontology contains knowledge that uses advanced language features – any one permitted in OWL 2 DL – then you’ll be able to generate more types of questions and feedback than any prior work.

Wrapping up

Besides the theoretical details, Toky also implemented the framework with the optimised content selection algorithm and we stress-tested it with AWO and EXMO and a number of different models to assess the concrete effects of the speed-up with the optimised algorithm, which was comparatively good on the whole (see paper for details). It also should be possible to declare questions and feedback that do not have one of the specific structures of typical educational questions, such as pop quizzes and competency questions, though we did not test that.

Note that the realiser – i.e., that part of natural language generation pipeline that aims to generate orthographically and grammatically correct sentences – is outside the scope of this paper. Put differently: you can choose your preferred realiser, be it template-based, grammar-based, LLM-based, or whatever, and in whichever natural language. We solved the content determination and selection step so that all those NLP-focussed researchers and practitioners won’t have to and instead can start with good quality and comprehensive input to improve on those tasks.

It’s not easy to represent knowledge in an ontology, and now we have another, and better, way of exploiting that knowledge for more tasks, thereby enabling getting more ‘bang for your ontology development buck’. I hope you will.

If all goes as planned, Toky will present the paper at ESWC 2026. If it won’t, I will find the money to attend the conference (that yet again has a suspiciously high registration cost well above even higher ranked conferences), assuming (well, hoping) there won’t be a force majeure because of the war.

References

[1] Raboanary, T., Wang, S., Keet, C.M. Generating Answerable Questions from Ontologies for Educational Exercises. 15th Metadata and Semantics Research Conference (MTSR’21). Garoufallou, E., Ovalle-Perandones, M-A., Vlachidis, A (Eds.). Springer CCIS vol. 1537, 28-40.

[2] Raboanary, T., Keet, C.M. An Architecture for Generating Questions, Answers, and Feedback from Ontologies. 16th Metadata and Semantics Research Conference (MTSR’22), Garoufallou, E., Vlachidis, A. (eds). 7 Nov – 10 Nov. London, UK. Springer CCIS vol 1789, pp135-147. 2023.

[3] Raboanary, T., Keet, C.M. Ontology-Mediated Framework for Generating Answerable Questions and Feedback from Ontologies. Proc. of ESWC’26, Dubrovnik, Croatia, 10-14 May 2026.

People ask me questions from time to time that are squarely in the realm of professional ethics, probably because I’ve taught computer ethics for a good number of years, co-authored lecture notes on social issues & professional practice (now called ‘society, ethics, and the profession’), and I wrote a collection of short stories that fictionalised several computing issues. I don’t have all the answers to everything, but some are easier to respond to and some of those questions re-occur in different settings. Take, for instance: Should you tell the client about particular software errors, notably those bugs that affect the core functionality of the application? Should you withdraw an accepted paper-with-code when you discover a bug that affects the reported results to the extent it changes the conclusions? The answer to the latter question is easy and unequivocally ‘yes!’ and research ethics training in academia is hopefully up to scratch everywhere. But what about the former question in industry? Does that make a difference? Aren’t both questions about integrity, transparency, and honesty, as components of trustworthiness and professionalism, and therefore ‘yes’ too, regardless the circumstances?

Anonymising a recent instantiation of that question and the short answer from among the options turns out non-trivial, even when ‘recent’ can be taken with a grain of salt because I’m woefully behind in writing blog posts. Nonetheless, just in case, I’ll include a few options in this post. (If you prefer to read relevant fiction instead: see ‘radiating confidence’ and ‘the switch’ short stories in the collection).

The basic scenario is as follows:

Imagine you’re the [team leader/manager/boss/CEO] of a group of software developers that has developed, and is responsible for, the maintenance of the FunkyFizzBuzzBorg app. The client’s main requirement is that it does fizzbuzz. They don’t have the competency to check that the app indeed carries out fizzbuzz and they are entrusting you as the expert that it fizzbuzzes, and does so correctly. FunkyFizzBuzzBorg has been taken online and is in operation. Now you’ve discovered that the app does the fizzing but not the buzzing, or: it actually does not operate according to the main software requirements. What should you do?

There are a number of options:

• Inform the client about the particular software error, and then either
  • leave it at that, or
  • ask the client for more money to fix it so that it also buzzes, or
  • fix it on your own costs.
• Quietly fix buzz and include it in a software update release without clearly mentioning that it now finally also buzzes.
• Hope the client won’t find out the app is fizzing but not buzzing and shove the issue under the carpet until the client finds out, if ever.

Obviously, the last option is unprofessional, even for software developers that aren’t legally speaking practicing a profession (not like medical doctors, engineers, and lawyers do – a separate debate not pursued here). This still leaves at least four options from the list. Before we narrow it down, your answer may be swayed by three categories of further details.

First, there may be complicating factors regarding fizzbuzz itself, like whether it’s harmful that FunkyFizzBuzzBorg isn’t buzzing, in that people could or will get ill from its faulty operation or the environment is polluted because of it, or it causes legal issues in that now the client is breaking the law because the app isn’t buzzing. This is an outcomes-based consideration, and decidedly a utilitarian take on the issue; others may be a deontologist or aspiring to virtues and thereby be more concerned with the actions, or lack thereof, than whether the app’s bug is harmful or not.

Second, why is FunkyFizzBuzzBorg not buzzing? There may be several reasons, for instance:

• You acted in good faith and were competent, just not competent enough for this task, but nor would your competitors have done any better job at delivering fizzbuzz.
• You grossly overestimated your competence and overpromised; any similar company would have implemented fizzbuzz correctly easily.
• The software design was good, but internal software testing processes fell short and therefore failed to catch that the software wasn’t buzzing.
• Delivering fizzbuzz was difficult from the design stage, due to your sub-optimal design.
• The client was difficult from the design stage, with a problematic design and tooling choice for implementing fizzbuzz, on insistence of the client despite your advice for a more suitable design.

Third, we have to consider the type of relation you have with the client, which also relates to the last item in the preceding list (the difficult client). The relations can be either one of the following three:

• Agency, or rather the lack thereof: you and the software developers as professionals do exactly what the client instructs you to do, even if it is not the optimal choice. A lack of agency suggests you may not be held morally responsible (but one may have the choice to walk out if the client’s choice is just too bad).
• Paternalistic: you as the professional make all the decisions for the client, and thus the client has abrogated all the decision-making to you as the presumed or actual expert. You’re responsible, although there may be tricky issues to untangle about whether the client is in the right to have handed over such a responsibility.
• Fiduciary: you and the client work together based on trust. You offer options and the client makes informed decisions. You do this ethically (e.g., no conflict of interest) and the non-expert client upskills enough to ensure they are well-informed to make decisions. If the decision-making happens based on consensus, then there is also a notion of a shared responsibility of the choices made.

Theoretically, all these parameters result in a very large number of detailed scenarios. Practically, they’re not all equally realistic. For instance, a paternalistic relationship doesn’t go with the enforcement of the client’s design, nor would lack of agency with your design.

If your relation with the client is paternalistic, you messed up in your design, and you messed up in software development processes by not implementing and testing the software properly, then you’re clearly responsible and therefore you have to fix it on your own costs. You should tell the client as well, especially if the non-functioning of fizzbuzz is harmful. There are a number of famous software screw-ups and the handling of it, ranging from the deadly THERAC-25 to Intel’s FDIV “trivial” corner case.

If you acted in good faith and were competent and don’t have any agency because the client insists on being in control, I think you could ask for money to fix it. Remaining silent and shoving it under the carpet is definitely not a good idea: while you may not be responsible, you can act responsibly and with integrity. Doing so also aligns with many codes of practice, conduct, and ethics, such as that of the IITPSA, BCS, ACM, and IEEE, and you have the knowledge and choice to do so. One could counter that if you’re not a member of an IT & computing organisation you don’t have to adhere to their/such professional practices, but aren’t you shooting yourself in the foot then if you want to be a professional software service provider? Or: who in their right mind and who has specialised for years in software programming aspires to be an unprofessional software provider?

Incompetence and overconfidence is unfortunately a pervasive problem, due in part to that software engineering is not a protected profession. Anyone and their mama’s can download a textbook or watch a few youTube videos, vibe-code a low-code app together, and call themselves a software developer or programmer. They are not. Situational incompetence contributes to this category as well; e.g., someone having been hired as an IT manager but who doesn’t know what software engineering entails. The list of famous mistakes is long. The Mars Climate Orbiter Mishap is one of those: NASA’s software assumed the input was in metric units but it was delivered in imperial units, which caused a miscalculation in the trajectory and the disintegration of the spacecraft when it entered the Martian atmosphere. It came about due to failures in practices (including inexperience and lack of mentorship), in communications, and in testing protocols.

A good number of tools are shipped with bug lists, i.e., errors that are known to exist upon release and that are not considered critical—they’re neither fizz nor buzz—and so this case therefore falls in a different category. If it’s fizz or buzz, however, you can’t just ‘leave it at that’ on or off a bug list. Telling the client may be hard to do, but also may function as a trust-builder for your honesty. Quietly fixing buzz when buzz is not harmful anyway is likely not the best course of action, but it’s better than remaining silent and hoping the client won’t find out. Why? What will you do when they do find out? Lie that you didn’t know, or tell them you did know and deceived them for the past while? For both response options, and no matter the type of relationship with the client, the dishonesty does not reflect well and can result in a breakdown of trust either because of withholding information or of perceived lack of competence (it shouldn’t be the client to find out when they’ve hired you for your expertise).

The quietly-fixing-it route was taken by, among others, YouTube’s views counter fix. The many software patches for, among others, Microsoft products likely will contain a few important bug fixes as well in some of their monthly Patch Tuesday updates, and their infamous blue screen of death. That some take the quiet route doesn’t mean you should, too. There are plenty examples where clients are informed and companies do act proactively; e.g., in February 2026 alone, notable examples from multinationals include NVIDIA’s 595.59 driver that was taken offline for further investigation and Ford recalling trucks due to software issues with brakes.

It is, of course, an entirely different story if you knowingly didn’t make the tool buzz, it harms the environment and breaks the law, you shoved it under the carpet, and thus are deceiving the client. The Volkswagen Defeat Device is a well-known example of that, with consequent culpability accompanied by $14.7 billion to settle, and jail time for engineers and resignations and suspended sentences of top management.

While more scenarios are possible, hopefully the ones described already have provided some useful food for thought if you are in such a situation, and they may help make up your mind to decide what to do if/when it applies to the software you built or oversaw it being built.

There are many resources available to explore the topic further, from longer and shorter academic books with foundations and theories, such as this very recent and short open access book or one of Tavani’s books, and case studies to help thinking through various potential issues before one actually emerges in your company (e.g., here and here).

p.s.: Did any of this occur to me and what did I do, you may wonder. Yes. The most impactful one happened with a conference paper I co-authored a few years ago. I found out there was a problem when I was writing a blog post and stepped through the algorithm manually to work out a new example. It didn’t work. Retracing it with a known example, it became clear that the judgements that the evaluators had provided to the algorithms’ output simply could not be right, and they indeed turned out not to be so. The algorithm had to be improved upon in another round of refinements to obtain the really good outcomes that we had thought we already had. We withdrew the accepted-but-not-yet-published paper, fixed it, carried out another evaluation, added a bit, resubmitted the revision to another (and better quality) conference, and had it accepted and published there.

p.p.s.: Check out the FizzBuzz as programming challenge rather than children’s game.

Let me start the new year with a long overdue topic to write about: low-resourced languages (LRL). If you take English as the benchmark and a calimero attitude of a ‘but they have it much easier with so many resources and that’s not fair’ for computational tasks involving NLP/HLT, then you can complain it’s not easy and unfair for 99.99% of the languages in the world. That’s not helpful to understand what ‘not easy’ really amounts to, nor what the – in many cases unrealistic – implications are of the ignorant (at best) statements along the line of ‘just get yourself together and work a little harder’ attitude, or just how much effort some work has taken even if it looks like mere baby steps from a highly resourced language technologies perspective.

Not just that. Let me cherry-pick a few anecdotes to illustrate. A conversation with a fellow researcher I spoke with at INLG2023 told me he just gets his new high quality annotated data delivered and can readily use it for his research. What?!?! Really?!! Other researchers, be it in NLP or requiring NLP tools for the intended task, have to collect and annotate it themselves, clean it up, and determine quality, or manage it to be done so as part of their research. My fellow researcher was surprised that also I had to do all that extra work in order to have enough results to write it up in a paper. The paper I was still working on at the time (presented at the 2024 edition, a year later [Mahlaza24]), it included trips to the library, online searches for grammar rules, and consulting with the linguists just to get a few examples and rules to begin with to try to work out how to convert numbers to text in isiZulu, and a number of iterations to plug the gaps in the limited rules’ documentation to get to a passable level of correct output. There was no data for good reasons; we generated that data to make it less hard for data-oriented researchers. OCR issues are documented elsewhere, and some can be gleaned from carefully reading between the lines of some of my NLG papers.

I probably could write a book about the anecdotes, but the plural of anecdote isn’t data. Were we just repeatedly unlucky? Didn’t we search hard enough? Do other people – researchers and software developers alike – working with low-resourced languages not have such problems? No, they struggle, too. For instance, having to adapt UD before being able to computerise sentence annotations for St Lawrence Island Yupik [Park21].

What makes it challenging, and could one ‘low-resourced’ be even worse than another ‘low-resourced’, akin to a very low-resourced? I’ve heard a Dutch colleague claiming Dutch was low-resourced, and he was staunchly convinced of it. I shook my head in disbelief and could not resist to comment, as he clearly didn’t know what low-resourced really was like. But it does raise the question: what is low-resourced? What are its characteristics so that it can be distinguished from intermediately resourced and well-resourced?

They’re not new questions and other researchers have tried to answer them with the typical approach of bean counting something: Wikipedia articles, number of corpora, number of tools, number of papers in top-level NLP conferences. They all have issues of missing out in the counting: much of the work on low-resourced languages (LRLs) doesn’t make it into the top-tier conference venues that take English as the gold standard, the number of tools doesn’t tell anything about whether they actually work, and available non-published tools are easily overlooked yet could be really useful, and Wikipedia has skewed editor issues.

For instance, media darling and recent SAICSIT emerging pioneer award winner Prof. Vukosi Marivate doesn’t get much of his work into premier international NLP conferences even though he most definitely uses data-driven techniques for years and managed to set up spin-off company lelapa.ai on NLP for African languages. It is not much different for P-rated Dr Jan Buys for his papers on African languages, who also has been working on data-driven approaches for years, including having a number of papers in the main NLP conferences – just not about African languages. Our trailblazing work before the LLM craze having resulted in, among others, 4 INGL papers, a COLING paper, and a CiCLing paper & prize and and journal articles in TALLIP and LRE on NLP for African languages is notable as well, but it mostly won’t reflect in, e.g., Joshi et al’s top conference paper-based counting [Joshi00]. Prof. (emer.) Laurette Pretorius’ LREC papers and ZulMorph were largely before the resource indexing and open source requirements, and AwezaMed, spellcheckers for MS Office, and so on and so forth would fall through the bean counting cracks as well.

Not being indexed by bean counting scrapers of the researchers from the Global North doesn’t mean nothing is happening. Admitted, variant spellings of names of languages and changes in names of languages hampers the bean counting approach when searching for resources—though locals know. Joshi et al.’s ‘Mbosi’ language search could have been augmented with ‘Mboshi’ and ‘Embosi’ if only they’d known, and then they would have found and included the LREC18 paper [Rialland18], for instance, but, alas.

Is there another way to capture the fuzzy notion of LRL differently? My collaborator, Langa Khumalo, and I set out to take a different, complementary, approach: contextualising the language to determine resourcedness.We focussed on three key issues:

• What are really the distinguishing characteristics of LRLs (and, by extension, ‘non-LRLs’)?
• What are the characteristics of levels of resourcedness?
• Which language fits where and why?

The results are described in detail in our technical report [KeetKhumalo26]: we identified 11 dimensions of resourcedness, their components, and tentative scales or grouping buckets and matched the dimensions to Very LRL, LRL, RL, High RL, Very HRL levels, and assessed its operationalisability with isiNdebele and several other languages.

The dimensions concern the sort of things that actually impact developing NLP tools. For instance, the amount of people: fewer people are harder to find and more in demand, not to mention tens of participants (if that) for crowdsourcing who’d need to be paid internet data upfront to do the evaluation. Or take the participants’ level of education in that language: speaking and writing a language is not the same as a deep grasp to provide 100% correct feedback on the morphological analysis, say, or having received education in the language at least up to matric/high school exams. Less-than-correct feedback requires more rounds of human evaluation, or: takes more time to carry out the evaluations, more time to analyse the data, and more remuneration for the tasks. Or the choice or grammars, or the lack thereof: taking a UD or SUD from the shelf versus digging into old books and poring over various linguistics papers to determine what it is that needs to be represented in any formalism expressive enough to capture it. Having a choice of parsers versus no or outdated software that needs to be brushed up or re-implemented first.

The dimensions and described, motivated, and illustrated over a good 6 pages in the paper. There may be more dimensions, but this already gives a good basis to assess and classify languages, to develop policies to benchmark and assess changes in language resourcedness, for certain people to get down from their English high-horse incorrectly judging efforts for other languages, and to make better sense of ‘LRL paper tracks’ at conferences and workshops. And perhaps anyhow to gain an appreciation of NLP activities when there’s no cornucopia of tools and datasets.

We grouped the dimensions as contributing to characterising Very LRL, LRL, RL, HRL and Very HRL. Admittedly, there’s a notable flip at the RL level that asks for more fine-grained needling and characterising. Yet, the notion of getting the ball rolling being harder than keeping it rolling and amassing more thanks to the bandwagon effect applies to many areas.

We apply the dimensions to isiNdebele, a language spoken in South Africa and Zimbabwe with about 3.7 million first/home-language speakers overall. There are newspapers, TV news bulletins, schoolbooks, a dictionary and more in isiNdebele, i.e., it is actively used in daily life. It turns out that it is in the Very LRL category, albeit noting it’s not all doom and gloom, or: there are a few resources.

The discussion section of the report elaborates on various aspects, including policy implications, and there’s a bonus section on nitpicking about terminology, including low-resource vs. low-resourced vs. under-resourced languages. What can I say, besides NLP, co-author Langa is the Director of the South African Digital Languages Resource centre and I’m an ontologist. The paper’s flavour overall is distinctly on the languages side rather than computation, which may be taken as a warning or an encouragement; either way, I hope you’ll find something of interest in it. Opinions, additions, or your assessment of your language(s) of interest are welcome.

References

[Joshi00] Joshi, Pratik, et al. “The State and Fate of Linguistic Diversity and Inclusion in the NLP World”. arXiv [Cs.CL], 20 Apr. 2020, http://arxiv.org/abs/2004.09095.

[KeetKhumalo26] Keet, C.M., Khumalo, L. Contextualising levels of language resourcedness for NLP tasks. Arxiv report 2309.17035.17 January 2026. https://arxiv.org/abs/2309.17035.

[Mahlaza24] Mahlaza, Z., Magwenzi, T., Keet, C.M., Khumalo, L. Automatically Generating IsiZulu Words From Indo-Arabic Numerals. 17th International Natural Language Generation Conference (INLG’24), Tokyo, Japan, September 23-27, 2024. Association for Computational Linguistics.

[Park21] Park, Hyunji, et al. “Expanding Universal Dependencies for Polysynthetic Languages: A Case of St. Lawrence Island Yupik”. Proceedings of the First Workshop on Natural Language Processing for Indigenous Languages of the Americas, Association for Computational Linguistics, 2021.

[Rialland18] Rialland A, Adda-Decker M, Kouarata G-N, Adda G, Besacier L, et al. “Parallel Corpora in Mboshi (Bantu C25, Congo-Brazzaville)”. 11th Language Resources and Evaluation Conference (LREC 2018), ELRA, May 2018, Miyazaki, Japan.

This is a more concrete follow-up to the previous somewhat theoretical post on ontologies not being just RDF.

I tried hard to think of how other people might approach the syntax issues and assumptions. When I asked someone who’s involved in developing a vocabulary represented in a Turtle document about it, it resulted in a befuddled reply. Maybe there lies a problem. Regardless, I’ve seen a number of people editing the text files directly rather than through a user interface that helps the modeller avoiding making syntax errors. Either way, we’ll look at two documents in this post: SEMIC’s Core Public Event Vocabulary aimed at EU public administration interoperability, because it was the most recent one of all the Core Vocabularies with a published update, and the Financial Industry Business Ontology, because it has so many files, and both are actively maintained and each one has a user community that, to the best of my knowledge, does not overlap.

The Core Public Event Vocabulary CPEV

Having noted the manual editing of the serialisation, I imagine thy need a plain RDF or Turtle syntax checker at least, so let’s try that. The first hit in duckduckgo is the http://ttl.summerofcode.be/ and I copied the Core Public Event Vocabulary (CPEV) into it. And…

Yay! It is valid Turtle syntax. The verdict is satisfying, so why bother looking beyond it? Because we want that type-level vocabulary it claims to be, conformant to OWL so that anyone can use it for their ontology-driven, Semantic Web and W3C standards compliant application, be it to foster interoperability or to serve a stand-alone knowledge-driven software application (or use it in graphRAG if you insist).

Let me try another tool, Protégé, as the go-to ontology editor for most ontology developers that comes with the reliable OWL API, under the assumption that I don’t have any other options. When I try to load and parse the CPEV by URL from the GitHub repository where it is published, i.e., https://github.com/SEMICeu/Core-Public-Event-Vocabulary/blob/master/releases/1.1.0/voc/core-public-event.ttl, it returns a number of syntax errors. There’s that inconvenience of uploading ontologies on GitHub: you have to click the ‘raw’ button, and then load by URL from that URL rather, being https://raw.githubusercontent.com/SEMICeu/Core-Public-Event-Vocabulary/refs/heads/master/releases/1.1.0/voc/core-public-event.ttl. It loads. Downloading the core-public-event.ttl locally and opening it also works, in the sense of opening in Protégé without any imports. No imports were declared, either, although multiple prefixes have been used.

Inspecting the content, curiously, certain fields are empty in the header section (see image on the right). The file itself certainly does have content for those items, using FOAF. There’s also a foaf:Person class with a number of odd instances of the _:genid2147483656 variety, which it is not supposed to have, nor is that present in the ttl file that lists the actual names of the editors, so something does not add up. It might be tempting to blame the software ‘downloaded from the Internet’ that my operating system warns me for and prioritise the text file one can inspect directly in a text editor, but bear with me for a little more.

Since there’s something amiss with the persons, and so something to do with FOAF usage, one could try to import FOAF explicitly to see what happens, or delete the empty metadata fields, or convert it to the required exchange syntax RDF/XML or another syntax to attempt to gain insight what the issues are. Protégé’s error messages were a bit cryptic when I tried the latter with functional style syntax. I’ll save you reading through a few dead ends.

Was all this a productive use of my time? Most definitely not. A few of the erstwhile students of my ontology engineering course didn’t think so, either, and developed the OWL classifier that finds out straight away the DL fragment you ontology is in, in which OWL Species it is, and it presents a lists of violations of the other OWL Species profiles, if any, using two OWL API versions, for OWL and OWL 2. Here’s a screenshot from the downloaded CPEV ttl and one where I had imported FOAF:

The core-public-event.ttl contains 80 OWL 2 DL violations that causes it to be in OWL 2 Full only and the one where I had imported FOAF still contained 31 violations. Importing FOAF resolved 68 “undeclared x” issues, but added 19 more punning issues, which, at some point, looked promising to possibly pursue. I started to dig in earnest.

There are undeclared classes (e.g., foaf:Person) reported, undeclared annotation properties, punning problems (e.g., accessibility and event number), and so on and so forth. However, more of a smoking gun were the two detections of “Use of reserved vocabulary for class IRI: rdf:langString”, which remain in both lists of violations: the rdf:langString is not a permitted datatype for a data property range in OWL, and it shouldn’t have been reporting it as a class. The rdf:langString was new in RDF 1.1 of 2014 and is intended for “A literal is a language-tagged string if the third element is present.”, yet OWL 2 was last updated in 2012. The OWL API added support for it in February 2015 nonetheless. Removing the rdf:langString from the range declarations of its two uses, with declared data properties accessibility and event number, resolves most issues except for one. It resolves many because rdf:langString is treated as a class yet ought to be a data type, ‘confusing’ the rest of CPEV’s content.

Is a language tag for event number so relevant that we have to leave behind DL-based ontologies? No, that data type should be an xsd:integer or else rdfs:plainLiteral and if someone wants to add ‘rd’ or ‘de’ ‘ieme’ after a 3 in a user interface, then that has to be sorted out by the surface realiser where it ought to be addressed anyway. Must the accessibility data property have a language tag? I appreciate there will be one somewhere in the information system, but a language-tagged blurb about how the venue of the event is accessible for people with mobility restrictions does not warrant a transgression into undecidability of the vocabulary. Nor is it ontologically defensible. Any information system can handle that requirement trivially without destroying ontology-based data access prospects, without forcing undecidable FOL reasoners upon us. Add another field ‘in language’ if you must (which also gives the freedom for more languages and dialects than pre-set ones, even more so with MoLA) or maybe ontolex-lemon is of use here.

That out of the way, the one remaining category of issue is the anonymous individuals in OWL 2 EL and OWL 2 QL, which, considering that few DL-based OWL features are used, does make sense to aim for in the interest of scalable applications. The blank nodes that generate to new individuals in the ontology file are due to the unnecessary nesting of the list of editors that forced the introduction of blank nodes, rather than adding them one by one as an individual each. That is, instead of a pattern like

  <http://www.w3.org/2001/02pd/rec54#editor> [
    a foaf:Person;
    foaf:firstName "x";
    foaf:lastName "y"
  ], [
    a foaf:Person;
    foaf:firstName "z";
    foaf:lastName "w"
  ];

in the ontology metadata, adding a separate entry for each, like

<http://www.w3.org/2001/02pd/rec54#editor> “x y”
<http://www.w3.org/2001/02pd/rec54#editor> “z w”

addresses that problem.

Removing that Turtle list as it was, the modified CPEV file is also in all OWL 2 Profiles. Is an RDF list with blank nodes worth it to forfeit CPEV usage in ontology-based data access systems, when it can be solved simply by adding each editor individually? I don’t think so. Or: what are the arguments why the listing causing the blank nodes is preferable over scalable use of CPEV?

The Financial Industry Business Ontology FIBO

FIBO has many files in its GitHub repository, and I randomly picked one, being Legal Capacity https://github.com/edmcouncil/fibo/blob/master/FND/Law/LegalCapacity.rdf. The W3C RDF Validator is ok with it (see image on the right).

Testing it in the OWL Classifier, it also turned out to be in OWL 2 Full:

and a copy of the full text of the list of violations is pasted here to see the entire entries:

1 - Use of undeclared annotation property: owl:minQualifiedCardinality in annotation [Annotation(owl:minQualifiedCardinality "0"^^xsd:nonNegativeInteger) in AnnotationAssertion(owl:minQualifiedCardinality _:genid650 "0"^^xsd:nonNegativeInteger)]

2 - Use of undeclared annotation property: owl:minQualifiedCardinality in annotation [Annotation(owl:minQualifiedCardinality "0"^^xsd:nonNegativeInteger) in AnnotationAssertion(owl:minQualifiedCardinality _:genid649 "0"^^xsd:nonNegativeInteger)]

3 - Use of unknown datatype: rdf:langString [DatatypeDefinition(<https://www.omg.org/spec/Commons/TextDatatype/Text> DataUnionOf(rdf:langString xsd:string )) in OntologyID(OntologyIRI(<https://www.omg.org/spec/Commons/TextDatatype/>) VersionIRI(<https://www.omg.org/spec/Commons/20221101/TextDatatype/>))]

4 - Use of reserved vocabulary for annotation property IRI: owl:minQualifiedCardinality [AnnotationAssertion(owl:minQualifiedCardinality _:genid649 "0"^^xsd:nonNegativeInteger) in OntologyID(OntologyIRI(<https://spec.edmcouncil.org/fibo/ontology/FND/Utilities/Analytics/>) VersionIRI(<https://spec.edmcouncil.org/fibo/ontology/master/latest/FND/Utilities/Analytics/>))]

5 - Use of reserved vocabulary for annotation property IRI: owl:minQualifiedCardinality [AnnotationAssertion(owl:minQualifiedCardinality _:genid650 "0"^^xsd:nonNegativeInteger) in OntologyID(OntologyIRI(<https://spec.edmcouncil.org/fibo/ontology/FND/Utilities/Analytics/>) VersionIRI(<https://spec.edmcouncil.org/fibo/ontology/master/latest/FND/Utilities/Analytics/>))]

Setting aside the langString, the “AnnotationAssertion(owl:minQualifiedCardinality” is clearly the problem: cardinality constraints are not there for annotation, but to be used in class expressions, and they are reserved for it at that. This is both a problem for Legal Capacity and the Utilities/Analytics it imports. Someone had added minQualifiedCardinality as an annotation property, likely by accident:

It is not allowed to be so if it is to be a DL-based OWL ontology, because it’s reserved vocabulary. Note that “An OWL 2 Full ontology document is any RDF/XML document”, and since it validates, one could argue it’s an OWL ontology. Yet, the DL constructs used are merely ALCHIQ(D), or: most certainly using less than the OWL 2 DL features one could use. Would one want to forfeit decidable automated reasoning for an unused annotation property? I think not.

Where to go from here?

These sort of issues are hard to find manually, and ever harder once the size and complexity of the ontology and the modules it imports increase. Eight OWL Species to choose from in a number of different concrete syntaxes doesn’t make the debugging task any easier either. That’s why my students chose to develop the tool. They did so a while ago, however, and the OWL classifier (GitHub repo) I used was developed in 2016 and only works with older JDKs due to backwards incompatibility of Java, it having been a mini-project topic of the course, the CS honours students – Brian Mc George, Aashiq Parker, and Muhummad Patel – graduated and moved on, and new students want to do new things. You’ll have to set up an older version of JDK to avail of the OWL Classifier to catch syntax violation issues with basic explanations. It doesn’t solve the syntax problem yet, but at least it pinpoints, or at least directs, to where the violations are that make it RDF/Turtle but not the lightweight OWL many an RDF-oriented modeller is after.

Finally, I don’t want to merely complain; I want to help. Writing this and the previous post in an uncontrollable GitHub issue for one ttl/rdf file is a bit much, and, going by the ttl and rdf files that exist on disparate repos, it serves to be known for more than one such file.

It’s good to see how much of the Semantic Web technologies actually made it into industry and public administration, especially considering all the boasting (and bullying?) by the LLM groupies. I’d like to see it taking a step up towards further effective interoperability in the EU and beyond.

Over the past few years that I’ve been peeking and dabbling outside computer science and the ivory tower of academia more than before, I noticed a disturbing trend, or perhaps even entrenched practice, of talk about “RDF ontologies” and of “ontologies really being no more than just RDF graphs”. But just because ontologies in OWL are expected to be serialised in RDF/XML as the required exchange syntax according to the standard – and optionally in another specified format, such as Turtle (an acronym of Terse RDF Triple Language), OWL/XML, functional style syntax, or Manchester syntax – and has a mapping into RDF, it doesn’t make them ‘RDF ontologies’. Why isn’t an ontology ‘just RDF’?

A very short non-technical answer is that while ontologies (formalised in OWL) can be seen as an RDF graph when that particular serialisation language is chosen, not all RDF graphs are ontologies, and since there are valid serialisations of OWL ontologies that are not graphs (e.g., OWL/XML), not all OWL ontologies are RDF graphs when you encounter the document. A longer explanation follows, where I’ve adapted sidebar 7 of my textbook to make its contents more suitable for a blogpost, and for that reason it also has a little from the ‘encoding peculiarities’ section and sidebar 12.

Abstract versus concrete syntax

As preliminary, recall that the OWL 2 Web Ontology Language is a W3C recommendation since 2009 with a 2nd edition in 2012, and the latest RDF 1.1 for publishing and linking data is a recommendation since 2014 (RDF 1.2 is on the way). And, for what it’s worth it (one certainly can squabble about certain parts – visuals have limitations), here’s an adjusted Semantic Web layer cake, with more standards, less crazy on the colours, and relevant DIKW pyramid concepts on the right.

Let’s consider “Figure 1 The structure of OWL 2” from the OWL 2 overview, reproduced below, and the lime-green oval in the centre with the “mapping”-labelled arrows between OWL and RDF, and, why not, also that orange rectangle at the top-centre with the “RDF” mention and the “Turtle” on the right as well. Perhaps that’s what might cause a reader to simplify it all to equate an ontology with an RDF graph, and save their ontology with a .rdf or, as problematic, .ttl extension instead of saving the ontology in RDF/XML format with an .owl extension to indicate it’s meant to be an ontology in OWL.

An OWL 2 ontology is represented as an instance of the OWL 2 structural specification, which is independent of concrete OWL 2 exchange syntaxes. Put differently, an OWL 2 ontology has one structural specification and will be written and stored in one or more concrete exchange syntaxes. RDF/XML is one such exchange syntax, and the mandatory one at that; functional style syntax is an optional exchange syntax, and so are Turtle, Manchester syntax and OWL/XML. Here are two examples of those concrete syntaxes and their respective rendering in a GUI: berry being a fruiting body and carnivorous plants eating animals from a tutorial on improving an ontology, as lazy screenshots of Protégé that fit in my laptop window.

For the data and information modeller among you, you may draw a parallel with UML: there’s the standard that specifies valid UML diagrams, and for a modelling tool one can choose how to turn the UML class diagram into flat text to manipulate and store it, be it OMG’s XMI, some other XML, JSON, your home-grown pet language, or even store them in RDF by treating the diagram as a graph. Does that make the UML class diagram alternatingly a tree data structure, a graph, and a collection of name/value pairs or, schizophrenically, all of them at the same time? No, a UML class diagram remains exactly that, regardless of the implementation choice for the serialisation language.

Back to OWL. The particular structure of an OWL ontology can be mapped into an RDF graph for a concrete computer-processable serialisation of the ontology. Any Description Logic-based OWL ontology still has a direct semantics that is model-theoretic. That mapping into what is syntactically an RDF graph does not change the semantics of the ontology if it’s DL-based (i.e., in either of OWL DL, OWL Lite, OWL 2 DL, OWL 2 EL, OWL 2 QL, or OWL 2 RL), or: the ontology does not swap into a graph-based semantics by serialising it in RDF or its Turtle dialect and we still can send it to the DL-based automated reasoner.

Another way of looking at it is that for concretely writing down the ontology for computational use, we abuse/avail of some syntax that was already specified somewhere for another purpose – representing data and information on the Web – that’s reused here for a different purpose – serialising an ontology where knowledge is represented. It’s a bit like abusing UML class diagram notation to visualise key aspects of an ontology for communicative purpose because it’s around already, people are more familiar with UML notation, and it saves you inventing and explaining a new visual notation.

There are two key reasons why a distinction is made between an abstract structural specification and concrete syntaxes. First, the abstract structure serves as a pivot that then can be linked to multiple concrete syntaxes, compared to generating many-to-many mappings between all exchange syntaxes. Second, additional practical conveniences can be added to concrete syntaxes that do not affect the logical theory (the ontology). For instance, a concrete syntax may have an abbreviatedIRI feature to simplify processing long IRI strings and it may have extras for ontology annotations.

If you look at the fine print of the mapping specification from OWL into RDF, that is, not the convenient table but some parts of the surrounding text, you’ll notice the ‘snag’ that it isn’t simply 1:1. Ontology O and the transformation of it into RDF syntax, T(O), works anyhow, yes, but it’s the “The mapping presented in Section 3 can be used to transform an RDF graph G satisfying certain restrictions into an OWL 2 DL ontology OG” that makes a difference (bold face added). Whatever is in the graph needs to adhere to what’s described in that Section 3; if it doesn’t, it’s still a graph, but just isn’t an OWL ontology. Consequently, RDF tools great for processing lots of instances aren’t necessarily adequate for OWL ontologies – if the tool’s feature set doesn’t boast adherence to those “certain restrictions”, then they aren’t adequate as tool for ontologies for sure.

RDF Schema?

Perhaps the people who talk about ‘RDF ontologies’ mean lightweight ontologies or vocabularies in RDFS, short for RDF Schema. RDFS is based on the RDF Semantics specification and is intended for type-level information and can help guide what to add to a graph. You can declare classes, properties, class hierarchies, property hierarchies, domain and range restrictions, and a few other things like labels, see-also, and bags, but not more substantive knowledge about the subject.

It won’t let you declare characteristics of properties (e.g., inverse, transitive), nor local range restrictions (e.g., that for a class Person specifically, the property hasName has as range xsd:string), nor complex concept descriptions (e.g., that class Bicycle is defined by the union of Human-powered bicycle and Electrical bicycle), nor cardinality restrictions (e.g., each Electrical Bicycle has exactly 1 motor), nor disjointness axioms (e.g., nothing can be both Apple and Orange), not to mention that one can mess up/around, like using vocabulary of the language (e.g., stating that rdfs:Class rdfs:subClassOf ex:a).

If you were thinking in the direction of a schema for RDF, and so RDFS, yet an ontology regardless, then you probably had intended to say an ontology in OWL 2 Full. Reasoning over OWL 2 Full is undecidable, so it’s not like that by forfeiting all the nice modelling features you’d be rewarded with good performance. Or: this may not be what you really want to have.

Ontologies in data stores

Perhaps the people who talk about ‘RDF ontologies’ meant something else. There are, for the lack of a better term, ‘encoding peculiarities’. I could store my ontology about, say, electrical bicycles in a relational database as well, if I so fancy. For the class hierarchy, I can create a 2-column table called Taxonomy, and store it there:

and so on for other tables, like a hasPart table with four columns: one for the whole, one for the part, and two for the basic constraints (universally or existentially quantified, number restrictions). Mathematically, that trick has turned my classes and properties into values. Not that most people would care, because we can look at it and think of it as if they were classes. Computationally, some tasks will go faster. Regardless, we can take R2RML and convert the relational database to RDF, and voila, we have the ontology as an RDF graph at the level of individuals. It’s mathematically and technologically gymnastics, but anyone who understands the stretching wouldn’t talk of an RDF ontology, but keep the performance optimisation hack under wraps and of no concern to the modeller.

When I look at the .ttl files of the SEMIC Core Vocabularies, for instance, such as the most recent release that happens to be v1.1 of the core public event vocabulary, it looks like that the intent is the first case, i.e., where an OWL ontology is serialised in Turtle, as is the case for QUDT, and others. If OWL 2 Full or any of the DL-based OWL 2 languages was intended, they should have had an .owl extension to indicate the ‘specialness’ of that Turtle file. It is not much different for the Financial Industry Business Ontology (FIBO) where, although the syntax isn’t even in Turtle or simple RDF, the file extension is still .rdf rather than .owl. I don’t mean to pick on these, but just happen to know of them and they originate from different communities.

In closing

As per Conformance (normative) of OWL 2, there are OWL 2 Full, OWL 2 DL, OWL 2 EL, OWL 2 QL, and OWL 2 RL ontology documents. Not ‘RDF ontology’ documents. They can be serialised in, at least, RDF/XML, Functional Style Syntax, OWL/XML, Turtle, and Manchester Syntax. Let’s not conflate the ontology with merely one of its exchange syntax serialisation options. More precise terminology may help communicating better, like tasting one’s vocabulary agreement tea.

Of course, other modelling languages exists that can be used for representing an ontology on paper or for computational use that are also not RDF graphs, such as Common Logic. Also, a tool such as Protégé can easily convert between the exchange syntax formats specified in the OWL standard and a few others (export to LaTeX, render it visually in OntoGraf, and whatnot). If you fancy the ontology to be in OWL/XML so you can use Owlready2 in a Python programming environment, go for it – just make sure it’s an OWL 2 ontology. It’s conformance to the OWL standard that counts for all those ontologies in the Semantic Web we weave in order to not end up knitting knots that would become too daunting to disentangle.

p.s.: I‘ll do have more concrete examples in the next post that I’ll finish up in a day or two, zooming in on CPEV and FIBO.

A bottom-up approach to knowledge graph development may be in part alike bottom-up ontology development from existing and legacy resources, but for sure also involves other tasks, and perhaps principally so. The major other task concerns instance data that also have to turn up in the graph. Digging into a pile of instances begets one dirty hands, however, and therefore substantial work has gone into trying to automate the task of processing the source data and automating loading them into a knowledge graph. Different types of source formats give rise to distinct frameworks with their algorithms and mapping languages, and there can be disparate core requirements on top of it that add to the ever growing list of potential solutions to choose from.

For instance, converting relational database data into a graph requires a different algorithm from converting tree-shaped semi-structured data (XML) into a knowledge graph. A requirement for a high quality graph with legal consequences in case of errors demands more quality control checks along the extract-transform-load (ETL) pathway than a community-based best-effort will-do graph. Control over the source and whether the source must be maintained or can be abandoned once the data has been converted also affects how to go about creating that knowledge graph, as does the requirement whether all data has to be converted or only the selected part that is of interest right now.

Many algorithms and tools have been proposed to automate the task. Since this is only a blog post, I’m going to condense the extant approaches that I know of into three main groups:

1. ETL-then-quality: first extract stuff from the unstructured, semi-structured, or structured source(s), dump the generated triples in the graph, and then clean it up for as much as feasible;
2. Quality ETL to KG: the semi-structured or structured source is carefully mapped to the schema of the graph and then the data is loaded into the knowledge graph accordingly;
3. Virtual KG: only a selected fragment of the structured source data is converted into the graph, which is computed on the fly upon selection.

Each approach has their own set of permutations. A feature comparison then inevitably leads to a few generic statements. I gave it a try nonetheless, as shown in the table below.

Let’s look at some of those values in the table. The “at least one” set of mappings for VKGs is that scalable VKGs can have two sets of mappings or one set of mappings + transformations; e.g., Ontopic’s VKG has a dedicated mapping language to map the ontology to the data and then uses W3C’s R2RML mapping language to convert the query answer into RDF. This makes it exceedingly suitable for scenarios where the source data needs to remain where they are and they are regularly updated, resulting in always up-to-date content in the RDF graph.

The quality ETL works only with semi-structured or structured data (unstructured data is of low quality) and may cater for, among others, selected or all trees in the XML files or all attributes in all RDBMS database tables, using any one of a variety of approaches ranging from dedicated mapping languages, such as RML, to ad hoc code to queries. Since each ETL conversion takes time, it makes sense to use it when one wouldn’t still need the source data in that older format, though re-running the transformation is easily done.

For ETL-then-quality, the source format can range from unstructured text to spreadsheets and beyond, and such best-effort approaches are typically not constrained upfront by a complex domain ontology to allow for as much triple generation as possible, but rather have a schema of sorts emerge from the conversion and cleaning up afterwards. It is, perhaps, the most well known option with NLP-based (including LLM) KG construction, a dash of Schema.org to it, and Google’s knowledge panels as end-user facing rendering of the output. There are obviously lots of methods and techniques for the various subtasks, but I’m not aware of a methodology for it.

I’ve worked on both the VKG/OBDA and the quality ETL approaches, and read up on and used the latter. I don’t have a preference on the whole, because the distinct approaches serve different scenarios, although a half-baked quality improvement for the ETL-then-quality approach irks me as a job half-done at best. This is not a case of bothsideism, but having an understanding of their respective strengths and thereby which one to use when, and consequently that one always can construct use cases with requirements for evaluation where one wins by design, as is the case also for the four approaches of VKG/OBDA as well and a brief overview of those considerations is included in Chapter 8 in the second edition of my ontology engineering textbook. There, I take also other features into account, such as computational complexity and open vs closed world assumption.

Are there other KG construction approaches with an automated component? Should there be more or other implementation-independent features to compare them on? Are some features more important than others? Is one approach much more prevalent in industry than the others, be that in number of projects, size, or funding, or in prospects for successes and failures in solving the problem? Questions, questions.

Regardless, later this week I’ll give a presentation about a particular Quality ETL to KG approach at the European Data Conference on Reference Data and Semantics (ENDORSE 2025) in the ‘AI driven data interoperability & mapping’ session. Meaningfy developed both a preliminary methodology and a supporting tool, called Mapping Workbench, that focusses on converting XML files to an ontology-based knowledge graph in this first iteration. Early results were presented at the SEMANTiCS conferences in 2023 and 2024 in the posters & demos session, and we’ve been working on more tool and methodology enhancements since then, including automation of testing whether the mappings are correct and looking into more types of data as input. If you’re interested in either the methodology or tool, be it for research or for bringing your old XML data (or another format) into the 21st-century technology ecosystem, and the 2020s really, please feel free to contact me, attend the presentation, or arrange for a meeting with demo afterwards. I’ve also installed and checked in on the conference app.

The second edition of my ontology engineering textbook was published earlier this month with a non-profit publisher, College Publications, to keep the book affordable. I wouldn’t be getting rich from the number of textbooks sold anyway and affordability of access to knowledge is important for a myriad of reasons. The book is not for free: printing hardcopies cost money, as does cover design, so does the server where the eBook will be stored, and so on. (Expecting it for free is unsustainable in the long run if the creation of textbooks is not to be dependent entirely on the whims of a wealthy benefactor.)

The textbook was configured to cost around 31 GBP or 43 USD or 37 EUR by the current current currency exchange rates, give or take a few dollars/euros due to country-specific taxation differences and fluctuations in exchange rates. It is around that price indeed on Amazon.com and Amazon.co.uk, yet not so everywhere else I checked. Amazon.de had it on offer for 65.65 euro mid September, and Amazon.es for 93.30 euro and likewise for Italy. Amazon apparently is expecting that people in the eurozone are so used to fork out exorbitant prices that they will do so for this textbook as well.

Amazon.com.au speculated with Australian dollars over the weekend from nearly 80 to 135 back to 83.44 AUD now (though ‘out of stock’). The newly established Amazon.co.za sets its tone by demanding twice the set price from its South African customers – reality soon to be acting out my SIPP/SEP/computer ethics course’s popquiz question about what to do when textbooks are at R1500 (i.e., too expensive). 31 GBP is around R700, however.

The extra 30-60 euros go neither to College Publications nor to me, but to Amazon’s already huge amount of profits and its obscenely rich founder. It appears that there’s nothing we—i.e., College Publications or I—can do to reign in Amazon’s Algorithm Overlords. Not right now. It would not surprise me if this sort of price manipulation also happens to other authors and publishers and a class action suit against Amazon for monopoly abuse sounds like a fine plan.

There are other online retailers, one might retort. True, but they either don’t list my book yet, are in the process of doing so (e.g., ibs.it), or followed Amazon’s lead and added their own markup on top of it (e.g., Thalia.de), except for Booktopia that offers it for a few AUD less than Amazon’s lowest price in Australia. To the best of my knowledge, this sort of manipulation didn’t happen with the first edition of the textbook.

Algorithms are not magic, nor are they the boss; they are designed by humans who are also in charge of deploying them. Hence, the price manipulation and duping of customers in the, perhaps, ‘non core’ countries is by design. This is unethical and should be, if not already is, illegal. Meanwhile, if you’d like to buy the textbook and have limited means or don’t want to sponsor an already fat cat on principle, it can be worth it to shop around to find a better deal.

The ebook of the second edition of An Introduction to Ontology Engineering will be available soon here, where it will be free from Amazon’s algorithms. It won’t be DRM protected, which may have the result that insufficient hardcopies are going to be sold to break even. Publishing can be complicated. Either way: thank you to those who already have bought a copy. I’m sorry if you paid too much for it; I tried my best to avoid that and I hope you’ll find the contents insightful and worthwhile regardless.

It is here: the second edition of An Introduction to Ontology Engineering, also published with the non-profit College Publications and making its way through the distribution channels (e.g., on amazon.co.uk and amazon.de through print-on-demand already).

Did I really want to write a second edition over moving on to write a brand new book? Not really, but it was pulling at me hard enough to go ahead with it anyway. Seven years passed since the publication of the first edition, and everything before COVID seems so long ago. New scientific results have been obtained, new interests emerged, known gaps in the book’s content needed to be filled more urgently than before, and ontologies are on the rise again for a variety of reasons. Those ontologies may, at times, be only lightweight, incorporated in a knowledge graph, or presented as a harmless-looking low-entry controlled vocabulary, but it’s a renewed interest in modelling nonetheless. Also, I fancy the thought that my writing skills have improved over the years and that I could improve the book that way as well.

What’s the difference? What’s new?

I’ve added several recent advances and gracefully shortened or removed older material that lost relevance. The updated and extended NLP section is but one of such cases (see also the recent post), the OBDA chapter another, and, yes, now there is a section on competency questions and I could not avoid writing something about LLMs either. Chapter 11 is new, consisting of integrative and advanced topics, such as ontology modularisation and ontology matching, and a few other topics.

There are also improved explanations and better contextualisation in the broader firmament, like where logics fit and which ones, the DIKW pyramid to also visually position ontologies in the knowledge layer, a new integrated diagram for ontology development methodologies (trialled in this post), and more.

Other novelties are highlighted “learning outcomes” formulated per chapter, more exercises in the book and a new workbook that was announced recently. There are 53 new or improved figures, serialisations neatly in code listings, a prettier layout, and other enhancements. Overall, chapters 1, 7, 8, and 11 have been revised substantially, Chapters 2, 4, 5, 6, and 9 have been updated for a considerable part, and there are additions and improvements in Chapters 3 and 10. All the enhancements caused the main content to increase with 80 pages, or about 30% more, compared to the first edition.

Additional materials

The website accompanying the textbook has been growing over the years, with new ontologies for the tutorials and exercises, additional software for the exercises, and instructions for improved accessibility for the visually impaired (see here or here). The slides still have to be updated, which I’ll probably only get around to do when the next installment of the ontology engineering course is schedule.

I moved the answers to selected exercises from the appendix to the workbook that now also contains tutorials, in order to keep the printing costs of the book relatively low. To recap from the post about the workbook: the new tutorials are about developing good ontologies, reusing ontologies, reasoner-based use of OntoClean, and generating natural language sentences from ontologies.

Audience

The book is still unapologetically aimed at postgraduate students in computer science. There is no quick fix for developing a good ontology, and so nor does the book offer that. Rather, it looks at the foundations of ontology engineering and ontology development. Not everyone needs all that, and that’s fine; some do need it to devise novel theories, methods, techniques, and tools for ontology development, and to maintain the ontology engineering software ecosystem.

What that didn’t make it?

The LLM section is short. Results are coming in indeed, but there’s difference between preliminary research results and a textbook. The section on competency questions is also short: while there are substantive results, it is not as core a topic as the others are that did receive more attention. And a content request for guidelines how to develop an ontology collaboratively could not be honoured beyond an informal sidebar, because there is no substantive reliable, tested, and working materials on what works well. Other topics are nice, but would fit better in a more practical guide for industry, such as how to manage ontology annotations. Hard choices had to be made, for various reasons. If you would have made different choices: you always can cherry-pick from the content and supplement it with other materials—I did so for other subjects’s respective textbooks for courses I taught—or try to write your own textbook.

Is it as cheap as the first edition?

No, sorry. There’s considerably more content and thus more pages to print, the size is different, which affect the softcover hardcopy price as well, and, unlike the first edition, it’s printed in colour. The colour really helps in the explaining that B&W print wouldn’t have. Then there are price fluctuations due to currency exchange fluctuations. There’s a cheaper eBook version, and that file likely will end up on a sharing site at some point. College Publications is non-profit, and so at least the cost is still substantially lower and more affordable than it otherwise would have been.

I hope you will find the updated version interesting and useful. I’m happy to receive feedback and endeavour to be responsive.

Late 2024, Zubeida and I proposed the notion of different types of competency questions for ontologies [1], with each type serving a different purpose. Some youngsters attending the talk at EKAW’24 deemed it not only obvious that there are different types of questions but that surely they existed already. They didn’t. We have been working on this line of investigation: what are the constituents of those types of competency questions that makes them different from each other?

To answer that question, one might be tempted to give NLP a try or feed an LLM a large amount of competency questions (CQs) and let it figure it out. We didn’t do that. We looked at the meaning behind the questions rather than just surface structures and probabilities, because we already could see that NLP wouldn’t be able to second-guess that much implicit information. (ChatGPT might have embedded an unreliable ‘top-level ontology’ of its own.)

For instance, a question about a relational property (rpRCQ), such as “If a human loves, must it also love itself?” refers implicitly to the ‘loving’ relation and the relational property assessed (reflexivity), though one of course could do so explicitly as well, like a “Is the counsels relationship between a therapist and a patient irreflexive?”. A scoping CQ has different constituents: it must have as associated elements at least one entity, be in a particularly subject domain, and is in relation to a prospective ontology; e.g., in “What can the pipes in a sewer network convey?”, the scoping entities are pipe, sewer network, and conveying something, the subject domain is hydrology, and the prospective ontology is the SewerNet ontology.

We analysed all types of CQs we had identified and identified what makes them distinct from other types of CQs. Besides describing it, we created ER model snippets for each, both for communicative purpose and for the plan to create a database for further analysis, and wrote a corresponding formalisation to be a bit more precise for those who want it. We call the resulting model QuO, and kept it as a ‘model’ because we consider it not mature enough to call it an ontology just yet. The details are described in the recently accepted paper entitled Characterising Competency Questions for Ontologies [2] that will be presented at the 9th Cognition And OntologieS workshop as part of the Joint Ontology Workshops that will take place on 8 and 9 September in Catania, Sicily, which is co-located with FOIS’25 that takes place from 10 to 12 September.

The paper also describes a use case-based evaluation (sewer networks), an illustration where different types of CQs can be used in the various ontology development processes, and examples of potential use. We close with a few notes on exemplary CQs, questions that are almost CQ, faulty CQs, and answerability, some reflections in the discussion, and conclusions.

The paper does not describe evaluations with LLMs or other NLP algorithms, but it is an obvious next step: can they be used to improve the quality of automatically generated CQs [3], diversify the stilted short phrases generated, and make the outputted questions more relevant? There are no user evaluations either, because a key question to answer first is: can it feed into a method to assist domain experts to get them to write more good, varied, and useful CQs, and if so how, or could CLaRO [4] somehow be extended and then re-evaluated? And will the types of CQs have a beneficial effect on the quality of the ontology or the CQ authoring process? Such a method is yet to be developed and workshop papers have page limits, one which we reached already, and the writing is dense as it is. There are no benchmark evaluation reports in the paper either, because there was nothing to compare against; there’s only our extensively annotated dataset of CQs by type, i.e., the Repository of Ontology Comptency Questions (ROCQS) that we now have turned into a GitHub repo, yet testing on our own highly curated set wouldn’t be convincing. And so, the evidence is our theoretical argument and the evaluation the applicability in the use case. Did I write this paragraph for a [clueless (?)/lazy (?)/limited-thinking (?)/one-who-used-a-reviewing-checklist (?)] reviewer who whined that “no quantitative evaluation or user study” was a weakness of the paper? Mainly, yes.

While it’s more of a theoretical advance rather than a practical one, practical applicability and use seems tantalisingly close and ROCQS as dataset can be of use there. For now, there are those types of CQs, and they have shown their use in the development of the SewerNet ontology, which is a promising start. I’ll present the paper at CAOS and feel free to reach out for follow-up activities.

References

[1] Keet, C.M., Khan, Z.C. On the Roles of Competency Questions in Ontology Engineering. 24th International Conference on Knowledge Engineering and Knowledge Management (EKAW’24). Springer LNAI vol. 15370, pp123–132. Amsterdam, Netherlands, November 26-28, 2024.

[2] Keet, C.M., Khan, Z.C. Characterising competency questions for ontologies. 9th Cognition And OntologiesS workshop (CAOS’25) part of JOWO’25, 8-9 September 2025, Catania, Italy, CEUR-WS (in print)

[3] Mahlaza, Z., Keet, C.M., Chahinian, N., Haydar, B. On the Feasibility of LLM-based Automated Generation and Filtering of Competency Questions for Ontologies. Proceedings of the 5th Conference on Language, Data and Knowledge 2025 (LDK’25). ACL. (in press)

[4] Keet, C.M., Mahlaza, Z., Antia, M.-J. CLaRO: a Controlled Language for Authoring Competency Questions. 13th Metadata and Semantics Research Conference (MTSR’19). E. Garoufallou et al. (Eds.). Springer CCIS vol. 1057, 3-15. 28-31 Oct 2019, Rome, Italy.