2022 - Week 20

A peerage database - finally live

Way back in the mists of time, in the era before lockdown, we came to the conclusion that we needed a proper model for peerages. Our current efforts describe a title for a Member but have no notion of the way in which inheritance causes different bottoms to occupy the same seat at different points in time. A problem that also extends to our modelling of bishops. More of which in future episodes.

Knowing where to start with a peerage model proved tricky, none of us being experts in matters of letters patent, special remainders, ranks and rank labels. Luckily, we struck gold when David generously handed us his lovingly compiled database of peerage creations. Which meant we at least had something to poke at. Poking a database being one of our favourite ways to explore a domain. David’s data describes the act of peerage creation in the UK and, by extension, the first holder of any hereditary peerage. It does not describe any subsequent chain of holders. We got luckier still when David and College of Arms Grant offered use of their considerable brains to help with the reshaping task. Librarian Ned chipped in to fill gaps with his extensive librarian skills. Which means we now have a model that can be used to describe peerage creation, types of peerages, kingdoms in which peerages were created and holders of a given peerage over time. A model that young Robert and Michael are preparing to turn into example RDF for Viscount Thurso. Lovely stuff. Thanks David. Thanks Grant. Thanks Ned.

A side effect of this modelling effort was a newly reshaped database compliant with the new model. The new database also contained sample peerage holding data and a handful of pre-UK created peerages. Sadly we lacked the capability to make this new database editable and available online. So we approached Paul, thinking this new dataset would compliment the Rush database of Commons Members which the History of Parliament Trust already host. Happily, Paul was in agreement and stumped up the funds to pay James to turn our Postgres scribblings into a properly supported website with built-in editing capabilities. This week, David came back with a fresh dump from his Access database, James converted to Postgres, Michael ran our reshaping tasks, Ned realigned identifiers for side-loaded data, we sent the new data back to James and we are now live. If peerage data is your thing, please take a look.

Now we have the database and the ability to easily edit it, we hope to add more in the way of pre-UK peerages and more in the way of subsequent holders. Most probably concentrating on those hereditary peerages being held by current and potential Members of the Lords. If you’re a peerage expert and would like to help out, please do get in touch.

Always be shipping

A new peerage website was not all that went live this week. Librarian Jayne and her computational helpmate Michael also pressed ‘push’ on a new version of our beloved egg timer. This time handling four - count ‘em - different calculations for various flavours of legislative reform orders and updating the instructions page accordingly. A small task made much easier by already having calculation code matching the definition of days set out in the legislation. In truth, it took longer to agree labelling with JO Jane and JO Philipp than it did to amend the code. Which is always where the real work is. We hope they are happy.

Gender, sex and data models

There have been a number of occasions of late when we’ve had cause to question our notions of sex and gender. Which is why Wednesday saw an actual in person meeting with Research Director Grant, Librarian Anya, House of Lords Kirsty, Michael and a whiteboard. Well, a flipchart. We’re not allowed to write on the whiteboards. First up for discussion was the Gender Recognition Act 2004 which, it would seem in hindsight, might be better titled the Sex Recognition Act. Legally speaking, there are two recognised sexes: male and female. A person having one sex at one time. Either as registered at birth or via a Gender Recognition Certificate. Or sex recognition certificate if you will. Gender is a whole other kettle of fish, the list being inexhaustible and more a matter of how you feel - gender identity - and how you express - gender expression. We now have a straw man database schema to capture gender. The sex part being none of our business.

Return to public bill mountain

We are pleased - nae delighted - to announce our - and we believe the world’s first ever - fully mapped logical and arithmetic legislative consent motion procedure. This one for the Senedd. Tweaks having been made to bring things in line with feedback from Sarah and Gareth, the resulting pixels were bundled into an email and dispatched in the direction of Cardiff. This time round, gold stars were indeed awarded and yet another card made it into our out tray. Thanks Sarah. Thanks Gareth. Onwards!

Prodding the procedure parser

