Proposal: SSN-Extensions ontology

[dr-shorthair]

I've drafted a proposal for a small ontology which extends SSN in two directions:

1. Add ObservationCollection class, for sets of observations that share a common (foi|op|sensor|procedure) - aids discovery and also streamlines serialization
2. Add hasUltimateFeatureOfInterest to link an Observation|Sampling|Actuation to the intended subject, useful for cases where a Sample is the proximate feature of interest, to support intentionality and data discovery

The goal would be for this to be issued by the SDWIG as a W3C Note, to supplement the SSN Ontology.

See https://w3c.github.io/sdw/proposals/ssn-extensions/

[lieberjosh]

Could the ObservationCollection class also represent / map to SensorThings:Datastream? Each Datastream links to 1 Sensor, 1 ObservedProperty, and 1 Thing for 0..* Observations (https://ogc-iot.github.io/ogc-iot-api/datamodel.html). It does not presently, however, link directly to 1 FeatureofInterest.

[dr-shorthair]

Yes.

To clarify: the members of an ObservationCollection should share one-or-more of (feature-of-interest|observed-property|sensor|procedure|phenomenonTime|resultTime[|ultimate-feature-of-interest]) .
It is not necessary to share all of them. A collection should be 'homogeneous' on at least one, possibly multiple axes.

[KathiSchleidt]

Then sounds closer to SensorThings MultiDatastream.

[lieberjosh]

Kathi,

That may actually be something that is missing from the ObservationCollection proposal. Neither Datastream nor ObservationCollection provides the complex or arrayed set of results that a Multidatastream does.

An alternative in SensorThings is a dataArray result for an observations request:

"In SensorThings services, users are able to request for multiple Observation entities and format the entities in the dataArray format. When a SensorThings service returns a dataArray response, the service groups Observation entities by Datastream or MultiDatastream, which means the Observation entities that link to the same Datastream or the same MultiDatastream are aggregated in one dataArray.”

Potentially a service implementing ObservationCollection can request an array form of the observation members to an ObservationCollection, but that entity won’t independently have its own dataArray property as a MultiDatastream does. Not sure, of course, whether a MultiDatastream is a better option than the multiple Observations as dataArray response option.

[dr-shorthair]

I generally shy away from anything that looks like 'arrays' when living in the RDF world, as RDF knows pretty much nothing about ordering, so tuples and arrays end up involving hacks. Probably better going to a micro-syntax inside a literal for that. I suggest this is out of scope for SSN.

[lieberjosh]

I’m agreeing that it isn’t necessary to add an array property from STA:Multidatastream to ObservationCollection. It might be useful in API’s based on SSN to provide a response format, e.g. JSON SWE Common for requests of the observation members of a Collection. I’ve also proposed that STA:Datastream add a FoI link to better support sensors fixed on one feature (as well as discovery of which ObservedProperties pertain to a given FoI). —Josh

…

On Mar 23, 2018, at 4:52 PM, Simon Cox ***@***.***> wrote: I generally shy away from anything that looks like 'arrays' when living in the RDF world, as RDF knows pretty much nothing about ordering, so tuples and arrays end up involving hacks. Probably better going to a micro-syntax inside a literal for that. I suggest this is out of scope for SSN. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#7>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AExWhobLeiq6w3wk_m3iV7kWtztYyVdoks5thWCKgaJpZM4S35-N>.

[dr-shorthair]

Clearly there is some interest here. I've also had positive feedback from the geology community about the ultimate-feature-of-interest, particularly in the context of sampling rather than observations, which I had not spotted as such a key use-case!

How to progress this? The technical detail of the proposal is quite mature, but need some compelling examples - preferably not just made-up ones.

[lieberjosh]

There are a number of IoT-inspired examples for ObservationCollection that I could probably help with developing, in the context of alignment with the Sensor Things API model. —Josh

[dr-shorthair]

Could @lieberjosh and @KathiSchleidt write some words about the requirements from / alignment with Datastream?

[dr-shorthair]

The proposal has triggered a Project https://github.com/w3c/sdw/projects/7 so I'll close this issue and we can move on to more atomic issues.

[maximelefrancois86]

Asked some questions during F2F 3 today, happy with this ongoing proposal