Database Reference
In-Depth Information
Example .Assuming that instances of the class User
are stored in the table T_User (uri, first_name,
last_name, email), retrieve all users using a SQL
query.
Designing a layered architecture has the draw-
back to increase the complexity of data processing
in upper levels. The introduced complexity has in
general consequences on efficiency of query pro-
cessing. In such architecture, one way to optimize
processing at a given level is to use the lower level
(e.g., create an index to optimize logical queries).
In the proposed architecture, the ontological level
has been added on top of the conceptual level.
Thus, to optimize query processing at this level,
the DBMS shall provide an access to the lower
level, i.e. the conceptual level.
Example. Create the class User of our example
and add some instances.
Ontologies are a conceptualization of a
domain aiming at covering a wide and diverse
range of technical and business requirements.
As a consequence, ontologies usually define a
lot of concepts. For example, the IEC ontology
(IEC61360-4, 1999) on the domain of electronic
components contains approximately 100 classes
and more than 1000 properties. Moreover, users
of an ontology are rarely its designer. Thus, users
should have a mean to discover ontologies with
the language.
In addition, since an ontology defines gener-
ally a lot of concepts, a hierarchy of classes may
have many levels. When a query is expressed on
a class at a given level, the result may contain
instances of this class and of its subclasses. Thus,
these instances can be associated to different
ontological description that the user may want to
retrieve. This example shows the need to be able
to query both ontologies and data. Notice that this
capability would also be useful to extract a part
of an ontology with its instances. In traditional
languages, this operation requires the composi-
tion of two queries. Thus, this capability would
be useful in distributed architecture where the
network trips have to be minimized.
Requirement 6: (Access to the conceptual model
of data) The language should allow to define,
manipulate and query the conceptual model of
data from the ontological level.
Example. Create the conceptual model of data
corresponding to the class User knowing that only
the properties first_name, last_name and email
will be used in the target application.
Requirements on the Expressive
Power of the Language
Requirement 8: (Queries on ontologies and on
ontologies and data) The language should offer
querying capabilities on ontologies and both on
ontologies and data.
In traditional databases, the data definition lan-
guage (DDL) is used to create tables and the data
manipulation language (DML) to insert rows with
their properties values. The DML has the advan-
tage to be a powerful declarative language being
combined with the query language. In the proposed
architecture both ontologies and data are stored.
A data definition and manipulation languages is
required to define and manipulate them.
Example . Return all instances of Resource. For
each instance, retrieve also the classes it belongs
to.
In this section, we have defined a require-
ment specification for an exploitation language
of the OBDB architecture defined in section 3.
A language fulfilling these requirements would
allow to fully exploit this architecture. Using
these requirements, we are now able to compare
existing ontology query languages.
Requirement 7: (Ontology & data definition
and manipulation) The language should offer a
definition and manipulation language for ontolo-
gies and data.
Search WWH ::




Custom Search