Open Data Needs Open Source Tools

macslocum writes "Nat Torkington begins sketching out an open data process that borrows liberally from open source tools: 'Open source discourages laziness (because everyone can see the corners you've cut), it can get bugs fixed or at least identified much faster (many eyes), it promotes collaboration, and it's a great training ground for skills development. I see no reason why open data shouldn't bring the same opportunities to data projects. And a lot of data projects need these things. From talking to government folks and scientists, it's become obvious that serious problems exist in some datasets. Sometimes corners were cut in gathering the data, or there's a poor chain of provenance for the data so it's impossible to figure out what's trustworthy and what's not. Sometimes the dataset is delivered as a tarball, then immediately forks as all the users add their new records to their own copy and don't share the additions. Sometimes the dataset is delivered as a tarball but nobody has provided a way for users to collaborate even if they want to. So lately I've been asking myself: What if we applied the best thinking and practices from open source to open data? What if we ran an open data project like an open source project? What would this look like?'"

Comments

Already being done

[kiwimate]

What if we ran an open data project like an open source project? What would this look like?

Wikipedia. With all the inherent problems of self-proclaimed authorities who don't know what they're talking about; bored trouble-makers who inject bad information because they're, well, bored; petty little squabbles which result in valid data being deleted; and so on.

Re:Already being done

[musicalmicah]

What if we ran an open data project like an open source project? What would this look like?

Wikipedia. With all the inherent problems of self-proclaimed authorities who don't know what they're talking about; bored trouble-makers who inject bad information because they're, well, bored; petty little squabbles which result in valid data being deleted; and so on.

Gee, you make it sound so terrible when you put it like that. It also happens to be an amazing source of information and the perfect resource for an initial foray into any research topic. It's a shining example of what happens when huge amounts of people want to share their knowledge and time with the world. Sure, it's got a few flaws, but in the grand scheme of things, it has made a massive body of information ever more accessible and usable.

Moreover, I've seen all the flaws you've listed in closed collaborative projects as well. Like all projects, Wikipedia is both a beneficiary and a victim of human nature.

Use Open Standards

[The-Pheon]

People could start by documenting their data in standardized formats, like DDI 3.

Open data needs open data structure and owner

[bokmann]

Interesting problem. Several things come to mind:

1) The Pragmatic tip "Keep knowledge in Plain Text" (fro the Pragmatic Programmer book, that also brought us DRY). You can argue whether XML, JSON, etc are considered 'plain text', but the spirit is simple - data is open when it is usable.

2) tools like diff and patch. If you make a change, you need to be able to extract that change from the whole and give it to other people.

3) Version control tools to manage the complexity of forking, branching, merging, and otherwise dealing with all the many little 'diffs' people will create. Git is an awesoe decentralized tool for this.

4) Open databases. Not just SQL databases like Postgres and MySQL, but other database types for other data structures like CouchDB, Mulgara, etc.

All of these things come with the poer to help address this problem, but come with a barrier to entry in that their use requires skill not just in the tool, but in the problem space of 'data management'.

The problem of data management, as well as the job to point to one set as 'canonical' should be in the hands of someone capable of doing the work. PErhaps there is a skillset worth defining here - some offshoot of library sciences?

Re:Open data needs open data structure and owner

[GrantRobertson]

Perhaps there is a skillset worth defining here - some offshoot of library sciences?

That offshoot is called "Information Science." Most "Library Science" programs now call themselves "Library and Information Science" programs. There is now even a consortium of universities that call themselves "iSchools." In my preliminary research while looking for a graduate program in "Information Science" it seems as if the program at Berkeley has gone the farthest in getting away from the legacy "Library Science" and moving toward a pure "Information Science" program.

I personally think that the field of "Information Science" is really where we are going to find the next major improvements in the ability of computers to actually impact our daily lives. We need entirely new models of how to look at dynamic, "living" data and track changes not only to the data but to the schema and provenance of that data. That is how "data" becomes "information" and then "knowledge." I won't write my doctoral thesis here, but suffice it to say that simply squeezing data into a decades old model of software version control is not quite going to cut it. In software version control you don't have as much of a trust problem. Yes, you do care if someone inappropriately copies code from a proprietary or differently-licensed source. However, you don't have as much incentive for people to intentionally fudge the code/data one way or another. In addition, data can be legitimately manipulated, transformed, and summarized to harvest that "information" out of the raw numbers. This does not happen with code. Yes, there is refactoring, but with code it is not as necessary to document every minute change and how it was arrived at. With data, the equations and algorithms used for each transformation need to be recorded along with the new dataset. In addition, the reason for those transformations and the authority of those who did the transformation.

Throw into the mix that there will be many different sets of similar data gathered about the same phenomena but with slightly different schemas and different actual data points which will all have different provenances but will need to be manipulated in ways to bring their models into forms that are parallel to all the other data sets associated with those phenomena while still tracking how they are different ... and you will see that we don't just need a different box to think outside of, we need an entirely different warehouse. (You know, the place where we store the boxes, outside of which we will do our thinking.)

Many of the suggestions posted here are a start, but only a start.