A Semantic Layer is the framework for connecting data from multiple sources and formats in both a human- and machine-readable way that enables organizations to understand the meaning of their data, extract contextualized information, and discover new insights. A key part of a mature Semantic Layer is an ontology, which is a formal representation of the logic implicit in different knowledge assets. The ontology captures the entities and relationships that are important for understanding and utilizing relevant information. Maturing a semantic layer almost always requires multiple ontologies to connect data across an organization. One of the best ways to consistently scale multiple models is to utilize an ontology hierarchy.
A semantic layer should be able to accommodate new use cases and integrate data from additional groups within an organization. Well-crafted ontologies are designed to be reusable, scalable, and interoperable with each other to respond to evolving business needs. Growing in semantic maturity as an organization requires leveraging ontologies that represent different domains and bring data about different topics together in the same place. Multiple ontologies will almost always be adopted for the information from individual data sources to be contextualized and understood.
This seems like a daunting task for the many different domains that are relevant for an enterprise semantic layer. For example, one client in the vehicle manufacturing space required a semantic layer that represented knowledge from a variety of disparate domains, such as organizational structure, design and production processes, vehicle parts, supply chain, safety regulations, and more so that they could meaningfully exchange and query data from different sources.
Not only did this necessitate the use of multiple ontologies, these models also had to be interoperable and consistent with each other for successful implementation and scalability. If ontologies are developed independently without a shared structure, they quickly become isolated assets — useful within a single domain or use case, but unable to support enterprise-wide data exchange. Over time, this leads to brittle models with a short lifespan, requiring significant effort to reconcile through mappings or redesign. While ontologies are there to help organizations overcome information silos, models that are not interoperable risk replicating these silos, preventing organizations like the vehicle manufacturer from accessing the full semantic context that is a representation of their business and how they operate.
The key to avoiding this outcome lies in designing ontologies with a top-down strategy for interoperability. In the case of the vehicle manufacturer, ontologies were designed within a hub-and-spoke architecture by extending from upper level standards like the Basic Formal Ontology and Common Core Ontologies. When interoperability is built in from the beginning, the outcome is a unified semantic model of the business: data becomes exchangeable across the organization, AI systems can leverage consistent, machine-readable knowledge, and users can query across business domains with the full context needed to make informed decisions.
A Mature Ontology Hierarchy
Ontologies come in many shapes and sizes, but highly mature ontologies have a hierarchical structure consisting of multiple layers along a spectrum of conceptual specificity / generality. When sharing the same hierarchy, standards, and design principles, different ontologies operate on a common foundation that prevents silos and enables interoperability across different domains and applications.
The top layers consist of a top-level ontology (sometimes called a foundational or upper level ontology), which contains highly general entities and concepts relevant to many domains. True top-level ontologies contain the most generic terms relevant to any domain, while other upper level ontologies may also include domain specific content. The terms in this layer are domain neutral and will have relevance to modeling across virtually all domains. These ontologies contain concepts like “process,” “material entity,” or “quality.” Extending from the top-level is a mid-level ontology, which connects the top-level to different domain ontologies. The mid-level contains more specific entities like “person,” “organization,” or “act.” Beneath the mid-level ontology are domain ontologies dedicated to specific knowledge about a particular domain or field, such as chemistry, automotive engineering, or finance. Underneath the domain ontology layer is the application ontology, which is dedicated to modeling for specific use cases. These models represent the logic of particular data sources for an organization’s business needs.
When building an application ontology, a certain amount of domain ontology will almost always have to be constructed or adopted for the information in the individual data sources to be properly contextualized and understood. For example, a biomedical application ontology may need to incorporate information from other domains, like chemistry, research investigations, or technical equipment. Mature ontologies are structured to accommodate new domains for additional use cases by committing to foundational structures and principles that are reusable, scalable, and interoperable between multiple ontologies. As application ontologies expand, they mirror the same hierarchical pattern of core models that lower level extensions can plug into.
Ontology Interoperability Strategy
One of the most effective approaches to ensuring interoperability between multiple ontology modules within a semantic layer is to adopt shared top and mid-level ontologies. This strategy uses the top-level and core ontology hierarchies as a hub that connects all the models extending from it. Ontologists plug new models into this existing framework to expand the semantic layer domain coverage.
The difference between ontology efforts that scale and ones that stall often comes down to how foundational concepts are handled. Ontologies without a top-level hierarchy still make implicit assertions about one in their definitions and rules by referring to fundamental categories like processes, objects, or attributes. When application and domain ontologies are developed in silos, without the guardrails of a shared semantic framework, they run into inconsistencies and contradictions between differing, ambiguous assumptions in their models, making it harder to integrate new data, extend to new use cases, or trust the results of cross-domain analysis. However, the organizations that get this right unlock a fundamentally different relationship with their data. A coherent, enterprise-wide semantic architecture, where domain ontologies share a common foundational framework, transforms data from a collection of isolated records into a connected, queryable representation of organizational knowledge.
Top and mid-level ontologies improve the reasoning capabilities of application ontologies by providing high level distinctions and rules that apply at the lower levels. A semantic layer does not always use the full potential of ontologies to infer new information about the data, but by adopting this consistent, hierarchical approach, stakeholders can more efficiently deploy reasoning over their ontology models.
Although working with a top-level ontology requires time and expertise, leveraging established models like the Basic Formal Ontology saves ontologists from defining fundamental terms from scratch. Rather than duplicating effort for every new data requirement, subsequent ontologies and expansions simply build upon these higher-level structures, eliminating redundancy by reusing existing entities and relationships.
Conclusion
Consistently scaling a semantic layer is difficult, but using a hierarchy of established ontologies improves the quality of your models, allows you to expand faster while mitigating risks, and realizes the full potential of ontology to reason and acquire new insights about your data. If you have questions or would like to learn more about interoperability between ontologies in a semantic layer, reach out to EK and we will be happy to provide additional guidance.