Ontologies and terminological concept modelling

1
Handelshøjskolen i København
Ontologies and terminological concept
modelling Bodil Nistrup Madsen Hanne Erdman
Thomsen DANTERMcentret Copenhagen Business
School EAFT and NORDTERM Workshop 10th February
2006, Vaasa
2
Part 1 The terminological method principles
and tools Part 2 Terminological ontologies
vs. other kinds of ontologies Part 3
Terminological concept modelling vs.
conceptual data modelling
3

• Part 1 The terminological method principles
  and tools
• Principles
• feature specifications
• dimensions
• dimension specifications
• subdividing dimensions
• inheritance
• Tools
• i-Term i-Model
• CAOS 2

4

• Example ontology from Working Group 07
• Prevention, Health Promotion and Public Health
• National Board of Health, Denmark
• Background
• IT strategy for the health sector, Government
  of Denmark, 2003 The Danish Council for
  Health Terminology
• Working groups Administrative concepts,
  Clinical process, Medication, Adverse events,
  Quality development, Information security,
  Prevention, Health Promotion and Public Health,
  Clinical interventions and results
• Objective
• To develop a common concept database for the
  Danish health sector as a basis for the
  development of electronic health record systems.
• DANTERMcentret terminology courses and
  consultancy

5
Working Group 07 Prevention, Health Promotion
and Public Health National Board of Health,
Denmark http.//begrebsbasen.sst.dk/forebyggelse
and special report which may be downloaded from
the web site
6
Terminological methods presented by examples from
i-Term i-ModelTerminology and Knowledge
Management System DANTERMcentret
7
i-Model allows the user to interactively produce
a graphical representation of a concept system
(traditional presentation). It is possible to
enter all kinds of concept relations, using
special symbols for generic, part-whole, temporal
and other relations, which may be named
specifically by the user. The user may also
enter feature specifications and subdivision
criteria (subdividing dimensions).
8
subdividision criteria
feature specification
9
i-Model choose your own colours and layout
10
i-Model Traditional layout
11
i-Model Inheritance may be introduced. Polyhier
achy is possible. No checking of consistancy in
diagrams.
12
polyhierarchy
inheritance
13
illegal polyhierarchy the two superordinate
concepts must belong to different groups
(dimensions)
14
How to build a concept system in i-Model
15
(No Transcript)
16
(No Transcript)
17
(No Transcript)
18
(No Transcript)
19
(No Transcript)
20
(No Transcript)
21
(No Transcript)
22
(No Transcript)
23
(No Transcript)
24
(No Transcript)
25
(No Transcript)
26
(No Transcript)
27
(No Transcript)
28
CAOSComputer-Aided Ontology Structuring

• Bodil Nistrup Madsen
• Hanne Erdman Thomsen
• Carl Vikner
• Bo Krantz Simonsen
• Jacob M. Christensen
• Dept. of Computational Linguistics

29
Concept systems in CAOS are based on the UML
notation with extensions. We build
terminological ontologies.
30
(No Transcript)
31
How to build a concept system in CAOS 2
32
(No Transcript)
33

• First concept prevention
• and dimension specification
• TARGET GROUP
• with values
• popuplation
• high-risk groups
• high-risk individuals!

34
The terminologist does not know the terms yet!
35
Three subordinate concepts automatically
generated on the basis of the dimension
specification. No terms yet!
36
(No Transcript)
37
Terms have been added
38
(No Transcript)
39
TARGET GROUP chosen as subdividing dimension
40

• Second dimension specification
• PHASE IN CLINICAL COURSE
• with values on new concepts
• before
• during
• after

41
Terms added at this stage.
42
(No Transcript)
43
(No Transcript)
44

• Attempt at creating an illegal polyhierarchy a
  concept universal selective prevention with two
  superordinate concepts within the same group
  (dimension TARGET GROUP).

45

• Creating a legal polyhierarchy a concept
  universal primary prevention with two
  superordinate concepts within two different
  groups (dimensions TARGET GROUP and PHASE IN
  COURSE).

