epos-eu/EPOS-DCAT-AP

proposal: describe WMS resources by getCapability operation rather than getMap

Opened this issue · 4 comments

kaestli commented

a dcat description of of a wms by the description of its getMap request

  • either requires to have a "data set", a "distribution", a "web service" and a "request" entity for each layer, in order to allow for a detailed description of the layer content, bounding box, etc,
  • or allows only for identical bounding boxes, projections, and return formats for all layers, and the layer ID as only descriptive element of the layer content.

This is clumsy for large, and changing layer sets (imagine shakemap collections, requiring updated metadata each time a new event happens)
It would be much more elegant if just the getCapabilities request is represented in dcat. Guis and services would retrieve the list of available layers, and their description in real time from the getCapabilities service

marc-portier commented

This seems to duplicate #480 ?

As for my 2c on the matter

  • I also see a conceptual overlap between the attempted semantic (hydra) description of webservices - and the self-describing and service-discovery support of the OGC family through getCapabilities -- to some extend there seems to be awareness of this in the OGC community too --> see https://docs.ogc.org/per/16-046r1.html#_rest_api_description_languages
  • still hydra's attempt (and the choice for it by epos) is to overcome the "ogc - only" focus and allow interoperability (beyond the successful but more narrow gis-focussed interoperability of the gis tools using the ogc standards)
  • so while I do feel your pain and acknowledge your rightful question for more convenience - I am not sure it should come from this group, alternatively:
    • we could hope/wait for OGC to see the light and evolve towards some "as hydra" export of their getCapabilities ?
    • we might join forces into a separate / independent handy tool to convert the getCapabilities.xml (and inject additional annotations) to the hydra.ttl that fits this? (would be happy to collaborate)
sgrellet commented

+1 on your 2cents.
That's something we tried to initiate during the EPOS-IP project mapping OGC WMS & WFS GetCaps with Hydra reuse in EPOS_DCAT_AP.
Ideally I would have prototyped an implementation of such mapping in Geoserver (which we highly use here for WMS, WFS and OGC API - Features). I have not been able to push this further (other projects runnings).
I know that @rpaciello worked recently in a equivalent exercise to parse WMS GetCaps outputs to feed the corresponding part in EPOS_DCAT_AP.
Now is maybe a better time fo finalize this ?

nmtoken commented

The older OGC Web Service (OWS) APIs (WMS/WFS/WCS/WPS etc) inherit from OWS Common which dictates only XML output.
The XML response is schema driven (and as such fulfils the REST requirement for APIs driven by hypermedia), so if REST archictecture is the requirement... These APIs are also not bound to any protocol (another REST requirement)

Newer OGC APIs are now being developed / released using JSON. These APIs are bound to the HTTP(s) protocol, and thus fail a REST condition ~ hence they are normally marketed as Web APIs.

nmtoken commented

This proposal seems to fit well with example in DCAT3 for data services ~ https://www.w3.org/TR/vocab-dcat-3/#examples-data-service

like ...

dcat:endpointDescription <http://services.ga.gov.au/gis/services/Judicial_Courts/MapServer/WMSServer?request=GetCapabilities&service=WMS> ;
dcat:endpointURL <http://services.ga.gov.au/gis/services/Judicial_Courts/MapServer/WMSServer> ;