6.2: Methods to Improve an Ontology’s Quality

The methodologies we have seen in the previous section may include one or more methods at a particular step in the process. These methods aim to assist the ontologist in certain tasks of the ontology engineering process, such as to assist the modeling itself and to integrate ontologies, which may have supporting software tools. The methods can be divided roughly into: logic-based only, purely based on philosophy, a combination of the two, and practical rules or guidelines. Each of these categories has several methods with more or less tool support. In this section, we take an illustrative sampling of each of them, respectively:

1. The ‘debugging’ of deductions that caused, e.g., one or more classes to have become unsatisfiable, where we’ll see some detail as to what creates such justifications;
2. OntoClean to ‘clean up’ a ‘dirty’ taxonomy;
3. The RBox compatibility service for coherent hierarchies and role chains of object properties;
4. OOPS! with TIPS to catch common pitfalls and how to avoid them.

Logic-Based Methods: Explanation and Justification

People make errors with respect to what they intend to represent in the ontology, or do it correctly, but are somewhat surprised by one or more deductions. The automated reasoners can help explain that, or: ‘justify’ the deduction. The more recent versions of ODEs may have this feature already implemented, and you may have come across it during the exercises (e.g., by having clicked on the “?” on the right of the yellow deduction in Protégé). Put differently: you have been using an automated reasoner to ‘debug’ the ontology. Where do they come from, and what is a good strategy to explain deductions to the modeler or domain expert?

As a first step to obtain the answers, researchers looked at what were the most common logical mistakes that modelers made. Typical mistakes that cause a class to be unsatisfiable, result in undesirable inferred subsumptions, or inconsistent ontologies, are the following ones:

• The basic set of clashes for concepts (w.r.t. tableaux algorithms) resulting in an incoherent ontology are:

– Atomic: Any individual of a class would belong to a class and its complement;

– Cardinality: A class has a max cardinality restriction declared, but its subclass has a higher min cardinality on that same object or data property;

– Datatype: A literal value violates the (global or local) range restrictions on a data property (i.e., conflicting data types).

• The basic set of clashes for the ontology resulting in an inconsistent ontology are:

– Inconsistency of assertions about individuals, e.g., an individual is asserted to belong to disjoint classes or has a cardinality restriction but related to more individuals;

– Individuals related to unsatisfiable classes;

– Defects in class axioms involving nominals (owl:oneOf, if present in the language).

The second step was to integrate this with what the reasoner computes along the way to the final deduction: which axioms are involved that lead to the unsatisfiable class or inconsistent ontology? Any such explanation feature thus uses at least the standard reasoning services. It adds further and new reasoning services tailored to pinpointing the errors and explaining the entailments to, e.g., try to find the least number of axioms among the alternative explanation. Such ‘debugging’ goes under terms like glass box reasoning, (root) justification, explanation, and pinpointing errors. This may sound easy: just get a log from the reasoner. It is not that simple, however. Consider the following example.

Example \(\PageIndex{1}\):

The ontology \(\mathcal{O}\) under consideration contains, among many other axioms, the following two:

\(\texttt{A}\sqsubseteq\texttt{B}\sqcap\texttt{C}\sqcap\neg\texttt{C}\)

\(\texttt{A}\sqsubseteq\neg\texttt{B}\)

One deduces \(A\sqsubseteq\bot\). Why? There are two routes that explain this deduction purely based on the axioms, indicated in red:

1. \(\texttt{A}\sqsubseteq\texttt{B}\sqcap\textcolor{red}{\texttt{C}\sqcap\neg\texttt{C}}\)
2. \(\texttt{A}\sqsubseteq\textcolor{red}{\texttt{B}}\sqcap\texttt{C}\sqcap\neg\texttt{C}\)

\(\texttt{A}\sqsubseteq\textcolor{red}{\neg\texttt{B}}\)

Which of the two ‘explanations’ should be shown to the user, or both? And the whole axiom, or only the relevant part(s) of it, or like the color highlighting? Or, given a set of explanations, those axioms that appear in all explanations or, vv., that are unique (i.e., appear only once across all explanations)? Or maybe to not show a whole set of axioms, but instead only the essence in natural language, alike “\(\texttt{A}\) is a subclass of both a class and its complement, which causes it to be unsatisfiable” or perhaps a Venn diagram can be drawn?

