Wikibase/Indexing/Data Model

This page describes the proposed data model to represent Wikibase data in graph database, such as Gremlin-compatible database.

Note: this is a draft, not a final solution, and is subject to change without any notice at any moment. Watchlist this page if you want the updates.

Terminology
The data model is based on Wikibase Data Model and the terms like "item", "claim", "property" are derived from that data model. Please keep the terminology compatible with the Wikibase glossary.

To distinguish between Wikibase Properties/Entites and Titan properties and other constructs, the references to Wikibase terms Property, Item , Entity are capitalized.

Titan vertex names are listed as ''italic. ''Titan property (key) names are listed as bold.

Vertices
Each Wikibase Entity (this pertains to both Q and P Entities) is represented as a vertex in the graph. Each Entity has an unique vertex, which has property wikibaseId with its wikibase ID (as is, e.g. Q42 or P31). The vertex also has properties named labelLNG, where LNG is the language code (such as labelEn for the English label) and may have more properties as necessary.

TBD: define which other properties we want on vertices. Descriptions? Aliases? Sitelinks? Badges?

Claims
Claims on Entities are represented by vertices, each vertex representing one claim. The edge leading from owning Entity to the claim vertex is marked by the claim Property, and the claim vertex is linked by edge to either linked Entity or Property, as described below.

The claim edges have edgeType property set to the value of " ".

The claim vertices have wikibaseId property matching the Claim ID in the data set. The ID value is assumed to be constant for the lifetime of the claim, and change to the claim is assumed to produce different ID.

Representing link between Entities
Link between two Entities is represented as an edge going from owning Entity to the claim vertex, and from the claim vertex to the claimed Entity, with edge label being marked by the Property represented by the claim.

For example, if "USA" (Q30) is claimed to be "instance of" (P31) a "country" (Q6256) this produces an edge from vertex Q30 to a claim vertex, labeled P31, and from the claim vertex to vertex Q6256 labeled P31.

Representing Property value
Property value - i.e., claim having non-Entity value, such as string, number, date, location, etc. - is represented by an edge from the claim vertex to the vertex representing the Property, with with the edge label being marked by the Property represented by the claim. The data value is stored in the property of the edge named after the claim Property with suffix value. The same value is stored in the claim vertex itself.

For example, if "USA" (Q30) is claimed to have a population (P1082) of 318,697,314 people, this produces an edge from vertex Q30 to the claim vertex, and from the claim vertex to vertex P1082 labeled P1082 and having P1082value property of 318,697,314. Additionally, the claim vertex would have the same value properties stored on the vertex itself. TBD: we may want to choose one of the storage ways, but so far I'm not sure which one is better.

The separate names of the property values for the edges will allow to create a typed index (such as fulltext or geospatial index) on the values.

Representing data types
The data for the values is stored as presented in imported data, with the exception of the following types which are processed: Along with the data value, for non-primitive types the accompanying data are stored in separate properties, according to the names in the original data prefixed with the value name above, i.e. for globe-coordinate value stored as value for P625, along with property P625value, there would be properties P625value_globe, P625value_precision, etc.
 * globe-coordinate - is represented in Titan as Geoshape object. Note that this is a Titan-specific representation which may need to be changed for other backends.
 * monolingualtext - is currently represented as "language:text" string. We may want to seek better representation.
 * time - is represented as Java Date value. TBD: Note that currently values not representable as Java Date are stored as "somevalue".
 * quantity - only the amount is stored

Representing pseudo-values
The pseudo-values " " and " " are represented as edges to special vertices novalue and unknown respectively. The value property of the edge (see above) is unset. This way the property still can have typed index without actually mixing data values with placeholder values.

Representing ranks
The rank of the claim is represented by the property rank of the edge leading to the claim vertex and on the claim vertex itself. The claims with rank "deprecated" are ignored on import and are not represented in the indexing data set.

TBD: Although deprecated statements will probably not be queried that often, we should try to import and index all data.

