[okfn-labs] Next generation data catalogues.
Pieter Colpaert
pieter.colpaert at okfn.org
Mon Aug 26 18:23:03 UTC 2013
Hi Ross,
Yes, no problem! I would be pleased. You can add me to the github org as
well.
As The DataTank is concerned, http://thedatatank.com/help is the completest
documentation we have at this moment. We are working on a Long Term
Support release (release date: 5th of December 2013) which the core
datatank team will publish more information about soon. I've put the Irina
of The DataTank is in CC (Jan Vansteenlandt), maybe he has more to share?
Kind regards,
Pieter
On Mon, Aug 26, 2013 at 6:37 PM, Ross Jones <ross at servercode.co.uk> wrote:
> Hi Pieter,
>
> Do you mind if I wholesale copy big chunks of your email onto our Wiki for
> discussion and as general areas to focus around? Would also welcome your
> feedback when we have something to feedback on - can I add you to the
> github org?
>
> I also just had another look at datatank, and had never realised that is
> seems to serialise the data to lots of different formats (json, rdf, xml,
> map). Is there any documentation around with a complete overview of what
> datatank is and how it works?
>
> Ross
>
>
> On 26 Aug 2013, at 16:26, Pieter Colpaert <pieter.colpaert at okfn.org>
> wrote:
>
> Hi Ross,
>
> It does! In fact this is one of of the subjects I'm researching at Ghent
> University as part of my PhD. I really like the idea of a new generation
> Open Data portal.
>
> To give direct input, a paper I'm writing atm is describing 5 things,
> ordered by difficulty, that an open data portal should provide, in order
> for data owners to reach their goal (stimulate data reuse concerning a
> specific domain):
>
> * A dataset registry
>
> There should be a list of open datasets which you can search and browse
> through.
>
> ** A meta-data provider
>
> The meta-data that is collected should be actively maintained and should
> be made Open Data itself (here: released under an open license and
> described using e.g. DCAT): by doing that, other open data portals can
> harvest this data. At this moment I think CKAN is the best solution for
> this out there.
>
> *** A co-creation platform
>
> The data portal should stimulate communication around data reuse:
> - (open source) tools that are being created should be listed at the
> dataset
> - co-creation events and ideation projects should use the platform to
> "+1" the best ideas, concepts or apps
>
> CKAN has some extensions for this star, yet I think this should be in
> there by default.
>
> **** A data publishing platform
>
> The data itself should be made available through the platform in common
> formats so that the programmers can access it in an easy way (e.g. through
> The DataTank: http://demo.thedatatank.org)
>
> Also, a URI strategy should be made.
>
> ***** A common data hub
>
> Provenance, Trust, Feedback cycles, Linking data, and so on. The data
> becomes part of data cycles which everyone can implement. This could be
> made by a "Git for Data", as James Smith wrote in this blog post:
> http://theodi.org/blog/adapting-git-simple-data
>
> (My paper is called "The 5 stars of Open Data Portals")
>
> Kind regards,
>
> Pieter
>
> On 08/26/2013 04:45 PM, Ross Jones wrote:
>
> Hi,
>
> There was a bit of discussion on the #ckan channel this morning between some developers
> building data catalogs around what a next-generation data catalog would look like. It was
> noted that it might _not_ look like CKAN, and so we booted up the catalog-ng organisation
> on github (https://github.com/catalog-ng) as a place to work on some ideas and proof-of-concepts
> around what we think would be included in a new data catalog using the knowledge gained
> working with CKAN.
>
> There really isn't a plan yet, certainly the intention isn't to damage CKAN in any way, but more
> of a way to experiment with building catalogs without any of the baggage involved with a
> mature product - what would you build today with the new tech available and the experience
> of working with CKAN. Rather than go through the process of doing this outside, I thought it might
> be useful to do this as part of labs and keep it inside OKF, and possibly keep it on a OKF mailing list.
>
> Does this belong in OKFN-labs? Does the idea of building something new in that area sound
> vaguely interesting to anyone (other than those of us with work with CKAN day-to-day)?
>
>
> Ross.
> _______________________________________________
> okfn-labs mailing listokfn-labs at lists.okfn.orghttp://lists.okfn.org/mailman/listinfo/okfn-labs
> Unsubscribe: http://lists.okfn.org/mailman/options/okfn-labs
>
>
> _______________________________________________
> okfn-labs mailing list
> okfn-labs at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/okfn-labs
> Unsubscribe: http://lists.okfn.org/mailman/options/okfn-labs
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/okfn-labs/attachments/20130826/191438f7/attachment-0002.html>
More information about the okfn-labs
mailing list