When a Data Contract Needs an Ontology: ODCS 3.2 Test

Executive Summary

A data contract needs an ontology only when a consumer decision depends on governed relationships or logical commitments that the contract, an authoritative definition, and a taxonomy cannot settle. Open Data Contract Standard (ODCS) 3.2.0 can already state structure, ownership, quality expectations, service expectations, and links to external definitions. The official repository identifies v3.2.0 as current ^[1]; its authoritativeDefinitions field is an optional list of type and link pairs ^[2]. That link can point to a business definition, glossary, taxonomy, or ontology. It does not, by itself, prove equivalence, execute reasoning, or establish that the data are accurate.

The practical test begins with the consumer decision and the harm from a wrong answer. Use the smallest artifact that makes the decision deterministic. A contract is sufficient when types, required fields, ranges, allowed values, ownership, freshness, and executable quality rules fully determine acceptance. JSON Schema itself anticipates separate structural and semantic validation for sufficiently complex formats ^[3], while dbt defines a model contract as guarantees about model shape ^[4]. Add a glossary link when one stable concept removes label ambiguity. Add a taxonomy when the decision needs governed classification or hierarchy. Add an ontology only when consumers need cross-system equivalence, typed class or property relations, reusable relational constraints, consistency checking, or inference. NIST characterizes ontologies through concepts, relationships, and axioms ^[5]; OWL reasoning can test consistency or make implicit knowledge explicit ^[6].

The recommended handoff has five tests: the concept URI resolves, the pinned definition is compared with the current definition, a renamed field retains its stable identifier, incompatible meaning is detected, and the consumer query is evaluated before and after the change. ODCS recommends stable, refactor-safe identifiers ^[2]; Data Contract CLI documents that identifiers preserve links when names change ^[7]. Yet the same tool keeps ODCS glossary, ontology, and taxonomy entries as links rather than merging their content ^[7].

There is no defensible universal threshold based on numbers of producers, consumers, meanings, or relationships. Teams should record those counts in a local complexity ledger, set decision-specific acceptance criteria, and prefer contract-only when it passes. Published ontology research reinforces caution: one BioPortal study found most ontologies reused less than 5% of their terms ^[8]. An ontology is justified by required behavior, not by architectural prestige.

Introduction and Background

“Semantic data contract” is often used as if it named a single artifact. It does not. A data contract can contain a schema, business descriptions, owners, service expectations, and quality rules while linking to semantic assets maintained elsewhere. One documented implementation combines schema, semantics, quality metrics, and service-level objectives in the contract ^[9]. That breadth still does not turn every contract into an ontology.

This report uses an acceptance test, not a technology hierarchy. The controlling question is: what evidence must a consumer have to make a specified decision without silently changing its meaning? Peer-reviewed information-systems research defines a data product as a managed artifact that satisfies recurring information needs and creates value ^[10]. The contract should therefore be evaluated at the point of use, not by counting semantic technologies.

This distinction prevents two symmetric errors. Under-modeling leaves consumers to guess whether two labels denote the same thing or whether one status implies another. Over-modeling creates an ontology program where a type, enumerated value, definition, or taxonomy would have settled the decision. W3C guidance explicitly recommends the level of formal semantics that fits the data and likely applications ^[11].

For a system of record, semantic agreement and evidential support are separate dimensions. Reliable Context describes one canonical record per real thing, a dated verbatim source behind every value, declared unknown states, and reproducible past states. Those are observable provenance properties, not substitutes for a glossary, taxonomy, ontology, catalog, or master data management (MDM) function.

Definitions and the smallest sufficient artifact

Contract, schema, and executable rule

A data contract is a producer-consumer agreement over an interface. In dbt, the narrow form is a set of guarantees about the model’s shape ^[4]. A schema expresses representation constraints such as names, types, required fields, arrays, and ranges. JSON Schema validation asserts constraints on instance structure ^[12]. A quality rule is a testable assertion about data; Great Expectations similarly defines an expectation as a verifiable assertion ^[13].

