dependabot[bot] on npm_and_yarn
Bump follow-redirects from 1.13… (compare)
roll on main
Fixed project workflow (compare)
There is something buggy in the library somewehre - it is trying to read a file that does not exist - as you can see it is repeating the url in the file path (i suspect it is not supportive of dp v1 specs in the path field ...)
I suggest you could load the CSV directly for now in R (which i know somewhat defeats the point) ;-)
Or any other links directly from the https://datahub.io/JohnSnowLabs/diagnosed-diabetes-prevalence-2004-2013
@HeidiBaya_twitter :-) - it is so great to have you using the data - please keep the feedback (and bugs) coming so we can fix them. We should have R instructions updated on site this week and hope we will have a usable R lib soon.
In the mean time you could almost just do yourself:
Just open the datapackage.json link:
https://datahub.io/JohnSnowLabs/diagnosed-diabetes-prevalence-2004-2013/datapackage.json (will redirect for you ...)
Open that and look at the resources section and you'll have all the CSV files with schemas etc
We also have a dedicated chat channel just for datahub.io at http://gitter.im/datahubio/chat
Indeed, looking forward to get in gear. But first, we have a hackathon to run - and that means making more data packages! https://discuss.okfn.org/t/october-27-open-tourism-data-hackathon/5860
@loleg that's great and you can start pushing your data packages to the new https://datahub.io/ - if you are interested in being an alpha publisher user just sign up and then fill in the short questionnaire ...
This post walks you through the major changes in the Data Package v1 specs compared to pre-v1. It covers changes in the full suite of Data Package specifications including Data Resources and Table Schema. It is particularly valuable if:
You can find the entire blogpost here http://datahub.io/blog/upgrade-to-data-package-specs-v1
@Stephen-Gates because i don't think the specific resource inherits in a defined sense like licenses. sources are a less specific in that sense - whereas licenses obviously filter down the sources you specify may apply to some resources but not others etc.
I guess my question is more to you: what semantics do you want and why :-) ?
sourcesonce at the package level and explicitly say resources inherit. If
sourcesvary at the resource level, specify at that level and don't specify at the package level. Given licence compatibility issues, you could you specify different
licencesat the resource and not have a
licenceat the package level. The Specs support this apart from explicit inheritance of
sourcesfrom the package. This could be fixed in the data resource spec by
source: as for Data Package metadata. If not specified the resource inherits from the data package.
Good afternoon. I am reviewing the various specifications and had two questions. First have you come across a use case where a "query" is being represented as a data resource?
@bruth yes we've definitely thought about this use case. You could definitely use it this way.
And second, are there any support/examples for including and/or deriving provenance (PROV or otherwise) from data resources?
You can use the
sources attribute. Would you want more than that?
contributorsattributes are a good start for provenance. I need to evaluate to what extent I need/want to embed all provenance information in the
datapackage.jsonor if I would reference a changelog/PROV graph of sorts