Update, 2 Feburary 2018: The previous iteration of collection.britishmuseum.org (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 Nomisma.org'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: https://collection.britishmuseum.org/id/object/CGR219968
However, you can still access the data in the new ResearchSpace system at https://public.researchspace.org/resource/?uri=http://collection.britishmuseum.org/id/object/CGR219968
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 https://collection.britishmuseum.org/id/object/CGR219968. 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.
There are 61,853 coins from the British Museum integrated into Nomisma.org'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: https://collection.britishmuseum.org/id/object/CGR219968
However, you can still access the data in the new ResearchSpace system at https://public.researchspace.org/resource/?uri=http://collection.britishmuseum.org/id/object/CGR219968
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 https://collection.britishmuseum.org/id/object/CGR219968. 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.
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.