iso tc37/sc4 n433 busan 2007 ontologies & taxonomies bodil nistrup madsen department of...

ISO TC37/SC4 N433

Busan 2007

ONTOLOGIES & TAXONOMIES

Bodil Nistrup MadsenDepartment of International Language Studies and

Knowledge Technologywww.cbs.isv.dk

&DANTERMcentretwww.danterm.dk

Copenhagen Business School


• Terminological ontologies

• Concept clarification: ontology, taxonomy, data model etc.

• An ontology of ontologies

• A taxonomy for lexical data

• Terminological concept modelling vs.conceptual data modelling

• Modelling partiel equivalence between concepts

Overview

Terminological Ontologies

Principles:• feature specifications (modelling

characteristics of concepts)• dimensions / subdividing dimensions

(modelling subdivision criteria)• dimension specifications • constraints

Tools:• i-Term & i-Model, DANTERMcentret• CAOS 2 prototype

(Computer-Aided Ontology Structuring), Group of Computational Linguistics

Terminological principles presented by means of

examples from i-Term & i-Model

Terminology and Knowledge Management System

DANTERMcentretwww.i-term.dk

feature specification: attribute-value pair

subdivision criteria

polyhierarchy

inheritance

Extract of an ontology for prevention in i-Model

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.

Concept oriented !

Associative concept relations

OntoQuery – Ontology-based Queryingwww.OntoQuery.dk

Madsen, Bodil Nistrup, Bolette Sandford Pedersen & Hanne Erdman Thomsen:

The Role of Semantic Relations in a Content-based Querying System: a Research Presentation from the OntoQuery Project.

In: Simov, Kiril & Atanas Kiryakov (eds.): Proceedings from OntoLex ”2000, Workshop on Ontologies and Lexical Knowledge Bases, Sept. 8-10 2000, Sozopol, Bulgaria,.

rolerelation

agentrelation

patientrelation

instrument relation

resultrelation

agent-patient relation

agent-instrument relation

agent-result relation

patient-instrument relation

patient-result relation

instrument-result relation

activity-agent relation

activity-patient relation

activity-result relation

activity-instrument relation

activity relation

semantic relation

source-target relation

activity-source relation

activity-target relation

source relation

target relation

location relation

staticlocation relation

activity – static location relation

entity – static location relation

dynamiclocation relation

ship – quay

disembarkation – ship landing – airport

swim – water

oasis – dessert

heal – doctor

teach – student

paint – brush

coffee making – coffee

drawer – drawee

surgeon – scalpel

drawer – draft

wood - plane

student – graduate

coffee machine – coffee

Madsen, Pedersen & Thomsen, 2001: The relations location, activity and role

location relation

dynamic location

source

directed to (activity-target)

originates in (activity-source)

transmits to (source-target)

takes place in (activity-static location)

situated in (entity-static location) static location

role relation

performed by (activity-agent)

performed on (activity-patient)

performed with (activity-instrument)

results in (activity-result)

affects (agent-patient)

uses (agent-instrument)

brings about (agent-result)

processed with (patient-instrument)

transformed into (patient-result)

produces (instrument-result)

associative relation

target

activity

agent

patient

instrument

result

CAOS Version

CAOSComputer-Aided Ontology

Structuring

Bodil Nistrup MadsenHanne Erdman Thomsen

Carl ViknerBo Krantz Simonsen

Jacob M. Christensen

Group of Computational LinguisticsISV

CAOS implements more restrictive terminological principles than i-Model.

CAOS helps the user in setting up consistent ontologies adhering to the terminological principles.

CAOS is based on the UML notation, but extensions are needed.

The backbone of this concept modelling is constituted by characteristics modelled by formal feature specifications, i.e. attribute-value pairs.

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

primary feature specification

inherited feature specifications

Three subordinate concepts automatically generated on the basis of the dimension specification. No terms – yet!

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

The CAOS prototype is based on UML notation, but extensions are needed for terminological concept modelling

UML class diagrams:

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







Overview

classification taxonomy

thesauruswordnet

ontologyconcept system

Clarification needed !

classcategory

keyword (syn)set

type concept

term

eCatTerminology taskCEN CWA 15045

Multilingual Catalogue Strategies for eCommerce and eBusiness

Bodil Nistrup Madsen

DANTERMcentret, the Danish Terminology Centre - www.danterm.dk

&