Representing qualifiers
The qualifiers are modeled the same way as properties, but attached to the claim edge instead of Entity edge. For example, qualifier "point in time" (P585) attached to the claim about the US population would produce the edge from the claim vertex to P585 vertex with P585value property containing the date value. The Entity-values properties in the same vein are represented as edges to the vertex corresponding to that Entity.

The edges representing qualifiers have edgeType property set to " ".

Preferred/best value representation
For some properties, there can be multiple claims but only one value (or subset of values) of the claim is preferred. For example, for property "population" on the "USA" there are a number of values, but only one represents the current US population. Or for a person, there could be number of companies he has been employed at, but only subset of those are the current employers.

It is proposed to have an additional edge(s) for such properties, to make the queries against current values easier. These edges have names like the regular property edges but with _best suffix appended. So, for US population the edge would be named P1082_best.

Such edges would correspond to claims that have either one the following properties: If there are no preferred ranks and no suitable qualifiers on any of the claims, then no values are considered to be the "best". If some of the claims have the qualifiers and some do not, we consider the data with no time point defined as being one of the "best" values, if there are any other "best" values, otherwise there are no "best values". If there are values that fit both criteria 2 and 3, the start date is compared to the point in time value, and the latest one is considered the "best".
 * 1) Have the rank "preferred". If one of the claims has this rank, only ranking is considered and the following criteria are ignored.
 * 2) If the claims on the property have the "point in time" (P585) qualifier, the latest value is chosen as the "best".
 * 3) If the claims on the property have "start date" (P580) and "end date" (P582) qualifiers, the value that has start date in the past and does not have end date or has one in the future, is chosen.

If there are no values that fit the "best" criteria, no additional edges are created.

Note that multiple values can be chosen as "best", and the "best" values are always the subset of the all property values represented by the regular edges.

TBD: this proposal is not strictly necessary for implementing all the above and represents the performance-oriented enhancement and the means to simplify common queries. If the data would be properly ranked for all relevant values, the additional logic may not be necessary and usage of the rank property may be enough, but currently we may want to keep it considering the current state of the data.

TBD: We may also opt to replace two edge names with edges named the same but having additional parameter - such as bestValue - that would encapsulate the logic described above.

Criticism (by Daniel)
I see several issues with the heuristics for "best" values described here.
 * 1) It doesn't match the spec. The wikibase data model defines the semantics of ranks such that for a query, the only "preferred" claims for a given properties should be considered, if there are any. If there are no "preferred" claims, only the "normal" claims shall be considered. The claims that are thus defined to be relevant to queries according to this are referred to as the "best" claims for that property.
 * 2) It leads to surprises. The graph database is intended to be used for queries, not searches. Queries have a well defined result set, which should be clearly predictable to the author of the query. Predictability is important; A search index may used heuristics to follow the actual content. A query index should have clearly defined behavior, and allow content to me modeled accordingly.
 * 3) Applying such heuristics takes away one of the main incentives to actually rank statements manually (resp by bot). Explicit ranking is extremely valuable, and useful for using values in infoboxes etc. One reason we don't see many "preferred" ranks on Wikidata is that they don't have much effect yet. Once people see how ranking effects query results, this will hopefully be used a lot more. The heuristics suggested here would obscure this effect.
 * 4) The heuristics may have averse "political" consequences. When designing the wikibase model, we took great care to allow for competing views and contradictions. Having e.g. census data ignored because it's a year older than information from another entity may lead to confusion and even animosity (yes, people get into fights about the population of China, or Israel, or India, because it very much depends on which regions you include as territory - this is highly political stuff).
 * 5) One of the wiki principles is: avoid magic, let the community edit content. This means here: leave it to the community if, when, and where they want to apply heuristics like "the newest value is the best". They can write a bot that changes the rank accordingly, with a record in the history, discussions on the wiki, etc.

Illustration
Here is the example (partial) representation of the vertex "USA" and its properties: