<eposap:operation> update

[epos-eu]

For lexical consistency, can we change, in this file https://github.com/epos-eu/EPOS-DCAT-AP/blob/master/examples/EPOS-DCAT-AP_example.xml at line 235

to ? Operations and actions have a specific meaning in the context of web apis, it would be good to maintain same semantics.

[nmtoken]

Operation seems semantically correct in this example:

https://github.com/epos-eu/EPOS-DCAT-AP/blob/master/examples/WP15/WP15_CSW-EPOS-DCAT-AP.xml

<eposap:operation>GetCapabilities</eposap:operation>

GetCapabilities is an operation of the web service, it isn't an action of the service.

[epos-eu]

eposap:operation purpose was initially to provide a list of actions that the GUI could trigger on a specific web service. e.g. 'download'. 'visualise time-series','visualise image' etc. (should be a button associated to any workflow item or configuration).

GUI developers pointed out that for lexical consistency sake, it was better to provide self explaining XML attributes. That's why I reported this issue here. But of course we can discuss.

About getcapabilities and other operations... everything depends on how we want to handle OGC webservices.

A sort of agreed decision (for the prototype) is that OGS services will not be fully and runtime brokered by the ICS-C. It means that the ICS-C will borker the initial interaction, and then the visualisation of maps (WMS case) will be achieved by connecting the GUI client diectly with the WMS server. In the sense it should be enough to provide a minimal set of information to the GUI...however, as I'm not an OGC services expert, it's not yet clear to me what this "minimal set of information" could be. Do you have ideas or suggestions about it?

[nmtoken]

Logically, it's difficult to see how metadata about a (web) service can know what actions the/any GUI will perform on it. The service can only document (provide metadata about) itself, so it can only know about its own operations, not the actions of the GUI. Alternatively a web service can report what type of service it is (though I see this less as something called operations or actions).

I don't see this as an OGC web services only issue, it applies to all web services.

If we want to go down the what type of service route then my comments in Issue 35 are relevant. The controlled vocabulary is not limited to OGC web services.

[epos-eu]

Yes good point, that's an issue for all webservices, not OGC only. Here some interesting discussion about representation of Webservices in DCAT (work in progress). https://www.w3.org/2017/dxwg/wiki/Use_Case_Working_Space#Modeling_service-based_data_access_.5BID18.5D

We should definitely consider this.

[nmtoken]

In the sense it should be enough to provide a minimal set of information to the GUI .however, as I'm not an OGC services expert, it's not yet clear to me what this "minimal set of information" could be. Do you have ideas or suggestions about it?

Very simply, for any OGC web service, the first request done by a client is a GetCapabilities, the XML response provides enough information for an OGC aware client to know what other requests can be made, on what data, using which coordinate reference systems, with what media types...

We have the endpoint of the service which would typically look like:

http://ogc.bgs.ac.uk/cgi-bin/TFL-PSI/ows?

This is the URL to which all request parameters are appended.

When using HTTP GET requests there is a key[=value]& syntax where the key is case insensitive and the value case sensitive.

A WMS GetCapabilities request has the following mandatory parameters:

service=WMS&
request=GetCapabilities&

The parameters may be specified in any order

A version parameter may also be provided, (like version=1.3.0& or version=1.1.1&). This is a request for a particular version of the WMS specification, and is usually used to override the default version, which is the highest version supported by the service,

The simplest request is therefore [endpoint + service=WMS& + request=GetCapabilities&] or in our example:

http://ogc.bgs.ac.uk/cgi-bin/TFL-PSI/ows?request=GetCapabilities&service=WMS&

For the GUI to be able to display a map (issue a GetMap request to a WMS) it will need to parse the GetCapabilities response.

An example of a GetMap request on the example WMS is as follows:

http://ogc.bgs.ac.uk/cgi-bin/TFL-PSI/ows?language=eng&SERVICE=WMS&VERSION=1.3.0&REQUEST=GetMap&BBOX=43.45170447652554202,13.43180907122941115,43.68037888655367595,13.66128961901322647&CRS=EPSG:4258&WIDTH=854&HEIGHT=851&LAYERS=ITA_Ancona4_ESA_EN_5k_psi_TS,ITA_Ancona3_ESA_EN_5k_psi_TS,ITA_Ancona2_ESA_EN_5k_psi_TS,ITA_Ancona1_ESA_EN_5k_psi_TS&STYLES=,,,&FORMAT=image/png&DPI=96&MAP_RESOLUTION=96&FORMAT_OPTIONS=dpi:96&TRANSPARENT=TRUE&

For the GetMap request the following parameters (key/value combos) are fixed:

SERVICE=WMS&
VERSION=1.3.0& (because we requested this version and now we must use it)
REQUEST=GetMap&

We must also supply the image format we want:

FORMAT=image/png&

Must be one of the formats reported as supported in the GetCapabilities response for the GetMap operation:

`

image/png image/jpeg image/png; mode=8bit application/x-pdf image/svg+xml image/tiff application/vnd.google-earth.kml+xml application/vnd.google-earth.kmz` The layer or layers (data) we want: `LAYERS=ITA_Ancona4_ESA_EN_5k_psi_TS,ITA_Ancona3_ESA_EN_5k_psi_TS,ITA_Ancona2_ESA_EN_5k_psi_TS,ITA_Ancona1_ESA_EN_5k_psi_TS&` From the list of layers... The coordinate reference system: `CRS=EPSG:4258&` From the list of supported CRS: ``` CRS:84 EPSG:4258 EPSG:3034 EPSG:3035 EPSG:3857 EPSG:4326 EPSG:900913 ``` The name of the style we want applied or blank for the default, like: `STYLES=,,,&` The bounding box specified in the Coordinate reference system like: `BBOX=43.45170447652554202,13.43180907122941115,43.68037888655367595,13.66128961901322647&` You can specify any bounding box, but if you want a map you'll need to have a bounding box that intersects the bounding boxes of one or more of your layers. The service itself gives a bounding box, but that is just a hint to the location of the data, and data too may not be continuous across the whole service bounds (especially true for point data sets). Finally you need to specify the width and height of the image you would like returned (in pixels) which should correspond to the width and height of the map interface in the GUI. `WIDTH=854&HEIGHT=851&` GetMap is a required operation of a WMS, other operations may also be available such as GetFeatureInfo. An example of a GetFeatureInfo request for a point on the above map is as follows (note it's giving a time-series response for data at the selected point). http://ogc.bgs.ac.uk/cgi-bin/TFL-PSI/ows?language=eng&SERVICE=WMS&VERSION=1.3.0&REQUEST=GetFeatureInfo&BBOX=43.45170447652554202,13.43180907122941115,43.68037888655367595,13.66128961901322647&CRS=EPSG:4258&WIDTH=854&HEIGHT=851&LAYERS=ITA_Ancona4_ESA_EN_5k_psi_TS&STYLES=&FORMAT=image/png&QUERY_LAYERS=ITA_Ancona4_ESA_EN_5k_psi_TS&INFO_FORMAT=text/html&I=184&J=359&FEATURE_COUNT=10& This is almost identical to a GetMap request, because you are effectively specifying an image coordinate in a map (`I=184&J=359&`) , you need to specify the layers you are querying (`QUERY_LAYERS=ITA_Ancona4_ESA_EN_5k_psi_TS&`) which may be different from the layers used to create the map image, and an output format (`INFO_FORMAT=text/html&`) which is a format advertised as supported by the operation in the GetCapabilities response, such as: ``` text/html application/vnd.ogc.gml text/xml text/plain ``` Similarly a WFS GetCapabilities has the same basic structure like [endpoint + service=WFS& + request=GetCapabilities&]. There is also version negotiation, though the parameter name has changed between versions, let's forget it as it is not simple, so we could have: [http://ogc.bgs.ac.uk/cgi-bin/TFL-PSI/ows?service=WFS&request=GetCapabilities&service=WFS&](http://ogc.bgs.ac.uk/cgi-bin/TFL-PSI/ows?service=WFS&request=GetCapabilities&service=WFS&) ...

[nmtoken]

Here some interesting discussion about representation of Webservices in DCAT (work in progress).

Definitely interesting, and something to consider.

Looking at Existing approaches:

a:Dataset a dcat:Dataset; 
dcat:distribution [ a dcat:Distribution ;
dct:title "GMIS - WMS (9km)"@en ;
dct:description "Web Map Service (WMS) - GetCapabilities"@en ;
dct:license <http://publications.europa.eu/resource/authority/licence/COM_REUSE> ;
dcat:accessURL <http://gmis.jrc.ec.europa.eu/webservices/9km/wms/meris/?dataset=kd490> ;
# The distribution points to a service
dct:type <http://publications.europa.eu/resource/authority/distribution-type/WEB_SERVICE> ;
# The service conforms to the WMS specification
dct:conformsTo <http://www.opengis.net/def/serviceType/ogc/wms> ] .

dct:Type doesn't resolve, but I assume that the natural replacement is indeed http://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceCategory

The dcat:accessURL I see resolves directly to a GetCapabilities response, and specifies a datasetid parameter. I'm not sure how this then dct:conformsTo the OGC WMS specification as it's using non standard parameters.

I think the example confuses data set with service.

[sgrellet]

Triggered by our WP6/7 - WP15 exchanges on that very topic I discussed with Andrea (creator of the Modeling service-based data access [ID18] use case considered in the dxwg). He is highly interested in joining efforts to provide a DCAT-AP description of OGC webservices GetCapabilities response. I that respect I started to add XPath to GetCaps response in WP15 WMS/WFS example EPOS-DCAT-APxml (see #107 ). Just need an extra pair of eyes to stabilize this in an external doc. Note that the mapping from 19139 to DCAT-AP already exists for OGC CSW (https://webgate.ec.europa.eu/CITnet/stash/projects/ODCKAN/repos/iso-19139-to-dcat-ap/browse). As discussed yesterday with Damian we just need to identify the missing information element to map 19139 to EPOS-DCAT-AP

[danielebailo]

This is fixed revised EPOS-DCAT-AP with RDF/turtle serialisation here: https://github.com/epos-eu/EPOS-DCAT-AP/tree/EPOS-DCAT-AP-shapes