46
(No Transcript)
47
There is only one delimiting dimension TARGET
GROUP. The introduction of the feature
specifications containing the dimension ARENA
indicates that there may exist some other
concepts,e.g. prevention in schools. Or the
feature specifications containing ARENA may be
considered as supplementary and determined by the
feature specifications containing TARGET GROUP.
New dimension specification ARENA with the
values school and risk environment.
48
CAOS implements more restrictive terminological
principles. CAOS helps the user in setting up
consistant concept systems adhering to the
terminological principles. The user has the
possibility of overriding some constraints if she
wants to. The backbone of this concept modelling
is constituted by characteristics modelled by
formal feature specifications, i.e.
attribute-value pairs.
49

• Constraints in CAOS related to subdivision
  criteria
• A concept (with only one mother concept) may
  contain at most one delimiting feature
  specification
• (i.e. a subdividing dimension may not overlap
  another one).
• Argumentation
• Multiplying delimiting characteristics in one
  concept may obscure the concept system by leaving
  out well-founded superordinate concepts, i.e.
  creating conceptual gaps, i.e. if the
  terminologist considers it necessary to attach
  more than one delimiting characteristic to a
  concept, this may indicate gaps in the concept
  system.

50
2) A concept (of level 2 or below) must contain
at least one delimiting feature specification
(i.e. the subdividing dimensions taken together
must cover all subordinate concepts). Argumentati
on It is not possible to make proper
definitions for a concept if the concept does not
have a delimiting characteristic.
51
3) An attribute may only be associated with one
value in a feature structure (i.e. one concept
can only be related to two superordinate
concepts, if the two superordinate concepts
belong to different subdividing dimensions
which is the case in a polyhierarchical
structure).
52
4) A given dimension may occur only on one
concept in an ontology (uniqueness of dimensions)
(i.e. feature specifications with the same
attribute must always occur on coordinate
concepts). Argumentation (to create
coherence and simplicity in the ontological
structure because concepts that are characterized
by means of a certain common dimension must
appear as coordinate concepts on the same level
having a common superordinate concept).
53
5) A feature specification may only occur once in
an ontology as primary (uniqueness of primary
feature specifications) (i.e. a given primary
feature specification can only appear on one of
the subordinate concepts). Argumentation This
principle contributes to create coherence and
simplicity in the ontological structure because
closely related concepts, i.e. concepts with
common characteristics, are kept closely together
in the ontology in that they must be subconcepts
of one common superordinate concept.
54
The two uniqueness principles (4 and 5) make it
possible to a certain extent to carry out
automatic placing of concepts into an ontology.
If a new concept is characterized by one or more
feature specifications, the system can be
instructed to search the ontology for concepts
with the attributes as dimensions and possibly
concepts having the same feature specifications,
and on this basis propose a location for the new
concept.  
55
Part 2 Terminological ontologies
vs. other kinds of ontologies
56
Terminological ontologies vs. philosophical
ontologies bottom-up vs. top-down
57
Sowa (199736) says "Philosophers usually
build their ontologies from the top down. They
start with grand conceptions about everything in
heaven and earth. Programmers, however, tend to
work from the bottom up. For their database and
AI systems, they start with limited ontologies or
microworlds, which have a small number of
concepts that are tailored for a single
application."
58
Brentanos tree structure of the categories of
Aristotle.
59
Terminology work is corpus based bottom up.
60
List of references used by Group 07
Prevention, Health Promotion and Public Health
61

• Need for a topontology for the health
  terminology!
• The working groups use general concepts in their
  definitions and as top concepts.
• Possible strategies
• Top-down before the work of the working groups
• Bottom-up after / during the work of the
  working groups based on general concepts
  identified by the 7 groups.
• Solution Strategy 2!

