Ontology evolution often leaves consumers with RDF expressed using an older vocabulary and no machine-discoverable route to the current one. This specification provides a declarative bridge from RDF expressed with one ontology to RDF expressed with another. Those ontologies may be releases of one continuing ontology or members of different ontology families. A migration set names the source and target ontologies, selects source and target SHACL validation gates, and explicitly associates its executable SHACL-AF transformation cases. Each case can also associate named SHACL SPARQL Rules that, after additive migration and successful target validation, produce an exact plan of source triples eligible for later retraction. A set may point to a corresponding reverse migration without claiming a lossless inverse, and paired W3C query-evaluation tests can provide EARL-reported evidence that declared observations survive the migration. It supports discovery, source and target validation, direct source-term coverage inspection, multi-case execution, and auditable consumption without making individual rules destructive or conflating migration with edit history, logical equivalence, or proof of complete semantic preservation. When execution genuinely depends on rule order, the reusable Ordering Ontology states the semantic dependency while SHACL-AF scheduling values remain processor-facing execution hints.

This is an unofficial 0.1.0 Editor's Draft maintained in the Inferal ontology repository.

Feedback should be sent to contact@inferal.com.

This specification defines six conformance classes: migration-set distribution, migration-set publisher, migration processor, retraction-capable processor, migration verification processor, and migration-set validator.

A migration-set distribution is a self-contained RDF package containing one or more om:OntologyMigrationSet descriptions and the RDF needed to assemble each set offered for execution. Each set MUST declare one source ontology, one distinct target ontology, and at least one explicitly associated rule-bearing case. The package MAY use one RDF graph or an RDF dataset and MAY contain unrelated RDF or other migration sets. For every set offered as executable, the set MUST identify its concrete assembled execution shapes graph with om:executionShapesGraph, that resource MUST declare sh:entailment sh:Rules, and the distribution MUST contain the complete RDF descriptions of its selected cases and the SHACL structures reachable from their additive and retraction rules, conditions, and ordering relations. A case MAY associate any number of named retraction rules using om:hasRetractionRule, om:retractionRuleOf, or both; a set MUST identify exactly one source shapes graph, exactly one target shapes graph, and exactly one execution shapes graph. For every asserted om:sourceShapesGraph, om:targetShapesGraph, and om:executionShapesGraph, the publisher MUST make one concrete, well-formed SHACL shapes graph resolvable by that IRI through the supplied dataset, catalog, or retrieval context. If a set asserts om:reverseMigration, the package or indexed discovery context MUST provide that reverse set's source and target endpoint description. If a set provides an om:MigrationVerificationCase, its referenced W3C query-evaluation test descriptions and common expected result MUST be available in the verification context.

A migration-set publisher MUST assert case membership using om:hasCase, om:caseOf, or both, and MUST provide a complete executable distribution for every set offered for execution. It MUST declare sh:entailment sh:Rules on the resource each set identifies with om:executionShapesGraph. A directional migration MUST NOT be presented as logical equivalence between its source and target ontologies. A publisher asserting om:reverseMigration MUST describe a set with swapped endpoints and MUST NOT present the relation as a guarantee of symmetry, equivalence, or lossless round-tripping. When one rule depends on another, a publisher MUST state that dependency with ord:precedes or inverse ord:follows, and both rules MUST identify the migration set through ord:inOrdering. A publisher MUST NOT use sh:order as the sole declaration of a meaningful dependency.

A migration processor first resolves om:sourceShapesGraph, validates the source data graph against it, and stops before executing any rule if resolution, shapes-graph well-formedness, or source conformance fails. It then resolves om:executionShapesGraph and executes the SHACL-AF rules that graph defines [[SHACL-AF]]. It MUST signal failure when it cannot execute the rule regime declared by the execution shapes graph and MUST preserve source triples throughout additive migration. It MUST assemble the final target consumer view as the union of an optional initial target graph and all triples inferred by the additive rules. It MUST NOT copy source triples into that view unless they were independently supplied as target data or constructed by a rule. It MUST respect the acyclic ord:precedes and ord:follows partial order within each phase. A processor that requires numeric SHACL-AF scheduling MAY consume compatible sh:order values or derive an equivalent schedule; it MUST reject a numeric schedule that contradicts the declared dependencies. The processor MUST resolve exactly one om:targetShapesGraph, validate the final target consumer view against it, and signal failure if resolution, shapes-graph well-formedness, or target conformance fails.

