XML in legislature/parliament environments

Last time I talked about KLISS I said I would talk about some of the reasons why a legislature/parliament is not a happy hunting ground for the blind application of standard IT architecture patterns from the document management/content management/publishing space.

The first, often quite glaring architectural non-sequitur goes like this:

1) legislatures/parliaments are full of very structured documents : bills, resolutions, journals, calendars, statutes, annotations...all have readily apparent structure.

2) XML is all about handling very structured documents.

3) Therefore, classic XML approaches fit legislatures/parliaments.

There are a variety of reasons why this analysis is, in my opinion, wrong but it will take me a number of posts to explain why.

Before I start, let me point out that XML *has* an enormous role to play in legislatures/parliaments but it cannot be simply applied blindly per the standard XML value model without causing significant problems. The 7 main reasons are:

a) the centrality of line/page number citation in amendment cycles

b) the complex nature of amendatory actions

c) the critical nature of fidelity with historically produced renderings

d) the fluid nature of work-in-progress legal assets

e) the complexity of amendment cycle business rules that often pre-date computers and cannot be changed to make life easier for modern software

f) the subtle inter-play between legal content and legal content renderings

g) content aggregation and derived document types

Next up : "the centrality of line/page number citation in amendment cycles"

law.gov goes to Washington

The law.gov initiative has arrived in Washington. Stream of today's meeting at the Committee on House Adminstration is here.

I strongly recommend the law.gov video set now up on Youtube covering the meetings held at a variety of law schools over the last few months. Much fascinating stuff.

KLISS. First things first. What is a legislature/parliament?

I thought I'd start talking about the technical aspects of KLISS at the highest possible level...

Before progress can be made modelling any domain inside a computer system, it is necessary to put a box around the highest possible view of the domain, thereby establishing what is inside the model boundary and what is outside.

At the highest possible level of abstraction, a legislature/parliament is a black box, into which a corpus of law (at some time, T) is injected. The legislature/parliament then acts on that corpus to produce an updated corpus of law at some time T+1.

Thats the highest level model that I have found useful to start discussions of enterprise legislative architectures. Some interesting points about this:

0) The "Corpus of Law" is easier to state than it is to enumerate. It includes the primary law for the legislature/parliament obviously but also, depending on the jurisdiction, secondary forms of law and "softer" forms of regulation such as chamber rules.

1) The "Corpus of Law" subject to modification by the legislature/parliament is smaller than the corpus in force. I.e. federal level laws that bind in various ways, at state level, and yet are not modifiable at state level. Some organizations may adopt rules of order like Rogers or Masons, that are not modifiable directly.

2) Note the feedback loop. The corpus of law at time T is the input to the function (the black box) that produces the law at time T+1, and that then becomes the input for the next legislative act. This feedback loop is the primary source of complexity in legislative informatics.

3) Note the self reference. The corpus often includes laws that specify how laws are made. Those laws are themselves often subject to change inside the black box.

4) In order to qualify as a democratic entity, the transition from Corpus(T) to Corpus(T+1) must be rigorously audit trailed and that audit trail is *itself* an output of the legislature/parliament. I.e. journals, committee reports etc. that expose how Corpus(T) became Corpus(T+1).

5) Note the word "act". Legislatures/parliaments act on a corpus i.e. changes are proposed, debated and potentially implemented. The black box can be thought of as an event driven machine. A machine in which events happen (new bills introduced, amendments proposed, votes taken etc..) and these events cause down-stream events/actions.

6) In order for the audit trail to be comprehensive and accurate it must be able to cite - not just documents like bills, committee meeting minutes etc. - but cite those documents as they looked at arbitrary *points in time*.

Some formalisms I find useful in thinking through this model:
Speech acts provide a nice model for reasoning about actions and reactions, causes and effects inside a legislature.

Rigid designators provide a nice model for reasoning about citations and dealing with the incredibly rich, temporally laced, network graph that legislatures both consume and produce.

Eventual consistency provides a nice model for reasoning about the synchronization of all the disparate views of legislative outputs that must somehow be kept consistent: bill status, agenda minutes etc. etc., each produced in paper, PDF, HTML versions PLUS twitter feeds, rss feeds etc.

Peter Suber's paradox of self amendment is an excellent analysis of the problems inherent in a system that operates under a set of modifiable rules in which modifications to the rules must occur according to the rules set out in the set of modifiable rules :-)

Next time: some thoughts on the main reasons why legislatures/parliaments are very different animals to most process-centric/document-centric/publishing-centric organizations and why, most "classic" design patterns need to be modified if they are to be successful in Legislative Enterprise Architectures.

Phew!

Well, it has been almost *two years* since I came to live in Lawrence Kansas to work on the KLISS project. KLISS is by far the most all-inclusive vision for eDemocracy I have come across and it has been a very rewarding and very intense work, extending our core LWB product to be able to implement the vision.

So intense, that I have had little brain-space to devote to writing/blogging...

I hope to be able to devote some time to blogging/writing in the months ahead. The way LWB meets the challenges of the KLISS vision are, I think, interesting and I'm going to try to find ways to lay out the key technical concepts here.

When asked to outline KLISS I generally start by saying that KLISS is an application in the same way that Chinatown is a restaurant. It is absolutely vast in its scope. It touches everything from creating new bills to realtime display of legislative activity to remote testimony at committees to authentication of born-digital legal materials. And everything in between.

So anyway, if document management, or XML, or jurisprudence, or temporal logic, or political science, or event driven architectures, or democracy or digital preservation, or authentication, or legislative intent, or law.gov or data.gov or semantics is your thing, you might be interested in what will appear here over the next while!

If you work in this field or are involved in creating applications in similar areas, please get in touch. I'd love to compare notes.

Cohen plays Sligo

Typical. I move to the other side of the planet and then Cohen decides to play just down the road from my house.

Executable regulations. And so it begins..in Python

A couple of years ago, I wrote an article on ITWorld about how software may provide a way to improve financial regulation.

It appears that the SEC are heading in this direction for capturing the semantics of complex financial instruments...and doing it with Python to boot.

Blog comment spam hits 100%

I stepped away from my machine for a couple of days and today I find 60+ comment spams for moderation. I have taken to using a "super quick scan" followed by "select all" and "delete" strategy.

Sigh.