Additional documentation: backgrounds, context and position of the new spec

[thijsbrentjens]

From a discussion with colleagues: it would be nice if there is a bit more context on this new spec, also to help data-providers determining what to do. Such documentation is not part of the spec itself I think (although the scope is to some extent), but there could be a need for some more background.

It could deal with:

• the position of the new spec: is an OAPIF implementation conforming to this spec a fully valid alternative for e.g. ATOM feed and WFS 2.0 Download Service implementations? The Scope section does suggest this, but we had some different interpretations because of the Good practice introduction in the Readme.
• what are benefits/strengths of using OAPIF for INSPIRE, for example: extending the API with some convenience functions (given the coordinates, find the closest address) could be useful for API users
• current limitations, for example: support for other CRSes is not available now, because it depends on an extension that is not final yet
• how this spec relates to other (upcoming) API specs, like OGC API Catalogues ( @cportele are there relevant developments in OGC API Catalogues for this spec?)

[cportele]

@cportele are there relevant developments in OGC API Catalogues for this spec?

@thijsbrentjens - I don't think so. OGC API Records (that is the new name) is basically mainly reusing the building blocks from Features, just for complementary types of data like metadata records in catalogs, codelists and their values, etc. That is, OGC API Records could be useful in other contexts like the registry or discovery services, but I don't see a direct impact on the download service guidance.

[kalxas]

@thijsbrentjens we are currently working on the OGC API Records specification, it would be a good timing to consider INSPIRE requirements in the discussion.
https://github.com/opengeospatial/ogcapi-records

[alexanderkotsev]

For clarity reasons the background and reference to additional specifications such as the OGC API Records can be provided in the README.md instead of the spec itself.

[heidivanparys]

Input from the group is needed: what would the group like to see here? And should it be in the specification itself or in another document (such as the README.md, as suggested by @alexanderkotsev )?

[thijsbrentjens]

I prefer the README.md (or some other doc, but let's start with the README.md) to provide backgrounds / context.

[alexanderkotsev]

Let's indeed start with the README.md. @thijsbrentjens - would you like to propose an outline (e.g. headings and sub-headings) to structure the content.

[thijsbrentjens]

Some first thoughts: use the points from the first comment as a start and extend that a bit:

1. OGC API Features as INSPIRE Download Service --> short intro, like the current README.md is. The spec "in a nutshell": the spec is a guidance on how to implement (valid) INSPIRE Download Services with OGC API Features, it's current status / position in relation to other Download Service types etc (is it a fully valid option to comply to the IR?)
2. Why is this specification drafted? --> Explain trend and background, so: simplification and modernization of INSPIRE infrastructure, next generation OGC specs, APIs.
3. Why use OGC API Features as INSPIRE Download Service? --> benefits / cases where OGC API Features are suitable. And where it may be better to implement other types of Download Service, like WCS for coverages
4. Current limitations --> e.g. CRS support and maybe other issues. And to what extent that may be an issue
5. Examples and resources --> sample implementations, references to the specs and maybe even tooling?

[thijsbrentjens]

What other topics should be in there too? If we have a bit more agreement on the topics, I'm happy to write a first draft

[alexanderkotsev]

I think the proposed structure makes full sense. Thanks @thijsbrentjens for volunteering to prepare the first draft. I think we already have the substance and know the answers of sections 1, 2 and 3. The sections on Current limitations and Examples and resources would, I hope, come from the work of our group, and those should be done at a later stage.

[heidivanparys]

I also think the proposed structure makes sense.

Perhaps a suggestion to extend the number of topics and relate this to the Open Data Directive as well? Does JRC / the Commission have some input here?

From https://ec.europa.eu/digital-single-market/en/european-legislation-reuse-public-sector-information

The Directive introduces the concept of high value datasets, defined as documents the re-use of which is associated with important benefits for the society and economy. They are subject to a separate set of rules ensuring their availability free of charge, in machine readable formats, provided via Application Programming Interfaces (APIs) and, where relevant, as bulk download.

[heidivanparys]

I think we have two target groups:

1. People that are familiar with INSPIRE but not with OGC API - Features and perhaps Web APIs in general.
2. People that are familiar with Web APIs but not with INSPIRE

Perhaps we should keep that in mind when describing the context, as those target groups have different viewpoints.

Perhaps https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=LEGISSUM:l28195 could be used as a reference to a short introduction on INSPIRE for the second target group?

[alexanderkotsev]

I think we have two target groups:

1. People that are familiar with INSPIRE but not with OGC API - Features and perhaps Web APIs in general.

2. People that are familiar with Web APIs but not with INSPIRE

I agree with the evaluation of @heidivanparys , and hope that there is a 3rd category (even if smaller) of people who know OGC APIs and INSPIRE ;) . I think what we should cover is the Open Data Directive because of the envisaged sharing of High-Value datasets through APIs, but also the broader context defined by the European Strategy for data