A retraction-capable processor is a migration processor that executes every applicable, non-deactivated named sh:SPARQLRule associated through om:hasRetractionRule or inverse om:retractionRuleOf. It MUST finish all additive rules first, MUST resolve the identified om:targetShapesGraph, validate the final target consumer view successfully against it, MUST execute each retraction rule for the focus nodes selected by its associated case that conform to all of the rule's sh:condition values, over the union of the preserved source graph and final target consumer view, and MUST materialize the union of the constructed results as a separate retraction plan. It MUST verify that every planned triple occurs in the original source graph. It MUST NOT delete a source triple without a separate, explicit request to apply that plan.

A migration verification processor executes the paired mf:QueryEvaluationTest resources identified by an om:MigrationVerificationCase using the W3C SPARQL test structure [[SPARQL-TESTS]]. It MUST execute the migration over the source test's declared data before evaluating the target test, rather than accepting a hand-authored target fixture as proof of execution. It MUST compare both query results with the common declared mf:result according to that test structure and MUST record the observed outcome using EARL [[EARL]]. Outcomes such as inapplicable, cannot-tell, and untested MUST remain distinguishable from failure. A passing assertion is evidence only for the declared query, fixtures, processor, and migration version; it does not prove complete semantic preservation.

A migration-set validator applies the intrinsic constraints described in . SHACL conformance establishes structural well-formedness; it does not prove that the migration is semantically complete or correct for every source graph.

Introduction

A correspondence table can say that two terms are related, and an edit log can say that an ontology changed, but neither necessarily constructs the target RDF required by an existing consumer. Conversely, a folder of unlabeled query files may perform the work while providing no machine-readable source ontology, target ontology, case inventory, or coverage surface.

This ontology provides migration-set identity, directional endpoints, explicit case membership, source and target validation links, reverse migration discovery, paired verification cases, and bidirectional phase attachment for post-validation retraction planning. SHACL-AF already defines rule attachment, focus-node targets, conditions, numeric scheduling, Triple Rules, and SPARQL Rules. The Inferal Ordering Ontology defines queryable semantic dependencies through ord:precedes and ord:follows [[INFERAL-ORDERING]]. SPARQL CONSTRUCT already defines side-effect-free graph production. Reusing those models keeps each migration and retraction-planning case executable and independently inspectable. The W3C SPARQL test structure supplies query tests and expected results, while EARL supplies observed evaluation outcomes; this module adds only the migration-specific pairing between a source-side and target-side test. The intended audience is ontology maintainers publishing migrations, data engineers selecting version-compatible transformations, catalog builders indexing them, and reviewers checking their coverage.

Scope and Non-goals

The module owns discovery metadata for additive RDF-to-RDF migration between two ontology resources, mandatory source and target validation gates, optional reverse discovery and paired verification evidence, optional staged retraction planning, and the closed-world packaging contract for an explicitly scoped, assembled SHACL-AF execution distribution. The endpoints may identify releases of one continuing ontology or ontologies from different families. Publishers SHOULD use immutable, release-specific ontology IRIs when the transformation cases depend on a particular release, and MAY connect an endpoint to a continuing artifact, version token, release, or provenance record.

The module deliberately does not:

• describe ontology edit operations or reconstruct change history;
• assert logical equivalence between source and target terms;
• replace SSSOM correspondence metadata;
• make a transformation rule destructive or treat retraction-rule discovery as deletion authorization;
• prescribe endpoint transactions, backups, credentials, or deployment-specific graph names;
• guarantee total coverage merely because every known term is targeted;
• claim that declared tests prove completeness or define an intrinsic migration-quality percentage;
• define a new general-purpose test-suite, expected-result, or evaluation-outcome vocabulary;
• require static analysis of arbitrary SPARQL strings or declare a complete list of terms that a rule can touch;
• require processors to crawl the Web for inverse links that are not present in their loaded or indexed RDF;
• define processor configuration, deployment, or credential policy.