62
Draft topontology for the health
terminology Terminological principles used!
63
OpenCyc Selected Vocabulary and Upper
Ontology http//www.cyc.com/cycdoc/vocab/upperont-
diagram.html
64
Terminological ontologies vs. mathematical-logic
al ontologies
65
In terminological concept modelling only relevant
subconcepts are registered. This means that not
all possible combinations of concepts from two
or more groups (dimensions) will be registered,
e.g. a concept universal secondary prevention is
not relevant.
66
x
y
In lattices you typically find all combinations
that are logically possible.
a
b
c
d
67
Part 3 Terminological concept modelling vs.
conceptual data modelling
68
Concept systems corresponding to central
concepts in ISO 1087-1 with extensions from the
NORDTERM version of ISO 1087-1
69
extension
ISO-1087 Terminology of terminology Concept
system 3.2 Concepts Concept marked with red is
not defined in ISO 1087-1.
intension
object
characteristic
individual concept NUMBER OF REFERENTS one
object
concept
NUMBER OF REFERENTS
concept system
general concept NUMBER OF REFERENTS two or more
objects
concept relation
POSITION IN HIERARCHY
associative relation
hierarchical relation
superordinate concept POSITION IN HIERARCHY
above subordinate concept
subordinate concept POSITION IN HIERARCHY below
superordinate concept
sequential relation
generic relation
partitive relation
temporal relation
70
extension
intension
ISO 1087-1 (cf. previous slide)
object
intension set of characteristics which makes up
the concept
characteristic
concept
concept unit of knowledge created by a unique
combination of characteristics
71
extension
intension
object
characteristic
NORDTERM Danish definitions translated into
English
concept
ISO 1087-1 (from previous slide)
intension set of characteristics which denotes
the extension of a concept mængde af
karakteristiske træk der udpeger ekstensionen af
et begreb
concept unique combination of characteristics
which makes up the content of a term unik
kombination af karakteristiske træk der udgør
indholdssiden af en term
NORDTERM Danish version of concept system 02
Concepts Concept marked with red is not defined
in ISO 1087-1.
property quality of an entity
72
Draft concept system NORDTERM Terminology of
terminology in i-Model
73
intension
concept
extension
ISO-1087 Terminology of terminology Concepts
marked with red are not defined in ISO 1087-1.
object
characteristic
referent
NUMBER OF REFERENTS
property
individual concept NUMBER OF REFERENTS one
object
concept system
general concept NUMBER OF REFERENTS two or more
objects
POSITION IN HIERARCHY
concept relation
superordinate concept POSITION IN HIERARCHY
above subordinate concept
associative relation
hierarchical relation
subordinate concept POSITION IN HIERARCHY below
superordinate concept
sequential relation
generic relation
partitive relation
temporal relation
74
concept
ISO 1087-1 concept system 3.2 Concepts
unit of knowledge created by a unique combination
of characteristics
concept system
set of concepts structured according to the
relations among them
concept relation
associative relation
hierarchical relation
relation between two concepts which may be either
a generic or a partitive relation
relation between two concepts having a
non-hierarchical thematic connection by virtue of
experience
associative relation based on spatial or temporal
proximity
sequential relation
generic relation
partitive relation
relation between two concepts where the intension
of one of the concepts includes that of the other
concept and at least one additional delimiting
characteristic
relation between two concepts where one of the
concepts constitutes the whole and the other
concept a part of that whole
temporal relation
sequential relation involving events in time
75
Terminological concept modelling using UML UML
diagrams corresponding to central concepts of
ISO 1087-1 NB! Here we are not talking about
conceptual data models for a database
76
concept
ISO-1087 Terminology of terminology
NUMBER OF REFERENTS
individual concept NUMBER OF REFERENTS one
object
general concept NUMBER OF REFERENTS two or more
objects
POSITION IN HIERARCHY
superordinate concept POSITION IN HIERARCHY
above subordinate concept
subordinate concept POSITION IN HIERARCHY below
superordinate concept
Traditional presentation
77
concept
discriminator
specialisation
position in hierarchy
number of referents
individual concept
superordinate concept
general concept
subordinate concept
Example of specialisation ( type relation) and
discriminators ( subdivision criteria) in UML
diagrams ISO-1087 (types of concepts)
78
concept
ISO 1087-1 concept system 3.2 Concepts
unit of knowledge created by a unique combination
of characteristics
concept system
set of concepts structured according to the
relations among them
concept relation
associative relation
hierarchical relation
relation between two concepts which may be either
a generic or a partitive relation
relation between two concepts having a
non-hierarchical thematic connection by virtue of
experience
associative relation based on spatial or temporal
proximity
sequential relation
generic relation
partitive relation
relation between two concepts where the intension
of one of the concepts includes that of the other
concept and at least one additional delimiting
characteristic
relation between two concepts where one of the
concepts constitutes the whole and the other
concept a part of that whole
temporal relation
sequential relation involving events in time
79
concept
1..
Example of aggregation ( part-whole relation) in
UML diagrams ISO-1087 (types of concepts)
concept system
concept relation
1..
aggregation
associative relation
hierarchical relation
generic relation
partitive relation
sequential relation
temporal relation
80
Same concept system with definitions from ISO-1087
concept
1..
concept system
unit of knowledge created by a unique combination
of characteristics
concept relation
set of concepts structured according to the
relations among them
1..
relation between two concepts having a
non-hierarchical thematic connection by virtue of
experience
associative relation
hierarchical relation
relation between two concepts which may be either
a generic or a partitive relation
associative relation based on spatial or temporal
proximity
generic relation
partitive relation
sequential relation
relation between two concepts where the intension
of one of the concepts includes that of the other
concept and at least one additional delimiting
characteristic
relation between two concepts where one of the
concepts constitutes the whole and the other
concept a part of that whole
temporal relation
sequential relation involving events in time
81
Conceptual data modelling for DANTERM / CAOS
databases represented in UML
82
is expressed by
1..
1..
class
belongs to
1..
attributes
association
0.. zero, one or more 1.. one or more
0..
multiplicity
1..
is related to
is related to
1..
83
is expressed by
1..
1..
class
belongs to
1..
attributes
attributes are found in a special compartment in
the class
association
0..
multiplicity
1..
is related to
is related to
1..
84
is expressed by
1..
1..
belongs to
1..
information about primary key (pk) foreign keys
(fk) and data types (String), may be added to the
attributes
0..
1..
is related to
is related to
1..
85
is expressed by
1..
1..
belongs to
1..
extra class between classes in a many-to-many
relationship
0..
1..
is related to
is related to
1..
86
is expressed by
1..
1..
reflexive association One concept in one position
in a concept system is related to one or several
concepts in the same concept system.
belongs to
1..
0..
1..
is related to
is related to
1..
87
Terminological concept modelling vs. conceptual
data modelling

