[okfn-labs] Next generation data catalogues.

Ross Jones ross at servercode.co.uk
Mon Aug 26 16:26:31 UTC 2013


Hi,

Yeah, I hadn't forgotten about pudo/datahub, definitely might be easier to build on than the current repo (requirements and readme).

For me particularly, I'm interested in publishing (and all of the background processes that go on behind that - archiving, etc) and so that's likely to be one of the areas I focus on.  What *does* 'easy but useful' publishing looks like.  How might datapackages fit in.  How much meta-data can we get *without* asking users to provide it.  But the others have different priorities and interests.  Even if the end-result is CKAN doesn't need X,Y or Z then I think it's useful, if it ends up being a smaller more efficient CKAN with less baggage and is more fun to use/work with - that's useful too.

Google are doing a _terrible_ job of finding data, or at least CKAN doesn't do a very good job of enabling it to do a better one (it needs to implement schema.org to make it easier for search engines - so I've been told :P). I disagree that search is irrelevant, it's currently lowest common denominator search and nobody realises Google has more than one page of results ;)  Maybe all we actually need is a duckduckgo plugin (http://duckduckhack.com/) ?

Shame about Buzzdata, I hadn't heard, but then I never *really* understood what it was for.  They were pivoting so often it was hard to keep track.

Ross.

On 26 Aug 2013, at 16:21, Friedrich Lindenberg <friedrich.lindenberg at okfn.org> wrote:

> Hey Ross, 
> 
> that sounds cool, it'd certainly be fun to keep the -labs list in the loop. For what it's worth, we also still have https://github.com/pudo/datahub hanging around, so if you want to play with concepts that may be easier to hack than CKAN proper. In terms of other tech, I'd also really look at Max's dat stuff. He's apparently started working on that and I feel it could be a useful data transfer convention. 
> 
> Finally, my sense is that this should be driven by _activities_: what do you want to do? If the answer is "search data", then you have a problem (because, well, Google). Nobody has ever really wanted to "read and update metadata". "Explore" and "visualise" are mostly BS: why? Whats your larger aim? How often do you do that? Who are you, anyway? "Upload" has existed for years... And a whole generation of fake-social catalogues has just died off (RIP BuzzData).
> 
> Maybe there's some help in being more specific: Heroku data clips are cool, and a weird percentage of my data projects now depends on Nomenklatura (even though I'm still pretty much its only user :( ). Also, Google Spreadsheets: amazing table UI and horrible API, but it works for people. 
> 
> Cheers, 
> 
>  - Friedrich 
> 
> 
> 
> 
> 
> 
> 
> On Mon, Aug 26, 2013 at 4:45 PM, Ross Jones <ross at servercode.co.uk> 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 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/78823b42/attachment-0002.html>


More information about the okfn-labs mailing list