Håvard Hjulstad

Standards Norway, [email protected] or [email protected]

data model

classification system

ontology

model

knowledge representation

subjectclassification system

taxonomy

Based on eCatTerminology taskCEN CWA 15045Multilingual Catalogue Strategies for eCommerce and eBusiness

Concept Synonyms Characteristic Definitions

model PURPOSE: knowledge representation

simplified representation of knowledge about phenomena

ontology concept model; concept system

DESCRIPTION: concepts

model for the description of knowledge about concepts

data model DESCRIPTION: data

formal model for the description of data in an IT system


classification PURPOSE: classification

system for the division of phenomena into classes

taxonomy CONTENTS: categories

classification system for the division of categories of a domain

subject classification system

subject classification

CONTENTS: subject fields

classification system for the division of phenomena into subject fields

Translations of definitions from the OIO Concept database

data model


ontology

model



taxonomy


ontology

NOTE: An ontology may comprise all kinds of relations between concepts, e.g. generic, partitive and temporal relations.

Synonyms: concept model, concept system

A data model should always be based on an ontology, but sometimes a data model, represented by means of an ER or a UML diagram, is referred to as an ‘ontology‘. Our recommendation is to use the term ‘ontology‘ only as defined here. Please observe that the term ‘conceptual model‘ is referring to a kind of data model.An ontology may typically be used for the precise description of concepts.

CEN CWA 15045

taxonomy

NOTE: A taxonomy is a kind of classification system, that comprises exclusively generic relations between the categories, in contrast to an ontology, which is a kind of model that may comprise all kinds of relations between concepts.

A taxonomy may typically be used for defining the types of data categories used within a specific field, eg. within the field of product description.

CEN CWA 15045

data model


ontology

model



taxonomy


conceptual data model

data model that represents an abstract view of the real world

ISO/IEC 11179-3: 2003(E), 3.2.8

information model

data model that represents the organization of information in a manner that reflects the structure of an information system

Amended from ISO/IEC FCD 11179-3: 2003(E), 3.2.13

CEN CWA 15045

class description

concept in an ontology

concept definition

data category in a taxonomy

data category definition

class in a classification system

class description

class in a data model

Concept definitions form the basis for the definitions / descriptions of data categories, classes in classification systems, classes in data models







Overview

ontology

philoso-phical ontology

pragmaticontology

top level ontology

universalontology

domain specific ontology

generalontology

taskspecificontology

task inde-pendantontology

language inde-pendant ontology

language inde-pendant ontology

formalontology

not formal onto-logy

POINT OF VIEW

specific ontology

LEVEL SUBJECT

PURPOSE LANGUAGE FORMALIZATION

application specificontology

With input from:

Guarino, Nicola (1998). Formal Ontology and Information Systems,.

Bodil Nistrup Madsen, Alting på sin plads og plads til alting. Om at ordne og udnytte viden om verden. I: Anita Nuopponen, Bertha Toft, Johan Myking (eds.): I Terminologins tjänst. Festskrift för Heribert Picht på 60-årsdagen. Proceedings of the University of Vaasa, Reports, Vaasa 2000, s. 71-91.

terminological ontology

METHOD

Hanne Erdman Thomsen

On the basis of Gómez-Pérez et al (2004) Ontological Engineering

TC 37 Terminology and other language and content resources

Ontology Task Force

Provo, August 2007

Members of TC37 Ontology Task Force team:

SC 1Donald ChapinHanne Erdman Thomsen Hendrick Kockaert

SC 2Gerhard Budin

SC 3Bodil Nistrup Madsen (convenor)Klaus-Dirk SchmitzSue Ellen Wright

SC 4Koiti Hasida Jae Sung LeeKey-Sun ChoiNicoletta Calzolari

ISO/IEC JTC 1 SC32Bruce Bargmeyer

TC37 SecretariatChristian Galinski

Organization of work:

1) Concept clarification

• Different types of knowledge representation resources

• What is the difference between ontology, taxonomy, thesaurus etc.

Result: systematic overview (concept system with definitions)

2) Overview of ontologies and projects 'outside' TC37- examples!

Organization of work:

3) Overview of related ongoing projects, existing standards, proposals for future projects within TC 37

4) Proposal for a strategy for TC 37 including future co-ordination by the Ontology Task Force

New title 2005-08-25:

Systems to manage terminology, knowledge and content

New scope 2005-08-25:

Standardization of specifications and modelling principles for systems to manage terminology, knowledge and content with respect to semantic interoperability

ISO/TC 37/SC 3 N542

Examples of future projects:

Principles for building taxonomies for metadata

Examples: • A taxonomy for lexical and terminological data.• A taxonomy for any other kind of data collection.

TC 37 should be a pioneer within this field!Such taxonomies, which describe the contents of data

collections, also comprise systematic definitions and examples which will make it easier to classify data elements.

Motivation: It is extremely important to be able to describe elements of

data collections systematically in order to build databases / IT systems for storage, management and exchange of data. Many metadata vocabularies are not built on the basis of the principles of taxonomies, which means that they may be incomplete, inconsistent and difficult to use.

Principles for the use of concept models (ontologies) in developing data models

Examples: • Concept model for central concepts that form the basis of the

development of a data model for a terminology database.• Concept model for any other kind of database / IT system

(e.g. Electronic Health Care Systems) and the corresponding data model.

This project is not the same as the NWI in TC 37 SC 1 on Guidelines for applying concept modelling in terminology work (N 273).

Motivation: Many data models are still developed without being based on a

concept model. The two concepts ‘concept model’ (ontology) and ‘conceptual data model’ are very often mixed up. Ontology is often used for conceptual data model.

Principles for the development and use of meta models

This project should comprise guidelines based on the experience gained from the development of the meta model in ISO 16642.

It is related to the previous proposal.

Motivation: It is a non-trivial job to develop a meta model: How detailed should / could a meta model be? How to build specific data models on the basis of a meta

model?







Overview

Proposal for a Taxonomy of Lexical Metadata Categories

for ISO TC 37

Terminology and Other Language Applications

ISO TC 37 published a standard in 1999 specifying data categories used in terminological resources, ISO 12620:1999, Computer assisted terminology management ― Data Categories.

In 2003, TC 37/SC 3 initiated a revision of the existing document with the intention of creating a family of data category standards designed to meet the needs of terminologists and other language experts developing a variety of electronic linguistic resources.

The intention was to include data categories for a variety of applications, including for example terminological and lexicographical data collections as well as machine translation lexica, cf.: SC 3 Systems to manage terminology, knowledge and content SC 2 Terminographical and lexicographical working methods SC 4 Language resource management.

At the same time it was suggested to set up a Data Category Registry (DCR) for all the above mentioned kinds of lexical data, cf. also Ide & Romary (2004). The DCR is intended to be compliant with ISO 11179-3, Information technology — Metadata registries (MDR) — Part 3: Registry metamodel and basic attributes.

The data categories of ISO 12620:1999 were classified in three major groups, and the groups were further subdivided into ten sub-groups:

A.1 term

A.2 term-related information

A.3 equivalence

A.4 subject field

A.5 concept-related description

A.6 concept relation

A.7 conceptual structures

A.8 note

A.9 documentary language

A.10 administrative information

Term and term-related data categories:

Descriptive data categories:

Administrative data categories:

This structure is not homogenous, i.e. it reflects various subdividing criteria (dimensions), and it does not give a very clear overview of the data categories. One dimension is for example term-related information vs. concept-related description. Here it is not clear why e.g. subject field and concept relation do not fall within the group: concept-related description.

An example of term-related information is A.2.1.18.1 collocation, while an example of concept-related information is A.5.3 context (a text or part of a text in which a term occurs). Types of contexts can, among others, include: defining context (a context that contains substantial information about a concept, but that does not possess the formal rigor of a definition) and linguistic context (context that illustrates the function of a term in discourse, but that provides no conceptual information).

It seems as if the structure of ISO 12620:1999 is to some extent based on the structure typically found in a terminological entry. Since the above mentioned DCR of TC 37 will also include data categories of dictionaries, this structure is not very appropriate.

Consequently it was decided to give up a classification of the categories.

It is however difficult to ensure completeness, consistency, user-friendliness and extensibility of the above mentioned DCR, if there is no structure of the data categories.

The structure of the DCRAs already mentioned the DCR will contain data categories that are relevant in various areas, such as terminology, lexicography and machine translation. These areas are referred to as thematic domains.

In August 2007 there was an introductory meeting for the TC 37 Data Category Registry, in which all Sub-Committees and Working Groups that have any activities involving data categories were requested to nominate experts to serve on the Thematic Domain Group (TDG).