These artifacts answer “is this instance acceptable under the declared interface?” They do not necessarily answer “does this value denote the same concept used elsewhere?” JSON Schema notes that some constraints on relationships among elements cannot be expressed ^[3]. Passing validation proves only the assertions actually present ^[14].

Definition, glossary, and taxonomy

A business definition fixes the intended meaning of one concept in prose. A glossary governs a set of such terms, often with owners, synonyms, and status. Microsoft documents a glossary as a controlled taxonomy that can be organized hierarchically ^[15]. A taxonomy adds controlled classification and hierarchy. ISO defines it as controlled-vocabulary terms organized in a hierarchical structure ^[16].

These assets are sufficient when the consumer needs a stable label, scope note, broader or narrower category, or classification path but no logical inference. SKOS, the Simple Knowledge Organization System, is designed for semi-formal knowledge organization and is explicitly not a formal knowledge-representation language ^[17]. That limitation is often useful: the artifact promises only what the decision requires.

Ontology and authoritative concept

An ontology is a formal account of classes, properties, relationships, and axioms in a domain. NIST describes ontology assets as representations of concepts, relationships, and axioms ^[5]. Web Ontology Language (OWL) 2 has formally defined meaning ^[18]. It can support consistency checking and derive implications, but OWL is not a schema language for syntax conformance ^[6].

An authoritative concept is a governed concept identified independently of a physical field name. Authority comes from accountable ownership, scope, version, and change control, not from the URI syntax. ISO defines identifier uniqueness only within a specified context ^[19]. RFC 8141 likewise warns that a syntactically correct urn: string is not automatically a valid Uniform Resource Name ^[20].

Table 1 summarizes the smallest sufficient artifact for common requirements.

The table’s central boundary is between classification and commitment. A taxonomy can place a supplier under “approved.” An ontology becomes relevant if “approved” must entail eligibility for a particular transaction only when related certifications, jurisdictions, dates, and organizational identities satisfy governed relations. Even then, evidence about the actual supplier remains a separate requirement.

The consumer-decision acceptance test

Step 1: state the decision and the harm

Write one sentence in the form: “The consumer uses field X to decide Y; a false positive causes A, and a false negative causes B.” Do not start with an ontology language or platform. The sentence determines the necessary precision and test data.

• Decision: name the action, not the dashboard or pipeline.
• Unit: state whether the value concerns a legal entity, location, account, product, event, or relationship.
• Time: state whether the value is current, effective-dated, observed, or historical.
• Unknown: distinguish not found, blocked, not applicable, and genuinely false.
• Harm: describe what changes if meaning is interpreted incorrectly.

Step 2: test contract sufficiency

Contract-only is the default candidate. Ask whether the decision is settled by:

• Physical constraints: type, format, nullability, uniqueness, and cardinality.
• Value constraints: range, enumeration, pattern, and cross-field tests.
• Operational commitments: owner, support channel, freshness, availability, and deprecation notice.
• Quality evidence: executable assertions against delivered data.
• Change policy: compatibility mode and consumer notification.

Schema evolution tools can compare a new schema with previous versions under a compatibility policy ^[21]. This is valuable but bounded. Confluent’s documented default non-transitive backward mode checks only the latest schema ^[21]. A structurally compatible change may still alter business meaning.

Choose contract-only when every material consumer can implement the decision from these constraints and tests, and when no cross-system relation must be governed. This is a positive recommendation, not a semantic shortfall. dbt warns that governance features can increase maintenance if adopted too early ^[4].

Step 3: test definition or taxonomy sufficiency

If consumers disagree because a label is overloaded, link one versioned definition. Ask each consumer to paraphrase it and classify boundary cases. If agreement returns, stop. If the decision requires only a controlled hierarchy, link a taxonomy and test each code’s placement. NIST frames controlled vocabularies around standardized terms for annotation ^[5].

Choose contract plus definition or taxonomy when:

• One concept is disputed, but its relations are not executable inputs.
• A finite crosswalk is reviewable, and mappings have explicit owners.
• Classification is sufficient, with no need to infer new facts.
• Change is infrequent, and consumers can review revisions directly.

Step 4: test ontology need

