The Inferal Versioning Ontology defines reusable RDF terms for version identifiers, explicit version ordering contexts, numeric component comparison, open and closed version ranges, and materialized range membership. It specializes the Inferal Ordering Ontology [[?INFERAL-ORDERING]] and Range Ontology [[?INFERAL-RANGE]] for version identifiers. It is independent of any one software package, data product, or statement metadata model.

This is an unofficial 0.1 Editor's Draft maintained in the Inferal ontology repository. It is written as a ReSpec source document so it can later be exported as static HTML if the ontology is advanced toward a formal publication process.

Feedback should be sent to contact@inferal.com.

This specification defines three conformance classes: versioning data graph, version ordering processor, and version range evaluator.

A versioning data graph is an RDF graph that uses the terms defined in this specification consistently with the normative requirements below, including the validation expectations in . Machine-readable SHACL artifacts MAY be used to test those requirements, but this specification is the self-contained normative description of the 0.1 validation surface.

A version ordering processor is software that consumes a versioning data graph and derives, validates, or queries ordering relations. A conforming processor MUST respect ordering context isolation and MUST NOT infer comparison edges across distinct ver:inVersionOrdering resources.

A version range evaluator is software that determines whether a version identifier belongs to a version range. A conforming evaluator MUST implement the range membership algorithm in or produce equivalent results for every graph that has the same comparison closure.

Namespace

Prefix IRI
ver https://ontology.inferal.com/modules/versioning/
ord https://ontology.inferal.com/modules/ordering/
rng https://ontology.inferal.com/modules/range/

This specification defines the normative vocabulary and behavior for the namespace above. Implementations MAY publish equivalent machine-readable RDF, OWL, SHACL, or SPARQL artifacts, but readers do not need repository-local files to understand or implement versioning 0.1.

Term Index

Term Kind Normative role
ver:VersionIdentifier Class A comparable version token inside one ordering context; a specialization of ord:Comparable.
ver:ComponentVersionIdentifier Class A version identifier normalized into integer major, minor, and patch components.
ver:VersionOrdering Class A named comparison context for version identifiers; a specialization of ord:Ordering.
ver:NumericComponentOrdering Class An ordering that compares integer major, minor, then patch components.
ver:VersionRange Class An interval over version identifiers; a specialization of rng:Range.
ver:versionText Datatype property The lexical version string supplied by the source system.
ver:versionMajor Datatype property The integer major component of a component version identifier.
ver:versionMinor Datatype property The integer minor component of a component version identifier.
ver:versionPatch Datatype property The integer patch component of a component version identifier.
ver:versionSuffix Datatype property An optional lexical suffix retained for display or provenance.
ver:inVersionOrdering Object property Associates a version identifier with one ordering context.
ver:greaterThanVersion Object property States that the subject version sorts after the object version.
ver:lessThanVersion Object property States that the subject version sorts before the object version.
ver:lowerBound Object property Lower version bound of a range.
ver:upperBound Object property Upper version bound of a range.
ver:lowerInclusive Datatype property Boolean flag stating whether the lower bound is included.
ver:upperInclusive Datatype property Boolean flag stating whether the upper bound is included.
ver:includesVersion Object property Materialized relation from a range to a version inside it.

Version Identifiers

A ver:VersionIdentifier is a resource that represents one version token in one comparison context. A version identifier MUST have exactly one ver:versionText literal. The literal SHOULD preserve the source lexical form, including leading zeros or suffixes when those are significant to the source system.

A version identifier MUST have exactly one ver:inVersionOrdering relation to a ver:VersionOrdering. Two version identifiers are comparable only when they share the same ordering resource. A producer MUST NOT assert ver:greaterThanVersion or ver:lessThanVersion between versions that do not share an ordering.

A ver:ComponentVersionIdentifier is a ver:VersionIdentifier with normalized numeric components. It MUST provide exactly one integer ver:versionMajor, exactly one integer ver:versionMinor, and exactly one integer ver:versionPatch. Authors SHOULD normalize a two-component lexical version such as 1.2 to major 1, minor 2, and patch 0.

A ver:ComponentVersionIdentifier MAY provide at most one ver:versionSuffix. The suffix is not used by ver:NumericComponentOrdering. This module therefore defines a numeric component ordering, not full Semantic Versioning prerelease precedence.

Within one ver:inVersionOrdering, a conforming graph MUST NOT contain two distinct ver:ComponentVersionIdentifier nodes with the same ver:versionMajor, ver:versionMinor, and ver:versionPatch values. Lexical variants such as 1.0 and 1.0.0 are represented by one normalized component identifier, with the chosen source spelling preserved in ver:versionText. Suffix-only variants such as 1.0.0-alpha and 1.0.0-beta also share that tuple in ver:NumericComponentOrdering; use distinct ordering contexts or a profile-specific SemVer ordering when prerelease suffix precedence matters.

