Zusammenfassung

  • Der W3C-Arbeitsentwurf Semantic Sensor Network Ontology vom 29. September ergänzt sieben Zuordnungen von Navigationsattributen der SensorThings API und ihren Umkehrrichtungen zu SOSA/SSN-Eigenschaften. Die Fassung vom 25. September enthielt bereits Klassenbezüge, aber diese Beziehungstabelle noch nicht.
  • Das Dokument erklärt ausdrücklich, dass sich die Ausrichtung einer JSON-API nicht allein mit OWL/RDFS-Axiomen darstellen lässt. Die neue Tabelle ist eine Entwurfshilfe, kein Transformationsprogramm und kein Nachweis für einen unveränderten Hin- und Rückweg der Daten.

Bei einem Systemwechsel lässt sich ein Typname leicht übernehmen. Schwieriger ist die Frage, ob die Verbindungen zwischen den Datensätzen dasselbe aussagen wie zuvor. Ein Beobachtungswert, der mit dem falschen Objekt verknüpft wird, kann trotz korrekter Klassenbezeichnung irreführend sein. Genau an diesem Punkt erweitert die am 29. September veröffentlichte SSN-Fassung den bisherigen Entwurf. Sie macht eine technische Entscheidung überprüfbar, erledigt sie aber nicht für die Betreiber.

Schon die Ausgabe vom 25. September stellte über OMS eine Verbindung zwischen SensorThings-Entitäten und SSN-Klassen her: Thing entsprach etwa sosa:Platform, Datastream einer sosa:ObservationCollection. Tabelle 17 führt nun die Navigation zum Sensor, zur beobachteten Eigenschaft, zur Plattform und zu den Beobachtungen selbst auf. Hinzu kommen getrennte Verbindungen für ein unmittelbar betroffenes und ein letztlich gemeintes Merkmal. Für jede Zeile ist auch die Gegenrichtung angegeben. Der zugrunde liegende Änderungsvorschlag im W3C-Repositorium wurde am 29. September nach Korrekturen an zwei plattformbezogenen OMS-Verweisen zusammengeführt. Eine neue OGC-Version der SensorThings API folgt daraus nicht.

Die beiden Arten von Untersuchungsgegenstand sind keine Wortklauberei. In einem denkbaren Datenfluss wird eine Probe unmittelbar gemessen, um etwas über ein größeres Ziel zu erfahren. Der Entwurf ordnet ProximateFeatureOfInterest der Eigenschaft sosa:hasFeatureOfInterest und UltimateFeatureOfInterest der Eigenschaft sosa:hasUltimateFeatureOfInterest zu. Würde ein hypothetischer Export beide Verweise zu einem Feld zusammenziehen, könnte eine spätere Abfrage Probe und Ziel verwechseln. Das ist kein Bericht über einen tatsächlichen Produktfehler, sondern ein Beispiel für einen prüfbaren Bedeutungsverlust.

Die Autoren benennen die Grenze ihres eigenen Instruments. SensorThings ist eine JSON-API; ihre Entsprechung in SSN lässt sich nicht durch OWL und RDFS allein axiomatisieren. OMS bietet eine begriffliche Brücke. Welche Quellversion eine Umstellung verarbeitet, wie sie fehlende Links behandelt und wie ein Rückimport verglichen wird, muss eine Implementierung dennoch festlegen. Gleiche Klassen, funktionierende Graphabfragen und ein erfolgreicher HTTP-Aufruf liefern unterschiedliche Belege, aber keinen gemeinsamen Freibrief für semantische Gleichheit.

Der Text bleibt ein Working Draft auf dem Weg zu einer möglichen Empfehlung. Laut Statusvermerk bedeutet die Veröffentlichung keine Billigung durch W3C oder seine Mitglieder; weitere Änderungen sind möglich. Wer Tabelle 17 heute einsetzt, sollte deshalb die verwendete Fassung dokumentieren und die konkreten Beziehungen testen. Ein allgemeines Gütesiegel für Interoperabilität lässt sich aus ihr nicht ableiten.

Quellen