Akoma Ntoso, Standards

Common Identifiers or a Common Data Format. What is more important?

I just read this excellent post by Tom Bruce, et. al. from the Legal Information Institute at the Cornell University Law School.

Tom’s post brought to mind something I have long wrestled with. (Actually so long that it was a key part of my job working on CAD systems in the aerospace industry long ago). I sometimes wonder if having common identifiers isn’t more important than having a common data format. The reason is that being able to unambiguously establish relationships is both very difficult and very useful. In fact, one of the reasons you want a common format is so that you can find and establish these identifiers.

I have used a number of schemes for identifiers over the past ten years. Most of the schemes I have used have involved Uniform Resource Names or URNs. A decade ago we designed a URN mechanism for use in the California Legislature. Our LegisWeb product uses a very similar URN schema based on the lessons learned on the California Project. In more recent years I have experimented with the URN:lex proposal and the URL-based proposal that is within Akoma Ntoso. Both of these proposals are based around FRBR. I can’t say I have found the ideal solution.

I favor URN-based mechanism for a number of reasons. URNs are names – that was their intent as defined by the IETF. They are not meant to imply a location or organizational containment (well mostly they aren’t). In theory, these identifiers can be passed around and resolved to find the most relevent representation when needed. But there is a problem. URNs have never really been accepted. While they conceptually are very valuable, their poor acceptance and lack of supporting tools tends to undermine their value.

Akoma Ntoso takes a different approach. It uses URLs intead of URNs. Rather than using URLs as locations though, they are used as if they are identifiers. It is the duty of the webserver and applications plugged into the webserver to intercept the URLs and treat them as identifiers. In doing this, the webserver provides the same resolution functions that URNs were supposed to offer. My upcoming editor implements this functionality. I have built HTTP handlers that convert URLs into repository queries which retrieve and compose the requested documents. I have it working and it works well – as much as I understand the Akoma Ntoso proposal. I’m still not totally crazy about overloading identifier semantics on top of location semantics though. At least the technology support is better in place.

So what issues have I struggled with?

First of all, none of the proposals seem to adequately address how you deal with portions of documents. There are many issues in the area. The biggest of course is the inherent ambiguity within legislative documents. As Tom mentioned in his post, duplicate numbering often occurs. There are usually perfectly good and valid reasons for this – such as different operational conditions. But sometimes these are simply errors that everyone has to accommodate. Being able to specify the information necessary to resolve the ambiguity is not in any proposal I have seen. Add to that the temporal issues that come with renumbering actions. How do you refer to something that is subject to amendment and renumbering? Do you want a reference to specific wording at a specific point in time, or do you want you reference to track with amendments and renumbering?

At this point people often ask me why a hash identifier followed by a cleverly designed element id won’t work. The first thing you have to realize is that the # means something to the effect of “retrieve the document and then scroll to that Id”. The semantic I am looking for is “retreive the document fragment located at Id”. The importance of the difference becomes obvious when you realize that the client browser holds the “#” part of the request and all the server sees is the document URL, minus the hash and identifier. When your document is a thousand pages long and all you want is a single section, that distinction is quite important. Secondly managing ids across renumbering actions is very messy and introduces as many problems as it solves.

Secondly, the referencing mechanism tends to be documented oriented. Certainly, Akoma Ntoso uses virtual URL identifiers to refer to much more than simple documents, but the whole approach gets cumbersome and hard to explain. (If you want to appreciate this, try and explain XML schema’s namespace URI/URL concept to an uninitiated developer.) What’s more, it’s not clear if a common URL mechanism does enough to establish common enough practices for the effort to be useful. For instance, what if I want to refer to the floor vote after the second reading in the Assembly? Is there a reference to that? In California there is. That’s because the results of that vote are reported as a document. But there is nothing that says this should be the case. I have had the need to interrelate a number of ancilliary documents with the legislation. How to do that in a consistent way is not all that clear cut.

The third problem is user acceptance. The URN:Lex proposal, in particular, looks quite daunting. It uses lots of characters like @, $, ;, While end users can be shielded from some of this, my experience has taught me that even software developers rebel against complexity they can’t understand or appreciate. So far, this has been a struggle.

