Practical Advice for Ontology Engineering on RDF & Property Graphs

Ontology modelling is often regarded as a debate about standards and graph formats. In practice, it is both a conceptual and an engineering discipline. It requires careful decisions about the meaning of entities, relationships, identity, and constraints, ensuring that a graph continues to represent the intended semantics as data, systems, and requirements evolve. This challenge emerges sooner than many organisations expect, and it is equally relevant to RDF and property graph systems.

When the SHACL schema of the Film Club Knowledge Graph was first loaded into gdotv, the resulting data model revealed a structural issue that was not detected by existing SHACL validators. Although Actor and Director were correctly defined as subclasses of Person, as intended by the schema, they remained structurally disconnected from the rest of the model. Specifically, no paths linked these classes to the films in which actors performed or directors directed, and no relationship associated an Award with the corresponding Person recipient. These missing connections originated from the schema design rather than from any deficiencies in the instance data.

The gap between data that is structurally valid and a model that carries its intended meaning is precisely what ontology engineering is concerned with closing. This gap arises regardless of whether a graph is stored as RDF triples or as a labeled property graph.

The Film Club Knowledge Graph’s SHACL schema, visualised as a data model in gdotv: Actor and Director are defined but structurally disconnected from Film.

Why Graph Projects Need More Than a Schema

Graph-based applications rarely originate from semantic modeling; instead, they are typically driven by data ingestion requirements. Development commonly begins with a collection of relational tables, JSON documents, or other heterogeneous data sources, together with a set of query patterns that must be supported. The implementation process then focuses on constructing data loaders, assigning node labels that correspond to source attributes or table names, and populating the graph accordingly. For applications developed by a single team to satisfy a well-defined set of functional requirements, such an approach is often sufficient.

These challenges typically emerge only at later stages of development, and they are rarely attributable to performance limitations. Instead, they arise from inconsistencies in semantic representation. Different teams may model the same underlying concept using different abstractions: one may define the central entity as Customer, another as Party, while a third decomposes it into Account and Contact. Although each representation may be appropriate within its own application context, the absence of a shared conceptual model hinders interoperability. Similarly, relationships often accumulate generic names such as HAS or RELATED_TO, whose semantics depend entirely on the types of the connected entities. As a consequence, it becomes difficult to determine whether two nodes that appear to represent the same real-world entity are in fact equivalent. The same concept may therefore be represented in multiple incompatible forms, ownership and semantics become ambiguous, and meaningful reuse across teams is significantly constrained.

These issues are characteristic manifestations of model drift and can be traced to a common underlying cause: the semantics of the graph were never made explicit or governed consistently. Instead, the intended meaning of the data remained implicit in the assumptions of the individuals responsible for designing and implementing individual ingestion pipelines. As additional teams contributed to the platform, these assumptions diverged, leading to increasingly inconsistent conceptualizations. A schema developed for a particular system constrains the structural form that data must satisfy within that system. However, it does not establish a shared semantic interpretation that is valid across the broader platform or among the multiple teams that depend upon it. Consequently, while structural consistency may be enforced locally, semantic consistency remains undefined.

This represents the more persistent and consequential challenge, as its effects accumulate over time. Performance deficiencies, such as an inefficient query, can often be identified and resolved within a relatively short period. By contrast, a platform in which multiple teams maintain conflicting interpretations of a concept such as Customer requires substantial effort to achieve semantic alignment. Moreover, this effort is not a one-time activity; unless the underlying causes of model drift are addressed through explicit semantic governance, the reconciliation process must be repeated as the model continues to evolve.

The same issue extends to query execution. A query may be syntactically valid and execute successfully on any compliant engine, yet still produce results that are semantically invalid with respect to the underlying model, as discussed in SPARQL query guardrails. Query engines evaluate syntax and execution semantics but do not assess whether a query is conceptually meaningful. Such validation is only possible when the intended semantics of the model have been explicitly defined rather than remaining implicit in the collective understanding of the development team.

