Resumen

  • La edición del 29 de septiembre del borrador Semantic Sensor Network Ontology incorpora siete filas que relacionan atributos de navegación de SensorThings API y sus inversos con propiedades SOSA/SSN. La edición del 25 de septiembre solo ofrecía el puente entre clases de entidades.
  • El propio W3C advierte de que una API JSON no puede alinearse mediante axiomas OWL/RDFS sin más. La nueva tabla orienta el diseño, pero no acredita una transformación, una implementación ni la equivalencia de ida y vuelta.

Si dos sistemas llaman «observación» al mismo tipo de registro, todavía pueden discrepar sobre el objeto observado. La diferencia suele estar en el vínculo que une el registro con el sensor, la plataforma o el elemento de interés. El W3C ha añadido al borrador de su ontología de redes de sensores una tabla que baja precisamente a ese nivel. Es una noticia pequeña en número de filas y considerable para quien mantiene una integración durante años.

Hasta la versión del 25 de septiembre, la sección sobre SensorThings API mostraba principalmente correspondencias de entidades. Pasaba por OMS para asociar, por ejemplo, Thing con sosa:Platform y Datastream con sosa:ObservationCollection. El texto del 29 de septiembre mantiene ese esquema e incorpora la tabla 17: navegación desde el flujo hacia el sensor, la propiedad observada y la plataforma; pertenencia de las observaciones al flujo; y enlaces diferenciados a elementos de interés próximos y últimos. Incluye también la dirección inversa de cada correspondencia. La propuesta del repositorio que añadió la tabla se integró el mismo día, tras corregir dos referencias de plataforma. No es una revisión de la especificación de SensorThings.

La diferencia entre interés próximo y último evita un atajo engañoso. En un caso hipotético, una medición obtenida a través de una muestra puede referirse directamente a esa muestra y, en otro nivel, al objeto que se pretende conocer. La tabla dirige esos vínculos hacia sosa:hasFeatureOfInterest y sosa:hasUltimateFeatureOfInterest, respectivamente. Si una exportación los funde en un solo atributo, una consulta posterior puede perder la distinción. No consta aquí un fallo de producto: se trata de la pregunta que una prueba de migración debería poder contestar.

El borrador no promete una conversión automática. Su propia sección de alineamiento explica que SensorThings es una API JSON y que esa correspondencia no se puede axiomatizar solo con OWL y RDFS; OMS funciona como puente. El equipo que transforma datos debe decidir qué versión del origen acepta, cómo resuelve vínculos ausentes, qué hace con relaciones inversas y qué comparación considera suficiente al reconstruir el resultado. Reconocer una clase, generar un grafo y recuperar la misma semántica son tres resultados distintos.

Además, se trata de un Working Draft. El aviso de estado excluye que su publicación equivalga al respaldo del W3C o de sus miembros, y la tabla aún puede cambiar. Adoptarla como referencia versionada es razonable; presentarla como sello de interoperabilidad o como prueba de un despliegue real no lo es. La autoridad de publicar una conversión útil y sus límites permanece en quien controla esa conversión.

Fuentes