Terminology and RDF graph boundaries

This specification uses RDF graph only for a set of RDF triples in the sense defined by [[RDF12-CONCEPTS]], and named graph only for a named component of an RDF dataset. A distribution, contract, view, plan, and rule order are distinct concepts even when an implementation represents one of them using an RDF graph. Nothing in this specification requires these logical boundaries to use particular named graphs, files, stores, or in-memory objects.

Migration-set distribution

A self-contained RDF package from which a processor can assemble one or more executable migration sets. It may be delivered as one RDF graph, an RDF dataset, or an equivalent collection of RDF resources.

Execution shapes graph

The actual SHACL shapes graph assembled for one selected migration set and selected by om:executionShapesGraph. It contains the selected cases and the reachable SHACL-AF rules, conditions, and execution-regime declaration.

Source graph and initial target graph

RDF data graphs supplied as processor inputs. The endpoint properties identify ontologies and do not identify either data graph.

Source shapes graph

The actual SHACL shapes graph selected by om:sourceShapesGraph to express the assumptions that source data must satisfy before any transformation rule executes.

Final target consumer view

The logical RDF result formed from initial target data and triples inferred by additive rules. It is called a view because it need not be persisted or occupy a named graph, although it is treated as an RDF graph when passed to SHACL validation.

Target shapes graph

The actual SHACL shapes graph selected by om:targetShapesGraph to express the target-conformance contract.

Retraction plan

The RDF graph of exact source triples constructed as eligible for a later, separately authorized update. It is a plan, not a deletion.

Verification observation and report

A query result compared with a declared expected result, and an EARL assertion reporting the observed outcome. Neither is a migration data graph or proof that the migration covers every possible input.

Rule dependency relation

The partial order stated with ord:precedes and ord:follows. It is not an RDF storage boundary.

Contract

A set of normative requirements. A SHACL shapes graph may express a contract, but the words are not interchangeable.

Competency Questions

The same directional contract covers version-to-version migration within one ontology family and migration between different ontology families. The endpoints identify concrete owl:Ontology resources, and the selected migration set identifies the executable cases.

• How do I go from version A to version B of ontology X?
• How do I migrate from ontology A to ontology B?
• What source assumptions must hold before any migration rule executes, and why did validation fail?
• Which executable transformation cases make up the migration, and can they be composed?
• Which loaded source terms and patterns are covered, unsupported, or not declared?
• What target assertions does each case produce, and what happens when a source value is unsupported?
• How do I know whether each source record migrated fully enough for the target data to validate?
• Which corresponding reverse migration is declared, and what does that relation not guarantee?
• Which paired source and target tests provide migration evidence, and what outcomes were observed?
• After all transformation cases run and target validation succeeds, which source triples may be retracted, and how is retraction kept separate from migration?

Namespace and Dependencies

SHACL-AF is a W3C Working Group Note rather than a W3C Recommendation. Its rule vocabulary is nevertheless reused directly because it defines the exact RDF structures and execution behavior required here. A processor claiming this specification's migration-processor conformance therefore explicitly commits to that optional regime.

The SPARQL test and EARL vocabularies are referenced, not imported into the migration namespace. Their existing semantics remain authoritative; this module defines only how a migration verification case selects one source-side and one target-side query-evaluation test.

Conceptual Model

An ontology migration set keeps its directional endpoints separate: the source ontology is accepted as input, while the target ontology names the vocabulary constructed by its cases. Neither endpoint relation is an equivalence claim.

Vocabulary Term Index

Coverage and Discovery