Ontology governance is justified when at least one required behavior cannot be made reliable by the preceding artifacts:

• Cross-system equivalence: consumers must determine whether differently named concepts are the same, narrower, broader, or merely related.
• Typed relationships: the decision depends on who owns, supplies, certifies, operates, succeeds, or is located at what.
• Reusable constraints: several contracts must share the same relational commitments.
• Logical consistency: incompatible class membership or property combinations must be detected.
• Inference: consumers must obtain conclusions not explicitly carried in each record.
• Stable semantic queries: a query should survive physical renames or source substitutions.

ISO defines semantic interoperability as shared data understood through formally defined domain concepts ^[19]. Resource Description Framework (RDF) supplies a graph of triples ^[22]; Shapes Constraint Language (SHACL) validates RDF graphs against declared conditions ^[23]. These technologies serve different commitments. SHACL does not make the source assertion true, and recursive validation behavior is left to implementations ^[23].

Step 5: stop and clarify when no artifact can settle the decision

Do not encode ambiguity as false precision. Stop when owners cannot state the identity unit, effective time, authoritative source, or consequence of disagreement. Record the unresolved state explicitly and name what evidence is missing. This preserves the difference between unknown meaning, unknown value, and known conflict.

Key changes in ODCS 3.2 that affect the decision

Standard version and contract version are separate

As of September 22, 2026, the official repository identifies ODCS v3.2.0 as current ^[1]. In an ODCS document, apiVersion states the standard version used to build the contract ^[24]; the separate version field is the contract’s own current version ^[24]. Conflating them makes it impossible to tell whether the serialization standard changed or the producer-consumer agreement changed.

Authoritative definitions are optional and extensible

ODCS documents authoritativeDefinitions as a list of type and link pairs ^[2]. Recommended types include a glossary entry that defines a term ^[2], a taxonomy that classifies an element ^[2], and an ontology describing a concept and its relationships ^[2]. The type remains open to other string values ^[2].

This design supports a handoff, not automatic semantic closure. The official examples place authoritative definitions at root, element, and property scope ^[25]. A consumer still needs a policy for dereferencing, version selection, accepted relation types, unavailable links, and contradictory sources.

Stable IDs differ from labels and tags

ODCS describes an authoritative-definition identifier as a stable, refactor-safe reference ^[2]. Tags, by contrast, are deliberately not a controlled vocabulary ^[26]. Tags are suitable for search and local grouping; they are weak evidence for governed equivalence.

Tool behavior is not normative semantics

Data Contract CLI release 1.2.0, dated September 8, 2026, added ODCS v3.2.0 support ^[27]. Its documentation says glossary, ontology, and taxonomy authoritative definitions remain links ^[7]. It rejects a contract when a reference it attempts to resolve cannot be resolved ^[7]. Those are implementation behaviors. They do not mean that ODCS normatively dereferences every ontology or validates its logic.

The BITOL project is listed by LF AI & Data as a Graduate-stage project (Source: lfaidata.foundation). Project status establishes governance context, not semantic correctness of a particular contract.

Implementation considerations and process changes

A worked field crosswalk (Hypothetical Example)

Consider supplier_status, a synthetic field used by procurement and diligence consumers. The identical string approved can conceal different units and lifecycles: approval of a legal entity, a site, a product category, or a time-bounded relationship. The contract must not force these into one concept merely because their strings match.

Table 2 shows the crosswalk needed before selecting an ontology.

The crosswalk reveals that no ontology is needed merely to prevent these three fields from colliding. Distinct names, identity units, definitions, value sets, and temporal semantics may suffice. An ontology becomes justified if consumers must traverse and govern relations among entity, facility, relationship, certification, jurisdiction, and effective period across many contracts.

ODCS 3.2 handoff fixture

The smallest useful fixture pins both contract and semantic references and preserves an unresolved state. The following is illustrative, not a claim that ODCS proves the linked concept’s content:

