Augmenting from the outside
For November’s hack day we were joined by teams from the Science Museum and the V&A Museum who are collaborating on the Heritage Connector, a project which is building a linked data web of connections between their two collections, so the theme for the day was to explore this.
Neil and I wanted to take advantage of the Heritage Connector to make more connections between other collections and the NMSI and VAM ones.
We chose two collections, the National Portrait Gallery and the Royal Society’s Science in the Making; each of these sites includes pages devoted to individuals.
We didn’t want to do a mass data convergence exercise, but rather find a way to use the material in the Heritage Connector to enhance the existing pages on the target sites. Our vision was that the existing page on the NPG or SitM site would be extended with additional information. Although this is a hack day, we decided against hacking into the relevant sites and actually extending their pages; instead, we settled on creating a browser extension which would modify the page in the user’s browser.
The critical requirement here is to figure out the node in the HC corresponding to the person to which a page on the SitM or NPG site refers. There are quite a few attempts to create standard lists or controlled vocabularies of individuals, such as the pioneering FOAF; ULAN which we’ve often worked with in relation to our clients in the art world; and VIAF which comes from the world of libraries. In the Heritage Connector the core identifier, for people as well as everything else, is a Wikidata identifier (“QID”).
So we split the work into three parts: identifying the Wikidata identifier associated with a given personal page; using that to locate linked resources in the HC; and modifying the web page to display the additional information.
Rather than divide the work fairly, I undertook the first part, leaving Neil to do the other two. As an appropriate separation of concerns — which also made it easier to develop independently — we decided that I would make an API which the browser extension could query with a URL, receiving back either a QID or a null response.
(The fourth task of course should have been to come up with a snazzy name for our hack. Instead, we called it the Augmentanator.)
There could be all sorts of ways to match a person as represented on a page, to a relevant QID. If we were to do this on an industrial scale, the back-end service might contain recipes for particular sites: enabling it for example to locate name and life dates, which could then be matched against Wikidata to try to identify the correct person. Or some sites might contain another identifier, such as one of the ones noted above, which could then be matched against the Wikidata entries. It could even attempt named entity recognition against the text of a page, although the chances of that producing many accurate results would be slim. But whatever approach was used, it would probably cache known matches. So in the scope of a single day’s work, I decided to simply build the back-end service as a single database table (which we could imagine as the cache store) and an API which does no more than look up URLs in this table, returning a QID if there was an entry. That freed me to use any kind of ad-hoc methods to populate this table.
I had a cunning scheme for the NPG: I know that many of the person pages on the NPG site have a link to that person’s entry in the Oxford Dictionary of National Biography (DNB); and I knew that Wikidata has links to the DNB. So I first extracted a mapping from people pages on the NPG site to DNB identifiers. Then I went to the excellent Wikidata Query Service to see how I could find the matching entries for each DNB identifier.
I’m sure that this would have been easy… but in fact when looking at the data I realised that one of the pieces of data that Wikidata maintains for people is links to relevant pages in the NPG site!
So I simply requested Wikidata to generate a list of all the people known to Wikidata with a linked NPG page; and with a bit of reformatting that essentially populated the NPG part of the database.
Get Ben Rubinstein’s stories in your inbox
Join Medium for free to get updates from this writer.
When I went to look at the Royal Society part of the problem, it turned out to be trivially easy as well. About 75% of the ‘people’ pages on the Science in the Making site include a link to the person’s Wikipedia page. So I scraped those links from each Science in the Making page to get a Wikipedia page; and then for each Wikipedia page, scraped out the Wikidata link (you’ll always find this in the left-hand column), which gave me the QID. I used a third-party service to make a simple query API against the combined database. My job done, I settled down for a nap.
Neil writes:
While Ben snoozed on the bean bags, and seeing as I was lucky enough to land two jobs, I wasted no time in setting up the JavaScript toolchain for developing the browser extension. Once I’d done that, I started to think about how I was going to use the remaining hour of hackday.
Cheap JavaScript shots aside, two requirements I had were 1) to avoid having to constantly reload the extension and 2) to use React for the front end component. I decided to use this extension boilerplate to give me a head start.
The basic plan for the extension was that it should recognise when it was visiting a URL relating to a person; query various APIs; and end up with an object bursting with metadata and lovely images for each related thing.
There are two main components:
- One does most of the work in the background
- The other waits for things to appear and complains if it gets something it doesn’t like.
No, this isn’t some clever metaphor for our hack day team, I’m referring of course to the extension’s service worker and content script.
Each time a recognised URL is loaded, the browser executes the content script which uses the chrome.runtime.sendMessage() API to send a message to the service worker. The service worker then takes control of data fetching and processing.
The service worker submits the URL to Ben’s API, which returns a Wikidata ID. It then uses the Wikidata ID to query the Heritage Connector API. This API returns zero or more resources relating to that individual. Once the worker has possession of that data, it then makes another series of API requests to the relevant museum APIs to enrich the related items with object level metadata. It’s all then formatted in a friendly way, ready for use in the front end component.
Using React for the front end component might sound like overkill at first, but it allowed me to quickly throw together a semi-presentable interface, with a fancy slider and a select box to quickly switch between related objects for different collections.
At present the extension runs when it recognises URLs relating to people from either the National Portrait Gallery or Royal Society’s Science in the Making website. It’s not yet in the Chrome Web Store, and probably never will be. But it demonstrates the powerful opportunities that the Heritage Connector could offer.