I’m eagerly awaiting Part 2 of Tom’s post on identifiers. It’s a great subject to explore.

Standard
Akoma Ntoso, Standards, Transparency

Imagine All 50 States Legislation in a Common Format

Last week I expressed dissapointment over NCSL’s opposition to the DATA Act (H.R. 2146). Their reasoning is that the burden this might create on the state’s systems will not be affordable. Contrast this with the topic of the international workshop held in Brussels last week – “Identifying benefits deriving from the adoption of XML-based chains for drafting legislation“. The push toward more transparent government need not be unaffordable.

With that in mind, stop for a while and imagine having the text from all 50 states legislation publishing in a common XML format. Seem like an impossibly difficult and expensive undertaking doesn’t it? With all the requirements gathering, getting systems to cooperate, and getting buy-in throughout the country, this could be another super-expensive project that in the end would fail. What would such a project cost? Millions and millions?

Well, remember again Henry Ford’s quote “If you think you can do a thing or think you can’t do a thing, you’re right”. Would you believe that a system to gather and publish all 50 states has recently been developed, in months rather than years, and on a shoe-string budget? That system is BillTrack50.com. It’s a 50 state bill tracking service. Check it out! We, at Xcential, helped them to do this herculian task by providing a simple and neutral XML and the software to do much of the processing. The press release is here. The format is SLIM, the same format the underlies my legix.info prototype. It’s a simple, easy-to-adopt XML format built on our past decade’s experience in legislative systems. Karen Sahuka at BillTrack50 recently gave a presentation on her product at the Non-profit Technology Conference in San Francisco.

SLIM is not as ambitious as Akoma Ntoso. If you take a gander at my legix.info site, you will see that it’s very easy to go from SLIM to Akoma Ntoso. In fact, going between any two formats is not all that difficult with modern transformation technology. It’s how we built the publishing system for the State of California as well. My point is that with the right attitude, a little innovation, and the right tools, achieving the modern requirements for accountability and transparency need not be out of reach.

Standard
Standards, Transparency

The State of the Art in Legislative Editors and the DATA Act

(My plan was for my next blog to contain a mini-tutorial on my editor, that is still coming this weekend)

A report on legislative editors has just been released in Europe. You can find the report at https://joinup.ec.europa.eu/elibrary/document/isa-leos-final-results. It’s a very interesting read. It’s focused on Europe but is something we should look at seriously in the US.

After almost a decade in this business, I discovered my European counterparts a couple years ago when I attended the LEX Summer School in Ravenna, Italy (Info on ths year’s class can be found here) What struck me was how much innovative work was occurring in Europe compared to the USA. Sure we have plenty of XML initiatives in the USA and there are many examples of modern up-to-day systems we can point to, but there is a lot of fragmentation and duplication of effort and learning. All in all, it is my feeling we’re falling far behind in this field. And yet the Europeans expect and want leadership from the USA; we’re the ones with a society more conducive to innovation and entrepreneurialism.

So how are we doing in the USA? This week the DATA Act (H.R. 2146) passed the U.S. House. It requires accountability and transparency in federal spending. Sounds like a good thing, doesn’t it? One does expect that the government we elect ultimately be accountable to we the people.

The DATA Act, while addressing federal spending, could be the impetus that drives state governments in America to update their systems to publish in open and transparent formats. Viewed as an opportunity, this act could ultimately drive better cooperation amongst the various state legislatures. This cooperation would improve innovation and progress in US legislative systems by focusing on common approaches and open standards. This less insular viewpoint would, as a result, improve efficiency and lower costs. Common standards allow common tools and common tools cost a lot less than full custom solutions. Check out the blog by Andrew Mandelbaum at NDI – http://www.demworks.org/blog/2012/04/how-xml-can-improve-transparency-and-workflows-legislatures.

Henry Ford once said “If you think you can do a thing or think you can’t do a thing, you’re right”. I was disapointed to see NCSL came out with their opposition to the DATA Act. Their reasoning is that the DATA Act is a cost they cannot afford at this point. Certainly, we are all feeling the effects of the economic meltdown in the past few years and it’s hurting the states especially hard. But why can’t the move to open and transparent systems be viewed as an opportunity to improve efficiency and reduce costs? If modern standards-based automation was a liability, would businesses have automated to the extent they have? I don’t see very much focus on using automation as a tool to improve efficiency in legal informatics. It’s an opportunity squandered I think.

If you want to know more about open legislative standards, consider attending our upcoming “unhackathon”. You can sign up here.

Standard
Akoma Ntoso, Hackathon, Standards

Building a Web-Based Legislative Editor

I built the legislative drafting tool used by the Office of the Legislative Counsel in California. It was a long and arduous process and took several years to complete. Issues like redlining, page & line numbers, and the complexities of tables really turned an effort that, while looking quite simple at the surface, into a very difficult task. We used XMetaL as the base tool and customized it from there, developing what has to be the most sophisticated implementation of XMetaL out there. We even had to have a special API added to XMetaL to allow us to drive the change tracking mechanism to support the very specialized redlining needs one finds in legislation.

Using an XML editor allows one to develop a very precise and accurate solution. The price you pay is the rigidity imposed upon you by the XML structure enforced by the editor. We worked very hard to loosen up that rigidity by providing a rules-based system that allowed the user to work within some wiggle room relying the application to sense what was intended and produce the desired rigid structure that XML demands. Another approach, taken by many, is to use a word processor to generate the document, relying on styles or lightweight tagging in the word processor to guide an XML generator or transformer after-the-fact. This gives the drafter more flexibility, at the expense of the accuracy when the drafter deviates outside of the expected range of document patterns that the XML generator can handle.

I have often wondered if a web-based editor wouldn’t be a better approach, allowing us to achieve the flexibility the user needs with the rigidity that makes XML useful to downstream processing. In the end, the question has always been whether such an editor is even possible. When the Writely word processor (now Google Docs) came along in 2005, the answer seemed to be a tentative yes. Looking into it a little bit I discovered that while feasible, given all the browser incompatibilites of the time, achieving a worthwhile editor of the sophistication needed to draft and manage legislation would still be a daunting task. So the idea has always remained in the back of my mind waiting for browser technology to mature to the point where building such an editor comes within a shot of being a reasonable approach.

That point has now arrived. With HTML5, it is now possible to build a full fledged browser-based legislative editor. For the past few months I have been building a prototype legislative editor in HTML5 that uses Akoma Ntoso as its XML schema. The results have been most gratifying. Certainly, building such an editor is no easy task. Having been working in this subject for 10 years now I have all the issues well internalized and can navigate the difficulties that arise. But I have come a long way towards achieving the holy grail of legislative editors – a web-based, standards-based, browser-neutral solution.


There are a lot of challenges. Interacting with all the browser events to maintain an undo stack is no easy task. Building a change tracking mechanism from scratch gives me lots of freedom but getting your head around all the variations is bewildering at times. And how do you build something that is useful to multiple jurisdictions and is sufficiently flexible to adapt to all the varying needs? This takes a trick – but one I have thought long and hard about.

HTML5 is not yet a fully defined standard. None of the browsers fully support what is defined. The same can be said for CSS, JavaScript, XML Support, and on and on. But the editor I have built works with the latest version of all four major browsers. I don’t have a single CSS quirk at all. In fact, the only substantive browser incompatibility that I have had to deal with arises from the fact that Internet Explorer’s XML implementation pre-dates the standard in this area and the API does not yet match the full standards-based API. This is the case despite IE having been the pioneer in this area.

What’s more, I have achieved this with Akoma Ntoso as the internal XML schema. Akoma Ntoso is itself a proposed standard within OASIS. Certainly not everything has been smooth sailing and I have submitted a whole slew of issues to the drafters of Akoma Ntoso, but I have been able to find my way to a workable implementation. It works!

Our plan is to use this prototype for the Unhackathon at UC Hastings and Stanford Law School on May 19th and then in follow-on events elsewhere. In a few days I will provide a link to the prototype for everyone to try it out. It’s still early days and the editor is far from being a complete and robust tool suitable for production, but what I have now confirms my belief that the next generation of legislative systems will be web-based and built on open-standards.

