Recent research in the area of ontology representation for the Semantic Web has led to several different language proposals. Among the others, it led to the standardization of OWL, on one hand, and to the emergence of the DL-Lite family of Description Logics, on the other hand. These two outcomes mainly differ on their objective: while OWL aims to be a standard, and as such, it is tailored towards expressivity, the main goal of the languages in the DL-Lite family is to allow accessing huge amount of data, by maintaining tractability, and delegating query processing to a DBMS. In this paper we show how DL-Lite can meet OWL. Specifically, we focus on DL-LiteA, the language in the DL-Lite family that is closest to OWL, and introduce the SparSQL language, a concrete epistemic query language, inspired by both SQL and SPARQL, that allows posing expressive tractable queries over DL-LiteA ontologies. Finally, we introduce the main novel DL-LiteA features beyond OWL. The capability of handling such features, together with the SparSQL queries, are some of the new functionalities recently implemented in the MASTRO system.
Web Ontology Language (OWL) has become the standard W3C language for the definition of ontologies for the Semantic Web community. As a standard language, no limits have been posed to its expressivity, and the complete language of OWL, OWL Full, is not decidable. Some fragments of OWL have been identified in order to meet decidability, with restricted forms of constructs. This is the case of OWL Lite and OWL DL. Although these fragments are decidable, they enforce very high computational costs even for simple reasoning tasks, not allowing a practical use of OWL.
The DL-Lite family [
In this paper we show how the two aspects mentioned above, that is, the need for a
standard language and the capability of handling ontologies with a huge number of
instances, can be both achieved. More precisely, the main contributions of this paper can
be summarized as follows: (i) we provide an expressive query language for DL-LiteA
ontologies, named SparSQL , whose syntax is inspired by both SQL and SPARQL,
the W3C recommendation towards a standard query language for RDF ; SparSQL is
actually an epistemic query language that implements the language EQL-Lite(UCQ)
presented in [
Notably, all the contributions discussed in this work are currently implemented
within the MASTRO system, a tool for ontology representation and reasoning that has
DL-LiteA as proprietary core language. The main feature of MASTRO is to reduce all
reasoning tasks, such as consistency checking and query answering to the evaluation
of standard SQL queries over a DBMS. Note that one of the major benefits of using
DBMS technologies, is to allow using huge amounts of possibly pre-existing data, to
populate the ontology instances [
The rest of the paper is structured as follows: in Section 2 we introduce DL-LiteA as a fragment of the standard functional-style syntax of OWL; in Section 3 we present the SparSQL query language for DL-LiteA ontologies; in Section 4 we introduce all the new DL-LiteA enrichments that are beyond OWL and present some conclusions in Section 5. 2
In this section we present DL-LiteA as a fragment of OWL, coherently with its functional-style syntax 2. Note that DL-LiteA differs from the tractable fragment of OWL recently proposed and called DL-Lite 3, essentially because it allows using both functional object properties and sub-object properties, by appropriately restricting their use. In providing the specification of our language, we use A to denote a named class, P (possibly with subscripts) an object property, UC a data property, D a datatype, owl:Thing the most general class, and rdfs:Literal the universal datatype. Then, DL-LiteA expressions are defined as follows: objectP ropertyExpression ::= P j InverseObjectPropertyOf(P ) dataP ropertyExpressions ::= UC classExpression ::= A j DataMinCardinality(1 UC ) j
ObjectMinCardinality(1 P ) j
2 From now on we will refer to OWL 2.0, see http://www.webont.org/owl/1.1/. 3 See http://www.w3.org/Submission/owl11-tractable/#3
As usual in DLs, a DL-LiteA ontology O = hT ; Ai represents the domain of discourse in terms of two components: the TBox T , i.e. a set of axioms representing the intensional knowledge, and the ABox A, i.e. a set of axioms representing the extensional knowledge, known as facts.
More precisely, DL-LiteA intensional axioms have the form: ClassAxiom ::= SubClassOf(classExpression (classExpression j
ObjectComplementsOf(classExpression))) j
EquivalentClasses(2* classExpression) j DisjointClasses(2* classExpression) ObjectP ropertyAxiom ::= SubObjectPropertyOf(2*2 objectP ropertyExpression) j EquivalentObjectProperties(2* objectP ropertyExpression) j DisjointObjectProperties(2* objectP ropertyExpression) j InverseObjectProperties(P1 P2) j ObjectPropertyDomain(P (classExpression j
ObjectComplementsOf(classExpression))) j ObjectPropertyRange(P (classExpression j
ObjectComplementsOf(classExpression))) FunctionalObjectProperty(objectP ropertyExpression)
AsymmetricObjectProperty(objectP ropertyExpression) DataP ropertyAxiom ::= SubDataPropertyOf(2*2 dataP ropertyExpression) j EquivalentDataProperties(2* dataP ropertyExpression) j DisjointDataProperties(2* dataP ropertyExpression) j
ObjectComplementsOf(classExpression))) j
FunctionalDataProperty(dataP ropertyExpression)
Then, a DL-LiteA TBox is a set of intensional axioms that must satisfy the following restriction: no functional object property (or functional data property 0) can be specialized, i.e., (resp. 0) cannot appear in axioms of the form:
SubObjectPropertyOf(
) (resp. SubDataPropertyOf( 0 0)).
We now specify the form of a DL-LiteA ABox. Coherently with OWL, DL-LiteA uses two disjoint alphabets, i.e. individual URIs to denote objects, and constants to denote values (e.g. integer, strings). Then, DL-LiteA ABox axioms have the form: f act ::= ClassAssertion(individualU RI A) j
ObjectPropertyAssertion(P 2*2 individualU RI) j
Before providing an example of DL-LiteA ontology, we recall that the semantics of
DL-LiteA is given in terms of FOL interpretations with the unique name assumption.
Refer to [
Example 1. Consider the following DL-LiteA ontology:
SubClassOf(F emale P erson) DisjointClasses(F emale Male) ObjectPropertyDomain(MARRIES P erson) SubClassOf(P erson DataMinCardinality(1 SSN)) ClassAssertion(mary F emale) ClassAssertion(ann F emale) ClassAssertion(bob Male) ObjectPropertyAssertion(MARRIES bob jane) SubClassOf(Male P erson) ObjectPropertyRange(MARRIES P erson) SymmetricObjectProperty(MARRIES) ClassAssertion(john Male) ClassAssertion(jane F emale) ObjectPropertyAssertion(MARRIES john ann) ObjectPropertyAssertion(MARRIES bob mary)
The intensional level of the ontology asserts that males and females are disjoint sets of persons, where all persons have at least one social security number and can marry other persons. Moreover, it says that if a person x marries a person y , then also y marries x. On the other hand, the extensional level of the ontology asserts that mary; ann; and jane denote female individuals, while john and bob males. Finally, bob marries both jane and mary, while john marries ann. 3
In this section, after briefly recalling the EQL-Lite(UCQ) epistemic query language [
EQL-Lite(UCQ)
It is well-known that open-world semantics, typically adopted to interpret DL
ontologies, are essential for representing incomplete information, but make FOL queries
submitted over DL ontologies undecidable. To the best of our knowledge, the most
expressive FOL fragment for which decidability of query answering has been proved in
DLs, is the class of union of conjunctive queries (UCQs) [
Hence, a non monotonic epistemic query language, named EQL-Lite(Q) , was
introduced in [
SparSQL SparSQL is the query language currently implementing EQL-Lite(UCQ) in MASTRO. Its syntax, as the name of the language suggests, is based both on the SQL STANDARD syntax and the SPARQL syntax 4. Indeed, in SparSQL queries, SQL plays the role of 4 We refer to http://www.w3.org/TR/2008/REC-rdf-sparql-query-20080115/ for details about SPARQL.
FOL in EQL-Lite(UCQ) , while a fragment of SPARQL is used as embedded query language, i.e. to define the so-called sparqltables. The latter play the role of EQLLite(UCQ) atoms in SparSQL queries.
Thus, before precisely presenting the SparSQL queries syntax, let us focus on sparqltables. These are defined as SPARQL queries in the fragment of the SPARQL syntax expressing UCQs. More precisely, such a fragment does not include neither the GraphGraphPattern, nor the FILTER constraints, nor the OptionalGraphPattern. Moreover, for the sake of simplicity, the SparSQL syntax does not require the use of the FROM clause in the SPARQL query. Specifically, a non boolean SPARQL query in SparSQL has the following syntax:
On the contrary, a boolean SPARQL query in SparSQL has the following syntax:
Now that we have introduced how sparqltables are defined, we can present the SparSQL syntax. A non boolean SparSQL query has the following form:
FROM listOf Sparqltables [WHERE conditions] [GROUPBY listOf GroupingAttributes] [HAVING listOf GroupingConditions] [ORDERBY listOf AttributesT oOrder] where each sparqltable (defined in terms of a SPARQL query as described above) is associated to an alias, and no joins can occur between sparqltables defined as non boolean SPARQL queries and sparqltables defined as boolean SPARQL queries. As expected, a SparSQL query differs from an SQL query mainly because of the presence of one or more sparqltables in the FROM clause. Note that SparSQL queries, like SQL queries, can have nested queries that are again SparSQL queries. Next we illustrate SparSQL by providing two examples of non boolean queries, the first one referring to a sparqltable defined in terms of a non boolean SPARQL query, and the second one to a sparqltable defined in terms of a boolean SPARQL query.
Example 2. Consider the ontology presented in Example 1, and suppose that we want to know the persons that we know have married at least two persons. This query can be expressed by the following SparSQL query:
FROM SparqlTable(SELECT ?x ?y
The answer to this query would be the tuple (bob; 2).
Now, suppose that we want to know all the known wifes, provided we know that Bob is married either with Mary or with Ann:
FROM SparqlTable(SELECT ?x
WHEREf?x rdf:type 0F emale0:
?x :MARRIES ?yg) wif es; SparqlTable(ASKff0bob0 :MARRIES 0mary0g
UNION f0bob0 :MARRIES 0ann0gg) spouses Since the boolean sparqltable conditions are verified, the answers to the query are the tuples (mary), (ann) and (jane). Observe, however, that if the spouses sparqltable would have been false, then the overall SparSQL query would have been empty.
Let us next focus on boolean SparSQL queries. A boolean SparSQL query has the following syntax5:
where conditions is defined as for non boolean SparSQL query. A boolean SparSQL query returns true if the conditions are verified, otherwise it returns false.
Next, we provide an example of boolean SparSQL query.
Example 3. Consider again the ontology of Example 1, and suppose that we want to know if there is not any person that is not known be a male or a female. This query can be expressed by the following boolean SparSQL query:
FROM SparqlTable(SELECT ?x
EXCEPT( SELECT males:x FROM SparqlTable(SELECT ?x
UNION
FROM SparqlTable(SELECT ?x
WHEREf?x rdf:type 0F emale0g) f emales)) This query returns true, since there are no persons that are not known to be males or females.
The example above shows that using SparSQL , we can express negation (which cannot be expressed in UCQ) through the use of the EXCEPT SQL operator (or NOT IN SQL operator using nested queries) . 3.3
SparSQL processing In this section we sketch out the processing of SparSQL queries. The technique exposed below is currently implemented in the QuOntoEQL module, that is a client of MASTRO in charge to process SparSQL queries.
In particular, QuOntoEQL takes as input a SparSQL query qEQL and a DL-LiteA
ontology O = (T ; A) and performs the following steps:
5 Note that this syntax simplifies the SQL syntax used to express boolean queries.
– every sparqltable occurring in the qEQL query is expanded according to the TBox
T : the expansion process amounts to compute the perfect reformulation (see [
REF of the sparqltable;
– the REF query is unfolded and rewritten as UNF , so to be expressed in terms of
the database where the ABox A is stored (cf. details in [
Hence we obtain a whole query expressed in SQL that can be executed by any DBMS.
We refer to [
This section aims to present new features of DL-LiteA, that are absent in OWL. These
amount to (i) extend the intensional level of DL-LiteA ontologies, and (ii) introduce
a new component of DL-LiteA ontologies, called ECBox (Epistemic Constraints Box),
embracing a useful expressive kind of epistemic constraints.
We next present a series of extensions of DL-LiteA that are beyond OWL and concern
the intensional level of ontologies. More precisely, we first introduce object property
data, that allow handling data properties of object properties. Then, we present denial
and local identification constraints, that were formally introduced in [
In the following we use UR to denote an object property data. Then, the new axioms involving object property data are defined as follows: ObjectP ropertyDataAxiom ::= SubObjectPropertyDataOf(2*2 UR) j EquivalentObjectPropertyData(2* UR) j DisjointObjectPropertyData(2* UR) j
ObjectPropertyDataRange(UR D) j FunctionalObjectPropertyData(UR)
For the semantics of these axioms refer to [
Denial constraints Now, we pass considering the second extension to the intensional level of DL-LiteA ontologies: the denial constraints. Denial constraints (for short, DCs) are TBox assertions defined as follows: DCAxiom ::= deny(q) where q is a boolean union of conjunctive queries. The semantics of denial constraints is given in terms of FOL interpretations. Specifically, an interpretation I satisfies the DC deny(q) if q is false in I. Thus, the semantics of ontologies with denial constraints is the set of interpretations that satisfy all assertions in A and T , including every denial constraint in T .
Local identification constraints Finally, we present the third and last extension: the local identification constraints. Local identification constraints (LIdCs) are TBox assertions defined as follows: LIdCAxiom ::= KeyFor(simpleP ropertyExpression *(; path) classExpression) where path ::= simpleP ropertyExpression j testRoleExpression j CompositionOf(2*(path)) simpleP ropertyExpression ::= keyDataP ropertyExpression j objectP ropertyExpression testRoleExpression ::= TestRole(classExpression j valueDomainExpression) valueDomainExpression ::= D j RangeOf(UC ) j RangeOf(UR) keyDataP ropertyExpression ::= UC j InverseDataPropertyOf(UC )
As for DCs, the semantics of LIdCs is given in terms of FOL interpretations 6.
Intuitively, let KeyFor( 1; :::; n A) be an LIdC, n 1, where A denotes a
classExpression, 1 denotes a path of length 1, i.e. a simpleP ropertyExpression, and i denotes
a path of arbitrary length, for i = 2; :::; n. Then an interpretation satisfies such an LIdC
if for any two individuals a; a0 of A, there exists at least one path j , j 2 f1; ng, such
that a; a0 differ on the set of individuals and values that are reachable resp. from a; a0 by
means of j (for more details about the formal semantics of LIdCs, please refer to [
Now, a DL-LiteA ontology with LIdCs is a DL-LiteA ontology whose TBox T can also include LIdCs, such that for each LIdC in T , every simpleP ropertyExpression in a path of is not specialized in T . Then, as for DCs, the semantics of a DL-LiteA ontology with LIdCs is the set of interpretations that satisfy all assertions in A and T , including every LIdC in T .
Let us now illustrate by an example the extensions presented above.
Example 1 (cont.) The ontology of Example 1 can be now enriched with these axioms: ObjectPropertyDataDomain(W eddingDate MARRIES) ObjectPropertyDataRange(W eddingDate rdf:date) KeyFor(SSN P erson) deny(q() W eddingDate(X; X))
ObjectPropertyDataAssertion(W eddingDate bob mary 006=02=060) The new intensional assertions state that MARRIES is the domain of the object property data W eddingDate, while its range is date. Moreover, they state that SSN is an identifier for P erson, and that nobody is married with himself. Finally, the extensional assertions specify the date of the wedding of bob and mary. 4.2
Expressing epistemic constraints in DL-LiteA: the ECBox
In this section we present a new component of a DL-LiteA ontology, called ECBox,
consisting of a set of epistemic constraints, named EQL constraints, formally
introduced in [
The syntax for the EQL constraints (or EQLCs) is the following: 6 Note that OWL 2.0 Easy Keys fundamentally differ from LIdCs, since they are interpreted with an epistemic semantics.
EQLCAxiom ::= EQLC(q) where q is a boolean SparSQL query.
The semantics of such constraints is given in terms of epistemic interpretations [
With this notion in place, we can revise the notion of DL-LiteA ontology: a DL-LiteA ontology with ECBox is a triple (T ; A; C), where T and A resp. denote as usual a DL-LiteA TBox and ABox, and C is a ECBox.
Now, we say that an ontology (T ; A) satisfies an ECBox C, if for each EQLC(q) 2
C, the boolean SparSQL query q is true over the ontology (T ; A). Then, the semantics
of an ontology with ECBox (T ; A; C) is defined as the set of models of (T ; A), if
(T ; A) satisfies C, and the empty set of models, otherwise. Also, we say that an ontology
with ECBox is satisfiable if its set of models is non-empty. We remind that the idea of
epistemic constraints, follows the research line introduced in [
Let us now illustrate the role of the ECBox.
Example 1 (cont.) Through the ECBox, we can now enrich the ontology of Example 1 and model the following: – if someone, let us say X, is married with someone else, let us say Y , and Y is married with X, then their wedding dates have to be the same: EQLC(q0), where q0 is the boolean SparSQL query asking for the nonexistence of two persons X; Y such that it is known that X is married with Y , that Y is married with X, and that their wedding dates are different. For shortness, we don’t show the actual form of q0. – a person is a male or a female: EQLC(q00), where q00 is the boolean SparSQL query showed in Example 3.
Let us focus on the last constraint. It is well-known that DL-LiteA, being conceived to keep data complexity of the main reasoning tasks within LOGSPACE, has renounced to express few constructs typically used in the ER (or UML) formalisms, such as complete generalization and minimal cardinality (greater than 1) on relations. Hence, for example, it is not possible to assert in a DL-LiteA ontology that a person is either a male or a female (and nothing else). However, by weakening the semantics and using the last EQLC, it is possible to guarantee that if the ontology with constraints is satisfiable, then a person is either a male or a female, in all the models of the ontology. 5
The main contribution of this paper is to show how to implement efficient reasoning
tasks over ontologies while keeping compliant with OWL. To this aim, we presented a
new query language, called SparSQL , that is an implementation of the EQL-Lite(UCQ)
epistemic query language presented in [
It is worth noting that all along this paper we considered DL-LiteA ontologies,
having traditional ABoxes as for data layer. Actually, MASTRO is able to access through
an ontology and an appropriate set of mappings [
As future work we plan to follow two main directions. On one hand, we plan to investigate the use of SparSQL to query ontologies written in DLs, other than DL-LiteA, e.g. OWL-DL, and in RDFS. On the other hand, we plan to run experiments with actual users, in order to compare the usability of MASTRO with the other tools for ontology management reasoning that are currently available.
Acknowledgments. This research has been partially supported by the MIUR FIRB 2005 project “Tecnologie Orientate alla Conoscenza per Aggregazioni di Imprese in Internet” (TOCAI.IT), and by the FET project TONES (Thinking ONtologiES), funded by the EU under contract number FP6-7603.