Ontologies & Models


Given the ubiquity of the term, from philosophy to systems engineering and enterprise architecture, ontology could arguably be understood as the mother of modeling.

Astrological Ontologies are meant to put Reason into Stars (Ai Weiwei)

That would suggest the presence of logical or functional lineages with practical consequences for conceptual modeling, operational decision-making, knowledge management, and above all enterprise architecture.

Ontologies as Thesauruses

As introduced long ago by philosophers, ontologies are systematic accounts of existence for whatever is considered, in other words some explicit specification of the concepts meant to make sense of a universe of discourse. From that starting point three basic observations can be made:

  1. Ontologies are made of categories of things, beings, or phenomena; as such they may range from simple catalogs to philosophical doctrines.
  2. Ontologies are driven by cognitive (i.e non empirical) purposes, namely the validity and consistency of symbolic representations.
  3. Ontologies are meant to be directed at specific domains of concerns, whatever they can be: politics, religion, business, astrology, etc.

With regard to models, only the second one puts ontologies apart: contrary to models, ontologies are about understanding and are not supposed to be driven by empirical purposes.

On that basis, ontologies can be understood as thesauruses describing galaxies of concepts (stars) and features (planets) held together by semantic gravitation weighted by similarity or proximity. Taking wine for example:

Draft thesaurus for oenology: concepts (books) and features (pages) with standard logical operators for inverse, transitivity, and symmetry.

But thesauruses are for languages and don’t lend themselves to graphical modeling, as can be seen with the OWL (W3C’s Web Ontology Language) original version of the example above. What is needed is a modeling approach to ontologies.

Ontologies & Models

Compared to ontologies with their focus on semantics, the purpose of models goes beyond understanding and imply some pragmatic anchor to actual domains of concerns. Such modeling purposes can be summarily set in two basic categories:

  • Descriptive (aka extensional) ones take from reality, trying to put actual things, beings, or phenomena into categories defined with regard to domains of concerns.
  • Prescriptive (aka intensional) ones go the other way, being blueprints to be used to build artifacts.

Along that perspective, ontologies can be seen as floating above models because they are only concerned with the epistemic consistency of representations, independently of the practical reality to be represented. Being so detached, ontologies can pertain to descriptive as well as prescriptive models, e.g business for the former, systems for the latter.

Ontologies can be seen as floating above models

Given the higher perspective it may be tempting to associate ontologies with meta-models, but that could be misguided because meta-models are still models whose purpose is to describe and process other models, as compared to ontologies which are only concerned with understanding and internal validity.

On that detachment account, ontologies could still be understood as conceptual models to be used in systems modeling either for business or systems categories, or for the overlapping enterprise categories in-between.

Ontologies as Conceptual Models

If ontologies are to be put to use as models, they have to go beyond the sole understanding of a domain of concern and be driven by some purpose, e.g enterprise architecture.

As illustrated by W3C’s OWL, ontology languages cannot support conceptual modeling without semantic stereotypes, e.g:

  • Categories of physical entities: plant, fruit, grape, beverage, and wine.
  • Categories of symbolic entities: winery, enterprise.
  • Classifications of categories (aka power-types): wine grapes with associated geography, vintages.
  • Enumerations (partitions without associated properties): liquidity and edibility (exclusive), color.

Fleshing out an ontology backbone using semantic stereotypes

It must be noted that introducing partitions at category (power-types) and feature (enumerations) level makes labels redundant by removing semantic ambiguities.

Given a conceptual backbone the next step is to define reasoning capabilities.

Ontologies: Concepts + Logic

Reasoning capabilities are governed by integrity constraints, which can be specified with cardinality or logical set operators.

The former is often the option of choice as it’s more versatile and translates easily into programming; yet cardinality comes with the cons of its pros as it makes no difference between structural and functional integrity constraints.

Set operators may be more challenging but their logical nature is a better fit for conceptual modeling:

Patterns of Connections (UML# notation)

Extending the principle to sub-types (structures vs aspects) would bring ontologies on par with conceptual models:

  • Assuming that wines must be associated to a vintage (defined as a partition with a default option), the reference is part of their identity (#).
  • Wines are made of wine grapes, possibly multiple (/) but not to be modified (black).
  • Wines are not necessarily made by wineries but when they are the reference is exclusive (x) and cannot be modified (black).
  • Sub-types are understood as subsets (black) of plant and fruit, as aspects (white) for beverage and enterprise.

Using set operators to specify epistemic constraints

At this point it’s important to remind that, contrary to models, the validity of ontologies is internal: one could define wineries as a subset of enterprises, or indicate that wineries have some of enterprise aspects. Nonetheless, some integrity constraints may be more important than others, and logic operators can be used to make a formal distinction between alethic and deontic modalities:

  • Alethic rules deal with the existence of instances independently of their features or state. They are supposed to hold independently of the domains of concern.
  • Deontic rules are defined with regard to the meanings associated to features and their value for instances. They are specific to domains of concern.

Back to enterprise architecture as a purpose, that distinction could help ontologies to bridge the gap between business and system models, with deontic rules set separately for each, and alethic ones uniformly for both.

Ontologies & Enterprise Architecture

In  their pivotal article Davis, Shrobe, and Szolovits set five principles for knowledge representation

  1. Surrogate: KR provides a symbolic counterpart of actual objects, events and relationships.
  2. Ontological commitments: a KR is a set of statements about the categories of things that may exist in the domain under consideration.
  3. Fragmentary theory of intelligent reasoning: a KR is a model of what the things can do or can be done with.
  4. Medium for efficient computation: making knowledge understandable by computers is a necessary step for any learning curve.
  5. Medium for human expression: one the KR prerequisite is to improve the communication between specific domain experts on one hand, generic knowledge managers on the other hand.

Whereas models are meant to fully and consistently meet these requirements, ontologies do not: ontological commitments (2) are not supposed to be used for surrogates (1) nor be designed for efficient computation (4). Instead, ontologies are to focus on intelligibility and transparent reasoning (3, 5), and that can be seen as the main objective of enterprise architecture.

EA as an ontology of symbolic systems

Compared to models that are meant to be directed at system analysis (descriptive ones) or software design (prescriptive ones), the purpose of an EA ontology would be to provide a conceptual framework for systems (symbolic representations of business environment and enterprise resource) and governance (reasoning and decision-making). The Zachman Framework is arguably the current best example of  that approach:


Zachman’s Ontology of Architecture Capabilities

Ontologies & Knowledge Management

Insofar as enterprises are concerned, the primary objective of knowledge management is to support decision-making. For that purpose a wide range of regulatory, business, or technological domains must be taken into account, with different, overlapping or even conflicting semantics. Hence the benefits of a principled taxonomy of ontologies based on source and time-frame, e.g:

  • Social: pragmatic semantics, no authority, volatile, continuous and informal changes.
  • Institutional: mandatory semantics sanctioned by regulatory authority, steady, changes subject to established procedures.
  • Professional: agreed upon semantics between parties, steady, changes subject to established procedures.
  • Corporate: enterprise defined semantics, changes subject to internal decision-making.
  • Personal: customary semantics defined by named individuals.

Ontologies, capabilities (Who,What,How, Where, When), and architectures (enterprise, systems, platforms).

Crossing capabilities (Who,What,How, Where, When) and architectures (enterprise, systems, platforms) with archetypes of ontologies will help to link enterprise architecture workflows with knowledge of business and technical environments.

Further Reading

External Links



Your content with a new angle at WordPress.com

IT Modernization < V.Hanniet

About IT Modernization

IT Modernization < V. Hanniet

software model driven approaches

Caminao's Ways

Do systems know how symbolic they are ?

%d bloggers like this: