Wikidata is the largest general-interest knowledge base that is openly available. It is collaboratively edited by thousands of volunteer editors and has thus evolved considerably since its inception in 2012. In this paper, we present Wikidated 1.01, a dataset of Wikidata's full revision history, which encodes changes between Wikidata revisions as sets of deletions and additions of RDF triples. To the best of our knowledge, it constitutes the rst large dataset of an evolving knowledge graph, a recently emerging research subject in the Semantic Web community. We introduce the methodology for generating Wikidated 1.0 from dumps of Wikidata, discuss its implementation and limitations, and present statistical characteristics of the dataset.
A knowledge graph is \a graph of data intended to accumulate and convey
knowledge of the real world, whose nodes represent entities of interest and
whose edges represent potentially di erent relations between these entities" [
Most research so far treats knowledge graphs as static in the sense that
change over time is not modeled explicitly. However, in practice, knowledge
graphs change over time: new knowledge may be added to the graph (in the form
of new edges being added to existing entities, new entities emerging over time,
etc.), and existing knowledge may be revised (in the form of imprecise labels being
updated, duplicate entities merged, existing contents declared out-of-scope, etc.).
This more general setting is only starting to be considered recently [
For example, while there are a plethora of di erent approaches for knowledge
graph embedding [
Currently, there are practically no published datasets recording a knowledge
graph's organic evolution over time that would enable such research and facilitate
reproducible evaluation environments. Instead, existing research either simulates
knowledge graph evolution on top of datasets of static knowledge graphs using
simple heuristics such as statement ordering (e. g., Daruna et al. [
Wikidata [
In particular, our contributions are: { We present our methodology for transforming a dump of Wikidata's revision history into streams of RDF triple deletions and additions which form Wikidated 1.0, a dataset recording Wikidata's evolution over time (Sect. 3). { We present statistics over the dataset and visualize its characteristics (Sect. 4). { We publicly release Wikidated 1.0 in two variants, the code base used to built it, and a Python API to access it1.
In addition to the above, Sects. 2 and 5 discuss background and related work, respectively, and Sect. 6 concludes.
In this section, we review the data model of Wikidata (Sect. 2.1) and its serialization as RDF (Sect. 2.2). 2.1
Formally, the data model of Wikidata3 can be de ned as a set of entities e1; : : : ; eN , where N is the number of entities in Wikidata. Let id(ei) denote the entity ID of entity ei. Each entity is either an item or a property 4. Items are things or concepts in the real world about which facts should be stored; their IDs are numbers pre xed with \Q"|for example, the English writer Douglas Adams (Q42) or the concept of a human (Q5). Properties are abstract types of statements which are used to store facts about entities; their IDs are numbers pre xed with \P"|for example, the properties instance-of (P31) or date-of-birth (P569).
A revision de nes an entity's state at a speci c point in time. Each revision is comprised of: (1) a ngerprint, which consists of multilingual sets of labels, descriptions, and aliases of the entity, (2) a set of site links, which are usually links to Wikipedia articles about the entity, and (3) a set of statements, which are records of facts about the entity. There is one exception: if an entity is found to be a duplicate of another one, a revision can also be a redirect. In the case of redirects, no ngerprint, site links, or statements are present, and the revision consists of just the entity ID that the redirect's entity is deemed to be a duplicate of. Further, each revision (including redirects) carries metadata, such as the time it was created at, the contributor that authored it, and a comment string about the change.
Every time an entity is modi ed, a new revision is created. We therefore model entities as sequences of their revisions ei = (ri;1; : : : ; ri;ni ), where ni is the number of revisions of entity ei. Let id(ri;j ) denote the revision ID of revision ri;j . Revision IDs are assigned by incrementing a global counter. They are thereby unique over all entities and induce a total ordering of all revisions in Wikidata5.
Finally, statements record facts about entities and fundamentally consist of a property and a value, which is either another entity or a literal. For example, statements about Douglas Adams include instance-of human and date-of-birth \11 March 1952". As is the case in the latter example, literals can be of various data types, e. g., dates or geographical coordinates. An example of a statement about a property is that the complementary-property of date-of-birth is date-ofdeath. Note, that entities whose latest revision is a redirect and deleted entities can still be targets of the statements of other entities, but that Wikidata aims to replace instances of this with new revisions where this is not the case. There are
a lower ID, can occur. We attribute this to slight miss-synchronizations of clocks on parallel servers. The di erence is never larger than one second. two special values of statements: none, which signi es that it is known that the property of that entity has no value, and some, which indicates that it is known that there is some value for the property of that entity, but it is unknown what it is. Each statement can be annotated by (1) a set of quali ers, which re ne a statement (e. g., to indicate that it has only been true for some period of time), (2) a set of references, which provide sources to support the statement, and (3) a rank, which can be used to assign preference to con icting statements (e. g., to distinguish current from historical facts).
Dumps of Wikidata's contents are available for download in various formats6. Most dump formats only provide the most recent revision of each entity; only the pages-meta-history XML dumps include the full revision history, but store revision contents as JSON blobs7. Notably, each revisions stores its complete state at its creation time and there is no trivial way to identify what changed from one revision to the next.
In cases of vandalism, or when entities do not meet Wikidata's notability policy8, administrators may delete the a ected revisions or whole entities from Wikidata9. Since such deleted contents may contain copyrighted materials or sensible personal information, deleted entities and revisions are not accessible to the general public and are not contained in the o cial dumps of Wikidata. IDs of deleted entities and revisions are never reused for new ones, which leads to gaps in the incremental numbering. In case an entity is detected that is a duplicate of an existing one, Wikidata prefers not to delete the new entity, but to establish a redirect from the new entity to the existing one instead. 2.2
RDF
The Resource Description Framework (RDF) [
Let I, B, and L be disjoint countably in nite sets of IRIs, blank nodes, and
literals, respectively. A RDF triple is a triple (s; p; o) 2 (I [ B) I (I [ B [ L),
where s is called the subject, p the predicate, and o the object. A RDF graph is a
set of RDF triples. Let G1 n G2 denote the set di erence between two RDF graphs
G1 and G2. Computing it is non-trivial, because in order to decide whether two
RDF triples are equal, one needs to decide which triple components are equal
to one another. This is straightforward for IRIs and literals, but hard for blank
nodes, as they are only characterized through the RDF triples they participate
in and do not have identi ers across RDF graphs. In general, nding a mapping
between the blank nodes of two RDF graphs that minimizes the set di erence is
NP-hard [
wikidata.org/wiki/Wikidata:Requests for deletions. 1 wd:Q42 a wikibase:Item ; 2 rdfs:label "Douglas Adams"@en ; 3 schema:description "English writer and humorist"@en ; 4 skos:altLabel "Douglas Noel Adams"@en ; 5 wdt:P569 "1952-03-11T00:00:00Z"^^xsd:dateTime ; 6 p:P569 s:Q42-D8404CDA-25E4-4334-AF13-A3290BCD9C0F . 7 8 <https://en.wikipedia.org/wiki/Douglas_Adams> a schema:Article ; 9 schema:about wd:Q42 . 10 11 s:Q42-D8404CDA-25E4-4334-AF13-A3290BCD9C0F a wikibase:Statement ; 12 ps:P569 "1952-03-11T00:00:00Z"^^xsd:dateTime ; 13 prov:wasDerivedFrom ref:355b56329b78db22be549dec34f2570ca61ca056 . 14 15 ref:355b56329b78db22be549dec34f2570ca61ca056 a wikibase:Reference ; 16 pr:P248 wd:Q5375741 .
Listing 1. RDF serialization of Wikidata entity Q42 in Turtle syntax (abridged).
While Wikidata doesn't store revisions in RDF internally, RDF serializations
for them are available [
In this section, we discuss our methodology for creating Wikidated 1.0 (Sect. 3.1), our implementation (Sect. 3.2), and limitations (Sect. 3.3). 3.1
Fundamentally, Wikidated 1.0 is a transformation from a Wikidata dump's stream of revisions into a stream of incremental revisions. We de ne an incremental revision as a tuple of the (1) entity metadata (the entity ID and some Wikidata internal elds), and the (2) revision metadata (the revision ID and when and by whom it was authored) of the Wikidata revision it is based upon, as well as sets of (3) RDF triple deletions and (4) RDF triple additions in comparison to the previous revision of the respective entity. As hinted at in Sect. 2, we thus decide 10 Taken from https://www.wikidata.org/wiki/Special:EntityData/Q42.ttl. Documentation at https://www.mediawiki.org/wiki/Wikibase/Indexing/RDF Dump Format.
Global
empty sequence 2 download pages-meta-history dump of Wikidata 3 foreach entity ei in dump do 4 Entity empty sequence rRDF-prev fg for j = 1 to ni do rMeta take revision metadata of ri;j from dump rJSON take JSON blob of ri;j from dump rRDF rDel rAdd rRDF-prev serialize rJSON as RDF graph rRDF-prev n rRDF rRDF n rRDF-prev
rRDF append incremental revision (ei; rMeta; rDel; rAdd) to Entity output Entity as entity-stream variant of entity ei append all elements of Entity to Global 16 sort Global after ascending revision IDs id(ri;j ) across entities 17 output Global as global-stream variant
Algorithm 1. Construction of the Wikidated 1.0 dataset. 1 to de ne change between Wikidata revisions via the di erence in triples between their RDF serializations. This allows for more straightforward dataset modeling and consumption, as opposed to de ning change for each of the di erent aspects of the Wikidata data model ( ngerprint, site links, and statements with quali ers, references, and ranks).
Wikidated 1.0 consists of two complementary variants of the same data: 1. The global-stream variant consists of all incremental revisions across all entities sorted in chronological order. 2. The entity-streams variant contains a separate stream of incremental revisions for each entity of Wikidata.
The former can be used for global analysis, e. g., for analyzing the number or style of revisions in a speci c time period, whereas the latter is useful for entitycentered analysis, e. g., when one is only interested in a subset of all entities or when the aim is to directly compare consecutive revisions of the same entity.
Algorithm 1 outlines the steps of creating Wikidated 1.0. First, we download a full Wikidata dump11 (Line 2). Next, we iterate over all entities in the dump (Line 3). For each entity, we iterate over all of its revisions in the order they were created in (Line 6). Because the dump les store entities and revisions 11 Speci cally, Wikidated 1.0 is based on the 20210601-pages-meta-history dump, the history of Wikidata from its inception on 30 October 2012 until June 2021. The ID of the last revision is 1433475551, which was authored on 2 June 2021 at 05:35:58. in exactly this order, this amounts to linearly traversing the dump les. For each revision, we rst extract revision metadata and the JSON blob of revision contents from the dump les (Lines 7 and 8). We then serialize the revision contents as an RDF graph (Line 9), and compute the sets of RDF triple deletions and additions (Lines 10 and 11) compared to the RDF graph of the previous revision, for which we maintain a helper variable (Lines 5 and 12). Having now transformed the revision into its incremental counterpart, we append it to a sequence of all incremental revisions of the entity Entity (Line 13, initialization in Line 4). After all revisions of an entity have been iterated over, we output Entity as the entity-stream variant of that entity (Line 14). Finally, we maintain a sequence of all incremental revisions across all entities Global (Lines 1 and 15). After sorting all revisions in it globally (Line 16), we also output Global as the global-stream variant (Line 17). 3.2
We provide a Python API for browsing and iterating the dataset without having
to know how the dataset is stored on disk. Internally, both variants are stored
as gzip-compressed text les in JSON Lines format, i. e., each line is a JSON
object encoding one incremental revision. For the entity-streams variant, the
les for all entities are packaged in a tar archive. While approaches for storing
di erences between RDF graphs in RDF itself exist [
The le size of the global-stream variant of Wikidated 1.0 is 239 GiB whereas the tar archive for the entity-streams variant is 329 GiB (both gzip-compressed). In contrast to this, the o cial Wikidata dump of non-incremental revisions that Wikidated 1.0 is built from is available in the two compression formats bz2 and 7z with a size of 1 040 GiB and 339 GiB, respectively. While Wikidated 1.0's smallest variant is thus only 71% the size of the o cial dump's smallest format, one might have expected an even larger reduction in size due to the usage of incremental revisions that do not repeat all statements from earlier revisions. We suspect that this bene t is o set by using the RDF serialization, which is more verbose than the JSON blobs of the o cial dumps, that the non-incremental revisions are more compressible through their repeated statements, and by the inferior compression of gzip compared to 7z. We are therefore looking into publishing our dataset in additional compression formats in the future, but have opted for the universally-available and streamable gzip format for the rst release.
For serializing Wikidata revisions as RDF graphs (Line 9), we use Wikidata
Toolkit12. Because it does not provide a way to serialize Wikidata revisions that
are redirects, we encode these via the owl:sameAs predicate, following the choice
of the Wikidata Query Service13 [
For computing set di erences between RDF graphs (Lines 10 and 11), we can avoid the di cult task of nding an optimal mapping between blank nodes. In the case of Wikidata's RDF serialization, blank nodes are only used to encode the special some values, and each blank node never occurs in more than one RDF triple. Because of this, there is an e cient way to determine the set di erence between RDF serializations of two Wikidata revisions: two RDF triples can be treated as equal if their non-blank-node components are equal.
Last, assembling the incremental revision streams Global and Entity (Lines 15 and 16) is not as straightforward as presented, because both would quickly exceed available main memory. Instead, we directly append any incremental revisions (Line 13) to the target le without keeping them in memory. To merge all Entity streams into a sorted Global, we use a hierarchical multiway merge. 3.3
The main limitation of Wikidated 1.0 is that is does not contain any record of deleted entities or revisions14 because these are not recorded in Wikidata's revision history dumps, as explained in Sect. 2.1. However, entity deletions are comparatively rare in Wikidata, since the common case of duplicate entities is addressed through merges, i. e., redirects of one entity to another, which| unlike deletions|are recorded in Wikidated 1.0. Additionally, statements of other entities may still target deleted entities, so partial history of them is recorded.
Multiple implementations of RDF serializations of Wikidata revisions exist. The one in Wikidata Toolkit was used to construct Wikidated 1.0. Both the RDF exports of individual Wikidata entities and the o cial Wikidata RDF dumps use two other slightly di erent implementations. In practice, the di erences are minimal and mostly amount to how certain metadata is encoded|the important parts, i. e., facts about entities, are encoded identically in all implementations.
By design, Wikidated 1.0 only contains the revision history of entities. As a consequence the \meta level" of Wikidata is not part of the dataset. Among other things, this includes the talk pages of all entities, where editors discuss aspects such as how certain content should be modeled or what is in scope for Wikidata, or the help pages, which document how to use Wikidata. While this plain text data is part of the Wikidata dumps it is not RDF serializable.
In May 2018, three new entity types have been added to the Wikidata data
model to model lexicographical data: lexemes, forms, and senses15 [
Entities
Revisions 2012 2014 2016 2018
2020 End of year 1.5 1.2
In this section, we present statistical characteristics of the Wikidated 1.0 dataset in order to provide context for any research work building upon it. Much of the analysis also applies to Wikidata given that Wikidated 1.0 is a direct representation of it.
We plot the number of entities and revisions over time in Fig. 1(a)16. For
both, we observe a mostly linear growth, with a slightly stronger incline since
2016, which follows the integration of Freebase into Wikidata in the latter half
of 2015 [
Fig. 1(b) shows the number of revisions per entity in more detail. Roughly half of all entities have fewer than 10 revisions, and the majority have more than one. 99% of entities have less than 100 revisions, whereas some of the remaining entities can have signi cantly more.
The time between consecutive revisions of the same entity is visualized in Fig. 2(a). 30% of revisions are being authored within less than a minute since the previous revision. We suspect that this stems either from heavy activity on the most popular entities, or from editors performing multiple related changes directly after another, such as changing two related statements or reverting erroneous edits. For 60% of revisions, the time since the previous revision is less than a month. For less than 4% of revisions, that time is more than a year. Coupled with the previous gure's data of only 2.5% of entities having exactly one revision, it stands to reason that most entities in Wikidata are edited somewhat frequently. 16 In all gures of this section, we treat revisions that are redirects as regular revisions (being represented by exactly one owl:sameAs RDF triple). As a consequence, we also count entities whose latest revision is a redirect as regular entities. 46%
39% 11% 1
(b) 4%
0
35.3% 80% First addition First deletion
25% 7% 7% 13% 8% 9% 16%
40% 29% However, this does not imply that most entities are checked by humans with some frequency, as these changes could also have been made by automated bots.
Getting closer to the contents of revisions, we look at the number of additions and deletions of RDF triples per revision in Fig. 2(b). Note that there is no one-to-one correspondence between the number of Wikidata statements and the number of RDF triples. For example, a single site link is expressed in more than one triple (compare Lines 8 to 9 of Listing 1). Additions are much more common than deletions with 80% of revisions not featuring any triple deletions. Since 89% of revisions contain less than 10 triple additions, we conclude that most revisions constitute atomic changes and that the case in which multiple statements of a single entity change is much rarer.
In Fig. 2(c), we show the time until a RDF triple is rst added or deleted. Approximately half of triples are added within less than a day since the the creation of its entity. Deletions take far longer: more than half of all deleted triple are deleted more than half a year after they had originally been added. Besides changes to the Wikidata schema|like the deletion of properties|that potentially entail (semi-) automated changes to otherwise unchanged entities, we see two competing explanations for these late deletions: it might simply take a while until facts in the real world change and Wikidata can only update its record of them once they do, or alternatively, Wikidata might take a while to detect incorrect knowledge for the less popular entities. A more detailed look into classifying the types and causes of changes will therefore be necessary for further investigation.
Last, Fig. 2(d) visualizes repeated deletions of the same RDF triple. Unsurprisingly, the vast majority of triples added to Wikidata are never deleted. Slightly less than 10% of triples are deleted exactly one time; 4% of which are added back into Wikidata again afterwards (not shown in gure). Even though only less than 1% of triples are deleted from Wikidata more than once, a few of these are deleted very many times. For example, around 52 thousand triples are deleted and added to Wikidata more than 100 times (not shown in gure). We suspect heavy edit wars|potentially between bots|as the main cause for this.
To summarize, we have quanti ed how Wikidata changes over time on a macro level through analyzing statistical characteristics of Wikidated 1.0, which demonstrates its tness as a dataset for evolving knowledge graph research. 5
Based on their naming, Wikidata's incremental dumps17 may seem to address the exact same problem as Wikidated 1.0. These dumps are published every 24 hours and contain all revisions authored since the last dump. However, like the full dumps discussed in Sect. 2.1, each revision is stored in its full state and no obvious way exists to identify what changed from one revision to the next. Additionally, incremental dumps older than a few months are routinely taken o ine. Because of this, they do not o er a way to trace the full edit history since Wikidata's inception like Wikidated 1.0 does. Their main use case is to keep live services operating on Wikidata's contents up-to-date.
Much closer to our setting is the history query service18 [
In contemporary work, Shenoy et al. [
The CorHist dataset [
Other research that studies Wikidata's evolution includes Sarasua et al. [
We have presented Wikidated 1.0, a dataset containing Wikidata's revision history as incremental revisions, i. e., sets of deletions and additions of RDF triples. To the best of our knowledge, it constitutes the rst large evolving knowledge graph dataset of its kind. We foresee applications both from the Wikidata community for studying how Wikidata changed over time, as well as from the wider knowledge graph community for evaluating techniques over evolving knowledge graphs, such as incremental knowledge graph embeddings or updatable indexing structures for e cient query answering.
Besides releasing the dataset and the accompanying codebase1, in this paper we have documented our methodology for creating Wikidated 1.0, and discussed its implementation and limitations, the biggest one being the omission of deleted entities, which are not contained in the openly available revision history dumps 19 Data and analysis scripts available at https://w3id.org/wd quality. of Wikidata. Additionally, we have presented statistical characteristics of our dataset, and compared it to related work. 6.1
In the future, we plan to release new versions and additional variants of our dataset. In particular, we aim to establish a release cadence for publishing a new Wikidated version on the most recent Wikidata dump in regular time intervals, based on community uptake. Additionally, we are working on extracting subsets of Wikidated 1.0 that only contain RDF serializations of simple statements, i. e., statements with quali ers and references removed, or \thruthy" statements, i. e., statements with the highest rank|similar to the existing equally-named variant of the o cial Wikidata dumps. Last, we are thinking about additional ways of reducing the large le size of Wikidated 1.0, such as switching to better compression formats, subsampling the dataset, or aggregating deletions and additions of all revisions in a xed time frame (e. g., an hour, day, or week).
Further future work includes deeper analysis of the editing dynamics of Wikidata recorded in Wikidated 1.0, such as detecting updates from sets of triple deletions and additions, or classifying the type and source of changes; and consideration of Wikidata's more recent lexicographic data, the rst step towards this would be to implement a RDF serialization of it in Wikidata Toolkit. We invite the Wikimedia Foundation speci cally to consider also releasing o cial Wikidata dumps in an incremental format|such as the one used for Wikidated 1.0|in order to save bandwidth and storage space for users. Additionally, we would welcome any way to access and integrate revision data of deleted entities and revisions into Wikidated. While the raw data itself contains sensible personal information and copyrighted material that is unavailable to the general public for good reason, the metadata of deleted entities and revisions, e. g., number of deleted statements, is by itself interesting to us. For instance, it could be published by replacing all literal values in deleted revisions with generated ones, thus only preserving the data's graph structure.
Acknowledgments Lukas Schmelzeisen was supported by the German Research Foundation (DFG) via grant agreement number STA 572/18-1 (Open Argument Mining). Corina Dima was supported by the German Federal Ministry for Economic A airs and Energy (BMWi) via grant agreement number 01MK20008F (Service-Meister). Thanks to Raphael Menges for suggesting the name \Wikidated".