A morning panel today at API Strategy and Practice focused on APIs for Government and Public Data. Chaired by API Evangelist Kin Lane, who presented a workshop on government open data tools on Wednesday, speakers came from government, university and private settings to talk about creating open data APIs with government agencies.
“This [API/open data agenda] goes beyond Government, its public as well. UC Berkeley for example, is pushing the envelope in terms of APIs in the institutional setting,” Lane said in his opening remarks.
George Atala, from UC Berkeley kicked off the discussion: “We are a very research-focused university, and knowledge is created to be shared.
“Web APIs started with a focus on distribution channels. For a university, these distribution channels look a little different. We can’t have one API like Twitter. So saying we should have an API and open our data isn’t a very good business case.”
There’s a lot of reasons for a university to have an API strategy:
“Open data in research, in particular, is emerging as a new driver in the university setting”, Atala noted. “Universities have to look at open data for their very survival. Open data is disrupting the University, just as much as it is for Government.”
For Atala there are three main elements to a university API strategy:
To resolve security concerns, Atala suggests making an upfront distinction between what APIs are private, public or partner-oriented and whether these are read-only or live data, for example.
Socrata is a company aimed at providing a platform for governments and private-public partnerships to publish and manage open data. Chris Metcalf from Socrata spoke next to share some war stories in helping government’s develop APIs.
Metcalf pointed to core values of government open data including improved transparency, efficiency, innovation, accessibility, and inclusiveness.
Government has a number of key barriers that create difficulties. Heavyweight procurement processes, for example, often work against agile, smaller businesses from submitting suggestions for public-private partnerships. Outdated legislation, the very nature of politics, antiquated IT systems in place across a government bueaucracy, bad data that requires documentation and cleaning, and stubborn IT stakeholders all prevent companies like Socrata from being able to assist governments to open their data.
The procurement process, for example, has been a fundamental cause behind the failure of the recent US healthcare.gov
“Streamlined procurement, policies that open data by default, and changes to the way governments buy IT are three of the top things that need to happen”, Metcalf urged. Metcalf urged developers to use government data to create applications as a key way for community members to assist in encouraging governments to open data via API, as it shows the value of data access.
Nick Muerdeter spoke on behalf of the National Renewable Energy Lab (NREL), and also shared some of his recent work with data.gov.
Some recent APIs NREL has been building including:
Both examples aim to show how they are not just about sharing static data but about serving the public. For example, by querying the alternative fuel stations data, the API helps identify the closest station, and can help map travel routes to it.
Much of the motivation for NREL’s API strategy and implementation has been driven by the desire to get developers to build applications using the data, and to meet growing demand for the data that became too onerous to provide any other way. For example, with the fuel stations in particular, NREL was finding an increasing amount of resources were taken up in responding to individual requests for this information.
NREL itself consumes many of its APIs in its own work. “Its a great way to deal with collaborations with research labs and with other departments within government”, Muerdeter said.
To keep going forward, NREL has reached the point of needing to create a standard API management platform. As a result, Muerdeter found himself contributing to an api.data.gov pilot project, aimed at lowering the barriers to agencies being able to create APIs, and reducing barriers for end users (such as having to sign up for multiple API keys with each government agency). The pilot also introduces access to analytics so government agencies can review how end users are using their APIs, a bizarre gap that private providers are often shocked to discover isn’t in place already.
Developer hubs across government are now accessible via data.gov/developers.
The panel ended with Jed Sundwall from Measured Voice. Measured Voice created the Social Registry API to streamline “fedsourcing”, the process of how over 3,000 individual government departments and accounts are represented on the web (domains ending in .gov, Twitter accounts, etc).
returns all NASA accounts registered on Twitter.
To show the potential of the API, Measured Voice was able to create a mashup to show trends and popularity in government tweeting for example. “It’s turned out to be a really useful training tool,”says Sundwall, sharing how government can communicate effectively with the public.”
For those attending the panel session, the greatest opportunity lies in making use of the APIs and access to open data to create solutions that show the potential back to government of what is possible.