Civic Innovations

A couple months back, I was thrilled to see the New York State Senate expose an API for querying the status of bills in its Legislative Information System.

The release of this API is just one component of an exciting change underway in the Senate’s IT management (under NY Senate CIO Andrew Hoppin and his talented staff), and to my way of thinking it perfectly captures what people like Tim O’Reilly mean when they talk about government as a platform.

The NY Senate is doing a lot these days to make government more open and more efficient (through the use of open source software tools like Drupal). But the API excites me the most because of what I think it says about open government.

When governments make their data available in public formats, and expose APIs for querying such data, they are throwing the door open to outside developers to build useful things. That’s significant, and the NY Senate should get some major props for being among the first (if not the first) legislative body in the country to provide an API for their legislative information.

When governments make data available through an API, they are telling developers: “Use any platform or programming language you want to access our data.” The basic requirements for invoking an API like the NY Senate’s (or the District of Columbia’s 311 API) is the ability to communicate via HTTP and to parse XML, or JSON. Since pretty much every modern programming language and development platform can do these things, it creates opportunities for developers of all stripes.

But if APIs are platform and language agnostic, they are also modality agnostic – if the data exposed through an API is compact enough, there are lots of different ways to present this data to an end user.

In my opinion, government APIs also make a very compelling (albeit somewhat more subtle) statement about the different modalities that can be used to access data. More traditional types of applications that use government APIs are browser-based, visual applications. But if APIs are platform and language agnostic, they are also modality agnostic – if the data exposed through an API is compact enough, there are lots of different ways to present this data to an end user. Providing multi-modal access to government data and services is something I have been interested in for a long time, and this interest was the catalyst for the Access Delaware project I helped start when I worked for the State of Delaware back in 2003.

Shortly after the folks at the NY Senate launched their API, I began working on an application that would allow someone to query the status of a bill using an Instant Messaging Client. At the time, I said that I wanted to add additional functionality for different user agents (including regular telephones) to make my demo application truly multi-modal.

I’ve been getting things done in dribs and drabs, but I now finally have the telephone interface complete and the latest code checked into GitHub. There are four different methods for querying legislative information exposed via the NY Senate API:

• Instant Messaging Client (Jabber): opensenate@bot.im
• Twitter Client: Send a tweet formatted as a @reply to @opensenate
• Short Message Service (SMS): Send a text message to (315) 308-1943
• Regular Telephone: Call (646) 736-2439 (Available in both English and Spanish.)

The same underlying application logic services all four modalities. The telephone interface requires an additional layer – I opted to use CCXML for this because the send/response format that can be used to obtain data from external sources is very similar to the response format used for the other three modalities.

Right now, I’m using the Voxeo/IMified platform to host the application. It’s very much still hosted in a staging environment, so it probably won’t stand up to a heavy user load. Its also why I’m a bit limited right now in the phone numbers deployed for SMS and voice access — I would prefer to have only one number for this, but at least the two numbers I’m using are both NY State numbers.

There are a host of other services cropping up that specialize in hosting multichannel communications apps – one of the more exciting is called MessagePub (look for a separate post on the MessagePub service in the next week or two). This is good news for governments that want to encourage developers to build multichannel applications.

Even though this is just a small demo application, It demonstrates what can be done when an organization like the NY Senate has forward thinking IT leadership, that embraces open standards, open source and open information.

Remember; its about the platform.