Design goals

• Remain structural, graph-aware, and independent of serialization.
• Represent additions and removals as first-class RDF resources.
• Keep delta membership navigable in both directions.
• Support RDF 1.1-compatible quad decomposition and optional RDF 1.2 reifier views.
• Provide a SPARQL 1.2 construction path for two complete dataset manifests.
• Keep provenance, comparison governance, canonicalization, and patch execution composable rather than embedded.

Scope and non-goals

The ontology owns descriptions of unordered structural differences between two identified RDF dataset snapshots. Its RDF and OWL semantics do not compute those differences. The reference constructor compares complete Service Description dataset manifests supplied in one active carrier dataset. The module does not prescribe blank-node matching, define comparison completeness, apply patches, order operations, or model proposals, decisions, branches, merges, releases, and conflict resolution.

A structural difference concerns asserted quad membership. A processor MUST NOT describe an entailed-only statement as a structural addition or removal unless the selected comparison regime first materializes that entailment into the compared snapshots. The regime itself belongs in a comparison or governance vocabulary.

Competency questions

1. Which dataset snapshots are the baseline and result?
2. Which exact quads were added or removed?
3. Did an affected quad occur in the default graph or which named graph contained it?
4. Which deltas include a given change?
5. Can membership be consumed regardless of its asserted direction?
6. Can an identity comparison be represented without inventing a change?
7. What can and cannot be concluded when a delta has no reported changes?
8. How are graph moves and value replacements represented without inventing compound primitive changes?
9. How can comparison provenance be attached without treating the delta as an activity?
10. Can a deterministic delta be constructed from two complete dataset manifests?

Delta identity, direction, and lifecycle

A delta:DatasetDelta is a persistent description of one directional relationship between a baseline snapshot and a result snapshot. It is a prov:Entity, not the activity that compared the snapshots and not a mutable sequence of update instructions. Swapping the endpoints reverses the meaning of every primitive transition and therefore describes a different delta, even if the same two snapshot resources are involved.

The ontology supplies no key or identity rule for deltas. Two resources with equal endpoints and equal reported changes are not thereby owl:sameAs. Publishers control delta IRIs and SHOULD keep each IRI attached to the same ordered endpoint pair and comparison meaning over its lifetime. Additional descriptions may accumulate under RDF's open-world semantics, but they MUST NOT change the identity of either endpoint or reverse an existing transition.

A comparison activity MAY be connected to the delta with PROV-O or a comparison-governance vocabulary. That activity may record software, time, agents, entailment regime, canonicalization, and coverage. Those facts qualify how the delta was obtained; they are not members of the structural delta itself.

Dataset endpoints

Each delta:DatasetDelta identifies exactly one delta:baselineDataset and exactly one delta:resultDataset. Each endpoint represents an sd:Dataset: one default graph and zero or more named graphs [[SPARQL-SD]]. Use of either endpoint property also entails that the endpoint is a prov:Entity. The endpoint therefore identifies one immutable dataset snapshot whose asserted quad membership is fixed for the lifetime of that resource.

A producer MUST use a different snapshot IRI when asserted quad membership changes. An IRI for a mutable dataset service or continuing dataset identity MUST NOT be used directly as an endpoint unless that IRI is defined to denote one fixed snapshot. Snapshot entities MAY use prov:specializationOf to identify the continuing dataset and MAY carry generation, attribution, derivation, and time.

In this pattern, ex:liveDataset is the continuing identity whose current content may change. The two specializations are fixed snapshot entities and are suitable delta endpoints. prov:generatedAtTime records when each snapshot entity came into existence; it does not record when a later comparison ran. Neither the timestamp nor prov:specializationOf proves content completeness. The producer remains responsible for keeping each snapshot IRI bound to fixed asserted quad membership and for supplying a complete manifest to a closed-world comparison.

The two endpoint properties MAY identify the same snapshot only for an identity delta with no reported changes. Two different snapshot IRIs may nevertheless have equal asserted quad membership and produce an empty delta. Empty named-graph existence remains outside this ontology's quad-change model, so a snapshot identity may change for that reason without producing a primitive change.

Primitive changes and contextual identity

Every delta:Change in the intrinsic SHACL contract MUST be classified as exactly one delta:Addition or delta:Removal and MUST identify exactly one delta:changeTarget. The OWL addendum declares the two primitive classes disjoint. A replacement is represented as one removal and one addition; higher-level claims that they form one conceptual replacement belong to a semantic-change vocabulary.

An addition or removal is relative to every delta that includes it. Reusing a change resource across multiple deltas therefore asserts that the same target has the stated membership transition for each associated baseline/result pair.

A target and primitive kind do not form a global identity key for a change. Independent change resources may describe the same quad transition, and the ontology does not infer that they are identical. Producers SHOULD normally mint change IRIs within the identity scope of one delta. They SHOULD reuse a change across deltas only when they deliberately assert the transition against every associated endpoint pair. The reference construction profile follows the safer local policy by deriving change IRIs from both the delta IRI and the quad.

Graph position and compound interpretations

The target's optional ss:graphTerm is part of quad identity. Its absence denotes default-graph position; its presence identifies the logical named graph. Consumers MUST compare graph position as well as subject, predicate, and object. They MUST NOT collapse equal triples from different graph positions into one primitive change.

A higher-level vocabulary may group primitive changes as a move, rename, replacement, correction, or domain event. Such an interpretation refers to the primitive resources; it does not alter their structural meaning and is not inferred by this ontology.

Bidirectional membership

