create record models extending OARec

[tomkralidis]

Given #1, create OARec metadata models with (say) metoc: extensions foreach defined record type.

[ShaneMill1]

Discussion on 1/21/21:

The metocean metadata profile would be an extension of OGC API Records. The beginning of this profile is being discussed in #1 for using BUFR Table A to begin with.

[chris-little]

@tomkralidis and others. I am a great believer in re-use, and Dublin Core metadata has been around at least 30 years. The original 13 then 15 terms are still valid, but if we look at what terms have been added over the years, we can see where the original set was not detailed enough.
I.E:
Coverage needs to be refined into spatial, temporal, and now vertical!
Date has lots of refinement: valid, available, createdof, issued, modified, etc
Relation has: conformsTo, references, replaces, source, requires, isReplacedBy, isRequiredBy, isPreferredBy, hasPart, isPartOf, hasVersion, isVersionOf, etc.

Plenty of other terms, independent of the orginal 15 too, including 'provenance', 'audience', etc.

There are also several referenced vocabularies to re-use. As well as the usual URI RFC3986, country and language codes, MIME types, there are also DCMI-Box and DCMI-Point.

For time, besides DCMI-Period and ISO8601-1, there are Extended Data Time Format, W3C DTF (but RFC3339 not mentioned)

[tomkralidis]

@chris-little makes sense. We should re-use Dublin Core where possible as our first stop after exhausting options from OGC API - Records Core and EDR schemas.

[tomkralidis]

Some updates following today's discussion:

• removed root bbox property (not in OGC API - Records, not sure why I thought it was [mea culpa])
• added links to ISO 19139 metadata as "rel": "alternate"

Issues for clarification against the OARec record schema:

Geometry CRS

In OARec, the root geometry object is required; structure is referenced/defined at http://schemas.opengis.net/ogcapi/features/part1/1.0/openapi/schemas/geometryGeoJSON.yaml, but has no CRS property per se

Possible option: we could have the BP addmetoc:geometry for other CRSs. Other options?

Extents

In OARec, the root extent object is required (note pending OARec PR to make it optional), and

• does not account for vertical extent
• only accounts for start/end time for temporal extent

Option: we could use the EDR API extent model and cast as metoc:extents in the BP record model. Other options?

Concepts and scheme

We need to clarify how to refer to a vocabulary as well as machine readability (or not)

[tomkralidis]

Should we consider citation as an extended property (see opengeospatial/ogcapi-records#116 for upstream discussion)? i.e. metoc:citation or wmo:bibliographicCitation or dcat:bibliographicCitation ?