Both the theory and how to present it to the user have been investigated. If you use Protégé, it is based on the work presented in [HPS08]. They use the notions of laconic justifications, which are justifications—i.e., a set of relevant axioms— whose axioms do not contain any superfluous parts (and all of whose parts are as weak as possible³) and precise justifications, which are laconic justifications where each axiom is a minimal repair in the sense that changing something to any axiom may result in fixing the undesirable deduction. While they are useful topics, we will spend little time on it here, because it requires some more, and more in-depth, knowledge of Description Logics and its reasoning algorithms (suitable for a Description Logics course).

Proposing possible fixes automatically is yet a step further and research is still under way to address that. This is in no small part because it is hard to second guess the user. Taking the axioms in Example 5.2.1 as example, there are already multiple options, such as removing \(\texttt{A}\sqsubseteq\neg\texttt{B}\), or deleting \(\texttt{A}\sqsubseteq\texttt{B}\), and likewise for \(\texttt{C}\), yet showing all possible ways to fix the undesirable deduction results in too much clutter.

Philosophy-Based Methods: OntoClean to Correct a Taxonomy

OntoClean [GW09] helps the ontologist to find errors in a taxonomy, and explains why. One might ask oneself: who cares, after all we have the reasoner to classify our taxonomy anyway, right? Indeed, but that works only if you have declared many properties for the classes so that the reasoner can sort out the logical issues. However, it is not always the case that many property expressions have been declared for the classes in the ontology and those reasoners do not detect certain ontological issues.

OntoClean fills this gap for taxonomies. It uses several notions from philosophy, such as rigidity, identity criteria, and unity (based on [GW00a, GW00b]) to provide modeling guidelines. Let’s take rigidity as example, for it can be used elsewhere as well. There are four different types of rigidity, but the useful ones are rigid and anti-rigid, which are defined as follows:

Definition \(\PageIndex{1}\)

(+R [GW09]) A rigid property \(\phi\) is a property that is essential to all its instances, i.e., \(\forall x\phi (x)\to\square\phi (x)\).

Definition \(\PageIndex{2}\)

(∼R [GW09]) An anti-rigid property \(\phi\) is a property that is not essential to all its instances, i.e., \(\forall x\phi (x)\to\neg\square\phi (x)\).

OntoClean takes these sort of metaproperties to annotate each class in the ontology. For instance, a modeller may want to assert that Apple is rigid (each instance remains an apple during its entire existence) and being a Professor is antirigid (all individuals that are professors now were at some time not a professor).

Subsequently, we apply meta-rules to reclassify the classes. For our rigid and anti-rigid meta-property, the applicable rule is as follows:

• Given two properties (classes), \(p\) and \(q\), when \(q\) subsumes \(p\) the following constraint hold:

1. If \(q\) is anti-rigid, then \(p\) must be anti-rigid

Or, in shorthand: \(+R \not\subset ~R\), i.e., it cannot be the case that a class that is annotated as being rigid is subsumed by a class that is annotated as being anti-rigid.

For instance, if we have, say, both Student and Person in our ontology, then the former is subsumed by the latter, not vice versa, because Person is rigid and Student anti-rigid. If \(\texttt{Person}\sqsubseteq\texttt{Student}\) were asserted, it would say that each person is a student, which we know not to be the case: 1) it is not the case that all persons come into existence as students and die as students, and 2) it is not the case that if a student cease to be a student (e.g., graduates), then that object also ceases to be a person.

Besides manual analysis, currently, two approaches have been proposed for incorporating the ideas of OntoClean in OWL ontologies. One is to develop a separate application to handle the annotations of the classes and the rules, another is to leverage the capabilities of the standard reasoning services of the OWL reasoners, which is done by [GRV10, Wel06]. They differ in the details, but they have in common the high-level approach:

1. develop the domain ontology (TBox);
2. push it into the ABox (i.e., convert everything from the TBox into ABox assertions);
3. encode the OntoClean ‘meta rules’ in the TBox;
4. run the standard OWL reasoner and classify the ‘instances’;
5. transfer the reclassifications in the taxonomy back into the domain-ontologyin-TBox.

Finally, observe that this machinery of OntoClean also provides one with the theory to solve the “green apple issue” we encountered in Section 1.2: What is an Ontology? "Good, Not so Good, and Bad Ontologies on Good and Bad Ontologies": Apple is rigid (and a sortal), but its greenness is not. It is the rigid entities that provide a backbone of an ontology, not the other ones (like Green, Student) that depend on the existence of rigid entities.

Combining Logic and Philosophy: Role Hierarchies

