Thursday, February 1, 2018

A Closer Look at ResearchSpace.

Following on my earlier post about the British Museum's URIs getting killed by the deployment of ResearchSpace into production...

The first glimpse I saw of ResearchSpace was at the Linked Ancient World Data Institute in May 2012. We are fast approaching six years since the first demo I saw, and the project must have existed for at least a year before that. So we are at 6-7 years of development with $1-2million from the Mellon Foundation for an application ( that looks wholly underdeveloped compared to many cultural heritage platforms that I've seen (that were built in a fraction of the time with a fraction of the money).
Let's take a look, shall we?

Um, okay. Not the easiest starting point for a query interface of a museum collection. The interface eschews keyword search--this is a feature, not a bug, mind you (see

Essentially, you can only query by making relationships between different categories of information. If I just want to see the coins of Antioch, I have to sort my way through several iterations of expressing a query as triples. Now certainly there is some potential in querying in this way, but the problem is that this isn't how the vast majority of the public (general public or researchers interested in a specific portion of the collection) expects or wants to interact with the collection through a UI. Libraries, archives, and museums have been implementing faceted search of their collections (based on Solr, ElasticSearch, etc.) for over a decade now. There are facets in ResearchSpace, although they are not prominently displayed (click on the left to show via Javascript). Not all of the facets are terribly useful (some are 1:1 directly with the coin itself with regard to production events), but you do have to have some idea about how relationships are expressed between objects and concepts. I should also note that I'm skeptical that SPARQL-generated dynamic facets will be able to bear the load of production usage.

Okay, I got Things from Antioch. How to narrow? Add another query parameter. How about a Thing that is a Concept. What concept? Well, I have to select the relationship between the Thing and the Concept. "Has type". Useful to be familiar with modeling data in CIDOC CRM before you use the interface. Then I select "coin."

Oh. 0 results? There were definitely coins in the last page.

As it turns out, I really wanted things from Antiochia ad Orontem, but I also need to know that the emperor is expressed by the "refers to" property. "Refers to" appears twice, so you have to select the one with the person icon. There are times when the top-level filters conflict over overlap with the left-hand facets.

Coins of Antioch

User interface issues aside--certainly there is room for improvement here--the larger issue is the time frame and money it cost to arrive with this product. Having been funded by the Mellon Foundation, it would seem that both the data and the code should be open source, but the ResearchSpace code has never been opened, and therefore it is presently impossible to test, critique, or contribute back in order to make the platform better.

Aside from the fact that URIs don't dereference (failing the primary requirement of a LOD system), the UI is entirely driven by AJAX, making it complicated to paginate (clicking on a coin and then clicking back in the browser wipes out your facets and your page number) and impossible for a robot to crawl the collection, thus reducing access to the public who might happen upon museum objects through search engines. At the ANS, about 70% of all visitors to our Library, Archive, and Museum platforms come through search engines.

Even if you go to , what is actually there? A CURL yields the same basic HTML template. There's actually no useful information for a machine to extract--not even human readable versions of the data--and especially not RDFa or other types of microdata.

Content negotiation?

curl -H "Accept: application/rdf+xml"

No response. No HTML header metadata pointing to alternative serializations that can be requested by URLs. The whole system is antithetical to modern design--not just within cultural heritage, but everywhere.

ResearchSpace project managers have traveled from conference to conference in digital cultural heritage over the years, talking about the system and its advanced functionality, but the product we are seeing now falls extremely short of the hype. The problem has been in its management. It seems, from the outside, that there were never any achievable goals that could be reached in a concrete timeline. The ambition for the project grew to include IIIF, 3D annotation, and a host of other useful features.  ResearchSpace shot for the moon for its first public release. However, the project could have been released as a simpler framework years ago with these new features added in iterative development. With the code stored in Github, they might have been able solicit feedback from the cultural heritage community. Is ResearchSpace writing its own IIIF viewer? WebGL viewer? Is it using other open source libraries? Who knows.

There are a some cool features in the system--distribution analysis of categories based on your queried subset.

Material distribution of Antiochene coins of Elagabalus

So there's obviously potential. But between the high cost, the long duration of development, and the application architecture itself, with its walk back from stable URIs and REST, at what point is it safe to question whether or not the project has been a success? (since it technically exists on the web now, I suppose it's no longer vaporware) Did the British Museum lay off Dan Pett and put all of its eggs into the ResearchSpace basket for its future online collection database? It's really a crying shame that the BM employed one of the 10 top thinkers and doers in Digital Humanities in the entire world--the one person in their organization with the experience and creativity that might have been able to salvage the BM online collection and do something truly revolutionary with it (as he had done with the Portable Antiquities Scheme). It's a completely squandered opportunity, and the BM has done much to destroy the reputation it has gained as a leader within the museum Open Access and Open Data movement.

On stable URIs at the British Museum

Update, 2 Feburary 2018: The previous iteration of (Metaphacts) has been restored, and the collection object URIs now redirect once again to the Metaphacts framework. Earlier critiques of the system design still stand, relating to referenceable URIs, CURL, content negotiation, etc.

There are 61,853 coins from the British Museum integrated into's SPARQL endpoint and made available through type corpora such as OCRE and CRRO. The BM is the single largest contributor of numismatic data, providing about 3,000 more coins than the American Numismatic Society itself. With the aid of its highly talented and collaborative curators in the Coins and Medals Department, the British Museum's contributions to this research ecosystem have been transformative for the discipline, and the BM has played a vital role in demonstrating, through Linked Open Data methodologies, that LOD makes the whole greater than the sum of its parts.

This morning, all links have died.

And not died in the way that they have died when the oft-neglected, but extremely valuable (even though it had some obvious data modeling problems) British Museum SPARQL endpoint has gone down. Now they are 404's. Dead. Gone. Not a spinning circle you get when a server application runs out of memory. We've all known that there's some wonky and inefficient CIDOC-CRM modeling, and despite claims from ResearchSpace project managers, the British Museum data were never 5* Linked Open Data because they never linked externally. But stable, clean URIs are the A #1 requirement for LOD architecture.

And so ResearchSpace has managed to kill their own URIs when transitioning to the public version of the software. I was assured many years ago that these were the permanent URIs for objects.

So the URI for this coin of Augustus is dead:

However, you can still access the data in the new ResearchSpace system at

It should be noted: The BM implemented https://, effectively changing the URIs of its objects, but the URIs within the underlying graph database/SPARQL endpoint are still http://.

But you shouldn't have to negotiate the ResearchSpace framework with an unclean, application-specific request parameter to extract the data for At least create a proxy that allows for the resolution of the URI into human and machine-readable data, as per Linked Open Data principles? Or a semantic 303 redirect? Anything but straight-up killing millions of URIs. This betrays a serious deficiency in how to develop web applications.