A Lesson in Contextual Ontology for Systems and Software Developers

Information Science | May 5, 2023




Header Photo by Venkat Ragavan

When we think about how to conceptualize a system, there is a lot of tacit knowledge that needs to be captured and codified. This codified tacit knowledge of various domain experts can take various forms, usually relates to concepts, real-world objects, and processes. This requires one to find ways to represent those objects, concepts, and processes linguistically or otherwise. But this representation should occur in a way that is useful within and tied to said domain context.

This brings us to Ontology: the ways in which we represent concepts, categories, objects, and the relationships between them. Ontology is of upmost importance to systems developers, as it allows us to consider how we may define conceptual systems and structures in an abstract manner without realizing their existence in the real world.

How do we step into ontology?

Let’s consider one of the more challenging aspects of creating an ontology. Let’s consider, for example, an elephant. Most folks instantly have the iconic animal pop into your head. Now, think of several attributes that describe an elephant (as one may exist generally, not any one in particular.)

You probably came up with several visual attributes of the elephant, and there are additional attributes we could capture, as well. Maybe an attribute used to represent the elephant could be what it eats, or its temperament. Ultimately, it is challenging to represent real-world instances of concepts without context. When we add context, we can more easily and creatively focus on what attributes may be the most useful, especially when we’re familiar with the fundamental concepts and language tied to that context. Let’s consider an elephant from various contexts.

In the context of a zoo, let’s again think of attributes to describe an elephant. The attributes will likely be related to constraints for enclosures and animal husbandry. Maybe the elephant also has a name. Some attributes may include how much food the elephant needs to consume per day, its weight, or the kinds of medicine it needs to take. This information ultimately is useful in the context of the zoo because it can inform us on how to take care of the animal, which is a primary concern and objective of the zoo’s operations.

In the context of a Wildlife conservation organization, we may track separate attributes about elephants. Examples might include how many attempts may have been made to poach an elephant, its geographic location, or protections put in place for that animal. This information is useful, as it relates to the primary concern of a wildlife conservation organization.

To create useful ontologies with representations of knowledge which describe existence in the context of some engineered system, we also need to consider how those represented entities relate to one another. Terms that describe relationships between various concepts, objects, and other entities are often referred to as “associations”. Associations are generally used to help denote structural relationships between various entities. Various types of associations are usually defined which describe how tightly associated various entities are related to one another.

The most common types of association are “composition” and “aggregation”. Composition refers to a relationship between one and several other entities where one entity is essentially an abstraction or concept that refers to an entity that is itself composed by the grouping of all the other entities (it is itself equal to the grouping of said entities, i.e. a composite of them.) Aggregation refers to a relationship between one and several entities where one entity is essentially an abstraction or concept that refers to an entity which contains or groups other entities but isn’t itself a grouping of entities.

Associations themselves also have attributes which are useful in determining structural relationships. The most common and useful apparent in various conceptual models are “multiplicity” and “optionality”. Multiplicity refers to how many entities participate in a relationship. Multiplicities are often presented as a range of integer values, where the upper and lower limits are referred to as the “cardinality”. Optionality refers to whether it’s logically necessary for an entity to participate in an association. Optionality may be logically implied when a multiplicity’s lower cardinality is zero.

When an association itself has attributes that are useful within some context beyond multiplicity and optionality (usually when multiplicity indicates several of both entities in the relationship may participate), the association itself is often treated as its own entity (an associative entity) which works like a gerund (a noun that describes a verb). Classic examples show attributes that relate to a many-to-many cardinality in an association – e.g. in an association between an invoice and products, the association could be considered a detail of which products appear on an invoice – an attribute that would describe this “product detail” gerund might be the quantity of each participating product on the relevant invoice.

Three different types of common conceptual schematic models are presented below, including associations with denoted multiplicity and optionality, to demonstrate how conceptual entities and their associations are represented. These conceptual models are some of the main tools used to detail ontologies.

Entity Relationship Diagram (Often used by database administrators, data modelers, data analysts, and data engineers to describe relationships in structured data):



Block Definition Diagram (A SysML diagram often used by system engineers to visualize the structure of a system of interest):



Class Association Diagram (A UML diagram often used by software developers to detail various complex types and their associations):



As systems developers and engineers who are primarily concerned about the usefulness of engineered systems, creating ontologies that are contextualized by the needs, objectives and goals of the users and stakeholders of the system allows us to begin to create conceptual representations of some proposed system that are meaningful. These are referred to as “contextual ontologies”.

Contextual ontologies are the basis for most if not all object-oriented software development – classes, class associations, and class diagrams are essentially software-specific linguistic terms for schematic models containing representations and relationships for domain-specific, contextual ontologies.

© Hillier Engineering | 2024