KEOPS Kernel (Protégé/OWL 2)

And yet, most present-day ontologies overlook that distinction, and consequently confuse the nature of objects and phenomenons (concrete or symbolic) with the open-ended range of their representations by human minds.

Related readings

• Ontological Prisms for beginners
• Ontological Prisms & The Geometry of Knowledge
• Enterprise’s New Brains

Preamble

Ontologies & Enterprises

Ontologies are vessels meant to organize knowledge. At enterprise level they can be developed from three sources: conceptual Models, databases schemas, or facts (observations, datasets), and documents.

Ontological prisms are designed to be pragmatic and agnostic. Pragmatic, in order to avoid definitional debates about the nature of ontologies and to focus on how they can be constructed and utilized. Agnostic, in that they support ontologies regardless of representations semantics and lifecycles.

Ontologies & Knowledge

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.

Traditional models can support points 1, 4 and 5, but fall short of points 2 and 3. Ontologies are meant to generalize the representation of and reasoning about any number of realms, actual or virtual. The aim of the kernel is to bring under a common roof the whole of representations pertaining to enterprises governance.

Ontologies & Language

Language has always been the underlying subtext of artificial intelligence (AI), whether it’s for implementation (computer languages), communication (user interfaces), or truthfulness (knowledge representation). The comprehensive surge of generative language models (GenLMs) has created a new and powerful momentum that blends communication and representation. The confusion between language and knowledge is further reinforced by the ubiquity of knowledge graphs, which are viewed indiscriminately as both content and containers. Ontological prisms unfold the two roles of languages, communication and representation, allowing for the mapping of semantic layers with knowledge shapes.

Kernel Organization

Overview

In line with the objectives of ecumenism and parsimony of ontological prisms, the KEOPS kernel relies solely on core OWL features, leaving as much room as possible for users’ customized extensions without the risk of confusing overlaps. Consequently, the overview of the online OWL/Protégé addresses only the relevant features.

Protégé Class Hierarchy

Protégé entries are organized into nodes and edges, which are presented as a hierarchy of classes under the root owl:Thing. The KEOPS kernel introduces two significant distinctions: on one hand, it introduces Aspect to represent edges with properties, making a step towards labeled property graphs; on the other hand, the KEOPS kernel does not assign any particular meaning to the Protégé hierarchy, except for the management of entries, and instead relies on stereotyped connectors, such as ontoRef_.

OWL/Protégé KEOPS Kernel.

Native OWL/Protégé connectors appear as unlabeled. Solid lines represent type hierarchies, while dotted lines indicate instantiation.

Protégé Properties

OWL Classes can be characterized by object, data, and annotation properties.

Object Properties  

Object properties are references that define edges between nodes. The KEOPS kernel introduces a limited number of stereotyped connectors that are free of any domain-specific semantics.  

Data Properties & Datatypes  

Data properties are attributes that characterize the nodes themselves, independent of their edges. Datatypes are built-in data property standards in OWL/Protégé. The KEOPS kernel does not interfere with Protégé data properties and datatypes.

Annotation Properties  

Contrary to object and data properties, which pertain to content, annotation properties relate to their processing. The kernel does not rely on annotation properties.  

Individuals  

The KEOPS kernel uses Protégé individuals as defined but introduces the ‘§’ prefix to their names to compensate for the absence of Protégé colors in the printed book.

Kernel Extensions

Kernel Nodes

The KEOPS kernel categorizes OWL classes into two groups: primary (or standalone) nodes and aspect (or dependent) nodes. Primary nodes are used for OWL classes which can be identified independently as facts, concepts, or categories. The kernel employs different notations for facts (e.g., [Staff]), concepts (e.g., _Person), categories and aspects (e.g., Staff, Person), and individuals (e.g., §Bob). OWL instantiation connectors appear as unlabelled dotted lines.

The kernel aspects are classes whose instances’ identification and semantics are defined through  their association with primary nodes. Aspects are used to represent structured object properties as well as connecting edges.

Kernel Ontological Connectors

