clarify runtime and design time metadata

[tomkralidis]

cc @ShaneMill1

Provide definitions/discussion on meanings of design time metadata and runtime metadata.

[tomkralidis]

cc @m-burgoyne

[ShaneMill1]

Runtime- EDR core metadata (required)
Design Time- linking out to specific metadata (specific to the domain and optional)

EDR core metadata would align with the OGC-API Records metadata with extension.

• Any application could pick up on this metadata in order to operate.

Design Time would be what we see in a MetOcean best practices in relation to OGC-API Records

• Can add the extra value to the metadata and would be specific to the domain.

Discussed in 10/22/2020 MetOcean DWG

[ShaneMill1]

Discussion 1/21/21 - Pete T.

Need to make it clear that there is metadata for discovery (in finding a collection). But, once you have the collection, we need to be able to describe specifics about the data.

Collection Level Discovery

• An example would be looking for rainfall rate as an observation

Once in the collection:

Specific to the data (geospatial object, and its properties)

• Is the rainfall measured by a rain gauge, is it derived from radar, etc.

This is important for implementation and a decision tree. This is where link relations are important as well. The ability to refer to other records from within a record.

In OGC API Records, there is the ability to do associations which would be useful to leverage here.
OGC API Records supports keywords. @tomkralidis could propose to have "sets" of keywords (such as metoc: keywords).
A set of these keywords could point to a thesaurus.

Can leverage the link relations and/or associations to allow consumers to make a graph or decision tree.

[tomkralidis]

FYI keyword sets proposal in OGC API - Records can be found at opengeospatial/ogcapi-records#70

[tomkralidis]

Update on keyword sets proposal from today's OGC API - Records SWG meeting:

• keywords should remain as a low barrier freeform list of terms/tags without a specific vocabulary/scheme, in support of broad interoperability
• as suggested by the SWG, we could use themes which is part of the core record model like the below (suggested by @pvretano)

"themes": [
    {
       "scheme": "VOCAB1",
       "concepts": ["foo1","bar1","baz1"]
    }
]

I think this would work for our MetOcean BP here, as well as keeping with core OARec.

@chris-little @ShaneMill1 @mburgoyne any objections? Note that there will be some tweaks to OGC API - Records core that I would undertake as a result.

[m-burgoyne]

@tomkralidis I think this provides a good balance between providing specific metadata vocabularies and simplicity.

[chris-little]

@tomkralidis Looks good. So would this be in "Core" and with only one conformance class?

[tomkralidis]

@chris-little yes this would be in core with a conformance class regarding the OGC API - Records record model. We will also add recommendations and examples in the specification to this effort.

[ShaneMill1]

@tomkralidis I think this looks very good as well.

Consensus on 1/28/21 meeting was that this is a good approach forward because it allows us to use OGC-API Records core without needing to create an extension.

Steve Olson brought up supporting authoritative thesaurus or vocabularies. The following example gives a way to do this using a still generic approach.

opengeospatial/ogcapi-records#70 (comment)
(keywords replaced with scheme and concepts)

Another conversation to be had is if we should supply the actual link relations rather than the paths within the concepts.

@tomkralidis will add an example that would represent something from a WMO code list, GCMD example, WIS2 metadata. Could continue to build out examples for different audiences.

[tomkralidis]

Update: first pass examples published to https://github.com/OGCMetOceanDWG/ogcapi-records-metocean-bp/tree/master/core/examples

[ShaneMill1]

Relied heavily on examples provided above to create an example for the existing collection:

https://data-api.mdl.nws.noaa.gov/EDR-API/collections/automated_gfs_100_forecast_time0_lat_0_lon_0_Isobaric_surface_Pa/instances/2021-01-19T00:00:00?f=application/json

Addressed in pull request:
#9