DBpedia is a community effort that has created the most important cross-domain datasets in RDF, a focal point of the Linked Open Data (LOD) cloud. In its core there is a set of declarative mappings extracting the data from Wikipedia infoboxes and tables into the RDF. However, while DBpedia focuses on publishing knowledge in a machine-readable way, little attention has been paid to the benefits of supporting machine updates. This greatly restricts the possibilities of automatic curation of the DBpedia data that could be semi-automatically propagated to Wikipedia, and also prevents maintainers from evaluating the impact of their edits on the consistency of knowledge. Excluding the DBpedia taxonomy from the editing cycle is a major drawback which we aim to address. This paper starts a discussion of DBpedia making a case for a benchmark for Ontology Based Data Management (OBDM). As we show, although based on fairly restricted mappings (which we cast as a variant of nested tgds here) and minimalistic TBox language, accommodating DBpedia updates is intricate from different perspectives, ranging from conceptual (what is an adequate semantics for DBpedia SPARQL updates?) to challenges related to the user interface design.
? An extended version of this paper including additional details is available in [
Mapping constraints . The specification [
For a Wiki instance I, by M(I) we denote the chase of I with the tgds in M [
Example 1. A tgd formalizing a French DBpedia mapping for clergy: 8U 8I Wi(U; ’fr:Pre´ lat catholique’; I) !
Wd(I; ’titre’; ’Pape’) !9Y Pope(U ) ^ occupation(U; Y ) ^ PersonFunction(Y ) ^ title(Y; ’Pape’)) // “Intermediate node mapping” ^ ...
^ 8X(Wd(I; ’pre´ de´ cesseur pape’; X) ! predecessor(Y; X)) ... ^ (Wd(I; ’titre’; ’Preˆ tre’) ! Priest(U )) ^ (:Wd(I; ’titre’; ’Pape’) ^ : : : ^ :Wd(I; ’titre’; ’Pr eˆtre’) ! Cleric(U )) // “otherwise” ^ 8X(Wd(I; ’nom’; X) ! foaf:name(U; X)) ... ^ 8X(Wd(I; ’nom naissance’; X) ! birthName(U; X))
The specification stipulates that conditions are evaluated in the natural order, and thus every next condition has to include the negation of all preceding conditions. In our case, this is only illustrated by the last, default (“otherwise”) case, since the conditions are mutually exclusive. Note also that no universally quantified variable besides the page URI U and the technical infobox identifier I) – i.e., no variable representing an infobox property, called X in the example – can occur in more than two Wd atoms.
One further particularity of the chase with tgds is handling of existentially
quantified variables. A usual approach is to instantiate such variables by null values, which
could be blank nodes in the case of RDF. The strategy followed by DBpedia is however
different: instead of blank nodes, the chase produces fresh IRIs, avoiding clashes with
existing page URIs. Already the following problem is worst-case intractable for WDFs:
ABox source consistency ASCONS [
Definition 1 (Translation of an infobox update). Let I be a Wiki instance, e = (e ; e+) be an infobox update and let M be a DBpedia mapping. The translation MI (e) of e w.r.t. M and I is a DBpedia update u = (u ; u+) where u = M T (I)nM T (e(I)) and u+ = M T (e(I)) n M T (I).
The inverse translation, casting a DBpedia update as a Wiki update, can be defined similarly, with the difference that such a translation is often not unique or even not existing, for various reasons: (i) many-to-many relations between Wiki and RDF properties: modifying just a single fact can be impossible (ii) updates can cause inconsistencies as directly w.r.t. the previous DBpedia knowledge, as also indirectly, by triggering a conditional mapping rule, causing already existing infobox properties to be transfered to DBpedia, resulting in a clash. Therefore, we define translations based on containment. Definition 2 (Update containment). The syntactic containment u1 u2 holds when u1+ u2+ and u1 u2 is the case. Given an instance I of a WDF (M; T ) the WDF containment u I e between the Wiki update e and the DBpedia update u holds if u MI (e). The proper update containment relations and I are defined analogously.
For the heterogeneous pair u; e of updates as above, we say that e minimally
contains u, written u Imin e, if (i) e(I) satisfies the source constraints of W and
? 62 MI (e), written e 6j=I ?, and (ii) for every Wiki update e0 with e0 e, u 6 I e0
or e0 j=I ? is the case; if e0 e implies u 6 I e0 (that is, the option e0 j=I ? is
eliminated), e is said to faithfully contain u, written u Ifth e. We also use u Iex e
(“exact”) and u =I e as shorthands for (u MI (e)) ^ (MI (e) u).
Intuitively, minimal containment ensures that all insertions and deletions performed by
e are necessary either to implement u or to restore the ABox consistency after
implementing u. In contrast, faithful containment deprecates extending u purely for the sake
of restoring the consistency. The notions of minimal and faithful adapt the semantics
considered in [
Using the above definition, the decision version of the OBDM [
stance I, DBpedia update u, Wiki update e. Test if u
I e holds.
1 See [
The source revision problem is a special case of belief revision problem tailored to the OBDM setting, in which the mapping and the TBox are considered fixed and the ABox is derived: that is, only the infobox data can be actually modified. 3
Discussion and Practical Outlook
OBDM related problems tend to be intractable w.r.t. the worst case complexity even
for simple mapping and ontology languages, such as those underlying DBpedia. Our
initial experiments with the translation of SPARQL updates in this setting (discussed in
[
Little attention has been paid so far to the benefits that the semantic infrastructure can bring to maintain the wiki content. In fact, the DBpedia mapping language has to the best of our knowledge never formalized as a rule language, which this paper does. Our early practical experiments with a DBpedia-based OBDM prototype show that likely not the worst case complexity of update translation is a major challenge in such a system, but defining a reasonable DBpedia-enabled maintenance process, comprehensible user interface, and automatic aid in resolving ambiguities due to the robust design of DBpedia mappings.
Acknowledgements. This paper is funded by the Austrian Science Fund (FWF): M1720G11, and by the Vienna Science and Technology Fund (WWTF), project ICT12-SEE.