Version 2 of the Data Package specification will soon be released. Once it is supported by frictionless-py (and ideally Frictionless Repository, which we currently use for some of our CI tests), we could migrate the metadata to use it. See the Changelog.
Move constraints.enum to categories, where each category has a value and a description. The definitions list could then be moved out of description, which would go a long way towards making working with a JSON file less painful (see below).
And finally, include a datapackage.json file because:
A file containing a Data Package descriptor MAY have other name rather than datapackage.json as an internal part of some project or system if supported by corresponding implementations. A descriptor SHOULD NOT be externally published under any other name than datapackage.json.
We could either work from datapackage.json (which I agree feels more clumsy), or build it from datapackage.yaml and leave the two alongside?
Version 2 of the Data Package specification will soon be released. Once it is supported by
frictionless-py(and ideally Frictionless Repository, which we currently use for some of our CI tests), we could migrate the metadata to use it. See the Changelog.$schema: https://datapackage.org/profiles/2.0/datapackage.jsoncontributors: Replacerolewithrolesarray populated with DataCite terms (creator,DataCollector,DataCurator, possiblyDataManager).dialect: Addtype: delimiteddepending on outcome of https://github.com/frictionlessdata/datapackage/pull/74schema: AddfieldsMatched: exactfieldtype: listconstraints.enumtocategories, where eachcategoryhas avalueand adescription. The definitions list could then be moved out ofdescription, which would go a long way towards making working with a JSON file less painful (see below).And finally, include a
datapackage.jsonfile because:We could either work from
datapackage.json(which I agree feels more clumsy), or build it fromdatapackage.yamland leave the two alongside?