Caminao Ontological Kernel (Protégé/OWL 2)


The immersion of enterprises into digital environments calls for a seamless integration of data analytics, information systems, and knowledge based decision-making. That can be best achieved through an ontological approach to enterprise architecture frameworks.

What they see is what you get (Mantegna)

To that end a kernel prototype is being build combining the Stanford’s modeling paradigm with established cognitive and knowledge principles:

  • Targets: actual or symbolic.
  • Connections: associations and analogies.
  • Processing: truth-preserving or domain specific reasoning.
  • Layers according to: epistemic nature of contents (concepts, documents, or artifacts), functional nature of contents (environment, enterprise, systems, platforms), and contexts (institutional, professional, corporate, social).

A beta version using  OWL 2 is available for comments on the Stanford/Protégé portal with the link: Caminao Ontological Kernel (CaKe).


From a theoretical perspective the objective is to demonstrate the benefits of the Stanford modeling paradigm that defines systems as containers managing symbolic representations (aka surrogates) of operational environments.

From a functional perspective the kernel is to meet the principles of knowledge representation set by Davis, Shrobe, and Szolovits  in their seminal article:

  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.

On that basis ontologies deal with numbers 1,2,3, and 5, and models with numbers 4 and 5. The proposed approach is to use ontologies for profiles and domains as to support a seamless conceptual integration with model based systems engineering (MBSE).


That is to be achieved through a compact set of unambiguous concepts, straightforward modeling principles, and implementation with Stanford University’s Protégé/OWL 2.

Concepts, Categories, Aspects, Documents

The kernel is built on four kind of things (terms) corresponding to the epistemic nature of targeted elements:

  • Concepts (e.g Contract): intensional concepts come with core necessary semantics detached of any context or purpose; extensional concepts orbit intensional ones and are about heterogeneous sets of instances.
  • Categories (aka classes, aka types): terms for sets of instances. Power-types represent categories of categories.
  • Aspects: terms for structural or functional descriptions that cannot be instantiated (aka valued) on their own.
  • Documents (e.g Requirements): terms for the nature of information contents, with instances for actual contents.
  • Items (aka terms, aka labels) are characters strings with no semantics.

Besides concepts and documents, which correspond to thesaurus and content management systems (CMS), the backbone of the kernel is built around categories of  actual and symbolic entities.

Then, a formal distinction is made between entities identified independently (object, agent, actor, events, processes, …) and aspects (aka facets), which can only be instanciated in association with entities.  Aspects are detailed using generic constructs (collection, composition, graph, logic, …) that can be applied uniformly across categories.

Compared to items that represent nothing, partitions  (aka powertypes) represent categories of categories to be managed as business objects on their own, possibly across domains; items (with indexes) being used to map entities to partitions.

Since aspects are not meant to directly represent individuals in domains, they can be defined according to standards, generic of functional constructs:

  • Features (Properties and operations).
  • Numeric and logic expressions.
  • Abstract data types (collections, graphs, …)
  • Rules and heuristics.

Contrary to categories, whose instances are to be checked for external consistency, aspects have only to be checked for internal consistency.

Objects properties (Connectors)

Connectors being of the essence of knowledge, their semantics is to make the difference. On that account, three kind of connectors are distinguished, depending on targets.

Functional (aka semantic) connectors are set at instance level with semantics defined by modeling perspective:

  • References connectors can points to symbolic representations (aka surrogates) or to other entries. The kernel provides generic references for core modeling artefacts: activities, locations, processes, actors, events, etc.
  • Flows connectors are associated to exchanges between activities: passive symbolic or actual content, or active requests.
  • State connectors (aka transitions) are associated to the synchronization of processes execution.
  • Channels connectors represent the communication links between actual objects and locations according to capabilities: physical, digital, or symbolic.

Structural (aka syntactic) connectors are set at representation level. Generic ones coincide with established standards for collections, aggregates, and compositions; they are meant to be executable and support truth-preserving operations independently of domain semantics.

Logical connectors do the same for rules:providing for the definition of  left or/and right footprints and expressions.

Semiotic connectors are set at linguistic level. Predefined ones deal with basic associations (synonyms, homonyms, metaphors, metonymies, etc); they are meant to support cognitive operations independently of domain-specific semantics.

Combining formally defined nodes and connectors greatly enhances the transparency and consistency of models independently of the semantics refinements to be added.

Generic Functional & Structural Connectors (blue)

Abstraction connectors are set at category level with semantics defined by epistemic nature of targeted elements.


Abstraction is arguably at the core of knowledge, hence the importance of reliable representations. But as far as ontologies are concerned, it can take different meanings depending on targeted elements:

  • Items represent basic elements about which nothing is known except labels.
  • By contrast, concepts are used for knowledge wholly detached from domains’ instances and features.
  • Classes (or types) is OWL’s default option, for which specialization usually implies inheritance of features.
  • Partitions are types of types and are introduced for subsets of instances with commonly valued features.

