On how to link CSW records and STA observations

[charlycou]

In the context of Theia/OZCAR information system, solutions are evaluated and tested to implement Theia/OZCAR "pivot model" using SensorThings API and ISO19115 MD_Metadata object. These guidelines represents a first step toward this implementation by documenting a mapping between STA entities and the pivot model "Observation" object. CSW records are used to implement pivot model "Dataset" objects.

The next step is to link both CSW records and STA Observations in order for the user to be able to navigate ;
1 - from a catalog service to resources provided by STA endpoint
2 - from the STA data to ISO19115 MD_Metadata information describing the dataset that STA data belongs to.

1 - From CSW record to STA

The STA endpoint can be referenced using gmd:CI_OnlineResource according to the model proposed by https://github.com/INSPIRE-MIF/gp-data-service-linking-simplification/blob/7447323e73f0d26460241878f6f3c69ad5d76bfa/proposals/JRC/Consolidated_proposal.md

<gmd:CI_OnlineResource>
   <gmd:linkage>
      <gmd:URL>https://api.example/agri4cast/v1.0/</gmd:URL>
   </gmd:linkage>
   <gmd:protocol>
      <gmx:Anchor xlink:href="http://www.opengis.net/def/serviceType/ogc/sta">OGC:STA</gmx:Anchor>
   </gmd:protocol>
   <gmd:name xsi:type="gmd:PT_FreeText_PropertyType">
      <gco:CharacterString>Service OGC SensorThings Agri4cast</gco:CharacterString>
      <gmd:PT_FreeText>
         <gmd:textGroup>
            <gmd:LocalisedCharacterString locale="#FR">Service OGC SensorThings Agri4cast</gmd:LocalisedCharacterString>
         </gmd:textGroup>
         <gmd:textGroup>
            <gmd:LocalisedCharacterString locale="#EN">Agri4cast OGC SensorThings service</gmd:LocalisedCharacterString>
         </gmd:textGroup>
      </gmd:PT_FreeText>
   </gmd:name>
   <gmd:description gco:nilReason="missing" xsi:type="gmd:PT_FreeText_PropertyType">
      <gco:CharacterString/>
   </gmd:description>
</gmd:CI_OnlineResource>

2 - from STA to CSW record

Several solutions are being evaluated but non of them optimally suit the need.

- using a properties property

The CSW record URL could be documented in a properties property of Datastream and MultiDatastream entities. This property structure could be documented using a JSON Schema itself referenced at the SERVICE_ROOT_URI.
Disadvantage: Referencing JSON schema documenting user-defined properties in SERVICE_ROOT_URI is not standard and we don't have example such usage yet. With this solution, we must ensure that the collection of observations represented by Datastream or MultiDatastream only belongs to the Dataset described in the CSW record.

User-defined properties are not allowed on Observation object in v1.1 so the solution above cannot be applied directly to Observation entity.

- using one STA endpoint for each CSW records

This solution involve as many STA endpoints as CSW records. Hence, all observations available behind a STA endpoint belong to the same Dataset described by a CSW record.
Disadvantage: This solution does not address the usecase where a user need to navigate from a STA Observation to ISO19115 MD_Metadata information describing the dataset. Also this solution is more Dataset-centered. For example, Observation sharing the same ObservedProperty won't be easily queriable using STA (since identical entity would be available behind different STA endpoints).

[KathiSchleidt]

From CSW record to STA

Good start for 1:1 mapping between STA:CSW. Question is if more finegrained metadata would be necessary, e.g.:

• All measurements for a specific pollutant: there one could reference the ObsProp
• All measurements on a specific site: reference the Thing
• One type of measurement on one thing: reference the Datastream

from STA to CSW record

User-defined properties are not allowed on Observation object in v1.1
Shouldn't be an issue, Observation has parameters (named differently to align with O&M, but also a JSON_Object, just like the properties. This is why we didn't add additional properties to the Obs under v1.1)

It could be worth proposing an optional "metadata" attribute across STA classes, like available in GML.

HTH!

[charlycou]

Thank you Kathi for your input!

Good start for 1:1 mapping between STA:CSW. Question is if more finegrained metadata would be necessary, e.g.:

In the context of Theia/OZCAR, the STA endpoint in gmd:CI_OnlineResource would be enough if we agree on a method, using STA, to retrieve which collection of observation belongs to the CSW Dataset. Outside of this context, a solution would be to reference a STA query that retrieve all observations from a CSW Dataset, but it is not easy to achieve without additional property on STA entities.

Shouldn't be an issue, Observation has parameters (named differently to align with O&M, but also a JSON_Object, just like the properties.

I didn't catch that one thank you! I was wondering how adding an optional "metadata" attribute would impact the performance though, especially for Observation entities. This optional "metadata" object could be added to the entity set in order to avoid returning the entire metadata object for each observation. I guess that this is similar to what @Mario-35 proposed with https://api.geosas.fr/agri4cast/v1.0/