Content uploaded by Roman Špánek
Author content
All content in this area was uploaded by Roman Špánek on Jan 20, 2015
Content may be subject to copyright.
Design of an Ontology for Humin Substances
Pavel Tyl
Technical University of Liberec
Liberec, Czech Republic
pavel.tyl@tul.cz
Roman Špánek
Technical University of Liberec
Liberec, Czech Republic
roman.spanek@tul.cz
Martin ˇ
Rimnáˇ
c
Institute of Computer Science
Czech Academy of Sciences
Prague, Czech Republic
rimnacm@cs.cas.cz
Július Štuller
Institute of Computer Science
Czech Academy of Sciences
Prague, Czech Republic
stuller@cs.cas.cz
ABSTRACT
Knowledge can be used for description, sorting and search-
ing of useful data. Knowledge, on the other hand, may be
very narrowly connected with a person, who may leave a
company. Such situation can be avoided by using of ontol-
ogy as a tool of knowledge engineering or in general as a tool
for knowledge representation.
The paper presents on ontology design to peculiarities of
humin substances based on analysis of existing similar type
ontologies. It enables to preserve, make accessible and reuse
gained experiences, for instance for design of functionally
rich, flexible and easy integrable systems and applications.
In introduction this work presents an overview of selected
formalisms for interception of data structure and processes
in humin substances area with respect to using ontologies
and their possibilities. The paper is especially a case study
of ontology application for evidence and data organization
of humin substances, their measurement and experimenta-
tions, where use of ontologies is not yet common. It shows
a potential of ontologies and illustrates parameters of gen-
erally applicable model for such area.
Keywords
ontology, humin substances
1. MOTIVATION
Humin acids, in general humin substances, can higly in-
fluence a growth of various crop-plants. Humin substances
(HS) could be used in the area of fytoremediation of con-
taminated soil. Influence of using HS for soil fytoremedi-
ation in dependance on used crop-plant was investigated
within the scope of project Advanced Remedial Technologies
(ARTEC). Influence of interaction between HS and plant
substrates on growth of selected crop-plants and remedia-
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. To copy otherwise, to
republish, to post on servers or to redistribute to lists, requires prior specific
permission and/or a fee.
iiWAS2012, 3-5 December, 2012, Bali, Indonesia.
Copyright 2012 ACM 978-1-4503-1306-3/12/12 ...$15.00.
tion dynamics (intensity of contaminants collecting from soil
by crop-plant) is observed. There is a real assumption that
HS (thank to their stimmulative e↵ects on growth of plants)
could dramatically influence the growth of their root system
and also contaminants transformation intensity to the plant
that can be used as biofuel after the harvest.
Previously mentioned activities are only a part of goals
of ARTEC Research Center that deals with remediation
technologies. Recently it happens to apply obtained results
about particular technologies and their testing on real tasks.
The paper describes pilot project, whose goal was to de-
sign and to construct an ontology for humin substances pro-
duction and for description of experimentations with humin
substances include their results.
1.1 Why to Use Ontology?
In recent years the development of ontologies – explicit
formal specifications of the terms in the domain and rela-
tions among them [3] – has been moving from the realm of
artificial intelligence area to the area of interest of domain
experts. Ontologies have become common on the Internet.
The ontologies on the Web range from large taxonomies to
categorizations of products with their properties. Many dis-
ciplines now develop standardized ontologies that domain
experts can use to share and annotate information in their
fields. For example in the biochemistry topic was devel-
oped big standardized structured vocabulary and onotlogy
of chemical entities related to biology – ChEBI [1]. The
WWW Consortium [14] is developing the Resource Descrip-
tion Framework and later OWL and OWL 2.0 languages [8],
languages for encoding knowledge of objects (entities) on
Web pages to make it understandable to electronic agents
searching for information.
An ontology defines a common vocabulary for groups of
users (people or software agents) who need to share data, in-
formation and knowledge in a domain. It includes machine-
interpretable definitions of basic concepts in the domain and
relations among them.
Why would someone want to develop an ontology? Some
of the reasons are:
•To sh are co mmo n unde rst and ing of t he st ruc ture of i n -
formation among people or software agents – one of
the most often reasons for ontology development al-
lows software agents to summarize extracted informa-
387
tion from more overlapping sources and answer user’s
queries.
•To en able re u se of d oma in kn o w ledge –ifwewantto
create new ontology, we can use the existing ones and
integrate them, decrease or increase according to our
needs.
•To ma ke recen t gen eral vi ew of do mai n kno w l ed ge –
unambiguous specification of domain knowledge is im-
portant for new users who need to know the mean-
ing of ontology terms. If pieces of knowledge are de-
scribed in a ontologz, we can easilt find them or change.
Changing and looking for all software agents with fixed
knowledge (inner logic of every agent) would be much
more difficult.
•To an alyz e dom ain k nowledg e – this can be done, if
we have available exact meaning of particular ontologz
terms. It can be used to the following increasing and
reuse existing ontologies.
•To se pa ra te do main k now ledg e from th e operati onal
knowledge – other commmon use of ontologies. We can
for example describe a configuration of some product
from its components according to required specifica-
tion and create a program that makes such configura-
tion independent on concrete product and components
themselves.
Often an ontology of the domain is not a goal in itself.
Developing an ontology is akin to defining a set of data and
their structure for other programs to use. Problem-solving
methods, domain-independent applications, and software agents
use ontologies and knowledge bases built from ontologies as
data inputs. In this context, an ontology of humin sub-
stances serves for both internal cooperation in research team
and for presentation of knowledge in the area of humin sub-
stances to other developers [6].
1.2 What is in an ontology?
Literature knows more definitions of an ontology. For the
purposes of this paper an ontology is a formal explicit de-
scription of notions in a domain of discourse, in our case the
domain of humin substances. Ontology will contain objects
(called concepts,sometimescalledclasses), their properties
(called roles,sometimescalledslots) and given restrictions
of objects and properties (roles restrictions ,sometimescalled
aspects). An ontology together with a set of concept i n-
stances and roles constitutes a knowledge base. A fine line
where the ontology ends and the knowledge base begins is
often very vague.
Concepts are the focus of most ontologies. Concepts de-
scribe basic notions in the domain. For example, a concept
Material represents general material. Specific existing mate-
rials are instances of this concept. A concept can have sub-
concepts that represent notions that are more specific than
the superconcept alone. For example the concept Experi-
ment has subconcepts Parcel experiment and Container experiment.
can be divided the class of all wines into red, white, and
ros ˜
Al’ wines. Hierarchy of concepts (relationship subconcept–
superconcept) is transitive.
Roles describe properties of concepts and instances. Ev-
ery Material has for instance particular majority element
and observed element. Property majority element can have
several di↵erent values (Al,Ca,Cl,Fe, . . . ). Property ob-
served element can have other possible values (As,Cd,Co,
Cr, . . . ). At the concept level, we can say that instances
of the concept Material will have role majority element and
observed element and so on.
All instances of the concept Material have role major-
ity element giving a value of concentration of particular el-
ements (instances of the concept Element)inMaterial (see
Fig. 1).
In practical terms, developing an ontology includes:
•defining concepts in the ontology,
•arranging concepts in a taxonomic (subconcept–superconcept)
hierarchy,
•defining roles and describing allowed values and re-
strictions for these roles and
•sometimes topping up instances and values for roles
(see Fig. 2).
2. ONTOLOGY DESIGN METHODOLOGY
Some fundamental rules in ontology design to follow and
to keep in mind are these:
1. There is no“one correct”way or methodology for devel-
oping ontology – there are always viable alternatives.
“The best” solution almost always depends on the ap-
plication that you have in mind and the extensions
that you anticipate.
2. Ontology development is necessarily an iterative pro-
cess – we start with a rough first pass at the ontology,
we then revise and refine the evolving ontology and fill
in the details (along the way, we discuss the modeling
decisions that a designer needs to make, as well as the
pros, cons, and implications of di↵erent solutions).
3. Notions of the ontology should be close to real ob-
jects in described domain. (Concepts will be probably
represented by nouns,roles among them by verbs and
all together will create simple sentences describing our
domain of interest.)
Deciding what we are going to use the ontology for, and
how detailed or general the ontology is going to be will in-
fluence its modeling. Among several viable alternatives, we
will need to determine:
•which one would work better for the projected task,
•which one would be more intuitive,
•which one would be more extensible and
•which one would be more maintainable.
After we define an initial version of the ontology, we can
evaluate and debug it by using it in applications or problem-
solving methods or by discussing it with experts in the field.
As a result, we will almost certainly need to revise the initial
ontology. This process of iterative design will likely continue
through the entire lifecycle of the ontology.
388
Figure 1: Concept Material and role majority element.
Concepts are depicted in elliptic form, datatype roles and instances as rectangles. Arrows symbolize object
roles, arrows with word is-a represent role subconcept–superconcept (subproperty–superproperty respec-
tively).
Figure 2: Some concepts, their roles and relationships among them in the humin substances domain.
2.1 Determine the domain and scope of the
ontology
For determining the domain and scope of the ontology we
have to answer several basic questions:
•What is the domain that the ontology will cover?
•For what we are going to use the ontology?
•For what types of questions the information in the on-
tology should provide answers?
•Who will use and maintain the ontology?
The answers to these questions may change during the on-
389
tology design process, but at any given time they help limit
the scope of the model.
Domain of our ontology are humin substances, which are
used (in the scope of this paper) as an additive to plant sub-
strates, but in general they can be used for specific applica-
tions in given chemical or biochemical processes. Ontology
could be used for:
1. qualitative assessing and selection of deposits of pri-
mary carbonaceous materials in humin acids, or in gen-
eral in humin substances (oxyhumolits, lignit, peat),
2. processing procedure of primary carbonaceous materil
to products (mechanicaly modified oxyhumolit, alka-
line humat, pure humin acids) with required qualita-
tive parameters of humin acids contained (HA content,
relative molecule materialities spectra, biological activ-
ity level, functional groups content with basic e↵ect to
their chemical and bilogical activity [–COOH a fenolic
–OH groups], ashes content, etc.),
3. assessing of propriety for precesses application of humin
substance with given quality parameters, with defined
conditions of their ordering and vice versa, what qual-
itative parameters humin substance has to have to
achieve requirements of our defined process.
If the ontology we are designing will be used to assist in
natural-language processing of articles about chemical sub-
stances, it may be important to include synonyms and part-
of-speech information for concepts in the ontology. If the
ontology will be used to help to infer economical costingness,
we need to include costs of particular experiments and mea-
surements, or availability of particular materials and chem-
icals. If the people who will maintain the ontology describe
the domain in a language that is di↵erent from the language
of the ontology users, we may need to provide the mapping
between the languages.
2.1.1 Competency questions
One of the ways to determine the scope of the ontology is
to sketch a list of questions that a knowledge base based on
the ontology should be able to answer, competency questions
[4]. These questions will serve as the test later:
•Does the ontology contain enough information to an-
swer these types of questions?
•Do the answers require a particular level of detail or
representation of a particular area?
These competency questions are just a sketch and do not
need to be exhaustive. In the humin substances ontology
are the competency questions for example following:
•What energetic plant should we plant, if some area is
contaminated by “any of observed elements”?
Selection fo suitable plants depends on concrete case
and conditions (type and sort of contaminant, clima,
soil, humidity, used technological system, i. e., phytore-
mediation as a part of other remediation applications,
technology of particular plants cultivation, possibility
of further using of cropped plants, etc.).
•What financial costs will be needed for decontamina-
tion of an area in five years horizont?
It depends on several factors – chosen plant and its
planting technology severity or costs of using various
mechanization means, type and way of application of
humin substances, further using of grown phytomass,
climatic factors, etc. From this point of view multi-
annual plants are prefered. On the contrary possible
profit from grown phytomass is lower.
•What majority elements are contained in the material
which is produced by some concrete chemical process?
•What observed elements are figuring in parcel mea-
surement results, if any?
Judging from this list of questions we can get an overview,
what possible answers (in the form of appropriate data) we
can obtain from database, information system or knowledge
base which are build up the developed ontology – for ex-
ample the selection of the the most suitable energetic plant
while risk of contamination, financial and time costs for de-
contamination etc.
2.1.2 Consider reusing existing ontologies
It is almost always worth considering what someone else
has done and checking if we can refine and extend existing
sources for our particular domain and task. Reusing ex-
isting ontologies may be a requirement if our system needs
to interact with other applications that have already com-
mitted to particular ontologies or controlled vocabularies.
Many ontologies are already available in electronic form and
can be imported into an ontology-development environment
that we are using. The formalism in which an ontology
is expressed often does not matter, since many knowledge-
representation systems can import and export ontologies.
Even if a knowledge-representation system cannot work di-
rectly with a particular formalism, the task of translating
an ontology from one formalism to another is usually not a
difficult one.
There are libraries of reusable ontologies on the Web and
in the literature. For example, we can use the Ontolingua
ontology library [7] or the DAML ontology library [2]. There
are also a number of publicly available commercial ontolo-
gies, e. g., UNSPSC [12]. Already mentioned ontology li-
brary ChEBI [1] focuses on classification of chemical sub-
stances of biological importance. There also exists a tax-
onomy of chemical substances created by collaboration of
HCLS (Semantic Web Health Care and Life Sciences Inter-
est Group) and W3C [5].
By importing of these ontologies our ontology would be
too diverted from experiments and measurements problems,
economical monitoring and other aspects relating humin sub-
stances. Let us assume that no relevant ontologies already
exist for our purpose.
2.2 Ontology basic concepts and terms
The following section gives a brief overview on concepts
and terms that are important for designed ontology. Each
term is followed by a summarization of its properties and a
short description.
For example we will use the following terms:
•Material,
•Locality,
•Biologic activity,
390
•Plot,
•Plant,
•Substrate,
•Energetic plant,
•Physical process,
•is measured,
•is processed,
•...
The list ought to be complete, extensive; terms may overlap.
2.2.1 Concepts definition and concepts hierarchy
Concepts hierarchy can defined in three possible ways –
top-down,bottom-up and combination o f both [13]. Selecting
the best method cannot be defined explicitly, but it has to
follow ontology designer experience, topic peculiarities, etc.
As the topic of Humic compounds is relatively complex, the
combination of top-down (used for concretion of hierarchy)
and bottom-up (used for wrapping of a concept by more uni-
versal one) was used.
The first step during an ontology design is a specification
of terms – state-full terms are chosen from the set of impor-
tant terms (see section 2.2) at first step, followed selection
of terms describing the state-full ones more in details. The
state-full terms are in an ontology described by concepts.
Concepts hierarchy is then created from a set of concepts
instances that are inevitably instances of another concept
(e. g., included one). For example, price of any term defined
in the ontology is inevitably econo mi cal parameter.
2.2.2 Concept properties/roles definition
Concepts themselves cannot be used for answering com-
petence questions (see section 2.1.1). It is necessary to de-
scribe also properties and relationships between defined con-
cepts. Roles candidates have been already chosen from a
set terms (e. g.,is measured,is processed,can be found,be-
longs to locality,...
For each role in the set a concept has to be selected and
assigned. The roles are sticked to concepts. For example,
concept Material has roles label,description,overall acidity,
and other roles from physically-chemic parameters.
Properties that can be roles in an ontology can be classi-
fied into the following:
•inner property – e. g., overall acidity Materials,
•outer property – e. g., label Localities,
•parts – for structured (real or abstractly) objects, e. g.,
relative increment Biologic activity,
•relationships – on connection of particular instances (of
given concepts), e. g., Material is processed Process.
Thus, concept Material will have the following roles:label,
overall acidity,carboxyd group,dust,dryBasis,water,etc.
Every sub-concepts inherit roles from parent-concept. Each
sub-concept of Process concept in our ontology Physical process
and Chemical process) will have date,label arank.Roleby
ought to be connected to the most general concept in the
hierarchy.
2.2.3 Definition of roles constraints
Di↵erent types of constraints (e.g., allowed data types,
values, cardinality, etc.) can be defined for roles. For ex-
ample, value of majority element role is a String (up to 3
letters). Role can be found can have multiple values from
set of place of sample instances.
The most common constraints are listed bellow:
Role cardinality – defines a multiplicity of a role. Some
systems can distinguish only between one and more cardi-
nalities, some systems are also able to define maximum and
minimum.
Role Data type – express data types possible for role val-
ues. Most common data types are String, number, truth
value, enumeration and instance.
Role Domain – the most general concept describing roles.
Material is a domain of is processed role.
Role Range – the most general concept, which instances
are valid values of the role. Process is range of is processed
role. If there are more concepts being a range of a role
(is processed role has both Process and Chemical process)
than the most general concept is used (Process).
2.3 Creation of instances of concepts
Instances of concepts are in some cases created as the last
step of an ontology design. Instance definition requires the
following:
1. concept selection,
2. creation of instance of the concept,
3. filling with values of roles.
For example, assume that an instance of Container experiment
(particular experiment) is to be created. At first the follow-
ing set of values of roles has to be set (it is not a complete
set of values but only an example set):
•date:2010-04-05,
•fertilization: Before a plant is seeded, substrate which
is going to be used for container experiments is an-
alyzed and based on the analysis results fertilization
(addition nutrients – biogenic elements) is set up. Nu-
trients are added with in watering,
•used soils (substrates):
–Locality Prague–Ruzynˇe (label R),
–Locality Milevo (label M),
•container label:
–R(variants 1–10),
–M(variants 11–20),
•number of repetition: 2 (a, b),
•experiment schema:
391
Id Substrate Container Plant Fertilizat. Coal
[g/cont.]
1 R 1R – – –
2 R 2R – true –
3 R 3R – true 60
4 R 4R – true 120
5 R 5R – true 240
6 R 6R true – –
7 R 7R true true –
8 R 8R true true 60
9 R 9R true true 120
10 R10R true true 240
11 M11M – – –
12 M12M – true –
13 M13M – true 60
14 M14M – true 120
15 M15M – true 240
16 M16M true – –
17 M17M true true –
18 M18M true true 60
19 M19M true true 120
20 M20M true true 240
•coal: temporal label JV21 (mine Druˇzba, Sokolov),
•watering: up to 50 % of the maximal water capacity,
•experiment support: Experiment location provides pro-
tection against lost of inflowed solution (due to high
precipitation) from a bowls beneath containers,
•used plant: each soil type is used in set of container
with and without plant (instance of Plant concept)
2009 2010 2011 2012
1. plant – Spring
Wheat
Spring
Wheat
Oat
next plant Corn
Seeded
Field Pie Corn
Seeded
–
•used analytic methods:
–Soil samples
pH/KCl
Leach Mehlich II. – content of P, K, Ca, Mg [mg/kg]
Content of humic [%]
Overall organic mass in dry basis [%]
HSA+HSBin dry basis [%]
–Plant samples
Estimation of majority elements concentration (N,
P, K, Ca, Mg) in dry basis [%],
•has result:ResER 2010-04-05 001 (instance of
Result of experiment concept).
2.3.1 Created instances notes
2010
Container experiments have show no change of volume of
humic compounds as a result of coal transformation dur-
ing the first year of the experiments. Results also showed
(with respect to an acceptable error) that content of organic
mass was increased in correlation to requirements. Results
of analysis and weight of dry basis in harvested corn do not
corresponds to incremented ratio of coal. Decrease of con-
centration of elements in containers with oxyhumolitic coal
corresponds to dilution e↵ect inducing by increase of dry
basis.
2011
Harvest in 2011 showed that high concentration of coal de-
creases weight of harvested plants. Wheat analysis (wheat
grew in both soil types) revealed the fact, that concentra-
tion of N, P, and Ca increased in all containers with coal
with no correlation to coal amount. Field pie, on the the
hand, increase of elements concentration was identified only
in containers with substrate from Ruzynˇe. Substrate anal-
ysis done at the end of the containers experiment revealed
that increased coal amount caused increase of content of hu-
mic and decrease of substrate pH.
2012
Results of dry basis of samples took from wheat in the first
midyear of 2012 were not e↵ect by coal in the containers.
The experiments followed by planting corn into containers.
Weight of dry basis was increased by running high amount
of oxyhumolitic coal. Analysis of substrate did in Autumn
2011 showed correlation between contain of organic mass in
dry basis and amount of oxyhumolitic coal.
Established container experiment with oxyhumolitic coal
fulfills prerequisites for successful continuation; results are
yet to be final and will be replenished.
2.4 Concepts definition, concepts hierarchy –
common errors, recommendations
This section contains common errors that may occur dur-
ing concept definition, definition of concept hierarchy. The
section also contains recommendations helping proper on-
tology and ontology hierarchy definitions.
The designed ontology hierarchy may depend on possi-
ble application of the ontology, level of details necessary for
application processing, but it may also depend on compat-
ibility with the existing models. On the other hand, there
exists a methodology, that should be followed and therefore
we would like to revise the designed ontology and do some
back-checking.
2.4.1 Is designed hierarchy correct?
IS-A relationships – Hierarchy of concepts represents
an IS-A (KIND-OF) relationship: concept Chemical process
is a subconcept of Process, each concrete chemical process is
also a process. Subconcept represents a term, which some-
how represents parent concept. Designing the concept Par-
cel measurement as a subconcept of Parcel experiment would
be an error. Despite the fact that parcel experiments are
composed of s set of (SET-OF) parcel measurements, con-
crete Parcel measurement cannot be considered as Parcel experiment
– it does not follow the reality.
Transitivity of hierarchy relationships – relation-
ships of subconcept is transitive. Let Cu is an Observed element
and Observed elements are Quantitative parameters, then
Cu is also a Quantitative parameter.Cu is also direct sub-
concept of Observed element.
Evolution of concepts hierarchy – maintain concepts
hierarchy in consistent state may be a complicated if topic
of interest is under continual evolution. Consistency is on
the other hand crucial, if an ontology has to reflect chosen
portion of the reality from the selected domain.
Avoidance of cycles in the hierarchy – A hierarchy
contains a cycle if concept Bis a subconcept of concept A
and concept Ais also a subconcept of concept B. It logically
leads to equivalence of concepts AaB.
Analysis of siblings in concepts hierarchy – Siblings
are direct subconcepts of a parent concept. Each of them
should be designed with the same level of abstraction. For
392
example, Majority elements and Hg cannot be of the same
level of abstraction. Majority elements are more abstract
compared to Hg term. Concept close to the root of the hi-
erarchy represent basic terms and such concepts are usually
direct subconcepts of a very abstract concept (e. g., Thing).
Thus, such concepts are not required to be an the same level
of abstraction.
Too few or too much siblings? – There is no rule how
to set number of siblings. Even though, if there is only one
subconcept. it usually means that ontology is not complete
or here is an error in modeling. As an example let us men-
tion a list – a list should not contain only one element. If
there are about 12 subconcepts, it is recommended to add
a interleaved category. List concepts of hierarchy are excep-
tions. which can be substituted by instances (in our case
labels of elements – As,Cd,Co,Cr, . . . ). If there are not
interleaving categories, we should no create on, as the reality
should be given preference
2.4.2 Multiple inheritance
Majority of systems for creation, maintenance and pro-
cessing of ontologies (e. g., ontologic editors Prot´eg´e [9], SWOOP
[11], . . . ) enable multiple inheritance – one concept can a
subconcept of several concepts. For example, set of physically-
chemical processes which instances are elements from con-
cept Physical process and also Chemical process. Such con-
cept inherits from both parents.
2.5 Creating new concepts
One of important decision in the ontology modelling is a
question if to create new concepts or to express semantic dif-
ference by di↵erent roles. It is a quite difficult to understand
the ontology with many nested concepts or to understand
the ontology with a small amount of concepts, but having
much data expressed by the roles. A sound ontology design
well arranges these two extremal approaches. Several rules
of creating new concepts in a hierarchy exists. Commonly,
subconcepts of any concept
•have more propeties, which the original concept do not
have
•have constraints di↵ering to supconcept
•assign another relationships than supconcept.
For example in our case, the concept Chemical process has
the role reaction duration, which is not used for a description
of the supconcept Process. New concept in the hierarchy will
be defined in the case, if exists anything, which is valid for
a concept, but not for a subconcept. Especially, each new
concept should be extended by new roles or should have
defined a new values of roles or should precise a inherited
roles. On the other hand, subconcepts may not be created,
when these subconcepts cannot be used for inference except
the cases, when this new concept simplify a navigation in a
taxonomies. A concept may be also created in situations,
when a domain expert distinguish given terms and does not
model the di↵erence between the terms.
2.5.1 Creating new concepts or properties?
The specific di↵erences can be modelled by roles or a set of
concepts according to the ontology domain. For example in
our ontology, the Parcel experiment and Container experiment
can created as subconcepts of Experiment, or alternatively
the concept Experiment can be extended by the role Ex-
periment type having specified domain of Parcel and Con-
tainer. Since the results of Parcel experiment and Con-
tainer experiment are totally di↵erent (the experiments are
connected with Parcel experiment Result, respectively Con-
tainer experiment Result, a new concept should be used (to
avoid at least to connect Parcel experiment Result with Ex-
periment of Experiment type to be set to Parcel . In other
words, if concepts with di↵erent values of roles becomes to
be limited for di↵erent roles, new subconcept is created; oth-
erwise a type is distinguished by especial role, expressing a
kind of the concept, to be created in the concept. In these
cases, it is recommended to potentioaly create a correspond-
ing instances.
2.5.2 Creating instances or concepts?
A decision to use a concept or instance depends on as-
sumed application of the ontology. The di↵erence between
concepts and instances is the lowest level in a hierarchy of
terms. The candidates to instances are the terms, which
are the most specific from the domain of the interest (to
be selected in searching competence as presented above in
Section 2.1.1). The important di↵erence between concepts
and instances is, that instances are not ordered in hierarchy
(instead of concepts), a subinstance is not commonly used in
ontology modelling. If exists a hierarchy between the terms,
the concepts should be used. For example, Energetic plant
grows on Parcels. These Parcels are distinguised by the place
they are located, for example southern or northen parcels -
in such a particular case, this will be modeled by new sub-
concepers. In our case it fully sufficient to use the concept
Parcel (Fig. 3), which has instances as Parcel OH 2009 Nor
Parcel COOH 2010 NO.
Figure 3: Concept Parcel need not further subcon-
cepts (instances are enough).
2.5.3 Limiting the scope
The ontology should contain all available data about the
descripted domain, but it may not specify other (relevant)
terms, which are not used by any ontology application. In
our case, it is not necessary to know a material of tools
for collecting samples or an age of the person, which col-
393
lects the samples. Similarly, the ontology may not include
all roles and hierarchy contraints of concepts, which are not
used by the application (in our case, there are modeled only
compounds, which are relevant; compounds, which are not
relevant are not provided). Only the most important (aimed
to answer the question of competence) roles of concepts are
given. All these decisions, if the roles or concepts are nec-
essary, should be noted in an ontology documentation to
simply understanding the ontology by other users.
2.5.4 Disjoint concepts
Most ontology designers allows to explicitly specify dis-
joint concepts. The concepts are disjoint, if they have no
joined instances. For example, Measurement result and Ex-
periment resu lt are not disjunct because there may exists
such experiment results, which are ident with Measurement results.
2.5.5 Inverse roles
A value assigned to a role may depend on another role.
For example, Substrate is on the Parcel and Parcel contains
Substrate. These two roles are inverse. Keeping both inverse
roles is rendant. If a given instance of Substrate has a role
is on assigned to a given instance of Parcel, the application
using the ontology i↵er also an inverse value of the relation-
ship. This feature may be used for verification of modeled
relationships (where a user can naturally read both relation-
ships).
2.5.6 Default values
Many systems based on frames (for example [10]) allows
to specify default values of roles. If the value of any role is
identical for most instances of a given concept, such value
can be defined as default. In such a case, if any instance do
not explicitly redefine an assigned value (to another allowed
value), a default value is automatically used.
2.5.7 Namimg convention
Naming convection and consequenlty its usage plays an
important role for sound ontology understanding and often
avoids common mistakes during extending ontology. Of-
course, there exists manu convections. The convection in-
cludes a rules, how to call concepts and roles, several rules
are given by a selection of tool for designing the ontology
(for example Prot´eg´e [9]). These are
•di↵erent namespaces for concepts, roles and instances,
•letter case sentivenes,
•which special characters (for example ,!,etc.) may
be used to name the concept?
These rules can be applied into a policy
•selecting separator, for example ChemicalProcess,Chem-
ical process,chemical-proces,Chemical process,...),
•plular or singular, for example ChemicalProcess or Chem-
icalProcesses,
•role prefixes and postfixes, for example is. . . ,has-a.
The recommended rule is not to call concepts, roles as
Class. . . and not to abbreviate the names.
3. CONCLUSION
The paper presents a description of a design of the on-
tology for humine compounds. The paper was aimed by
presenting rules for modelling the ontology and to discuss a
chosen solution (as in Figures 1, 2 and 3 ). Each descibed
step was extended by a teoretical background leading to cre-
ation of concepts, roles and their values.
The ontology design significantly depends on the designer;
if two designers try to create an ontology from the same do-
main and application, both will follow all relevant rules, the
designed ontologies can be totally di↵erent. The ontology
quality can be, unfortunatelly, expressed by its sound usage
in the proposed application.
4. ACKNOWLEDGMENTS
This project is supported by the grant GAP202/10/0761
“Web Semantization” and partly supported by the student
grant SGS 2012/7821“Interactive Mechatronics Systems Us-
ing the Cybernetics Principles”.
5. REFERENCES
[1] ChEBI. Ontology for chemical entities of biological
interest. http://www.ebi.ac.uk/chebi,2012.
[Online].
[2] DAML. Darpa agent markup language.
http://www.daml.org, 2012. [Online].
[3] T. Gruber. Ontology. In Encyclopedia of Database
Systems, pages 1963–1965. Springer US, 2009.
[4] M. Gr¨
uninger and M. Fox. Methodology for the
Design and Evaluation of Ontologies. In IJCAI’95,
Workshop on Basic Ontological Issues in Knowledge
Sharing, April 13, 1995,1995.
[5] HCLS. Semantic web health care and life sciences
interest group. http://www.w3.org/2001/sw/hcls,
2012. [Online].
[6] N. F. Noy and D. L. McGuinness. Ontology
development 101: A guide to creating your first
ontology. Development,32(1):1–25,2001.
[7] Ontolingua. Database and ontology. http:
//www.ksl.stanford.edu/software/ontolingua,
2012. [Online].
[8] OWL. Web ontology language.
http://www.w3.org/2007/OWL, 2012. [Online].
[9] Prot´eg´e. Ontology editor and knowledge acquisition
system. http://protege.stanford.edu,2012.
[Online].
[10] Prot´eg´e-Frames. Frame-based domain ontology editor.
http://protege.stanford.edu/overview/
protege-frames.html, 2012. [Online].
[11] SWOOP. Hypermedia-based owl ontology browser and
editor. http://code.google.com/p/swoop,2012.
[Online].
[12] UNSPSC. The united nations standard products and
services code. http://www.unspsc.org, 2012. [Online].
[13] M. Uschold and M. Gr¨
uninger. Ontologies: principles,
methods, and applications. Knowledge Engineering
Review,11(2):93–155,1996.
[14] W3C. The World Wide Web Consorcium.
http://www.w3.org, 2012. [Online].
394
