How to standardize dimension types, beyond just convention?

[jkeifer]

Maybe this concern is already addressed within the backing data formats in some way, but this could be an area that makes interoperability difficult. Specifically, how can we enforce consistency in the dimensions so clients can reliably query for data across varying datasets?

One idea here is to not rely on convention and hope data producers use the same dimension names in the same way, but to instead have some metadata specifying the dimensions with a type field. The type could be like the rel field in a link, and provide an indication to the client what the dimension is in a more semantic manner. We can then have a set of common standardized dimension types with URIs that clients could match on to know how to query a given dataset.

I think practice will show if this concern is realized or not. If this is solved by other mechanisms already then we can just close this issue. If not, perhaps the above will be a useful idea, or can kick off a larger conversation to find a better one.

[jkeifer]

One idea that came up in the initial spec development was to borrow the OGC/STAC concept of advertising queryables via a jsonschema object. I decided against this for the initial spec merely to keep the initial revision as simple as possible. It seemed like maybe dataset metadata would provided everything required for the client to derive the queryables and their appropriate formats, so I didn't want to force the requirement of something redundant and unnecessary.

But maybe queryables is not quite redundant? I'm not sure, I think a PoC for both raster and tabular data is required to see how this works in practice. Either way, the queryables pattern would provide an effective means of explicitly advertising the supported dimensions, their types, and the allowed format of values, which is also important on the API side to facilitate request parameter validation and failing fast, to avoid spending cycles trying to resolve chunks using a bad query.