A catalog or loaded RDF dataset can locate a migration set by matching both endpoint properties, then enumerate only cases explicitly joined to that set through om:hasCase or inverse om:caseOf. This enumeration returns direct target declarations, structured Triple Rules and the sh:construct strings of SPARQL Rules. Optional retraction planners are discovered from om:hasRetractionRule or inverse om:retractionRuleOf, using the same case targets while keeping their named sh:SPARQLRule bodies out of additive execution.

When the source ontology is loaded and its terms identify their defining version with rdfs:isDefinedBy, direct selection coverage can be computed by joining terms to sh:targetClass, sh:targetSubjectsOf, or sh:targetObjectsOf. Custom targets and terms mentioned only inside a SPARQL string require target-specific analysis or SPARQL parsing. Therefore “not declared” is a review finding, not proof that the term can never influence a rule. This version deliberately defines no touchesTerm-style assertion or scope-selection query: arbitrary SPARQL can make complete static introspection impossible, and an unverified declaration would be easy to mistake for an execution guarantee. Publishers SHOULD document intended semantic alignment with comments and mapping metadata while treating direct target inspection as useful, incomplete evidence.

After additive execution, an informative readiness diagnostic can compare the preserved source assertions with the constructed target assertions and the exact patterns eligible for retraction. Such a diagnostic SHOULD distinguish complete records, partially migrated records, unsupported source values, and records for which no target assertion was produced. “Complete” is always relative to the declared cases; it does not imply total source-vocabulary coverage, and uncovered source assertions remain retained.

Validation

The module's intrinsic SHACL contract targets each migration set and reaches only its explicitly associated cases and attached rules. A case that asserts om:caseOf is also targeted directly. It requires:

• an IRI for every migration set; multiple sets may occur in one graph;
• exactly one IRI source ontology and one distinct IRI target ontology;
• at least one named, labeled, commented, explicitly targeted case associated through om:hasCase or om:caseOf;
• a well-formed Triple Rule or SPARQL Rule body for every additive sh:rule value;
• an acyclic, phase-local ord:precedes or ord:follows relation for every meaningful dependency, with each participating rule identifying exactly one migration set through ord:inOrdering;
• no standalone sh:order value and no numeric schedule that contradicts a declared dependency;
• a named, labeled, commented sh:SPARQLRule with exactly one sh:construct for every om:hasRetractionRule or om:retractionRuleOf attachment;
• exactly one IRI-valued om:sourceShapesGraph and exactly one IRI-valued om:targetShapesGraph;
• swapped source and target endpoints for every asserted om:reverseMigration;
• for every om:MigrationVerificationCase, exactly one migration, distinct source and target W3C query-evaluation tests, complete query actions, and one common expected result.

These intrinsic constraints validate mapping packaging. A conforming execution distribution declares sh:entailment sh:Rules on its execution shapes graph resource. Source validation is a processor gate before rule execution using om:sourceShapesGraph; target validation is a subsequent gate using om:targetShapesGraph. Validation of the package does not resolve either shapes graph or execute a retraction rule; a migration processor is responsible for shapes-graph resolution, target validation, and rule execution. A retraction-capable processor additionally performs result-subset checks and enforces the target-conformance gate. Absence of a retraction rule is not an RDF inconsistency; coverage and consumption policy remain specific to the mapping and its consumers.

The public validation resources are om:OntologyMigrationSetShape, om:TransformationCaseShape, om:TransformationRuleShape, om:RetractionRuleShape, and om:MigrationVerificationCaseShape. They are SHACL shapes, not additional vocabulary classes or properties.

Operational Behavior

A processor accepts a source RDF graph, an optional initial target RDF graph, one selected migration set, and a complete loaded distribution. It resolves and applies om:sourceShapesGraph first; a nonconforming source produces a SHACL validation report and no transformation rule is executed. The processor then resolves membership in either direction, assembles only the selected cases and their complete SHACL structures and ordering closure as the execution shapes graph, validates that graph, resolves the acyclic rule dependencies, executes one ordered SHACL-AF rule iteration against the source graph, and unions the inferred triples with the initial target graph to form the final target consumer view. An absent initial target graph is treated as empty. The source graph remains intact and is not implicitly copied into the target view. A processor MAY expose the union of source and final target triples for rule evaluation or inspection, but MUST distinguish that expanded graph from the final target consumer view.

