How would you solve the following conflicts without loosing information or give wrong information in the communication from CKAN to DCAT? (From DCAT to CKAN is even worse, as we step down in granularity)
granularity conflict:
7: License at distribution level (DCAT) vs. License at dataset level (CKAN)
8: Status at distribution level (DCAT) vs. status at dataset level (CKAN)?
Raised in https://joinup.ec.europa.eu/asset/ogd2_0/issue/dcat-ap#comment-18465
These issues can be resolved - and a reusable solution for the first one already has been created for DCAT-AP-NL. They simply added a property dct:license for datasets and excluded that property from distributions:
We believe that in the vast majority of the case license and rights will be the same for every distribution. In exceptoinal cases, where this is not true, we recommend to define separate distributions [datasets seem to be meant here].
https://docs.google.com/spreadsheets/d/1SPfA6fA9im_6EtxLDBtCMyBpt1q1aXl…
Issue 7 resolved ! (Other solutions within the DCAT-AP framework also exist)
adms:status can be used for datasets: issue 8 resolved !
Comments
Of course we could have used DCAT-AP in this respect and added the licence at dataset level and disallowed usage at ressource level and so on.... but
1) in combination with a closed list of licenses this is a bit too much tweaking of a W3C standard isn't it?
2) main issue why this is a rather long term improvent topic is on the legacy data we have at https://www.govdata.de/ and other portals in Germany following the OGD 1.1 rather CKAN oriented structure.
Depending on the direction of a mapping we have to cope with a granularity gap here, as DCAT-AP is more granular (and also right! ;) ) in this aspect.
OGD->DCAT-AP: One has to invent a not existing licenses at resource level or
DCAT-AP->OGD: One has to chose out of a existing list of resource level licenses the ONE for the dataset
Who will do this for all the 100.000 existing open data sets that have license (only) at dataset level?
---------------------------- German ----------------------------------------------
Hier geht es nicht nur um den Granularitätskonflikt an sich, sondern um eine ganz andere rechtliche Aussage, je nach Kommunikationsrichtung. Natürlich können wir so ein Feld einfach einbauen und das andere verbieten, aber das löst ja die Situation der unterschiedlichen Datenlage nicht.
Wir leben aber mit OGD 1.1. und dieser Situation und entsprechend konzipierten Lizenz-auf-Datensatz-Portalen und haben entsprechende Bestandsdaten aufgebaut. https://www.govdata.de/
Die Kosten die ein "händisches" Durchgehen aller Lizenzangaben zum Zwecke einer Feingranulierung auf Ebene der Ressourcen bringen würde ich meines Erachtens aktuell in der Breite nicht finanzierbar.
von DCAT-AP zu OGD: Hier muss man sich für eine Lizenz von vielen Distributionen (die erste?) entscheiden und diese für den Datensatz behaupten.
von OGD zu DCAT-AP: Hier muss man die Datensatzlizenz grob fachlich falsch für eine Lizenz auf Distributionsebene ausgeben, etwas womit die Zielgruppe des Standards meines Erachtens zu Recht auch fachliche Probleme hat.
Adding properties is not tweaking the DCAT standard. The DCAT conformance criteria state:
and:
But I agree that disallowing the use of a DCAT property in a profile is problematic. I do not think that such a restriction is necessary to resolve this issue in a DCAT-friendly way. But it needs to be specified what happens when a dataset has a different license than a distribution contained in it.
>> How would you solve the following conflicts without loosing information or give wrong information in the communication from CKAN to DCAT?
>> (From DCAT to CKAN is even worse, as we step down in granularity) granularity conflict:
>> 7: License at distribution level (DCAT) vs. License at dataset level (CKAN)
>> 8: Status at distribution level (DCAT) vs. status at dataset level (CKAN)?
>> Raised in https://joinup.ec.europa.eu/asset/ogd2_0/issue/dcat-ap#comment-18465
The GovData cooperation showed willingness to move from “dataset granularity” to “distribution granularity” for the license issue and is willing to fill this field with the proper license information that is needed to allow reuse of those datasets on distribution level.
The costs of a manual recheck of a license information today seems to be an acceptable Must-do. We therefore now solved the granularity problem by moving to the target granularity of “distributions having licenses”.
This was possible by creating a German extension of DCAT-AP as a solution for the GovData metadata federation. Within DCAT-AP.de we restricted further the cardinality of the dct:license property in the dcat:Distribution class, turning it into a mandatory 1:1 property of a distribution.
Other ways of saying something about license (rightsStatements) were included in DCAT-AP.de – as were all DCAT-AP entities. We further suggest to use a license out of a proofed set in a dynamic list of licenses within the namespace http://dcat-ap.de/def/licenses/ in our dcat-ap.de “implementing Rules / Konventionenhandbuch (http://dcat-ap.de/def/dcatde/1_0/implRules.pdf ) ” (pointing then there to the original places of creative commons and other licenses).