In my next post I will provide a little mini-tutorial to set the stage for the upcoming pre-beta release.

Standard
Akoma Ntoso, Hackathon, Standards

Toward’s more Affordable Solutions in Legal Informatics – with Standards

Got six million dollars? That’s the ballpark figure for a complete legislative system and it is too much. A decade ago when the technologies were still new, the risks were high, and experience was scarce, the reasons for this were easily explained. But now it’s time to move beyond the early-adopter market towards a more mature, affordable, and predictable market for legislative systems. The key to moving to this new era is standards.

Towards this end I am participating as a member of the OASIS LegalDocML Technical Committee. Our charter is to develop a common standard for legal documents. We had our initial meeting in March and are defining our deliverables for this important mission.

The wide variety of legal systems and traditions ensures that there are never going to be off-the-shelf solutions in legislative systems. However, all the differences should not deter us from finding what we have in common. It is this commonality that provides the basis for the development of common applications that can be cost-effectively adapted to local requirements. Of course, to achieve this goal you need a common information model. The OASIS TC is using Akoma Ntoso as the starting point for this information model.

Akoma Ntoso Logo

Okay, so what is Akoma Ntoso? Akoma Ntoso is an XML schema developed at the University of Bologna and supported by Africa i-Parliaments, a project sponsored by United Nations Department of Economic and Social Affairs. It defines an XML-based information model for legislative documents. In the last few years it has been gaining traction in Europe, Africa, South America, and now slowly in North America as well.

Do you find the name Akoma Ntoso intimidating? Well, you’re not alone. However, it’s easy to say once you know how. Simply pronounce it as in “a-coma-in-tozo” and you’ll be close. Akoma Ntoso means “linked hearts” in the Akan language of West Africa.

If you find all the talk about XML confusing, then we have a solution for you. Through my company Xcential, I am working with Ari Hershowitz @arihersh of Tabulaw, Charles Belle @brainseedblog of UC Hastings, and Pieter Gunst @DigitalLawyer of Stanford and LawGives.org to host two “unhackathons” on May 19th at UC Hastings and at the Stanford Law School, both near San Francisco. The point of our unhackathons is to provide participants with an entry-level and fun introduction to the world of XML markup and Akoma Ntoso. And once we’re done with the May 19th events around San Francisco, we’re going to stage other events in other locations around the world to bring the same knowledge to a much wider audiance

If you would like to attend one of these events please sign up at the Eventbrite.com site and/or contact one of the organizers. And if you would like to host or participate in a virtual unhackathon in June, please let one of us know as well. We’re looking for volunteers.

Within the next week I will be posting a prototype of a new legislative editor for use at the unhackathon.  It’s an HTML5-based editor built entirely around Akoma Ntoso. While we don’t yet have any productization plans, this editor will demonstrate the coming era of cost-effective and standardized components which can be mixed and matched to produce the next generation of legal informatics solutions. Stay tuned…

Standard
Akoma Ntoso, Hackathon, Standards

International Open Standards Hackathon

An international open standard for legislative documents will be an important next step for making legislative information available to the people. An open standard will promote the creation of tools and services worldwide that will enable citizen participation in the legislative process and will enhance how governments make the laws they produce more transparent.

Today there is a great deal of inconsistency in how open participation and transparency are achieved around the world. Putting cultural and political differences aside, part of the reason for the inconsistency is the tremendous effort and cost involved in building the infrastructure to support these new objectives. An open standard will start to solve this problem by promoting the establishment of a real legal informatics industry of interoperable tools and services which can easily be put together to address whatever committment a government has made to open and transparent government.

Akoma Ntoso is an emerging standard the promises to do just this. It is an XML schema, developed by the University of Bologna in Italy. It was developed for Africa i-Parliaments, a project sponsored by United Nations Department of Economic and Social Affairs. In the coming weeks, an OASIS technical committee will begin the process of turning this standard into an international standard. I am a participant on that TC.

