Recently they ran their second competition looking for interesting and useful applications and tools to be built using or leveraging data published by government.
It’s a clever model: offer $10,000 or so to a winner who creates and submits the most interesting entry. Give applicants encouragement, publicity and assistance. I have to believe that this creates a groundswell of energy and hacking that furthers the foundations goals and uses the prize money in a highly leveraged way.
““By setting government data free on its new Data.gov site, the Obama administration enabled and encouraged the creation of fresh, new ideas that could help citizens get more involved in their government,” said Clay Johnson, director of Sunlight Labs. “Seizing upon this important moment, Sunlight organized this Apps for America contest to catalyze the development of useful applications and visualizations to make this information more comprehensible to more people. We also wanted to demonstrate to the government that when it makes its data available, it makes itself more accountable and creates more trust and opportunity in its actions.”
The first prize winner is Datamasher.org, a Web application designed by Forum One Communications that lets anyone—no programming background required—choose different government data sets and mash them up to create visualizations and compare results on a state by state basis.
The second prize winner is GovPulse, which allows viewers to quickly search the Federal Register in a variety of ways, including by agency or date. And the third was ThisWeKnow.org, which lets users type in their zip code and get back a wealth of information about their neighborhood drawn from different agencies.
I’ve just finished writing part 3 of my series about DataRSS. Part 1 gives the background and justification for the concept, and Part 2 worked through a semi-believable scenario where having DataRSS would be a good thing.
In part 3 I try to get into more technical detail. I hope that you take the time to read it because that’s the only way I will get technical feedback on it. The reason I wrote the first two parts is that realistically I expect to lose 99.5% of you guys once you open up part 3. That’s why this post is labeled [GEEKY]. Here’s some of what I cover in part 3:
“Data RSS is a simple protocol and a simple data format. It can be implemented in any programming language.
Importantly, the Publisher and Accessor software need not know (can not know) what language the counterparties software is written in. ” (from DataRSS: Technical Overview)
“DataRSS is used between two parties, the Publisher, who ‘owns’ some data, and the Accessor, who wants to use that data. Publisher and Accessor are organizations with people in them. The Publisher wants to offer a technical means to allow an application program simple and standardized access to their data.
The Accessor wants to write an application program that accesses and does something useful with data coming from any Publisher. Accessor and Publisher don’t know each other. ” (from DataRSS: Technical Overview)
Delicious isn’t it? One final tease, I also have worked out some detailed examples of how DataRSS might work with the New York Times API, with the Sunlight Foundation API and with the Follow The Money API.
I want to start posting some of the cool things I am figuring out but so far I haven’t because I can’t really figure out how to organize it.
One area that I have immersed myself into is the many diverse groups who are doing work promoting government openness and transparency by, among many other things, creating the technical bridges to allow information that is already being collected to be more easily accessible. There are many of them, and one of them is the Sunlight Foundation. They are doing some really cool work, both themselves, and sponsoring and granting others who share their goals.
Wow what a long wind-up.
Anyway, in digging deeply into their APIs and datasets I decided to learn by doing and created a Ruby Gem called govsdk with the following goals:
- A simple and consistent sdk to all the various government (federal, state and local) APIs available.
- Totally hide from the user of the SDK what those APIs are, what the networking and REST pieces are. Instead provide classes which represent the natural domain objects and behind the scenes accesses appropriate datasets and APIs.
- Identify the ‘current’ best APIs for the various facts and figures so that the user need not do the work to learn each of the organizations and data models. When new ones come online or change, hide that as well.
- Provide all this in an open source library, for free, with example code, documentation and test suites.
Version 0.0.1 of the GovSdk GEM (0.0.1 — get the idea?) is implemented and available at GovSdk. Check it out, but expect it to change because this is still quite embryonic.