- From: Andrea Perego <andrea.perego@jrc.ec.europa.eu>
- Date: Mon, 31 Aug 2015 00:49:33 +0200
- To: Antoine Isaac <aisaac@few.vu.nl>
- Cc: GeoDCAT-AP WG <dcat_application_profile-geo@joinup.ec.europa.eu>, "public-dwbp-wg@w3.org" <public-dwbp-wg@w3.org>
Many thanks for your feedback, Antoine! Please find my comments inline. On Sun, Aug 30, 2015 at 7:33 PM, Antoine Isaac <aisaac@few.vu.nl> 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 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. 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 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 SDW WG. > 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. Cheers, Andrea ---- [1]http://joinup.ec.europa.eu/site/dcat_application_profile/GeoDCAT-AP/GeoDCAT-AP_2015-07-13_6th_WG_Draft/GeoDCAT-AP_Draft_6_v0.39_Annexes.pdf
Received on Sunday, 30 August 2015 22:50:16 UTC