The Identifier section on a Wikidata item is a useful directory of how that entity is represented in other databases, websites and systems. For building knowledge graphs and linking data these shared identifiers are potentially very powerful. But what kind of data is there, how reliable is it, what format is it provided in, what is the overlap? This analysis explores these questions for a very specific slice of Wikidata: bibliographic related names. This means a name, usually a person, that is involved in the creation of a book. I’ve singled out 1.76 million of these bibliographic names by filtering if they have a Library of Congress Name Authority Record identifier. To explore the content I’ve selected a single famous author, Mark Twain, and retrieved the data behind each of the 315 identifiers he has on his Wikidata item. This should represent the “best case scenario” of what these identifiers can potentially provide. There are six parts:
One tile per identifier. Pick what to group by in the tabs, switch layout, colour by any facet; click a tile for its record.
Every value the 315 sites state about Twain, merged by element and de-duplicated, with Wikidata's own values mixed in and marked. A number on a chip is how many sites state that value; hover for which ones. Long lists show the most repeated values, then each site's holdings with its first ten.
Counts of the 315 identifier properties (sites), from the crawl and the data fetches.
Share of the Wikidata items with a Library of Congress ID (P244) that also carry each identifier, from QLever. Bars are tinted by what the Twain crawl found on that site.
Share of the sites in each domain whose data files carried the element. Darker is more sites.
While the Identifiers section of a Wikidata item is mostly a mapping tool, a crosswalk between systems, there is some implied expectation that the links are being established to contribute value. The most interesting areas of comparison in my opinion are how to access data from the linked site, how that data is represented and how useful it is. Simply being able to access the external site programmatically is a basic requirement for being useful in a data ecosystem. Only about 50% of the sites would even respond to a cURL or Python request; the other half require a browser-like interaction to even serve up data. The form that data takes is also important: any sort of structure is good, of course highly semantic structure like RDF is perfect, but even just an ad-hoc JSON response would be fine. This analysis shows though that over one-third of the sites have no structure at all, just HTML. This introduces a high bar that would require parsing arbitrary HTML to produce structured data. And finally you would need a reason to want to parse it in the first place: how useful is the data? Usefulness in this case is being measured as containing information that is not present on Wikidata in some form. Not surprisingly for an author, most of the national libraries are useful in that they provide a listing of works related to Twain, compared to the majority of the sites which just repeat the same facts or a limited biography. Like most things it seems safe to say the identifiers follow the 80/20 rule, where most of the value would come from a limited set of identifiers. Regardless, simply having the place to make the connections, even if the sources don’t serve up data, is still a really valuable use case for Wikidata.