That said, ontology engineering addresses this challenge by making the intended meaning of a domain explicit, consistent across an organisation, and resilient as systems and teams evolve. Before examining how this is achieved, however, it is important to define precisely what is meant by an ontology, a term that is often used imprecisely.

Domain Model, Data Model, Schema & Ontology: A Practical Distinction

Four related terms in this context are often used interchangeably, despite referring to distinct concepts. This ambiguity is a common source of modelling inconsistencies and unnecessary debate. The definitions adopted in this article are presented below. Although alternative interpretations are equally valid and the boundaries between these concepts may reasonably differ across contexts, maintaining a clear distinction between them is essential in practice.

The domain model is the highest level of abstraction. It describes the entities, relationships, and business concepts of a domain independently of any data representation or implementation technology. For example, it captures the fact that a customer places orders and that an order contains line items, without referring to tables, triples, or graph structures.

The data model defines how information about the domain is represented as data. Although it remains independent of any specific technology, it specifies the structure of entities, their attributes, and the relationships between them.

The schema is the implementation-specific representation of a data model within a particular platform. It defines the structural constraints enforced by a database or graph engine, such as column definitions in PostgreSQL, node labels and indexes in Neo4j, or the predicates and constraints expected by an RDF triplestore.

The ontology is an explicit semantic specification of a domain. It defines concepts, relationships, constraints, and axioms that capture the intended meaning of the data. Unlike a schema, which primarily enforces structural validity, an ontology makes semantics explicit. It can express, for example, that Actor is a subclass of Person, that directed is the inverse of directedBy, or that an Award has exactly one recipient for each ceremony. As a result, an ontology supports interpretation and reasoning by both humans and machines.

The most significant distinction is between a schema and an ontology. A schema specifies the structural form that a particular system accepts, whereas an ontology defines the semantics of that structure for both humans and machines. In other words, a schema constrains data representation, while an ontology defines its meaning.

This distinction also explains the role of ontologies in knowledge graphs. In their 2021 survey, Knowledge Graphs, later published in ACM Computing Surveys, Aidan Hogan and colleagues describe a knowledge graph as a data graph enriched with additional semantic layers, including a schema that defines high-level structure, identity that specifies what entities denote, and context that determines the conditions under which statements hold. Within this framework, the ontology provides the explicit, machine-readable semantic model underlying the schema layer. Put simply, the ontology is the component of a knowledge graph that captures meaning rather than merely representing data.

Four layers, often conflated: the domain model and data model stay technology-agnostic, the schema is system-specific, and the ontology is the explicit semantic layer that carries meaning across all of them.

In RDF-based systems, this semantic layer is typically addressed explicitly through ontology engineering, reflecting the historical development of the ecosystem. In contrast, property graph platforms often approach the same activity under terms such as schema design, domain modelling, or semantic modelling. Although the terminology differs, the underlying engineering challenge remains the same: defining and maintaining a shared semantic model of the domain.

Does Ontology Apply to RDF & Property Graphs Both?

A Labeled Property Graph (LPG) does not support ontologies in the formal sense defined by OWL. OWL provides a model-theoretic semantics, adopts the open-world assumption, and enables logical inference through description logic reasoners, capabilities that property graph databases such as Neo4j do not implement. Constructs such as owl:TransitiveProperty therefore have no direct counterpart in the LPG model. Consequently, the claim is not that data modelling in property graphs and OWL ontologies are equivalent. Even so, ontology engineering practices remain relevant across both RDF and property graph systems, even if only one of the two ecosystems describes them in those terms.

In RDF ecosystems, ontology is a first-class concept. The technology stack provides standard languages for semantic modelling, including RDFS and OWL, together with SHACL for validating graph structures and constraints. As a result, the semantic layer is explicitly represented and governed using well-defined standards.

In contrast, LPG ecosystems address the same modelling concerns without a standard ontology language. Semantic definitions are typically embedded within the graph model, application data model, or application logic rather than expressed through a shared vocabulary. Nevertheless, many property graph projects maintain an explicit ontology (or an equivalent semantic model) to ensure that domain semantics remain consistent as systems evolve.

