Leveraging the Government 2.0 Platform

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.

3 comments

  1. Nathan Freitas (NY Senate) · September 8, 2009

    This is fantastic work, Mark. I’m flattered and relieved to have a developer of your quality and vision to be utilizing our OpenLeg API. I am working on a big update to the open.nysenate.gov home page and will plan to include your work in a showcase section. Voxeo/IMified is a neat platform to build on, especially with their support for XMPP.

    As a side note, have you noticed the RSS feeds we now have available? That is what is powering: http://twitter.com/nysenateopenleg

    I am really interested in getting data proactively pushed out and indexed, where citizens don’t have to go and seek out information, but it is instead weaved into the conversation throughout the web, social networks and more.

  2. Mark Headd · September 8, 2009

    Cool – so the RSS feed includes bills that have been acted upon within a specific period, correct? Would this include a bill that was just introduced (and referred to its initial committee for consideration)?

    I had some of the same thoughts that you did, about being able to proactively notify someone when an action is taken on a bill. I was thinking it would be neat to allow someone to “subscribe” to a bill through one of the channels listed above. So, for example, when someone sends a tweet to @opensenate to get the current status of a bill, they could then send a follow up like “#notify S1234” to be notified of future changes in the status of a bill.

    These notification requests would need to be persisted somewhere – probably just require the addition of a database backend to the app. If the OpenLeg RSS feed includes changes for a specific time period, it should be pretty straightforward to use it to find out which bills have seen a status change, query the database to see if the bills have any “subscribers” and then send out a notice to the end user on the same channel they used to subscribed.

    Just thinking out loud here, but I think its a viable approach.

    I like the idea of weaving bills into the conversations on social networks – I see you have Facebook and Twitter integration in the discussion section of the bill summaries. I need to try that and add a comment to a bill or two.

  3. Pingback: ….::: VOX POPULI :::…. » Blog Archive » Lots of Gov 2.0 Potential in Twitter Geolocation

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s