Using OWL to describe the different aspects of enterprise architectures (data, information models, knowledge and decision-making)  calls first for refined the semantics of classes sub-types:

  • Conceptual sub-types are intensional: specialization of meaning.
  • Documents sub-types are intensional: specialization of topics.
  • Category sub-types are extensional: subsets of instances.
  • Aspect sub-types are intensional: subsets of features.

Then, inheritance semantics must ensure the consistency of descriptions across abstraction levels. To that end, the Liskov Substitution Principle originally defined for intensional (aka design) models should be generalized to all representations:

  • Usual software design semantics (features inheritance) is to be used for all intensional descriptions (OWL’s default option for classes).
  • That understanding can be extended to all objects categories, symbolic or actual.
  • In contrast, inheritance of phenomena (events and behaviors) is to be defined with regard to circumstances and execution paths.

As the difficulty arises for extensional categories (i.e descriptions tied to external instances), partitions, which like structural and functional links operate at instance level,  is to be used as the first step of specialization, which deals with categories. Conversely, concepts can be used to pave the way to generalization.

Given the formal definition of aspects, categories, and partitions, it’s then possible to combine unambiguous semantics of delegation and inheritance connectors:

  • Subsets: a customer is a person with gender (structural partition).
  • Type realization: a dish item is an item
  • Aspect specialization:  customers behavior depends on functional (income and education) and analytical partitions (profile).
  • Role specialization: customers can also appear as actors in other contexts.

Partitions can be defined with a generic connector (partitionedBy_) or specifically.

data Properties

The kernel introduces a number of data properties beside OWL 2 native ones:

Cake data props

  • Architecture level: {“enterprise” , “environment” , “platforms” , “systems”}. Used to define and manage ontology profiles.
  • Social identity: Literal.
  • Behavior: {“passive” , “proactive” , “reactive”}. Used to characterize objects and rules as well as for consistency checks.
  • Change footprint:  {“expectation” , “physical” , “state” , “symbolic”}. Used to characterize events and consistency checks.
  • Rule modus-operandi: backward or forward.
  • Statutory context: {“institutional” , “professional” , “corporate”,”social”, “personal”}.
  • Embodiment: {“hybrid” , “physical” , “statutory”}. Used to characterize the organizational basis of collective agents.
  • Exclusivity: Boolean. Used to characterize power-types.
  • Mutability: Boolean. Used to characterize power-types.
  • Partitions: Enumeration. Used to characterize power-types.
  • Extensional: Boolean. True if associated with instances. Used for consistency checks.
  • Language abilities: Boolean for formal, natural, and domain specific language ability. Used for consistency checks.
  • Synchronization: {“asynchronous” , “detached” , “synchronous”}. Used to characterize the coupling between actual and symbolic realms, and check consistency.

Annex: Examples

These examples are focused on three key benefits of the approach, namely:

  • The distinction between representation syntax and contents semantics.
  • The distinction between truth-preserving and functional reasoning.
  • The processing of data into information and knowledge.

Syntax & Semantics: Categories, Aspects, Properties

The distinction between objects and aspects has a well established track record in software design and should be fully supported by ontologies.

  • Social Id and roles are structural aspects of manager entity, i.e identified by and used through managers’ instances (a).
  • Roles is a symbolic container for multiple (b) functional connectors (c).
  • Terms for actors and roles are deemed synonymous (d)
Connectors: syntactic (a, b), functional (c), semiotic (d)

Interfaces consistency can be checked by comparing agents’ actual language capabilities to actors’ required ones.

Integrity: Structural vs Functional Constraints

Factoring out truth-preserving reasoning is a direct benefit of the distinction between representation and domain specific contents.

With mutability uniformly and unambiguously defined across domains, a distinction can be made between what is known and what is open to scrutiny.

  • The relationships between cars and models cannot be modified (dark blue).
  • The relationships between rentals and cars can be modified (clear blue).


By contrast, the cardinality of occurrences is best defined by domains as it combines functional and structural integrity constraints.

  • Existential integrity: rentals must be uniquely associated to cars and groups; but groups can mix models.
  • Functional integrity: as business may require multiple assignments of actual cars to rental ones, mandatory constraints should not be mixed with exclusivity ones.
  • Inferred connections can be directly specified with the tool.

These object and data properties may have to be refined as to limit the overlapping with OWL 2 native ones.

From Data to Knowledge: Individuals, Categories, Concepts

The benefits of the distinction between representation syntax and domain semantics, as well as its corollary for truth-preserving reasoning, encompass all information systems, and so ensure a sound basis for knowledge management.

But knowledge is dynamic by essence and what is at stake is the processing of raw data into information and knowledge assets:

  • Data is first captured through aspects.
  • Categories are used to process data into information.
  • Concepts serve as bridges to knowledgeable information.

Information models describe what systems are meant to manage in terms of categories, e.g for customers and business processes. Insofar as ontologies are concerned, individuals are logical instances, e.g invoicing insurers or customer with family.


Data is first acquired as hypothetical structures to be mapped to information models, e.g through applying statistical knowledge.

Knowledge is managed through expressions, concepts, and documents. When knowledge is considered, the critical point is to decide what should count as individuals.

Further Reading

External Links