The idea was, that each TDG should be charged with the specification of domain-specific data categories for a specific data processing environment within TC 37.

Figure 1 (from Wright 2004) illustrates clearly that the various subsets of the DCR, i.e. the thematic domains, will overlap. For example, the data categories part of speech and grammatical gender will be relevant in all three different thematic domains.

Collections of Lexical data -

description of data categories and data structure -

Part 1: Taxonomy for the classification of information types

’STANLEX’

Danish Standard: DS 2394-1 (1998)

STANLEX taxonomy

Main categories based on linguistic disciplines

etymological information grammatical information graphical information phonetic information semantic information usage

In addition to these categories there are some categories for administrative information and structural information.

This taxonomy was developed by a group of terminologists, lexicographers and people working with machine translation and other kinds of natural language processing.

Grammatical information

• Part of speech• Gender

• Information on inflection • Stem• Paradigm information• Inflected form

• Word formation

• Syntax • Syntactic frame (valency)• Specification of syntactic frame• Specification of auxiliary verb• Syntactic function

Main group Category Subcategory

Examples:

Main group Category Subcategory

Usage • Examples of usage • Citation• Collocation

• Information on usage

• Temporal• Spatial• Communicative • Frequency

• Evaluative information

All main groups, categories and subcategories are defined and exemplified. The structure of this taxonomy gives a much clearer overview of the data categories than the original structure of ISO 12620:1999, and it is clearly better than a plain alphabetical list.

The use of a taxonomy makes it much easier to check whether the DCR of ISO TC 37 comprises all relevant data categories within a certain group. In the case of proposals for new data categories it is also much easier to check whether the category is already in the DCR, maybe under another category name.

Proposal for a taxonomy for lexical metadata categories

On the background of the above mentioned advantages of using a taxonomy for the classification of metadata categories it is suggested that the principles of the taxonomy of DS 2394-1:1998 are used for the structuring data categories in the DCR for lexical data in ISO TC 37.

There will no doubt be a need for more categories and subcategories than those found in DS 2394-1:1998, but it will be easy to fit new categories into the structure, as long as they are mutually independent.

There may also be a need for adjustments of the structure, since there do exist different ways of classifying lexical data.

However, DS 2394-1:1998 is a good starting point, and using the principles of this taxonomy will ensure

completeness

consistency

user-friendliness

extensibility







Overview

Ontologies (concept models) and conceptual data models have different aims:

• ontologies aim at concept clarification and mutual understanding of concepts and consistent use of terms

• conceptual data models aim at specifying the information types of an IT system and their mutual relationships

In order to produce a well-functioning database it is necessary to know the concept model for the domain underlying the database structure, i.e. you have to be familiar with the central concepts of the domain in which the database is going to function.

Ontologies (concept models)

conceptual data models

information about concepts in the form of feature specifications and concept relations (information about meaning)

information about the classes in the form of attributes and associations between the classes

NB! The attributes of the data model 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.

• ontologies and data models do have something in common

but• there is no one-to-one correspondence between an

ontology and the data model of the database:

• There is no one-to-one mapping between concepts

and characteristics in the ontology and classes and attributes in the data model.

• Some concepts correspond to attributes or values

in the data model - some concepts may not correspond to classes, attributes or values.

Terminological concept modelling vs. conceptual data modelling

Draft concept system: NORDTERM ‘Terminology of terminology’ in i-Model (here translated into English)

More elaborate Danish version

Conceptual data modelling

for DANTERM / CAOS databases represented in UML

belo

ngs

to

1..*

is related to

is related to

1..* 1..*

1..*

0..*

is expressed by

1..*

conceptSystem

S-IDSYSTNAMELANG

concSystPos

S-ID C-ID1C-ID2

concept

C-ID LANG CLASSA

term

C-IDE-IDSTATUS …

expression

E-ID EXPRESS

concSystRel

S-ID C-ID1 S-ID2C-ID2R-ID

0..* = zero, one or more1..* = one or more

class

attributes

association

multiplicity:

belo

ngs

to

1..*

is related to

is related to

1..* 1..*

1..*

0..*

is expressed by

1..*

conceptSystem

S-ID pkSYSTNAMELANG fk

concSystPos

S-ID pkC-ID1 pkC-ID2 pk

concept

C-ID pkLANG fkCLASSA fk

term

C-ID pk fkE-ID pk fkSTATUS String…

