search

INSPIRE-MIF / gp-ogc-api-features

Good Practice document for INSPIRE download services based on OGC API - Features
13 stars 12 forks source link

Need for OpenAPI extensions for NS metadata elements? #6

Closed michellutz closed 3 years ago

michellutz commented 4 years ago

Would the lightweight mapping of NS metadata elements to OpenAPI proposed in Annex C, i.e. without extensions of OpenAPI terms (terms beginning with ‘x-’ in accordance with the OpenAPI specs), be sufficient?

cportele commented 4 years ago

It is probably obvious, but adding mandatory INSPIRE extensions to the OpenAPI definition is equivalent to the mandatory Capabilities extensions of INSPIRE, so it should be avoided, if possible.

thijsbrentjens commented 4 years ago

Is it required that a mapping for all metadata elements is available? If not, some clarification would be nice.

If it is required, then it would be good if for all elements in Annex C a mapping or statement is available. Such a statement could also be "provided in a separate metadata document" (a bit similar to the 2 scenarios for some service types that refer to ISO metadata documents).

Now the mapping is incomplete, which opens up questions to me. How to map the other elements? What should an API provider do? Is it okay to leave them blank or should they be provided in another way and if so how?

thijsbrentjens commented 4 years ago

Personally, I would avoid OpenAPI extensions.

If there are elements that can be mapped to other OAPIF elements, like to a /collections description, then it would be an option to include them in this mapping too. Even if an element can't be mapped exactly.

For example: Geographic Bounding Box (M) could be mapped to the extent ( /req/core/fc-md-extent in OAPIF), although the OAPIF spec defines the extent on a collection level (while INSPIRE uses one bounxing box for the entire dataset).

heidivanparys commented 4 years ago

This issue is also related to the discussion regarding the linkage simplification.

I would also avoid OpenAPI extension. Input from the group on this issue would be much appreciated.

heidivanparys commented 4 years ago

@alexanderkotsev Can we perhaps add a GitHub label like "waiting for input"? Or change "question" to "waiting for input"?

alexanderkotsev commented 3 years ago

Custom extensions are against the principle of the Good practice, so a minimalist approach is undertaken without using terms other than the ones already defined by the OpenAPI spec.