It may surprise our reader to learn that not many moons ago at least one of your correspondents did not know what a statutory instrument was. Let alone why Parliament should take an interest in such things. It took JO Jane patiently walking us through her collection of many and various flowcharts to make any sense of it. Our minds drift back to workshops in the stickle brick castle that was then the home of the Parliamentary Computational Section, where plans were planned and wireframes sketched for what was to become the SI service. Parliament’s website is mostly fine when it comes to documenting what has happened. It is less good at showing users what is likely to happen next. To work that out, one needs a knowledge of procedure. Which means a knowledge of the legislation, standing orders, Speaker’s rulings and precedence that underpin procedure. Which is hardly common knowledge.
Early wireframes divided a work package page for a statutory instrument into four sections: one for the instrument itself, one for things that had already happened, one for things scheduled to happen and - breaking slightly with tradition - a section showing what was likely to happen next. JO Jane’s various flowcharts indicated we’d have to model some kind of process flow. It was from this - several whiteboards later - that our beloved procedure model and maps emerged. It would have been simpler and quicker to build the SI service as another link hub, with no knowledge of the underlying structure of procedure. But then we wouldn’t have been able to build our sparkling SPARQL library to query precedence across instruments. And the underlying model would have been quite dumb; incapable of extending our light cone of procedural possibilities into the future.
The thing about a process model is, given accurate maps and the means to populate them with your journey so far, you can extrapolate into the future. At this point your maps begin to function like sat navs, and the roads ahead become clear. This at least is the theory. But theory can be hard to reconcile with practice. All of which led to Michael spending the best part of the last few weeks attempting to write code to parse a work package subject to a logically mapped procedure, in an attempt to show not only what has happened but what should happen next, what might happen next and what definitely should not happen next. His efforts have met with what can fairly be called limited success. Waking and sleeping hours have seen him preoccupied with traversing routes through procedures, in a desperate attempt to save us from the embarrassment of having to tell JO Jane that, actually, procedures cannot be parsed and the space of future possibilities was not a space it would be possible to explore. Given the amount of words we’ve written and the number of presentations we’ve given, this would have been unfortunate at best. But this week …
This week, our code parsed its first procedure. Unfortunately we were not in the office; cries of joy and ripples of applause did not ring out across SW1. And as pubs remain closed, pint glasses went unclinked. Nevertheless, we cannot pretend to not be pleased by this. A cry of “PRAXIS!” may even have escaped Michael’s lips. That in itself is not unusual.
The code is less than optimal, there is still work to do. Happily, there is always more work to do. You might, for instance, have noticed that the machines think laying into both Houses is a still a thing that should or might happen. Even though it’s quite clearly happened. This is a side effect of how we currently store laying dates, which is much too tedious to go into here. A ticket has been raised for the attention of our Jianhan. In the meantime, young Robert and Michael sharpened their tiny chisels and once more embarked on a mission to refactor and re-comment the code. Resulting in what might be their most obtuse comment to date. We’d all like to thank Samu for - once again - pointing our noses in the right direction.
In more humdrum procedure modelling news, Librarian Jayne and Michael continued to remap the monstrosity that is the made affirmative procedure - or perhaps, more accurately, procedures - to our new logical model. The Commons and Lords sides and the ever- and omni-present JCSI are mostly done. It only remains to wrap with options of ‘remaining law’ and ‘stopping being law’ and to pop a couple of ‘procedure concluded’ bows on top, and we are done with all SI procedures. At least for now.
Now that our work to enable enabling Acts is enabled, we’ve been wondering if we could save ourselves a little work populating it. The impetus for adding the enabling Act model is to identify proposed negative statutory instruments by their enabling Act; to separate enabled by the European Union (Withdrawal) Act 2018 from enabled by the European Union (Future Relationship) Act 2020. That model is simply begging to also be populated with links from SIs to their enabling Act or Acts. A chat with John, Matthew and Catherine raised the prospect of calling their beta legislation API with the URL of an SI and getting back all enabling Act details. Which would make linking the two trivial. This week, Catherine sent through the details of the new API. Enabling Acts is not there yet; hopefully it will be soon. In the meantime, Jianhan has started to grab Act data in the hope we can populate our internal search platform in a more efficient way than DevOps folks adding triples by hand. Thanks TNA people.
Anya, Jianhan and young Robert have been busy beavering away on ingesting petitions data - first into the data platform and from there, in a slightly reduced form, into our search and indexing triple store. They’re waiting on people at the other end of the pipes to retain Government responses that have been succeeded by a more recent response, but everything else is proceeding smoothly. Mostly. There was a brief kerfuffle when Anya added petitions as a new subtype and the facet refused to show up in the web interface. But a quick smack from Jianhan’s trusty computational spanner seemed to fix that snaggle. There is almost no computational problem that can’t be fixed by hitting the thing with a spanner.
If you’ve been following along from home, you’ll know that we’ve been wading knee-deep through David’s peerage database. Whilst David’s data is peerage centric - describing the first holder only, and the letters patent by which the peerage was granted - we were keen to reshape it into something that can also capture subsequent holders. We now have a table for peerages, a table for people and a table joining the two, to hold the peerage holders. Librarian Ned compiled some test data to check the newly reshaped database could hold everything we needed it to. No problems were spotted. Now Grant - our new friend at the College of Arms - has started to compile his own spreadsheet and the data has been loaded into the website, the Barony of Blythswood being one such example.
In a nod toward linking the peerage data, Michael has added external identifiers to people - Wikidata, MNIS and Rush - and peerages - for now just Wikidata. So far only populated for one person and one peerage. If anyone knows of a librarian with time on their hands …
A wee while back Anya took issue with our implementation of persistent URLs for standing orders. Whilst the URLs functioned perfectly well, a single order divorced of all context was not, we were told, what anyone would expect. So Michael added a new redirect URL. If the order is extant the new URL redirects to the current revision set, anchor linked to the order in question; if the order is extinct it redirects back to the orphan order. At some point last week, Michael popped into a twitter conversation to share his opinions on the separation of identification from naming conventions. He later realised that having added the new redirect URLs they were not described anywhere, so nobody knew they existed. He’s added a signpost to the redirect URLs from both order and fragment pages. And even added some JavaScript to copy them to your clipboard. Should you be so inclined. This is his first bit of JavaScript in about 20 years and will probably not work on your machine.
Last week we reported that the House of Commons Library had fielded its first enquiry the answer to which lay at the far end of a Wikidata query. This week, it only went and happened again. The web of Members and places and Government positions grows ever richer and ever more entangled. Thanks to Andrew and Simon for lending a helping hand.