Skip to main content
Engineering LibreTexts

7.2: Foundational Ontologies

  • Page ID
  • \( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)

    \( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)

    \( \newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\)

    ( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\)

    \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\)

    \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\)

    \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\)

    \( \newcommand{\Span}{\mathrm{span}}\)

    \( \newcommand{\id}{\mathrm{id}}\)

    \( \newcommand{\Span}{\mathrm{span}}\)

    \( \newcommand{\kernel}{\mathrm{null}\,}\)

    \( \newcommand{\range}{\mathrm{range}\,}\)

    \( \newcommand{\RealPart}{\mathrm{Re}}\)

    \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\)

    \( \newcommand{\Argument}{\mathrm{Arg}}\)

    \( \newcommand{\norm}[1]{\| #1 \|}\)

    \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\)

    \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\AA}{\unicode[.8,0]{x212B}}\)

    \( \newcommand{\vectorA}[1]{\vec{#1}}      % arrow\)

    \( \newcommand{\vectorAt}[1]{\vec{\text{#1}}}      % arrow\)

    \( \newcommand{\vectorB}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)

    \( \newcommand{\vectorC}[1]{\textbf{#1}} \)

    \( \newcommand{\vectorD}[1]{\overrightarrow{#1}} \)

    \( \newcommand{\vectorDt}[1]{\overrightarrow{\text{#1}}} \)

    \( \newcommand{\vectE}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash{\mathbf {#1}}}} \)

    \( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)

    \( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)

    The basic starting point for top-down ontology development is to consider several core principles of Ontology for ontologies; or: some philosophical guidance for the prospective engineering artifact1. Although we will not delve into deep debates about philosophical theories in this course, it is useful to know it has something to offer to the development of ontologies, and we will see several examples where it has had influence. A few examples where results from philosophy can be useful when deciding what is going to be represented in one’s ontology, and how, are the following ones.

    • One can commit to a 3-Dimensional view of the world with objects persisting in time or take a(4-Dimensional (perdurantist) stance with space-time worms; e.g., are you convinced that you after reading this sentence is a different you than you before reading this sentence? If so, then you may well be a perdurantist, if you consider yourself to be the very same entity before and after, then you lean toward the 3D, endurantist, commitment (but before proclaiming to be one or the other based on this single example, do read up on the details and the implications).
    • The distinction between (in OWL terminology) classes and individuals: the former can have instances, but the latter cannot be instantiated further; e.g., a class Chair can have instances, such as the one you are sitting on now, but that chair cannot be instantiated further (it is already an individual object). Generally, philosophers tend to agree on such a distinction, but one has to decide whether one’s ontology is for individuals or for classes, or both.
    • In the previous chapters, we have used terms like class and concept as they are used in that specific field. Philosophically, however, terms like class, concept, universal, type, and category each have their very specific meaning and this brings us back to comments in Section 1.2: What is an Ontology "Some Philosophical Notes on Ontologies" concepts live in the mind/one’s thoughts, whereas universals are out there in the world (if one is convinced universals exist). OWL and its reasoners are entirely agnostic about this distinction, but the people who are reading, developing, and evaluating the ontologies typically are not.
    • Descriptivist vs. prescriptivist: should the ontology try to describe as best as possible the subject domain, i.e., give an account of it, or should that what is represented in the ontology prescribe how the world is, i.e., that the entities in the ontology and constraints represented necessarily must hold, and shown to hold, in reality? Conversely, if something is not represented in the ontology, then a descriptivist may say it was unintentionally incomplete whereas a prescriptivist may say not only that, but also, pedantically, argue that if it’s not in the ontology, then it does not exist in reality.

    Then there more detailed decision to make, such as whether you are convinced that there are entities that are not in space/time (i.e., that are abstract), whether two entities can be co-located (the vase and the amount of clay it is made of), and what it means that one entity is [dependent on/constituted by/part of/...] another. There are more of such questions and decision to make. If you do not want to entertain yourself with these questions, you can take someone else’s design decisions and use that in ontology development. Someone else’s design decisions on Ontology for a set of such questions typically is available in a foundational ontology, and the different answers to such questions end up as different foundational ontologies. Even with the same answers they may be different2. The intricacies of, and philosophical debates about, the more subtle details and differences are left to another course, as here the focus is one why to use one, where, and how.

    In the remainder of this section, we’ll first have a look at typical content of a foundational ontology (Section 6.1: Foundational Ontologies "Typical Content of a Foundational Ontology") and that there are multiple foundational ontologies (Section 6.1: Foundational Ontologies "Several Foundational Ontologies") to subsequently proceed to the why, where, and how to use them (Section 6.1: Foundational Ontologies "Using a Foundational Ontology").

    Typical Content of a Foundational Ontology

    Foundational ontologies provide a high-level categorization about the kinds of things that will be represented in the ontology, such as process and physical object, relations that are useful across subject domains, such as participation and parthood, and (what are and) how to represent ‘attributes’ in a particular subject domain, such as Color and Height (recall Section 1.3: What is the Usefulness of an Ontology?), which can be done, e.g., as quality or some kind of dependent continuant or trope. To make sense of this, let us start with the two main ingredients: the ‘class’ taxonomy and the relationships.

    Universals, Categories, Class Hierarchy

    Just like with other ontologies we have seen, also a foundational ontology represented in OWL has a hierarchy in the TBox. However, there are some differences with a domain ontology or tutorial ontology such as the AWO and the Pizza ontology. The hierarchy in a foundational ontology does not contain subject domain classes such as Boerewors and PizzaHawaii, but categories (or, loosely, ‘conceptual containers’) of kinds of things. For instance, all instances of PizzaHawaii can be considered to be physical objects, as are those sausages that are an instance of Boerewors. If we assume there to be physical objects, then presumably, there can also be entities that can be categorized as non-physical objects; e.g., the class (concept/universal/...) Organization, with instances such as the United Nations, fall in the category of social object, which are a type of non-physical object. Non-physical objects typically ‘inhere in’ physical objects, or physical objects are the ‘bearer’ of the non-physical ones; e.g., being an instance of Student is a role you play3 where the physical object is you as an instance of Human.

    Likewise, one can categorize kinds of processes. For instance, writing an exam is something that unfolds in time and has various sub-activities, such as thinking, writing, erasing pencil marks, and so on; taken together, writing an exam is an accomplishment. Contrast this with, say, an instance of Sitting: for the whole duration you sit, each part of it is still an instance of sitting, which thereby may be categorized as a state. None of the things mentioned in slanted font type in this paragraph actually are specific entity types that one would encounter in an ontology about subject domain entities only, yet we would want to be able to categorize the kinds of things we represent in our domain ontology in a systematic way. It is these and other categories that are represented in a foundational ontology.

    The categories introduced with the examples above actually are from the Descriptive Ontology for Linguistic and Cognitive Engineering (DOLCE) foundational ontology, and a screenshot of its hierarchy is shown in Figure 6.1.1-B. Behind this simple taxonomy in the picture, is a comprehensive formalization in first order predicate logic that was introduced in [MBG+03]. The taxonomy of the Basic Formal Ontology (BFO) v1 is shown in Figure 6.1.1-A, to illustrate that the DOLCE categories and their hierarchical organization are not the only way of structuring such core entities. (How to deal with such variety will be addressed further below).

    Being a pedantic ontologist, one could go as far as saying that if a category is not in the foundational ontology, then its developers are of the opinion it does not exist in reality. It is more likely that the ontology is incomplete in some way. There are efforts ongoing to harmonize the foundational ontologies better, to create a ‘core’ foundational ontology, and to standardize such a core. At the time of writing, this is under construction.

    Relations in Foundational Ontologies

    In analogy to the ‘subject domain classes’ in domain ontologies versus categories in foundational ontologies, one can identify generic relations/relationships/object properties that are different from those in domain ontologies. For instance, a domain ontology about universities may have a relation enrolled to relate Student to Course, or in a sports ontology that a runner runs a marathon. These relations are specific to the subject domain, but there are several that re-appear across domains, or: they are subject domain-independent. Such subject domain-independent relations are represented in a foundational ontology. Notable core relations are parthood (which we shall look at in some detail in Section 6.2: Part-Whole Relations), participation of an object in an event, constitution of an object (e.g., a vase) from an amount of matter (such as clay), and dependency when the existence of one entity depends on the existence of another. The characterization of such relations go hand in hand with the categories from a foundational ontology, so as to be precise rather than alluding to ‘object’ or ‘event’ and assuming your and my intuition about what those things really mean are the same. For instance, one thus could assert that, say, participates in holds only between exactly a dolce:Endurant, which is an entity that is wholly present at a time, and a dolce:Perdurant (an entity that unfold in time).

    Screenshot (90).png

    Figure 6.1.1: Screenshots of the OWLized BFO v1 and DOLCE taxonomies; for indicative purpose: Perdurant \(≈\) Occurrent, Endurant \(≈\) IndependentContinuant.

    It is a typical characteristic of foundational ontologies to have a set of relations that are used heavily in axioms so as to constrain the possible models as much as one reasonably can.


    The third main component of representing knowledge the foundational ontology way are attributions, as, just like in conceptual data modeling, ‘attributes’ have to be represented somehow. There is a domain-specific component to it and there are general, recurring, principles of attributions, and it is the latter that are captured in an foundational ontology—to some extent at least. However, this is represented quite differently from attributes you have modeled in UML or EER.

    Let us first revisit the ‘attribute’ Color that we have come across in Section 1.3: What is the Usefulness of an Ontology? "Data and Information System Integration" and Figure 1.3.1 when trying to integrate legacy systems. One could decide to make it a data property in OWL, declare its domain to be Rose and choose the data type String, i.e., \(\texttt{hasColor}\mapsto\texttt{Rose}\times\texttt{String}\) in ontology \(\mathcal{O}_1\), or, in OWL functional syntax style notation:

    DataPropertyDomain(ex:hasColor ex:Rose)

    Screenshot (91).png

    Figure 6.1.2: DOLCE’s approach for qualities (‘attributes’) (Source: [MBG+03])

    DataPropertyRange(ex:hasColor xsd:string)

    That is, a binary relationship, which is the same approach as in UML class diagrams. Now, if another ontology developer decided to record the values in integers in \(\mathcal{O}_2\), then the hasColor properties in \(\mathcal{O}_1\) and \(\mathcal{O}_2\) are incompatible in the representation. Or consider the scenario where \(\mathcal{O}_1 =\texttt{AWO.owl}\) that has a data property hasWeight for any object, including elephants, and its XML data type set to integer. One can declare, e.g., \(\texttt{Elephant}\sqsubseteq =\texttt{1 hasWeight.integer}\). Perhaps a hasWeightPrecise with as data type real may be needed elsewhere; e.g., in ontology \(\mathcal{O}_2\) that will be used for monitoring all the animals in the zoo’s in your country in, say, Europe. Implicitly, it was assumed by the developers that the weight would be measured in kg. Then someone from the USA wants to use the ontology, but wants to record the weight in lbs instead, which then amounts to adding, say, hasWeightImperial or the developer has to fork the ontology with such a data property, and so on, all about weights. Now the WWF wants to link both zoo management systems across the pond and compare it with African wildlife. What should the WWF IT specialists do? What is happening here is a replication of the very same issues encountered in database integration. But this was precisely what ontologies were supposed to solve! Copying the problem from information systems into the ontologies arena (perhaps because you’re more familiar with that way of modeling things), is not going to solve the interoperability problem. It is still the case that there’s a sameness of conceptualization and/or reality—like Color, and the meaning of Weight is all the same throughout as well. Thus, we need something else.

    The first step toward resolving the issue is to realize that the choice of datatype is an implementation decision, just like it is in database development from the EER diagram to SQL schema. Even EER as conceptual data model already has the underlying principle to be implementation-independent, so surely should the ontology be, for it is typically expected to be even application-independent. In short: if one indeed aims for the purposes of interoperability and reusability across applications by means of an ontology, then don’t use data properties and data types.

    The next step then is: how to solve that problem? That other way of handing attributions is the one typical of foundational ontologies and their respective OWLized versions. The idea is to generalize (more precisely: reify) the attribute into a class so that we can reuse the core notion that is the same throughout (Color and Weight in the examples), and this new entity is then related to the endurants and perdurants on the one side and instead of datatypes, we use value regions on the other side. Thus, an unfolding from one attribute/OWL data property into at least two properties: there is one OWL object property from the endurant/perdurant to the reified attribute—a quality property, represented as an OWL class—and a second object property from quality to the value region. In this way, the shared understanding can be shared, and any specifics on how one has to store the data is relegated to the implementation, therewith solving the problem of the limited reusability of attributes and preventing duplication of data properties. For instance, Color would be a subclass of Quality in DOLCE [MBG+03] and a Specifically dependent continuant in BFO. An example of the approach taken in DOLCE is depicted in Figure 6.1.2: rose1 is an instance of Rose, which is a subclass of NonAgentive Physical Object, and it is related by the qt relation to its colour property, c1, which is an instance of the quality Color that is a subclass of Physical Quality. The actual value—the [measured] redness—of the color of the rose at a given time is a region red color as instance of the Color Region, which is a subclass of Physical Region, and they are related by means of the q|t relation4.

    The remaining step one may have to take is the case when one really has to represent some values in the ontology itself, which is something that the foundational ontologies are silent about. The least complicated and most reusable option is to create a data property, say, hasDataValue with the Region class as domain and XML data type anyType as range. This allows one to use the attributions across ontologies and tools, yet leaves the flexibility to the implementer to choose the actual data type.

    This concludes the brief idea of what is in a foundation ontology. As you will have observed, there are several foundational ontologies, which may be confusing or look like overcomplicating things, so we spend a few words on that now.

    Several Foundational Ontologies

    In this section, a selection of the foundation ontologies are summarized with respect to their ontological commitments.


    As the name suggests, the Descriptive Ontology for Linguistic and Cognitive Engineering (DOLCE) has a strong cognitive/linguistic bias. It takes a descriptive (as opposite to prescriptive) attitude and the categories mirror cognition, common sense, and the lexical structure of natural language. The emphasis is on cognitive invariants and the categories are intended as ‘conceptual containers’ in the sense that there are no deep metaphysical implications. Further, its documentation [MBG+03] focuses on design rationale so as to facilitate a comparison with different ontological options. It is rigorous, systematic, and has a rich axiomatisation. Concerning the size, it may look ‘small’ from an OWL ontologies viewpoint, having 37 basic categories, 7 basic relations, 80 axioms, 100 definitions, and 20 theorems, but it is a rather dense ontology nonetheless. Besides the paper-based version in [MBG+03], there are also several versions in OWL (Dolce-lite, Dolce-lite Plus, ultralight), where some concessions have been made to force the formalization into a less expressive language. Some more information and downloads of the various versions are available5.

    BFO and the RO

    The Basic Formal Ontology (BFO)6 sees Ontology as reality representation. It aims at reconciling the 3-dimensionalist and 4-dimensionalist views with a ‘Snap’ ontology of endurants, which is reproduced at each moment of time and is used to characterize static views of the world, and a ‘Span’ ontology of happenings and occurrents and, more generally, of entities which persist in time by perduring. It has a limited granularity and is heavily influenced by parthood relations, boundaries, dependence.

    Its version 1 is a bare taxonomy, i.e., there are no relations/object properties. There is a separate Relation Ontology (RO) [SCK+05], which was developed to assist ontology developers in avoiding errors in modeling and assist users in using the ontology for annotations, and such that several ontologies would use the same set of agreed-upon defined relations to foster interoperability among the ontologies. Philosophically, it is still a debate what then the ‘essential’ relations are to represent reality, and if those included are good enough, are too many, or too few. Several extensions to the RO are under consideration and refinements have been proposed, such as for RO’s transformation_of [Kee09] that avails of theory underlying OntoClean and derived_from [Bro06].

    Meanwhile, BFO v2.0 is richly annotated, the forked ROcore7 does use relevant BFO classes for the domain and range of the incorporated RO relations, whereas the forked draft release of BFO v2.1 (of 2014) takes yet another route where most names of the relations suggest temporality and thus indicate a different intended meaning, yet OWL is atemporal. There is also a BFO Core with mereological theories8.


    The General Formal Ontology (GFO)9 [HH06] is a component of an integrated system of foundational ontologies that has a three-layered meta-ontological architecture. The three layers are the abstract core level (ACO), the entities of the world (ATO) that are exhaustively divided into categories and individuals, where individuals instantiate categories, and among individuals, there is a distinction between objects and attributives, and the basic level ontology that contains all relevant toplevel distinctions and categories. It has (3D) objects and (4D) processes, admitting universals, concepts, and symbol structures and their interrelations. There are also modules for functions and for roles, and s slimmed version GFO-basic.

    Other Foundational Ontologies

    There are several other foundational ontologies that did not receive their separate paragraph in this version of the textbook as the aim is to have about 20 pages per chapter. They include, in alphabetical order:

    • GIST minimalist upper ontology [McC10];
    • GUM, the Generalized Upper Model, driven by natural language [BMF95];
    • SUMO, the Standard Upper Merged Ontology [NP01], which was an early FO and has relatively very many classes and relations;
    • UFO, the Unified Foundational Ontology [Gui05];
    • YAMATO, the Yet Another More Advanced Top-level Ontology, which focuses on qualities and processes and events [Miz10].

    To the best of my knowledge, only GIST, UFO, and YAMATO are being maintained or extended at the time of writing.

    On Multiple Foundational Ontologies

    The documentation of the foundational ontologies contain further details about their formalization and the rationale for having modeled it in the way they did; e.g., that DOLCE takes a multiplicative approach, GFO lets one represent both universals and individuals in the same ontology, BFO claims a realist approach, and so on. Their properties have be structured and are included in the ONSET tool that assists an ontologist with selecting a suitable foundational ontology for one’s own domain ontology based on the selected requirements [KK12]. It saves the suer reading the foundational ontology literature to large extent, and all of those new terms that have been introduced (like “multiplicative”) have brief informal explanations. There will be an exercise about it at the end of the chapter.

    One can wonder whether such foundational ontologies just use different names for the same kind of entities, but are essentially all the same anyway. Only very few detailed comparisons have been made. If we ignore some intricate philosophical aspects, such as whether universals and properties exist or not, then still only few entity-by-entity alignments can be made, and even less mappings. An alignment is a mapping only if asserting the alignment in the new ontology containing the (foundational) ontologies does not lead to an inconsistency. Table 6.1.1 lists the common alignments among DOLCE, BFO, and GFO. More alignments and mappings are described and discussed in [KK15] and a searchable version is online in the foundational ontology library ROMULUS [KK16].

    1. endurant Independent Continuant Presential
    2. physical-object Object Material_object
    3. perdurant Occurrent Occurrent
    4. process Process Process
    5. quality Quality Property
    6. space-region SpatialRegion Spatial_region
    7. temporal-region Temporal-Region Temporal_region
    Relational Property
    1. proper-part has_proper_part has_proper_part
    2. proper-part-of proper_part_of proper_part_of
    3. participant has_participant has_participant
    4. participant-in participates_in participates_in
    5. generic-location located_in occupies
    6. generic-location-of location_of occupied_by

    Table 6.1.1: Common alignments between DOLCE-Lite, BFO and GFO; the ones numbered in bold can also be mapped. (Source: [KK13a])

    In closing, observe that there are different versions of each foundational ontology, not only differentiating between a formalization on paper versus what is representable in OWL, but also more and less detailed versions of an ontology. The other main aspect from an engineering perspective, is to choose the most suitable foundational ontology for the task at hand.

    Using a Foundational Ontology

    Having some idea of what a foundational ontology is, is one thing, but how to use them is a different story, and one that is not fully resolved yet. In this subsection, we start first with answering why one would want to use one at all, and some examples where it helps a modeler in making modeling decisions for the overall (domain) ontology. We then turn to some practical aspects, such as their files, language used, and how (where) to link one’s domain entities to those generic categories in a foundational ontology.

    Why Use a Foundational Ontology?

    Foundational ontologies exist, but does that means one necessarily must use one? Not everybody agrees on the answer. There are advantages and disadvantages to it. The principal reasons for why it is beneficial are:

    • one does not have to ‘reinvent the wheel’ with respect to the basic categories and relations to represent the subject domain,
    • it improves overall quality of the ontology by using principled design decisions, and
    • it facilitates interoperability among ontologies that are aligned to the same foundational ontology.

    From the viewpoint of Ontology, a foundational ontology serves to clarify philosophical details and be upfront about them, bring assumptions to the fore and justify them, and, with that, it may become clear where there are any philosophical agreements and disagreements and what their underlying causes are.

    A subset of domain ontology developers do not see a benefit:

    • they consider them too abstract, too expressive and comprehensive for the envisioned ontology-driven information system, and
    • it takes excessive effort to understand them in sufficient detail such that it would not weigh up to the benefits.

    A controlled experiment has been carried out with 52 novice ontology developers, which showed that, on average, using a foundational ontology resulted in an ontology with more new classes and class axioms, and significantly less new ad hoc object properties than those who did not, there were no part-of vs. is-a mistakes, and, overall, “the ‘cost’ incurred spending time getting acquainted with a foundational ontology compared to starting from scratch was more than made up for in size, understandability, and interoperability already within the limited time frame of the experiment” [Kee11b]. There is room for further experimentation, but results thus far point clearly to a benefit.

    Modelling Guidance: Examples of Some Principal Choices

    An immediate practical benefit is that Ontology and foundational ontologies help preventing making novice ontology developer’s mistakes, such as confusing parthood with subsumption and class vs instance mix-ups. The former will become clear in Section 6.2: Part-Whole Relations (e.g., a province is part of a country, not a subclass). Regarding the latter, ontologically, instances/individuals/particulars are, roughly, those things that cannot be instantiated, whereas classes (or universals or concepts) can. For instance, the chair you are sitting on is an instance whereas the class Chair can be instantiated (the one you are sitting on is one such instance). Likewise, MacBookPro is a type of laptop, which in an OWL ontology would be added as a subclass of Laptop, not as an instance of Laptop—the MacBook I have with serial number \(\sharp\texttt{123456}\) is an instance, and, likewise, GoldenDelicious is a subclass of Apple, not an instance (the actual instances grow on the tree and are on the shelves in the supermarket).

    An example on choosing how to represent relations is described next.

    Example \(\PageIndex{1}\):

    A relation, i.e., an \(n\)-ary with \(n\geq 1\), can be represented as an unary entity (a class in OWL) or as a \(n\)-ary relation (object property in OWL if it is a binary). It is certainly more intuitive to keep the \(n\)-aries as such, because it indicates a close correspondence with natural language. For instance, in formalizing “Person runs marathon”, it is tempting to represent “runs” as an object property runs and assert, say, \(\texttt{Marathon}\sqsubseteq\exists\texttt{runs}^{-}.\texttt{Person}\).

    The foundational ontologies take a different approach. Such perdurants, like running, and the verbs we use to label them, are included as an unary (OWL class) suitably positioned as a subclass of ‘processes’, being Perdurant in DOLCE and Occurrent in BFO, which are then related with a new relation to ‘objects’, which are suitably positioned subclasses of Endurant in DOLCE (Continuant in BFO), in such a way that an endurant is a participant in a perdurant. For instance, still with the TBox-level knowledge that “Person runs marathon”, then Running (being a subclass of Process) has participant some Person (i.e., \(\texttt{Running}\sqsubseteq\exists\texttt{has_participant.Person}\)) and another binary to Marathon (e.g., \(\texttt{Marathon}\sqsubseteq\exists\texttt{involves.Running}\)), but there is no 1-to-1 formalization with an object property runs that has as domain and range Person and Marathon.

    The option with runs results in a more compact representation, is intuitively closer to the domain expert’s understanding, and makes it easier to verbalize the ontology, and therefore is likely to be more useful in praxis. The Running option is more generic, and thereby likely to increase reusability of the ontology. No scientific experiments have been conducted to test which way would be better to represent such knowledge, and current mapping tools do not deal with such differences of representing roughly the same knowledge in syntactically very different ways. Theoretical foundations for mappings between such distinct modeling styles have been proposed [FK17], and this may be resolved soon.

    Whichever way one chooses to represent such information, adhering to that choice throughout the ontology makes the ontology easier to process and easier to understand by the human reader.

    A longer and practical example and exercises with the African Wildlife Ontology is included in the next section.

    Practical Aspects on Using a Foundational Ontology

    It was already mentioned that there are OWL-ized versions of several foundational ontologies, but there is more to it. Once the most appropriate foundational ontology is selected, the right version needs to be imported either in full or a module thereof, and it has to be linked to the entities in your ontology. The latter means you will have to find out which category each of your entity is and which object properties to use.

    Some 15 years ago researchers already realized it might not be feasible to have one singe foundational ontology that pleases everybody; hence, the idea emerged to create a library of foundational ontologies with appropriate mappings between them so that each modeler can choose her pet ontology and the system will sort out the rest regarding the interoperability of ontologies that use different foundational ontologies. The basis for this has been laid with the Wonderweb deliverable D18, but an implementation was yet to be done and new foundational ontology developments have taken place since 2003. A first step in the direction of such a foundational ontology library has been laid recently with the Repository of Ontology for MULtiple USes, ROMULUS [KK13b]. ROMULUS focuses on OWL ontologies in particular.

    The leaner OWL versions of DOLCE and BFO have been made available and are intended to be used for development of ontologies in one’s domain of interest. These files can be found on their respective websites (see earlier footnotes), which also lists domain ontologies that use them. Observe that DOLCE-Lite is encoded in the DL language that is characterized by \(\mathcal{SHI}\), BFO is simpler (in \(\mathcal{ALC}\)); that is, neither one uses all OWL-DL capabilities of \(\mathcal{SHOIN (D)}\), let alone all OWL 2 DL features. Recall that another difference is that BFO-in-owl is only a bare taxonomy (extensions with the RO do exist; see Section 6.1: Foundational Ontologies "Several Foundational Ontologies"), whereas DOLCE-Lite makes heavy use of object properties.

    To make reuse easier, ‘clever modules’ of foundational ontologies may be useful, such as light/basic and full versions according to the developers’ taste, a separate major branch of the ontology (e.g., using only Endurants), and a computationally better behaved fragment with the best semantic approximation of the full version (i.e., not merely dropping the violating axioms), such as an OWL 2 EL compliant fragment of DOLCE. Some of those are also available from the aforementioned ROMULUS and, by extension, the OntoHub ontology libraries.

    Once the foundational ontology is imported (not leaded and extended), the task is to find the right classes to link one’s domain classes to, and likewise for the object properties. The whole process is illustrated in the following example, starting with a very basic African Wildlife Ontology, and gradually extending it and improving its quality.

    Example \(\PageIndex{2}\):

    Continuing with the African Wildlife Ontology from Example 4.1.1, a first step to improve its quality may be to add knowledge to ensure a better coverage of the subject domain. Adding classes and object properties to an ontology does not necessarily make a better quality ontology. One aspect that does with respect to the subject domain, is to refine the represented knowledge further and with more constraints so as to limit the possible models; e.g.: 1) giraffes eat not only leaves but also twigs, 2) they are disjoint from impalas, and 3) more object property characteristics, e.g., that the is-part-of is not only transitive, but also reflexive, and is-proper-part-of is transitive and irreflexive or asymmetric (recall that the latter can be added thanks to the increased expressiveness of OWL 2 DL compared to OWL-DL, but not both irreflexivity and asymmetry).

    Third, we can improve the ontology’s quality by using a foundational ontology, as mentioned in Section 6.1: Foundational Ontologies "Using a Foundational Ontology"; e.g., one of DOLCE, BFO, GFO, SUMO, and YAMATO that were introduced in Section 6.1: Foundational Ontologies "Typical Content of a Foundational Ontology" and all happen to have OWLized version of them.

    For the sake of example, let us take DOLCE to enrich the African Wildlife Ontology. To do this, we need to import into the AWO an OWLized version of DOLCE; in this case, this means importing DOLCE-lite.owl. Then, consider first the taxonomic component of DOLCE in Figure 6.1.1-B (for details, see Wonderweb deliverable D18 Fig 2 p14 and Table 1 p15 or explore the imported ontology with its annotations).

    • Where does Plant fit in in the DOLCE categorization?
    • Giraffes drink water: where should we put Water?
    • Impalas run (fast); where should we put Running?
    • Lions eat impalas, and in the process, the impalas die; where should we put Death?

    To answer such questions, we have to look at the principal distinctions made in DOLCE among its categories. Let us take Plant: is Plant wholly presents during its existence (enduring), or is it happening in time (perduring)? With a 3D versus 4D worldview, the former applies. Within endurants, we look at its subclasses, which are Arbitrary Sum, Physical Endurant, and Non-Physical Endurant: a plant is certainly not some arbitrary collection of things, like the set of this lecture notes and your pencil are, and a plant takes up physical space, so one chooses Physical Endurant. We repeat this for the subclasses of Physical Endurant, which are Feature, Amount of Matter, and Physical Object. A feature (in DOLCE) is something like a bump in the road or the hole in a swiss cheese, hence quite distinct from Plant (but a plant can have such things). Amount of matter is in natural language normally denoted with a mass noun, such as gold and water, and it can be counted only in quantities (a liter of water); however, plants can be counted, so they are physical objects and, hence, we can add \(\texttt{AWO:Plant}\sqsubseteq\texttt{dolce:PhysicalObject}\) to the ontology. One can find the alignments for the other ones in a similar step-wise way, which may be assisted by the decision diagram in Figure 6.1.3. The answers can be found in AfricanWildlifeOntology2a.owl.

    DOLCE is more than a taxonomy, and we can also inspect in more detail its object properties and reuse the properties already defined instead of re-inventing them. First, the African Wildlife Ontology’s is-part-of is the same as DOLCE’s partof, and likewise for their respective inverses, so declare them equivalent. Concerning the subject domain, here are a few modeling questions.

    1. The Elephant’s Tusks (ivory) are made of Apatite (calcium phosphate, an amount of matter); which DOLCE relation can be reused?
    2. Giraffes eat leaves and twigs; how do Plant and Twig relate?
    3. How would you represent the Size (Height, Weight, etc.) of an average adult elephant; with DOLCE’s Quality or an OWL data property?

    Answers to the first two questions are included in AfricanWildlifeOntology2a.owl. Note first that \(\texttt{AWO:Tusk}\sqsubseteq\texttt{dolce:PhysicalObject}\) and \(\texttt{AWO:Apatite}\sqsubseteq\texttt{dolce:AmountOfMatter}\), so we need to find an object property that has as domain a physical object and as range an amount of matter; at present, the easiest way to find out, is to run it through the OntoPartS tool [KFRMG12], which returns the constitution relation as the only one that fits these constraints. OntoPartS’s constitution is more restrictive than DOLCE’s, so one can either 1) use dolce:generic-constituent that relates perdurants or endurants or 2) add AWO:constituted-of with domain and range

    Screenshot (93).png

    Figure 6.1.3: The Decision Tree of D3; a single branch can be selected at a time. (Source: [KKG13b])

    dolce:PhysicalObject and range dolce:AmountOfMatter and add \(\texttt{AWO:constituted-of}\sqsubseteq\texttt{dolce:generic-constituent}\), and then assert \(\texttt{Tusk}\sqsubseteq\exists\texttt{constituted-of.Apatite}\) in the ontology. Option 1 has the benefit of direct reuse of a relation from DOLCE instead of inventing one’s own from scratch, whereas option 2 is more restrictive and precise, thereby also improving the ontology’s quality.

    How does it work out when we import the OWL version of BFO v2.0 into AfricanWildlifeOntology1.owl? Aside from minor differences—e.g., Death is not a type of Achievement as in DOLCE, but a ProcessBoundary instead, and animals and plants are subtypes of Object, see also Figure 6.1.1-A—there is a major difference with respect to the object properties (BFO has none). A possible outcome of linking the same entities of the wildlife ontology to BFO is included in AfricanWildlifeOntology3a.owl. To do these last two exercises with DOLCE and BFO in a transparent and reusable way, a mapping between the two foundational ontologies is needed. Even more so: with a mapping, only one of the two exercises would have sufficed and software would have taken care of the mappings between the two. ROMULUS has both mapping and a solid method and tool to ‘swap’ a foundational ontology [KK14].

    One could take the development a step further by adding types of part-whole relations so as to be more precise than only a generic part-of relation: e.g., Root is a structural part of some Plant and NatureReserve is located-in some Country, which will be discussed in some detail in the next section. Another option is to consider a Content Ontology Design Pattern10, such as being more finicky about names for plants and animals with, perhaps, a Linnaean Taxonomy content pattern or adding some information on Climatic Zones where the plants and animals live, and so on11.

    Such patterns are the topic of Section 7.6: Ontology Design Patterns.

    You may like to inspect a real ontology that is linked to DOLCE as well. There are multiple examples, such as BioTop [BSSH08] that is linked to both DOLCE and BFO-RO, and the Data Mining Optimization Ontology we have come across in Section 1.3: What is the Usefulness of an Ontology? "Ontologies as Part of a Solution to Other Problems" [KLd+15]. A selection of the links is depicted in Figure 6.1.4.

    Methods and supporting tools are being developed that are informed by foundational ontologies or provide actual support using them, e.g., [HOD+10, KK12, KKG13b, KK16, Hep11], but more can be done to assist the modeler in the ontology authoring process involving foundational ontologies.

    Screenshot (94).png

    Figure 6.1.4: Selection of DMOP classes linked to DOLCE.


    1As philosophy enters, a note about terminology may be in order, because some ideas are borrowed and changed, and some terms that are the same do mean different things in different disciplines. In the literature, you will come across material ontology and formal ontology. The former (roughly) concerns making an ‘inventory’ of the things in the universe (we have the vase, the clay, the apple, etc.), whereas the latter concerns laying bare the formal structure of (and relation between) entities, which are assumed to have general features and obey some general laws that hold across subject domains, like identity, constitution, and parthood (the latter will be introduced in Section 6.2: Part-Whole Relations). So, in ontology engineering the ‘formal’ may refer to logic-based but also to the usage of ‘formal’ in philosophy, which concerns the topic of investigation and does not imply there is a formalization of it in a logic language. In most computer science and IT literature, when ‘formal’ is written, it generally refers to logic-based.

    2see, e.g. beyond concepts [Smi04], the WonderWeb deliverable [MBG+03], and a synopsis of the main design decisions for DOLCE [BM09]

    3not ‘role’ as in DLs or ORM, but role in the common sense meaning.

    4There are alternative theories in philosophy one can commit to whilst taking the unaries approach to attributes, but this would be more suitable for an intermediate level of ontology engineering.






    11But note that regarding content, one also can take a bottom-up approach to ontology development with resources such as the Environment Ontology ( or pick and choose from ‘semantified’ Biodiversity Information Standards ( etc. Bottom-up approaches are the topic of the next chapter.

    This page titled 7.2: Foundational Ontologies is shared under a CC BY 4.0 license and was authored, remixed, and/or curated by Maria Keet via source content that was edited to the style and standards of the LibreTexts platform; a detailed edit history is available upon request.