apiVersion: v3.2.0
kind: DataContract
version: 1.3.0
id: supplier-decision-contract
status: active
schema:
  - name: supplier_decision
    properties:
      - name: supplier_status
        id: supplier-status-property
        physicalType: string
        required: true
        description: Review state for one legal entity under one buyer policy.
        authoritativeDefinitions:
          - type: businessDefinition
            url: https://example.org/definition/supplier-status?v=1.4
          - type: ontology
            url: https://example.org/ontology/procurement/1.4#SupplierReviewStatus
        examples: [pending, approved, suspended, unknown]

The stable property ID is more important than the human-readable name for change continuity. Data Contract CLI explicitly recommends identifier-based references because they survive a name change ^[7]. Persistent naming also requires governance: RFC 8141 describes Uniform Resource Names as persistent and location-independent ^[20], while FAIR principle F1 calls for globally unique persistent identifiers ^[28].

Handoff tests

Table 3 turns semantic linkage into acceptance behavior.

The last row is essential. W3C PROV defines provenance around entities, activities, and people involved in producing data ^[29]. Reliable Context’s first-party guarantee that every value points to a word-for-word source, locator, and observation date illustrates an evidential contract. An ontology can define what SupplierReviewStatus means; it cannot establish that a particular supplier currently has that status.

Versioning and change control

Pin semantic assets when reproducibility matters. Semantic Versioning 2.0.0 associates backward-incompatible public API changes with a major-version increment ^[30]. Ontologies need their own policy. OBO Foundry requires a unique version IRI for each official release ^[31] and says official release files must not later change ^[31]. W3C recommends a complete version history explaining each change ^[11].

For every change, classify separately:

• Physical compatibility: can old consumers parse the new data?
• Contract compatibility: do declared rules and service expectations still hold?
• Semantic compatibility: do definitions, relations, and entailed answers still hold?
• Evidential compatibility: does the cited source still support the value?
• Decision compatibility: does the consumer take the same action for the same real-world case?

Data Analysis and Evidence

No published evidence supplies a universal numeric trigger for ontology adoption. The quantitative material instead shows why the decision must be local and test-based. A competency-question dataset formalized 131 SPARQL-OWL queries (Source: pubs.cs.uct.ac.za). A separate published dataset released 234 competency questions with translations across several ontologies and domains ^[32]. These are demonstrations of test design, not thresholds at which an ontology becomes economical.

Maintenance evidence argues against assuming frictionless reuse. A BioPortal study reported that most ontologies reused fewer than 5% of their terms ^[8]. A preliminary ontology cost model used effort-multiplier starting values from 0.1 to 2 ^[33]. Those model inputs are not universal cost ratios. A 2025 semantic-change study examined 20 consecutive ontology releases ^[34], illustrating that change analysis spans explicit and derived axioms, not just text diffs ^[34].

Teams should therefore maintain a reader-supplied complexity ledger for each decision:

• P: number of producing systems.
• C: number of materially distinct consumer decisions.
• M: number of conflicting meanings for relevant labels.
• R: number of governed relationship types used by those decisions.
• Q: number of competency questions that must remain stable.
• V: number of independently versioned semantic assets.
• U: number of unresolved identity, time, or authority questions.

The ledger is descriptive, not a score. A local policy might require ontology review when R > 0 and the same relation affects several contracts, but that is a governance choice, not an industry benchmark. A single high-consequence relation may justify formal treatment, while 100 fields of unambiguous measurements may remain contract-only.

Measure the options with the same protocol:

1. Baseline: record consumer accuracy and disagreement using the contract alone.
2. Definition treatment: add the versioned definition or taxonomy and rerun cases.
3. Ontology treatment: add only the relations needed by competency questions.
4. Change test: introduce a renamed field and a changed concept definition.
5. Unknown test: remove the semantic resource or supporting source.
6. Cost record: count governance reviews, mappings, test cases, and consumer changes.

The chosen artifact is the smallest one that meets the predeclared acceptance criteria. The Open Data Products standard expresses a similar minimality principle by allowing a bare-minimum representation to expand only as needed ^[35].

Implications and Future Directions

