TITLE II - Enhancing Public Access to the Work of Congressional Committees, Legislative Information, and Votes

Sec. 207. Creation of a legislative database. (9 Comments) subscribe to the comments feed

Creating an API for legislative information from THOMAS would allow technologists reliable access to legislative data at its source.

  1. The Library of Congress shall offer an Application Programming Interface (API) to provide public access to legislative documents, bill status, and summary information.

9 comments on Sec. 207. Creation of a legislative database.

  • This is very good. Some variations to be a bit more specific. (I like #3 best.)

    (1) "The Library of Congress shall offer an Application Programming Interface (API) compatible with Industry standards to provide public access to legislative documents, bill status, and summary information."

    (2) "The Library of Congress shall offer an Application Programming Interface (API) to provide license-free non-discriminatory public access to legislative documents, bill status, and summary information."

    (3) "The Library of Congress shall offer a documented Application Programming Interface (API) to provide machine-readable, license-free, non-discriminatory public access to legislative documents, bill status, and summary information."

    See: http://resource.org/8_principles.html

    posted by Greg Elin at March 27, 2008
  • No APIs! I would be majorly upset if the LoC ever thinks its job is done with an API.

    A bulk-downloadable database *must* be first. You can always build an API off of a bulk download, but you can't necessarily go the other way around.

    posted by Joshua Tauberer, GovTrack.us at March 27, 2008
  • On a side note, I hope that the Library of Congress hires a DBA (Database Administrator) to properly design the database schema and normalize it.

    http://en.wikipedia.org/wiki/Database...

    I definitely like the first person's #3.

    I agree with the second person, in that, APIs can be built later. The main thing that needs to be done is the database design, and import of ALL data into it, and subsequent ability to download that data. Once a good structured database schema is being used, then start working on an API.

    posted by Matthew Castanien at April 2, 2008
  • My attempt at a rewrite of the first person's rewrite:

    The Library of Congress shall offer a documented Application Programming Interface (API) to provide machine-readable, license-free, non-discriminatory public access to legislative documents, bill status, and summary information. This information will be stored in a relational database, and database schema will be made available to the public.

    posted by Matthew Castanien at April 2, 2008
  • Additional Notes:

    I'm not that familiar with APIs, but I would recommend someone look at how Google and others license/make available/terms their API. You would have to stipulate limits on amount of connections made to the API etc.
    http://tinyurl.com/3286um


    Just saying that it is license-free is a little ambiguous. It needs to have an OSI approved license. Also, when you talk about a license, are you talking about a license for the API, or for using the API? You could technically make the API code GPL, and that would allow people to see the API code. But, I think you might be talking about th e data being freely accessible...license free. Semantics...

    http://en.wikipedia.org/wiki/Open-sou...

    posted by Matthew Castanien at April 2, 2008
  • Replying to Matthew's comments:

    "On a side note, I hope that the Library of Congress hires a DBA (Database Administrator) to properly design the database schema and normalize it. "
    The LOC has had a database in place for as long as there has been THOMAS, and they were in the process of converting the database to an XML database... which probably is finished now. I would suspect they probably have a good design in place, I think it's best not to ask them to do it over. :) I would be happy if they just made their database in whatever format they have it in now public.

    "I would recommend someone look at how Google and others license/make available/terms their API. You would have to stipulate limits on amount of connections made to the API etc."
    This is exactly why I think an API is not appropriate as the primary means of access to government data (where a bulk download is feasible).

    "Just saying that it is license-free is a little ambiguous. It needs to have an OSI approved license"
    The motivation here is that there should be no presumption that there are any limitations at all on the use of the data (besides existing privacy, etc. law). If the data is in the public domain (as it should be if it was created by the government), there is no need for an OSI license, for instance. An OSI license only works if the data is copyrighted... and if it is, there's already a problem.

    As for whether license-free applies to the API "itself" or the data- This comes from the http://www.opengovdata.org principles, which intended it to be applied to data. To talk about an API being license free would probably mean the documentation --- and actually that's an important point to consider if there is going to be an API (which I hope there is not!). The code behind an API is not really important, IMO.

    posted by Joshua Tauberer, GovTrack.us at April 3, 2008
  • I see Joshua's point regarding APIs. A government-built API won't be sufficient. It will take a long time for them to produce it. It will cost them lots of money. And it will fall short of our expectations. And as Joshua mentioned in the GAO section, standards change, meaning the government would have to go through this process every few years to keep up with the times. I doubt they're prepared for that.

    posted by matt burton at April 4, 2008
  • We need a section 209 - All legislation should be viewed, and discussed ,with clear changes on a Wiki. All Elected Representatives should have to publicly acknowledge
    on the Wiki that he/she has read the proposed legislation before they can vote on it.


    There should be no excuses as to why a rep would vote on something they have not read.

    posted by SpaceLifeForm at April 17, 2008
  • The API should also include access to Statements to the Congressional Record and Committee Reports.

    Ideally it would also include a consolidated list of committee meetings, bills being marked up, and speakers (w/ links to their prepared testimony), but that might be tricky to implement.

    posted by Rob Pierson at May 8, 2008

Comment on Sec. 207. Creation of a legislative database.

(You may comment anonymously. Moderators may remove offensive or off-topic comments.)

Your Name (and Organization*):

Your Comment: (HTML is not permitted, but links will be automatically linked)

*We encourage you to take credit for your comments by including your name and organization.

The Sunlight Foundation supports, develops and deploys new Internet technologies to make information about Congress and the federal government more accessible to the American people. Through its projects and grant-making, Sunlight serves as a catalyst to create greater political transparency and to foster more openness and accountability in government. This Site may contain links to Internet sites that are not operated by Sunlight Foundation. These links are provided as a service and do not imply any endorsement of the activities or content of these sites, nor any association with their operators. Sunlight Foundation does not control these Internet sites and is not responsible for their content, security, or privacy practices. We urge you to review the privacy policy posted on web sites you visit before using the site or providing personal information.