The underlying modelling challenges are identical in both paradigms. Decisions about what constitutes an entity rather than an attribute, how relationships should be named and constrained, how identity should be defined, and how concepts such as roles, hierarchies, provenance, events, and time should be represented are independent of the underlying graph technology.

Neither RDF nor property graphs provide answers to these questions. They are fundamentally modelling decisions. Consequently, a property graph team that defines two explicit relationships such as DIRECTED and ACTED_IN instead of a generic RELATED_TO is performing ontology engineering in practice, regardless of whether that terminology is explicitly adopted.

// Vague: what does RELATED_TO mean between a Person and a Film?
(:Person)-[:RELATED_TO]->(:Film)

// Explicit: the semantics are in the edge, readable by a human and a query author
(:Person)-[:DIRECTED]->(:Film)
(:Person)-[:ACTED_IN]->(:Film)

The key distinction is that the discipline of explicitly defining domain concepts and making those definitions shared and durable applies independently of the underlying graph model. The objective is to establish a common semantic model that remains consistent regardless of how the data is represented or serialized.

This distinction is becoming increasingly important as organisations adopt multiple graph technologies. It is now common for an RDF triplestore and a property graph database to coexist within the same enterprise, requiring a single conceptual model that spans both environments, a scenario platforms like AWS Neptune make concrete by exposing both RDF/SPARQL and property graph/openCypher access over the same store. In practice, the RDF and property graph ecosystems are converging more rapidly than their respective standards might suggest, a trend reflected in several presentations at the Knowledge Graph Conference 2026.

One conceptual model, two serializations: the same entities and relationships expressed as RDF triples and as an LPG.

Best Practices for Ontology and Graph Model Engineering

The principles presented in this section apply equally to RDF and property graph systems. Each practice is paired with the modelling issue it is intended to prevent, as many common failures arise from the omission of a corresponding design principle.

Start with Domain Questions, Not Source Structures

Ontology and graph model design should begin with the questions the graph is intended to answer and the concepts that exist within the domain, rather than with the structure of the source data. A common modelling error is to reproduce the source schema directly within the graph, causing the model to inherit implementation artefacts such as join tables, denormalised columns, or legacy decompositions that reflect storage decisions rather than domain semantics.

A relational schema is designed to support efficient data storage and retrieval within a database system. An ontology, by contrast, defines the concepts of a domain and the semantic relationships between them. Allowing the structure of the source database to determine the conceptual model results in a graph that mirrors implementation details instead of representing the domain itself.

Model Identity Early

The identity of each node should be established at the outset of the modelling process. A real-world entity, the source record describing that entity, its identifier, and an event involving that entity represent distinct concepts and should not be conflated. Failing to distinguish between them introduces inconsistencies that become increasingly difficult to resolve as the graph evolves.

A common modelling error is to equate a source record with the entity it represents. When multiple systems contain records for the same real-world customer, assigning one Customer node to each record produces duplicate representations of the same entity, leading to incorrect query results and inconsistent analytics. RDF makes this issue explicit because every resource requires an IRI, forcing a clear definition of what that identifier denotes. Property graph systems require the same modelling decision, although it is often made implicitly rather than explicitly.

Make Relationship Semantics Explicit

Relationships are as semantically important as entities, and generic relationship types quickly reduce the interpretability of a graph. Labels such as HAS or RELATED_TO often combine multiple unrelated semantics into a single relationship type, making it difficult to understand or query the model without inspecting the underlying data.

The Film Club graph introduced earlier illustrates this issue. Although the schema defined the classes Actor and Director, the corresponding relationships to films were not modelled explicitly, leaving these specialised classes disconnected from the graph. Consequently, the model could not determine which actors appeared in which films or which directors directed them. This issue is avoided by defining semantically precise relationships, such as ACTED_IN and DIRECTED, together with their intended domains and ranges. The approach used by gdotv to reconstruct these relationships from SHACL property shapes is described in SHACL in gdotv.

