When Predicates Lie: SHACL, Reification, and the Event-First Ontology

Apr 11, 2026

Kurt Cagle and Chloe Shannon
The Ontologist

There is a quiet assumption embedded in most ontology work that goes largely unexamined: that the domain you are modelling is fundamentally a collection of things with properties. You identify your classes, you assign your predicates, you wire them together with OWL restrictions or SHACL shapes, and you call it a model. The result is usually technically correct and practically brittle — a system that handles the cases it was designed for and fails instructively at the edges.

This article is about those edges, and about a deeper way of thinking about knowledge graph design that the edges point toward. We will move through a concrete regulatory modelling problem — food safety rules across jurisdictions — and use it to examine three ideas that, taken together, represent a significant shift in how expressive knowledge graphs should be built: the structural difference between SHACL and OWL, what RDF 1.2 reification actually makes possible, and why event-first modelling is not just a tactical improvement but a different epistemological orientation entirely. Underneath all three, we will find the same structural pattern: the holon.

We are writing for the intermediate data modeller — someone comfortable with Turtle, familiar with OWL class hierarchies, beginning to work seriously with SHACL — who senses that something is missing from the standard toolkit but hasn’t yet found the language to name it. We hope to provide that language.

Part One: The Problem with Properties

A Regulatory Scenario

Consider a food manufacturer operating across multiple jurisdictions. One business rule governs ingredient approval: genetically modified ingredients are freely permitted in the United States (subject to an approved list), permitted for a narrower subset in Japan, and prohibited entirely in France. A second rule, introduced later, complicates the French case: starting in 2026, France permits a limited and distinct set of GMO ingredients, but only for products approved after that date and only under a specific piece of legislation.

This is not an exotic scenario. It is the kind of multi-axis, context-dependent, temporally evolving rule that governs most serious domains — regulatory, financial, clinical, supply chain. And it is precisely the kind of scenario that exposes the limits of the standard ontology toolkit.

What OWL Does

OWL’s response to this problem is class proliferation. The regulatory distinctions must be absorbed into the class hierarchy, because OWL has no other mechanism for carrying contextual conditions. A French product becomes a subclass of Product. A pre-lift French product and a post-lift French product become disjoint subclasses of that. Jurisdiction-specific ingredient approvals become subclasses of GMOIngredient. The class hierarchy becomes a changelog.

@prefix owl:  <http://www.w3.org/2002/07/owl#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix xsd:  <http://www.w3.org/2001/XMLSchema#> .
@prefix ex:   <http://example.org/food#> .

ex:GMOIngredient a owl:Class ;
    rdfs:subClassOf ex:Ingredient .

ex:NonGMOIngredient a owl:Class ;
    rdfs:subClassOf ex:Ingredient ;
    owl:disjointWith ex:GMOIngredient .

ex:FRApprovedGMO a owl:Class ;
    rdfs:subClassOf ex:GMOIngredient ;
    rdfs:comment "GMO ingredients approved under FR_GMO_PartialLift only." .

ex:FRProductPreLift a owl:Class ;
    rdfs:subClassOf ex:FRProduct ;
    rdfs:subClassOf [
        a owl:Restriction ;
        owl:onProperty ex:hasIngredient ;
        owl:allValuesFrom ex:NonGMOIngredient
    ] ;
    rdfs:subClassOf [
        a owl:Restriction ;
        owl:onProperty ex:approvedUnder ;
        owl:allValuesFrom ex:FR_GMO_Prohibition
    ] .

ex:FRProductPostLift a owl:Class ;
    rdfs:subClassOf ex:FRProduct ;
    rdfs:subClassOf [
        a owl:Restriction ;
        owl:onProperty ex:hasIngredient ;
        owl:allValuesFrom [
            a owl:Class ;
            owl:unionOf ( ex:NonGMOIngredient ex:FRApprovedGMO )
        ]
    ] ;
    rdfs:subClassOf [
        a owl:Restriction ;
        owl:onProperty ex:approvedUnder ;
        owl:allValuesFrom ex:FR_GMO_PartialLift
    ] .

ex:FRProductPreLift owl:disjointWith ex:FRProductPostLift .

