Creating an API for legislative information from THOMAS would allow technologists reliable access to legislative data at its source.
The Library of Congress shall offer an Application Programming Interface (API) to provide public access to legislative documents, bill status, and summary information.
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
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.
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.
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.
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...
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.
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, 2008We 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.
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.