The Inferal Range Ontology defines RDF terms for open, closed, and half-open ranges over ordered comparable resources. It supplies a small generic interval vocabulary that domain modules can reuse for versions, dates, numeric resources, release tracks, policy levels, or other ordered domains represented as RDF resources.

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

Feedback should be sent to contact@inferal.com.

This specification defines three conformance classes: range data graph, range producer, and range evaluator.

A range data graph is an RDF graph that uses terms from this specification consistently with the term definitions and validation expectations below.

A range producer is software or an authoring process that emits range resources, bounds, inclusivity flags, and optional membership assertions.

A range evaluator is software that determines whether an ordered comparable resource belongs to a range. A conforming evaluator MUST implement the membership semantics in or produce equivalent results for every graph with the same comparison closure.

Namespaces

The range namespace imports the Inferal Ordering Ontology [[!INFERAL-ORDERING]]. Bounds and included values are ord:Comparable resources. Literal values such as raw numbers, dates, or strings MUST be represented by comparable resources before they can be used directly as range bounds.

Term Index

Range Model

A rng:Range describes an interval over resources that are ordered by the Inferal Ordering Ontology. The lower and upper endpoints are optional. A missing rng:lowerBound means the range has no lower endpoint. A missing rng:upperBound means the range has no upper endpoint. A range with neither endpoint is unconstrained by this module and may include any ord:Comparable resource.

Inclusivity flags are bound-side metadata. A range MUST state exactly one rng:lowerInclusive boolean when it has a rng:lowerBound, and it MUST NOT state rng:lowerInclusive when the lower bound is absent. A range MUST state exactly one rng:upperInclusive boolean when it has an rng:upperBound, and it MUST NOT state rng:upperInclusive when the upper bound is absent.

A range MAY have at most one lower bound and at most one upper bound. If both bounds are present, they MUST share at least one ord:inOrdering value. A lower bound MUST NOT strictly follow the upper bound in that ordering.

If the lower and upper bounds are the same RDF resource, or are connected by ord:sameRankAs, both inclusivity flags MUST be true. Otherwise the range is empty under the default membership semantics.

Ordering Context

A range does not have its own ordering property. Ordering context is derived from the bounds and candidate values. For a one-sided range, candidate values MUST be compared in the ordering of the present bound. For a two-sided range, the lower bound, upper bound, and candidate value MUST share an ordering. For a fully unbounded range, this module imposes no ordering-context restriction.

Range evaluators depend on strict ordering relations such as ord:follows or inverse ord:precedes, including their specialized comparative and immediate subproperties. If a graph only states adjacent ordering edges, an evaluator SHOULD operate over the ordering closure produced by OWL entailment, SPARQL property paths, or an equivalent graph expansion. If the ordering is partial, a candidate without a strict relation to a required bound does not satisfy that side of the range.

The default semantics in this specification use RDF term identity for equality with a bound and ord:follows or inverse ord:precedes, including their specialized subproperties, for strict ordering. Domain-specific profiles MAY define richer equivalence-class behavior, for example by canonicalizing values that are related by ord:sameRankAs, but such behavior is outside this base module.

Membership Semantics

A candidate value is an ord:Comparable resource being tested for inclusion in a rng:Range. A candidate belongs to a range when it satisfies both the lower-side and upper-side checks below.

The lower-side check passes when no lower bound is present. If a lower bound is present and rng:lowerInclusive is true, the candidate passes when it is the lower-bound resource or when the candidate strictly follows the lower bound. If rng:lowerInclusive is false, the candidate passes only when it is strictly after the lower bound in the shared ordering closure.

The upper-side check passes when no upper bound is present. If an upper bound is present and rng:upperInclusive is true, the candidate passes when it is the upper-bound resource or when the upper bound strictly follows the candidate. If rng:upperInclusive is false, the candidate passes only when the upper bound is strictly after the candidate in the shared ordering closure.

rng:includesValue records the result of that membership evaluation. A producer MAY materialize rng:includesValue triples, and a consumer MAY compute them on demand. A consumer MUST NOT assume that all true memberships have been materialized unless the data source explicitly says that the membership relation is complete.

The following executable query is the reference materialization form for these semantics.

Validation Expectations

A conforming range data graph MUST satisfy the following validation expectations:

• Each rng:Range MAY have at most one rng:lowerBound.
• Each rng:Range MAY have at most one rng:upperBound.
• Each present bound MUST be an ord:Comparable resource.
• Each present rng:lowerBound MUST have exactly one boolean rng:lowerInclusive value, and no lower inclusivity flag is allowed without a lower bound.
• Each present rng:upperBound MUST have exactly one boolean rng:upperInclusive value, and no upper inclusivity flag is allowed without an upper bound.
• When both bounds are present, the two bounds MUST share an ord:inOrdering value.
• The lower bound MUST NOT strictly follow the upper bound.
• A range whose lower and upper bounds are the same RDF resource or are connected by ord:sameRankAs MUST include both bounds.
• Each asserted rng:includesValue value MUST be an ord:Comparable resource that satisfies the lower-side and upper-side membership checks.

These validation expectations are closed-world checks over the supplied data graph and its provided or inferred ordering edges. They do not prove that every possible membership triple is present.

Examples