Ian,
I think your email came only to me, so I am replying to it, and cc-ing
to OKFN.
On Jan 29, 2010, at 12:31 PM, Ian Ibbotson wrote:
I think I kinda raised this concern at OKCon a couple of years ago,
but never managed to put it into sensible words..
You have described the concern so well below... you should be proud of
that.
the worry for me is
that these data sets are often not like perl modules in one very
important way: they aren't discrete complete final entities. And I
worry that OKFN sometimes blurs this versioned-files analogy to better
fit the CKAN "It's like CPAN but for data" model. These datasets are
often growing and evolving entities that are (IMNSHO) more correctly
described as streams than files (Sometimes with versions, often not).
Indeed. I envision CKAN to be a network of mirrored registries
accessible by, hopefully, RESTful APIs that offer the path to plugging
into the authoritative data sources. I should be able to query CKAN
for a dataset by various criteria (nouns, license, provider, etc.),
get a list of providers, and, if they have made their data available
programmatically, plug into those streams.
Harvesting protocols such as OAI allow us to reference those streams
(Of metadata or discrete RDF graphs) without actually having to move
the data from one place to another. I'm not against repositories/silos
per-se but I am worried about an ecology that favours building a
dependency on one specific hub over using an authoritative source (Or
synchronised (In some way) mirror of that source). I guess I'd rather
see CKAN as the "mirror" software of the knowledge age rather than the
all-knowing oracle. I appreciate there's nothing to stop people
running copies of CKAN in this way, although it's not clear to me how
the mirroring side of things would work.
Totally in agreement. Data should not be duplicated, and should remain
with authoritative providers. CKAN should only be a means to getting
to the edges. All the intelligence should be in the edges.
It's fine to have many copies of data, but if we do that sooner or
later we're going to have to face up to the inevitable question "Who
holds the authoritative copy, and how do I know what I'm looking at is
up to date". Granted, this isn't much of a problem for wikipedia etc,
but if we want access to the repository of ofsted inspection reports
so we can build some mashups of local childcare provision it's going
to be pretty high on the list :)
But really just random thoughts :)
Have a great weekend all,
Ian.
On 29 January 2010 17:58, Mr. Puneet Kishor <[email protected]>
wrote:
While I managed to rant a bit below, I neglected to address the
main point
squarely --
On Jan 29, 2010, at 11:51 AM, Mr. Puneet Kishor wrote:
On Jan 29, 2010, at 11:07 AM, Jo Walsh wrote:
..
Puneet, I think we just have to get used to overlap.
indeed, multiple overlapping services may be inevitable, and
perhaps even
welcome from an "ecology" perspective. However, since CKAN is an OKFN
production, it might be worthwhile to aim for CKAN to become like
CPAN, say,
5-10 years from now. *The* canonical repository for knowledge.
After all, no
point in having the adjective "Comprehensive" in its name, if we
don't mean
it, and intend to make it so.
--
Puneet Kishor http://www.punkish.org
Carbon Model http://carbonmodel.org
Charter Member, Open Source Geospatial Foundation http://
www.osgeo.org
Science Commons Fellow, http://sciencecommons.org/about/whoweare/kishor
Nelson Institute, UW-Madison http://www.nelson.wisc.edu
-----------------------------------------------------------------------
Assertions are politics; backing up assertions with evidence is
science
=
=
=====================================================================
_______________________________________________
okfn-discuss mailing list
[email protected]
http://lists.okfn.org/mailman/listinfo/okfn-discuss
--
Ian Ibbotson
Director
Knowledge Integration Ltd
37 Paradise Street, Sheffield. S3 8PZ
T: 0114 273 8271
W: http://www.k-int.com
_______________________________________________
okfn-discuss mailing list
[email protected]
http://lists.okfn.org/mailman/listinfo/okfn-discuss
