要約

  • W3Cが9月29日に公開したSemantic Sensor Network Ontologyの作業草案は、SensorThings APIのナビゲーション属性と逆方向の関係をSOSA/SSNのプロパティに対応させる7行の表を追加した。9月25日版にあったのは主にエンティティとクラスの対応だった。
  • 草案は、JSON APIとオントロジーの対応をOWL/RDFSの公理だけで表せないと明記する。新しい表は変換を設計する手掛かりであり、実装や相互運用性の認証ではない。

データの移行で、名前が一致することと、関係が保たれることは違う。観測値に「センサー」「プラットフォーム」という正しいラベルが付いていても、測った対象へのリンクが入れ替われば、後で作るグラフの読み方は変わる。W3Cの9月29日版は、そのリンクを議論するための表を加えた。移行責任を規格の発行者へ移したわけではない。

従来の9月25日版は、OMSを橋渡しにしてSensorThingsのThingをsosa:Platformへ、Datastreamをsosa:ObservationCollectionへ結び付けるなど、エンティティの対応を示していた。追加された表17は、センサー、観測対象の性質、プラットフォーム、観測値の所属に加え、近接する対象と最終的な対象を別々の関係として掲げる。各行には逆方向の対応も載る。関連するW3Cの公開リポジトリの変更は、プラットフォーム関連の二つのOMSリンクを修正した上で9月29日に取り込まれた。これはSensorThings APIそのものの新版発行ではない。

近接する対象と最終的な対象を分ける意味は、サンプルを通して別の対象を知ろうとする場面で分かる。表はProximateFeatureOfInterestにsosa:hasFeatureOfInterest、UltimateFeatureOfInterestにsosa:hasUltimateFeatureOfInterestを対応させる。仮にエクスポート処理が両方を一つの汎用フィールドへ畳み込めば、後段の利用者は直接測ったものと推定の対象を区別しにくくなる。実在する製品でそうした不具合が起きたという報告ではなく、移行時に検査すべき損失の例である。

草案自身も境界を引いている。SensorThingsはJSON APIであり、SSNとの整合をOWL/RDFSだけで公理化することはできない。OMSを介した概念上の対応から、どのバージョンを入力とし、欠けたリンクをどう扱い、逆方向の関係をどう出力するかまでは決まらない。クラスの認識に成功したこと、推論器が動いたこと、APIが正常応答したことは、それぞれ異なる証拠だ。

この文書はRecommendationではなくWorking Draftで、公開はW3Cや会員の承認を意味しない。表を版付きの設計資料として使うことはできるが、「変換して戻しても意味が変わらない」という結論を表から直接引くことはできない。実装した組織が、採用した関係の向きと確認できた範囲を説明する必要がある。

出典