ObservationCollections

[KevinHaleydt]

There are multiple ways of depicting variation of data in one or more dimensions:

• W3 Cube was referenced in TW1.
• SOSA extensions Observation collections. This has already been added as part of the core model.

The current implementation of SOSA extensions ObservationCollections allows to make aggregations of data in 1 or more dimensions through the use of Feature of interest/ultimate feature of interest, phenomenon time, observed property, sensor, used procedure. The addition of an identifier to the observation collection will also allow any other arbitrary grouping of observations.

Is this enough to group observations? Do we need to add other aggregations?

[KevinHaleydt]

Following up on the issue of the ObservationCollections, this change is already present in the model through the addition of the ObservationCollections. As mentioned in the workshop, we believe the use of ObservationCollections may give more flexibility in slicing observations.

Below you can find different scenario that are possible with the current set-up:

1. General example of using ObservationCollection In this case, all the different observation results all correspond to a collection of the same:

• ObservableProperty
• Procedure
• Time of the observation
• Made by the same sensor

Each of the observations however has a unique results & feature of interest.

2. Using ObservationCollection to show timesereis

It is also possible to use the ObservationCollection to create timeseries. The image above shows how a timeseries is structured through the observationcollection. The collection shares the same ObservedProperty, FeatureofInterest, sensor and procedure.

The unique observations however all have their specific result and phenomenon time.

3. Nested Collections

Going one step further, an ObservationCollection can also be used to nest other ObservationCollections that share the same characteristics.

In the example above, all observations share the same procedure, observer (sensor) and ObservableProperty. However all the observations in Collection OC1, can further be subdivided in two different collections with a different phenomenon time, each of which contains a set of observations on different feature of interests.

PS: For those interested, these examples were taken from the Extensions to the Semantic Sensor Network Ontology source documentation.

[KevinHaleydt]

Further elaboration on this issue: Up till now the question still remained how this relates to qb:slice.

The Cube specs define a slice as: qb:Slice: Denotes a subset of a DataSet defined by fixing a subset of the dimensional values, component properties on the Slice.

Furthermore, the specs give some additional insights in how a slice is used: It is frequently useful to group subsets of observations within a dataset. In particular to fix all but one (or a small subset) of the dimensions and be able to refer to all observations with those dimension values as a single entity. We call such a selection a slice through the cube.

Looking further into Cube, we can see that a slice can be seen as a subclass of an ObservationGroup.

At first glance, this qb:ObservationGroup seems to be similar to the SOSA:ObservationCollection. Looking at their respective definition this is also confirmed: they're both a collection or group of observations

Definitions:

• SOSA:ObservationCollection: Collection of one or more observations, whose members share a common value for one or more property
• qb:ObservationGroup: A, possibly arbitrary, group of observations.

In conclusion:

• ObservationCollection in SOSA corresponds to ObservationGroup in Cube
• A qb:Slice is a subclass of a qb:ObservationGroup

Question to be answered: Do we need to include qb:Slice to the core model as a subclass of ObservationCollection?

[KevinHaleydt]

Resolved during last Thematic workshop