Rules MUST fail closed: an absent, ambiguous, or unsupported source condition MUST NOT generate an assertion whose meaning is not supported. If multiple cases construct the same triple, the target view contains that triple once. If cases construct logically incompatible assertions, graph union does not select a winner; target validation and mapping review must report the conflict. This specification does not add a fixpoint regime: SHACL-AF leaves repeated application after other rules fire unspecified. Reapplying the complete migration SHOULD reach the same graph, and publishers SHOULD include idempotence tests whenever rules read terms that other rules can infer.

Processor support is an explicit portability boundary. Ordinary SHACL Core validation does not execute these mappings. A deployment MUST use an Advanced SHACL processor implementing [[SHACL-AF]] or reject the migration set as unsupported; ignoring its rules is not a successful migration.

Interoperability and Reuse

KGCL describes high-level changes to ontologies and knowledge graphs [[KGCL]]. It is complementary: a change record may explain why a migration is needed, while the migration set constructs a target RDF view. SSSOM records qualified term correspondences and mapping-set metadata [[SSSOM]]. It may accompany a migration for review and alignment exchange, but it does not replace record-level construction.

Inferal Governed Artifact Evolution can type endpoint ontologies as immutable artifact versions and connect the migration to evidence, decisions, realizations, and comparisons. This module does not import that governance model because discovery must also work for ontology versions that have no governed-artifact record.

The W3C SPARQL test manifest vocabulary describes query-evaluation tests and expected results [[SPARQL-TESTS]], while EARL describes assertions about their observed outcomes [[EARL]]. Reusing them keeps migration verification compatible with existing test tooling. The migration-specific contribution is only the source/target pairing and its association with one migration set. A more general test ontology may be extracted later if independently reusable requirements emerge; this version does not anticipate that vocabulary.

SHACL 1.2 Rules is a Recommendation-track Working Draft with a different rule model and execution semantics, including stratification and order-independent evaluation [[SHACL12-RULES]]. This version does not claim conformance with that draft or map its terms to SHACL-AF. A future module version may add a separate profile after the specification and interoperable implementations stabilize; existing SHACL-AF migration sets will retain their declared execution regime.

Security and Privacy Considerations

SPARQL Rules, validation constraints, and verification queries are executable content. Processors SHOULD execute only trusted migration-set distributions, restrict dataset and service access, apply resource limits, and reject unsupported extension functions. Loading a remote ontology may reveal network access patterns and may trigger retrieval of additional RDF resources; retrieval policy and credential handling are processor responsibilities outside this ontology.

Source and target fixtures and EARL reports may contain sensitive data or reveal unsupported records. Publishers SHOULD minimize fixtures, avoid production identifiers, and apply the same access controls and retention policy to verification evidence as to migration inputs.

Migration can expose information through new links or classifications even before any source triple is deleted. Publishers SHOULD review the target view for privacy and access-control consequences independently from structural SHACL conformance.

Retraction application is destructive and MUST be opt-in. Processors SHOULD require a specifically selected named source graph, present or persist the materialized plan for review, archive removed triples, and use a transaction when the graph store provides one. They MUST reject a plan containing triples outside the original source graph and MUST NOT treat an ontology term IRI as permission to remove every statement that mentions that term. Blank-node source statements SHOULD be planned and applied within one dataset identity scope because serialization does not preserve blank-node identity across independent graphs.

Evolution and Governance

Public IRIs in the om namespace are stable. Incompatible changes will use versioned ontology metadata and deprecation mappings rather than silently moving terms. Because migrations are directional, changing either endpoint, membership, any additive case, either validation gate, a reverse-migration assertion, verification pairing, retraction-rule attachment, or retraction-rule semantics creates a new version of the migration set. A publisher SHOULD retain provenance for that change through an external governance or versioning model.