Ontologies & Models

Preamble

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

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

That would suggest a wide range of logical or functional lineages with practical consequences for conceptual and meta modeling, data analytics, operational decision-making, knowledge management, and above all enterprise architecture.

Ontologies as Thesauruses

As introduced by Greek philosophers, ontologies are systematic accounts of existence for whatever is considered (i.e named), 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 lexicon or 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, epics, 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:

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

But thesauruses are best suited to flat semantics and don’t lend themselves to multi-dimensional modeling, as can be seen with the OWL (W3C’s Web Ontology Language) original version of the example above.

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.

Both can be extended as to serve predictive purposes.

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.

Ontos_cloudEA
Ontologies can be seen as symbolic representations floating above descriptive (context) and prescriptive (systems) 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 meanings and and semantic consistency.

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 introducing semantic stereotypes, e.g:

  • Categories of physical entities: plant, fruit, grape, beverage, and wine.
  • Categories of social 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.

The use of set operators may at first appear more challenging but their logical nature is a better fit for conceptual modeling:

Patterns of Connections (UML# notation)

Extending logic 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: depending on concerns, one could define wineries as a subset of enterprises (the focus being on business management), or indicate that wineries have some of enterprise aspects (the focus being on grapes and wines). 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.

Taking enterprise architecture as the domain of concern, 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 apply to 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.

Compared to models which are meant to be directed at business intelligence (predictive ones), requirements analysis (descriptive ones) or software design (prescriptive ones), an EA ontology would provide a conceptual framework encompassing the different semantics associated to business environment and enterprise resources, and supporting  the reasoning and decision-making needed for their governance.

Taking the Zachman Framework as example, a fourth semantic layer for data analytics and business intelligence would be added to the ones for architecture capabilities:

Ontos_semlays

Using ontologies to frame the semantics of business and systems capabilities could be a game-changer for EA governance, from strategic planning to operational decision-making.

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.
OKnow_TabOntos
Ontologies, capabilities (Who,What,How, Where, When), and architectures (enterprise, systems, platforms).

Using profiled ontologies to bridge the semantic gap between business contexts and enterprise architectures appears all the more critical with the generalization of digital environments and the spreading of self-learning systems.

To cope with these changes enterprises have to integrate data analytics, information processing, and decision-making. That approach, often labelled as economic intelligence, defines data, information, and knowledge, respectively as resources, assets, and service:

  1. Resources: data is captured through continuous and heterogeneous flows from a wide range of sources.
  2. Assets: information is built by adding identity, structure, and semantics to data.
  3. Services: knowledge is information put to use through decision-making.
Economic Intelligence: Bringing data mining, information processing, and knowledge management into a single conceptual framework

A workbench built with the Caminao ontological kernel is meant to explore the scope and benefits of profiled ontologies, with a beta version (Protégé/OWL 2) available for comments on the Stanford/Protégé portal using the link: Caminao Ontological Kernel (CaKe_).

Further Reading

External Links