The KEOPS kernel introduces three types of ontological connectors and four types of ad hoc connectors.

Ontological connectors distinguish endogenous, exogenous, and instance connectors. The kernel endogenous connectors are set between nodes belonging to the same realm (homogeneous representation semantics), whether at the same level of representation (ontoRel_) or at different levels (ontoSub_ and ontoSup_). Exogenous connectors (ontoRef_) address nodes regardless of realms (heterogeneous representation semantics) and consequently of representation level. 

Ad hoc or non-ontological connectors address individual joints (§Relat_), inferences (logicRel_), semantics (semRel_), and engineering (engiRel_) relations.

Ontological suffixes ‘#’, ‘≈’, and ‘_’ can be added to these connectors to denote intrinsic, functional, or indeterminate characteristics, respectively. Additional suffixes can be used used to indicate mandatory (‘!’), conditional (‘?’), antinomic (‡), and multiple (‘*’) connections.

KEOPS Kernel’s Connectors & suffixes.

For instance, the observed [Dish] type has an intrinsic endogenous relation with a [Recipe] type, a functional reference with a CookingAppliance category, and a multiple endogenous relation with an [Ingredient] type. The [Ingredient] type has two exogenous references, one intrinsic with its homonym category and one mandatory (and thus implicitly functional) to the Allergy category. Moreover, the Ingredient category may have an endogenous relation to the FoodRegulation category, and an exogenous reference or through the _CarbonFootprint concept.

Aspects, Features, Properties

Ontologies are to models what movies are to pictures; they rely on continuous evolution rather than intermittent maintenance. This inherent changeability has direct consequences for features as well as the terms employed, typically properties or attributes. What starts as an observed attribute (e.g., a price) can later evolve into a composite one (e.g., a price with currency), a labeled edge (pointing to market price), a connecting node (linking product, contract, and currency), and finally, a node on its own. 

While models and, to some degree, siloed ontologies require one and only one representation, heterogeneous ontologies must allow for differences between domains and traceable changes over time. With OWL/Protégé, features can be fully documented through data properties, addressing business-specific content as well as integrity constraints. However, in line with its ecumenical ambition and to avoid redundancies or inconsistencies with external developments, the KEOPS kernel makes no direct use of data properties except for tutoring examples. Instead, data properties are represented as elementary aspects prefixed with ‘+’. In the example, a data property +seatedOrder is represented by a mandatory (ontoRel!) order aspect used to distinguish between seated and away orders.

Properties

It must be remembered that aspects in ontological prisms are syntactical constructs that acquire their semantics once attached to nodes, making them semantically neutral. This allows for their uniform application to types (facts), concepts, or categories.

Semantics of Ontological Connectors 

The aim of KEOPS kernel connectors is to ensure the ecumenism of knowledge architectures regardless of domain semantics. The ontoSub_ and ontoSup_connectors are used between nodes set at different levels of homogeneous representation. Their semantics—parthood for facts and concepts, and inheritance for categories—are implicitly defined according to the realm of the targeted nodes. While the kernel does not enforce consistency, it can be directly observed by comparing the formats of source and target names.

The ontoRel_ connectors are used between nodes that are set at the same levels of homogeneous representation. As with hierarchies, their semantics are implicitly determined by the realm of the targeted nodes, and their consistency can be directly verified. In contrast, the ontoRef_ connectors can be used regardless of representation semantics, allowing them to be used between nodes that are set across heterogeneous representations of facts, concepts, or categories. Given their semantic neutrality, they can be used as a default option pending further clarification.

