Re: [dxwg] Distribution service [RDISV]

Thanks, @fellahst , for sharing the Geoplatform.gov approach.

It seems that the solution you use is similar to the one developed in Geo/DCAT-AP (illustrated in [UC18](https://www.w3.org/TR/dcat-ucr/#ID18) & [UC20](https://www.w3.org/TR/dcat-ucr/#ID20)), although there are some differences. A full example on how this is done in Geo/DCAT-AP is documented at https://github.com/w3c/dxwg/issues/166#issuecomment-373878749 .

I think it would be nice to see if we can build on both approaches to provide a consolidated solution. I summarise below how this is done in Geo/DCAT-AP, focussing on the issues you mention.

About the similiarities:
- Also in GeoDCAT-AP a service is a first-class citizen, and it is described by a specific metadata record registered in a catalogue.
- We also use `dct:conformsTo` to specify the service / API "protocol"

Services are denoted as `dctype:Service`'s, and the specific service type (discovery, view, etc.) is specified via `dct:type` (i.e., soft typed). The reference code list is the one operated by the [INSPIRE Registry](http://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceType), which provides HTTP URIs for the relevant ISO 19115 code list.

The difference, is that the link to the resources (e.g., datasets) available from a service is specified by using `dct:hasPart` - as explained in #116 .

Coming now to the issue of modelling a distribution pointing to a service, this is done (a) by (soft) typing the distribution (`dct:type`) to specify that the data are available from a service and (b) by specifying the service protocol with `dct:conformsTo` (as done with the service). For a full example, see https://github.com/w3c/dxwg/issues/166#issuecomment-373878749 .

As explained in [UC18](https://www.w3.org/TR/dcat-ucr/#ID18), we also had the issue you mention concerning the fact that a service may give access to more than one dataset, so the question is how to specify the relevant query parameters.

Our aim was to identify a solution able to describe the query interface and parameters for any services (not only geospatial ones) by using a standard mechanism / language, preferably widely supported. In particular, the decision was not to encode in RDF the query parameters, but to link to (or embed in RDF) a separate (XML, JSON, ...) document providing this information.

The preliminary proposal was to use an OpenSearch description document (OSDD). You can find a full description of the approach in the DCAT-AP issue tracker ([DT2: Service-based data access](https://joinup.ec.europa.eu/discussion/dt2-service-based-data-access)).

This idea of using OpenSearch was further discussed ([a bar camp session of the SDSVoc workshop was devoted to it](https://www.w3.org/2016/12/01-sdsvoc-minutes#item17)), and, eventually, it was considered not fit for describing all services. So, the issue was put on hold.

Looking forward for your feedback.

-- 
GitHub Notification of comment by andrea-perego
Please view or discuss this issue at https://github.com/w3c/dxwg/issues/56#issuecomment-375936290 using your GitHub account

Received on Sunday, 25 March 2018 00:46:17 UTC