Ontology Query Languages for Ontology-Based Databases - Data Warehousing Design and Advanced Engineering Applications - page 244

Requirement 8 (Queries
on Ontologies and on
Ontologies and Data)

Currently, in OntoQL, the conceptual model
of data can only be defined through a subset of
the ontology.

Requirement 7 (Ontology & Data
Definition and Manipulation)

OntoQL is equipped of operators to combine
ontologies and data querying. In particular, it pro-
vides the TYPEOF operator to return the class an
instance belongs to. Example . Return all instances
of Resource with the classes it belongs to.

The data manipulation language of SQL can be
used to create classes and instances. Example.
Create the class User of our example and add
some instances. SELECT r.uri, TYPEOF(r).#name[en]

FROM Resource AS r

CREATE EXTENT OF User (“first
name”, “last name”, email)
TABLE T_User (first_name, last_
name, email)
CREATE #Class User UNDER Resource (
DESCRIPTOR (#name[fr] = 'Utilisa-
teur)
#property (“first name” String,
“last name” String, …)
)
INSERT INTO User VALUES('User1',
'Patrick', 'Dupond')

Explanation . The FROM clauses introduces
the alias r on instances of the class Resource.
For each instance, its URI is projected as well
as the name in English of the class it belongs to
(retrieved with the TYPEOF operator).
This brief presentation of OntoQL ends our
analysis of capabilities of ontology query lan-
guages to exploit OBDBs. We draw main conclu-
sions in the next section.

Explanation. The first statement creates the
class User. This class is defined as a class (#Class),
subclass of Resource. The name in French of this
class is specified in the DESCRIPTOR clause. The
#property clause is used to create properties having
User as domain. The second statement supposes
that we have created an extent for the class User
(see previous requirement). It uses a SQL-like
INSERT statement to insert an instance.
One limitation of the data manipulation lan-
guage of OntoQL is that it does not support multi-
instanciation, i.e., that an instance may belong to
many classes not linked by subsumption relation-
ships. This limitation allows to define an efficient
storage structure when instances have many
properties values (Dehainsala et al., 2007).

CONCLUSION

In this chapter, we have presented capabilities
of the main ontology query languages to exploit
databases extended with ontologies. To compare
these languages, we have first defined a set of
requirements for an architecture that extends
the traditional ANSI/SPARC architecture with
conceptual and ontological levels. Then, we
have discussed the capabilities of two Semantic
Web query languages (SPARQL and RQL), and
two database-oriented ontology query languages
(Oracle extension to SQL and OntoQL) to fulfill
these requirements. The result of this study is sum-
marized in Table 3. In this table, the symbol • is
used when the requirement is fulfilled, o when it
is partially fulfilled, and when it is not fulfilled.