Semantic and Context Layers via Open Standards

Mike's Notes

This is part of a series of thoughtful opinions about using Ontology in software information systems.

Pipi has an existing BORO Engine (bor) (inspired by Chris Partridge's book "Business Objects: Re-engineering for Re-use"), but it runs in reverse: it imports triples to extract entities and relationships, then uses them to build reference relational databases for back-end industry workspaces.

Part eight: A post by Kingsley Uyi Idehen on LinkedIn.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

28/09/2026

Semantic and Context Layers via Open Standards

By: Kingsley Uyi Idehen
LinkedIn: 20/09/2026

Kingsley Uyi Idehen: Founder & CEO at OpenLink Software | Driving GenAI-Based AI Agents | Harmonizing Disparate Data Spaces (Databases, Knowledge Bases/Graphs, and File System Documents)

Architecture for interoperable systems

Most data systems can tell you what a value is. Far fewer can tell you what it means within a shared universe of discourse. An ontology supplies that contextual frame: the concepts, relationships, constraints, and identity anchors through which a semantic layer becomes interpretable

Architecture at a glance

Figure: ontology as the context layer enclosing the semantic layer (TBox / RBox / ABox), grounded in RDF and expressed through open notations.

The architecture is compact but consequential. At the top sits a semantic layer: a TBox that defines the vocabulary with [RDF Schema (RDFS)](https://www.w3.org/TR/rdf-schema/), an RBox that defines relationship behavior with [OWL 2](https://www.w3.org/TR/owl2-overview/), and an ABox that supplies assertions about actual things. Around it sits the context layer—basically, the ontology that establishes the formal frame in which those terms, relationships, and assertions are understood. Beneath this ontology-enclosed semantic model is [RDF](https://www.w3.org/TR/rdf12-concepts/)—not a file format, but an abstract graph model that can be expressed through multiple concrete notations and serialization formats, including [Turtle](https://www.w3.org/TR/turtle/) and [JSON-LD](https://www.w3.org/TR/json-ld11/).

This separation matters because syntax alone does not produce interoperability. Two systems can exchange perfectly valid JSON and still disagree about the identity of the things being described, the meaning of their properties, or the conditions under which a statement should be applied. Open standards give us a way to make those assumptions explicit.

The ontology is the context: it establishes the shared frame in which terms, entities, relationships, and assertions acquire usable meaning.

RDF Schema - https://www.w3.org/TR/rdf-schema/ provides the TBox vocabulary for declaring classes, properties, domains, ranges, and class and property hierarchies through rdfs:subClassOf and rdfs:subPropertyOf.

The RBox—the role or relationship component—uses [OWL property axioms](https://www.w3.org/TR/owl2-syntax/#Object_Property_Axioms) to define how relationships behave. It captures characteristics such as transitivity and symmetry, inverse relationships, functionality, property chains, and related constraints.

The ABox—the assertional component—contains claims about particular entities: this organization issued this invoice; this product has this offer; this document was generated by this activity. It can also contain an explicit [*owl:sameAs*](https://www.w3.org/TR/owl2-syntax/#Same_Individual) assertion that two identifiers denote the same individual; the same equivalence can be inferred implicitly through OWL reasoning. The TBox supplies the shared classes and vocabulary, while the RBox supplies the semantics of the relationships. The ABox uses both to describe the world.

Keeping the three conceptually distinct produces leverage. Vocabulary and relationship semantics can evolve without being buried inside application code, and instance data can be interpreted by software that was not present when the data was created. A row in one database, an object in an API response, and a statement in a document can all refer to the same identified entity and use the same published predicate.

The context layer: ontology as the frame

A semantic statement rarely stands alone. “Alice approved the payment” is useful, but an operational system will immediately ask: Which Alice? What is an approval? Acting in what role? On behalf of whom? At what time? Against which policy? Using which source record? Is the assertion current, superseded, inferred, or disputed?

The ontology provides this context layer. It defines the domain’s universe of discourse and supplies the classes, relationships, rules, and reusable vocabularies needed to interpret the semantic layer. In practical systems, that ontological frame commonly covers:

  • Identity and authority: the agent responsible for an assertion and any delegation under which it acted.
  • Provenance: the source entities, activities, and transformations that produced the assertion.
  • Time and scope: when a statement was generated, when it applies, and the graph or dataset in which it is asserted.
  • Policy and purpose: the rules governing access, use, validation, or disclosure.
  • Quality and confidence: whether the data conforms to an expected shape and what evidence supports it.

The open-standards ecosystem already provides useful ontological building blocks. [PROV-O](https://www.w3.org/TR/prov-o/) defines an RDF vocabulary for entities, activities, agents, derivation, attribution, and delegation. RDF Schema and OWL define domain vocabularies and axioms. RDF datasets provide a default graph plus named graphs, giving applications a standard structural basis for organizing distinct assertion sets. [SHACL](https://www.w3.org/TR/shacl/) describes constraints over RDF graphs, allowing a system to state and test what acceptable contextualized data should look like.

The semantic layer: shared meaning before shared data

The semantic layer begins with distinctions borrowed from knowledge representation. The TBox—the terminological component—defines the kinds of things a domain recognizes. Classes such as Person, Organization, Product, or Invoice live here, together with the vocabulary used to describe them.

The key architectural choice is to make the ontology explicit rather than hide its assumptions in code, prompts, middleware, or undocumented conventions. Once the contextual frame is represented with identifiers and shared vocabularies, it can be queried, validated, exchanged, and audited using the same graph machinery as the domain data it governs.

RDF is the model—not the notation or serialization format

The lower half of the visual makes a distinction that is often missed. RDF is an abstract data model. The [RDF 1.2 Concepts](https://www.w3.org/TR/rdf12-concepts/) specification describes RDF graphs as sets of subject–predicate–object triples and RDF datasets as a default graph plus zero or more named graphs. An RDF document represents that graph or dataset using a concrete notation that also serves as a serialization format.

Turtle and JSON-LD are two such RDF notations and serialization formats. Turtle is compact and well suited to human authoring and inspection. [JSON-LD 1.1](https://www.w3.org/TR/json-ld11/) carries Linked Data through familiar JSON structures and integrates naturally with Web applications. They may look very different, yet both can represent the same underlying graph.

This gives architecture an escape hatch from format lock-in. One team can work in JSON-LD, another in Turtle, and a third through a SPARQL endpoint. As long as their documents map to the same identifiers and graph statements, the meaning survives the change in notation or serialization format.

An open standards stack

The diagram becomes more useful when read as a small stack of separable responsibilities:

Responsibility Open-standards role
Identity IRIs give entities, properties, graphs, agents, and policies globally referenceable names.
Semantic layer The TBox, RBox, and ABox work together to provide shared terminology, relationship semantics, and instance assertions.
Terminology RDF Schema publishes the class and property vocabulary and the *subClassOf* and *subPropertyOf* hierarchies that form the TBox.
Relations OWL supplies the RBox axioms that characterize relationships—for example, transitivity, symmetry, inversion, functionality, and property chains.
Assertions RDF graphs express ABox facts—including *owl:sameAs* equivalence asserted explicitly or inferred implicitly—while remaining independent of storage layout.
Context The enclosing ontology supplies the shared contextual frame, reusing vocabularies such as PROV-O for source, agent, activity, time, and scope.
Validation SHACL states machine-readable expectations for nodes, properties, cardinalities, datatypes, and relationships.
Access SPARQL](https://www.w3.org/TR/sparql11-query/) queries the graph by meaning and relationship rather than by one application’s table or object layout.
Exchange Turtle, JSON-LD, and other RDF notation–serialization format combinations carry the same abstract model across tools and organizational boundaries.

Why this matters now

The context problem becomes acute when software agents participate in workflows. A model can generate a plausible answer from text, but an accountable agent needs more: stable identifiers, source lineage, authorization boundaries, validation rules, and evidence that another system can inspect independently.

A semantic layer helps the agent understand that two differently shaped records refer to the same kind of entity—or the same entity. An ontology supplies the broader context needed to determine whether a statement is applicable and trustworthy for the task at hand. Open standards keep both layers from becoming proprietary memory trapped inside one model, vendor, vector index, or application.

This is also why a knowledge graph should not be reduced to “a database with edges.” The durable value lies in the contract around the edges: globally referenceable identities, published semantics, explicit provenance, reusable constraints, and a standard query model. The graph becomes a medium through which independent systems can exchange not just values, but interpretable claims.

A practical implementation pattern

  1. Start with identifiers. Mint or reuse stable IRIs for the entities, concepts, agents, and policies that must survive outside one application.
  2. Find, reuse, and cross-reference shared vocabularies. Create your own only as a last resort. That said, you can begin with your own vocabulary and progressively cross-reference it with shared ontologies as you—or, increasingly, your agents—discover them. **Construct** only the smallest useful set of TBox and RBox terms and axioms.
  3. Represent assertions separately. Keep domain facts in ABox graphs and preserve their source boundaries rather than flattening everything into an anonymous pool.
  4. Attach additional context progressively. Record provenance, time, delegation, validation state, and applicable policy using named resources and reusable vocabularies.
  5. Validate and expose. Use SHACL to validate graph-shape conformance, SPARQL for inquiry, and content negotiation or APIs to deliver the graph in the notation and serialization format each consumer can use.

The point is not to deploy every standard at once. It is to keep the architecture open at each boundary. Begin with the identifiers and semantics that remove the most ambiguity. Add context where decisions require evidence. Add validation where downstream systems need guarantees. Preserve the abstract graph so that serialization and storage remain implementation choices rather than permanent constraints.

The durable architecture

The sketch’s lasting insight is the separation of concerns through containment. The semantic layer expresses RDF Schema vocabulary in the TBox, OWL relationship axioms in the RBox, and instance assertions in the ABox. The enclosing context ontology establishes the shared interpretive frame—including identity, provenance, time, policy, and purpose. RDF supplies a common abstract model. Open notations and query standards make the result portable.

When these pieces are collapsed, meaning leaks into code and context disappears into operational exhaust. When they are separated but connected through open standards, data becomes easier to integrate, agents become easier to govern, and decisions become easier to explain.

That is the real promise of semantic and context layers: not another abstraction for its own sake, but a Web-native foundation for exchanging claims whose meaning and conditions of use can travel together.

Standards referenced

Related

1. LLMs Obsolete the GUI Moat. They Don’t Obsolete Loosely Coupled Architecture Built on Open Standards

2. Ontology by Another Name: Why BI "Semantic Layers" Are Just Narrow TBoxes — and R2RML Is the Open Path Out

3. The Agent Engineering Stack Nobody Shows You

#CDO #CDIO #CAIO #CIO #CTO #CMO #CxO #AI #Agentic #AgenticWeb #SemanticWeb #LinkedData #KnowledgeGraph #DataSpaces #RDF #Ontology #SPARQL #OWL #RDFS #SHACL

Posted on my behalf by Phenny

By ,
Tags , , ,

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)