When developing a knowledge graph, it is important to promote its (re)usability, accessibility, and persistence. One way of accomplishing (re)usability is through the principled use (i.e., using a structured development methodology) of a schema that describes and documents the relations between concepts in the knowledge graph. With respect to accessibility and persistence, one can consider exposing a SPARQL endpoint and allowing interested parties to query against it. While this is a very exible approach, it makes it di cult to explore the data. On the other hand, one could consider exposing data through a framework such as Wikibase. In this paper, we provide a small library of patterns that link between a traditional ontology design pattern and the underlying Wikibase data model.
When developing a knowledge graph, there are many aspects to consider during
its deployment. These range from usability of its interfaces (both human and
programmatic), the (re)usability of the data that it contains, its accessibility
(both in terms of uptime and its interfaces), transparency (relating to
provenance and trustworthiness), and its persistence. These characteristics are neatly
summarized in the FAIR manifesto [
Modular Ontology modeling (MOMo) speci es the development of a module
for sets of tightly bound key notions that will be included in a given ontology
[
As one of the largest publicly editable and accessible knowledge bases, Wikidata is an immense, crowdsourced knowledge base with persistent data that is available for public use and consumption. It would be very di cult to have an ontology of everything, but Wikidata is probably close enough for this purpose. It contains millions of pieces of knowledge from many di erent domains in the world. In addition, Wikidata serves as the structured data hub for all of Wikimedia's projects (e.g., Wikipedia, Wikivoyage, Wiktionary, and Wikisource). As such, when modeling an ontology, it makes sense to consider ease of integration with resources like Wikidata, among other Linked Data Platforms.5 Wikibase is the underlying technology for the Wiki- projects.
The Enslaved Ontology [
During development, we had assumed that it would be relatively easy to
adapt the modular Enslaved ontology to the Wikibase model. Unfortunately,
between di erent semantics for validating data to be put into the knowledge
base and unclear mapping between di erent notions of provenance, it was not
as straightforward as we had expected. In the meantime, we developed some
simple and complex mapping patterns between the Enslaved modular ontology
and the Wikibase model, established in the Enslaved benchmark [
This paper takes an alternative approach by starting at the beginning of
the modeling process. In particular, by utilizing a library of ontology design
patterns that have been speci cally engineered to explicitly represent how
Wikibase models data \under-the-hood," thus ensuring that the ontology is optimally
structured for interoperability with Wikibase. This library can be used by any
organization to model their own internal and proprietary knowledge graphs and
apply their alignments to Wikibase model as an important tool to augment or
induce new information into their own knowledge graph. In particular, this paper
provides the rst 6 set of such patterns for representing basic modeling problems
alongside an intuitive graphical notation of these patterns.
3 We focus on the MOMo paradigm as it is closely aligned with our use case, but any
pattern-based methodology, such as eXtreme Design [
We have developed two layers of notation. The rst layer, which we refer to as abbreviated, focuses on what an end user would input if they were adding an entry to Wikidata via the web interface. The second layer, referred to as expanded, builds on our abbreviated notation by including additional context information that Wikibase adds to statements, depending on their type and content. Our abbreviated notation, seen in gure 1, has the following syntax: 1. Gold boxes with solid borders refer to a Wikibase entity or item. 2. Arrows between nodes denote the type and direction of the relationship. In the diagrams, each relationship will have a pre x, which gives the type of the relationship, followed by a colon, and then the name of the property.
The di erent pre xes are explained in Section 2. 3. Blue ovals denote a speci c datatype. 4. Sometimes a property label may emit arrows; these represent context about the relationship. This is explained in detail in Section 3. 1. Gold boxes of the form prefix:<hash> refer to hash nodes created by Wikibase in order to add context statements to the relationship. 2. Purple boxes are explicit typing information added by Wikibase to give the type of the hash node. 3. Arrows pointing to a purple box are rdf:type.
The rest of this paper is organized as follows. Section 2 brie y outlines the standard Wikibase model in order to provide context for the rest of the paper. Section 3 describes our developed patterns with their schema diagrams. Section 4 concludes with future work. A Wikibase knowledge base is a collection of entities. Entities are the basic elements of the knowledge base, which can be described and referenced using the Wikibase data model. The Wikibase data model describes the structure of the data that is handled in Wikibase. In particular, it speci es which kind of information users can contribute to the system. In this section, we introduce how Wikibase models data in RDF format and some basic concepts that will be used in the rest of the paper.
There are several prede ned concepts in Wikibase data model introduced as follows: { Items: Items are the way Wikibase refers to anything of interest. For every Item, there is some basic information that clari es what the Item is about, such as the link to a Wikipedia page in some language. Each Item has a unique identi er of the format Q<number>, with a pre x of wd:, which is abbreviation of http://www.wikidata.org/entity/, such as wd:Q1234 in gure 3. There are also human readable labels and short descriptions that are used to help Wikidata users nd the right Item. { Statements: Statements are descriptions that users have entered about the Item. The RDF format represents statements in two forms. The rst type is named as a Truthy statement. These are simple triples that assert facts. The other statement type is the Full statement, which is used to represent all data about the statement in the system. To di erentiate them, Wikidata usually uses speci c namespaces in speci c places in both truthy and full statements. For example, in gure 3, the namespace http: //www.wikidata.org/prop/direct/, which is abbreviated using the prex wdt:, is usually used for the predicate of a truthy statement, and the range of the predicate is the simple value for the statement. The full statement is represented as separate node using property rei cation, with pre x wds: (http://www.wikidata.org/entity/statement/) with the ID of the statement (e.g., wds:12345678 in gure 3). There is no guaranteed format or meaning to the statement id. The statements are linked to the entity with the predicate with pre x p: (http://www.wikidata.org/prop/) and the name of the property. The simple value is represented by the predicate with pre x ps: ( http://www.wikidata.org/prop/statement/) and the name of the property while the full value is represented by the predicate with pre x psv: (http://www.wikidata.org/prop/statement/value/). { Quali ers: The statement always has no more than one value, but can have multiple quali ers and references. The quali ers are used to further describe or re ne the value of a property given in a statement. They are represented by predicates with pre x pq: (http://www.wikidata.org/prop/qualifier/), and the object is the simple value of the quali er. The full value is represented by the predicate with pre x pqv: (http://www.wikidata.org/prop/ qualifier/value/), and the range of the predicate is the full value node. { References: References o er a source that supports the given claim. They are represented by the predicate prov:wasDerivedFrom with the object being the reference node. Similar to quali ers, the simple value of the reference is represented by predicates with pre x pr: (http://www.wikidata.org/ prop/reference/), while the full value is represented by the predicate with pre x prv: (http://www.wikidata.org/prop/reference/value/). In what follows we outline the patterns we have designed. In each pattern diagram, we follow the notation syntax outlined in Section 1.1, and shown in gure 1 and gure 2. For each pattern, we show our two notations: { Our abbreviated notation shows what an end user might provide in the front-end interface of Wikibase if they were to add an item of that datatype (string, dateTime, quantity, etc.) and usage (statement value vs quali er). { Our expanded notation shows the additional context information that Wikibase adds to the given datatype/usage combination.
The patterns we have provided here are only a starting point. Wikidata and
Wikibase o er native support for an ever-growing list of datatypes, and even
more can be de ned with various extensions. We have chosen to focus initially
on three core datatypes that are de ned in OWL [
(a) Abbreviated
(b) Expanded
The essential components of Wikibase, and what makes it an intensely powerful platform for knowledge management, are the statements that describe each entity. Each statement makes a claim about the entity, and may or may not have a quali er - which provides additional information about the claim (such as when the claim was valid) - or a reference (where the claim was sourced from). These statements link and describe entities in a structured way that we have modeled in gure 4.
The abbreviated model for this ( gure 4a) is fairly straight forward. We have an entity, seen here in the gold box containing wd:Entity, linked by a property shown in the green box to another entity. Context information is then provided for that speci c Entity-Property-Entity relationship, which may include one or more quali ers or references. Each quali er is linked to the statement by a pq:PXXX identi er, with the pre x pq: here denoting that the relationship is that of a property quali er. References are linked via prov:wasDerivedFrom which will be expanded upon below.
The expanded model, seen in gure 4b, shows not only the information described above, but also yet more context information provided by Wikibase to each statement. Starting again from our main wd:Entity node, we see it liked by a property identi ed by a property ID with the format p:PXXX to a hashed node, identi ed by s:<hash>. For the property, the pre x p: denotes that the type of the relationship is that of a property, while the PXXX provides the property ID. On the hashed statement node, s: here denotes that the node is a statement. Coming o of the s:<hash> node, we see the link to another wd:Entity via a property statement with the format ps:PXXX. As with the abbreviated diagram, quali ers are linked via pq:PXXXX.
The three nodes on the left, pre xed with wikibase: are information added by Wikibase to describe the statement. The rst, wikibase:Statement types the hashed node as a statement, rather than a quali er or a reference. The other two, wikibase:BestRank and wikibase:NormalRank provide the style of ranking for the statement, and denote whether or not this statement is the \best" statement for this Entity-Property-Entity relationship. For example, if an entity is linked to two other entities, both by the same property, one of them can be ranked higher than the other, denoting it as the \best" or preferred value for the statement.
If a reference is provided for a given statement, Wikibase creates another
hashed node linked via prov:wasDerivedFrom [
The quali er example in gure 4b, as with many datatype values, has a complex structure that we will elaborate on in the next section. 3.2
In the patterns that follow, we will see that there is some signi cance to whether a given datatype is used as the value of a statement or a quali er. Let's rst look at the use of a dateTime, shown in gures 5 and 6.
The abbreviated notation is quite straightforward indeed. As a statement value, an entity is linked to a dateTime value via a property. But, as shown in gure 5b and as mentioned in section 3.1 above, Wikibase adds several data points to this that make each statement much more useful. In addition to the information added to the s:<hash> node, including a simple representation of the value via ps:PXXX, Wikibase adds another hashed node. This time the added (a) Abbreviated node will house the additional context information about the value. The statement node is linked to the v:<hash> value node via psv:PXXX, with the pre x psv: denoting the relationship as that of a property statement value.
Wikibase types the value node explicitly via wikibase:timeValue. In this instance, given that the datatype is a dateTime value, Wikibase adds a link to the Wikidata entity for the calendar model used (i.e. Gregorian, etc.) via wikibase:timeCalendarModel. Also provided is a number representing the timezone in o set from UTC, via wikibase:timeTimezone, and a number representing the time precision via wikibase:timePrecision.7 Lastly the value node links back to the simple value for the dateTime via wikibase:timeValue. 7 There are 15 levels of time precision on Wikibase, with 0 corresponding to "billions of years", and 14 corresponding to seconds. (a) Abbreviated
When a dateTime is used in a quali er, the internal structure for the v:<hash> node remains unchanged. However, rather than linking to the statement hash node via ps:PXXX and psv:PXXX, it is via pq:PXXX and pqv:PXXX respectively.
The quantity pattern ( gures 7 and 8) mimics some of the features of dateTime, but Wikibase then adds some speci c data about the quantity mentioned. When the quantity is being used as the value of a statement, the abbreviated notation continues to be quite simple. A wd:Entity is linked to a xsd:decimal via a property.
Expanding that model out, we see that Wikibase again adds a hashed node (v:<hash>). The statement hash links to the simple value for the quantity via ps:PXXX and to the value node via psv:PXXX.
When the quantity is a quali er, our abbreviated notation ( gure 6a) shows that the quantity is linked to from the property via pq:PXXX. In its expanded form ( gure 6b), Wikibase creates the same v:<hash> node mentioned previously however it links to the corresponding nodes via pq:PXXX and pqv:PXXX.
Wikibase adds two datapoints for a quantity, whether it is a statement value or a quali er. Firstly, it types the hash node via wikibase:QuantityValue. It also links to the Wikidata entity for the unit of measurement for that quantity via wikibase:quantityUnit. Finally, the value node links back to the simple value of the quantity via wikibase:quantityAmount. 3.4
(a) Abbreviated (a) Abbreviated (b) Expanded
In a slight deviation from the previous datatypes, Wikibase only adds ranking (wikibase:rank) and typing (wikibase:Statement) information for a statement with a string ( gures 9 and 10).
As the abbreviated notation shows, when used as the value of a statement, an entity is linked to a string via a property. In the case of a string being used as a quali er, a property is linked to a string via pq:PXXX.
Notably, no value node is created for a string. 4
When developing and deploying a knowledge graph, there are many obstacles
to a persistent, transparent, and usable resource. One way to overcome these
obstacles is to use the Wikibase framework. In this paper, we have represented
several common modeling constructions in a graphical syntax that makes it clear
how they map into the Wikibase context. This should allow ontology developers
to more quickly, accurately, and with reduced e ort create ontologies (or
knowledge graph schema) that are \Wikibase ready," thus improving persistence and
accessibility of the deployed knowledge graph. With a base understanding of
how these frequently occurring design patterns are represented in the Wikibase
model, there are many potential next steps. Of particular importance and
urgency would be
1. the complete translation of MODL [
Regarding the former, this would facilitate the creation of arbitrary, modular ontologies that are intended to be deployed to the Wikibase framework, thus encouraging a persistent (if Wikidata is utilized) and usable deployment of the knowledge graph in question. For the latter, we will be able to examine the e cacy of our approach by comparing the re-implementation of the Enslaved Ontology patterns to the manually altered modules utilized in the Enslaved Portal (see https://enslaved.org/).
Acknowledgements. The authors acknowledge support by the National Science Foundation under Grant 2032628 EAGER: Open Science in Semantic Web Research and Grant 2033521 A1: KnowWhereGraph: Enriching and Linking CrossDomain Knowledge Graphs using Spatially-Explicit AI Technologies, as well as the Mellon Foundation through the Enslaved: Peoples of the Historic Slave Trade.