Governed artifacts evolve through evidence, proposals, decisions, implementation, publication, and comparison. This specification keeps those stages separate so that a proposed or accepted change cannot be mistaken for a realized one. It supports auditable evolution of specifications, policies, schemas, mappings, configurations, controlled vocabularies, and ontologies. Publishers, reviewers, diff processors, and downstream consumers use the model to audit stable public contracts through layered governed-artifact, semantic-artifact, and ontology profiles.
This is an unofficial 1.0 Editor's Draft maintained by Inferal.
Version 1.0 strengthens comparison records introduced in version 0.1.
Existing comparisons need ae:usesComparisonRegime and
ae:coverageStatus; partial or indeterminate results also need a
literal ae:coverageDescription, while comparison regimes require
a non-empty literal dcterms:description.
Comparison/change-set generation links must agree in both directions.
The ontology profile now accepts inherited semantic and narrower
extension kinds and applies exact axiom targeting to realized changes.
Feedback should be sent to contact@inferal.com.
The key words MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY are to be interpreted as described in BCP 14 when they appear in all capitals.
Vocabulary meaning is defined by the RDFS distribution and optional OWL addendum under open-world semantics. Intrinsic record integrity is checked by the base SHACL shapes. A graph claiming conformance to the a named evolution profile MUST also satisfy that profile's SHACL constraints and every inherited constraints descriptor. Validators SHOULD load the ontology and the complete selected profile registry with RDFS entailment so controlled values and subclass relationships are visible.
Processors calculate diffs and apply changes; the vocabulary does not. Diagnostic queries may report missing realization links, unplanned changes, and conflicting decisions, but such reports do not select an authoritative decision or prove that absent facts are false.
Change systems often collapse a request, an approval, a commit, and a published semantic difference into one status field. That destroys the evidence needed to explain why a change was proposed, who decided it, what was actually implemented, and whether the released artifact differs from the accepted plan. This ontology treats each as a resource with its own identity and provenance.
The intended audience includes artifact publishers, ontology and schema maintainers, governance reviewers, semantic-diff processors, validators, and consumers assessing compatibility or migration risk.
A mutable proposal status loses earlier decisions and their authorities. A commit is an implementation container, not a semantic consequence. A diff is an observation, not evidence of prior intent. Publication is not approval. The model links these records without identifying them.
The ontology covers governed, versioned artifacts. It does not model arbitrary physical change, organizational change programmes, project schedules, ticket systems, Git object identity, authorization policy, or deployment orchestration. It does not infer acceptance from publication, implementation from acceptance, or authority from recency.
The core remains artifact-neutral. The governed-artifact profile defines lifecycle completeness; the semantic-artifact profile adds contracts shared by schemas, shapes, mappings, vocabularies, and profiles; and the ontology profile adds OWL ontology and axiom-specific obligations.
| Question | Evidence supplied by this specification |
|---|---|
| What evidence motivates a proposal, and what contradicts it? | The lifecycle example and the independent support/contradiction relations. |
| Which artifact and immutable baseline does a proposal concern? | The proposal shape verifies that the baseline belongs to the concerned artifact. |
| Which operations and exact statement targets are proposed? | The ontology-profile examples exercise exact axiom targeting. |
| Who decided a proposal, with what outcome and provenance? | The governance example records authority, activity, rationale, outcome, and time. |
| Which accepted proposals have no recorded realization? | An executable accepted-but-unrealized diagnostic. |
| Which observed changes were not linked to a plan? | An executable unplanned-change diagnostic. |
| Which non-superseded decisions conflict? | An executable conflict diagnostic that excludes explicit supersession. |
| Which changes have compatible, conditional, incompatible, or unknown impact? | Qualified impact assessments with evidence and optional confidence. |
| Under which regime were two versions compared, and with what coverage? | Comparison records identify a reusable plan and a complete, partial, or indeterminate coverage status. |
https://ontology.inferal.com/modules/artifact-evolution/ with prefix ae:.
| Vocabulary | Role |
|---|---|
| PROV-O | Entities, activities, agents, generation, usage, derivation, attribution, and specialization. |
| DCAT 3 | Continuing-resource/version hierarchy and previous-version chains. |
| Inferal Versioning | Comparable version identifiers and ordering contexts. |
| Inferal Scoped Statements | Exact quad and quad-group targets without asserting them. |
| Inferal Confidence | Scale-aware confidence and derivation assumptions. |
| SKOS | Extensible controlled schemes. |
The historical Changeset vocabulary is not imported. It is useful for triple additions and removals, but its resource-description and RDF reification model is narrower than this quad-aware governance lifecycle.
| Resource | Meaning | Does not imply |
|---|---|---|
| ae:EvolutionSignal | Evidence that review may be warranted. | A particular repair. |
| ae:ChangeProposal | Operations proposed against a baseline. | Acceptance or change. |
| ae:ChangeDecision | One authority's outcome. | Global authority or implementation. |
| ae:ChangeRealization | Implementation generating a version. | Publication or conformance. |
| ae:ArtifactComparison | Comparison generating a change set. | Logical or compatibility correctness. |
| ae:RealizedChange | An observed version difference. | That the difference was planned. |
A ae:GovernedArtifact is the continuing identity. An ae:ArtifactVersion is an immutable specialization of exactly one governed artifact. ae:hasArtifactVersion and ae:versionOfArtifact specialize DCAT and PROV version relations and are OWL inverses. ae:currentArtifactVersion records a publisher designation, while ae:versionIdentifier connects a version to an explicitly ordered version token.
Every version in the base validation contract MUST identify exactly one governed artifact. A current-version link is a publisher designation, not an ordering axiom: it does not exclude unpublished drafts, branches, or later proposals. DCAT describes revision lineage; Inferal Versioning describes tokens in an ordering. Neither relation by itself proves semantic identity between serializations.
A signal uses ae:hasSignalKind and ae:concernsArtifact. A proposal MUST identify one ae:baselineVersion, at least one ae:hasOperation, and supporting evidence with ae:supportedBy. Contradicting evidence uses ae:contradictedBy. An operation uses one ae:hasChangeKind and targets a resource through ae:affectsResource, an exact target through ae:affectsStatementTarget, or both.
A proposal MUST carry supporting evidence, but support is not proof and need not be unanimous. Contradicting evidence SHOULD remain linked when a proposal advances. One signal may motivate competing proposals, and several signals may support one proposal.
A ae:ChangeReview uses a proposal and generates a ae:ChangeDecision. Each decision uses ae:decidesProposal and ae:hasDecisionOutcome and carries authority and time through PROV. ae:supersedesDecision is explicit; consumers MUST NOT treat the newest timestamp as authority.
An ae:ImpactAssessment uses ae:assessmentSubject, may state ae:hasCompatibilityImpact, and is connected with ae:hasImpactAssessment. Any lifecycle resource may carry a structured ae:confidenceAssessment.
Confidence qualifies evidential strength; it is not a decision outcome or authorization threshold unless an external policy explicitly says so.
A realization identifies proposals with ae:realizesProposal, operations with ae:implementsOperation, and its output with ae:generatedArtifactVersion. A comparison states one ae:baselineVersion, one ae:resultVersion, and one ae:usesComparisonRegime, classifies its result with ae:coverageStatus, and states one ae:generatedChangeSet. The generated ae:ChangeSet uses ae:hasChange for each ae:RealizedChange.
A realized change may use ae:realizesOperation and ae:plannedByProposal. Their absence means that planning linkage is unknown or unresolved, not necessarily that the change was intentional or unauthorized.
A realization MAY implement only a subset of a proposal and MAY generate a draft. A comparison records only what its declared regime observes. Neither a realization nor a change set proves publication, conformance, or complete semantic comparison.
A decision is an immutable record, not mutable proposal state. Each ae:ChangeDecision MUST identify exactly one proposal and one outcome, MUST be attributed to a PROV agent, and MUST identify its review activity and generation time. The review activity MUST use the proposal and identify an associated authority.
Multiple decisions MAY address one proposal. Timestamps provide chronology, not authority. A consumer may select an operative decision only when an applicable policy identifies the relevant authority, jurisdiction, scope, or review body. This vocabulary deliberately defines none of those authorization rules.
ae:supersedesDecision is explicit and may connect only decisions about the same proposal. The earlier record and rationale remain valid historical evidence. A later decision without supersession does not erase disagreement.
| Situation | Representation | Conclusion |
|---|---|---|
| Authorities disagree | Non-superseded decisions with different outcomes | A conflict exists; no winner is inferred. |
| An authority revises a decision | A new decision explicitly supersedes the earlier one | The prior decision remains historical evidence. |
| A proposal is accepted | An accepted decision exists | Acceptance is recorded; implementation remains separate. |
| A released version contains the requested change | Realization and comparison link proposal, operation, version, and observed change | The change was observed under the declared comparison regime. |
Compatibility is not an unqualified property of a version. An ae:ImpactAssessment identifies its subject, supporting evidence, optional contradictory evidence, and at most one compatibility result. Assessments may disagree when they cover different profiles, consumers, entailment regimes, or migration assumptions.
| Impact | Interpretation | Evidence expected |
|---|---|---|
| ae:BackwardCompatible | Scoped baseline consumers and data retain meaning without migration. | Named consumer/profile scope and regression evidence. |
| ae:ConditionallyCompatible | Compatibility depends on stated conditions. | Profiles, assumptions, versions, or migration steps. |
| ae:BackwardIncompatible | At least one scoped consumer or graph may change meaning or require migration. | A counterexample, changed entailment, validation result, or consumer contract. |
| ae:UnknownCompatibility | Available evidence justifies no stronger conclusion. | The unresolved or unevaluated scope. |
The core defines no universal compatibility algorithm. Adding a class is not automatically compatible, and changing a label is not automatically harmless: closed profiles, generated APIs, language-sensitive consumers, or imported entailments may change behavior.
A comparison processor accepts two immutable versions of the same
governed artifact and a declared comparison regime. It records an
ae:ArtifactComparison using both versions and generating exactly
one ae:ChangeSet. The comparison and change set MUST identify each
other through ae:generatedChangeSet and
prov:wasGeneratedBy. The change set repeats the artifact,
baseline, and result so its identity remains inspectable without
shortcut materialization. The comparison links the reusable
ae:ComparisonRegime through ae:usesComparisonRegime and records
its result through ae:coverageStatus.
The processor MUST state whether it compares asserted triples, canonical RDF datasets, RDFS closure, OWL entailments, SHACL contracts, human definitions, or a combination. It MUST preserve named-graph scope where graph identity affects meaning. Blank-node differences MUST be canonicalized or reported as indeterminate; serializer labels are not stable identities.
The comparison regime MUST provide a non-empty literal
dcterms:description containing those scope and processing
semantics. Processors SHOULD mint a stable regime IRI for each
independently versioned comparison configuration.
Every realized change MUST identify one change kind and at least one resource or exact statement target. A processor MAY link a change to a proposal when supported, but MUST NOT invent intent from resemblance. Missing versions, mismatched artifact identity, unresolved imports, failed canonicalization, or unsupported entailment MUST prevent a claim of complete comparison. Partial observations MAY be emitted only with ae:PartialCoverage and an ae:coverageDescription naming the actual subset. Conditions that prevent the processor from determining coverage use ae:IndeterminateCoverage and an ae:coverageDescription naming the unresolved condition. Absence from partial or indeterminate output is not proof of no change. A comparison with ae:CompleteCoverage MAY generate a change set with no ae:hasChange values; under that declared regime, the empty set records that no differences were observed.
This reference defines every public class, property, scheme, and core value. Domain and range statements are entailments, not input filters; shared lifecycle properties deliberately omit global domains where several record kinds use them.
| Family | RDFS/OWL relationship | SHACL contract | Important non-entailment |
|---|---|---|---|
| Artifacts and versions | DCAT resources and PROV entities; artifact/version directions are inverses. | One artifact per version; reciprocal links; at most one current version and identifier. | Current does not mean latest in every branch or ordering. |
| Signals, proposals, decisions, assessments | PROV entities; support and contradiction are influences; decisions derive from proposals. | Evidence, baseline agreement, qualified authority, outcome, and time. | Evidence does not entail proposal; acceptance does not entail realization. |
| Review, realization, comparison | PROV activities using and generating lifecycle entities. | Required inputs/outputs and cross-record agreement. | Generation does not entail publication or completeness. |
| Operations and realized changes | PROV entities classified by open SKOS concepts. | One kind and at least one affected resource or exact target. | Similarity does not establish planning correspondence. |
| Controlled values | SKOS concepts in open schemes; profile values may be narrower. | Preferred label and scheme membership. | The schemes are not closed OWL enumerations. |
| Term | Role |
|---|---|
ae:GovernedArtifact | Continuing governed artifact identity. |
ae:ArtifactVersion | Immutable artifact version. |
ae:EvolutionSignal | Evidence-bearing review signal. |
ae:ChangeProposal | Proposed operations relative to a baseline. |
ae:ChangeOperation | One proposed change component. |
ae:ChangeDecision | Qualified decision record. |
ae:ImpactAssessment | Evidence-backed impact conclusion. |
ae:ChangeReview | Review activity generating decisions. |
ae:ChangeRealization | Implementation activity generating a version. |
ae:ArtifactComparison | Comparison activity generating a change set. |
ae:ComparisonRegime | Reusable plan governing comparison scope and behavior. |
ae:ChangeSet | Possibly empty observed delta between two versions. |
ae:RealizedChange | One observed change. |
ae:SignalKind | Extensible signal-kind concept. |
ae:ChangeKind | Extensible change-kind concept. |
ae:DecisionOutcome | Extensible decision outcome. |
ae:CompatibilityImpact | Extensible compatibility conclusion. |
ae:ComparisonCoverage | Extensible comparison-coverage status. |
| Term | Role |
|---|---|
ae:hasArtifactVersion | Artifact to immutable version. |
ae:versionOfArtifact | Version to continuing artifact. |
ae:currentArtifactVersion | Publisher-designated current version. |
ae:versionIdentifier | Comparable version token. |
ae:concernsArtifact | Continuing artifact in scope. |
ae:baselineVersion | Immutable baseline. |
ae:resultVersion | Immutable later result. |
ae:hasSignalKind | Signal classification. |
ae:supportedBy | Supporting evidence. |
ae:contradictedBy | Contradicting evidence. |
ae:hasOperation | Proposal operation. |
ae:hasChangeKind | Operation or realized-change kind. |
ae:affectsResource | Affected resource. |
ae:affectsStatementTarget | Affected exact RDF target. |
ae:decidesProposal | Decision's proposal. |
ae:hasDecisionOutcome | Qualified outcome. |
ae:supersedesDecision | Explicit decision supersession. |
ae:assessmentSubject | Impact assessment subject. |
ae:hasImpactAssessment | Qualified impact assessment. |
ae:hasCompatibilityImpact | Assessed compatibility. |
ae:confidenceAssessment | Structured confidence. |
ae:realizesProposal | Proposal used by realization. |
ae:implementsOperation | Operation implemented. |
ae:generatedArtifactVersion | Version generated by realization. |
ae:generatedChangeSet | Change set generated by comparison. |
ae:usesComparisonRegime | Declared plan used by a comparison. |
ae:coverageStatus | Complete, partial, or indeterminate comparison coverage. |
ae:coverageDescription | Actual partial scope or unresolved coverage condition. |
ae:hasChange | Change-set membership. |
ae:realizesOperation | Observed change to proposed operation. |
ae:plannedByProposal | Observed change to planning proposal. |
ae:SignalKinds,
ae:ChangeKinds,
ae:DecisionOutcomes, and
ae:CompatibilityImpacts, and
ae:ComparisonCoverages
are open SKOS concept schemes. Profiles and domains may add narrower
concepts without changing the core values.
Signal kinds are ae:ValidationFailureSignal,
ae:MappingLossSignal,
ae:CompetencyGapSignal,
ae:ResidualPatternSignal,
ae:UsageDriftSignal,
ae:EvidenceConflictSignal, and
ae:StaleEvidenceSignal.
Core change kinds are ae:Addition,
ae:Removal,
ae:Replacement,
ae:Modification, and
ae:Deprecation.
Decision outcomes are ae:Accepted,
ae:Rejected,
ae:Deferred,
ae:NeedsRevision,
ae:Withdrawn, and
ae:Superseded.
Compatibility impacts are ae:BackwardCompatible,
ae:ConditionallyCompatible,
ae:BackwardIncompatible, and
ae:UnknownCompatibility.
Comparison coverage statuses are
ae:CompleteCoverage,
ae:PartialCoverage, and
ae:IndeterminateCoverage.
Complete coverage is always relative to the declared comparison regime;
it is not a universal claim that all semantic consequences were compared.
ae:GovernedArtifactProfile
is the artifact-neutral completeness layer. It requires the artifact and
immutable version relationship, evidence-bearing proposals, attributable
and time-qualified decisions, traceable realizations, and explicit
comparison endpoints. It does not require an RDF, schema, or ontology artifact.
ae:SemanticArtifactProfile
profiles ae:GovernedArtifactProfile. It requires MOD semantic-artifact
typing, structured confidence and impact assessments, and change kinds
appropriate to machine-readable or human-readable semantic contracts.
It applies to schemas, SHACL graphs, mappings, profiles, controlled
vocabularies, and ontologies; it does not require owl:Ontology.
ae:SemanticChangeKinds
contains validation strengthening and weakening, profile-requirement,
mapping, human-semantics, and publication-metadata changes. Narrower
artifact profiles MAY define more specific schemes and concepts.
ae:OntologyEvolutionProfile
profiles ae:SemanticArtifactProfile and requires governed artifacts
to be OWL ontologies. Proposed operations and realized changes MUST use
ontology-specific kinds, inherited semantic kinds, or narrower extension
kinds. Proposed and realized axiom additions, removals, and modifications
MUST identify exact statement targets.
The ontology-specific kinds cover public-term addition, deprecation, and replacement and axiom addition, removal, and modification. Validation, profile, mapping, human-semantics, and publication changes are inherited from the semantic-artifact profile. A public IRI MUST NOT be silently assigned a different meaning; deprecation and migration preserve history.
The profile does not make an accepted operation true, edit the base ontology, close the SKOS schemes, or choose an authority. It adds validation obligations over data using the base vocabulary.
ae:OntologyChangeKinds
contains the ontology-specific concepts below.
ae:PublicTermAddition,
ae:PublicTermDeprecation, and
ae:PublicTermReplacement
govern stable public-term lifecycle. Deprecation retains identity;
replacement requires a distinct target and migration semantics.
ae:AxiomAddition,
ae:AxiomRemoval, and
ae:AxiomModification
cover asserted RDF/RDFS/OWL contract changes and therefore require exact
statement targets.
ae:ValidationStrengthening
rejects or warns about graphs previously accepted, while
ae:ValidationWeakening
accepts graphs previously rejected or lowers severity. Neither is
reducible to adding or removing one triple without considering the
selected validation regime.
ae:ProfileRequirementModification,
ae:MappingModification,
ae:HumanSemanticsModification, and
ae:PublicationMetadataModification
distinguish contract surfaces whose consequences require different
comparison methods. They belong to the inherited
ae:SemanticChangeKinds scheme and remain valid in the ontology
profile. Extension-owned concepts may specialize either semantic or
ontology-specific kinds through skos:broader.
Base shapes require matching artifact baselines, targeted operations, attributable time-qualified decisions, same-artifact distinct comparison endpoints, and agreement between comparisons and generated change sets. These are validation requirements, not OWL cardinalities. OWL supplies only term typing and the genuine artifact-version inverse.
A conforming graph may contain several decisions about one proposal. Conflict diagnostics report unresolved disagreement but do not pick a winner. Missing planning links on a realized change remain unknown under the open-world assumption.
| Record | Intrinsic base requirement |
|---|---|
| Artifact version | Exactly one continuing artifact; at most one comparable version identifier. |
| Proposal | One concerned artifact, one matching baseline, at least one operation, and supporting evidence. |
| Operation | One change kind and at least one affected resource or statement target. |
| Decision | One proposal, one outcome, authority, review activity, and timezone-qualified generation time. |
| Comparison | Distinct versions of one artifact, one regime with a non-empty literal description, one coverage status, an explicit coverage description when incomplete, and one generated change set with matching endpoints and reciprocal generation links. |
| Change set | One artifact and version pair, one matching generating comparison, and zero or more realized changes. |
| Realized change | One kind, an affected target, and membership in a change set. |
RDFS domains and ranges infer types; they are not validation filters. Shared properties such as ae:supportedBy, ae:baselineVersion, and ae:hasChangeKind intentionally omit global domains because several record kinds use them. The OWL addendum declares the genuine inverse between artifact/version directions, but does not encode lifecycle cardinalities, functional decisions, outcome exclusivity, or authority selection.
SHACL conformance proves structural satisfaction under the selected data, shapes, ontology, and inference regime. It does not prove that evidence is truthful, a reviewer was authorized, a declared coverage status is accurate, compatibility was evaluated correctly, or a release was actually published.
Reference diagnostics find accepted non-superseded proposals without a realization, realized changes with no planning links, and conflicting non-superseded decisions. They fail conservatively: absent links are reported as gaps, while authority and compatibility remain explicit assessments rather than query guesses.
This informative diagnostic reports an accepted decision only when it
has not been explicitly superseded and no realization uses its proposal.
The result means no realization is represented
, not
implementation never happened
.
Conflict detection compares distinct non-superseded decisions about one proposal. It reports different outcomes and never ranks their agents. An external governance policy may consume this result to select an authority or require escalation.
A realized change is reported when it has neither ae:plannedByProposal nor ae:realizesOperation. Under the open-world assumption this is a missing planning link, not proof of an unauthorized or accidental change.
Evidence and change records may reveal restricted artifact contents even when the artifact itself is hidden. Access-control systems SHOULD trim proposals, targets, and aggregate change reports against their complete evidence basis before disclosure. This vocabulary records provenance but does not define authorization policy.
An apparently harmless aggregate can also leak information. Reporting that one hidden term was deprecated, that an undisclosed policy acquired a new constraint, or that a restricted proposal has unresolved conflict reveals state about the protected artifact. A disclosure processor SHOULD authorize the complete evidence, target, proposal, decision, and change-set path before exposing either details or counts. An empty or inaccessible evidence basis MUST NOT pass authorization vacuously.
Extensions SHOULD add SKOS concepts or named profiles rather than weaken the core lifecycle. Published term IRIs remain stable; incompatible meanings require new terms, explicit deprecation, and migration or mapping records.
| Need | Extension mechanism |
|---|---|
| A narrower signal, change, decision, or impact value | Add a SKOS concept in an extension-owned scheme and relate it conservatively to a core concept. |
| Stricter completeness for one interchange contract | Publish a named SHACL profile; do not add global OWL cardinalities. |
| Correspondence to a ticket, Git, patch, or domain-change model | Publish a logical alignment or executable mapping with direction, conditions, coverage, and loss. |
| A distinct reusable lifecycle or authority domain | Create a separately governed module rather than expanding this core speculatively. |
Adopted IRIs are stable. A changed meaning requires a new term; the old term is deprecated and connected through an explicit mapping or migration record. A profile may strengthen graph requirements but MUST NOT redefine the base term's open-world meaning.