Limitations of the strict feature collection requirements

[cportele]

The current draft uses a simple mapping of feature data to the feature collections in the API (in particular through /req/pre-defined/spatial-object-type and /req/pre-defined/collection-naming).

This is easy to understand and in many cases straightforward to implement, at least as long as the mapping of the feature data to the INSPIRE application schemas is straightforward, but it also has issues:

Typically, the same dataset now has to be shared via two APIs, one for INSPIRE (following the Good Practice requirements) and one for the existing national users of the data (with a different organisation of the features into collections including different collection ids). Each API would be a separate distribution and needs to be managed.

This has some interesting side-effects. For example, since both APIs share the same dataset, each object in the dataset now has two API URIs, one for each representation (provider schema and INSPIRE schema). For example:

• http://example.org/apis/gebaeude/v1/collections/gebaeude/item/123456
• http://example.org/apis/gebaeude-inspire/v1/collections/building/item/123456

The relationship between the two representations is, in general, lost.

It also continues the separation of the implementation of INSPIRE from the implementation of the national SDI. In addition, it may be confusing for those that are not experts and/or familiar with INSPIRE that the same dataset is shared via two separate APIs (which one should I use?).

One of the possible alternative approaches could be to implement a single API for the dataset and use the (draft) content negotiation by profile spec to select the desired schema. In that case there would be only a single API URI for that building object:

• http://example.org/apis/gebaeude/v1/collections/gebaeude/item/123456

The Accept-Profile header (or an additional query parameter, e.g., profile) could be used to select the provider schema or the INSPIRE schema. Default would typically be the provider schema.

Such an approach, however, has drawbacks, too. The most important one is that negotiation by profile is a new approach and currently not supported by OGC API Features implementations. However, this may change with time and then the current requirements would still enforce that separate APIs have to be published and maintained.

Would it be an option to change /req/pre-defined/spatial-object-type and /req/pre-defined/collection-naming to recommendations (as the approach that is recommended at this point in time) and add a requirement that the mapping of the feature collections to the INSPIRE spatial object types needs to be documented?

[alexanderkotsev]

Thanks @cportele for the interesting point. Content negotiation would indeed be an interesting alternative which would remove the need of a designated implementation of APIs for INSPIRE (i.e. better in order to avoid the possibility for creation of a parallel universe which would hardly be used as much as the original provider API). I also think we should stay away from requirements that are not supported by implementations (we have had issues with similar cases in the past).
The proposal makes sense to me, as it gives us flexibility. Just wondering whether requiring explicitly a mapping to INSPIRE spatial object types would not be too restrictive for non-harmonised data?

[cportele]

Just wondering whether requiring explicitly a mapping to INSPIRE spatial object types would not be too restrictive for non-harmonised data?

Indeed, that should only apply for APIs that "provide data that is harmonised according to the IRs for ISDSS".

[alexanderkotsev]

Sounds good. We can than frame the new req in a manner that is similar to what we currently have for /req/pre-defined/collection-naming, namely:

"For each collection that provides data that is harmonised according to the IRs for ISDSS ...."

Glad to further discuss and confirm that approach within our group.

[thijsbrentjens]

Good point @cportele. I agree that we should avoid as much as possible to duplicate implementations.
Nice approach to use content negotiation.

Another approach (maybe to farfetched, but for the discussion): what if JSON-LD could be used to map the provider schema to the INSPIRE schema? I don't know if it would work for all data specifications, but if a JSON-LD context would contain the mapping, it could be a relatively simple addition to harmonise data, without breaking existing implementations. These implementations would just ignore the JSON-LD context.

Disadvantage: if it can be done, it still would only work for JSON encoded data. And to use the data directly in the harmonised model (so a user would see the properties as defined in the INSPIRE data spec), you still need some kind of tool or code to "rewrite" the data from the provider schema or to present the context to the user somehow (for examle, if data is shown in an application, a tooltip with the INSPIRE property is shown or you could switch between the provider schema and INSPIRE schema without the need to get the data again).

What are your thoughts on this?

[cportele]

@thijsbrentjens - We have also looked at JSON-LD for this in some experiments, but there are additional issues beside the ones mentioned:

• If the provider also wants to "map" the JSON to its own provider vocabulary in a context it is not clear to me how to map the same JSON members to an INSPIRE vocabulary, too.
• This only works in cases where we have a straightforward 1-to-1 mapping between elements in the provider schema and the INSPIRE schema, which often will not be the case.

[thijsbrentjens]

Good arguments not to use JSON-LD for this indeed.

[sgrellet]

@thijsbrentjens : thanks for raising this. This definitely something that needs to be experimented. It's one of the many advantages of JSON-LD contexts. I'm not sure I agree fully with @cportele here. Most of the mapping I've done between national/community models & INSPIRE ones are not so far fetched. That's really worth the try.

[cportele]

@sgrellet - I am not saying that it cannot be done, we have experimented with that, too. My point is that we cannot make this a requirement, because the provider may want to use the context to link the GeoJSON data to some other, non-INSPIRE vocabulary. As far as I know, I can map a JSON member only once in the context.

[sgrellet]

@cportele - not a requirement indeed but a recommendation to start introducing upcoming practices to the INSPIRE community.
We tested the mapping tricks during OGC ELFIE and, you're right we cannot always play with JSON-LD context to move from one content semantics to another
I was also thinking multityping allowed by JSON-LD (rdf:type) may also inform about 'the mapping' between various models
@afeliachi : what do you think ?

[cportele]

Another case where the requirement to use the INSPIRE spatial object type identifiers is where the source dataset has more than one feature type that in an INSPIRE encoding would be mapped to the same INSPIRE spatial object type. The current requirements would require that all these feature types have to be lumped together in the same collection, even if from a user perspective this does not make sense.

Example: The IACS INSPIRE mapping, where multiple IACS feature types are mapped to LandCoverUnit.