Foundational Design Principles

There is significant ambiguity surrounding the definitions of “ontologies” and “semantic layers.” As traditional database schemas and graph structures are increasingly relabeled as ontologies for AI marketing purposes, the industry risks losing its shared technical definitions. Without a rigorous, agreed-upon semantic foundation, it is impossible to build agentic systems capable of true interoperability and autonomous reasoning.

An ontology is not merely an extended data schema; it is a formal contract of meaning designed explicitly for machine reasoning (Guarino, 1998). The following sections provide context for understanding ontological engineering, followed by nine foundational principles that establish the baseline prerequisites for engineering production-grade knowledge layers.

A Short History

Ontology engineering emerged from 1990s expert-systems and knowledge-representation research, where AI groups repeatedly relearned the same lesson: hand-built knowledge bases that weren’t grounded in an explicit conceptual model became unmaintainable within a few years. This produced the first formal methodologies (Uschold & King’s skeletal method, Grüninger & Fox’s competency-question approach) around 1995, aimed at making ontology construction as disciplined as software requirements engineering.

The Semantic Web effort (early-to-mid 2000s) standardized the representation layer — RDF, RDFS, OWL — and produced the next generation of methodologies (METHONTOLOGY, On-To-Knowledge, later NeOn) built around those standards. Through the 2010s, the field’s center of gravity shifted toward large, collaboratively maintained ontologies (Wikidata, Schema.org, biomedical ontologies like SNOMED CT and the OBO Foundry) and toward ontology matching/alignment as federation across independently built ontologies became the harder problem than construction itself.

The current phase, roughly 2023 onward, is LLM-augmented ontology engineering: using language models to accelerate the labor-intensive parts of the lifecycle (term extraction, competency-question drafting, candidate axiom generation) while keeping formal verification and human validation as non-negotiable gates.

The Ontology Engineering Lifecycle

Every established methodology, regardless of its specific name, decomposes into some version of the same six phases:

Specification → Conceptualization → Formalization → Implementation → Evaluation → Maintenance
      ↑                                                                                │
      └────────────────────────── feedback / re-scoping ─────────────────────────────┘

Specification. Define the ontology’s purpose, scope, and intended users before modeling anything. The output of this phase is a set of competency questions — concrete questions the ontology must be able to answer — not a list of concepts. Skipping this step is the single most common cause of ontologies that are technically well-formed but useless in practice.

Conceptualization. Organize domain knowledge into an informal conceptual model: candidate concepts, their attributes, relationships, and constraints, typically expressed in a glossary or mind-map before any formal language is chosen. This phase deliberately stays representation-agnostic so domain experts can validate it without needing to read OWL.

Formalization. Convert the conceptual model into a formal representation — RDF/RDFS/OWL, SHACL shapes, or a property-graph schema. This is where design decisions about expressivity get made.

Implementation. Encode the formal model in an actual tool (Protégé, TopBraid, or a graph database’s schema layer) and populate it, at least partially, with real instance data to stress-test the model against reality rather than leaving it abstract.

Evaluation. Verify the ontology is logically consistent (a job for an automated reasoner) and validate that it actually answers its competency questions and matches domain-expert judgment (a job that cannot be automated away).

Maintenance. Ontologies drift the same way schemas drift, except more subtly, because a stale concept definition doesn’t throw an error — it just quietly reasons incorrectly. Versioning, deprecation policies, and change-impact analysis belong here, not as an afterthought.

The loop back to Specification is deliberate: nearly every serious methodology (NeOn especially) treats ontology engineering as iterative, not waterfall — new competency questions surface once real users and real data hit the model.

Established Methodologies

For an enterprise team building from scratch on top of existing clinical or financial standards rather than starting from nothing, NeOn is usually the right conceptual starting point precisely because it assumes reuse and alignment as first-class activities rather than treating them as an afterthought.

The Semantic Prerequisites

Principle 1: Formal Conceptualization

An ontology is a formal, explicit specification of a shared conceptualization of a real-world domain (Guarino, 1998). It provides an unambiguous vocabulary and a structural framework that can be processed consistently by both software agents and humans.

Principle 2: Abstraction and Modularity

While the granularity of an ontology is guided by its initial implementation use case, its underlying semantic architecture must be decoupled, modular, and designed for broad reuse and extensibility across different domains.

Principle 3: Foundational Alignment and Real-World Fidelity

To ensure universal interoperability, domain-specific ontologies must align explicitly with a realist, domain-neutral Upper Ontology—such as Basic Formal Ontology (BFO) or DOLCE (Arp et al., 2015). The model must reflect reality as described by science and domain expertise, rather than arbitrary or temporary application views (Smith, 2012).

Principle 4: Semantic Consistency

The concepts, axioms, and relationships defined within the ontology must strictly adhere to, and never contradict, verified domain knowledge of the real world (Smith, 2012). Logical coherence across the knowledge layer is non-negotiable.

Principle 5: Multi-Level Stratification

The ontology must explicitly segregate real-world physical instances, their immediate categories (Types), and higher-level meta-categories (Types of Types). Properties, constraints, and logical rules specific to one abstraction layer must never be conflated or mixed with another.

Principle 6: Determinism of Invariant Laws

The invariant laws governing reality—whether physical laws or strict, immutable business and compliance policies—act as absolute validity constraints on the properties and instances within the ontology.

Principle 7: Formalization and Computability

The ontology must be expressed in a formal logic language with computational semantics, such as the Web Ontology Language (OWL) derived from Description Logics (Arp et al., 2015). This mathematical rigor enables autonomous software agents and reasoners to execute automated consistency checks, infer new knowledge, and validate data integrity.

Principle 8: Separation of Concerns

The physical data model and the semantic ontology must remain entirely decoupled. The data model addresses technical constraints related strictly to data structuring, performance, storage, and computing efficiency. These operational mechanics exist independently of the ontology’s pure semantic logic.

Principle 9: Operational Embodiment

The runtime data model functions as a technical translation and instantiation of the ontology. It allows the computer system to process, query, and store data at scale without altering, eroding, or losing the original semantic meaning defined by the ontology framework.

References

Arp, R., Smith, B., & Spear, A. D. (2015). Building Ontologies with Basic Formal Ontology. The MIT Press. https://doi.org/10.7551/mitpress/9780262527811.001.0001 Cited by: 1798

Guarino, N. (1998). Formal ontology and information systems. Formal Ontology in Information Systems, 3–15. Cited by: 7292

Smith, B. (2012). Classifying processes: An essay in applied ontology. Ratio, 25(4), 463–488. https://doi.org/10.1111/j.1467-9329.2012.00557.x Cited by: 92