Add reference to the conceptual model this implements

[jyutzler]

In Section 3, there is a gaping hole – no reference to the conceptual model that this API realizes.

I acknowledge that such a document does not exist today and that rectifying that is out of scope of this effort. (I am in the process of addressing this.) Nevertheless, I would recommend that this document not be adopted as a standard until then.

[cportele]

What conceptual model are you looking for?

This is a very simple Web API for Style resources. In practice, styling is often tool-specific. QGIS, ArcGIS, OpenLayers, MapBox, MapLibre, Cesium/3D Tiles, etc., they all have their own styling language or format - and underlying model what a style is. So has SLD/SE from OGC.

There is now the OGC Symbology Conceptual Model, but intentionally the API does not restrict styles to the recent OGC notion of a style, because in practice one needs to use the styling language of tools that users want to use. That is, the OGC Symbology Conceptual Model cannot be a normative reference, but it probably should be added to the bibliography.

There is an issue with the Style Metadata resource, where one can argue that it is missing a conceptual definition. The current metadata resource is the one that was specified in Testbed 15, but that has not been standardized and the OGC Symbology Conceptual Model does not cover metadata. We could remove any normative statements about the content of the Style Metadata resource until something has been standardized or remove that resource from Part 1: Core altogether.

[jyutzler]

Clemens,

I struggled to make this point to Scott as well. Allow me to try again. I am not talking about SymCore. That is the wrong level of abstraction. What both API Styles and GeoPackage need is a way to access and possibly update the styles that exist in a given repository. However, API Styles is an emerging Implementation Standard and GeoPackage is an Encoding Standard. Implementation of what? Encoding for what? That's why we need a conceptual model.

I believe this is enough of a problem that these proposals are currently not positioned to pass with unanimous consent.

A proper conceptual model would indicate what classes and properties are germane to this domain and would be available as a normative reference to ensure that any standard designed for this domain would be complete, thorough, and consistent.

• Here is the relevant part of the draft GeoPackage extension: http://rbt-gpkg-sprint-ogc-8631a67d386ea6d645dfee87553e7e144502c95ba7a.pages.ogc.org/documents/spec/24-010.html#_styling_requirements
• Here is the relevant part of the draft OGC API Styles API: https://docs.ogc.org/DRAFTS/20-009.html#rc_core

I did a quick crosswalk between the two specifications:

Item	GeoPackage	API Styles
Identifier	gpkg_ext_styles.style	styleId (as a path parameter) or id (as a response property)
Primary key	gpkg_ext_styles.id	No (probably not needed)
Description	gpkg_ext_styles.description	description property of style metadata
URI	For style only	Either style/{styleId} or in link for individual stylesheet
Format	gpkg_ext_stylesheets.format (string)	"Content-Type" header or links[n].type (media type)
BLOB	gpkg_ext_stylesheets.stylesheet	Either style/{styleId} with "Content-Type" header or @links[n].href
Preview	no	Link (preview)
Metadata	Use Metadata extension, no specification for the metadata schema provided	.../style/{styleId}/metadata or Link (describedBy)
Default style	no	yes
Schema	Use Schema extension? Unspecified.	Link (http://.../schema)

Even if I have some inaccuracy in this table, I was alarmed that the two specifications are so different it doesn't look like they are sponsored by the same organization. You have to squint really hard to find the alignment and this will make things more difficult for implementers. There are also opportunities where GeoPackage will want commonality with API Styles but normatively referencing an implementation standard is not appropriate.

[cportele]

@jyutzler

I see, you are looking for a conceptual model for Style resources. Something like https://docs.ogc.org/per/19-023r1.html#Metadata. That model was the starting point for OGC API Styles. Much of what you have in the right column is mapping this to the Web architecture (HTTP, Web Linking, etc.).

It would indeed help, if such a model would be captured in a standard or abstract spec.