The Inferal Localization Ontology defines RDF terms for abstract positions, reference frames, and provenance-bearing claims that locate those positions.

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: localization data graph, localization producer, and localization processor.

A localization data graph is an RDF graph that uses the terms defined here consistently with the term definitions, frame resolution rule, and validation expectations below.

A localization producer emits loci, frames, localization claims, or property/datatype frame registry entries.

A localization processor validates, expands, or queries localization data. A conforming processor MUST resolve frames for bare literals using the priority order defined in this specification and MUST keep ordered-frame comparisons inside their ordering contexts.

Namespace

Prefix IRI
loc https://ontology.inferal.com/modules/localization/

Term Index

Term Kind Normative role
loc:Frame Class A reference frame in which subjects can be localized.
loc:Locus Class A stable RDF subject for an abstract position in a frame.
loc:Localization Class An opinion, observation, fix, or judgment locating a locus.
loc:orderedBy Object property Connects an ordered frame to an ord:Ordering.
loc:inFrame Object property Connects a locus to its reference frame.
loc:at RDF property Gives a point value or region value for a locus or localization.
loc:localizes Object property Connects a localization claim to the locus it locates.
loc:defaultFrame Object property Declares the frame for bare literal values of a property.
loc:frameOfDatatype Object property Registers a datatype value space as positions in a frame.

When To Use It

Use an ordinary literal when the property already makes the frame clear enough for consumers. A domain vocabulary can declare loc:defaultFrame on a date, sequence, latitude, longitude, or other position-valued property once, and data using that property does not need a localization node.

Use loc:Locus when the position itself needs a stable identifier. This is common when the value is not known yet, when a range needs to use the position as a bound, or when later data may refine the value without changing the subject being discussed.

Use loc:Localization when a position value is an observation or judgment: a GPS receiver fix, a clock reading, a radiocarbon report, a catalog date, or a scholar's estimate. The localization claim is the resource that carries attribution, derivation, confidence, and review state. Competing claims about the same locus stay separate.

Use a region value when the claim does not identify a single point. For ordered frames, an rng:Range can say that a date, sequence position, or copy-order position lies between two loci. For spatial frames, use geometry vocabularies such as GeoSPARQL to express points or regions.

Model

A loc:Locus is an abstract position. It SHOULD be used whenever a position must remain addressable even when its value is unknown, contested, or later revised. A locus MAY carry one direct loc:at value as shorthand for a single uncontested localization. A locus MUST NOT carry more than one direct loc:at value.

A loc:Localization is the unit of claim. It MUST identify exactly one locus with loc:localizes and MUST carry exactly one loc:at value. Rival opinions about one locus MUST be represented as distinct localization resources so that each claim can carry its own PROV attribution, derivation, timestamp, and confidence assessment.

The value of loc:at determines interpretation. A value denoting a single position places the locus at that position. A value denoting a set of positions, such as an rng:Range over ordered loci or a geometry literal denoting a region, means the position lies within that region. Future value vocabularies can define graded regions without adding new localization properties.

Because loc:at accepts both literals and resources, the OWL addendum MUST NOT type it as either owl:DatatypeProperty or owl:ObjectProperty.

Frame Resolution

For a bare literal used as a localization position, the frame is resolved in this priority order:

  1. the literal itself, when its lexical form embeds a frame, such as a GeoSPARQL WKT literal with a leading CRS IRI;
  2. the property's declared loc:defaultFrame;
  3. the datatype registry through loc:frameOfDatatype;
  4. otherwise the literal is not a resolvable localization value.

The built-in UTC timeline registry maps xsd:dateTimeStamp, xsd:date, xsd:gYear, and xsd:gYearMonth. It intentionally does not map xsd:dateTime, because a timezone-less dateTime is a floating time unless the property supplies a default frame.

Ordered Frames

An ordered frame MAY point to an ord:Ordering with loc:orderedBy. The reference materialization query emits ord:inOrdering for loci in such frames. Loci become comparable through that materialization rather than by a subclass axiom, so loci in unordered frames do not trigger ordering validation.

In an ordered frame, a region-valued loc:at that is an rng:Range MUST use lower and upper bounds that are loc:Locus resources in the same frame as the localized locus. Disagreement among multiple localizations of one locus is not a shape violation.

Examples