The problems compound quickly. OWL-DL has no temporal reasoning primitives — there is no mechanism by which a reasoner can infer ex:FRProductPostLift from the value of an ex:approvalDate literal. That inference must be performed externally and the class assignment made manually, which means the ontology isn’t reasoning at all — it’s receiving answers and filing them. The class hierarchy doesn’t represent knowledge about the domain; it represents the consequences of decisions made elsewhere, encoded as type assertions. If France amends the regulation, a new class must be minted. The ontology has become operationally coupled to the legislative calendar.

More fundamentally, ex:FRProductPostLift is not a class in any ontological sense. It is a policy state wearing a class costume. The disjointness assertion between ex:FRProductPreLift and ex:FRProductPostLift makes a metaphysical claim — that these are categorically different kinds of things — when the reality is that they are the same kind of thing (a food product) evaluated under different regulatory conditions. OWL cannot represent that distinction.

The Predicate-Property Confusion

There is a deeper problem underneath the class proliferation, and it runs throughout most applied ontology work. In formal logic, a predicate is a relation — it holds between terms under given conditions. A property in the OWL/RDF tradition is treated as a functional attribute — something an entity has, with a value. These are not the same thing, and the RDF data model, by representing both as binary directed triples, systematically obscures the difference.

ex:hasIngredient looks like a property. It looks like something a product has. But it is actually a relation that holds between a product, an ingredient, a jurisdiction, a regulatory instrument, and a point in time — simultaneously. Flattening that five-dimensional relation into a binary predicate and then trying to recover the lost dimensions through class proliferation is working against the grain of what the domain is actually saying.

This conflation — predicate as relation versus property as attribute — is, we would argue, the original sin of most applied ontology work. The complexity it suppresses does not disappear; it surfaces later as class explosion in OWL, shape proliferation in SHACL, or reification debt in raw RDF. The tool pays the price for a decision that should have been made at design time.

Part Two: What SHACL Does Differently

Constraints as Context, Not Identity

SHACL’s fundamental architectural difference from OWL is often described as the open-world versus closed-world distinction, but that framing, while correct, undersells what is actually interesting. The more important difference is this: OWL makes statements about what things necessarily are; SHACL makes statements about what must be true in a graph given its current state and context.

This means SHACL can express the same property path (ex:hasIngredient) under different shape targets conditioned on a separate axis (ex:hostCountry), without asserting anything about class membership at all. The constraint is on the graph pattern, not the entity. Each regulatory regime is a distinct shape with its own closure, not a disjoint set.

@prefix sh:  <http://www.w3.org/ns/shacl#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix ex:  <http://example.org/food#> .

ex:USProductShape a sh:NodeShape ;
    sh:targetClass ex:Product ;
    sh:condition [
        sh:property [ sh:path ex:hostCountry ; sh:hasValue ex:USRegime ]
    ] ;
    sh:property [
        sh:path ex:hasIngredient ;
        sh:or (
            [ sh:class ex:NonGMOIngredient ]
            [ sh:in ( ex:ApprovedGMO_US_001 ex:ApprovedGMO_US_002 ) ]
        ) ;
        sh:message "US products may only use non-GMO or US-approved GMO ingredients."
    ] .

ex:FRProductShape a sh:NodeShape ;
    sh:targetClass ex:Product ;
    sh:condition [
        sh:property [ sh:path ex:hostCountry ; sh:hasValue ex:FRRegime ]
    ] ;
    sh:property [
        sh:path ex:hasIngredient ;
        sh:class ex:NonGMOIngredient ;
        sh:message "FR products may not contain any GMO ingredients."
    ] .

The ingredient doesn’t change its nature when it crosses a border. What changes is the validity conditions on its use in a given context. SHACL models that directly. OWL cannot.

Temporal and Legislative Axes

When France’s 2026 regulatory change introduces a second axis — product approval date in addition to jurisdiction — the SHACL model absorbs it cleanly:

ex:FR_Regulation_2026_GMO a ex:RegulatoryInstrument ;
    ex:jurisdiction   ex:FRRegime ;
    ex:effectiveDate  "2026-01-01"^^xsd:date ;
    ex:legalReference "FR-ENV-2026-0042" .

ex:ApprovedGMO_FR_001 a ex:GMOIngredient ;
    ex:approvedUnder ex:FR_Regulation_2026_GMO .

