As part of saving to and from the (Git + datapackage.json) MetaStore layer we need to convert from CKAN metadata to Frictionless metadata and vice versa:
CKAN <=> Frictionless
Key question: How do we convert from CKAN metadata structures to Frictionless? And vice versa?
Tasks
[x] "What" CKAN metadata? Is it core objects or results of methods like package_show?
[x] What is the criteria? Ans: it's about revisioning in essence so we need all the attributes
[x] Research how we can convert from CKAN me
[x] What code do we use to do that?
[x] What issues are there now?
[x] And how does that interact with package_show and package_update flow (which may be complex) ...
Analysis
What's the relation to package_show
A. What i get by calling package_show is essentially identical (modulo extras expansion) to what is in datapackage.json
B. It's different (and if so, what are the differences?)
Ans: they are different
package_show has much more than what is in core Package object. What we store in datapackage.json is approx what is in Package object (with dereferencing of relations to some extent)
Example: datastore_active is on Resources in package_show but not in Resource object (? tbc)
rufuspollock
commented
4 years ago
As part of saving to and from the (Git + datapackage.json) MetaStore layer we need to convert from CKAN metadata to Frictionless metadata and vice versa:
Key question: How do we convert from CKAN metadata structures to Frictionless? And vice versa?
Tasks
package_show?Analysis
What's the relation to
package_showA. What i get by calling
package_showis essentially identical (modulo extras expansion) to what is indatapackage.jsonB. It's different (and if so, what are the differences?)Ans: they are different
package_showhas much more than what is in core Package object. What we store indatapackage.jsonis approx what is in Package object (with dereferencing of relations to some extent)Example:
datastore_activeis on Resources inpackage_showbut not in Resource object (? tbc)