Use ObservationCollection to link SOSA to DCAT

[KathiSchleidt]

We've been discussing integrating observational metadata into discovery metadata systems for a while, keep circling about the strengths and weaknesses of the approaches used in the 2 versions of SOS:

• SOS 1.0: offerings listed
  • all ObservableProperties
  • all FoIs
  • all Procedures
• SOS 2.0: offerings listed triples of
  • ObservableProperty
  • FoI
  • Procedure

These approaches both have strengths and weaknesses:

• SOS 1.0: as we just had 3 grab-bags, one often performed queries that didn't return data
• SOS 2.0: all queries return data, but the getCapabilities response was often no longer finite (when dealing with non-timeseries observations, there was an entry for EVERY OBSERVATION)

New idea is using the SOSA: ObservationCollection, as this allows a great deal of flexibility, users can decide which of the approaches from SOS they wish to implement (Collections can be fuzzy or explicit)

[dr-shorthair]

Is this related to the SSN/SOSA ontology design? Or is it rather related to a SSN/SOSA API?

[sgrellet]

I do feel it's more related to 'aligning' (not sure about my terminology here) DCAT-SOSA, at least provide some sort of guidance/best practice on how to answer to the usual use cases : "we want to catalogue observations" / "we want metadata of available observations"

=> 'catalogue' + 'metadata' lead several projects to try and cover this with DCAT only while adding SOSA in an application profile will highly help

[rob-metalinkage]

Its a bit of a no-brainer to imagine an ObservationCollection as a dcat:Dataset. I think a DCAT profile for observations would be appropriate - no impact on SOSA. Where properties overlap (which may be limited to the time aspects?) we may need an alignment - e.g. is dcterms:created equivalent to sosa:resultTime? Generally speaking it seems DCAT provides useful extended metadata for collections - such as dcterms:temporal for the range of times the observations cover.

An informative example probably helps.

[dr-shorthair]

We could also add a note to *Collection documentation noting the interpretation as a dcat:Dataset.

[hylkevds]

We could also add a note to *Collection documentation noting the interpretation as a dcat:Dataset.

possible interpretation... A *Collection is not automatically a dcat:Dataset. A service may end up with millions of Collections. Registering all of those in a catalog will break things.

[sgrellet]

@hylkevds : as Collection can be nested this could still work.

and as Collection can also be collection of one of their members, @dr-shorthair suggestion seems to cover all cases.

Ex, building on Simon's suggestion:

A°/ conceptual level

• one Superset collection (<-> dcat:DataSet) for surface water quality observations
• child collections (<-> dcat:DataSet) corresponding to the various ObservableProperty / Procedure observed which can result in TimeSeries.

B°/ at implementation level we could have all possibilities (depending on UseCase, volumetry, ...)

• B1°/ we could just have the Superset collection in a triple store which could then point to a dcat:DataService (ex : SensorThings API) through a dcat:Distribution
• B2°/ or have both superset and child collections in a triple store but defer to the API for fetching observations
• B3°/ all in a triple store

=> it depends how you instantiate the 'catalogue'

[dr-shorthair]

See https://w3c.github.io/sdw-sosa-ssn/ssn/#OBOE_Alignment_class for a specific pattern of nested collections. Or https://www.w3.org/TR/vocab-ssn-ext/#observation-collection for some patterns that motivated the nesting idea in the first place. These should be carried over into the current document.