A single overloaded RELATED_TO edge hides several distinct meanings; explicit typed relationships put the semantics where queries and people can read them.

Separate Conceptual Design from Implementation Optimisation

The physical representation of a graph, whether as RDF triples or as nodes and properties in a property graph, is an implementation of the conceptual model, optimised for a particular platform and workload. It should not become the conceptual model itself. Otherwise, implementation decisions such as denormalisation, indexing strategies, or query optimisations become indistinguishable from domain semantics, making it difficult to separate business concepts from performance-driven design choices.

A conceptual model should therefore be maintained independently of any specific implementation. This ensures that changes to the physical representation for performance or operational reasons do not alter the intended meaning of the domain.

Treat Constraints and Validation as Part of the Model

Constraints are part of the semantic model rather than an isolated validation step. Rules such as requiring every nomination to reference exactly one film, limiting a person to a single date of birth, or ensuring that every order has an associated customer define the intended structure of the domain and should be modelled accordingly.

In RDF, SHACL provides a standard mechanism for expressing such constraints. As discussed in the blog post on SHACL, a shape requiring exactly one value for a property does more than validate data and it also captures an aspect of the domain model. In property graph systems, equivalent constraints are implemented through schema constraints, node keys, or application-level validation. Regardless of the technology, these rules should be explicit, versioned, and maintained alongside the model rather than embedded solely in application code or undocumented conventions. gdotv preserves SHACL constraints when loading a graph, although automated validation workflows remain part of the planned roadmap rather than the current implementation.

Version and Document the Model as a Shared Asset

A graph model should be treated as a shared engineering artefact. It should be versioned, documented, assigned clear ownership, and accompanied by the rationale for significant modelling decisions. Documentation, examples, change histories, and mechanisms for visualising the model are as important as the model itself because they promote a consistent understanding across teams.

This practice is one of the most effective safeguards against model drift. Without a single versioned source of truth, each team must infer the conceptual model from the data, inevitably leading to inconsistent interpretations and semantic divergence.

Modelling identity means keeping four things distinct: the real-world entity, the source record that describes it, the identifier that names it, and events it takes part in.

What Good Tooling Should Support

Tooling complements the modelling discipline described above by making it practical to apply consistently across teams. Regardless of the implementation or vendor, several capabilities are particularly important. Collaborative modelling and editing ensure that the model is maintained as a shared asset rather than an individual’s work. Visualisation should support both conceptual and implementation views, since each serves a different purpose. Constraints and validation enable modelling rules to be expressed explicitly and verified consistently. Versioning and governance provide traceability and accountability for changes. Mapping between the conceptual model and the physical graph allows semantics and implementation to evolve with an appropriate degree of independence. Finally, support for both RDF and property graph workflows reflects the increasingly common situation in which organisations employ both technologies.

It is instructive to examine how established tools address these challenges, as each illustrates design principles that can be applied more broadly. The following discussion is based on publicly available documentation and demonstrations and focuses on the modelling approaches adopted by each tool rather than providing a feature by feature comparison.

Graphologi, developed by Graphifi, focuses on taxonomy and ontology engineering and belongs to the same class of tools as the widely used editor Protégé. It supports SKOS and OWL, with the semantic model represented directly in RDF. Its primary contribution is a standards based approach in which interoperability with the broader semantic web ecosystem follows naturally from the underlying representation.

graph.build demonstrates a different approach. Source data is imported, the tool analyses its structure, and a conceptual graph model is defined visually by specifying entities, relationships, and mappings from source fields. From this model, the corresponding graph can be generated for either RDF or property graph platforms. The key design principle is the separation of conceptual modelling from physical representation, allowing a single semantic model to be realised in multiple graph technologies.

Design the target graph once, then generate either an RDF graph or a property graph from the same model: the pattern several mapping tools share.