ex:FRProductPostLiftShape a sh:NodeShape ;
    sh:targetClass ex:Product ;
    sh:condition [
        sh:property [ sh:path ex:hostCountry ; sh:hasValue ex:FRRegime ]
    ] ;
    sh:condition [
        sh:property [
            sh:path ex:approvalDate ;
            sh:minInclusive "2026-01-01"^^xsd:date
        ]
    ] ;
    sh:condition [
        sh:sparql [
            sh:select """
                SELECT $this WHERE {
                    $this ex:approvedUnder ?law .
                    ?law a ex:RegulatoryInstrument ;
                         ex:effectiveDate ?effDate .
                    FILTER(?effDate <= "2026-01-01"^^xsd:date)
                }
            """
        ]
    ] ;
    sh:property [
        sh:path ex:hasIngredient ;
        sh:or (
            [ sh:class ex:NonGMOIngredient ]
            [ sh:class ex:GMOIngredient ;
              sh:node ex:FRApprovedIngredientShape ]
        ) ;
        sh:message "Post-lift FR products may only use approved GMO ingredients."
    ] .

ex:FRApprovedIngredientShape a sh:NodeShape ;
    sh:sparql [
        a sh:SPARQLConstraint ;
        sh:message "GMO ingredient not approved under any active French regulatory instrument." ;
        sh:select """
            SELECT $this WHERE {
                FILTER NOT EXISTS {
                    $this ex:approvedUnder ?law .
                    ?law ex:jurisdiction ex:FRRegime ;
                         ex:effectiveDate ?effDate .
                    FILTER(?effDate <= "2026-01-01"^^xsd:date)
                }
            }
        """
    ] .

The legislative instrument is a named data node — a first-class graph citizen with its own properties. When France adds a newly approved ingredient in 2028, you add one triple:

ex:ApprovedGMO_FR_003 ex:approvedUnder ex:FR_Regulation_2026_GMO .

No shapes change. No classes change. The validation graph updates because the shape reasons over the data rather than encoding the data as structure. This is the architectural distinction that matters: in the OWL model, the regulatory regime is the structure. In the SHACL model, the regulatory regime is data the structure reasons about.

On Shape Proliferation

A fair objection at this point is that deep, multi-condition SHACL shapes can become as difficult to maintain as the class hierarchies they replace — that in escaping one form of complexity we’ve introduced another. This concern is valid, and it points at something important: the shapes are complex because the underlying predicate is still carrying more than it should. Shape proliferation is a symptom; the disease is modelling a multi-dimensional relation as a binary predicate and then trying to recover the lost dimensions in the shape graph.

The remedy is not simpler shapes. It is a different data model — one where the full relational context lives in the graph as data from the beginning, and the shapes can be written at the level where constraints actually belong. That remedy is what RDF 1.2 reification begins to provide.

Part Three: RDF 1.2 Reification and the Assertion as Node

What Changes

Classical RDF reification was technically available but practically painful — four triples to annotate one, no standard semantics, blank node identity issues, and no validator support. Most practitioners avoided it. RDF 1.2 replaces it with triple terms and rdf:reifies, giving you a proper named node that is about a specific triple assertion. The assertion itself becomes a first-class graph citizen.

The consequence for our model is significant. Instead of attaching approval metadata to the product node — which carries the hidden assumption that all ingredients in a product share a single approval context — we can annotate the ex:hasIngredient triple itself. The context travels with the specific assertion.

The `rdf:reifies` Form

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix ex:  <http://example.org/food#> .

ex:ProductBordeaux2026 a ex:Product ;
    ex:hostCountry  ex:FRRegime ;
    ex:approvalDate "2026-03-10"^^xsd:date ;
    ex:hasIngredient ex:ApprovedGMO_FR_001 .

ex:IngredientUsage_Bordeaux_001
    rdf:reifies <<( ex:ProductBordeaux2026
                    ex:hasIngredient
                    ex:ApprovedGMO_FR_001 )>> ;
    ex:approvedUnder   ex:FR_Regulation_2026_GMO ;
    ex:approvalGranted "2026-02-28"^^xsd:date ;
    ex:approvedBy      ex:FRFoodSafetyAuthority .

The reifier node ex:IngredientUsage_Bordeaux_001 is not a property of the product, nor of the ingredient. It is a statement about the relationship between them as asserted in this specific graph — which maps directly onto what the French food safety authority actually did: they didn’t approve the ingredient in general, nor the product in general; they approved this ingredient in this product under this regulatory instrument.

