Recommendation: Specify that standard_name SHOULD follow CF convention standard names (rather than MUST)

[maxrjones]

I'm working on some examples for GeoZarr v0.4 in advance of Wednesday's WG meeting and chose to start with GPM IMERG. However, I quickly discovered that the data variables do not include CF compliant standard names. Wietze also predicted this would be an issue in the multiscales discussion. I originally interpreted the requirement as standard_names MUST be CF-compliant, but it seems that would be impossible for many transformations from other file formats to Zarr. I think it would help a lot to specify in the spec that while standard_name is required, the alignment with CF_conventions is a SHOULD rather than MUST criteria.

[chris-little]

@maxrjones You might be interested in our experience in developing the OGC API-EDR. We made many aspects optional Recommendations rather than mandatory Requirements. Now that implementations are being developed widely, the developers, and users, are requesting restrictive profiles of the EDR standard. E.g. only using WGS84, or only using specific controlled vocabularies. We are now developing an OGC API-EDR Part 3: Service Profile Support to address this, so you might want to consider something similar in the longer term. HTH.

[ethanrd]

I just wanted to mention that CF is also looking at what it would mean to support alternate variable naming schemes. Several CF standard names folks are involved in the RDA's I-ADOPT working group. The I-ADOPT Framework is an ontology designed to allow interoperability between different variable naming schemes.

Have any GeoZarr folks looked at I-ADOPT?

I-ADOPT == InteroperAble Descriptions of Observable Property Terminology

[christophenoel]

@ethanrd indeed previously proposed defining the standard name property to accommodate multiple variable naming schemes and terminologies, with an optional recommendation for the CF scheme. This appears to be a good compromise.