OntoClean does little to help solving so-called undesirable deductions, be they logically consistent or not, and the justifications computed may not always point to the root problem from a modeling viewpoint. The \(RBox\) Compatibility service [KA08] and its extension to \(SubProS\) and \(ProChainS\) [Kee12a] can assist with at least some of that. They check for meaningful object property hierarchies and property chains. This has as prerequisite to know when a property hierarchy is ‘good’ (e.g.: guaranteed not lead to an undesirable deduction). Only afterward can one test for violations of those principles, and finally have guidance on how a mistake can be revised.

The hierarchy of object properties must be well-formed, which entails the principles as to what it means for one property to be a sub-property of another. In analogy to a class hierarchy, where the instances of a subclass necessarily are a subset of the set of instances of the superclass, one can state that in every model, the tuples (individual relations) of the sub-property are a subset of the tuples of its parent property. This can be guaranteed in two distinct ways. The most-straightforward case is that the domain and/or range of the sub-property must be a subclass of the domain and/or range of its super-property. This is similar to UML’s ‘subsetting’ for associations. The other has to do with implications of property characteristics; e.g., asymmetry can be derived from antisymmetry and irreflexivity, hence, it is a stronger constraint. This is presented informally in Figure 5.2.1.

Figure 5.2.1: Constraining a property: A: an example, alike the so-called ‘subsetting’ idea in UML; B: hierarchy of property characteristics (structured based on information in [Hal01, HC11]), where the dashed ones are not available in OWL 2 DL. (Source: based on [Kee14])

To state the subsetting notion formally into the \(RBox\) Compatibility service (a subset of \(SubProS\)), let’s introduce in the following definition the notation to denote the user-defined domain and range of an object property.

Definition \(\PageIndex{3}\)

(User-defined Domain and Range Concepts [KA08]). Let \(R\) be a role and \(R\sqsubseteq C_{1}\times C_{2}\) its associated Domain & Range axiom. Then, with the symbol \(D_{R}\) we indicate the User-defined Domain of \(R\)—i.e., \(D_{R}= C_{1}\)—while with the symbol \(R_{R}\) we indicate the User-defined Range of \(R\)—i.e., \(R_{R}= C_{2}\).

The RBox Compatibility can then be defined as follows, covering each permutation of domain and range of the sub- and super property in the hierarchy in the RBox \(\mathcal{R}\), with the domains and ranges from the TBox \(\mathcal{T}\) :

Definition \(\PageIndex{4}\)

(RBox Compatibility [KA08]) For each pair of roles, \(R\), \(S\), such that \(\langle\mathcal{T},\mathcal{R}\rangle\models R\sqsubseteq S\), check whether:

Test 1. \(\langle\mathcal{T},\mathcal{R}\rangle\models D_{R}\sqsubseteq D_{S}\) and \(\langle\mathcal{T},\mathcal{R}\rangle\models R_{R}\sqsubseteq R{S}\);

Test 2. \(\langle\mathcal{T},\mathcal{R}\rangle\nvDash D_{S}\sqsubseteq D_{R}\);

Test 3. \(\langle\mathcal{T},\mathcal{R}\rangle\nvDash R_{S}\sqsubseteq R_{R}\).

An RBox is said to be compatible iff Test 1 and (2 or3) hold for all pairs of role-subrole in the RBox.

An ontology that does not respect the RBox compatibility criterion can be considered as ontologically flawed, as it may not generate a logical inconsistency and the criterion—or: semantics of object property subsumption—is at least an extralogical, if not ontological, criterion. This holds also for the extended version, \(SubProS\), that has a longer list of tests to also cover the hierarchy of property characteristics.

Checking for RBox compatibility—hence, for ontological RBox correctness— can be implemented by availing of the standard DL/OWL automated subsumption reasoning service. It may serve to have further tooling assistance in correcting any flaws that may be detected.

On can extend this further to ‘safe’ property chains, as, essentially, they are also inclusions, just with a chain on the left rather than a single property. Basically, the domain and range class from left to right in the chain on the left-hand side of the inclusion has to be equal or a superclass, and likewise for the outer domain (resp. range) on the left-hand side and range of the object property on the right-hand side of the inclusion; the complete test to check for a safe chain is described in [Kee12a]. This is illustrated in the following example.

Example \(\PageIndex{2}\):