The Turtle 1.2 Annotation Syntax

Turtle 1.2 provides a compact inline form using ~name {| |}. The ~ex:name token names the reifier; the {| |} block carries its properties. The base triple is still asserted normally. The graph produced is semantically identical to the explicit rdf:reifies form.

ex:ProductBordeaux2026 a ex:Product ;
    ex:hostCountry  ex:FRRegime ;
    ex:approvalDate "2026-03-10"^^xsd:date ;
    ex:hasIngredient ex:ApprovedGMO_FR_001
        ~ex:IngredientUsage_Bordeaux_001
        {| ex:approvedUnder   ex:FR_Regulation_2026_GMO ;
           ex:approvalGranted "2026-02-28"^^xsd:date ;
           ex:approvedBy      ex:FRFoodSafetyAuthority |} .

# Anonymous reifier (when the node need not be referenced elsewhere)
ex:ProductLille2026 a ex:Product ;
    ex:hostCountry  ex:FRRegime ;
    ex:approvalDate "2026-05-14"^^xsd:date ;
    ex:hasIngredient ex:ApprovedGMO_FR_002
        {| ex:approvedUnder   ex:FR_Regulation_2026_GMO ;
           ex:approvalGranted "2026-04-01"^^xsd:date ;
           ex:approvedBy      ex:FRFoodSafetyAuthority |} .

The named form should be preferred whenever the reifier will be targeted by shapes, referenced in queries, or included in audit trails. A URI is the handle by which the assertion becomes queryable as a first-class entity.

SHACL Over Reified Assertions

With reification in place, the SHACL shapes simplify and sharpen. The post-lift shape delegates the approval check to the reifier:

ex:FRPostLiftIngredientShape a sh:NodeShape ;
    sh:targetClass ex:Product ;
    sh:condition [
        sh:property [ sh:path ex:hostCountry ; sh:hasValue ex:FRRegime ]
    ] ;
    sh:condition [
        sh:property [
            sh:path ex:approvalDate ;
            sh:minInclusive "2026-01-01"^^xsd:date
        ]
    ] ;
    sh:sparql [
        a sh:SPARQLConstraint ;
        sh:message "Post-lift FR product has a GMO ingredient with no valid approval annotation." ;
        sh:select """
            SELECT $this ?ingredient WHERE {
                $this ex:hasIngredient ?ingredient .
                ?ingredient a ex:GMOIngredient .
                FILTER NOT EXISTS {
                    ?usage rdf:reifies <<( $this ex:hasIngredient ?ingredient )>> ;
                           ex:approvedUnder ?law .
                    ?law ex:jurisdiction ex:FRRegime ;
                         ex:effectiveDate ?effDate .
                    FILTER(?effDate <= "2026-01-01"^^xsd:date)
                }
            }
        """
    ] .

ex:IngredientUsageReifierShape a sh:NodeShape ;
    sh:targetSubjectsOf rdf:reifies ;
    sh:property [
        sh:path ex:approvedUnder ;
        sh:minCount 1 ;
        sh:class ex:RegulatoryInstrument ;
        sh:message "Ingredient usage reifier must cite a regulatory instrument."
    ] ;
    sh:property [
        sh:path ex:approvalGranted ;
        sh:minCount 1 ;
        sh:datatype xsd:date ;
        sh:message "Ingredient usage reifier must carry an approvalGranted date."
    ] ;
    sh:property [
        sh:path ex:approvedBy ;
        sh:minCount 1 ;
        sh:message "Ingredient usage reifier must identify the approving authority."
    ] .

Each shape now does one thing clearly: the product shape checks whether the approval context exists; the reifier shape checks whether that context is well-formed. The constraint complexity has been distributed to the level where it actually belongs.

A Note on OWL and Reification

It is worth stating plainly that RDF 1.2 reification does not meaningfully improve OWL’s position. OWL 2 predates RDF 1.2 and has no semantics for triple terms. A reasoner operating over OWL axioms will treat reifier nodes as untyped resources and ignore the annotation context entirely. RDF 1.2 reification is, in practice, a SHACL and SPARQL story. This is not a criticism of OWL — it is a clarification of scope. OWL describes what is necessarily true about a domain’s structure. Reification describes the provenance, temporality, and conditions of specific assertions within that structure. These are different jobs, and the right tool depends on which job you’re doing.

Part Four: Event-First Modelling