For instance, [ Dish] uses a functional reference to the CookingAppliance category, and an intrinsic relation to [Recipe]. Using connectors set across representation levels is more challenging, as illustrated by those between [Dish] and [Cooked Dish], which combine an intrinsic upward (ontoSup#) connector with an indeterminate downward (ontoSub_) counterpart: from a bottom-up perspective cooked dishes may be viewed as an exclusive subset, while a top-down approach would blur the lines when considering cold dishes or pastry.

Hierarchies semantics

That kind of indeterminacy, which in our example also appears with _CookingFunction and CookingAppliance, is an integral part of heterogeneous ontologies due to their unbounded semantics and inherent changeability. These issues can be overlooked in the synchronic representation of siloed ontologies, but they become critical for the interoperability and diachronic representation of heterogeneous ontologies. They can be managed through kernel-structured connectors (see below).

The §Relat connector pertains to individuals, and since differences in representation semantics are irrelevant for individuals, §Relat connectors can be applied uniformly. For instance, assuming that orders are first written on paper, the ontologist will use the   §Relat to represent the concrete joint between table (e.g., §Table4), waiters (e.g., §Waiter2), dishes (e.g., §Steak T4), and possibly nominal mentions (e.g., ‘Medium rare’).

Individual connectors

This example illustrates a use of the distinction between ontological and individual connectors: at ontological level the relation between seated orders and tables is mandatory but not intrinsic because customers can change tables during meals, but the relation becomes intrinsic when orders are recorded.

Representing Territories

The KEOPS kernel can be further detailed through the ways it supports the proposed playbook, starting with the mapping of territories. It is important to remember that the aim is not to develop reference models but rather to illustrate the benefits of an ecumenical approach to representations.

Symbolic & Physical Environments

Ontological prisms adopt a pragmatic approach grounded in both facts and artifacts, encompassing physical as well as symbolic dimensions.

Datasets & Documents

Along with individuals or typed individuals, facts can be represented as [Document] and [Dataset] introduced as predefined types. Datasets are collections of uniformly structured elements, such as orders or customers, while documents are multimodal collections of variously structured elements that may (e.g., recipes) or may not be already typed. Unstructured data is represented by [DataObject], and packaged data by [DataProduct].

Individuals, Datasets, Documents 

In our example, §Orders:April appears as an instance of the [Orders] dataset, which is a collection of [Order] instances. Likewise, §Recipes:April appears as an instance of a [Recipes] document, which is a collection of poorly structured [Recipe] instances. Datasets and documents can also serve as gateways to categories and concepts, respectively, with the former accessed through taxonomies and the latter through thesauri.

Partitions, Taxonomies, Powertypes

Ontologies begin by making distinctions. Beyond differences in terminology, we can identify three terms: partitions operate first on direct observations and datasets; taxonomies follow, using partitions to build labeled hierarchies; and finally, powertypes translate taxonomies into categories. For instance, “hot” and “cold” dishes may be relevant as a partition but are of little use as a taxonomy. In contrast, partitioning diets into culinary and religious categories could lead to a useful taxonomy, but not necessarily to effective powertypes.

Partitions & Taxonomies

Powertypes are types whose instances represent collections of instances of other types that may or may not qualify as categories on their own, i.e., categories whose instances are meant to be managed as surrogates. This flexibility is especially useful for heterogeneous ontologies, which, in contrast to models, are intended to vary over time and across domains. Due to their semantic neutrality, powertypes can be used interchangeably across ontological realms, ensuring the continuity of representations from flat partitions to hierarchical taxonomies and inheritance hierarchies. This can be particularly useful for connecting artifacts, concepts, and categories.

For instance, a CookingAppliance2 partition can be introduced to target observed cooking appliances and then compared to a CookingFunction2 powertype defined at the category level.

Partitions & Powertypes 

Representation of Variants

Representing variants is at the core of ontologies, especially for heterogeneous ones. While partitions, taxonomies, and powertypes can serve as preliminary steps, they cannot scale with complexity and will eventually need to be translated into structured representations. 

Structured Connectors

The KEOPS kernel resets the semantics of established loop, merge, and split constructs in terms of ontological intrinsic and functional connectors: ontoSub and ontoSup between levels of representation, ontoRel within levels of representation, and ontoRef across realms’ representation semantics. Inbound connectors are those set from parent to structures, while outbound connectors are those from structures to elements.

Inbound connectors

OntoSub inbound connectors are used when parents and elements can be identified uniformly: intrinsic ones (ontoSub#) when elements can be fully identified as such (e.g., seated and away orders); and functional ones (ontoSub≈) when elements cannot be exclusively identified as such (e.g., kitchen and diner staff).

Structures inbound connectors 

OntoRel inbound connectors are used when parents and elements are of different types: intrinsic ones (ontoRel#) are used when identities of parents and elements are intrinsically bound (e.g., Recipe and Dish); functional ones (ontoRel≈) when they are not intrinsically bound (e.g., Party as Person or Organization).

Outbound Connectors

Outbound connectors replicate the nature of their corresponding inbound connectors (ontoSub or ontoRel), but intrinsic or functional qualifications are determined by context. For example, outbound connectors to persons or organizations are functional because identities are not bound. Instances of [Party] are intrinsically connected to instances of agents (ontoRel#), while for agents, the connection is functional (ontoRel≈). 

 These options can be illustrated by three examples: 

Structures

• When the spOr_DishHotCold construct is used by [Recipe] it’s through a functional relation: same realm, different classes.
• When the spXOr-Empl_Temp construct is used by [KitchenStaff] it’s through a functional subsumption: same realm, different levels. 
• When the spXOr-Environment construct is used by [Environment] it’s through an intrinsic subsumption: same realm, different levels, exclusive variant. 

The [KitchenStaff] example illustrates the discretionary nature of representations: the subsumption is represented upward (ontoSup) from an observer perspective (facts), but it could also be represented downward (ontoSub) from a business analyst (concepts) or database manager (categories). Hence the benefits of combining alternative representations, in particular for heterogeneous and/or diachronic knowledge representations.

Combining Structures

Variants can be set across the same targets as illustrated by dishes with an intrinsic spXOr_ for the exclusive partition between cooked and raw dishes, and a functional spOr_ for the non-exclusive partition between hot and cold dishes. The latter could also be used to characterize functional relationships (ontoRel≈) from recipes.

Combining Structures

Alternative representations of variants can be justified by domain specificities and/or by the knowledge life cycles across heterogeneous representation semantics. However, the parthood semantics used for representing facts and concepts cannot be aligned with the inheritance semantics used for representing categories. Leveraging their semantic neutrality, KEOPS kernel constructs can be used to connect variants across heterogeneous representations. For example, starting with [KitchenStaff], one can navigate through category variants related to Employee# and LegalEntity, and further explore concepts while checking the consistency of ontological connectors throughout.

Crossing realms with  structured connectors.

Constraints, Expressions, Rules

Constraints, expressions, and rules can be defined using SKOS (Simple Knowledge Organization System) and SHACL (Shapes Constraint Language) and implemented through interfaces like the Common Logic Interchange Format (CLIF) or plug-in OWL reasoners such as Pellet or KERMIT. While SKOS specifications can be integrated with OWL, the possibilities are limited, and their maintenance can be cumbersome. SHACL serves more as an alternative than as a complement to OWL, and the effectiveness of reasoners primarily depends on the consistency of the constraints and rules, as well as the consistency of tool integration.  To ensure its ecumenism, the primary objective of the KEOPS Kernel is to allow alignment with predicate logic.

Constraints through Connectors

With the KEOPS kernel, constraints can be expressed through ontological connectors, expressions, or both. Connectors allow for a direct representation of constraints in terms of intrinsic (#), mandatory (!), antinomic (‡), and optional (?) connectors. For instance, an antinomic connector (ontoRel‡) can prevent AI agents from holding organizational roles, while a mandatory connector (ontoRel!) can force judgments to be assigned to legal entities. This includes judgment roles and cognitive ability requirements.

Constraints through connectors

Along with connectors, structures can also be used to implement constraints. For instance, in the case of Party, one could use a mandatory connector to LegalEntity or a spXO_ construct pointing to Person and Organization.

Nominal footprints & Semantic Layers

Semantic layers can be defined in relation to the consistency of domain-specific thesauri and/or in terms of the consistency between thesauri and taxonomies. The former approach remains focused on the alignment of domain semantics, while the latter considers the mapping of the respective semantic spaces of thesauri, pertaining to words, and taxonomies, pertaining to things. Such a mapping can take advantage of the distinction between the nominal, formal, empirical, and ontological bases of semantic layers.

For example, consider a business (deontic) rule such as “The head waiter must have excellent English.” This rule could be represented as a nominal footprint combined with a §HumanResources SemanticSpace, where semantic spaces serve as the thesaurus counterpart of business domains. Based on thesauri, §SemRel_ connectors could be used to organize nominal items into semantic graphs, which can then be further associated with relevant entities through ontological connectors.

Nominal footprints & Semantic spaces

Alternatively, constraints and rules can also be represented by formal expressions..

Constraints through Expressions

Expressions, commonly referred to as methods in modeling terminology, are represented as aspects intended to be instantiated through their association with nodes. the KEOPS kernel distinguishes between numerical, logical, and business-specific expressions. Numerical expressions are supposed to be supported by dedicated tools, while logical expressions are intended to align with the Common Logic Interchange Format (CLIF) and predicate logic. Regarding business expressions, the objective is to enable interoperability between ontological prisms and relational databases, with expressions mirroring database schemas.

Complex constraints can thus be represented by combining expressions and ontological connectors. In our example, the rule “Head waiter must have excellent English”, is associated with a formal expression (languageLevel) intended to be aligned with a relational scheme or a Prolog predicate, using a prefix ‘§’ for controlled arguments.  In that example the controlled arguments allow for a joint with the partition of staff according to their language level (LangLevel2).

Constraints through Expressions

The constraint can be verified for the controlled arguments §Staff and §Lang.  

Inference Rules

The KEOPS kernel uses five dummy inference connectors to illustrate dependencies of truth values: antinomy (logic‡), necessity (logicΞ), congruence (logic>=), and divergence (logic>≠). The constraint example above can thus be expressed using the logicΞ connectors between the head waiter position and the English language condition. The inference connectors can also be applied to positive (logic>=) and negative (logic>≠) numerical changes. For instance, dish prices and orders are expected to move in opposite directions, while ice cream orders are expected to follow changes in weather temperature.

Inference connectors

While these are makeshift options intended to be replaced by established reasoners, a more generic approach can rely on the KEOPS kernel’s ontological modalities (see below): deontic (∆Permissible, ∆Impermissible, ∆Obligatory, ∆Optional) or empirical (∆Possible, ∆Impossible, ∆Necessary, ∆Contingent).

10.3 Representing Intents

This segment is focused on the representation of agents, goals and projects. Variants are detailed separately at the end of the segment. 

Agents & Goals

The development of agentic AI architectures and the role of ontologies supporting  them put the light on the representation of actors, goals, plans, and decision-making. 

Agents, Actors, Roles

The representation of agents should address embodiments, abilities, and entitlements.  As already mentioned, agents can be embodied as mechanical, digital, biological, or collective entities. Regarding entitlements the representation should distinguish between legal and digital entities.

Agents: Embodiments, Entitlements, Capabilities.

Taking Agentic AI in consideration, agents’ cognitive and communication capabilities should also be addressed, the former for observation, reasoning, judgment, and problem-solving; the latter  for natural, symbolic, digital, and physical communication.  Agents could also be characterized by their environment agency (symbolic or physical), and entitlements.

Agents represent active individuals, actors are agents in bounded contexts, roles describe what actors can do in organizational contexts, and actors describe how they do that in actual environments.

Goals

Goals can be defined by environments, parties involved, and outcomes. The representation below illustrates three different ways to use structures.

• [Outcome] is characterized by a functional non exclusive partition (spOr_) targeting tangible and intangible subtypes (ontoSub≈). 
• [Environment] is defined by intrinsic (ontoSub#) exclusive subtypes (spXOr_) targeting tangible and intangible subtypes (ontoSub#).
• [Horizon] directly combines non-exclusive functional operational, tactical, and strategic subtypes (ontoSub≈) referencing data, information, and knowledge, respectively.

Goals

Projects

Projects

Projects are, by definition, set across facts (current situation), categories (realization), and concepts (intents). These perspectives can be explicitly represented using the KEOPS kernel.

Projects

Process & Work Units

Taking the OODA (Observation, Orientation, Decision, Action) loop as reference for decision-making process, a project would iterate through four kinds of workunits (OODA_Step), with advances monitored in terms of state of processes, environment, outcome, and resources.

Process

A Sample of Variants

So far, the representation of variants and levels of abstraction has been based on an ontological extension of established constructs for composition, alternatives, and subtypes. Before presenting how abstraction levels can be represented with the KEOPS kernel, we will briefly revisit some of the examples mentioned above.

Agents are first characterized by the nature of their instantiation and the scope of their agency. The former is exclusive, the option for the latter is discretionary.

Agents & Agency

Agentic AI concerns are intended to be addressed through cognitive abilities and entitlements. Cognitive abilities distinguish between observation, reasoning, problem-solving, and judgement. Entitlements are defined by the nature of agents and their roles.

Agent Abilities

Primary variants for roles pertain to the respective entitlements of digital agents and legal entities, individuals or organizations. Conversely, roles can also be characterized by their scope: organizational, functional, or operational. The former is exclusive, the latter is not.

Finally, roles and agency must be congruent with processes’ environments.

Agency, Process, Environment

Time is addressed through events.

As illustrated by this sample, an open-ended range of objects and phenomena are bound to be characterized by a limited number of intrinsic variants, making the case for principled abstraction levels.

10.4 Representing Abstractions

Representing abstractions is arguably the defining dilemma of modeling, especially when addressing heterogeneous ontologies. As explained in our book, the core of the matter is akin to a sleight of hand: one hand is meant to separate domain-specific concerns from ecumenical constructs, while the other hand tries to ensure their seamless integration. Customary solutions such as metamodels and upper ontologies fall short of establishing reliable and effective mappings. The former struggles due to the overlaps between syntax and semantics, while the latter is hindered by the cumbersome conceptual twists required to align upper and lower ontologies. Ontological modalities borrow from both approaches: stereotypes and patterns from the former, and intrinsic and functional qualities from the latter.

Modalities

Modalities can be viewed as ontological stereotypes that provide a declarative alternative to imperative meta-models. The kernel includes KEOPS’ seven modalities for temporality, instantiation, identification, agency, communication, structure, and veracity. It must be noted that the list can be extended and the options modified provided they do not overlap.

Ontological Modalities

Ontological modalities address intrinsic and functional qualities regardless of realms. As such they ensure the consistency of abstraction levels without forcing discretionary and unwieldy options. In our example, a _LegalEntity has an elementary structure modality while Organization has a collective structure one, with an intrinsic lineage between  them. Regardless of business-related explanations of the discrepancy, it can be explained by the different abstraction semantics applied to concepts and categories which is materialized by the use of an ontoRef# connector.

Ontological Modalities

Grammatical Modalities

Modalities can also be applied to the parsing of texts.

Grammatical Modalities

Representation Modalities

Finally, modalities can be used to ensure the interoperability of representations between ontologies and tools such as relational databases or UML models.

Representation Modalities

Patterns

Patterns (prefix ∆2) are shared representations designed for reuse across different domains and realms. They are built on modalities, allowing for a shortcut free of the semantic discrepancies between representation levels. Patterns are rooted in realms and intended to be applied across realms; they can be defined directly from well-proven entities and modalities or by specializations of existing patterns. Additionally, they can combine different patterns.

Blueprints (concepts)

Blueprints are conceptual patterns. In our example, a ∆2PhysRole blueprint can be introduced as a specialization of ∆2Role because the instantiation modality of the latter is defined as functional and can thus be reset to intrinsic. The reverse would not be allowed.

Blueprint 

Blueprints can be composite or be mapped to profiles. 

Profiles (domains)

Profiles are domain patterns; they can be defined directly or based on blueprints, for instance a ∆2CookingControl profile may reuse ∆2PhysRole and D2Equipmet blueprints.

Templates (models)

Templates are realization patterns. As such they are best defined in relation with representation modalities.