Take the property chain \(\texttt{hasMainTable}\circ\texttt{hasFeature}\sqsubseteq\texttt{hasFeature}\) in the Data Mining and OPtimisation (DMOP) ontology, which is depicted in Figure 5.2.2. The two properties have the domain and range axioms as follows: \(\texttt{hasMainTable}\sqsubseteq\texttt{DataSet}\times\texttt{DataTable}\) and \(\texttt{hasFeature}\sqsubseteq\texttt{DataTable}\times\texttt{Feature}\). The range of hasMainTable and domain of hasFeature match neatly, i.e., both are DataTable. However, the domain of hasMainTable is DataSet and the domain of hasFeature is DataTable, and DataSet and DataTable are non-disjoint sibling classes. The reasoner infers \(\texttt{DataSet}\sqsubseteq\texttt{DataTable}\) because of the property chain, which is undesirable, because a set is not a subclass of a table. The ProChainS tests helps detecting such issues, and proposals how to revise such a flaw are also described in [Kee12a]. Note that in this case, there was not a logical inconsistency according to the language and the automated reasoning services, but instead it was a modelling issue.

Figure 5.2.2: The property chain \(\texttt{hasMainTable}\circ\texttt{hasFeature}\sqsubseteq\texttt{hasFeature}\) with the domain and range axioms of the two object properties. (Source: [Kee12a])

There are further aspects to the semantics of relations (roles/object properties), such as material vs formal relations and the ‘standard view’ vs ‘positionalist’ commitment as to what relations are [Fin00, GW08, Leo08, Loe15] that may influence the formalization as well as language design [FK15, Leo08, Loe15]. At present, within the scope of ontology development, there is only one preliminary model and corresponding Prot´eg´e plugin [KC16] that takes some of this into account and therefore it will not be elaborated on further here.

Heuristics: OntOlogy Pitfall Scanner OOPS!

Besides the theoretical guidance, there are other glitches in ontology authoring. Early works aimed at identifying typical modeling mistakes in OWL are described in [RDH⁺04], which moved onward to the notion of “anti-patterns” of the ‘don’t do this’ variety [RCVB09], and a growing catalog of pitfalls [PVSFGP12] of which 21 can be scanned automatically online with the OntOlogy Pitfall Scanner! (OOPS!)⁴. A selection of those pitfalls are: Creating synonyms as classes (P2); Creating the relationship “is” instead of using rdfs:subClassOf, rdf:type or owl:sameAs (P3); Defining wrong inverse relationships (P5); Including cycles in the hierarchy (P6); Merging different concepts in the same class (P7); Missing disjointness (P10); Missing domain or range in properties (P11); Swapping intersection and union (P19); Using a miscellaneous class (P21); Using different naming criteria in the ontology (P22); Defining a relationship inverse to itself (P25); Defining inverse relationships for a symmetric one (P26); and Defining wrong transitive relationships (P29). Pitfall P19 is illustrated in the following example.

Example \(\PageIndex{3}\):

You have to represent “a pizza Hawaii has as topping ham and pineapple”⁵. A modeler may be inclined to take the natural language description of the toppings quite literally, and add

\[\exists\texttt{hasTopping.}(\texttt{Ham}\sqcap\texttt{Pineapple})\]

However, this is not what the modeler really wants to say. The “\(\sqcap\)” means ‘and’, i.e., an intersection, and thus the “(\(\texttt{Ham}\sqcap\texttt{Pineapple}\))” is the OWL class with those objects that are both ham and pineapple. However, nothing is both, for meat and fruit are disjoint, so the pizza Hawaii in our ontology has a topping that is Nothing. What we want to represent, is that from PizzaHawaii there are at least two outgoing relations for the toppings, being one to Ham and one to Pineapple, i.e.,

\[\exists\texttt{hasTopping.Ham}\sqcap\exists\texttt{hasTopping.Pineapple}\]

In addition, one may want to add a so-called ‘closure axiom’ to say that all pizzas Hawaii “have as topping only ham and pineapple”,

\[\forall\texttt{hasTopping.(Ham}\sqcup\texttt{Pineapple)}\]

Note also here that there is not a one-to-one mapping between the imprecise natural language and the constructors: ham and pineapple, but using an ‘or’ \(\sqcup\), which becomes clearer when we rephrase it as “all toppings are either ham or pineapple”.

An evaluation of the presence of those 21 pitfalls showed that it does not make much difference whether the ontology is one developed by novices, an arbitrary ontology, or is a well-known ontology [KSFPV13]. It may well be that the notion of a good quality ontology is not tightly related to absence of pitfalls, or maybe the modeling pitfalls are propagated from the well-known ones by novice modelers; whichever be the case, it is fertile ground for research. Notwithstanding this, the ontology can be scanned quickly with OOPS! and the results provides pointers where the ontology may be improved.

