Summary

  • The 29 September Working Draft of W3C's Semantic Sensor Network Ontology adds a table matching seven SensorThings API navigation relationships and their inverses to SOSA/SSN properties. The preceding 25 September draft mapped entity types but lacked this relationship table.
  • W3C says a JSON API cannot be aligned with its ontology by OWL/RDFS axioms alone. The table is a design crosswalk, not a completed converter, W3C Recommendation or proof that data can survive an export and return unchanged.

A sensor record can arrive with every expected type label and still lose the answer to a more consequential question: what was actually observed? The newly published table in the 29 September draft makes the links, not just the nouns, part of the conversation. For teams moving data between OGC SensorThings API services and SSN/SOSA graphs, that is a useful advance. It is not a handover of responsibility for the conversion.

The earlier 25 September draft already offered an entity-level bridge through the Observations, Measurements and Samples model. A SensorThings Datastream, for example, aligned to sosa:ObservationCollection; a Thing aligned to sosa:Platform. The new Table 17 goes one level deeper. It identifies navigation attributes and inverse directions for a sensor, observed property, Thing, observations, and two kinds of feature of interest. The repository change was reviewed and merged on 29 September after corrections to two platform-related OMS links. The news is this added relation-level crosswalk, not the invention of SSN or a new SensorThings release.

The distinction between ProximateFeatureOfInterest and UltimateFeatureOfInterest shows why a relation is a governance choice as well as a schema choice. Table 17 associates the former with sosa:hasFeatureOfInterest and the latter with sosa:hasUltimateFeatureOfInterest in a datastream. Consider a hypothetical exporter that collapses both into one generic field. A later graph query might then treat the thing sampled or directly sensed as the underlying target of the observation. No published defect is being alleged; the example identifies information that a migration could discard unless its mapping is tested.

W3C itself marks a limit on what the draft supplies. SensorThings is a JSON API, so its alignment with SSN cannot be expressed as OWL/RDFS axioms. The text uses OMS as a bridge and provides conceptual correspondences. An implementer still has to choose the source API version, link direction, behavior for absent values, graph representation and criteria for comparing an exported result with its original. A class match, an ontology reasoner and a successful HTTP response are three different observations. None alone establishes a faithful round trip.

The publication is a Working Draft on the Recommendation track. Its status text says that publication does not imply endorsement by W3C or its members and that the document can change. A team may use Table 17 as a versioned design input now; it should not cite the table as certification of a product, a mandatory OGC transformation, or proof of live interoperability. The decision to rely on a particular mapping belongs to the operator that ships and maintains it.

Sources