To further promote and to publicize Akoma Ntoso, I am working with Ari Hershowitz #arihersh to stage an international hackathon within the next few months. The idea is to provide an event for people that will demystify XML and Akoma Ntoso (yes, it is hard to say) by providing a really easy way for anyone to create a document using the proposed standard. Our goal will be to collect a world’s worth of legislative samples. This could be an important step towards building a library that stitches together all the world’s laws and regulations in an open and transparent way.

We’re currently seeking sponsors, participants, and venues for this hackathon. The interest we have found so far has been quite amazing. If you are interested in helping us make this event a success, please let either Ari or me know.

Standard
Akoma Ntoso, Standards

International Meeting on Transparency and the use of Open Document Standards

This past week was a very interesting week for me. I attended the meeting “Achieving Greater Transparency in Legislatures through the Use of Open Document Standards” at the U.S. House of Representatives in Washington DC. The meeting was sponsored by the United Nations, the Inter-Parliamentary Union, and the U.S. House of Representatives.

Meeting Participants

For me it was a valuable opportunity to meet with colleagues I had already met in my travels in recent years, to meet with people I knew of but had never met, and to meet people I had corresponded with only through email. Particularly special for me was to finally meet Tim Arnold-Moore. It was by reading his thesis on “Information Systems for Legislation” back in 2001 that I became aware of the field of legal informatics.

It was quite fascinating to see the different ways in which different countries were approaching transparency. As one would expect, the American approach is a bit heavy-handed with a focus on providing access to existing documentation. It seems that the real innovation is coming from smaller or younger countries that are less encumbered by the top-down bureaucracy that tends to squash out more cost-effective innovation.

Two systems caught my attention in particular:

  • The first was the system put in place by the Brazilian Chamber of Deputies. More than merely providing their citizens with visibility to the workings of their government, this system focused on ensuring two way interaction between citizens and their elected representatives – even going so far as to allow citizens to express their viewpoints by way of YouTube-style video clips.
  • The other system to get my attention, of course, was Bungeni. This is an open source Legislative Information System developed in Nairobi, Kenya for use in the parliaments of Africa (and elsewhere in the future). It is based on the Open Office word processor, but does the most credible job of turning a word processor into an XML editor that I have seen so far. Of course, it works with Akoma Ntoso which was developed alongside it.

Speaking of Akoma Ntoso, it came up plenty of times during the conference. Monica Palmirani and Fabio Vitali from the University of Bologna in Italy presented various aspects of the XML Schema. On Tuesday the OASIS LegalDocumentML TC was opened to drive it towards being an international standard. You can read about it here.

On the Thursday after the meeting wrapped up, Knowledge as Power held a class on Legislative XML at the National Democratic Institute. I presented the work I had done on Legix.info including the transform of the U.S. Code into Akoma Ntoso.

All in all, the four days I spent in Washington D.C. were very worthwhile. Hopefully the outcome of that meeting will be better cooperation in the field of legal informatics. Clearly, after a dozen or so years of experience with XML, the time has come to start moving beyond the tentative first steps which have defined this field towards open standards and the benefits that come when everyone works towards common goals.

Standard
Akoma Ntoso, Standards

And now for something completely different… Chinese!

Last week we saw how Akoma Ntoso can be applied to a very large consolidated Code – the United States Code. This week we take the challenge in a different direction – applying Akoma Ntoso to a bilingual implementation involving a totally different writing system. Our test document this week is the Hong Kong Basic Law. This document serves as the constitutional document of the Hong Kong Special Administrative Region of the People’s Republic of China. It was adopted on the 4 April 1990 and went into effect on July 1, 1997 when the United Kingdom handed over the region to the People’s Republic of China.

The Hong Kong Basic Law is available in English, Traditional Chinese, and Simplified Chinese. For our exercise, we are demonstrating the document in English and in Traditional Chinese. (Thank you to Patrick for doing the conversion for me.) Fortunately, using modern technologies, supporting Chinese characters alongside Latin characters is quite straightforward. Unicode provides a Hong Kong supplementary character set to handle characters unique to Hong Kong. The biggest challenge is ensuring that all the unicode declarations throughout the various XML and HTML files that the information must flow through are set correctly. With the number of accents we find in names in California as well as the rigorous nature of California’s publishing rules, getting Unicode right is something we have grown accustomed to.