Ordering Semantics

ver:greaterThanVersion and ver:lessThanVersion are transitive inverse object properties. If a graph states B ver:greaterThanVersion A and C ver:greaterThanVersion B, an OWL reasoner can infer C ver:greaterThanVersion A.

Ordering edges are strict. A conforming versioning data graph MUST NOT assert or infer a version identifier to be greater than itself or less than itself. A conforming graph MUST NOT contain a cycle in ver:greaterThanVersion or ver:lessThanVersion.

Producers SHOULD state direct adjacent ordering edges when source data already supplies an explicit release order. Producers MAY instead state complete numeric components and apply the numeric component comparison rules below to infer direct comparison edges.

Numeric Component Ordering

A ver:NumericComponentOrdering compares ver:ComponentVersionIdentifier values lexicographically by integer major, then integer minor, then integer patch. The comparison result is independent of ver:versionText formatting and independent of ver:versionSuffix.

For two component version identifiers newer and older in the same ver:NumericComponentOrdering, a conforming version ordering processor MAY infer newer ver:greaterThanVersion older when any of these conditions is true:

  1. newer.major is greater than older.major.
  2. newer.major equals older.major and newer.minor is greater than older.minor.
  3. newer.major equals older.major, newer.minor equals older.minor, and newer.patch is greater than older.patch.

The SWRL rules below encode those three cases. A processor is not required to use SWRL specifically if it produces the same inferred comparison relation.

Version Ranges

A ver:VersionRange is an interval over version identifiers. A range MAY have one ver:lowerBound, one ver:upperBound, both, or neither. A missing lower bound means the range has no lower limit. A missing upper bound means the range has no upper limit.

A range MUST have exactly one boolean ver:lowerInclusive when it has a ver:lowerBound, and it MUST NOT have ver:lowerInclusive when the lower bound is omitted. It MUST have exactly one boolean ver:upperInclusive when it has an ver:upperBound, and it MUST NOT have ver:upperInclusive when the upper bound is omitted. The flags describe whether the corresponding bound is part of the interval.

When a range has both bounds, both bound versions MUST share the same ver:inVersionOrdering. The lower bound MUST NOT be greater than the upper bound. If the lower and upper bound are the same version identifier, both inclusivity flags MUST be true; otherwise the interval is empty and non-conforming.

Range Membership Algorithm

ver:includesVersion relates a ver:VersionRange to a ver:VersionIdentifier that falls inside the range. The relation is not inferred by OWL alone. A conforming version range evaluator MUST evaluate membership over a graph that includes all comparison edges the evaluator intends to rely on, including any OWL transitive closure or numeric component comparison results.

If a range has a lower or upper bound, that bound's ver:inVersionOrdering value determines the ordering context for that side of the range. A candidate version MUST share every ordering context determined by the range bounds. If both bounds are present, the bounds MUST have the same ver:inVersionOrdering value. A fully unbounded range has no ordering-context restriction.

Given a range r and a version v, a conforming evaluator MUST return true exactly when all applicable checks below are true:

  1. If r has a lower bound l, then v is inside the lower side when either v equals l and ver:lowerInclusive is true, or v ver:greaterThanVersion l is present in the comparison closure.
  2. If r has no lower bound, then v is inside the lower side.
  3. If r has an upper bound u, then v is inside the upper side when either v equals u and ver:upperInclusive is true, or u ver:greaterThanVersion v is present in the comparison closure.
  4. If r has no upper bound, then v is inside the upper side.
  5. v is in r when it is inside both the lower side and the upper side.

The following SPARQL CONSTRUCT query is the reference query for materializing ver:includesVersion. Implementations MAY use any equivalent algorithm.

Example: Transitive Dependency Solvability

The Versioning Ontology can be used by package or artifact vocabularies that define dependency edges. The dependency vocabulary below is local to the example: versioning supplies the ordered version identifiers, ranges, and materialized ver:includesVersion facts.

The application has direct requirements on an API, an adapter, and a plugin. The adapter adds transitive requirements: it narrows the API to version 2.5 or later and requires plugin 2.x. A resolver can therefore find a single API candidate that satisfies both API ranges, while also reporting that the plugin requirements are unsatisfiable together.

After a range evaluator materializes ver:includesVersion, the following query walks dependency edges transitively and keeps only candidate versions that satisfy every applicable requirement for the same root package. The output marks ex:api-v2-5 as the only API candidate for ex:application, both adapter 1.x candidates as usable, and ex:plugin as a conflict because no plugin candidate is both 1.x and 2.x. Solvable versions are emitted from the root package so the same candidate can be evaluated differently for another root.

Validation Expectations

A conforming versioning data graph MUST satisfy the following 0.1 validation requirements:

SHACL validation does not replace range evaluation. A graph can conform to these validation requirements and still require an OWL, SWRL, SPARQL, or application pass to materialize comparison closure and ver:includesVersion.