Which CoverageJSON fragments would make good "building blocks" for re-use

[chris-little]

OGC has a policy for re-usable "building blocks" at various levels of granularity to improve interoperability. @chris-little and @jonblower agreed that a first proposal would be to register the parameter object in the OGC register of building blocks.

The building blocks are organised in these folders: • geo: geospatial building blocks • ogc-utils: Utility building blocks that are used in OGC API's but are not inherently geospatial. They were created to ensure consistency within OGC API's where there was not a clear mainstream standard, and in line with best practices of the web and could be replaced, e.g. by building blocks specified in an IETF RFC or similar, if and when available. API's built with the geo building blocks do not need to use these, but they provide a nice default option that OGC-focused tools will understand. • unstable: These building blocks are not yet stable or mature. They may be extracted from core OGC API standards that have not yet been fully approved, or they may also be new ideas that are not yet in a standard.

Each building block is an AsciiDoc document, whose name follows the convention: PREFIX-NAME.adoc. The prefix is parameter, in the case of parameters, header in the case of headers, and encoding (e.g.: JSON) in the case of data types or resources. This is an example of a building block In addition, please register the building block in the register.json This provides information about the item, using an extension of the ISO19135 schema. All contributions welcomed, as pull requests to this repository

[jonblower]

Is there some potential for confusion here - we are talking about registering the Parameter object, and there is also a parameter prefix (which presumably means URL parameters)?

Would our Parameter be registered as an encoding?

[chris-little]

@jonblower Definitely room for confusion. This occurs in the API EDR standard too. There is parameter at a meta level meaning something in a URL or JSON schema, and parameter meaning a measurement or estimate or observed property of interest. I propose we register the CoverageJSON parameter object, which of course will need the PARAMETER prefix for PREFIX-NAME in the OGC Register.

[chris-little]

@jonblower We could register it as an ogc-util, as it is not inherently geo-spatial (though there is usually an associated spatiotemporal location)

[chris-little]

@jonblower I created a Pull Request in the Building Blocks repo, so at least the proposed CoverageJSON blocks could be named. OGC staff suggested what a full description of a building block should look like:

here's a straw man:

link to specification
description
metadata about governance
link to github container
model (UML)
model (OWL, or at least a formal and stable mapping of concepts to URIs)
JSON schema
JSON-LD context
validator
examples
link to further guidance

[chris-little]

@jonblower @jerstlouis I also suggest that we register some or all of the Domain Objects listed in detail here as building blocks.

[chris-little]

The parameter object and the domain objects have all been registered in the initial OGC Building Block repo. The parameter object will probably move from the Geo folder to the OGC-Utils folder. Can we close this issue, or do we keep it open to track the building bock developments?

[jonblower]

I'd suggest leaving it open as we may well want to come back to this

[chris-little]

Also, the Building Blocks register has just been re-factored. See also shortcut .

[chris-little]

@jonblower Definitely leave it open, as I never finished adding the domain types. In fact I only added one. Plenty of 404s!

[chris-little]

@jonblower There is an issue over adding the Domain Types from CoverageJSON. In the CoverageJSON schemas, the Domain types are nested in a set of dimensions to give flexibility and some compatibility with NetCDF structures. For 'stand-alone' use as a building blocks, these are not necessary, and make use of the domain types such a trajectory, polygon, etc unnecessarily complicated. So if we simplify them and removed the nesting in the schema fragments, they are not really CoverageJSON entities. I don't think that this is a problem.

[jonblower]

Thanks @chris-little - I didn't quite understand the issue here, but maybe someone could suggest a PR against covjson-validator to improve the schemas, if that's what the proposal is?