The Compression Problem

Return to the triple ex:ProductBordeaux2026 ex:hasIngredient ex:ApprovedGMO_FR_001. It presents itself as a fact. But it is actually a compressed event record: an approval process occurred, on a specific date, under a specific regulatory instrument, with a specific authority signing off, resulting in this ingredient being permitted in this product. The binary predicate hides all of that. The reifier begins to recover it.

But reification is still, in a sense, a patch — it annotates a compressed assertion after the fact. Event-first modelling asks: what if we never compressed it in the first place?

Inverting the Design Process

Most ontology design begins with a noun inventory: identify the classes, then ask what properties connect them. Event-first modelling inverts this. Begin with the things that happen in your domain — approvals, assignments, measurements, transactions, classifications, regulatory transitions — and let the entities crystallise as the stable participants that persist across those events.

In practice, your initial modelling sessions should ask: what are the significant state changes in this domain, and what must be true for each of them to be valid? The answers give you your event structure. Classes emerge as the things that participate in those events in recurring roles.

Applied to our scenario, the event is ex:IngredientApprovalEvent. Its participants are the product, the ingredient, the regulatory instrument, the approving authority, and the approval date. The predicate ex:hasIngredient doesn’t disappear — it becomes a materialised view over the event, a convenient query path for cases where the full context isn’t needed.

ex:IngredientUsage_Bordeaux_001 a ex:IngredientApprovalEvent ;
    ex:forProduct      ex:ProductBordeaux2026 ;
    ex:forIngredient   ex:ApprovedGMO_FR_001 ;
    ex:approvedUnder   ex:FR_Regulation_2026_GMO ;
    ex:approvalGranted "2026-02-28"^^xsd:date ;
    ex:approvedBy      ex:FRFoodSafetyAuthority .

The SHACL shape for this event node is now shallow and clear:

ex:IngredientApprovalEventShape a sh:NodeShape ;
    sh:targetClass ex:IngredientApprovalEvent ;
    sh:property [
        sh:path ex:forProduct ;
        sh:minCount 1 ; sh:maxCount 1 ;
        sh:class ex:Product
    ] ;
    sh:property [
        sh:path ex:forIngredient ;
        sh:minCount 1 ; sh:maxCount 1 ;
        sh:class ex:Ingredient
    ] ;
    sh:property [
        sh:path ex:approvedUnder ;
        sh:minCount 1 ;
        sh:class ex:RegulatoryInstrument
    ] ;
    sh:property [
        sh:path ex:approvalGranted ;
        sh:minCount 1 ;
        sh:datatype xsd:date
    ] ;
    sh:property [
        sh:path ex:approvedBy ;
        sh:minCount 1
    ] .

The shape complexity has not gone away — it has resolved into appropriate simplicity at the right level of the model.

The Four Questions

Before committing any relation to a binary predicate, ask four questions:

Does this relation carry provenance — does it matter who asserted it?
Does it carry temporality — does it have a start, an end, or a point of validity?
Does it carry conditionality — does it hold only under specific contextual circumstances?
Does it carry agency — did something happen to bring it into being?

If the answer to any of these is yes within any current or foreseeable use case, the predicate is an event in disguise. Model it as one from the start. The cost of doing so early is low; the cost of retrofitting it later — through reification debt, shape proliferation, or class explosion — is high.

This is not a mandate to model everything as an event at maximum granularity. A simple product catalogue with no regulatory complexity doesn’t need ex:IngredientApprovalEvent nodes. The discipline is to make the granularity decision explicitly and early, driven by use case analysis, rather than defaulting unreflectively to binary predicates and discovering the need for event structure later under pressure.

Part Five: The Holonic Pattern

What All of This Has in Common

At this point a patient reader might observe that we have essentially been describing the same structural pattern from three different directions — SHACL’s conditional shapes, RDF 1.2 reification, event-first modelling — and asking what unifies them. The answer is the holon.

Arthur Koestler introduced the term in 1967 to describe entities that are simultaneously wholes in their own right and parts of larger wholes. Every living system, every social organisation, every complex artefact has this structure — it cannot be reduced to either its components or its context without losing something essential. The word has had uneven uptake in systems theory, but the concept it names is precise and directly applicable here.

