dependabot[bot] on npm_and_yarn
Bump follow-redirects from 1.13… (compare)
roll on main
Fixed project workflow (compare)
Data Packagecentric (e.g.
datahub.iostores packages, not resources) so even having the
Data Resourcespecification to use
packageproperty feels kinda natural.
I'm validating my changes with Goodtables.io at http://goodtables.io/github/Stephen-Gates/licenses
In my okfn/licenses#57, I accidentally added an error by mis-spelling "superceded". Goodtables.io didn't fail the data despite my enum constraint.
I'm wondering if there's an error in my table schema or if GoodTables has a bug?
Hi, I'm looking for test
datapackage.zip files. I came across https://github.com/frictionlessdata/testsuite-extended and https://github.com/frictionlessdata/example-data-packages but these didn't help. I couldn't find datapackage.zip files on datahub.io either.
Any suggestions on a source for data package test data and if not, where is the best place to contribute these?
Are there notes anywhere of the roots of the standard, specifically how much it owes to (and potentially influences the future of) https://github.com/ckan/ckan/blob/master/ckan/logic/schema.py#L206 ?
Not a touchy topic at all. If you go back to the pre-history of frictionless data in 2007 or so then yes: ckan metadata was partially inspired by python packaging and so was first "dpm" (data package manager). In fact, as you may know, CKAN was originally intended to act like pypi or cpan cran etc.
Over time, the source of inspiration of data packages has shifted a bit towards more recent packaging systems like node + package.json (pypi was probably not the best initial inspiration).
This is something that would probably be worth a discuss.okfn.org question so we can write up there for posterity :-)
This post introduces you to the Core Data, presents a couple of examples and shows you how you can access and use core data easily from your own tools and systems including R, Python, Pandas and more.
This is a blog post. To read full text, please, follow the link above.
I was wondering what it would take to be involved in the next development of the specifications. In particular for the Tabular Data Package
You've taken the first step! We welcome contributions and new curators of the specifications.
At the moment points and GeoJSON support is there in a basic format, but issues like spatial extent of dataset, spatial reference system and vector geometry type (e.g polygon, point, linestring) need to be added to the schema to make the schema work properly in the geospatial world
We'd really welcome your help here - be it on improving geo in the tabular spec or on the separate WIP geo spec.
Rufus - co-lead curator of the Frictionless Data Specs
@Stephen-Gates first a huge appreciation of your ongoing contributions here -- you are a definitely a candiate for curator :-)
Given @palmerj's question about contributing, I notice that many frictionless data repositories don't have the recommended community files. In a the yet to be accepted PR okfn/licenses#57 I added a code of conduct, contributing, and other community files. Is it appropriate to add these to the repo or are there standard templates to apply to OK repositories?
@Stephen-Gates i'd say generally yes. For all of OKi stuff i'd recommending first suggesting on okfn/chat or the forum. For frictionless if you could do a draft (or pull out your exiting one into a PR and we can review).