search

opengeospatial / ogcapi-connected-systems

Public Repository for the Connected Systems SWG
Other
7 stars 6 forks source link

Harmonize ConnectedSystems with the OMSv3 specification #36

Open glennlaughlin opened 5 months ago

glennlaughlin commented 5 months ago

Harmonize the role of the Connected Systems spec as a provider of observations with the role of OMS as a consumer of observations.

There continues to be issues raised related to the concept classes of Observations, Samplings, Platforms, Devices ... etc. Ideally, we would identify in the spec who 'owns' these concepts or at least, we can document how the CS namespace complements or produces the OMS entities of concern.

Would like to raise this in the OMS SWG as an issue for priority review.

glennlaughlin commented 5 months ago

Related to #25

alexrobin commented 5 months ago

This was discussed in the telecon today (01/25/2024) and we had email exchanges as well. Let me copy-paste my email response here for the record.

Email from January 22nd 2024

Hi Sam,

Thanks for your feedback.

Our target has always been to build CONSYS on the models underlying SOSA/SSN. We chose SOSA/SSN rather than OMS for the reasons that I mentioned during our last call. Mainly, this is because SOSA/SSN not only defines the concepts necessary for the observation centric viewpoint, but also for the command/control side (i.e. actuations) and the system viewpoint (i.e. system characteristics and capabilities). The fact that SOSA/SSN is an ontology also gives us more flexibility as to how to use it, and this has proven very useful to integrate it with both GeoJSON and SensorML. For these reasons, I still think SOSA/SSN is the proper target for harmonization.

I have always avoided saying "we implement SOSA/SSN" because SOSA/SSN is an ontology, not a conceptual model, and we're building an API. That's why I like to say that our resource model is based on SOSA/SSN or that we use/reference the semantic concepts of SOSA/SSN. I will keep refining the wording to express all this more clearly.

All we are doing with SOSA/SSN conforms to the semantic model, including having Systems of type Platforms and having Systems that are both Actuators and Sensors. This is all possible with the ontology and is being done in some examples (In RDF, this is simply done by having a concept inherit from two classes simultaneously like so: a ssn:System , sosa:Platform or a ssn:System , sosa:Sensor , sosa:Actuator ;). I will also improve the wording to make this clearer, as well as provide examples of how the same patterns can be implemented using the ontology.

Also, rest assured that we are tracking the latest changes in SOSA/SSN closely and will try to align with it as much as possible. For example, the latest addition of ObservationCollection and ActuationCollection in the ontology will allow us to better document how our DataStream and ControlStream resources are a particular case (i.e. restriction) of these semantic concepts.

Regarding OMS, although we don't implement OMS directly (i.e. we don't define an encoding format for OMS classes), the current alignment between OMS and SOSA/SSN means that there will be a very clear mapping between CONSYS resources and OMS classes. Any data available via CONSYS could be easily presented as OMS once there is a concrete encoding defined for it. In fact, such encoding (let's say a GeoJSON representation for example) could become an alternative format for CONSYS resources.

Finally, I would also like to emphasize that CONSYS is designed to work with multiple representation formats (for systems, observations, commands, etc.), not all of which can/will be complete implementations of SOSA/SSN and or OMS models. Rather, the CONSYS standard mandates that mappings are defined between these formats and the SOSA/SSN concepts.

Hope this helps clarify and let's chat again during our meeting on Thursday, Thanks,