expression

E-ID pkEXPRESS

concSystRel

S-ID pkC-ID1 pkS-ID2 pkC-ID2 pkR-ID

information aboutprimary key (pk) foreign keys (fk) and data types (String), may be added to the attributes

belo

ngs

to

1..*

is related to

is related to

1..* 1..*

1..*

0..*

is expressed by

1..*

conceptSystem


concSystPos


concept


term


expression

E-ID pkEXPRESS

concSystRel


extra class between classes in a many-to-many relationship

belo

ngs

to

1..*

is related to

is related to

1..* 1..*

1..*

0..*

is expressed by

1..*

conceptSystem


concSystPos


concept


term


expression

E-ID pkEXPRESS

concSystRel


Reflexive association:

One concept in one position in a concept system is related to one or several concepts in the same concept system.

A concept system for concepts may comprise concepts such as superordinate concept and subordinate concept (both subordinate concepts to concept).

These concepts are not found in the data model.

Conceptual data model

There are no corresponding classes: superordinate and subordinate concepts 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 together with a specification of which relation type (attribute R-ID) holds between them.

concSystRel


belo

ngs

to

1..*

is related to

is related to

1..*

0..*

1..*

conceptSystem


concSystPos


concept


Draft concept system: NORDTERM ‘Terminology of terminology’ in i-Model (here translated into English)

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 UML diagram for a terminology database.

Ontology Conceptual data model

Logical data model

Physical data model

Models as the basis for development of IT systems

Recommendation:

Always develop an ontology before developing a conceptual data model!







Overview

In multilingual terminology work concept systems will be established for all languages in a project.

In some cases one concept in one language may be partially equivalent to several concepts in one or several other languages. This also means that the concept systems of the individual languages differ.

Therefore it should be possible in a terminology database to establish an equivalence relationship between one concept in one language and two or three concepts in another language.

Modelling partiel equivalence between concepts

parti

al

equi

vale

nce

partial equivalence

partial equivalence

Concept 1English

Concept 1German

Concept 2German

Concept 2English

This could for example be the case in terminology within the field of education. One level in the English education system may correspond to two levels in the German education system and vice versa.

Entry 1

Entry 2Entry 3

This means that each concept in a terminology database may be linked to several terminological entries.

Concept 1English

Concept 1German

Concept 2German

Concept 2English

partial equivalence

Entry 3

Entry 2

Entry 1 In many cases the Terminology Management System will build on a simpler model:

Concept 1 in English and Concept 1 in German are duplicated in the database, since one concept can not be linked to several entries.

Concept 1English Version 1

Concept 1GermanVersion 1

Concept 2German

Concept 2English

Concept 1GermanVersion 2

Concept 1English Version 2

partial equivalence

partial equivalence

0..1

1

1 1

0..*

1..*

1..*

1

0..*

1..*

1..*0..1

0..*

1

subject field

concept

definition term

grammarsourceidentifier

originatingperson

1

0..1

1

0..*

originationdate

1..*

0..*

context

note

1

0..*

terminological entry

1..*

1..*

degree of equivalence

entry_concept

1

0..*

The model allows one concept to be linked to one or more concepts in other languages. This means that each concept may be linked to several terminological entries.

SC 3: Design, implementation and use of terminology management systems

The system of courts in Italy

22 concepts

The Danish system

13 concepts

Generic concepts within Health Care in Denmark (top & core ontology – translated into English

Problems in translating e.g. activity, conduct, action.

• Domain specific ontologies should be based on the principles of terminological ontologies.

• Concept clarification is needed wrt. ontology, taxonomy, data model etc.

• An ontology of ontologies would help in this concept clarification

• A taxonomy for lexical data for TC 37 will ensure completeness, consistency, user-friendliness and extensibility

• Terminological ontologies and conceptual data models differ

• Introducing multilingualism in ontologies requires modelling of partiel equivalence between concepts

Conclusions

Thank you for your attention!

Bodil Nistrup MadsenDepartment for International Language

Studies and Knowledge Technologywww.cbs.isv.dk

&DANTERMcentretwww.danterm.dk


Handelshøjskolen i København

iso tc37/sc4 n433 busan 2007 ontologies & taxonomies bodil nistrup madsen department of...

Documents

model slide

role slide

ontology of ontologies

concepts overview slide

caos version slide

relations location

terminological principles

concept oriented