The dynamic and collaborative scholarly landscape of the humanities and cultural sciences is in urgent need of reliable knowledge about the origin and genesis of its data. Versioning, with its capability to document data and its modifications, can be used to integrate and provide this critical information. In the following paper, the versioning of RDF data is presented as a method to make research more trustworthy, and as a means of turning the processes through which data is changed over time into objects of study within the digital humanities.
Scholarly work and the knowledge that it generates are the result of
iterative processes. Making these processes transparent is an indispensable part
of scholarly communication: it serves as the basis for trust in data, which in
turn encourages the use of that data in subsequent research
The social need for trust in data is reflected in the concept of the Semantic
Web, where the legitimacy of data plays a fundamental role. There are
several ways to render data more trustworthy, one of them being the provision
of metadata concerning the origin of data and the modifications it has
undergone over time:
[N]ot only could such provenance metadata be used as selection
criteria, their existence may encourage scholars to contribute data to the
community, as credit could be assigned more accurately and publicly.
Provenance metadata also could enable processed data to be ‘rolled back’
through transformations for the purposes of correcting errors at
interim stages or computing diefrent transformations
Documenting data and its modifications and, if necessary, reversing those modifications, is precisely the function that versioning can fulfill. This paper presents versioning as a method to make research in the humanities and cultural sciences more trustworthy by providing researchers with greater knowledge about the origin and genesis of their data.
To date, the various approaches that have emerged over the last 15 years have not produced a universally accepted versioning standard for RDF data. The suitability and usefulness of these approaches for the digital humanities will be evaluated in the final section of the present paper (5), where typical research scenarios will demonstrate the diefrent requirements for versioning mechanisms. First, however, I will address the extent to which versioning can contribute to the trustworthiness of data (2). This will be followed by a discussion of the various approaches to the versioning of RDF data (3), and of the question as to which archiving models are suitable for which application (4). 2
In 2000, Tim Berners-Lee launched his seminal idea of the Semantic Web Stack (Berners-Lee, 2000) (Figure1). Significantly, it is not only concerned with the development of technical standards to make information machineunderstandable, but also incorporates social needs that arise out of dealing with the Semantic Web, with the layers of ‘proof’ and ‘trust’ representing essential preconditions for broad acceptance and use of shared content.
Since the debut of Berners-Lee’s stack, many of the technologies featured
in Figure1 have become W3C standards (XML, RDF(S), OWL, etc.). When
it comes to ‘proof’ and ‘trust,’ however, the situation is quite diefrent. As
becomes clear from Berners-Lee’s diagram, the task of the proof layer is to
explain the conclusions drawn from the logical layer and to make their origin
traceable – Sergei Sizov has referred to the former as “the layer of provenance
knowledge”
Recording versions of digital resources to document change over time is an important part of describing provenance. Versioning enables us to refer to intermediate stages in the research process, but it also allows us to trace a ‘version history’ and to identify and analyze very specific changes between versions. In this respect, versioning functions as a mechanism of the proof layer and helps to foster confidence in digital resources.
RDF versioning can be implemented in diefrent ways. Three diefrent approaches are presented in this section, the first of which is reification (3.1), a way of attaching provenance information or change descriptions to individual triples. The concept of named graphs is then discussed as a possible alternative (3.2), before the final subsection addresses the extent to which traditional version control systems are suitable for the versioning of RDF graphs (3.3). 3.1
In RDF, it is possible to further describe each RDF statement through a
built-in vocabulary.1 This process is called reification, and describes the
relationship between an instance of a triple and those resources to which the
triple refers: “reification is a method of formally modeling a statement in
such a way that it can actually be attached as a property to the new
statement”
In order to version a dataset via reification, it is necessary to furnish
individual triples or a set of triples with information on authors, a version
number, or a timestamp. Ideally, the nature of the change itself is also described.
For this purpose, separate vocabularies such as the Changeset Vocabulary
by
2http://purl.org/vocab/changeset
This example shows a resource with a description and a title. Then the title
is modified:
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc="http://purl.org/dc/elements/1.1/">
<rdf:Description rdf:about="http://example.com/res#thing"/>
<dc:title>New Title</dc:title>
<dc:description>A short description of this resource</dc:description>
</rdf:Description>
</rdf:RDF>
Describing this kind of modification as a reified statement would look like
this:
While the changes are described precisely by the vocabulary, the change
description ends up being much longer than the statement itself. Even if no
exact description of changes is given, each reification of triples involves the
addition of a whole statement with subject, predicate, and object
The semantic concept of named graphs goes back to an essay by
An RDF dataset is a collection of RDF graphs. All but one of these
graphs have an associated IRI or blank node. They are called named
graphs, and the IRI or blank node is called the graph name. The
remaining graph does not have an associated IRI, and is called the default graph
of the RDF dataset
Figure 2 shows a graph (A), which is assigned a name (B). This named graph then forms part of a new graph (C), which contextualizes the original graph and associates it with other statements. Compared to the mechanism of reification, a named RDF graph is easier to read and much more space eficient, which is precisely why current approaches to RDF versioning tend to use this type of information linkage. If a triple is modified, i.e. added or deleted, it can be provided with an IRI, which in turn can be described by other statements. 3.3
Traditional version control systems have their uses, especially in software development. They store and manage text files which, when modified, lead to new versions with a unique identifier, a timestamp, and the author’s name. It is always possible to determine who changed what and when: every file in the system has a version history, which allows versions to be compared. This comparison is done using dif algorithms, which detect any change to the file, be it in the addition of spaces or the correction of a spelling mistake. Each saved change automatically establishes a new version, allowing the restoration of each individual saved text state. But how useful is it in practical terms to manage graphs in line form?
Serialization techniques allow RDF graphs to be managed as text in line form with traditional version control systems. The best way to accomplish this is to use N-Triples notation, in which the individual triples of an RDF graph are written in one line. Because the N-Triples format employs neither prefixes nor truncated notation, the serialized result of the same RDF graph always looks the same. Sorted N-Triples provide a canonical representation of RDF that is easy to parse and serialize. However, this format has the disadvantage of being verbose and tedious to read.
The following example describes an entry from the Getty Art & Architecture Thesaurus3 in N-Triples: <http://vocab.getty.edu/aat/300343387> <http://www.w3.org/2000/01/rdf-schema#label> "national libraries (institutions)"@en . <http://vocab.getty.edu/aat/300343387> <http://purl.org/dc/terms/license> <http://opendatacommons.org/licenses/by/1.0/> . <http://vocab.getty.edu/aat/300343387> <http://purl.org/dc/terms/created> "2010-06-10T15:11:49"^^<http://www.w3.org/2001/XMLSchema#dateTime> . By comparison, the same statements in Turtle appear as follows:
Especially for small datasets, version management with traditional systems
can be a viable choice
The main challenges in versioning RDF data are the storage of versions,
the performance of the archive, and the associated possibilities of
information retrieval (
An important advantage of the ‘independent copies’ strategy is the low technical eofrt required to implement the storage of data record versions. Each version is stored and managed as a new, isolated dataset. The DBpedia project,4 initiated by the Freie Universität Berlin and Leipzig University in cooperation with OpenLink Software with the goal of extracting data from Wikipedia and making it available as Linked Open Data (LOD), has used this method to archive 18 versions of their entire data pool over the course of the regular updates undertaken between its initial release in 2007 and October 2016.
Wikidata,5 a project of Wikimedia Germany, also archives independent datasets. The project started in 2012 with the objective of providing data that can be used by any Wikimedia project, including Wikipedia. Since 2015, data dumps have been made available on the Internet Archive, amounting to a total of 162 Wikidata versions by the time of writing this paper.6 In order to make these versions queryable and comparable, each version could be stored as a graph in a triple store and provided with additional metadata concerning provenance.7 This way of dealing with multiple versions is very well suited for playing back entire versions and querying individual versions.8 However, the disadvantage of this approach is that it is very memory-intensive: the process of archiving each version is accompanied by an increasing number of duplicated triples, because there is a static core of unchanged triples that occurs in every version.
4http://wiki.dbpedia.org/
5https://www.wikidata.org/w/index.php?title=Wikidata:Main_Page&oldid=1086709037
6https://archive.org/details/wikimediadownloads
7The user Tbt (https://www.wikidata.org/wiki/Wikidata:History_Query_Service) is working on
a tool to query past Wikidata versions. In the future, all deletions in a named graph and all
additions in a separate named graph will be available for query. On the discussion page, the
author writes the following: “This tool ingests data from the XML revision dumps, so it
follows what is done for dumps regarding oversight. I do not know exactly what is done for
XML dumps.” Tpt (talk) 16:57, 9 April 2019 (UTC)
8On query requirements, (
The redundancies discussed in the previous subsection do not occur with
change-based archiving. The amount of memory required is kept to a
minimum. Only the changes (deltas) are archived, while static elements do not
have to be repeated. The delta of each triple consists of the change
description and the change relationship (delete or add).9 Because triples, unlike text,
can be localized without reference to lines, a version consists of a set of
deleted triples and a set of added triples
Many practical features of version control systems can also be found in
the implementation of systems adapted to RDF such as R&Wbase, a system
proposed by
In many respects, R43ples, the implementation developed by
Archives that store triple versions via a change-based approach are
designed to record the changes to versions. When querying a specific state of
the dataset at a certain point in time, the system’s computational eofrt
increases: first, all deltas up to the first entry (or the next full version/snapshot)
must be recalculated, followed by the deltas from the reconstructed first
version to the desired version. In order to cut down on the amount of
processing power required,
9Barabucci 2016 defines delta as follows: “A delta […] is a tuple of changes (C) and
change relations (R) that describes how to transform the source document (S) into the
target document (T)”
10The deltas are calculated from syntactic changes to the data. Changes in semantics
(e.g. when a class is renamed) are much more complex to calculate – these are referred to
as high-level deltas
As mentioned above, there are also approaches that add a time component to the previously discussed storage forms (snapshot or delta) with the goal of optimizing system performance for very specific queries (e.g. the query for valid triples at a certain time or interval).
A time-based strategy can be implemented in two ways. One possibility is to assign to each triple, for as long as it exists, meta information in the form of a time stamp as each new version is created. However, with this approach, there is always write work for the system, since it also assigns a new time stamp to triples that remain unchanged. An alternative would be to only annotate triples when they are added or deleted, meaning that a maximum of just two data fields is added to the triple.
This implementation can be found, for example, in X-RDF-3X, a
platform developed by
There are also systems that combine all three of these archiving strategies
in order to get the best of all worlds. In the implementation by
The models for version storage discussed in the present paper allow for a wide range of query requirements to be met. But what kind of demands regarding the versioning of RDF or Linked Open Data exist within the context of the digital humanities?
Scenario 1: Occasional Data Updates for a Digital Scholarly Edition (DSE) I am the editor of a digital scholarly edition of account books. I modeled my data in RDF and published it. I did a statistical analysis of the data and displayed it to the users. Now I want to add another account book, but the evaluation of my analysis is based on a closed database. How can I make the current state of research accessible and still publish new RDF data? On the one hand, this scenario describes a basic retrieval task, namely the retrieval of a specific version of the recorded data. On the other, there is also the need to query this past version, for example in order to keep statistical values verifiable. The ‘independent copy’ approach is perfectly adequate to fulfill these requirements, as each historical version dumps in an ordinary RDF memory. It is easy to provide full versions in the form of snapshots and to enrich these snapshots with additional metadata – for example, the PROV ontology can be used to create a version catalog or to provide additional provenance data, whereas diefrent graphs (versions) can be queried via SPARQL.
A time-based strategy involving the annotation of individual triples with their validity range could also work well. Materializing a specific past version is the most computationally demanding task when using an approach that only stores deltas, since all deltas must be re-calculated when requesting a full version. Assuming that the deltas are stored in such a way that they are only connected to the previous delta, the change chain is calculated back to the ifrst complete version and then, in order to be able to materialize a certain later state, the deltas are calculated forward again up to the desired version. In this scenario, combined storage approaches that record both snapshots and deltas can help to keep the computational eofrt manageable. 5.2
Scenario 2: Collaborative Ontology Development
I work for the National Library, and we want to develop a crossinstitutional common ontology that is maintained collaboratively. With these collaborative processes, would it not be useful to track the changes and to analyze how and why they occurred? This scenario focuses on the problem of collaborative editing. There is a need to query the changes that occurred between two or more versions. Here, functionalities provided by version control systems are expected – these involve merging branches, highlighting conflicts, quickly undoing changes, and so on. Yet a second requirement is also formulated, namely the tracking of very specific changes.
Calculating the diefrence between the versions of the datasets with an
‘independent copy’ approach requires significant computational assets given
that the calculation of specific deltas takes place at query time. With a
timebased approach, however, this task can be accomplished with little eofrt,
provided that the time of adding and deleting the triple is available as meta
information for each triple. In either case, the change-based implementations
by
Scenario 3: Analysis of Historical Topic Evolution in Wikidata
I am a historian, and I want to analyze historical topic development in
Wikidata from the beginning of Wikidata until today. I am interested
in the evolution of knowledge and its representation. For instance, how
are historical events and persons perceived and described? What are the
primary topics, and how have certain aspects evolved and changed over
time? How can I retrieve this kind of data?
In this scenario, the goal is to discover patterns that arise and develop over
time. This results in specific requirements: not only should it be possible to
compare past versions with each other, but the system should also allow users
to query the changes that have taken place. To query information that is
present in several versions, or specific changes that take place between them,
is a task that is very dificult to accomplish with a straightforward
‘independent copy’ approach – it is far easier to query the validity of triples using a
time-based solution. However, when it comes to tracking concept changes,
the ability to query deltas is required. The approach developed by
When versioning data and archiving it for research purposes, its usability for future scholarship is a major concern. The choice of a specific versioning strategy depends on how often and how much our research data changes and, above all, on which information is to be made retrievable. This paper has illustrated the diefrent requirements for versioning systems with user scenarios that are likely to occur in the context of the digital humanities. As has become clear, there are technically simple solutions to the problem of rendering RDF data and the changes that it is subjected to referenceable and retrievable. System requirements are bound to increase with a higher frequency of changes and mounting demands concerning their traceability, especially in collaborative research. For the collaborative development of graph data, versioning models are required that adopt functionalities from collaborative software development. Additional features permitting detailed analysis of changes over time are also desirable, and will empower scholars to undertake increasingly complex research projects as more and more RDF data is being published – and changed – in years to come.
As scholars working in the digital humanities, we are particularly interested in the origin and development of our research data. Versioning can be used to integrate and provide this critical information, whose importance for scholarly practice cannot be overstated. Moreover, versioning mechanisms ensure that our data can itself be used as an object of study. Not only does versioning create trust – it also enables the scholarly discourse of the future.