Hello, I’m Anya. I’m a librarian. This is Michael who occasionally wishes he was a librarian.
We’re going to talk about data, information management and this chap: a fellow librarian, who we’re sure you’re all familiar with...
… and we assume you’re also familiar with this. Erskine May’s work on codifying the custom and practice of Parliament.
The hierarchy on the right has been repurposed from the work of Paul Evans. We do have a different one for the Lords, but the slides are only so big. It’s an attempt to describe the components of procedure. The size and sequence of the blocks broadly correlate to the mutability and the “reach” of each component in procedure.
Paul added he’d prefer “improvising from first principles” to muddling through. But again… the slides are only so big.
And I expect you’re familiar with this: for the first time an edition of Erskine May is available to read online.
We’re sure everyone agrees this is a GOOD THING.
But our talk has something of a conceit.
If Erskine May had had a computer, would he have written a book?
Erskine May online is a huge step forward but whilst it’s on the web it is not in the web or of the web.
Now I’ve introduced the conceit of our talk, here’s a caveat:
We won’t be talking about the intricacies of procedure. We’re probably the least qualified people in the room to talk about that. We’re certainly not going to talk about procedural bloat or procedural reform - there’s another talk tomorrow for that. We have no opinions here and we wouldn’t claim them.
And a second caveat:
We’re also not going to talk about machine learning or artificial intelligence. General purpose artificial intelligence doesn’t yet exist and may well never exist.
Machines don’t learn and can’t be taught.
They can be trained - like my dog Conker: given enough things of a similar pattern they can recognise other things fitting that pattern. But whilst we can feed them data, the machines can’t make that into information, still less knowledge. They can’t take that training, combine it and apply it to new situations, because machines are neither adpative nor exaptive.
We are going to talk about modern information management and how procedure can be codified in a way that is legible to machines.
This isn’t a talk about computers. We’re as interested in computers as Erskine May would have been in a printing press.
Before we get back to Erskine May - just when you thought I was on track - we want to talk a little about “websites”.
Making websites is straightforward. We’ve been doing it for a while.
This graph shows the number of web domains in existence between 1995 and 2011.
It seems fairly clear that making websites is a solved problem.
Whilst making websites may be straightforward, a website is only the tip of an information iceberg.
This point is particularly true and particularly relevant for Parliament: which we might think of as a mechanism for ingesting, processing and producing information.
The inputs and outputs are less tangible than for say Pret...
While making websites may be trivial, designing and building a system to store the information needed to drive a website in a way that’s comprehensive, *integrated* and semantically true to Parliament is harder.
Designing data models that accurately reflect an organisation and don’t break under change is harder still.
For a complex organisation like Parliament it’s especially hard. Though we would say that.
Building a culture that appreciates the value of data, and understands the rewards of, and directs sufficient resources to information management is even harder.
In many cases, it’s not been anyone’s job to maintain accurate and timely data, beyond the immediate needs of a particular task or process.
There is no canonical source of government departments, laying bodies, ministerial positions, parliamentary periods, sessions or sitting days.
And finally you hit job changes and union negotiations and the event horizon of the possible.
So making websites may seem simple, but - under the surface - there is a lot of work to be done.
We can understand websites as a vehicle for information dissemination. But even after doing the work, a new website doesn’t mean the information dissemination problems are solved. It’s not 2006. Most people get their information about Parliament from other sources.
Parliament is as much a wholesaler as a retailer of information.
People get most of their information about Parliament through media organisations such as the BBC, ITN, Channel 4, The Daily Mail, The Times, The Guardian...
… and increasingly from Wikipedia, Google, Facebook, Twitter and so on.
Last year, more than half of Google searches stayed on Google, because Google met the user’s information needs directly. People are content with what they find there.
This in itself is not a problem, I’m not describing a market in which Parliament should seek to compete.But we need to acknowledge that people are increasingly unlikely to visit a website.
Publishing structured data is often a better way of making information available directly to end users. Parliament needs to be a better wholesaler.
But that’s a whole other talk.
So, what are the barriers to delivering any of this?
This is a diagram indicating some parts of Parliament.
The big columns are the two Houses.
The narrower columns are offices in those Houses.
And the rows indicate functions within those offices.
Parliament has tended to commission software to digitise existing functions within individual offices.
Papers are laid here, motions tabled here, results of decisions taken here, division data entered here.
The results of the commissioning of software to digitise individual functions can be seen in this diagram which shows how information is structured in data.parliament. Data.parliament was an early attempt to make Parliament’s data available in a structured and open way.
But the structure of the information Parliament ingests, processes and publishes is fragmented.
The oval at the top right describes division data. Who divided in what way, who the tellers were …
… but this data isn’t joined to the motions or motion amendments or bill amendments those divisions were on.
Attempting to make software on top of this - i.e. data.parliament - is like trying to complete a jigsaw with no picture on the box.
This is the result of all this expressed as individual websites.
We have over fifty subdomains of parliament.uk and growing. The existence of subdomains is not in itself a problem, but it is a symptom.
The links between these subdomains are sparse and do not adequately reflect the semantics of Parliament.
So we know we have problems. We have disjointed data silos that lack the potential to ever be greater than the sum of their parts.
And we ask, what’s missing from this picture?
What strings hold all this together?
And the answer, perhaps unsurprisingly is...
This, for example, is a much simplified view of some of the functions included in the procedure for statutory instruments.
To tackle the lack of joins between systems, we;re designing a model of parliamentary procedure.
It provides a means to describe individual processes using elements that are common to them all.
The procedure model is of two halves.
The bit on the right is used to describe a procedure in the abstract: being a set of routes through steps, some of which allow logical combinations to be described.
This allows us to state that <this> and <this> or <this> but not <this> having happened …
… then this other thing is allowed or caused or precluded from happening.
Taking this abstract model we can overlay the details for a particular procedure.
This is a work in progress to describe the public bill procedure.
On the left is the House of Commons, on the right is the House of Lords - bicameral procedure is indicated by the intersection.
The bits around the edge are activities outside Parliament, including the Queen and her first-born at the top left.
There are print outs on the walls which will be easier to read. And if you have questions we’re very happy to chat.
Zooming in on a tiny fragment of the SI procedure.
It uses our procedure model syntax to codify scrutiny reserve for affirmative instruments according to House of Lords public Standing Order 73.
And it says...
In order for the government to table a motion to approve the instrument in The House of Lords, it must have been laid into the Lords AND not withdrawn from the Lords AND...
...either the JCSI must have come to a decision OR scrutiny reserve under Standing Order 73 must have been suspended.
Zooming back out.
Once we’ve recorded all the possible steps and routes in a procedure, we can tell the machines to generate the maps.
So this is a machine-generated map of the draft negative SI procedure.
Back to the procedure model.
The left hand side of the model describes what happens to a thing subject to a procedure: a bill, a statutory instrument, a treaty
Each specific business item - a laying, a tabling, a debate, a decision, a referral - is related to an abstract form of that type of item.
This is a map of the Higher Education (Registration Fees) (England) Regulations 2019 subject to the made negative SI procedure.
Each grey blob is a procedural step that has already happened. And because we’ve captured the logic of the procedure, we can also say what might happen next. And what won’t.
So each orange outlined blob is a procedural step that may now happen, as a consequence of what has already happened.
And procedural steps that are precluded are no longer shown.
There’s a map like this for every SI laid since the start of 17-19 session. And they’re all on the web.
The first thing we built on this data was a website to track the journey of individual SIs through procedure.
We then expanded that to do the same for treaties.
But the website is the tip of an iceberg. And the simplest bit of the iceberg.
For the people in this room, we think the most important output is having a pot of data that can be queried for precedence.
Because we now have a description of procedure that's legible to machines it’s possible to interrogate procedure in ways that were previously difficult, or impossible. And certainly not repeatable.
So we can now ask when X last happened. And when X last happened but Y didn’t. And when both X and Y happened. And how many times X or Y happened during a session.
This is one example showing the number of days between laying and approval of draft affirmative instruments.
HT Phil Gorman in the Commons Library.
The number of days between laying and approval is calculated in calendar days rather than sitting days because we don’t yet have a reliable source of sitting day data.
This is available online allowing you to hover over each dot and see the name of the instrument and the exact number of days.
More importantly, it is repeatable.
The instrument that took the longest time is the Crime and Courts Act 2013 (Commencement No. 18) Order 2018, at 253 days.
And the shortest: European Union (Withdrawal) Act 2018 (Exit Day) (Amendment) Regulations 2019, with two days between laying and approval.
https://mognar.github.io/parly-data/draftaffirm.html - you can hover over the points and see the name of the instrument and the exact number of days between laying and approval.
So back to the question.
What would Erskine May do?
We think possibly…
If he’d had a computer, he would have used it to build a graph of knowledge of parliamentary business. And built a precedence engine out of data.
Or a data platform if you will.
This is an area we’d like help with exploring next.
Once we have procedure data and instances of things subject to that procedure, the maps can be annotated with private notes and correspondence, to build something more like an intelligent, procedurally aware filing cabinet.
And with that request for help, we’d like to thank this bunch of people. Some from the Commons. Some from the Lords. Some from outside our walls. They’ve all helped us in a variety of ways.
What would erskine may do?
Picture of Erskine May (the
What we’re not
This is the work we are doing:
● building one source of truth for Parliament,
● joining up the data in a way that is
semantically true to Parliament,
● doing that with the domain knowledge of
clerks, librarians and external experts.
… thank you!
Illustrations from The Noun Project
Adrien Cocquet, Pawel Rak, Setyo Ari Wibowo,
Idealogo Studio, Jesus Puertas, Olexandr Panasovskyi,
Marie Van den Broeck, Dimitrios Stamatis.