Résumé

  • La version du 29 septembre du projet Semantic Sensor Network Ontology ajoute sept correspondances entre attributs de navigation de l'API SensorThings et relations SOSA/SSN, avec leurs sens inverses. Celle du 25 septembre s'arrêtait aux catégories d'entités.
  • Le W3C précise que l'alignement d'une API JSON ne peut pas être formulé par de seules axiomes OWL/RDFS. Le tableau décrit des relations ; il ne valide ni une conversion logicielle ni la conservation intégrale des données.

Une migration peut garder les bons noms et déplacer pourtant la mauvaise relation. Dans les données de capteurs, « capteur », « plateforme » et « observation » sont utiles, mais la chaîne qui les relie dit comment lire la mesure. Le projet publié le 29 septembre par le W3C ajoute précisément cette seconde couche. Il donne aux équipes une grille commune pour discuter des liens SensorThings–SSN, sans se substituer aux essais qu'exige leur système.

La version antérieure rapprochait déjà les entités SensorThings des classes SSN par l'intermédiaire d'OMS : Thing vers sosa:Platform, Datastream vers sosa:ObservationCollection, notamment. Le nouveau tableau 17 associe désormais les navigations vers le capteur, la propriété observée, la plateforme ou les observations à des propriétés et à leurs inverses. Deux lignes supplémentaires séparent l'objet d'intérêt proche de l'objet d'intérêt ultime. La modification a été fusionnée dans le dépôt du groupe le 29 septembre, après correction de deux liens OMS concernant la plateforme. Rien de cela ne constitue une nouvelle version de l'API OGC.

Cette séparation des deux objets d'intérêt mérite une vérification concrète. Un flux peut décrire ce qui a été observé directement et le phénomène plus large auquel la mesure est rapportée. Le tableau distingue sosa:hasFeatureOfInterest de sosa:hasUltimateFeatureOfInterest. Si, dans un exemple hypothétique, un exportateur réduit ces deux relations à une seule, une requête ultérieure pourrait confondre l'échantillon et la cible. Il ne s'agit pas d'un défaut observé chez un fournisseur : c'est la perte d'information que le choix de conversion doit rendre mesurable.

Le texte du W3C contient lui-même la limite de l'exercice. SensorThings est une API JSON ; OWL et RDFS ne suffisent donc pas à formaliser cet alignement. OMS sert de pont conceptuel. Il reste à définir la version de chaque interface, le traitement des liens absents, le sens des relations et la forme du graphe produit. Une application qui reconnaît la bonne classe n'a pas nécessairement préservé les bonnes arêtes, et un aller-retour technique réussi ne se déduit pas d'une réponse HTTP positive.

Le document reste un Working Draft sur la voie des recommandations. Sa publication ne signifie pas que le W3C ou ses membres l'ont approuvé, ni qu'un outil est conforme. L'intérêt du tableau est plus modeste et plus pratique : il rend explicites des décisions que chaque exploitant aurait autrement pu enfouir dans son code de transformation. Citer une correspondance est facile ; prouver que le pipeline la respecte dans les deux sens demeure une responsabilité locale.

Sources