Blog

Welcome to the first in a series of blog posts about CERL and its Linked Open Data activities! What I will try in this blog post is to highlight the relevance of Linked Open Data for Early Modern Prints, while also providing a gentle introduction to some technical concepts. There are plenty of introductions to Linked Open Data by now, ranging from Wikipedia to my favorite book on the topic (van Hooland & Verborgh 2014) – so we may be covering some ground here that you are already familiar with. This blog post will not teach you how to publish your data as Linked Open Data – but it may show you why dragging your data out of its isolation and onto the Linked Open Data Cloud is well worth the effort of learning about it, for example by also having a look at all these other introductions.

Illustration 1: Don’t let your data be as isolated as St. Anthony (Wikimedia Commons)

 But first, let’s take apart the term into its three components! I am not going to get involved in the discussion of how we should define “data”, but once you have comfortably settled on whatever working definition you prefer, we can have a closer look into what it means for that data to be “linked” and/or “open”. As it turns out, while Linked Open Data (henceforth: LOD) is often used as  a very generic term (if not to say: an incantation), it actually combines two separate issues: that of linking your data and that of providing your data in an open form. Neither of the two depend on each other, although they beautifully work together: You may well see use cases for linked but closed data sets, or for open but non-linked data.

Linked Data refers both to a set of principles for data publication, and to their concrete implementation through standards developed by the W3C, the World Wide Web Consortium. Here’s the short list of ingredients, quoted from Tim Berners-Lee’s note, all of which we will need to unpack a little further:

[A] Use URIs as names for things

[B] Use HTTP URIs so that people can look up those names

[C] When someone looks up a URI, provide useful information, using the standards […]

[D] Include links to other URIs, so that they can discover more things

So, let’s begin with A. The basic way we used to record information in the library world was by writing it down in catalogs – catalogs designed for human consumption, that is, structured and organized in a way that helps human beings find the information they are looking for. What is helpful for a human being searching for books by a particular author? Well, that author’s name written down in the description of the book. Of course you may be faced with people sharing the same name, or pseudonyms, but a few additional data points (let’s say the life dates of the author in question) and your general world knowledge are fairly sufficient to help you identify the correct entries. In case any doubt remains, librarians have developed fairly complex rules on how exactly to write down things.

Illustration 2: Human beings produce catalog cards for human beings (Wikimedia Commons)

As it turns out, while human beings are quite good at making do with very little information, especially at a small scale, computers really are not. One major difference between the human brain and the computer is that we treat strings (the computer science term for a sequence of characters – basically, any piece of text) as having semantics – we read them for their meaning. But to the computer, strings are really just syntactic objects – sequences of characters that can be manipulated and analysed without any reference to what they mean. So a human being will instantly recognize that “Morten Luther” is probably a variant spelling of “Martin Luther”, but to the computer they are just different and unrelated strings (unless you put some thought into teaching the machine the concept of misspellings).

The computer does have one advantage over the human user though – it is really fast at looking up information elsewhere. And so we put this advantage to use in libraries by using authority files – external repositories of information on entities like authors. Now we don’t have to put any thought into correct spellings, name forms or anything like that – we can simply put down a number from our authority file, let’s say the GND’s 118575449, and collect all name forms and additional information there. This number is not very helpful for human beings – which is why electronic library catalogs tend to get the information from the authority file and display it to the user instead –, but it is incredibly helpful for the computer because it has a precise and unique definition.

Illustration 3: Martin Luther in the German National Library’s Authority File

So, turning back to principle A of Linked Data (‘use URIs as names for things’), the idea is that as many things as possible in your data set should be described in this way: Not as strings for human consumption, but as unique identifiers – which help the computer understand what is going on, and can be used to retrieve the human-readable information. Incidentally, this is good practice for maintaining your data set anyway – if researchers ever find out that Martin Luther actually faked his death and happily lived on until 1580, you won’t have to go into each separate record to change his life dates now. Principle A also suggests a particular type of identifier, namely URIs – Uniform Resource Identifiers. If you have ever seen a web address (or URL, Uniform Resource Locator), you roughly know what they look like. This is also the reason why they are the identifiers used in Linked Data – because they beautifully tie in with the overall architecture of the World Wide Web.

This often presents a challenge when processing legacy data sets today: When data is presented in strings, we have to find ways of automatically extracting and generating the relevant entities. Which isn’t always easy, especially when your source is largely unstructured, narrative text – let’s say a summary of a book’s provenance that freely mixes descriptions of provenance marks and biographical notes on previous owners.

Principle B (‘use HTTP URIs so that people can look up those names’) doesn’t need much explanation. URIs don’t have to be web addresses, but in practice, the URIs you use as identifiers should be – because that means people can open them in their web browser. Which leads us immediately to principle C (‘when someone looks up a URI, provide useful information, using the standards’) – when you have a URI like <http://d-nb.info/gnd/118575449>, you want to make sure some information is returned when people follow this link. This information should be presented following a number of technical standards, which we will all gloss over here – the main point is that you should probably present it in at least two different ways, depending on whether a human being or a machine is requesting the data. Give human beings nice, readable strings, maybe with some layout on top, and trust in their ability to process semantics implicitly, while returning highly structured data with precise semantic definitions to computers. The standard for the latter is called RDF (Resource Description Framework), and the most common language for querying data sets described in RDF is called SPARQL, two terms you will probably come across when dealing with Linked Data.

Illustration 4: A human-readable representation of Martin Luther in the CERL Thesaurus

One key feature of RDF is that you don’t just use URIs for the entities in your data set – you also use them for properties! So you don’t say “This book has the author <http://d-nb.info/gnd/118575449>”, you define a “hasAuthor” property, and identify it via a URI – and when somebody opens that URI, they will find either a human-readable description of that property, or a precise definition of its semantics. Very often it makes sense to not define your own properties, but to use existing ones from one of the many standard ontologies that have been proposed for various domains. And of course you will also identify “this book” via a URI – so you end up with lots of triples of the form “Entity hasProperty Entity” (or Subject-Predicate-Object), where all three ingredients are identified via URIs. And that is also why the databases for storing RDF are called “triplestores”.

Let’s turn to principle D (‘include links to other URIs, so that they can discover more things’)! That is where the linking comes in – since the entities in your data set now have an address on the World Wide Web, and those of other data providers do too, there is nothing that keeps you from having them point at one another. Let’s say you have a data set describing the collection of an institution’s Early Modern prints – well, then you don’t have to come up with your own authority file for their printers, because you might as well link them up with the CERL Thesaurus which provides RDF representations as well as a human-readable display (and a range of other formats) for each of its printers. This has multiple advantages: You do not have to maintain and curate the data yourself (but of course you have to trust another data provider to do that for you – much of the LOD community thrives on trust, also when it comes to keeping data sets available and identifiers persistent over time), your users can follow the links to obtain more information about the printers, and all data sets using the same identifiers are now linked with one another, allowing for interesting searches across databases. This effect only grows with the number of links, and especially when central data hubs like Wikidata connect data sets across domains. Which is really helpful, because it is never possible to foresee all future research questions – maybe you wouldn’t have though about connecting your database with a botanical data set, but once your researchers start asking questions about herbals, you may wish you had.

Illustration 5: Offering your data to the world like a veritable smorgasbord (Wikimedia Commons)

Now that your data is linked, what does it mean for it to be open? The idea behind Open Data is that data is all the more useful the fewer restrictions there are on its use. In practice this means releasing your data under an open license, or even into the public domain. If you do that using the principles outlined above, then you have reached your goal: You have published Linked Open Data.

In future blog posts, I will give you some more insight into how CERL publishes its own data as LOD, and maybe dive a little more into the nitty-gritty technical details. But for now, I will leave you with these basics, and a last look at the record of Martin Luther in the CERL Thesaurus – as it is presented to computers.

Illustration 6: A machine-readable representation of Martin Luther in the CERL Thesaurus

Andreas Walker, Data Conversion Group, Göttingen