The error, anti-pattern, and pitfall efforts look at quality of an ontology from the negative side—what are the mistakes?—whereas, e.g., OntoClean and the RBox compatibility view it from the positive side, i.e., what does a good representation look like? To this end, one also can turn around the pitfalls, into authoring guidelines, which is dubbed the \(\textbf{T}\)ypical p\(\textbf{I}\)tfall \(\textbf{P}\)revention \(\textbf{S}\)cheme, TIPS [KSFPV15], which describe the tips in the imperative so as to indicate what a developer should be checking. The one that includes trying to avoid the problem illustrated in Example 5.2.3 is the following:

T7: Intended Formalization

T7: Intended formalization (includes P14, P15, P16, P19, C1, and C4): A property’s domain (resp., range) may consist of more than one class, which is usually a union of the classes (an \(\texttt{or}\)), not the intersection of them. Considering the property’s participation in axioms, the \(\texttt{AllValuesFrom}/\texttt{only}/\forall\) can be used to ‘close’ the relation, i.e., that no object can relate with that relation to the class other than the one specified. If you want to say there is at least one such relation (more common), then use \(\texttt{SomeValuesFrom}/\texttt{some}/\exists\) instead. To state there is \(no\) such relation in which the class on the left-hand side participates, put the negation before the quantifier (\(\neg\forall\) or \(\neg\exists\)), whereas stating that there is a relation but just not with some particular class, then the negation goes in front of the class on the right-hand side; e.g., a vegetarian pizza does not have meat as ingredient (\(\neg\exists\texttt{hasIngredient.Meat}\)), not that it can have all kinds of ingredients—cucumber, marsh mellow, etc.—as long as it is not meat (\(\exists\texttt{hasIngredient.}\neg\texttt{Meat}\)). To avoid the latter (the unintended pizza ingredients), one ought not to introduce a class with negation, like NotMeat, but use negation properly in the axiom. Finally, when convinced all relevant properties for a class are represented, consider making it a defined class, if not already done so. [KSFPV15]

One that has nothing to do with logic foundations, but enters the picture for ontology development is the aspect where it is still more of a craft and engineering, is the following.

T1: Class Naming and Identification

T1: Class naming and identification (includes P1, P2, P7, C2, and C5): When identifying and naming classes in ontologies, avoid synonymy and polysemy: distinguish the concept itself from the different names such a concept can have (the synonyms) and create just one class for the concept and provide, if needed, different names for such a class using rdfs:label annotations. Regarding polysemy, where the same name has different meanings, try to disambiguate the term, use extension mechanisms and/or axioms. Other important cases regarding class naming and identification are (a) creating a class whose name refers to two or more different concepts by including “and” or “or” in the name (e.g., StyleAndPeriod or ProductOrService) and (b) using modality (“can”, “may”, “should”) in the ontology element’s names. In situation (a) consider dividing the class into different subclasses, and in case (b) consider a more appropriate name avoiding the use of modality or change to a logic language that can express it. Take care about about providing proper names for both the ontology file and the URI. [KSFPV15]

The topic of pitfalls, anti-patterns, and modeling suggestions spills over into a broader setting of ontology quality, which includes aspects such as accuracy, adaptability, clarity, completeness, computational efficiency, conciseness, consistency/- coherence and organizational fitness, and domain and task-independent evaluation methods that cover, among others, syntax, semantics, representation, and context aspects. (see, e.g., [Vra09] for an early overview.)

Tools

There are many tools around that help you with one method or with a methodology. Finding the right tool to solve the problem at hand (if it exists) is a skill of its own and it is a necessary one to find a feasible solution to the problem at hand. From a technologies viewpoint, the more you know about the goals, features, strengths, and weaknesses of available tools (and have the creativity to develop new ones, if needed), the higher the likelihood you bring a potential solution of a problem to successful completion.

Honesty requires me to admit that not all Semantic Web tools are being maintained and there is typically little documentation. In particular, plugins may falter when they have been developed for one ODE but not another, or for a prior version but aren’t compatible with a later version of the ODE. This short section it merely intended to give you an idea that there are tools for a range of activities, and if the one listed does not work anymore, then there is likely some open source code or at least a paper describing what it does and how, so that one could re-implement it, if needed⁶. The tools are grouped along five categories—to support methodologies, ODEs, implementing methods, portals, and exports—and where to start when you want to develop your own one.

Software-Supported Methodologies