• in order to produce a well-functioning database
  it is necessary to know the concept model for the
  domain underlying the data model, which forms the
  basis of the database structure
• knowledge about the concepts in a domain is found
  in the characteristics and the concept relations

88
Terminological concept modelling vs. conceptual
data modelling

• concept systems and data models do have something
  in common
• but
• there is no one-to-one correspondence between a
  concept system and the data model of the
  database
• There is no one-to-one mapping between concepts
  and characteristics in the concept model and
  classes and attributes in the data model.
• Some concepts correspond to attributes in the
  data model, and some concepts may neither
  correspond to classes nor to attributes.

89
A concept system for concepts may comprise
concepts such as superordinate concept and
subordinate concept, which are subordinate
concepts to concept.
concept
position in hierarchy
superordinate concept
subordinate concept
90
There are no corresponding classes or attributes
in the conceptual data model rather, they will
be represented by means of the attributes C-ID1
and C-ID2 on the class concSystRel, and the
corresponding table concSystRel relates two
concepts to each other (via their positions)
together with a specification of which relation
type (attribute R-ID) holds between them.
91
Another example concepts such as intension and
extension, which are very important in a concept
system for the understanding of central concepts
like concept and characteristic, will not be
found in an entity/relationship diagram for a
terminology database.
92

• UML
• UML was originally developed for conceptual data
  modelling, i.e. graphical presentation of the
  model that forms the basis of the structure of an
  IT system, for example a database.
• not possible to represent several dimensions,
  from which one may be chosen as the subdividing
  dimension
• no notation for the specification of dimension
  values, at least not in the way it is done in
  CAOS
• no notation for feature specifications (it is
  possible to use a facility of UML which comes
  close to feature specifications as used in CAOS
  in specializations it is possible to introduce
  attributes with initial values, e.g. plane for
  the class flight which is a specialization of
  the class travel).

93

• The attributes in a conceptual data model
• specify which kinds of information may be
  related to each class and consequently to each
  instance in the IT system
• the values of the attributes will exist only in
  the IT system (e.g. in the database), and they
  will give information about instances. The value
  of an attribute may differ for each instance of
  the class.

94
Terminological concept modelling vs. conceptual
data modelling

• Concept modelling
• information about concepts in the form of feature
  specifications and concept relations
• Conceptual data modelling
• information about the classes in the form of
  attributes and associations between the classes
• attributes give no information about the meaning
  of the classes, but only a specification of what
  kind of information will be given about the
  entities represented by the classes in question

NB! The attribute values describe the individual
instances, not the concept which lies behind the
class
95
Thank you for your attention!
96
(No Transcript)