Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document options for harvesting/importing/syncing remote metadata/data #77

Open
JJediny opened this issue Apr 6, 2016 · 2 comments
Open

Comments

@JJediny
Copy link
Contributor

JJediny commented Apr 6, 2016

Part of the appeal of today's distributed content generation is the ability not to have to separately maintain metadata/datasets - when they are better maintained elsewhere by others. It's safe to assume that many use-cases that JKAN calls for will need/want to take a hybrid approach to catalog both a collection of datasets maintained on JKAN together with those from remote sources.

Harvesting/snap-shoting datasets can be a version control nightmare, but its arguably better then recreating them entirely manually... However documentation could/should cover a few of the best options/processes out there to achieve the closest thing to syncing across multiple remote services. As an alternative/complementary approach it would also be good to include methods to integrate push notifications or webhooks to for example run a build and a gulp process to refresh a remote source and have a repeatable process to manage the fetch/ingest/transform/import process... this could then rebuilt a new docker container with jkan or run locally and commit the bulk updates

@JJediny
Copy link
Contributor Author

JJediny commented Apr 6, 2016

This also calls into the need to have a canonical source field to identify if the record on JKAN is externally or internally maintained

@timwis
Copy link
Owner

timwis commented Apr 6, 2016

Interesting idea @JJediny. To be honest, I don't have much experience doing that (I couldn't get ckan harvester to work). I agree we should document it though. Would you be open to working on a page in the wiki about it?

(Also, regarding #62, just waiting to hear from you on the dataset slug question)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants