Licenses not imported correctly

[Stephen-Gates]

When I upload this datapackage.zip to this ckan site the licenses aren't unpacked correctly

[GeraldGrootRoessink]

What seems to works partially (singular)
"license" : {
"type" : "CC-BY-4.0",
"url" : "https://creativecommons.org/licenses/by/4.0/",
"title" : "Creative Commons Attribution 4.0"
},

[Stephen-Gates]

Yep, but that's the pre v1.0 Frictionless Data specification.

Code is at https://github.com/frictionlessdata/ckan-datapackage-tools/blob/master/ckan_datapackage_tools/converter.py#L173

It needs to support v1 spec https://frictionlessdata.io/specs/data-package/#licenses

[amercader]

Implementation

Change the converter in ckan-datapackage-tools to support v1 spec.

I think we should still store the full DP licenses object. If we want to use CKAN's own license field logic will need to be a bit more complex, as we will need to make sure that the license exists in the internal registry, which can be customized depending of the site. If the DP license exists in the registry, set license_id, but CKAN only accepts one so we should choose the first one (My feeling is that 99% of times there will be only one anyway). So just to be on the safe side, we should still store licenses as an extra and use that if present when exporting to DP, so we don't lose any information.

So, to sum up:

• When ingesting DP:
  • If licenses is present check if the first item exists in the licenses registry.
  • If so, set license_id
  • If it doesn't exist in the registry, or there is more than one license, store the licenses object as an extra, so instances with the datapackager extension can handle it as they see fit. They will need to take care of keep license_id (the default field) and the licenses extra in sync.
• When exporting DP:
  • If there is a licenses extra, use that.
  • If license_id is present, use that to build the output licenses object.

Estimate

0.5 days