Re: GeoDCAT-AP: Call for public review

Hi Andrea,


> 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.


This is great, Andrea, thanks a lot!
I may not have the time to look at it myself in the coming days, but I'm sure it will be of great help to the discussion.


>
>> 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 http://ec.europa.eu/geninfo/legal_notices_en.htm"@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 <http://ec.europa.eu/geninfo/legal_notices_en.htm>  ;
>>          ]
>> ]
>> 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:
>
> https://geo-ide.noaa.gov/wiki/index.php?title=ISO_Constraints
>
> 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.


That's probably the core of the problem: I can understand the distinction between the two levels (license for use and access rights) but the data that you get in the ISO field (with the mixture of free text and URL) would only fit the semantics of the less specific dc:rights. Unless you expunge the free text and just keep the URL, which then fits the use of dcterms:license.


>
> 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"):
>
> https://webgate.ec.europa.eu/CITnet/stash/projects/ODCKAN/repos/iso-19139-to-dcat-ap/browse/documentation/HTTP-URIs.md
>
[...]
>
>> 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.


Alright!

Cheers,

Antoine

Received on Sunday, 6 September 2015 21:35:27 UTC