Much of week 3 was spent gently coaxing our procedure parsing code to spit out some pixels. The code, as it stands, declares procedural business steps in a work package to be either actualised or unactualised. Taking this as a starting point, it then traverses the routes between steps and - by means of logical and arithmetic operators - declares each route to be either TRUE, FALSE, ALLOWS or UNTRAVERSABLE. Taking this knowledge, once a route meets another business step, it declares the future potential state of that step to be either caused to happen, precluded from happening, allowed to happen or currently off limits. All of which gets rendered as a series of lists. If - and we recognise this is unlikely - you’d like to know more, you really should read our design notes. I mean, somebody should. We’ve slaved over them.
Whilst the list rendering suits some of our purposes, we’ve long intended to replicate the visualisations that team:Samu made for the old style maps, which were based on the route type. So this week, we added new code to generate a DOT file for each parsed work package, piped that into D3 which very kindly rendered an SVG of blobs and arrows, then decorated that with a splash of CSS. Why CSS designed to decorate an SVG uses completely different language to CSS designed to decorate HTML remains a mystery to us. If there’s one thing we’re always doing, it’s learning.
The results so far are somewhere between impressive and incomprehensible. Young Robert has taken over the map making reins, which is handy because not only is he skilled at information design, he’s trained to do it. He also has the ability to see colours, which is not among Michael’s many advantages in life.
As things stand, the pixels have already proved their worth in helping us to better understand and patch up both procedure maps and parsing code. Without maps, debugging has been a matter of working one’s way up the parse dump, trying to figure out where things had gone wrong. With the maps - plus working eyes and fingers - it’s much, much easier to trace the parse tree and find faults. Although, Michael still managed to spend three hours trying to fix our parsing code, only to find he’d typed ‘SUMMATION’ and not ‘Summation’. Proving that even with tools available, you can’t fix stupid.
Whilst Librarian Jayne and Michael might find our new maps handy, they are rather more complicated than the maps our crack team of librarians have grown used to. Which led to Friday finding Jayne, young Robert and Michael head down in CSS and pixels attempting to simplify matters. Not, it must be said, with much success. Removing a step in CSS does not remove the routes into it - obviously you might say - so we end up with more split ends than a poodle-permed rocker. Whether we’ll have more luck tinkering with the dot file generation than the CSS remains a job for next week.
It should, perhaps, be pointed out that the procedure parsing pixels do not, as yet, take account of Michael’s festive season efforts to apply plausibility scores to steps declared as allowed to happen. This is partly because he’s since noticed at least one step is returning a plausibility score in excess of 100%. Which we think might suggest an error in his sums. And partly because JO Jane pointed out that figures for steps taking place in the House of Lords should really be based on instruments that have been in the House of Lords. And not those before the House of Commons only. A good catch from JO Jane there. Whilst the rest of you might be developing an addiction to Wordle, Michael’s weekend puzzle solving comes via JO Jane’s admirable pedantry and some blasted SQL. Fun.
If half of the week was spent tidying the loose ends arising from our switch to logical and arithmetic procedure maps, the other half was spent planning for the future. It is, after all, a new year, so what better time to make resolutions we’ll struggle to keep. Over the course of the last week, our regular reader may have noticed a few changes to our beloved procedure model. In short order, these are:
A new class used to declare the display depth of a step in a procedure. The need for this arises from the fact that, whilst we store dates on business items, we do not store times. When a work package sees lots of business items happening on the same day - an occurrence often occasioned by things both Brexit and Corona related - the website doesn’t know which order to display them in. Which means we often see steps describing the conclusion of a procedure before we see the passing of an approval motion. Capturing the display depth, should, we hope, fix this.
New classes around step collections and step collection memberships. A whole bunch of use cases around grouping steps has arisen over the past year, from suppressing some steps from website display, to assigning steps to bill stages, to declaring steps to be starting steps, to declaring steps to be concluding steps. And so on. And so forth. We hope that some combination of display depth and step collections will help make the website rather less cluttered and our code rather less hard-coded.
A new class for legislature has been added, allowing us to both group our Houses into one UK Parliament and to declare steps around legislative consent motions to have happened in one of the devolved legislatures.
A new class of route availability has been added to better cope with changes in legislation, standing orders and orders of the Houses. The model we currently have allows for a route to be closed and reopened but only ever once. Should a standing order be suspended, then reinstated, then rescinded, we wouldn’t have been able to cope. Luckily that is not a thing we’ve seen in the time we’ve been mapping procedures. But one never likes to say never. And, like good scouts, we always like to be prepared.
And, finally, the citation class has had a small spring clean. Wherever our maps are informed by legislation or standing orders, we make every effort to cite the relevant material. So far, those citations only live in the form of pixels on maps, there being no slot in our database to store them. This is another thing we aim to fix in the coming months.
Work remains on reshaping our procedure model. We think we might want to introduce the ability for procedures to belong to procedures. Our current workaround involves assigning routes to more than procedure, but this approach is not what one might call efficient. And with Anya standing by with her time and motion clipboard, efficiency is everything to us.
On the subject of Anya’s efficiency drive, conversations with Silver saw the recent introduction of a new concept annotation class to our utility model. This is loosely based on the web annotation ontology and designed to capture not only the relationship between a document and its subjects, but also the act of subject indexing the document, when it happened and who did it. We now think we might want to do something similar with procedure actualisations, which currently exist as a object property but which may well become a class. All this so Anya can track both time and motion in order to hand out her newly minted Librarian of the Week medals. And yes, we do know about RDF-Star. We just don’t like it.
Way, way back, well before Christmas, Librarian Jayne posted a thread on recent developments to both website and queries. Friend of the family John picked up on one tweet and questioned the nature of the enabling act URI we were pointing to. Why, he wondered were we pointing to the Act as it exists now - for a moving window of now - rather than the Act as enacted. This week we finally got round to replying. A short email conversation covered both the form of the URI we store and the form of the URI we should publish. Our register of legislation URIs is used for two purposes. The first being to subject index parliamentary material. So our crack team of librarians can say, this debate, in Hansard, is about this Act in the most general terms. The second being the same crack librarians taking a statutory instrument and pointing it at its enabling Act. Acts are not unlikely to change over time. Which means the powers it may delegate may also change over time. And the nature of the SIs it may enable may likewise change.
Whilst it makes sense to store in the most generic fashion possible - there is little point in us replicating the work of TNA - we’d also like to be able to point at the Act as it existed at the time any delegated legislation was made. Which means we’ve decided to store the ID / work form of the URI, and amend Jayne’s SPARQL query to take that URI, grab the made date of the instrument and smush together a URL to the Act at the time of making. Which we hope will satisfy everyone. Not least John and team. Our Jianhan has picked up the URI migration task, our Jayne the SPARQL munging. We hope to have something to show shortly.
No further work has taken place on our mock data for written questions and answers. Mostly because no one has asked for any. That said, Librarian Ned has dived into Parliamentary Search in pursuit of stats. It turns out that, of 102 work level statements, 99 had an expression in each House, with only three having a single expression. And that, always in the House of Commons. Of the 99 pairs, all had identical titles, three pairs were expressed on different dates and four pairs were expressed by different government departments. Proof, if proof were needed, that our decision to tart up our written statement model a dash of FRBR was not unwise.
Sometime late last year, our crack team of librarians took over management of a system called MNIS. Or the Members’ Names Information System. Or at least the House of Commons bit of MNIS. Or at least some of the House of Commons bit of MNIS. We haven’t typed much about it here because everything was new and it took a while to get appropriate - and appropriately trained - bodies in place.
This week, librarians Anna, Emily and Phil have been mostly fretting about the display of party affiliations on the website. The House of Lords had asked for a change to the display logic, to no longer show a Member as being affiliated with a party or other parliamentary grouping during periods in which a Member was not actually a Member. If an hereditary peer left and later returned as either a life peer or an excepted hereditary, the dates displayed for party affiliation span the period of first membership, the period they were elsewhere and the period of second membership. Which is less than ideal. Changes to this logic are made more difficult by the differences in the Houses. Whilst a Member of the Lords may be considered a Member even during periods of dissolution, this is not true of Members of the Commons. And if a person is not a Member, they cannot be affiliated with a parliamentary bloc. Obviously. More patching up of ‘party’ affiliation dates may be required, but we think we know the way forward.
In other MNIS news, our query library is now fully operational and growing on a weekly basis. Access to GitHub has been granted and all librarians are now fully equipped to publish. Super stuff.
Librarian Anna has been busy tidying the Rush data. Shedcode James has been busy normalising her efforts. Which means we now have normalised data for trade union connection types and much tidier data for the number of seats in a constituency. Yes, some constituencies used to return more than one Member. Odd the things you learn.