This issue was raised during the 2nd GeoDCAT-AP WG call of 15 April 2014.
(related issue from the DCAT-AP revision: 138935 - IM2 - How to describe datasets available via services with specific access methods)
Issue: INSPIRE foresees in different kinds of network services (discovery services, view services, download services, transformation services) and other spatial data services (non-invocable, invocable, interoperable). It must be clarified how to encode the descriptive metadata of such services in GeoDCAT-AP Core. The following metadata elements are involved:
- resource type §1.3: This is the type of resource being described by the metadata: series, dataset, or service(s).
- resource locator §1.4 - *On-line resource (O): The resource locator defines the link(s) to the resource and/or the link to additional information about the resource. The value domain of this metadata element is a character string, commonly expressed as uniform resource locator (URL).
- coupled resource §1.6: This element is used to link a service to the target datasets or dataset series, by using the corresponding Unique Resource Identifiers.
The 1st WG Draft of the GeoDCAT-AP (based on the INSPIRE+DCAT-AP alignment work done earlier) provides a mapping, which was discussed as follows:
-
resource type: the resource type of services is represented using an RDF triple setting rdf:type to be dcat:Catalog (defined as 'A data catalog is a curated collection of metadata about datasets.'). This is illustrated by the following RDF Turtle snippet:
[] a dcat:Catalog. This encoding could work for an 'INSPIRE discovery service'. However, in some cases one may prefer to encode services as a dcat:Dataset (see below).
- resource locator: the resource locator is encoded in RDF using foaf:homepage (consistent considering services to be of type dcat:Catalog). However, during the 2nd GeoDCAT-AP WG call of 15 April 2014, it was discussed that this could also be a dcat:landingPage, dcat:accessURL, or dcat:DownloadURL, depending on the type of resource locator (in IS019139 this is indicated by the gmd:CI_OnLineFunctionCode, which can be of values 'download', 'search', 'offlineAccess', and 'information'). In this case, a service is no longer considered to be of type dcat:Catalog, but rather as of type dcat:Dataset or dcat:Distribution. ADDED: See related issue: 142481 - How to encode resource locator?
- coupled resource: only in case services are mapped to dcat:Catalog, the property dcat:dataset could be used for this (consistent considering services to be of type dcat:Catalog).
Comments
Thanks a lot, Stijn, for this comprehensive summary on the issue under discussion.
As far as the "resource type" option is concerned:
The current GeoDCAT-AP proposal for modelling spatial data services is to use dcat:Catalog, plus, optionally, a dct:type predicate, taking as value the relevant URI from the INSPIRE Registry code list of spatial data service types.
The rationale behind the proposal of using dcat:Catalog is that this would allow service metadata to be stored in DCAT-enabled data portals, since the only type of service modelled in DCAT is a data catalogue / catalogue service.
It is however questionable whether there would be the need to store in such data portals service metadata not concerning catalogue services. In one of the issues raised in the framework of DCAT-AP (Details of Distribution) it seems that this should be meant mainly to provide users more details on how to get to the data.
Another open question concerns the drawbacks of squeezing all types of spatial data services into dcat:Catalog. The benefits of this approach are unclear. Moreover, a discussion thread in DCAT-AP, about catalogue nesting, concerns scenarios requiring the use of dcat:Catalog only for services giving access to metadata, and that can be harvested.
Based on these considerations, a possible revision to the GeoDCAT-AP proposal could be as follows:
This solution applies to the extended version of GeoDCAT-AP, and it offers a way to represent all types of metadata records, for use cases needing that. Of course, users would be free to decide whether to represent or not services different from catalogues.
As far as GeoDCAT-AP Core is concerned, the proposal would be to represent metada records concerning just catalogue services, by using dcat:Catalog.
About how to express coupled resources, a possible solution could be:
This is also in line with the defintion of dcat:dataset as a sub-property of dct:hasPart - see http://www.w3.org/TR/vocab-dcat/#Property:catalog_dataset.
A possible "amendment" to the proposal could be the following:
As far as "coupled resource" is concerned, I wonder if using it in case of discovery (catalogue) services makes sense.
In any case, I agree with the proposal.
Hi, Antonio.
About using dcat:Distribution for download services, could you please elaborate on this proposal? In particular, do you mean that the URL of the download service should be specified by using the dcat:accessURL / dcat:downloadURL of a distribution, or rather that the download service itself should be modelled as a distribution?
About the use of coupled resources with a catalogue service, you're right. This should be clarified in the GeoDCAT-AP specification.
Hi Andrea,
I meant that the download services could be modelled as distribution.
But investigating more thoroughly, this solution could imply that we need to add other properties for the mapping with INSPIRE metadata elements.
E.g. for distribution no property allows to connect distribution itself to the related dataset (the opposite is true) and so no property in DCAT-AP could be used for "coupled resource".
At the end, your proposal (use dctype:Service for all the INSPIRE services except discovery services) is best suited.
I agree, Antonio.
+1 for Andrea's proposal to foresee an RDF syntax binding to dcat:Catalog in GeoDCAT-AP Core for discovery services only, as this better matches the definition 'A data catalog is a curated collection of metadata about datasets.' This means that other types of services (view, transformation,...) cannot be represented using DCAT(-AP) elements.
I also agree with using dctype:Service in GeoDCAT-AP Extended to represent services.
During the 3rd WG meeting of 29 April 2015, it was decided that the proposed syntax bindings for GeoDCAT-AP Core and Extended for modelling spatial data services described here above are accepted.
For metadata element 'coupled resource', the following proposal was accepted:
Did we discuss the option not to model services? What aspects of service metadata are relevant for the community we're focussing on to consume this dcat data? I'd suggest to duplicate any of these elements in each of the distributions of the datasets exposed via the service. This is the location the dcat community expects it to be...
Hi, Paul.
Please see my comments inline.
Did we discuss the option not to model services?
Yes, this option was discussed during the GeoDCAT-AP calls, as well as the general question "should we really model all INSPIRE / ISO elements?". And this helped clarifing the scope of GeoDCAT-AP, and its objectives.
The point is that GeoDCAT-AP is not meant to state which elements you MUST map. It simply provides harmonised mappings for (possibly all) elements in INSPIRE and ISO 19115 core, and it is up to you to decide which of them you would like to use. So, if for any reason you have also to model services, you have a recommendation, otherwise you just ignore the mapping.
BTW, there's a table in Appendix I to the GeoDCAT-AP spec, including the list of elements defined in INSPIRE, those in ISO 19115 core, and which of them are supported in DCAT-AP and GeoDCAT-AP. This table can be used to identify which mappings should be used in case you need to be compliant (at the conceptual level, of course) with INSPIRE and/or ISO 19115 core.
Finally, please take into account that services (different from catalogues) are supported only in the GeoDCAT-AP "extended" profile. If you use the "core" profile (the one including alignments only for elements supported in DCAT-AP), services are ignored (with the exception of catalogue / discovery services, which are modelled with dcat:Catalog).
What aspects of service metadata are relevant for the community we're focussing on to consume this dcat data? I'd suggest to duplicate any of these elements in each of the distributions of the datasets exposed via the service. This is the location the dcat community expects it to be...
I guess you're referring to the relevant discussion carried out in the framework of DCAT-AP (Details of Distribution) - just saw the comment you posted there.
Of course, whatever the DCAT-AP WG will decide on this, GeoDCAT-AP will align with that.
Andrea