While I hadn’t expected there to be any problems with Unicode, I was pleasently surprised to find that the fonts used in Legix simply worked with the Traditional Chinese characters without issue as well. (Well at least as far as I can tell without the ability to actually read Chinese)

The only issue we encountered was Internet Explorer’s support for CSS3. Apparently, IE still does not recognize “list-style-type” with a value of “cjk-ideographic”. So instead of getting Traditional Chinese numerals, we get Arabic numerals. The other browsers handled this much better.

So what other considerations were there? A big consideration was the referencing mechanism. To me, modeling how you refer to something in an information model can be more important than the information model itself. The referencing mechanism defines how the information is organized and allows you to address a specific piece of information in a very precise and accurate way. Done right, any piece of information can be accessed very quickly and easily. Done wrong and you get chaos.

Our referencing mechanism relies on the Functional Requirements for Bibliographical Records (FRBR). This mechanism is used by both SLIM and Akomantoso. Another interesting FRBR proposal for legislation can be found here.

FRBR defines an information model based on a hierarchical scheme of Work-Expression-Manifestion-Item. Think of the work as the overall document being addressed, the expression being the version desired, the manifestation the format you want to information presented in, and finally the item as a means for addressing a specific instance of the information. Typically we’re only concerend with Work-Expression-Manifestation.

For a bilingual or multilingual system, the “expression” part of the reference is used to specify which language you wish the document to be returned in. If you check out the references at Legix.info you will see that the two references the the Hong Kong Basic Law are:

The expressions are called out as “doc;en-uk” for the English version and “doc;zh-yue” for the Chinese version. Relatively straightforward. The manifestations are not shown and the result is the default manifestation of HTML.

Check the samples out and let me know what you think.

Standard
Akoma Ntoso

Applying Akoma Ntoso to the United States Code

A few weeks ago the U.S. House of Representative’s Committee on House Administration held a one day Legislative Data and Transparency Conference. While I was not able to attend in person, I did listen in to the presentation via the live stream that was provided.

Of all the things I learned that day, one specific detail intrigued me the most – that there is an XML representation of the United States Code that has been made available. This XML is available at http://uscode.house.gov/xml. While the data is a little stale and some titles are mysteriously absent (Title 14, the repealed Title 34, and Title 51), it is a great source to begin experimenting with the United States Code.

One question asked by Sarah Schacht of Knowledge As Power was why there wasn’t very much interest in Akoma Ntoso at the federal level. For me, the answer wasn’t altogether satisfying but it did gave me an idea! How about I try to transform the XML files that are available into Akoma Ntoso as best I know how. That way, I could learn for myself how well Akoma Ntoso adapts to the needs of the US federal government. Admittedly the US Code is only one aspect of the overall issue, but it is a reasonable place to start.

The effort took me just a few days and now I have (almost) the full United States Code available in Akoma Ntoso. You can find it on my Legix.info site under United States Laws. Click on the “AKN” link in the upper right of each file to see tha Akoma Ntoso rendition. As a bonus, I also updated the United States Constitution that we had already prototyped to use the latest transforms for federal data. With thanks to Monica Palmirani at the University of Bologna and Flavio Zeni at UNDESA for their help, I was able to get what I think is a fairly reasonable rendition of the United States Code in Akoma Ntoso. Additionally, I have transforms into the SLIM formats and into an HTML presentation format.

So what have I learned? First of all, Akoma Ntoso adapted quite easily to the hierarchical model of the United States Code. That isn’t too surprising as the U.S. Codes hierarchy isn’t unusual and Akoma Ntoso is quite flexible in this regard. However, I do have an issue with managing a document as large as the United States Code. From what I can tell, the component mechanism within Akoma Ntoso simply doesn’t adapt to modeling a very large code. I need some sort of composition or inclusion mechanism that would allow the single US Code to be modeled as a composite document made up of many files, preferably in some sort of hierarchical arrangement. Currently I have modeled the US Code as 48 different “Acts” corresponding to the available titles within US Code, but this is far from ideal. Modeling the individual titles as acts is not accurate and still does not resolve the scalability issues but is the best I cold figure out at this time. In the past I found Monica and her team to be quite responsive to issues such as this so hopefully we will have a quick resolution to this. Maybe I simply don’t know enough about Akoma Ntoso to model a large document adequately.

