Understanding the OSCAR data model and mapping to standard models

[ACDD-1.3](https://wiki.esipfed.org/Attribute_Convention_for_Data_Discovery_1-3) is a list of attributes, generally for use in NetCDF.

The [README](https://github.com/MeteoSwiss/oscar-nextgen-poc/blob/main/README.md) says:

> ACDD1.3 is a flat structure serialized as JSON objects

I'd like to understand more how MeteoGate/OASIS is using ACDD-1.3 so that I can understand how a mapping to the WIGOS metadata standard (WMDR) might work.

A couple of other things to ponder...

MeteoGate/OASIS provides OGC-API EDR end-points, with query responses encoded as CoverageJSON (and GeoJSON?). MeteoGate are defining a "profile" for OGC-API EDR that defines how the EDR collections are structured and query responses are encoded, including use of CF-names for variables. (@vegark73 to confirm please)

We should consider how well (or not) OGC-API EDR matches the requirements for OSCAR to provide detailed information about observing capabilities.

Also, WMDR has a rich data model originally derived from OGC's Observations and Measurements (now [Observations, measurements, and samples](https://docs.ogc.org/as/20-082r4/20-082r4.html)). Also see [W3C/OGC Semantic Sensor Network Ontology](https://www.w3.org/TR/vocab-ssn/) for another take on this data model.

Is it possible to capture the richness of this model in the flat structures used in MeteoGate/OASIS?

Start with README.md and the ACDD-1.3 description to trace how MeteoGate/OASIS represents metadata as JSON. Compare the referenced OGC API EDR, CoverageJSON, GeoJSON, WMDR, and O&M models, then document whether the current flat structures can represent the required observing-capability detail and what mapping questions remain.

Written by the indexing model from the issue text.