They are few and far between. WebODE provided software support for Methontology, the NeOn toolkit⁷ aims to support the NeON methodology for distributed development of ontologies.

Ontology Development Environments (ODEs)

Clearly, the tools listed under the ‘Software-supported methodologies’ are ODEs, but there are also ODEs that are not tailored to a particular methodology. They mainly lack project management features, and/or the possibility to switch back and forth between informal, intermediate, and formal representations, or do not have features for activities such as project documentation. It may well be the case that such functionality is available in part or in whole as a set of plug-ins to the ODE. Some of those ODEs are stand-alone tools, such as Protégé desktop and Racer, others have a web interface, such as WebProtégé and the Modeling Wiki MOKI. The HOZO ontology editor is the only editor that was specifically designed to explicitly accommodate for certain ontological commitments, in particular regarding roles [MSKK07].

Most ODEs are packaged with one or more automated reasoners, but one also can use another one, given that there is a plethora of ontology reasoners and editors⁸. This includes tools that have a pseudo-natural language interface or a graphical interface to adding axioms to an ontology, which serves as ‘syntactic sugar’ to the underlying logic.

Software-Supported Methods and Other Features

Additional features and implemented methods may exist as stand-alone tool or as plugin for an ODE, or, thanks to the widespread uptake, may have been integrated in the ODEs already upon installation. For instance, Racer has extensive features for sophisticated querying and OWL ontology visualization with Ontograf is already included in the standard installation of Protégé For the axiom tests component of test-driven development, there is a TDDonto2 plugin for Protégé [KL16], and plugins for very specific tasks, such as the DroolsTab for visual authoring of complex spatial process simulation, and the CompGuide Editor for obtaining Computer-Interpretable Guidelines for Clinical Practice Guidelines. There are many more Protégé plug-ins⁹, which are sorted by topic (e.g., NLP, biomedical) and type (e.g., API, viewing), but do verify the versioning of the plugins and the ODE before installation.

Some of the recent stand-alone tools focused on improving the quality of the ontology are the Possible World Explorerthat helps with adding disjointness axioms [FR12, Fer16], the OntOlogy Pitfall Scanner (OOPS!) that implements an automated check of the ontology with 21 common modeling pitfalls [PVSFGP12], and OntoPartS to represent part-whole relations better [KFRMG12].

There are many more tools, such as for ontology alignment, converting one language into another, tools for language extensions, and so on.

Portals

Other tools that can make an ontology developer’s life easier, are portals to more easily find ontologies and search them, and easily obtain some additional information. For instance, BioPortal [WNS⁺11] also lists an ontology’s use, OntoHub [CKK⁺17] analyses the characteristics of the ontology and which features have been used, and ROMULUS [KK16] and COLORE [GHH⁺12] zoom in on advanced aspects of foundational ontologies (the topic of the next chapter).

Exporting Ontologies

There are tools for exporting the knowledge represented in the ontology and rendering it in another format for documentation purposes. These include, notably, a conversion from OWL to latex so as to obtain the—to some, more readable—DL notation of the ontology (see “save as” in Protégé, select latex), and to automatically generate documentation alike software documentation, like in LiveOWL, LODE, and its successor WIDOCO [Gar17].

Develop Your Own Tool

There are many plugins and stand-alone tools. Still, it may be that what you need doesn’t exist yet. To develop your own tool, be it a standalone tool or as plugin, one does not have to start from scratch. For applications that have to read in or write to OWL files: rather than declaring your own regular expressions to find things in an OWL file and decalr methods to write into an OWL file, use the OWL API¹⁰, OWLink [LLNW11], or Apache Jena¹¹ for Java-based applications and Owlready for Python-based applications [Lam17].

Footnotes

³an axiom \(\beta\) is deemed weaker than another one, \(\alpha\) if and only if \(\alpha\models\beta\) and \(\beta\nvDash\alpha\)

⁴www.oeg-upm.net/oops

⁵and we ignore the fact that, according to Italians, pizzas are not supposed to have any fruit on a pizza—other than tomatoes—so the pizza Hawaii is not really an Italian pizza.

⁶Inclusion in this section does not mean I have tested all of them and give a quality judgement on it.

⁷http://neon-toolkit.org/

⁸https://www.w3.org/wiki/Ontology_editors and http://owl.cs.manchester.ac.uk/ tools/list-of-reasoners/

⁹protegewiki.stanford.edu/wik...Plugin_Library

¹⁰https://github.com/owlcs/owlapi

¹¹https://jena.apache.org/