Database Reference
In-Depth Information
Table 2. Syntax of the OntoQL language
Data Definition Language (DDL)
- The create class statement:
<class definition>::= “CREATE” <entity id> <class id> [ <view clause> ] [ <under clause> ]
[ <descriptor clause> ] [ <properties clause list> ]
-The alter class statement:
<alter class statement>::= “ALTER” <class id> [ <descriptor clause> ] [ <alter class action> ]
Manipulation Language (DML)
- The insert statement:
<insert statement>::= “INSERT” “INTO” <category id> <insert description and source>
- The update statement:
<update statement>::= “UPDATE” <category id polymorph> “SET” <set clause list> [ “WHERE” <search condition> ]
- The delete statement:
<delete statement>::= “DELETE” “FROM” <category id polymorph> [ “WHERE” <search condition> ]
including Hotels, Prices, Rate. Some examples
of instances in this domain include Ibis Poitiers
(Hotels), Paris (Cities). OntoQL can deal both
with the mentioned entities and their instances
(Table 3).
ties are defined. Rather than extending a specific
ontology model and being linked to the specific
extended ontology model, our proposal consists
in introducing a side model describing the non
functional entities together with the model of the
ontology model inside the same OBDB. The ad-
vantage of this approach is the possibility to adapt
non functional descriptions to any ontology model
keeping its definition unchanged and preserving
upward compatibility. Technically, this extension
is possible only if the meta-model that describe
the model of the ontology can be manipulated.
Indeed, such an extension requires being able to
attach any element of the model of the ontology
to the model of the non functional elements. The
OntoDB approach offers this manipulation facil-
ity thanks to the availability of the meta-schema
previously outlined.
Before we give the details of our approach, we
end our state of the art by giving an overview of
the EXPRESS language used to model the side
models associated to an ontology model expressed
in the meta-schema part.
Handling Non Functional
Properties in OBDB
In the OntoDB architecture previously presented,
the different models store both the ontology and
its instances. They also store the meta model
of the ontology. This approach is based on an
extensive use of meta modelling techniques.
However, all the described OBDB approaches lack
to offer primitives that are able to represent non
functional aspects related to the ontology models
such as quality of service, preferences or security.
Indeed, most of the well known ontology models
including OWL and PLIB do not provide built-in
constructors to represent these notions.
To overcome the problem of handling non
functional characteristics, specific attributes (e.g.,
note, remark) are introduced or particular proper-
Table 3. Hotel class creation with an OntoQL statement
CREATE #CLASS Hotel (id int, name String, starRate
int, price int, airCond boolean, tv boolean, wifi boolean,
pool boolean, jakuzi boolean, tennisCourt boolean,
casino boolean);
INSERT INTO Hotel (id, name, starRating, price, airCond, tv, wifi, pool, jakuzi,
tennisCourt, casino)
VALUES (52, 'HotelIBIS', 4, 75, true, true, true, false, false, false, false);
Search WWH ::




Custom Search