Re: GeoDCAT-AP: Call for public review

Many thanks for your feedback, Antoine!

Please find my comments inline.

On Sun, Aug 30, 2015 at 7:33 PM, Antoine Isaac <> wrote:
> Dear Andrea,
> As I'mIt's interesting to see the efforts on data quality. I hope we can
> align the efforts in your domain with the work in the W3C Data on the Web
> Best Practices WG!
> Unfortunately we didn't have time to ive into it a lot already. I've just
> put this as a work item in the next weeks.

Thanks, Antoine. Indeed, for GeoDCAT-AP, ongoing work on the Data
Quality Vocabulary is very much relevant.

Actually, I'm in the process of drafting a mail on this topic for the
DWBP WG. I'll send it shortly.

> In the meantime, I've got a couple of small comments about the current
> GeoDCAT-AP draft. In case they can be useful...
> The first one relates to the questions I've asked about the DCAT-AP draft on
> license [1]. These notions are really hard to manipulate... for GeoDCAT-AP,
> I've noticed that dct:rights has been dropped in favor of using dct:license
> and dct:accessRights alone. Are you sure this is correct?
> As a matter of fact annex II.15 has the example:
> [
> [] dcat:distribution [ a dcat:Distribution ;
>      dct:license [ a dct:LicenseDocument ;
>        rdfs:label "Reuse is authorised according to the European Commission
> legal notice at"@en ] ;
>      dct:accessRights [ a dct:RightsStatement ;
>        rdfs:label "no limitation"@en ] ] .
> ]
> The object of dct:license here could rather be the object of a (more
> general) dct:rights statement. If I was to use dct:license with an instance
> of dct:LicenseDocument, then I'd have put
> [
> [] dcat:distribution [ a dcat:Distribution ;
>      dct:license <>  ;
>         ]
> ]
> which is closer to the GNU example in the DC guide cited in the annex [4].

The motivation behind the current proposal is basically related to the
reference standard.

ISO defines different types of constraints, making a distinction
between access and use - you can find a summary here:

Dublin Core does something similar with dct:license and
dct:accessRights, whereas dct:rights (super-property of both) covers
both access and use.

Said that, it is true that the example we provide could be unclear, so
we have to discuss whether to keep or not. The problem is that the
corresponding "element" in ISO uses free text, so the example reflects
what you typically get when transforming an ISO record into a
(Geo)DCAT-AP one.

Actually, the ISO schema also allows URLs, and some data providers are
currently using this feature to provide the link to the licence
document. So, what we did, is to consider this option in the
GeoDCAT-AP XSLT - i.e., when a licence URL is specified, this is used
as the URI of the licence document.

There's a specific section on this in the XSLT documentation ("Use
conditions / licence URI"):

The document above is also meant to collect and elaborate common /
best practices for the use of HTTP URIs in geospatial metadata, not
limited to licences - something that might be addressed also by the

> Also, while reading the doc, I noticed that the GeoDCAT doc recommends two
> vocabularies for frequencies on p26, the DC one [2] and the MDR one [3],
> while they seem quite redundant, and DCAT-AP recommends only one (the
> latter). The document seem to mitigate this some pages later, but still, it
> could be confusing for readers.

Thanks for pointing this out. Actually, this is a typo that we have to
fix. As you say, the correct recommendation is included in the Annexes
(Annex II.27, pages 43-45) [1]: GeoDCAT-AP recommends the MDR code
list, plus the ISO one, for those values not supported there. In Annex
II.27 (page 44) we have also included a mapping table for frequency
codes, as specified in ISO, Dublin Core and in the MDR register.




Received on Sunday, 30 August 2015 22:50:16 UTC