Anya and Michael have been making weekly-ish exceptional weeknotes since 2019. Their latest weeknote – 2025 – Week 40 – is a great place to start because it starts with a rationale of the why behind their ongoing project.
A possible misnomer / starting from first principles
Our dear reader will be aware that for the past several years we have been attempting to build an open data platform. Please believe us when we add, it’s felt longer on the inside. A series of meetings this week caused us to question not only how we were going about that but also to what purpose. These are some notes on that.
Unlike many organisations, the open part of the equation has never been a difficulty. Parliament, like everywhere else, has non-open data in the form of HR, finance and facilities. That’s not the flavour of data we’re talking about. Our concerns relate to the procedural and the procedurally adjacent. The openness is helped by the existence of the Open Parliament Licence – think of the Open Government Licence, with the addition of a portcullis or two. Which itself is not so different from the Creative Commons Attribution licence. In our context, openness is a solved problem.
In many ways, having a platform to publish that open data is also a solved problem. Parliament’s Developer Hub makes available a set of open APIs, all published under the aforementioned Open Parliament Licence. It could be said then, that Parliament already has an Open Data Platform, at which point, you may be wondering why build another one. Well …
The problem we’re battling is not openness but Conway’s Law. Parliament’s approach to internet connected computers has tended to concentrate on digitising existing office functions. An example: the Journal Offices have always been responsible for the receipt of papers laid. Back in the olden days, this took the form of bundles of papers being transported down Whitehall and into Westminster. Happily, the process has been digitised, meaning a lot less shoe leather is used up. All good stuff.
Less good is the system still only deals with that one function. It neither cares about nor implements description of the procedures that commence once a paper is laid. This is true for a myriad of other systems. Hansard knows what was said and who said it, but carries no semantics about the debate. It does not know that some contributions formed part of a second reading debate, nor which bill that debate was on. Motions may also be tabled electronically, but there is no data connecting those motions to any debate that ensued. The motion having been disposed of by division, the division system does not have any data describing the motion being divided on, nor the debate that led to the decision. Committee reports published along the way do not carry any data about what was being reported on.
For anybody attempting to follow the passage of a piece of legislation or a treaty through Parliament, you’d typically need some idea of which committees might take an interest, what days those committees tend to meet and where they publish their reports. This is quite an overhead for people inside Parliament, and still worse for the uninitiated.
For today’s post, I would like the reader to pay attention to a particular bit of the work of the PDS: the creation of a small array of Mastodon accounts so those who are interested in tracking a topic or legislation can do so easily. They are found on this page: https://ukparliament.github.io/ontologies/meta/bots/
I would like to see more sets of pages that allow interested users to be kept up to date on recent events, publications, or accessions using ActivityPub.
There is no reason to be stingy with the creation of ActivityPub feeds.
I was out with a friend who worked for Twitter and I asked them whether it would be possible for the museum to “create 200,000 Twitter accounts, one for each object in the Cooper Hewitt’s collection”. My friend looked at me for a moment, laughed, and then simply said: No.
In that blog post, Aaron reveals that the San Francisco International Airport Museum is using ActivityPub to create automated social-media bot accounts for all its exhibits and, possibly, every object it hold.
And why not! That would be close to impossible to do on a centralised service. But on a decentralised service under your own control, it is relatively simple. Perhaps I only want to follow the museum’s canteen, or I just want to engage with a specific artefact. The Fediverse makes that possible.
This reminds me of the Melbourne “treemail” phenomenon. Every tree in the city had an email address, ostensibly so residents could email maintenance issues for a specific tree. Instead, people started interacting with the trees and sending them little love notes!
And yet the Canadian Broadcasting Corporation still holds on to an old-media paradigm that the only way one should deliver content is directly to only the largest audience possible. At least, reason that they give to explain why they remain on X.
The representatives of the CBC do not address that the social media platform of X is literally dangerous to the well-being of millions of Canadians who are supposed to be broadcast to by the CBC.
It would do a world of good of those involved in media and social media had a better understanding of the standards and the protocols that are needed to make social networks safer for more people.
In his new book Move Slowly and Build Bridges, Robert W. Gehl tells the story of the activists, software developers, artists, and everyday people who have built the fediverse, a noncentralized alternative social media system. Unlike big tech corporations like Facebook, TikTok, or X, the fediverse is comprised of thousands of small, independent communities who use a Web protocol to communicate with one another.
I’ve not finished the book yet but I’m almost finished. I particularly appreciated learning more about how the standard of ActivityPub came about and how messy and miraculous it was and remains.
