Presentation is loading. Please wait.

Presentation is loading. Please wait.

Ontologies and terminological concept modelling

Similar presentations


Presentation on theme: "Ontologies and terminological concept modelling"— Presentation transcript:

1 Ontologies and terminological concept modelling
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
feature specifications dimensions dimension specifications subdividing dimensions inheritance Tools: i-Term & i-Model CAOS 2

4 National Board of Health, Denmark
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, : 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 Prevention, Health Promotion and Public Health
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-Model Terminology 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 feature specification
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. Polyhierachy 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

16

17

18

19

20

21

22

23

24 part-whole relation temporal relation type relation associative relation

25 This concept system comprises:
concept positions feature specifications subdivision criteria

26

27

28 CAOS Computer-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 dimension specifications
(specify the values associated with the corresponding attribute on the subconcepts) subdividing dimension (concepts belonging to the same subdividing dimension are grouped together and the subdividing dimension is shown on the links to the concepts) type relation feature specification primary feature specification inherited feature specifications

31 How to build a concept system in CAOS 2

32

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

37 Terms have been added

38

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

43

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

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). Argumentation: 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 (1997:36) 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 Brentano’s 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

64 Terminological ontologies vs. mathematical-logical 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 corresponding to central concepts
Concept systems corresponding to central concepts in ISO with extensions from the NORDTERM version of ISO

69 extension intension ISO-1087 Terminology of terminology Concept system 3.2 Concepts Concept marked with red is not defined in ISO 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 hierarchical relation associative relation superordinate concept POSITION IN HIERARCHY: above subordinate concept sequential relation subordinate concept POSITION IN HIERARCHY: below superordinate concept generic relation partitive relation temporal relation

70 ISO 1087-1 (cf. previous slide)
extension intension ISO (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 NORDTERM: Danish definitions translated into English
extension intension object characteristic NORDTERM: Danish definitions translated into English concept ISO (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 characteristic property intension concept extension object referent 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 property quality of an entity

72 Draft concept system: NORDTERM Terminology of terminology in i-Model

73 extension intension concept ISO-1087 Terminology of terminology Concepts marked with red are not defined in ISO 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 hierarchical relation associative relation superordinate concept POSITION IN HIERARCHY: above subordinate concept sequential relation subordinate concept POSITION IN HIERARCHY: below superordinate concept generic relation partitive relation temporal relation

74 concept ISO 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 hierarchical relation associative 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 NB! Here we are not talking about conceptual data models for a database

76 Traditional presentation
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 ISO-1087 (types of concepts)
discriminator specialisation position in hierarchy number of referents individual concept general concept superordinate concept subordinate concept Example of specialisation (= type relation) and discriminators (= subdivision criteria) in UML diagrams ISO-1087 (types of concepts)

78 concept ISO 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 hierarchical relation associative 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 Example of aggregation (= part-whole relation) in UML diagrams
concept 1..* Example of aggregation (= part-whole relation) in UML diagrams ISO-1087 (types of concepts) concept system concept relation 1..* aggregation hierarchical relation associative relation generic relation partitive relation sequential relation temporal relation

80 Same concept system with definitions from ISO-1087
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 hierarchical relation associative 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 class attributes association multiplicity: 0..* = zero, one or more
is expressed by concept C-ID pk LANG fk CLASSA fk expression E-ID pk EXPRESS 1..* 1..* class 1..* belongs to term C-ID pk fk E-ID pk fk STATUS attributes association 0..* = zero, one or more 1..* = one or more 0..* multiplicity: concSystRel S-ID pk C-ID1 pk S-ID2 pk C-ID2 pk R-ID conceptSystem S-ID pk SYSTNAME LANG fk concSystPos S-ID pk C-ID pk POS-ID 1..* is related to is related to 1..*

83 attributes are found in a special compartment in the class
is expressed by concept C-ID pk LANG fk CLASSA fk expression E-ID pk EXPRESS 1..* 1..* class 1..* belongs to term C-ID pk fk E-ID pk fk STATUS attributes attributes are found in a special compartment in the class association 0..* multiplicity concSystRel S-ID pk C-ID1 pk S-ID2 pk C-ID2 pk R-ID conceptSystem S-ID pk SYSTNAME LANG fk concSystPos S-ID pk C-ID pk POS-ID 1..* is related to is related to 1..*

84 is expressed by concept C-ID pk LANG fk CLASSA fk expression E-ID pk EXPRESS 1..* 1..* 1..* belongs to term C-ID pk fk E-ID pk fk STATUS String information about primary key (pk) foreign keys (fk) and data types (String), may be added to the attributes 0..* concSystRel S-ID pk C-ID1 pk S-ID2 pk C-ID2 pk R-ID conceptSystem S-ID pk SYSTNAME LANG fk concSystPos S-ID pk C-ID pk POS-ID 1..* is related to is related to 1..*

85 extra class between classes in a many-to-many relationship
is expressed by concept C-ID pk LANG fk CLASSA fk expression E-ID pk EXPRESS 1..* 1..* 1..* belongs to term C-ID pk fk E-ID pk fk STATUS extra class between classes in a many-to-many relationship 0..* concSystRel S-ID pk C-ID1 pk S-ID2 pk C-ID2 pk R-ID conceptSystem S-ID pk SYSTNAME LANG fk concSystPos S-ID pk C-ID pk POS-ID 1..* is related to is related to 1..*

86 reflexive association
is expressed by concept C-ID pk LANG fk CLASSA fk expression E-ID pk EXPRESS 1..* 1..* belongs to reflexive association One concept in one position in a concept system is related to one or several concepts in the same concept system. 1..* term C-ID pk fk E-ID pk fk STATUS 0..* concSystRel S-ID pk C-ID1 pk S-ID2 pk C-ID2 pk R-ID conceptSystem S-ID pk SYSTNAME LANG fk concSystPos S-ID pk C-ID pk POS-ID 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 concSystRel S-ID pk C-ID1 pk S-ID2 pk C-ID2 pk R-ID belongs to 1..* is related to 0..* conceptSystem SYSTNAME LANG fk concSystPos C-ID pk POS-ID concept CLASSA fk 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 characteristic property intension concept extension object referent 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
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


Download ppt "Ontologies and terminological concept modelling"

Similar presentations


Ads by Google