Civic Innovations

I recently had an opportunity to speak about open data at the annual Joint Education Conference of the Nevada Food Safety Task Force. Not the most obvious venue for a discussion of civic collaboration, but I sometimes go where the open data currents take me. And so it was this time.

Sandwiched in between talks about new technology to measure and collect data on food temperature and hand washing frequency at food service establishments, I made a pitch to those in attendance about the importance (and the power) of open data. A quick initial poll of the audience revealed just a few that knew about open data – what it was or why governments were interested in it. I sometime think these kinds of presentations – though an immediate positive reaction can be less certain – are often more impactful than presenting to groups that are already familiar with open data. They provide an opportunity to create new converts – a welcome idea to an old catholic school boy like myself on the road stumping for government innovation.

My case for open data was boosted considerably by the fact that the Southern Nevada Health District (SNHD) – which is responsible for food safety inspections in the area where the conference was being held – publishes inspection data in an open format. A cursory examination of the data revealed a small issue that made it difficult to import into a relational database. This seemed like the intended use for the data, especially considering that the SNHD published a database schema with the data release – one specifically designed for MySQL, a commonly used open source database.

This seemed a bit unusual, but an email to SNHD to alert them of the issue resulted in a quick response and a fix to the published data file. A good sign, and one that I sometimes find lacking in governments that have more elaborate open data portals.

During my presentation, I made note of the SNHD data release (to acknowledge their efforts) and even demoed a quick prototype app I was able to develop with it that allowed a user to search for inspection results using a text message. My point in showing this was to demonstrate how easily a new application could be created with the tools and platforms available today to developers, provided they are armed with useful data.

As it happens, there were several staff members from SNHD in the audience, and though they seemed pleased by the mention of their data release they also expressed confusion as to why I’d created an app with their data. The SNHD already has a web app and mobile apps for searching inspection results (I’m also told they have an SMS app, though I could not locate information on it through repeated web searches).

I realized my presentation had missed the mark and I spent some time afterwards trying to figure out why. Surely if a public agency was releasing open data (along with a database schema for that data) they would not be all that surprised that people would actually use their data to build something, right?

Upon reflection, though, I think this may be exactly the issue.

The idea of open data has now been so broadly disseminated that governments large and small are aware if it, and an increasing number are opting to release data to the public. That is clearly progress. However, as open data evangelists perhaps we have not done as a good a job at communicating why governments should release open data, or – perhaps more accurately – what happens after governments publish open data.

The process of publishing open data extends beyond successfully posting a file to an external server – in many ways, this is actually just the beginning of the process. There are some very specific reasons why governments want (and should encourage) external users to do things with their data. First and foremost, as with the small technical glitch I found when I first access the SNHD data, it can help improve the quality of open data.

Publishing open data doesn’t mean that government agencies shouldn’t build their own apps for citizens – there are many reasons why they should. But encouraging outside users to experiment with data and create their own apps can be enormously beneficial, even for governments that decide to create their own apps. The Southeastern Pennsylvania Transportation Authority (SEPTA), which provides transit service for the Philadelphia area, has for many years published open data and APIs for third-party developers. More recently, and after these data resources had been available and used for some time, SEPTA opted to release its own mobile apps.

This approach allowed SEPTA to see the kinds of apps that third-party developers opted to build, and how those apps fared when marketed to and used by the public. It also allowed them decide when and on what platform to release their own mobile app, perhaps to ensure that it most effectively compliments the existing array of apps available to transit riders. In essence, this is a way for the organization to outsource R&D and user testing – it can provide invaluable information to the agency as it works toward its own app release and simultaneously provide an opportunity for the agency to improve its data.

As the mechanics and techniques for releasing data to the public become more numerous and more sophisticated, I think we need to invest more time and energy building tools and techniques for ongoing collaboration and conversation with external data users. Even in big cities that use expensive, sophisticated open data platforms identifying mechanisms for public feedback and discussion on data sets is sorely lacking.

Open data isn’t an outcome, its a process – one fueled by robust outreach to external collaborators that can help government unlock the true value of their data.