Closed epos-eu closed 6 years ago
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.
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?
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.
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.
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:
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:
`
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.
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
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
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