How is metadata exposed?

[letmaik]

Apart from the spatial/temporal extents there are typically various metadata information about a coverage, some which also influence how data can be processed/visualized/analysed. It will be hard to devise a common model which suits all applications. What to do instead?

Idea: Use the coverage type for that purpose. E.g. if the type is "http://www.opengis.net/waterml/2.0" (with domain type a standard point series), then the Coverage object could have custom WaterML-related metadata fields which the client then knows how to interpret. This means there should still be a common set of minimal metadata that describes the nature of the data which then allows to process/visualize the coverage.

[letmaik]

Had an idea how to put it together. Even though the coverage type may be used to guide a client to use pre-known hardcoded metadata fields, it is not a flexible approach and will not work well for generic clients. Instead, the JS API could be split up into core data (which corresponds to the fields and functions that are defined now) and other data. The core data can be used to handle coverages in a basic interoperable way. The "other" data is made available via .ld fields in Coverage, Domain, Parameter and possibly other core objects. And .ld is a valid JSON-LD document that can be queried for further data. I imagine that a client could then do var title = jsonld.query(cov.ld, 'http://purl.org/dc/terms/title') (EDIT: see here or here) and similar things. Not sure if a library for querying like that already exists. The advantage of doing it like that is that JSON-LD is used as a generic tool for exposing (meta)data in an interoperable way. No need for "field name" conventions and conflicts depending on coverage types. As long as the metadata is represented properly in any form of JSON-LD, it will work and clients have the chance to understand it.

This idea puts slightly more burden on implementers of the JS API for a given coverage format (which may not be LD-friendly by default), but in the end it will benefit the user. Initially it may also put a slight burden on the user since querying JSON-LD is not established widely, but again, I think this finally solves the problem of not knowing the exact semantics of random JSON fields (without looking up API docs), at least to some degree.

[jonblower]

I don't understand this sentence:

The "other" data is made available via .ld fields in Coverage, Domain, Parameter and possibly other core objects.

What might this look like in practice? Do you mean that .ld is a JSON object within a CoverageJSON document? Or is it a separate document in its own right?

[letmaik]

Remember that the JS API is an abstraction over CoverageJSON. In the case of CoverageJSON, .ld is not manifested as a separate or embedded JSON-LD document. Currently, I derive the .ld field for the coverage object simply by dropping the domain, ranges, and parameters. For WCS or something else that is not LD-friendly, you could imagine that a library translates some non-LD things into the LD world implicitly while reading the data.

[jonblower]

Ah, right, I understand. Sorry, I misunderstood the purpose of the .ld object. Makes sense to me.