Principle #13 – Metadata

[cmheazel]

• This part of the API helps the developer to understand what “the deal is with the resources”
• Use a clear and dedicated endpoint to provide metadata
– clearly different from the resource endpoints
• /v1/metadata or /v1/discover
• Starting with the next level, use URL path structures used for accessing resources
– /v1/metadata/features
– /v1/metadata/features/highways
– /v1/metadata/features/highways/A8
• Allow ‘?’ operator to send selection queries

[uvoges]

Is the metadata not just a representation of a geospatial item, like any other representation (HTML, geoTIFF, ....)
so we would have something like:
/v1/features/highways/A8?format=MIME_TYPE
?

[fhoubie]

I think it should not be at the resource level, but at the featureType / Collection / Layer / ..., so more /v1/features/highways?format=MIME_TYPE no ?

[uvoges]

maybe on both: we have featureType metadata (like EO Collection metadata in GeoDCAT-AP or ISO19139)
Examples (don´t have the mimeTypes..):
/v1/collections/collection4711?format=iso19139-2:xml
and metadata at featureLevel (like EO Product metadata in 10-157 or 17-003)
/v1/collections/collection4711/products/product4812?format=ogc17-003:json

[fhoubie]

Indeed, for coverage data & raster data, it is of course useful, I was just wondering for a feature if it would be useful but the service could return a 404

[cportele]

Why would you require a /metadata path separate from the resources. This is not how I would do it and there is no explanation why the proposal is a good idea or practice. Why not rather add metadata in the path after the resource path (eg /collections/buildings/metadata)?

[securedimensions]

now addressed in master