Multi-attributed relational structures (MARSs) have been proposed as a formal data model for generalized property graphs, along with multi-attributed rule-based predicate logic (MARPL) as a useful rule-based logic in which to write inference rules over property graphs. Wikidata can be modelled in an extended MARS that adds the (imprecise) datatypes of Wikidata. The rules of inference for the Wikidata ontology can be modelled as a MARPL ontology, with extensions to handle the Wikidata datatypes and functions over these datatypes. Because many Wikidata quali ers should participate in most inference rules in Wikidata a method of implicitly handling quali er values on a perquali er basis is needed to make this modelling useful. The meaning of Wikidata is then the extended MARS that is the closure of running these rules on the Wikidata data model. Wikidata constraints can be modelled as multi-attributed predicate logic (MAPL) formulae, again extended with datatypes, that are evaluated over this extended MARS. The result models Wikidata in a way that xes several of its major problems.
have an instance of link to person. But as of mid-June 2020 there are only about 30 items that have an instance of link to person|far fewer than the over 7.9 million humans in Wikidata. To nd all instances of person in Wikidata requires asking for instances of the transitive closure of subclass of under person. Again, it is not hard to remedy this particular problem, and it is so important that most accessors of Wikidata make the extra e ort to look through subclasses. On the other hand, based on our personal experiences the analogous workaround for subproperties is often not done.
As yet another illustrative example, what if an application wants to know what information is current, i.e., true at the present time. Wikidata has quite a number of constructs that specify temporal extents for pieces of information, including end time. How can the application know what it needs to do to lter out statements that are not valid at the current time?
Providing an interface to Wikidata that presented all and only the valid information would make it much easier to write applications that just want to know what's true based on what is in Wikidata, as opposed to how the information is said or who said it.
Maybe this e ort is doomed to be fruitless. Maybe Wikidata is just data and there is no way to provide a decent logical view of the data in Wikidata. This would indeed be a shame, as Wikidata is the best example of an open Knowledge Graph, and so it should be possible to treat the Wikidata data logically.
The need for well-founded reasoning capabilities in Wikidata has been noted and lightly documented in a WikiProject, but to date this project has not produced any concrete results. The current work may be viewed as a proposal to satisfy a superset of the requirements documented there.
Wikidata is data, but many portions of Wikidata that are vital to Wikidata's utility and success are conceived, discussed, and documented as if Wikidata is more than just data, as illustrated by spouse and instance of above. To reliably provide construction of the meanings implicit in the descriptions of even the central properties of Wikidata requires a formal theory for the properties and an implementation of this theory. Without such, di erent users and tool builders end up determining and implementing the meaning on their own, and this often produces di erent, non-compatible results.
One way of providing a common meaning is via a set of axioms in a logic and a service that implements reasoning in the logic. The service then provides a common resource that serves up the meaning of the various pieces of Wikidata. This is particularly vital for the central, ontological portion of Wikidata, including instance of as well as symmetric property.
Other parts of Wikidata are also currently under-speci ed and di erentially implemented and can be improved by a logical formulation. Wikidata constraints express regularities that are supposed to hold in general, but which may have exceptions. These constraints are not used to draw inferences but instead to point out potential problems to interested constributors who can then either x the problem or indicate that the particular anomaly is acceptable.
Wikidata constraints, albeit useful, are represented and processed in an incomplete, ad hoc fashion. Although in most cases they are declared and documented reasonably clearly, the declarations do not fully express their meaning, and thus do not provide a precise, unambiguous basis, or a logical foundation, for constraint-checking implementations. Further, building a constraint checker for a new constraint may be laborious, idiosyncratic, and error-prone. A logical formulation and implementation of constraints would permit constraints to be quickly speci ed and eliminate the implementation burden for each new type of constraint.
As noted in [
Wikidata has many classes and properties, such as female human, that are missing many of their expected instances or relationships. Axioms that give a logical formulation for these classes and properties would add back their missing elements and eliminate the incorrect information that currently comes from accessing them in Wikidata.
Wikidata has several ways of providing something other than a particular value for a property. The some-value snak represents some \unknown" value and the no-value snak says that there is no value. However the precise meaning of both of these is unclear, and a logical formulation for them would provide a better meaning for these parts of Wikidata.
We provide a logical foundation for Wikidata, building on previous work on
multi-attributed predicate logic (MAPL), including multi-attributed rule-based
predicate logic (MARPL) and multi-attributed relational structures (MARSs)
[
Wikidata's custom data model goes beyond the Property Graph data model, which associates sets of attribute-value pairs with the nodes and edges of a directed graph. Marx et al. refer to such generalized Property Graphs as multiattributed graphs, and observe that \In spite of the huge practical signi cance of these data models ..., there is practically no support for using such data in knowledge representation". Given that motivation, Marx et al. introduce the multi-attributed relational structure (MARS) to provide a formal data model for generalized Property Graphs, and multi-attributed predicate logic (MAPL) for modeling knowledge over such structures. MARS and MAPL may be viewed as extensions of FOL to support the use of attributes (with multiple values).
The essential new elements over FOL are these: a set term is either a set
variable or a set of attribute-value pairs fa1 : b1; :::; an : bng, where ai; bi can be
object terms. Object terms are the usual basic terms of FOL, and can be either
constants or object variables. a relational atom is an expression p(t1; :::tn)@S,
where p is an n-ary predicate, t1; :::tn are object terms and S is a set term. a
set atom is an expression (a : b) 2 S, where a; b are object terms and S a set
term. These elements are best illustrated with a simple example (from [
Marx et al. go on to introduce multi-attributed rule-based predicate logic (MARPL), roughly the Horn-clause fragment of MARS plus functions that compute the attributes of atoms in the consequent of rules. MARPL is decidable for fact entailment, but still provides a high level of expressivity. Note that Formula 1 falls within the MARPL fragment.
MARPL is close to what is needed as a basis for Wikidata but MARPL is missing datatypes and each rule in MARPL has to speci cally account for attributes (essentially the quali ers of Wikidata). Datatypes play a large role in Wikidata and handling Wikidata quali ers correctly requires accounting for many qualiers in each of many rules, which is infeasible from a practical perspective with MARPL. Using an extension of MARPL means that we have the chance of being able to relatively easily compute the consequences of Wikidata. We also use MAPL formulae in constraints, so we also need to extend MAPL.
As MARPL and MAPL are based on MARSs we start by adding datatypes to
MARSs. As Wikidata, like RDF [
Wikidata datatypes. The de ned datatypes of Wikidata are IriValue; StringValue; MonolingualTextValue, strings with language tags; MultilingualTextValue, strings in multiple langauges; QuantityValue, with an associated unit; GeoCoordinatesValue, in some coordinate system; and TimeValue, including a timezone. The last three of these are unusual in that they have imprecise values, containing a main value and some notion of precision (not necessarily symmetric), indicating an interval or range of possible values.
In our datatype theory for Wikidata all datatypes have equality and inequality relations that take into account all aspects of the data values. The precise datatypes have the usual set of relations and functions that extract their pieces.
Imprecise datatypes have as well equality and inequality for their main values, a predicate for whether a value is precise, and overlaps and disjoint and emptiness. They also have intersection functions that result in a smallest (in imprecision) value that includes the intersection of the two values, if the two values intersect, otherwise an empty value (not currently in Wikidata) results; and a kind of union function that produces a smallest (again in imprecision) value that includes both the values. (Some imprecise Wikidata datatypes have multiple values that are equivalent. Some imprecise Wikidata dataypes are not closed under intersection.)
QuantityValue has ordering relations of three avours, one for the main value, e.g., the main value of the rst argument is less than that of the second; one for necessary ordering, e.g., all possible values of rst argument are less than those of the second; and and one for possible ordering, e.g., some possible values of rst argument is less than one of the second. GeoCoordinatesValue has various direction relations, such as north of, must be north of and can be north of, the latter two taking into account imprecision.
TimeValue has ordering relations, as for QuantityValue, although the base names are before and after. There are also functions to return the part of one time that must (or can) be before (or after) the second. As well, there is a rst function whose returned TimeValue has a main time, rst possible time, and last possible time that are the earlier ones from either of its two (TimeValue) arguments, and an analogous last function.
This is just an initial set of relations and functions, and needs expansion.
Extended MAPL (eMAPL) is then MAPL based on eMARS. Datatype predicates and functions are allowed in eMAPL, of course. To support the representation of constraints, we add equality and, as syntactic sugar, counting quanti ers. De nition 3. eMAPL terms are MAPL terms with the addition of datatype function applications. eMAPL formulae are MAPL formulae using eMAPL terms plus the addition of datatype relations as predicates, an equality predicate, and counting quanti ers. Atoms with datatype relations cannot have non-empty attribute sets.
De nition 4. An eMAPL interpretation is a MAPL interpretation with the following additions and modi cations: { An eMAPL interpretation is into an eMARS. { The interpretations of datatypes, predicate and datatype relations, and functions are themselves. { The interpretation of a datatype function term is the application of the ( xed) function to its arguments. { The interpretation of datatype relations use the datatype relation itself. { The interpretation of the equality predicate is the identity relation. { Counting quanti ers have the obvious interpretation. 2.3
eMAPL rules Because we are interested in e ective reasoning, we restrict axioms to rules. We make the usual additions and allowances for datatype predicates and functions. De nition 5. An eMAPL rule is a MAPL rule modi ed as in eMAPL. (Note that the functions in MAPL rules are di erent from datatype functions.) A variable is relational if it occurs in the rule body as the argument of a predicate that is not a datatype relation (including the datatype equality relations). Terms in rule bodies can use datatype functions, but the variables in these terms must be relational. Atoms in rules can use datatype relations but variables in these atoms must be relational.
Remember that in MARPL ontologies attributes are processed using rules that take attributes and their values from instantiations of body atoms and determine how they augment the head instantiation that is the consequent of the rule. We want to be able to handle attributes (Wikidata quali ers) in a uniform manner so that each rule does not need to say, for example, how the Wikidata temporal quali ers are processed.
We do this by characterizing each Wikidata quali er, providing instructions on how it is to be processed in each rule that does not say anything about how the attribute's values are added to the consequences of the rule. De nition 6. An attribute is characterized in one of several ways. { No values for the attribute are to be added to the consequents of rules. We expect that most quali ers will have this (default) ignore characterization. { The values of the attribute in the facts matched by body atoms are each added to the consequents of rules, in an additive fashion. { The consequents of rules are given a single value for the attribute, formed by combining all the values for the attribute in matched body atoms by a datatype function that maps pairs of values in one datatype into a value in the same datatype. If the result fails to satisfy a unary predicate then the rule produces no result. { The most sophisticated characterization involves starting by combining values for several attributes as above and then blending the resultant values using a di erent function, provided that the resultant values satisfy a datatype relation.
Combination is only suitable for an attribute whose value has the datatype of the function. The datatype function should be commutative and associative, but other functions could be used if there is only a single value for the attribute, with the resultant value being the left reduction of the values taken in the order of occurence in the body of the rule.
Wikidata quali ers. Wikidata has the quali er point in time, which is used to state when some statements are valid. Combining statements with this quali er should take into account whether the time intervals overlap, so this quali er would be characterized as a combining quali er with the intersection function and the emptiness predicate.
Other Wikidata statements use the quali ers start time and end time to indicate the period when the statement is valid. To produce the value for start time when making inferences from statements with these quali ers requires rst nding the last possible start time and the rst possible end time and then taking the part of the combined start times that can be before the combined end times.
So the Wikidata start quali er could be characterized as a blending quali er by rst combining start and end quali ers using the last and rst functions, respectively, giving start and end times for the result, and then using the could be before function to cut out start times that cannot be before the end time. If there is no start time before the end time (not could be before is true between the combined start and end times), then the inference produces no result.1 De nition 7. An eMARPL ontology consists of a nite set of eMAPL rules, a nite set of function de nitions, and a nite set of attribute characterizations as above. The function de nitions are as in MARPL ontologies except that they can have datatype function terms in their consequences (i.e., in the consequents of their conditionals).
These attribute characterizations are used as macros, modifying the functions and rules of an eMARPL ontology.
De nition 8. The expansion of an eMARPL ontology uses the attribute characterization to modify its rules as follows: { First give each rule its own function by making copies of functions or creating a new function for the rule. Ensure that each atom in the rule body has its own set variable, adjusting the function as needed to access this set variable. { For each attribute whose characterization is addition, for each rule where the function does not mention the attribute in its consequences, augment the function to copy over all the attribute's values. 1 In actuality, all three of these quali ers should take into account all of them, so a better characterization would have a more complex blending speci cation. { For each attribute whose characterization is combine, for each rule where the function does not mention the attribute in its consequences, augment the function to add a single attribute value that is the combination of all the values in the body atoms. Also add a new body atom to check whether the combined value satis es the combination predicate. This will require adding multiple clauses to the function as well as splitting the rule to take into acccount the presence or absence of the attribute in body atoms. { For each attribute whose characterization is blend, for each rule where the function does not mention the attribute in its consequences, augment the function to compute the combination values and add the blend result. Also add a new body atom to check whether the blended value satis es the blend predicate. This will cause similar but more pronounced increase in the number of clauses than combination attributes.
The meaning of an expanded eMARPL ontology on an eMARS is just the inferential closure of the rules on the eMARS. 2.4
An expansion can be exponentially larger than the original ontology in the number of attributes with combination or blending characterizations. Implementations would not actually construct the expansion, instead gathering up values internally and applying the functions and predicates only to the existing values. So the size of the expansion is not a real complexity problem, by itself.
Datatype functions and relations are limited so that rules cannot add new datatype values to predicate extensions, eliminating this particular cause of intractability or undecidability in rules.
Even so, reasoning in MARPL, let alone eMARPL, is intractable because the number of attribute values can grow large. We view this as unavoidable, but we do not expect this worst-case intractability to be much of a problem in practice. 3
Now that eMARPL ontologies have been de ned we can show how we determine the meaning of Wikidata as an eMARS. Following that, we will show how the eMARS can be used to check Wikidata's constraints.
Objects in Wikidata are items, which include predicates (properties). Facts in Wikidata are statements, consisting of a subject (an item) and a main snak. Snaks are predicate-object pairs, or some-value snaks, or no-value snaks. Statements also have associated quali ers, which are also snaks. Statements have a rank, which is regular, preferred, or deprecated. Wikidata also provides optional typing information for the values of properties. We also use a characterization for each property used in a quali er in Wikidata; a set of ontological rules for Wikidata; and a set of constraints.
First we turn Wikidata itself into an eMARS. The domain elements of the eMARS are all the items in Wikidata, with additions as below. The predicate extensions in the eMARS are pairs of subjects and objects from statements with the predicate as property. Statements whose main snak is a some-value snak are modelled by adding a fresh element to the domain. (This treats a somevalue snak as stating that its value is a distinct domain element, which might not be quite the best treatment, but avoids computational problems having to do with determining which regular domain element the value is equal to.) Each quali er snak becomes an attribute of the statement, in the obvious manner. For statement ranks we add a special rank attribute with value preferred or normal. We ignore reference records for now.
Statements whose main snak is a no-value snak are ignored here, and left for future work. We think the best treatment of a no-value snak is as a constraint but it is unclear whether a no-value snak means no value at all, no value with the same quali ers, or something in between. These options can be modelled as eMAPL constraint formulae.
Property typing is modelled as rules requiring that the values of the property belong to the datatype. So the datatype for date of birth is modelled by the rule: date of birth(s; o) ! Point in time(o) (2) 3.1
Some parts of formalizing the Wikidata ontology have already been described above as examples of quanti er characterizations. Arguably, the most important part of this formalization, though, is formalizing the ontological rules of Wikidata.
The ontology problems with Wikidata can be solved by treating Wikidata as an eMARPL ontology, transforming Wikidata into an eMARS and adding a few ontology rules, such as those shown in (3). Each atom on the right-hand side of these rules is implicitly associated with an attribute set that is constructed by a rule function.
subclass of(c; d) ^ subclass of(d; e) ! subclass of(c; e) instance of(y; c) ^ subclass of(c; d) ! instance of(y; d) subproperty of(c; d) ^ subproperty of(d; e) ! subproperty of(c; e) subproperty of(p; q) ^ p(x; y) ! q(x; y) (3) instance of(p; symmetric property) ^ p(y; x) ! p(x; y) instance of(p; transitive property) ^ p(x; y) ^ p(y; z) ! p(x; z)
These rules look higher order, but they are not. The quanti cation is only over Wikidata properties, so the rules can be rewritten using a triple-based formulation, as in: T(p; instance of; Wikidata property) ^ T(p; subproperty of; q) ^ T(x; p; y) ! T(x; q; y)
So far, these ontology rules are just MARPL, and even just regular Horn rules. But Wikidata quali ers need to be taken into account, even if quali ers are forbidden in ontology atoms (i.e., those with predicates instance of, subclass of, subproperty of), because of occurrences of non-ontology atoms such as p(x; y) in some rules. In MARPL, such rules would either have to take into account every possible Wikidata quali er, or di erent rules would have to be written for each Wikidata property, but even these rules would have to take into acount all the quali ers that are present on Wikidata statements for the property. In eMARPL a single rule can be written, without regard to quali ers, and the quali er characterizations are used to handle the quali ers that are present. The most important, and most involved, Wikidata quali er characterizations are probably the ones for temporal quali ers, as they impact very many statements in Wikidata and missing temporal quali ers can lead to considering statements that are not relevant to the user's context. The characterizations of temporal quali ers above as blending attributes are, we feel, typical and show o the capabilities of eMARPL.
Many Wikidata quali ers have little logical import or are speci c to a
statement, such as the measurement method used to determine a statement or the
location of an event. The former can be simply ignored for most uses of
Wikidata and the latter, although of interest, should not be carried along in most
inferences, so they would be classi ed in the default classi cation. Other
Wikidata quali ers have logical import and thus should be carried along, but are
multivalued and do not in general interact with other quali ers. These can be
categorized in the \additive" categorization.
The meaning of Wikidata is then the inferential closure of the eMARS above
under this eMARPL ontology. It is this eMARS that is to be used when querying
or otherwise requesting what is true in Wikidata, or checking constraints.
Wikidata has constraints that do not add directly to the meaning of Wikidata
but instead provide signals that there is something questionable in Wikidata,
consistent with the view taken by other work on constraints for
knowledgegraph-like systems [
For example, the distinct values constraint in Wikidata is supposed to say that a given property should have di erent values for di erent items. Constraints like this one are currently implemented (if at all) by special-purpose code. The following eMAPL formula embodies this constraint property constraint(p; distinct values constraint)^ p(s1; o1) ^ p(s2; o2) ^ s1 6= s2 ! o1 6= o2 (4)
In a separate paper [
Adding a rule of the form instance of(human; h) ^ sex or gender(h; female) ! female human(h) (5) results in female human having the correct instances.
Many other notable under-populated classes can be handled in the same way. 4
We highlight relevant work from several slices of logical foundations for knowledge bases,
Logical foundations for Wikidata. SQID [
Logical foundations for annotated KBs. Annotated RDFS [
Adding attributes to logics. Just as MARPL was developed to provide a
(rulebased, Datalog-like) decidable fragment of MAPL, Krotzsch, Ozaki, et al. have
2 SQID's rule set may be viewed at https://tools.wm abs.org/sqid/#/rules/browse.
also explored description logics as a basis for other decidable fragments of MAPL,
and have analyzed the resulting family of attributed DLs in [
We have described eMARS, eMAPL, and eMARPL (extensions of previous work
of Marx et al. [
Our plans for future work include the discussion of other areas of Wikidata that can bene t from its use and the creation of a prototype implementation and then a detailed design for a scalable deployment.