Styles, Tiles: Metadata review

[cportele]

There is significant overlap between the metadata for a style and for a tileset. At the same time, there are issues and differences that should be addressed. And then there are the core queryables from Records.

• "title" and "version" are the same.
• "abstract" vs "description". Proposal: use "description. See opengeospatial/ogcapi-code-sprint-2021-05#31.
• "keywords": Styles uses strings, Tiles a more complex model. Note that Records uses strings for "keywords", too. For controlled vocabularies, "themes" is used. Proposal: restrict "keywords" to strings.
• Styles and Tiles use "pointOfContact", Records uses "contactpoint". Proposal: agree on a single name.
• Styles and Tiles use "accessConstraints" with a fixed list from the intelligence domain. At the same time more generally useful information like "license" is missing. Proposal: add "license" and drop "accessConstraints" (I think this does not belong into Core and communities that need it can always add it).
• Tiles has "publisher", Styles not. Records has it, too. Proposal: add "publisher" to Styles.
• Styles has a fixed "scope" (value "style"), Tiles has no "scope". Records instead has "type", a URI. Proposal: harmonize.
• Styles has various dates in "dates", Tiles in "date". Records only has "created" and "updated", but not embedded in a data type. Proposal: Follow the approach from Records. It is not clear to me where "validTill" or "receivedOn" are really useful for a style or tileset.
• Styles and Tiles both have "layers", but with different content.
  • "abstract" vs "description". Proposal: use "description. See opengeospatial/ogcapi-code-sprint-2021-05#31.
  • Styles has "type" (point, line, polygon, geometry, raster), Tiles has "dataType" (vector, coverage, map) and "geometryType" (points, lines, polygons). Proposal: use "dataType" and "geometryType".
  • Styles has "attributes" (the OpenAPI 3.0 schema for each attribute), Tiles has "propertiesSchema" (a subset of JSON Schema describing an object where each attribute is a property plus some extensions to JSON Schema like "observedProperty" or "uom"). Proposal: Use standard JSON Schema without restrictions. Add a recommendation for a profile, similar to the approach taken by Features for Queryables.

In addition, there are additional properties that are specific to the resource.

Additional comments on the tileset-specific extensions:

• I find the fact that one can specify scaleDenominator, cellSize and/or the tileMatrix confusing. So every client has to be able to handle all of them and convert them to the internal mechanism that the client uses. Why not pick one to make it easier for clients?
• There is "mediaType" as a string, but the description implies that there can be multiple media types. Should this be an array?

[jerstlouis]

• about the scaleDenominator, cellSize, tileMatrix -- I think the guidance is that if one is provided, all of them should be to make it easy for the client.
• about the mediaType, it was originally intended for an offline tileset in a single format I believe. For online it is not required, as the links will include the type.

[ghobona]

Day 3 of 2021-05 Sprint feedback

There is a lot of value in dropping 'accessConstraints' and going with 'license.'

Action: @joanma747 to review the metadata in OGC API - Common, - Maps , -Tiles and to brief on similarities/differences. We can then schedule a common call (multi-SWG) to discuss the findings.

We need to request feedback from Client implementors regarding whether to keep scaleDenominator, cellSize, tileMatrix elements. There are several benefits to keeping all of them.

Recommendation for ETS: If the server provides the scaleDenominator, cellSize, tileMatrix elements, there is value in the ETS checking if they are consistent to a significant number of digits (e.g. at least 12 digits).

[joanma747]

about "keywords" I will only change this in json. The reason is that in UML I use Language string so I need to implement a 0.. of 0.. (the second one is because of the languages). The json encoding does not have this problem.

[joanma747]

About:

Styles has "attributes" (the OpenAPI 3.0 schema for each attribute), Tiles has "propertiesSchema" (a subset of JSON Schema describing an object where each attribute is a property plus some extensions to JSON Schema like "observedProperty" or "uom"). Proposal: Use standard JSON Schema without restrictions.

I understand the value on JSON Schema without restrictions (actually I hate OpenAPI 3.0 for not having a fully compatible JSON schema) but that means that properties in propertiesSchema can be objects and object-of-object-objects. This makes the parsing on this far more sophisticated. Are you sure we want this?.

[cportele]

@joanma747 - The point is that we should not close the door for future use that goes beyond the suggested profile. The current proposal for a profile is also debatable (the same is the case for the queryables), we simply do not have enough experience to know what the sweet spot in terms of simplicity and expressiveness is. A recommendation is much easier to change in a revision once we have more experience without breaking changes, but it gives implementers on the server and client side guidance of what the should provide/expect. Does that make sense?

[joanma747]

"abstract" vs "description". Proposal: use "description. See opengeospatial/ogcapi-code-sprint-2021-05#31.

Adopted in 2DTMS

"keywords": Styles uses strings, Tiles a more complex model. Note that Records uses strings for "keywords", too. For controlled vocabularies, "themes" is used. Proposal: restrict "keywords" to strings.

Adopted in 2DTMS

Styles and Tiles use "accessConstraints" with a fixed list from the intelligence domain. At the same time more generally useful information like "license" is missing. Proposal: add "license" and drop "accessConstraints" (I think this does not belong into Core and communities that need it can always add it).

License added 2DTMS. Waiting for confirmation to remove "accessConstraints"

Styles has various dates in "dates", Tiles in "date". Records only has "created" and "updated", but not embedded in a data type. Proposal: Follow the approach from Records. It is not clear to me where "validTill" or "receivedOn" are really useful for a style or tileset.

Adopted in 2DTMS. Now we only have "created" and "updated",

"abstract" vs "description". Proposal: use "description. See opengeospatial/ogcapi-code-sprint-2021-05#31.

Adopted in 2DTMS

[cportele]

There is also a PR to update OGC API Styles: https://github.com/opengeospatial/ogcapi-styles/pull/29

[ghobona]

@cportele Since OGC API Styles has been updated through PR https://github.com/opengeospatial/ogcapi-styles/pull/29, shall we close this GitHub Issue?

Cc: @joanma747 @jerstlouis

[cportele]

@ghobona - Yes, I think we can.

[ghobona]

Done, thanks.