As our dear reader will well know, we are prone to the occasional descent into hair splitting territory. Every time we spot a hair, we have a tendency to split it. Which is why Monday saw Librarians Anya and Jayne and ‘computational experts’ young Robert and Michael meet in pixels for a chat about what a business step might be and what a summation step might be and how we might choose which type to create. Something you might think we’d know by now.

Our standard explanation of a business step is something that can be actualised by a business item happening in meat space - ideally, a business item that can be evidenced by the existence of a link to a report or some such. The majority of our business items may take place within a House - occasionally as joint activities - or outside of Parliament. The making of a statutory instrument being one such example.

Summation steps, on the other hand were added to our artillery as a means of summarising a set of logical and arithmetic operations that must yield true in order for the summation step to be true. Like margin notes in a book, they save our poor brains and fingers from tracing routes back through logical steps and arithmetic steps in some attempt to remember where we are and how we got here. A summation step not being actualised by a brarian, it has no state until the procedure is parsed.

The problem here being the current SI and treaty websites have no notion of a parsed procedure, only ever displaying actualised business steps. Which means, if we want users to know that a certain state has been reached - for example, it has been determined that a legislative reform order will travel down the super-affirmative route - we need to make that state a business step and our crack team of librarians need to actualise it. This, then, is why our design notes describe some business steps as redundant. If the website code were capable of parsing the procedure and we had some degree of control over the visibility of both actualised business steps and parsed summation steps, the website could display a mixture of the two and reduce our brarian workload. Sadly, we are some way off such procedure parsing cleverness being added to website code, so, for now, what is a summation step and what is a business step will remain an ‘editorial’ decision based on our understanding of the procedure and our understanding of what steps are useful to display to a user. That said, we have at least done the thinking. And thinking is also work.

In other procedure parsing news, our Jianhan has been hard at work stripping out all mention of our previous route based procedure maps from code, database and triplestore. Which means our staging environment and our live environment are, at last, fully back in sync. Further development now being possible without tripping over our shoelaces. Jianhan has also been tweaking the procedure parsing code which means none of our steps now propagate untraversability and our AND steps now allow for both inputs and outputs with a status of ALLOWS. Cheers Jianhan.

Member data

Over in MNISland, team:LibrarianPhil have been busy working out which party affiliations to close. We have a good many departed Members - some now deceased - without an end date on their party affiliation. This appears to have originated in a change of information management policy that wasn’t ever quite documented and wasn’t ever quite carried through to fruition - some House of Commons Members having House incumbencies and party affiliations that span Parliaments and stretch over dissolution periods, whilst others having incumbencies and affiliations per Parliament. The former making for easier querying one suspects. The latter being correct. Party affiliations pre-2015 all appear to fit into the former camp and, where Members have now left, no end dates have been applied. As part of a fix to the website released to the website by colleagues in Software Engineering, we’ve committed to plugging these gaps. Phil has now written a query to extract the data and made a plan to fix it.

Fascism, nazism and taxonomic transitivity

This week also saw our team of crack librarians faced with something of a taxonomic transitivity conundrum. A enquiry arrived, asking why a question - which was most definitely about nazism - had been subject indexed as fascism. Taxonomically, the problem arises because nazism is declared to be a synonym of fascism. Rather than a narrower concept. So parliamentary material on the subject of nazism can only be indexed under fascism and a search for either fascism or nazism will return everything indexed with fascism.

In some more ideal world, nazism would exist as a separate concept, with material about nazism indexed with nazism and material about fascism indexed with fascism. The search software atop the data would allow for transitivity down the hierarchy and a search for nazism would return only material indexed with nazism, whilst a search for fascism would return material indexed with either fascism or nazism.

Sadly, we do not live in an ideal world and such transitivity is currently unsupported. One day, we hope. Until then, we have a choice between optimising for recall, as at present, or splitting the two concepts and optimising for precision. Without transitivity we cannot have both. Which is the best - or better - approach remains unclear. Literary warrant - do Members make the distinction in speech - and user warrant - do searchers make the distinction in forms - are both under active investigation.