Monday, September 17, 2012
Thursday, July 19, 2012
As I've mentioned before, technology alone is not enough. Congress needs to take at least two steps in the way it writes bills, in order to make legislation more amenable to automated updates and analysis:
1. Move ahead with positive law codification: the Law Revision Counsel has prepared a number of Titles of U.S. law for passage into positive law. This would mean replacing the cobwebs of hundreds of overlapping laws and amendments with a single, authoritative text. This is never an urgent matter for Congress, but it does represent a very important and long overdue Housecleaning. For each Title that is passed into positive law, Congress now has a single base from which to work when making amendments.
2. Write new bills with full section-by-section text replacements. Currently, bills may change a single word, a sentence or an entire passage. The amendment is often described in words ("change the last word of the fourth sentence..."). Replacing entire sections makes automated redlining much more practical and effective, meaning that we could all more easily see what effect any new bill has on the existing legislation.
Of course, there is much more that could be said about each of these points, and about the goals that the Legislative Counsel and Law Revision Counsel have set out. I am very encouraged to see the political will gathering to make technological changes to the way bills are drafted, and I just hope that Congress can also make the bureaucratic changes necessary to support this new technology.
Friday, June 29, 2012
The editor will now be used to teach Akoma Ntosa in the Lex2012 summer course in Ravenna, Italy. In addition, Professor Monica Palmieri, a leading expert in legislative data standards, and a participant in the unhackathon, has also showed off the AKN-editor to parliamentary staff in Brazil.
Saturday, May 19, 2012
Thursday, May 17, 2012
- Twitter hashtag: #legalhacks
- Google+ Hangout --- link will be posted on Saturday morning around 11am PST on legalhacks.org
- View the tutorial video at: http://www.youtube.com/watch?feature=player_embedded&v=NOb-D1riJD4
- Also check legalhacks.org for other videos of "Ignite" talks on legislative mark-up
- Find a law or bill text, and mark it up using the AKN editor: http://legalhacks.org/Editor/Editor.html
- Publish your marked-up bill on legalhacks.org, and tweet out the link along with the #legalhacks hashtag.
Sunday, April 22, 2012
The International Legislation Unhackathon is being held May 19 at UC Hastings and Stanford Law Schools. Sign up, if you haven't already, at http://internationallegislation.eventbrite.com/. It is free, and lunch will be provided, thanks to the UC Hastings Center for State and Local Government.
The event is designed to be accessible for non-programmers and non-lawyers (hence an 'un'hackathon) who will 'get their hands dirty' adding metadata to actual legislation, using a developing international standard for legislative data, Akoma Ntoso. Future (and previous) posts will discuss such questions as Why Metadata in Legislation? and Why should legislatures use XML standards. You could get started by reading this excellent post by Andrew Mandelbaum of the National Democratic Institute.
Assuming that you agree that metadata and standards for legislation are a good thing, there are still questions of implementation: (1) At a technical level (does the proposed standard actually match the structure of real legislation 'in the wild'; is it workable, etc.), and (2) At the practical level (will legislatures actually adopt the standard, or can the private sector add the metadata post-facto to legislation?).
This unhackathon will be an experiment in both of these elements of implementation. Grant is developing a browser-based tool to easily add Akomo Ntosa metadata to legislation. The idea is to lower the barrier for anyone to just try it out. It should take no more than 5 minutes to learn how to add the data fields to legislation. Then the real test-- how well does the data model fit the actual data of laws? Can it be extended easily, for example to accomodate the requirements of the DATA Act?
As anyone who has worked in the web world knows, HTML has been an evolving standard, applied differently by different browsers over many years. It has undergone testing in the real world on billions of webpages with millions of authors. Data standards for legislation are, by comparison, much newer and have a much smaller audience. I am hopeful that participants in this unhackathon, including myself, will come away with a better understanding of what data models in legislation can do. And I also expect that the learning will go both ways-- that the developing standard of Akomo Ntosa can be refined through exposure to events like this one and as more legislatures begin to test and ultimately adopt the standard for drafting legislation.
Sunday, March 25, 2012
Saturday, March 17, 2012
Friday, March 9, 2012
Wednesday, March 7, 2012
A recurring theme for technically-minded people who start to think about how law and legislation works is: why can't the law be more like computer code? By this, they mean, why can't we use the same tools (version control, integrated development environments, compiling, testing) to work with legal code? This thought has been reflected in many recent conversations I've had with programmers about the law, and by the popularity, among a largely technical audience, of my answer to this Quora question: http://www.quora.com/Could-Git-be-used-to-track-bills-in-Congress.
For people who work with digitized data in other fields, the state of tools in law is puzzling. The current state of legal data is similar to that of music before the iPod. At the time, CDs had been around for a number of years. Anyone who had "ripped" a CD or otherwise moved music on and off of a desktop computer's hard drive had, at some point, thought about what it would be like to skip the CD altogether. I, myself, had a 100 CD player, and thought often about how nice it would be to compress that into a (relatively) small hard drive. In fact, digital music players did exist, but they were clunky. Getting mp3s on and off of them was cumbersome. And most people professed being quite happy with their large CD libraries. Then came the iPod.
The evolution of digital cameras tells a similar story. And it is inevitable that digital law will follow that path, sooner or later. There are lurches toward building digital toolsets in various jurisdictions: e-discovery, e-filing, e-compliance...
But these all have to contend with the basic lack of data structure in underlying legal data. What can be done with the data is therefore severely limited. But it is not far-fetched to imagine that laws around the world will soon be tagged with a common data format, taking us one step closer to having an iPod for law.
Grant Vergottini and I are hatching a plan for a hackathon, following up on the California Law Hackathon, to mark up sample legislation around the world in a standard XML format. Grant has done this already for the U.S. Code, California legislation, Hong Kong's Basic Law (essentially their Constitution) among others.
Although we have not yet "officially" announced this event, response to the idea has already been extremely encouraging, thanks in large part to Robert Richards' great outreach. We are already getting hints of legislatures around the world that may be ready to make the leap to linked digital data (like the UK has largely done, under John Sheridan's leadership). So there may not be a Steve Jobs of legislation (yet), but I believe that there are visionaries in legislatures worldwide who, together, can make this happen.
Friday, February 24, 2012
Thursday, February 16, 2012
Standards for their own sake have little meaning. What we'd like is a standard that would allow easy sharing and comparison legislative information from various jurisdictions, while flexible enough to integrate the kinds of metadata that Jim Harper of the Cato Institute has called for. By focusing on core structural elements, Grant has shown that translation between the different data formats is not only possible, but can be relatively straightforward. The U.S. legislative process is unique, as some experts at the House conference on legislative data pointed out.
True enough: every legislative process is, in some ways, unique. But there is enough overlap that a robust standard is possible. We're still far off from having a "computable" body of legislation, but this is a major step forward for making the code machine readable.
Wednesday, February 15, 2012
Thursday, February 2, 2012
I'll keep this one short, since others, particularly Jim Harper of the Cato Institute, have described in great detail what should go into this standard and why it is important.
Here, I want to focus on the importance of having a single XML standard from the first drafting of a bill to its codification. Lest you think this is already being done, or is an easy task to accomplish, Alex Howard (@digifile) of O'Reilly media has posted a helpful flowchart [and here] of the various offices that are involved in the first part of the legislative process (until the bill becomes law and is published by the GPO). The process of codification takes place after that.
A key element of any XML standard for legislation is that it be consistent throughout this process, as it passes from the jurisdiction of one office to another.
Wednesday, February 1, 2012
Tuesday, January 31, 2012
Monday, January 30, 2012
The attention from the House on data transparency, combined with current partisan gridlock on issues of policy, make this a perfect time to "reboot" Federal legislation for the 21th Century. The reboot comes in two mutually reinforcing parts. The first is the subject of this blogpost: make change to existing law in a consistent manner. The second is to push ahead with codification of existing law, so that future legislation can be built on a cleaner, more consistent and accessible platform. That is the topic of my next post.
Current legislation is riddled by language that describes the changes that should be made to the law. Take as an example, the Health Care Reform Act (HR 1692) which I've also referred to in my Quora answer:
Instead of this word-by-word description of the edits, a wholesale replacement should be made, preferably at the section level, changing the old section for the new one. In California, for example, this is done with language like this-- "Section [53395.1] of the [Government Code] is amended to read:"Section 1848(d) of the Social Security Act (42 U.S.C. 1395w–4(d)) is amended—
(1) in paragraph (10), in the heading, by striking ‘‘PORTION’’
and inserting ‘‘JANUARY THROUGH MAY ’’; and
(2) by adding at the end the following new paragraph...
If you are co-authoring a memo, Congress's writing approach is the equivalent of describing edits to your co-author in the text of an email ("In sentence three, take out the first two words..."). What I am recommending, and what California does, essentially, is redlining. Make changes in a consistent way, and replace entire sections with any amendment.
I understand, and have heard many of the reasons why this kind of change is not easy. Tradition, and bureaucratic inertia plays a large part in how Congressional language is currently crafted. Writing by committee is already difficult. Imagine the challenge of writing by various committees, hundreds of members, two chambers with, to put it mildly, some disagreements in priorities.
There are many reasons to think, however, that this technical change to the drafting form will be welcomed on Capitol Hill. It will provide more clarity, not only for the public, but for Congressional offices themselves, about what impacts a bill would have on existing law. The "replacement" method of legislative drafting would ultimately be easier for each Congressional office to participate in. And there are models to follow: California's legislature, not known for its easygoing legislative process is, by and large, able to make its changes using this method.
A major technical challenge to adopting this method at the Federal level is that many of our statutes, are "free floating". Either they stand apart from the U.S. Code, and exist only in the "Statutes at Large", or they have been incorporated into a Title of the U.S. Code, but that Title, as an organized volume, has not been passed into law, in the process known as positive law codification. Congress then, cannot technically refer to the existing text as "section 501 of Title 26", because Title 26 is not "positive law".
Instead, Congress refers to the original Acts which passed and which are being modified (e.g. the "Internal Revenue Code of 1986" or the "Patient Protection and Affordable Care Act"), and may include a parallel citation to the Code Title. These Acts, in turn, make their amendments to prior Acts, some of which have been codified and some of which haven't. This has lead to a significant tangled backlog of legislation, which just makes the current system more difficult to change. And that is why this change goes hand-in-hand with positive law codification, the subject of my next post.
Wednesday, January 25, 2012
I earlier listed recommendations for the U.S. House's Feb. 2 conference on legislative transparency and accessibility. These recommendations, to improve the human and machine accessibility of Federal legislation first require changes in the way that legislation is written, and second focus on the technology to support those changes. Some of these changes will meet with more cultural resistance and be harder to implement. This is probably the case with my first recommendation, to Write in Plain English, but I believe that Congress can make initial steps toward this goal right away.
By plain English, I mean writing clearly and consistently. In the highly nuanced and technical areas that are addressed by much of our legislation, plain language will still include technical language. And statutes will still require some expertise to understand and apply. Legislation will still include ambiguity: in fact much legislative compromise is built on carefully crafted, ambiguous, language. However, such ambiguity also carries heavy costs in decreased certainty, increased litigation costs and increased polarization.
As for implementation, there are already plain language initiatives that apply to Federal agencies and stylistic guidelines for how to write in plain language. Although Congress is clearly a different beast, lessons from these initiatives can apply to legislative drafting, as well. The centralized Office of Legislative Council already plays a very large role in drafting laws and crafting legislative language, for which most offices are very grateful. Strong plain language guidelines can be incorporated into the existing OLC guidelines (pdf) and, especially when backed by intelligent automation, can eventually make drafting a bit more of a science and less of an art. For example, to the basic stylistic guidelines, we can add a bit of technology: expand the vocabulary that is explicitly defined, set standards for the categories and kinds of words and phrases that require definitions, and work to harmonize definitions, to the extent possible, going forward.
Another single, but very powerful, stylistic change is to write all legislation as a full text replacement, at the section level, as is done in California and some other state legislative systems. I will discuss this more in my next post.
Friday, January 20, 2012
- Write in plain English
- Write changes to statutory sections as full replacements of previous sections. Use a consistent format to make changes (e.g. "Section 444 is amended to read as follows:").
- Commit to enacting positive law codification for all Titles. A positive law codification project for Title 26 should be considered as a non-partisan starting point for the effort to simplify tax law.
- Adopt a clean and simple XML data standard for Federal Legislation.
Tuesday, January 17, 2012
Wednesday, January 11, 2012
I have often thought about tax simplification from the starting point of tax statutes, and simplification of the underlying Code. That may be what David Brooks had in mind, in this week's column, advising Obama to champion simplifying the tax code among other good government measures. However, by using the data at its disposal, the IRS can go a long way toward simplification on its own. What I mean is this:
The IRS has massive amounts of data on the transactions of citizens and businesses and what impact those transactions had on tax determinations by the IRS. This data could be used to provide deterministic answers for a huge variety of specific taxpayer questions.
The IRS already provides guidance in a number of forms to individuals and businesses, with respect to the agency's interpretation of the law for particular circumstances. However, this advice comes in the form of written documents and letters that add to the overall volume of information that is required to understand and act on the law.
What I imagine is a tax calculator -- something like H&R Block or TurboTax software -- but using prior years' data, combined with IRS policy decisions, to prospectively help taxpayers determine the consequences of certain events or tax decisions.
Of course, the devil is in the details. But this is a place where the high volume of data that the IRS deals with can actually be an advantage toward simplification, just as Google uses its tremendous data advantages to simplify many informational challenges that would otherwise be far too complex.