Ontologies and terminological concept modelling Bodil Nistrup Madsen & Hanne Erdman Thomsen

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. conceptualdata 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 SystemDANTERMcentret

7. i-Modelallows 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. 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

24. associative relation temporal relation part-whole relation type relation

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

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. 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

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!

37. Terms have been added

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.

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).

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.