Exchanging Data amongst Linked Data applications

Abstract

The goal of data exchange is to populate the data model of a target application using data that come from one or more source applications. It is common to address data exchange building on correspondences that are transformed into executable mappings. The problem that we address in this article is how to generate executable mappings in the context of Linked Data applications, that is, applications whose data models are semantic-web ontologies. In the literature, there are many proposals to generate executable mappings. Most of them focus on relational or nested-relational data models, which cannot be applied to our context; unfortunately, the few proposals that focus on ontologies have important drawbacks, namely: they solely work on a subset of taxonomies, they require the target data model to be pre-populated or they interpret correspondences in isolation, not to mention the proposals that actually require the user to handcraft the executable mappings. In this article, we present MostoDE, a new automated proposal to generate SPARQL executable mappings in the context of Linked Data applications. Its salient features are that it does not have any of the previous drawbacks, it is computationally tractable and it has been validated using a series of experiments that prove that it is very efficient and effective in practice.

Subset of the OWL 2 Lite profile

The OWL 2 Lite profile specification provides a number of constructs that are classified into the following groups [6]: RDFS features, equality, restricted cardinality, property characteristics, general property restrictions, class intersection and meta-information. We analyse them in the following paragraphs. The conclusion is that out of the 43 constructs, the only ones with which our proposal cannot deal are zero-cardinality restrictions, general property restrictions and intersection of classes and restrictions. Our experience proves that this does not hinder its practical applicability since the constructs with which we cannot deal are not so common in real-world applications [21].

RDFS features: This group includes $owl{:}Class,\,rdfs{:}subClassOf,\,rdf{:}Property,\,rdfs{:}subPropertyOf,\,rdfs{:}domain,\,rdfs{:}range$, and $owl{:}Individual$. The only one that our proposal ignores is $owl{:}Individual$, since individuals are retrieved or constructed by means of the executable mappings we generate, but need not be dealt with explicitly in our proposal.

Equality and inequality: The constructs of this group are $owl{:}equivalentClass,\,owl{:}equivalentProperty,\,owl{:}sameAs,\,owl{:}differentFrom,\,owl{:}AllDifferent$, and $owl{:}distinctMembers$. The first two constructs need not be dealt with explicitly, since they are actually abbreviations. If an ontology contains a triple of the form $(c_1, owl{:}equivalentClass, c_2)$, it can be replaced by the following triples, with which we can deal natively:

$$\begin{aligned} \begin{array}{lll} (c_1,&rdfs{:}subClassOf,&c_2) \\ (c_2,&rdfs{:}subClassOf,&c_1) \end{array} \end{aligned}$$

Similarly, if it contains a triple of the form $(p_1, owl{:}equivalentProperty, p_2)$, we may replace it by the following triples, with which we can also deal natively:

$$\begin{aligned} \begin{array}{lll} (p_1,&rdfs{:}subPropertyOf,&p_2) \\ (p_2,&rdfs{:}subPropertyOf,&p_1) \end{array} \end{aligned}$$

The remaining constructs in this category deal with individuals; thus, we may ignore them for data exchange purposes.

Restricted cardinality: The constructs in this group allow to restrict the cardinality of a property, namely: $owl{:}minCardinality,\,owl{:}maxCardinality$ and $owl{:}cardinality$.

The $owl{:}minCardinality$ construct can restrict the minimum cardinality of a property $p$ with respect to a class $c$ to be zero as follows:

$$\begin{aligned} \begin{array}{l} (c, rdfs{:}subClassOf, \_{:}x) \\ (\_{:}x, rdf{:}type, owl{:}Restriction) \\ (\_{:}x, owl{:}minCardinality, \text{`}0\text{'}\hat{~}\hat{~}xsd{:}int) \\ (\_{:}x, owl{:}onProperty, p) \end{array} \end{aligned}$$

Note that, by default, all data and object properties have a minimum cardinality of zero. Therefore, it does not require any special treatment. Similarly, construct $owl{:}minCardinality$ can restrict the minimum cardinality of a property $p$ with respect to a class $c$ to be one as follows:

$$\begin{aligned} \begin{array}{l} (c, rdfs{:}subClassOf, \_{:}x) \\ (\_{:}x, rdf{:}type, owl{:}Restriction) \\ (\_{:}x, owl{:}minCardinality, \text{`}1\text{'}\hat{~}\hat{~}xsd{:}int) \\ (\_{:}x, owl{:}onProperty, p) \end{array} \end{aligned}$$

The previous set of triples can be replaced by $(c, mosto{:}strongDomain, p)$, if property $p$ has class $c$ as domain, or by $(c, mosto{:}strongRange, p)$, if property $p$ has class $c$ as range.

Construct $owl{:}maxCardinality$ can be used to restrict the maximum cardinality of a property to zero or one. In the former case, the property is annulated, which is a case with which our proposal cannot deal; we, however, have not found this to be a practical limitation since it is not common at all to annulate a property. The later case is the default in the OWL 2 Lite profile; thus, it does not require a special treatment.

Construct $owl{:}cardinality$ is a shorthand to combine the previous constructs; thus, neither does it require special treatment.

Property characteristics: This group includes constructs $owl{:}ObjectProperty$ and $owl{:}DatatypeProperty$, with which we deal natively; $owl{:}TransitiveProperty$ must actually be dealt with by a semantic-web reasoner, that is, we can assume that their semantics have been made explicit before using our technique; the rest of constructs are shorthands, namely: $owl{:}inverseOf,\,owl{:}SymmetricProperty,\,owl{:}FunctionalProperty$, and $owl{:}InverseFunctionalProperty$.

If an ontology contains a subset of triples of the form:

$$\begin{aligned} \begin{array}{l} (p_1, rdfs{:}domain, c_1) \\ (p_1, rdfs{:}range, c_2) \\ (p_1, owl{:}inverseOf, p_2) \end{array} \end{aligned}$$

we can transform them into the following triples, with which we can deal natively:

$$\begin{aligned} \begin{array}{l} (p_2, rdfs{:}domain, c_2) \\ (p_2, rdfs{:}range, c_1) \end{array} \end{aligned}$$

Furthermore, we can transform $(p, rdf{:}type, owl{:}SymmetricProperty)$ into a triple of the form $(p, owl{:}inverseOf, p)$. Similarly, we can transform a triple of the form $(p, rdf{:}type, owl{:}FunctionalProperty)$ into the following triples before using our technique:

$$\begin{aligned} \begin{array}{l} (\_{:}x, rdf{:}type, owl{:}Restriction) \\ (\_{:}x, owl{:}minCardinality, \text{`}0\text{'}\hat{~}\hat{~}xsd{:}int) \\ (\_{:}x, owl{:}maxCardinality, \text{`}1\text{'}\hat{~}\hat{~}xsd{:}int) \\ (\_{:}x, owl{:}onProperty, p) \end{array} \end{aligned}$$

Finally, if we find a subset of triples of the form:

$$\begin{aligned} \begin{array}{l} (p_1, owl{:}inverseOf, p_2) \\ (p_2, rdf{:}type, owl{:}InverseFunctionalProperty) \end{array} \end{aligned}$$

we can transform it into the following triples before applying our technique:

$$\begin{aligned} \begin{array}{lll} (p_1,&rdf{:}type,&owl{:}FunctionalProperty) \\ (p_2,&rdf{:}type,&owl{:}FunctionalProperty) \end{array} \end{aligned}$$

General property restrictions: This group includes a number of constructors that allow to express general constraints on properties, namely: $owl{:}Restriction,\,owl{:}onProperty,\,owl{:}allValuesFrom$ and $owl{:}someValuesFrom$. We cannot deal with these constructs in a general problem, but only in the cases that we have mentioned in the previous paragraphs, that is, functional properties and cardinality restrictions.

Class intersection: This group includes a single construct: $owl{:}intersectionOf$. We cannot deal with these constructs.

Meta-information: This category comprises three groups of constructs in the OWL 2 Lite profile, namely: header information, versioning and annotation types. They include constructs like $owl{:}Ontology,\,owl{:}imports,\,owl{:}versionInfo$ or $owl{:}backwardCompatibleWith$, to mention a few. They provide meta-information about an ontology, which make them irrelevant for data exchange purposes.