My effort is just a start. I still have lots to learn about how best to apply Akoma Ntoso in various contexts. I will be refining my transforms as time allows in the weeks to come. Take a look at what I have done and let me know what you think. I welcome all feedback, both constructive and otherwise. My intent in publishing all the experiments and research that we do at Xcential is to share what we know with the legal informatics community in the hopes of fostering a more collaborative spirit amongst us all. So please send me your comments!

Standard
Process

Computerize vs. Automate

There are two words that have long been important to me: computerize and automate. The dictionary defines these words as follows:

Computerize

(kəm-pyū'tə-rīz') 
tr.v., -ized, -iz·ing, -iz·es. 
   1. To furnish with a computer or computer system.
   2. To enter, process, or store (information) in a 

        computer or system of computers
Automate

(ô'tə-māt') 
v., -mat·ed, -mat·ing, -mates. 
v.tr. 
   1. To convert to automatic operation: automate a factory.
   2. To control or operate by automation.

We often make the mistake of confusing these two concepts as the same thing. They are very different. Doing one does not imply the other. Using a computer does not mean you have automated and automating does not imply the need for a computer. I have found the confusion between computerization and automation to be at the very heart of the disappointment many have with XML solutions. Just because you’re using XML does not mean you are reaping the benefits that XML can provide.

Let’s take a step back and see where we are in history. We are living in a very important era. We are witnessing the transition from paper documents to digital information. This is the sort of transition that only happens every few hundred years, rivaling the advent of the Gutenberg printing press in the 15th century. The benefits of digital information are all around us. Just think of how efficient many businesses have become. As I write this, I am waiting on a parcel that was shipped from Shanghai just 4 days ago. I have tracked that parcel throughout its journey and I know with certainty that is will be delivered in the next couple of hours. That is a benefit of automation.

In my experience, governments don’t see the same benefits of automation that the private sector does. Why is this? Governments, like private industry, have readily computerized their operations. But when it comes to automating, governments tends to balk. There are many reasons for this – the perceived loss of jobs, the need to retrain, the lack of competitive pressures. But to me it seems that the overriding reason is tradition. Things are done the way they are because that is the way they have always been done. When it comes time to rethink tradition, it is sometimes hard to identify who you need to get permission from.

Whatever the reasons, the slowness to automate slows innovation when it comes to legislative information. Sure, the information is now online. Great! But what has been put online is most often just digital paper – like PDFs or unstructured HTML. That’s a half step into the future whilst looking to the past. Rather than taking advantage of the new medium and exploiting what now can be done through automation, we’re clinging to the centuries old models for how to manage and publish paper.

Why is this important? What does it matter? Well, for starters, let’s consider accuracy. For as long as I have involved in this field, the importance of accurately representing the law has been drilled into me. Yet whenever I start writing software to analyze laws, from anywhere, I am surprised at how easy it is to find errors. I’m talking about citations to sections of laws that don’t exist anymore or have more recently been renumbered to be somewhere else. I am talking about duplicate numbering or misnumbering. I am talking about common typos. These are all things that could be rectified with proper automation.

A pet project for me is point-in-time law. It is a subject that has fascinated me for a decade. It is very hard to do. Why is that? Because deciding which law is effective or operational at any point in time is really hard to do. And deciphering references between documents is riddled with ambiguity. This is because, whilst we live in an era where information around the world is stitched together at lightning speeds by computers, we still write that information somewhere in the text of a bill to be read by a person alone. Sometimes I find that quite ironic as I am constantly surprised at how few people actually read the bills – despite having strong opinions about them.

Isn’t it time we started treating legislation as digital information rather than as paper? Isn’t it time we went beyond computerization and looked towards real automation of legislation?

Standard