An event node in our model is a holon. It has an interior — the full relational context of the assertion, its participants, its temporal anchors, its provenance, its regulatory conditions — and it presents an exterior face to higher-level shapes and queries that don’t need the interior detail. ex:hasIngredient is the exterior face of ex:IngredientApprovalEvent. The holon packages the complexity without hiding it: accessible when the context demands it, transparent when it doesn’t. That is precisely the whole/part duality, applied to the assertion level of a knowledge graph.

What is important is that this scales. The regulatory instrument is itself a holon — it has an interior structure (legal reference, effective date, jurisdiction, approved substance list) and presents an exterior face to shapes that only need to know whether a given use is compliant. The jurisdiction is a holon. The product approval is a holon. They nest: the ingredient usage event is a part of the product’s regulatory history, which is a part of the jurisdiction’s compliance record, which is a part of the broader regulatory landscape. Each level has its own valid closure while remaining a participant in the level above.

The deeper implication is that the move from property-first to event-first modelling is not just a tactical improvement — it is a recognition that the domain already has holonic structure, and the methodology should reflect that rather than flatten it. Binary predicates flatten it. Event nodes preserve it. SHACL shapes that target those nodes at the appropriate level of granularity navigate it.

Practical Implications for Your Own Ontologies

We close with a set of concrete orientations drawn from everything above.

Question every binary predicate. Before you commit ex:hasIngredient, ex:employedBy, ex:approvedFor, or any relation connecting two entities, apply the four questions. If any dimension — provenance, temporality, conditionality, agency — is present in any foreseeable use case, that predicate is an event in disguise. Model it as one now.

Start from the verbs, not the nouns. Your initial modelling sessions should produce event nodes before they produce class hierarchies. Ask what the significant state changes in the domain are, and what must be true for each to be valid. Let the classes emerge as the participants that persist across those events.

Treat predicates as views, not ground truth. Binary predicates are useful query shortcuts. They should exist in your graph. But they should be understood as derived from the underlying event structure, not as primary assertions. When a query needs the full context, it navigates the event node. When it needs a simple traversal, it uses the predicate path. Document which event structure each convenience predicate summarises and under what conditions the summary is valid.

Recognise holonic structure and model accordingly. Real-world domains have natural levels of granularity where things that are wholes at one level are parts at another. When you identify this structure, preserve it. Let each level have its own event nodes and its own shapes, with explicit participation properties connecting levels. Resist the urge to flatten cross-level relations into direct predicates.

Use RDF 1.2 reification at the right granularity. Reification is for the specific case where the assertion itself — not its subject or object, but the act of relating them — needs to carry context. The test: is the metadata about the relationship instance rather than either participant? Approval dates, granting authorities, confidence scores, and provenance records pass this test. General type information does not. Prefer named reifiers when the reifier node will be targeted by shapes or included in audit trails.

Design shapes at the level where constraints live. A constraint that requires navigating three property paths to reach its actual subject probably belongs on the intermediate event node. Before writing a complex sh:sparql constraint on a product shape, ask whether the constraint would be simpler as a sh:NodeShape targeting the usage event directly. Conversely, shapes that aggregate across events belong at the higher level and should be written there explicitly.

Let use cases set the granularity policy. The appropriate depth of event structure is determined by what the use cases demand, not by a general principle of maximum expressivity. The discipline is not to pre-emptively maximise complexity, but to make the granularity decision explicitly and early.

The Core Reorientation

Taken together, these implications amount to a single reorientation: the domain is not primarily a collection of entities with properties — it is a record of things that happened, the conditions under which they happened, and the participants they involved. Entities are the stable threads that persist across that record. Properties are the convenient abstractions we read off it.

SHACL, RDF 1.2 reification, and holonic graph architecture are not separate tools to be applied independently. They are a coherent stack for representing, constraining, and navigating domains that have this structure — which is to say, most domains worth modelling carefully.

The ontologist who begins from this orientation will write fewer shapes, accumulate less reification debt, and produce graphs that remain navigable as the domain evolves. The one who begins from noun inventories and binary predicates will spend considerable time later trying to recover what the domain was always trying to say.

Most of the complexity we encounter in mature ontology projects is not intrinsic to the domain. It is the accumulated cost of decisions made too early, at too coarse a granularity, by modellers who hadn’t yet asked whether their predicates were lying to them.

They usually are. The question is whether you find out at design time or in production.

The Ontologist

Discussion about this post

Ready for more?