search

opengeospatial / ogcapi-records

An open standard for the discovery of geospatial resources on the Web.
https://ogcapi.ogc.org/records
Other
60 stars 27 forks source link

clarify properties.type #117

Closed tomkralidis closed 3 years ago

tomkralidis commented 3 years ago

From @cholmes on pygeoapi Gitter

I have a question about the 'type'. Is it always 'dataset'? Or is it similar to tiles where it can be map, feature or coverage (but dataset isn't an option there).

Schema definition: https://github.com/opengeospatial/ogcapi-records/blob/master/core/openapi/schemas/recordGeoJSON.yaml#L35-L39

For me, I think of ISO 19115's MD_ScopeCode (prettier view) as a baseline, but I'm not sure we should fix users to use that codelist.

Perhaps some wording around suggested type codelists, while leaving it up to the information community to put forth their own? Or should we lock into a really small set for broad interoperability?

What do folks think? cc @pvretano @cportele @pvgenuchten

pvretano commented 3 years ago

@tomkralidis as the schema says, "the nature or genre of the resource".
It is the type of the resource being described by the catalogue record.

Actually I am just making up these values for type. They should, in fact, be some type identifier from a controlled vocabulary. It is up to a community of interest to define the resource type identifiers they want to use in their community. For OGC, we have issue #26. The goal of that issue is to come up with a set of "official" type identifiers for OGC resources (e.g. collection, feature, coverage, style, OAPIF, WFS, WMS, WCS, etc...).

Agreed about adding some more wording. I'll assign the issue to me to come up with a longer description of the type property.

ghobona commented 3 years ago

A reminder that the MD_ScopeCode codelist from ISO 19115 identifies a series of types e.g. service, dataset, model, tile, etc.

A wiki-page with the codelist is at here.

mhogeweg commented 3 years ago

Types have always been hard in metadata. When downloading a gml file from a web link is that considered a dataset? But what if the gml is the result of an api call? Is it still a dataset or a service?

Many metadata include a link to a GetMap operation but describe the metadata as for a wms service, although one can argue that the link in this case is just to a single png file.

It would be clearer to state the api (WMS, Esri Feature Service, OData, SODA, World Bank Indicators, ...) used by the service being described and use dataset for things that can be accessed without anything but the provided link and only support the access of the dataset in its entirety.

pvgenuchten commented 3 years ago

When downloading a gml file from a web link is that considered a dataset?

This applies if it is the gml export which is the subject of the record. However usually people describe the actual dataset and add the gml export as a distribution option only.

A reminder that the MD_ScopeCode codelist from ISO 19115 identifies a series of types e.g. service, dataset, model, tile, etc.

iso19115 scopecode is a good starting point, but quite limited; All types of api's would need to be clustered in a container of 'service'. Maybe we can recommend scopecode values, but allow to add also alternative types. In that case i'd prefer use of a uri, over a string.

tomkralidis commented 3 years ago

SWG 2021-06-17: leave type enumerations to information communities, provide text in document, provide examples of registries/codelists. Be normative about OGC definitions (go to OGC def server), i.e. point to some in the document as examples.

ghobona commented 3 years ago

Could OGC API - Records simply reference the URIs at http://www.opengis.net/def/standards-baseline ?

Ignore the repetition of items. This is an apparent bug on the User Interface.

Notice that the URIs include the URI for OGC API - Features http://www.opengis.net/def/interface/ogcapi-features

cnreediii commented 3 years ago

As a point of reference, CDB 2.0 (in development) will provide a set of enumerations and controlled vocabularies such as Country Codes (ISO compatible) and a Lights vocabulary. These enumerations/vocabularies are backwards compatible with previous CDB versions but in CDB 2.0 there are requirements stating how these lists can be extended (or replaced if appropriate) in order to meet domain requirements beyond the traditional CDB user base. As CDB specifies rules for a data store I suspect that URIs to external resources will not be mandatory. This is because a CDB data store needs to be fully 100% operational in a disconnected environment. Obviously more to discuss in the CDB SWG :-)

pvretano commented 3 years ago

09-AUG-2021: The recent PR from @cportele (#133) updated the definition of the type property to make it an enumerated list to simplify querying by type. This issue can now be closed as the only outstanding item it to propose and informative list of type values which is being handled in issue #26.