Allow keywords / tags for collections

[bradh]

WFS 2 supports ows:Keywords entries for "short words to aid catalogue searching."

While this is optional in the WFS 2 interface standard, at least the DGIWG profile makes it mandatory to provide some keywords.

It would be useful to allow something similar (e.g. tags) in OGC API (including OGC API Features) collection descriptions to support catalogues (e.g. CSW) and to support client side filtering of a large list of collections.

In terms of implementation, I'd like to see something like an array of strings:

{
  "links": [...]
  "crs": ["http://www.opengis.net/def/crs/OGC/1.3/CRS84"],
  "name": "lakes",
  "title": "Large Lakes",
  "description": "lakes of the world, public domain",
  "tags": ["lakes", "big lakes", "oversize dams"],
  "extent": [-180, -90, 180, 90]
}

I think keywords would be OK too, but its a bit messy in WFS 2 where keywords are also used for query parameters, and tags is probably more readily understood in modern web development. So less preferred:

  "keywords": ["lakes", "big lakes", "oversize dams"],

[cportele]

Do we have evidence that tags in the JSON and XML encodings would be useful for a broad range of uses so that they should be included in the Core?

For example, I note that STAC (which itself is a catalog) only includes keywords in the collection spec afaik, but keywords are not even used in the examples.

And in general for discovery of data or APIs the focus in the Spatial Data on the Web work was more on supporting search engines (where keywords can be provided in the HTML using meta tags and schema.org annotations).

While adding a "tags"/"keywords" member would be straightforward, I think we should only do this in the Core, if we are convinced that it would make a difference. And I never saw much impact from using "keywords" (or not) in WxS deployments on searches in geoportals, but I may be wrong.

Probably a good topic to discuss at the hackathon.

[pvretano]

@cportele is there anything in the specification that prevents anyone from adding additional keys? An implied '"additionalProperties": true" sort of thing ... If not, then I don't think we need to say anything about "tags" in the core. Actually, we might want to add language that says that other keys are allowed but not specified in this specification...if the core does not already say that. If, in time, we find that the use of the "tags" key becomes popular, we can consider adding it to OGC API - Common (if it has not already done so). Just my 2-cents worth ...

[cportele]

@pvretano - We already allow additional properties ("Additional properties may be added to the schema definition of a Response Object"), which in any case is necessary to keep the core extensible.

[bradh]

I was more thinking about compatibility with CSW (and because my client infrastructure already supports tags...).

My concern with arbitrary additional properties is that its an interoperability problem - should I search for tags, keywords, category (used in Atom), or some other term when building my metadata. What is internal vs intended to be user-visible / user-meaningful?

I can see both sides of not having it in the core. Since we're trying for fairly minimal, perhaps an extension is a better approach at this stage. Given that its about the simplest possible thing you could add, perhaps worth doing as an extension example in any case.

[pvretano]

@bradh as Clemens suggested, we can discuss at the hack-a-thon and if people think it will make a difference it is easy to add. I should add that I am the pro tempore chair of the CAT 4.0 SWG so I am not unsympathetic to additions that support catalogues. :)

[bradh]

I won't be at the hackathon, but I thank you for your efforts on this.

[cportele]

Decision not to add this in the Core, but we leave the issue open for consideration as/in an extension.

[bradh]

Also see https://github.com/opengeospatial/oapi_common/issues/48