Should OGC API - Common - Part 1: Core be limited to 1 dataset?

[dblodgett-usgs]

The issues making (breaking) assumptions about the cardinality of "OGC API-endpoint" to "dataset" is growing.

The first statement in the overview of OGC API-Features requirements classes states:

A server that implements this conformance class provides access to the features in a dataset1. In other words, the API is a distribution2 of that dataset. A file download, for example, would be another distribution.

With the following note:

note: Other parts of this standard may define API extensions that support multiple datasets. The statement that the features are from "a dataset" is not meant to preclude such extensions. It just reflects that this document does not specify how the API publishes features or other spatial data from multiple datasets.

I call out those definition urls rather than link to make the point that these are NOT OGC definitions but are rooted in the W3C DCAT definitions.

The current draft does not address this issue of datasets and distribution. Rather, everything references "resource" but "resource" is not defined formally in the document. (see issue #119 for more on resource)

Proposal

Section 8.1.1 should describe the relationship of an OGC API instance to the terms "dataset" and "distribution" rather than an abstract description of OGC API-resources.

[m-mohr]

If it is limited to 1 dataset, it should be made very, very clear and easy to combine multiple datasets.

[dblodgett-usgs]

I feel like the onus to make it easy (let's be real, it's not easy) to combine multiple datasets in one API would be on a future, non-core, Common extension.

The premise is that, until further work on the topic is completed, an OGC API instance is intended to be part of a system of OGC API instances, each for one dataset.

There could always be a higher-level catalog of datasets (each with an OGC API instance) but that is future work and doesn't belong in the core.

[rob-metalinkage]

The problems are:

• choose a single dataset model and things will break and people will do multiple datasets in multiple ad-hoc ways, because thats easier than engaging and developing the necessary extension
• choose a multiple dataset model and the whole thing needs a coherent model for hwat the moving parts are and canonical means to refer to them - making it (perhaps only a little bit) more complex to read, but significantly harder to come to agreement on and test :-(

How about a compromise...

• agree on the single-dataset implementation, but test at least one option for handling multiple datasets at an endpoint as a straw man, and publish that part as a roadmap, but not need to get agreement and fully test all nuances of it, just enough to catch any unnecessary restrictive definitions in the simple model.

[dblodgett-usgs]

That makes some sense @rob-metalinkage but I want to draw this out a little more.

Thinking about this in terms of dataset distribution(s), we have to assume datasets will be distributed by non-OGC API mechanisms an OGC API(s).

Given this, setting up a world where an OGC API represents multiple datasets, we are presuming that:

1. OGC API will provide the catalog of all distributions (OGC API and otherwise) of a dataset, or
2. OGC API will provide hooks for each dataset's distribution to be embedded into external catalogs.

From my perspective, both of those options are problematic. The first sets up a world where we expect people to catalog using OGC API when, likely, people already have a data distribution catalog that they want to use. The second sets up a requirement that the system of OGC APIs can both have an internal catalog and a way to hook into an external catalog -- sounds complicated.

It seems that if we treat an OGC API instance as one distribution of one dataset, we sidestep this issue all together. This leaves open the option for "datasets" that are actually catalogs of metadata -- like OGC API-Records.

[dblodgett-usgs]

This has been clarified in #140. I think what we are saying is that an OGC API IS or can be thought to be a single dataset bade up of many collections of data.

For consistency and clarity, I think we should add something to that affect as is included in Features.

[joanma747]

We are agreed in 2020-11-23 that the core will not say anything about "dataset/datasets". We envision a superlanding-page that links to landing-pages. Both superlanding-page and landing-pages will depen on core and have the 3 common resources (landingpage, conformance and api description)

[cmheazel]

Action for Jerome - document the super landing page approach.

[cmheazel]

Updated definitions and DCAT citation to reference the DCAT Version 3 Editors Draft (dated June 15, 2021):

• Data Service: "A collection of operations that provides access to one or more datasets or data processing functions."
• Dataset: "A collection of data, published or curated by a single agent, and available for access or download in one or more representations."
• Distribution: "A specific representation of a dataset. A dataset might be available in multiple serializations that may differ in various ways"

If we assert that a Web API is a DCAT Data Service, then a Web API MAY support multiple datasets. This means:

1. API-Features can limit implementations to one dataset per API
2. API-Common cannot.

This would be consistent with the resolution of 2020-11-23.

Recomendation: capture the super landing page approach in the Guide, close this issue against collections.

[cportele]

If API Common supports multiple datasets per API, clients should be able to identify which API resources represent a dataset / a distribution.