- From: Andrea Perego via GitHub <sysbot+gh@w3.org>
- Date: Fri, 30 Mar 2018 10:51:16 +0000
- To: public-dxwg-wg@w3.org
@dr-shorthair dixit: > OK - then one thing we should definitely do is to push back on CKAN, and explain the need for different licenses on different distributions. It is an easy argument to make. @jakubklimek gives a nice example above. Just to complement @jakubklimek 's point, it is worth mentioning that there are several examples of CKAN extensions addressing this issue (including the one we developed for the JRC Data Catalogue). A notable one is the European Data Portal (EDP) - the EDP extension is on [GitLab](https://gitlab.com/european-data-portal/ckanext-edp/tree/master/ckanext/eodp) (see [the relevant line](https://gitlab.com/european-data-portal/ckanext-edp/blob/master/ckanext/eodp/schema/schema.py#L101)). There's therefore a clear requirement from (at least part of) the community of CKAN users. > If CKAN is OK with extending their model a little to meet that requirement, I still suggest we reciprocate, but more importantly meet the community request that has been expressed, and add some verbiage around the use of dct:license and dct:rights (and other conditions-of-use properties) in the context of dcat:Dataset, fenced with warnings about potential interactions with additional or alternative conditions applied at the dcat:Distribution level. On the CKAN implementation side, this could be harmlessly addressed in different ways - e.g., by revising the CKAN schema to support licences on both datasets and distributions, or by having a config parameter determining whether the licence is on the distribution or dataset level. This way, the CKAN DCAT extension could be aligned with DCAT without being in conflict with the (revised) CKAN schema. -- GitHub Notification of comment by andrea-perego Please view or discuss this issue at https://github.com/w3c/dxwg/issues/104#issuecomment-377500865 using your GitHub account
Received on Friday, 30 March 2018 10:51:23 UTC