Semantic data contracts should evolve toward testable handoffs, not ever-larger documents. The contract should identify the authoritative concept, expected version, resolution policy, and consumer behavior. The semantic asset should own cross-contract relationships and logical commitments. Provenance records should separately establish which source supported each instance value and when.

This division also clarifies product categories:

• Use a data catalog when the primary problem is finding, grouping, and understanding assets. Microsoft describes catalog data products as groupings that help users find the full data picture ^[36].
• Use MDM when the primary problem is conforming important shared entities across operations. Microsoft defines MDM around conforming important entities that must be accurate ^[37].
• Use a data-quality suite when the main need is profiling, assertion execution, monitoring, and issue workflow.
• Use a schema registry when compatibility of serialized messages is the controlling requirement.
• Use an ontology environment when governed relations, logical consistency, inference, and stable semantic queries are the controlling requirements.
• Use a defensible system of record when one canonical record, source-level evidence, explicit unknowns, and historical replay are the controlling requirements. Reliable Context says its records keep disagreements visible and make past states reproducible.

These categories can coexist, but none should be renamed to make an architecture appear unified. A catalog entry may point to a contract. A contract may point to a glossary or ontology. An ontology may define identity relations. A system of record may preserve the evidence behind a value. The links are useful precisely because the responsibilities remain distinguishable.

Future work should report negative as well as positive results: cases where a definition eliminated disagreement, where an ontology changed no consumer answer, or where reasoning introduced operational cost without decision benefit. Competency questions are natural-language questions that constrain the knowledge an ontology should represent ^[32]. They provide a disciplined bridge from consumer need to formal semantics.

Frequently Asked Questions (FAQs)

What is the difference between a data contract and an ontology?

A data contract governs an exchanged interface, including structure, responsibilities, service expectations, and testable quality terms. An ontology governs formal concepts, relationships, and axioms. A contract may link to an ontology without containing or executing it.

Does ODCS 3.2 require an ontology?

No. ODCS documents authoritative definitions as optional links and recommends several types, including business definition, glossary, taxonomy, and ontology ^[2]. Select the type that meets the consumer acceptance test.

Is a semantic data contract the same as an ontology-backed contract?

No. A contract can carry explicit descriptions, value meanings, and authoritative glossary links without an ontology. “Ontology-backed” should be reserved for a contract whose consumer behavior depends on governed ontology concepts or relations.

Does an ontology prove data accuracy?

No. It may define what a claim means and whether it is logically compatible with other claims. Accuracy requires evidence about the instance, its source, observation time, and transformation history. FAIR principle A2 also recognizes that metadata may remain accessible after data disappear ^[28].

When should a team stay contract-only?

Stay contract-only when declared types, ranges, enumerations, owners, service expectations, and executable rules settle every material consumer decision, and when no governed cross-system relationship or inference is required. Reconsider only when a documented decision fails that test.

Conclusion

A data contract needs an ontology at a specific boundary: when a consumer decision requires governed relationships or logical commitments that structure, rules, a stable definition, and classification cannot supply. Before that boundary, contract-only is the correct design. A linked definition is appropriate for label ambiguity. A taxonomy is appropriate for controlled hierarchy. An ontology is appropriate for equivalence, typed relations, reusable relational constraints, consistency checking, inference, or stable semantic queries.

ODCS 3.2 provides the handoff mechanism without mandating the destination. Its separate standard and contract versions, optional authoritative definitions, stable identifiers, and multiple link types permit a narrow contract to depend on governed semantic assets. The link remains a claim to test, not proof of equivalence or correctness.

The operational discipline is simple: state the consumer decision, identify the harm, test the contract, add the smallest semantic artifact that removes the observed ambiguity, and stop if authority or identity remains unresolved. Then test resolution, version drift, rename stability, incompatible meanings, query behavior, and evidence separation. Record producer, consumer, meaning, relation, question, version, and unresolved counts locally, but do not convert them into unsupported universal thresholds.

This acceptance-test approach avoids both under-modeling and an unnecessary semantic-technology program. It also leaves each category accountable for what it can actually prove: contracts for interfaces, definitions for terms, taxonomies for classification, ontologies for formal relations, and provenance for the evidence behind values.