delta:hasChange relates a delta to a change; delta:inDelta expresses the same membership from the change. The OWL addendum declares them inverse. Producers MAY assert either direction or both. Validators MUST accept either direction when evaluating the intrinsic contract and MUST NOT require redundant materialization merely for validation convenience.

Membership is set-like and unordered. Repeating the same triple does not create another occurrence, and neither membership direction supplies patch order. An application that needs repeated operations, ordering, or relation-level annotations must use an operational patch representation or qualified occurrence model outside this ontology.

Empty deltas and completeness

A dataset delta MAY contain no changes, but zero published membership triples has more than one possible interpretation. The base ontology deliberately does not close that ambiguity.

Completeness, coverage, comparison regime, and failure status belong to provenance or comparison-governance metadata. Consumers MUST NOT interpret missing delta:hasChange or delta:inDelta statements as a closed-world assertion unless an external contract explicitly authorizes that interpretation.

Delta, activity, patch, and semantic interpretation

Producer and consumer guidance

Producers SHOULD give snapshots, deltas, changes, and targets stable IRIs when those resources will be cited or enriched. They MUST preserve the ordered baseline/result roles, SHOULD keep change identity local to a delta, and SHOULD attach provenance to the delta or its generating activity rather than overloading primitive membership. Producers MAY publish only one membership direction.

Consumers MUST retain graph position, MUST treat addition and removal relative to the containing delta, and MUST NOT infer completeness, patch order, semantic equivalence, falsity, approval, or a compound domain event from the intrinsic graph alone. Consumers applying the OWL addendum MAY navigate either membership direction without requiring publishers to materialize both.

Parameter and input contract

The delta and endpoint resources MUST be IRIs. Each request MUST have exactly one baseline and one result. Each endpoint MUST be an immutable sd:Dataset snapshot and prov:Entity with exactly one IRI-valued sd:defaultGraph. Each listed sd:NamedGraph MUST have exactly one IRI-valued sd:name and exactly one IRI-valued sd:graph. Logical graph names MUST be unique within each dataset manifest.

Each selected manifest MUST be complete for the snapshot's asserted quad membership: it MUST list every compared graph position, and each carrier graph MUST contain every asserted triple in that position. Only under that local input contract may the constructor treat absence from a carrier graph as absence from the snapshot. This closed-manifest assumption does not change the global open-world meaning of sd:Dataset.

Service Description types MAY be asserted or supplied by RDFS entailment from these structural properties. The constructor MUST NOT require the corresponding rdf:type triples to have been materialized in the control graph.

The active default graph MUST be the control graph. A processor MUST NOT use a union-default view that exposes carrier graph content as control triples. A carrier graph with no triples represents an empty graph for quad comparison; this ontology does not represent empty graph existence as an independent change.

Comparison and output

The constructor normalizes both manifests into graph-position, subject, predicate, and object tuples. The graph-position component distinguishes the default graph from every logical named graph. A quad occurring only in the baseline becomes a delta:Removal; a quad occurring only in the result becomes an delta:Addition; a quad occurring in both produces no change. Moving a triple between graphs consequently produces one removal and one addition.

Exact keys include graph position, literal lexical form, datatype, case-insensitive language tag, and directional language-literal base direction. No entailment regime is applied to snapshot contents. Change and target IRIs are SHA-256-derived from the delta IRI and a length-prefixed quad key, so repeated execution over the same supported input is stable. The projection constructs both membership directions and the complete ss:QuadTarget decomposition.

Fail-closed boundary

The reference SPARQL 1.2 constructor accepts IRI subjects and IRI or literal objects. A blank node, RDF 1.2 triple term, or another unsupported term anywhere in either described dataset causes that complete request to produce no output. Producers SHOULD skolemize or canonicalize blank nodes under an explicitly declared comparison regime before invoking this projection.

Ambiguous endpoints, default graphs, named-graph components, duplicate logical names, or non-IRI graph values also produce no output. This avoids presenting a partial result as a complete or empty delta. Operational systems SHOULD surface rejection diagnostics separately.

Artifact Evolution composition

The Inferal Artifact Evolution Ontology can qualify an RDF delta with a governed artifact, immutable artifact versions, a comparison activity, a declared comparison regime, and an explicit coverage status. The two ontologies remain independent: this ontology does not import Artifact Evolution. No class in either vocabulary is globally equivalent to or a subclass of its similarly named counterpart, and no property is globally equivalent to or a subproperty of its similarly named counterpart.

Using ae:generatedChangeSet to identify an RDF delta entails through its range that the delta is also an ae:ChangeSet. A producer that uses this direct pattern MUST satisfy both ontologies. In particular, the Artifact Evolution baseline and result MUST be distinct versions of the same governed artifact, the comparison and change set MUST identify each other, and the comparison MUST declare its regime and coverage. A same-endpoint RDF identity delta therefore cannot use this direct pattern, although distinct artifact-version snapshots with equal asserted quads can form an empty dual-typed change set.

The example makes each contract visible instead of relying on local-name similarity. The change is an instance of the delta:Addition class and separately carries the ae:Addition change-kind individual. The target is shared because ss:QuadTarget satisfies Artifact Evolution's exact statement-target range. Both membership predicates are asserted because neither ontology entails the other.

Companion resources for interpreted change

A producer SHOULD keep the resources separate when Artifact Evolution groups, interprets, or otherwise changes the granularity of primitive quad transitions. For example, one label replacement is one removal plus one addition in RDF Delta but may be one ae:Modification in an interpreted change set. The comparison may generate both entities, and the interpreted change set may record derivation from the structural delta.

In both patterns, coverage qualifies what the declared comparison regime completed. ae:CompleteCoverage does not claim universal semantic equivalence and does not change the structural meaning of RDF Delta additions or removals.