TopBraid EDG from TopQuadrant is RDF-centric and designed around governance and change management. It supports versioning of data and ontologies at the same time, treating the model as a managed artefact. On the modelling side, it places strong emphasis on SHACL, with prebuilt ontologies, templates, and modelling practices that prioritise SHACL over exclusive reliance on OWL or RDFS. The main pattern it illustrates is the treatment of versioning and governance as core capabilities, combined with a SHACL-first modelling approach.

metaphactory aligns closely with W3C standards and the FAIR principles. Two capabilities are particularly notable. First, it provides a catalogue in which ontologies can be imported, annotated, and searched while remaining logically separated within a shared environment, which is essential in settings where multiple vocabularies coexist. Second, it offers vocabulary mapping functionality that supports migration from older to newer terms, including suggestions as changes are introduced by contributors. The key pattern it demonstrates is a governed vocabulary lifecycle in which change history is preserved as part of the model itself.

Hackolade represents a different approach. Its polyglot data model functions as a technology-agnostic conceptual layer in which entities correspond to classes, attributes to datatype properties, and relationships to object properties, forming a structure that resembles an ontology at a conceptual level. From this single blueprint it can generate implementation schemas for multiple targets, including document stores, relational databases, RDF triplestores, and property graphs. The main pattern it offers is a clear separation between conceptual modelling and physical representation, enabling one model to be projected into multiple storage technologies. It is important to be precise about scope, since this conceptual layer is not a formal OWL ontology: it does not aim to provide description logic reasoning or open-world semantics, although its structural correspondence is intentional and useful.

Across these tools, two common themes emerge. First, the model is treated as a first-class, versioned artefact rather than an incidental by-product of data management. Second, RDF and the W3C stack remain central for standardised semantic representation and interoperability. These are also the design principles that gdotv aims to follow.

With respect to gdotv itself, the current state and intended direction should be distinguished clearly. At present, gdotv extracts a data model from an RDF triplestore and unifies SHACL, OWL, and RDFS layers into a single explorable representation. The ontology support introduced earlier this year and the subsequent addition of SHACL constraint loading provide the foundation for this view. SHACL constraints are ingested and preserved, although they are not yet executed as part of a live validation pipeline. In addition, gdotv’s Data Discovery mode incrementally incorporates structures observed during query execution, extending the model beyond explicitly declared schema elements when new patterns appear in the data.

Several capabilities remain in progress. These include collaborative editing, model versioning and governance, explicit mapping between conceptual and physical models, and a unified workflow spanning RDF and property graph systems. These are explicitly planned directions rather than existing functionality, and it is important to distinguish them from current behaviour.

gdotv’s data model view over a synthetic dataset built from the W3C Wine Ontology, consolidating RDFS, OWL, SHACL, and instance-level literals into one explorable model. Source: gdotv.

Ontology Engineering as a Discipline, Not a Format Debate

It is easy to interpret this discussion as a comparison of formats, RDF versus property graphs, or standards versus pragmatism. That interpretation is misleading. The point of this post is that ontology is not exclusively an RDF concern, and that serialization choice is secondary to the modelling work itself.

RDF provides a more explicit and formal foundation for ontology engineering through standardised vocabularies, formal semantics, reasoning support, and SHACL for constraint definition. This is a practical advantage in contexts where such capabilities are required. However, property graph systems confront the same fundamental questions regarding identity, entities, relationships, and constraints. Addressing these questions rigorously is no less an act of ontology engineering simply because it is framed as schema design.

What distinguishes a stable graph system from one that drifts is not the underlying technology, but whether the model is treated as a governed engineering artefact that is owned, versioned, documented, and shared. In contrast, systems that allow semantics to emerge implicitly from ingestion pipelines inevitably accumulate inconsistencies over time. The appropriate serialization should be selected based on system requirements, after which the modelling discipline must be applied consistently.

To understand the actual structure of a graph model, rather than its assumed structure, the graph can be loaded into a triplestore and explored using gdotv, or examined using a system such as Apache AGE graph. The extracted model view makes the underlying structure explicit. The SHACL deep dive demonstrates these mechanics on a real dataset. As with the Film Club graph, the difference between syntactically valid data and a semantically coherent model can be substantial.