W3C home > Mailing lists > Public > public-dxwg-wg@w3.org > January 2019

RE: dxwg-ACTION-278: Prepare a report about Ine's email and send it to the group

From: <andrea.perego@ec.europa.eu>
Date: Wed, 23 Jan 2019 15:52:32 +0000
To: <public-dxwg-wg@w3.org>
Message-ID: <EDFF15E839F79242AA55B1468C63DDA914DB61AD@S-DC-ESTG02-J.net1.cec.eu.int>
Ine's mail:


I summarise below my understanding of the main points:

1. My interpretation of the 1st point raised by Ine is: fine we have services now in DCAT, but it is important that this change does not affect how things are done by people who don't want / need to have service metadata (i.e., following the DCAT 2014 approach). I think this is quite an important point. We got different feedback on the inclusion of services in DCAT, some supportive, some preferring the "old" DCAT approach. IMO, it is important to include services/APIs in DCAT, as there is enough evidence, also outside the geo domain, that this is a gap which is worth filling. However, this change should not have an impact on who is not planning to use them - and of course should be backward compatible. So, maybe we can think to make this point more explicit.

2. The semantics of the properties linking datasets and services should be unambiguously defined, in order to avoid inconsistent use which may result in reducing interoperability. In particular, Ine identifies some ambiguities in properties used on datasets, distributions, and services (namely, dcat:downloadURL, dcat:accessURL,  dcat:landingPage, dcat:endpointDescription, and dcat:endpointURL), asking clarification on their definitions, and highlighting an inconsistency wrt the INSPIRE definition of access point and end point.

 I think there are 2 points here worth considering while addressing Ine's comments: 

(a) Some of those properties, and the corresponding definitions, are a legacy from DCAT 2014 (the *new* properties are dcat:endpointDescription and dcat:endpointURL). So, changing semantics/definitions may result in breaking backward compatibility

(b) The inconsistency between our notion of endpoint (I mean, as we use it in DCAT) and the INSPIRE one, could possibly be solved by adding a note in the relevant point of the spec saying how our notion of endpoint and the existing properties map to INSPIRE

About point (b):
- In INSPIRE [1], an access point is a URL pointing to the description of a service/API: this corresponds to dcat:endpointDescription
- In INSPIRE [1], an end point is a service/API URL with a set of query parameters which return a dataset distribution in a specific format (CRS, spatial resolution, etc.). I think we discussed this case, and if I remember well the idea is that this can be modelled with dcat:downloadURL, as the URL is a direct link to the distribution (although dynamically generated), and it is irrelevant whether this is obtained by querying a service or downloading a static file from an HTTP / FTP server.
- Property dcat:endpointURL corresponds instead to the base URL of the service / API, without parameters

Ine has some concerns about dcat:endpointURL, as it is a "dead link"  if not instantiated with query parameters. However, we can explain here that this property is meant to be used together with dcat:endpointDescription, which gives a client the necessary information to build the relevant query parameters, and append them to dcat:endpointURL.

3. In relation to issue https://github.com/w3c/dxwg/issues/411, Ine is raising a concern on the actual meaning of the expression "informationally equivalent" in the definition of multiple distributions of the same dataset. Quoting:

The definition of the phrase "informationally equivalent" works only for us if the visual representation of a dataset and the downloaded objects of this same dataset is seen as "informationally equivalent".

About this, I think that the discussion in https://github.com/w3c/dxwg/issues/411 went in the direction of not requiring that multiple distributions of the same dataset must be informationally equivalent. 

4. Ine asks if dct:identifier could be also used for dcat:CatalogRecord, mentioning that, in the geo metadata world - i.e., ISO 19115 -, catalogue records have their own identifiers, which are different from the dataset identifier. I think our answer is yes, but probably we need to be more explicit on this in the DCAT spec. BTW, GeoDCAT-AP includes dct:identifier among the properties of dcat:CatalogRecord. And in case it may be useful for our discussion, a summary of the properties used for catalogue records in DCAT-AP, and related extensions, is here:




[1] http://data.europa.eu/eli/reg/2014/1312/oj 

Andrea Perego, Ph.D.
Scientific / Technical Project Officer
European Commission DG JRC
Directorate B - Growth and Innovation
Unit B6 - Digital Economy
Via E. Fermi, 2749 - TP 262
21027 Ispra VA, Italy


The views expressed are purely those of the writer and may
not in any circumstances be regarded as stating an official
position of the European Commission.

>-----Original Message-----
>From: Dataset Exchange Working Group Issue Tracker
>Sent: Wednesday, January 23, 2019 3:28 PM
>To: public-dxwg-wg@w3.org
>Subject: dxwg-ACTION-278: Prepare a report about Ine's email and send it to
>the group
>dxwg-ACTION-278: Prepare a report about Ine's email and send it to the

>Assigned to: Andrea Perego
>On product: DCAT
>Prepare a report about Ine's email and send it to the group

Received on Wednesday, 23 January 2019 15:52:57 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 April 2019 13:45:06 UTC