Ontology Engineering

(1)

1 Vorlesung Netzbasierte Informationssysteme

Ontology Engineering

Prof. Dr. Adrian Paschke

Arbeitsgruppe Corporate Semantic Web (AG-CSW) Institut für Informatik, Freie Universität Berlin paschke@inf.fu-berlin.de

http://www.inf.fu-berlin.de/groups/ag-csw/

(2)

2

28.01.2009

Ontologieentwicklung - Warum?

• Um Domänenannahmen explizit zu machen

• Leichter die Annahmen in einer Domäne zu ändern

• Leichter bestehende Daten zu verstehen und zu ändern

“liver” as an term of human anatomy

“keyboard” as term for computer equipment Enables data integration at different granularities

• Um Domänenwissen von operationalem Wissen zu trennen (seperation of concerns)

• Getrennte Wiederverwendung von Domänen- und Anwendungswissen domain: “liver” is_a “organ”

domain: “caspase 8” is_a “protein”

domain: “caspase 8” involved_in “programmed cell death”

operational: “proteins” have sequence data

operational: “protein sequences” are input for EBI-BLAST

(3)

3

28.01.2009

Ontologieentwicklung - Warum? (2)

 Eine Community Referenz für Anwendungen

 Um ein konistentes Verständnis darüber was Information bedeutet zu teilen

Design Pattern:

CEP Design -> EDBPM Pattern

Author name:

Adrian Paschke, FU-Berlin, CSW

(4)

4

Vom „Ontologien bauen“ zum Ontology Engineering

•

Zu Beginn individuelle „Kunst“ einzelner Experten – kannten die Theorie & Standards

– konnten mit Werkzeugen umgehen

•

Aber: Wissen ist nur repräsentativ, wenn es ein Konsens vieler Personen ist

– Teilnehmer bei Ontologie-Entwicklung haben unterschiedlich ausgeprägtes Wissen

• der Ontologie-Entwickler ist in den seltensten Fällen auch Domänen-Experte

– der Prozess ist kollaborativ, verteilt und asynchron – der Prozess ist iterativ

– Es gibt viele alternative Wege eine Ontologie zu modellieren

 grundsätzliche Prinzipien vom Software Engineering adoptiert – Neueste Ansätze definieren Übersetzungsleitfäden (z.B.

spezielles OE Glossar)

(5)

5

Ontology Engineering Definition

Ontology Engineering beschreibt den Ontologie-

Entwicklungsprozess, den Ontologie-Lebenszyklus, die Methoden und die Methodiken um Ontologien zu erzeugen sowie die Werkzeuge und Sprachen, die dieses unterstützen.

Quelle: Asunción Gómez-Pérez, Mariano Fernández-López, Oscar Corcho (2004). Ontological Engineering: With Examples from the Areas of Knowledge Management, E-commerce and the Semantic Web. Springer, 2004.

(6)

6

Ontology Engineering Aufgaben

Ontology Engineering

Prozess

Designphase

Betrieb und Pflege

Ent- scheidungs-

phase

(7)

7

Ontology Engineering Phasen

• Anforderungen und Analyse

• Design und

Implementierung

• Testen und Validierung

• Wartung und Pflege

(8)

8

Anforderungen und Analyse

• Top Down: Critical Success Factor Analysis

• Historie:

• Konzept “Success Factors" entwickelt von D. Ronald Daniel (McKinsey) 1961 und neudefiniert durch Jack F. Rockart 1986

• Angewandt 1995 durch James A. Johnson und Michael Friesen in unterschiedlichsten Domänen

• Kritische Erfolgsfaktoren (critical success factors) sind Element die notwendig für den Erfolg einer

Projektstrategie sind.

• Im Ontologie Engineering:

• Bestimmung der kritischen Erfolgsfaktoren für ein Ontologie-Projekt

• Beispiele: Ontologie Design, Finanzierung, Produktion, Pfelge der Qualität, etc.

(9)

9

Anforderungen und Analyse (2)

• Bottom Up:

• Use Case Analyse

• Vorherschende Form um Nutzungsanforderungen zu sammeln

• Technische Design Anforderungsanalyse

– funktionale Anforderungen, Performanz-Anforderungen, Entwurfs-Anforderungen (z.B. mögliche Sprachen…) etc.

• Kompetenzfragen (Competency questions)

• Gruninger and Fox 1995

• Ermittlung des Anwendungsbereiches und der Anforderungen durch Fragen, z.B.

- Kann ein Student v zu Zeitpunkt w in Raum x sein, in dem Kurs y gehalten wird, für den Kurs z Voraussetzung ist?

• Können später auch als Test verwendete werden, z.B.

- Enthält die Ontologie genug Informationen um diese Typen von Fragen zu beantworten?

- Benötigen die Antworten ein bestimmtes Detaillevel oder Repräsentation in einem bestimmten Gebiet?

(10)

10

Anforderungsanalyse

• Funktionale Anforderungen für die Anwendung

• z.B. Kundenanforderungen, Funktionaledesignanforderungen

• Nicht-funktionale Eigenschaften für die Entwicklung

• individualizability/customizability

• ability to make adaptations and differentiations of ontology

• composability

• ability to compose,import and integrate ontology hierarchies which are composed from modules and further submodules

• interoperability

• ability to cooperate with existing external tools, data sources and functionalities

• declarative implementability, modifyability and evolvability

• ability to declaratively implement, add or modify (unspecified) future functionality

• reusability and interchangeability

• ability to interchange and (re)-use ontologymodules in different target environments and by different entities (collaborative humans, agents, services)

AG Corporate Semantic Web

(11)

11

Anforderungsanalyse

•

Nicht-funktionale Eigenschaften zur Laufzeit

• active adaptability and user-defined configurability

• ability to adapt to changed situations

• usability

• ability for the users (humans or machines) to easily use the ontology

• understandability and explanation

• ability of the users (humans or machines) to easily understand produced results from the ontology

• efficiency

• adequated performance

• scalability

• ability of the ontology system to grow in size

• correctness

• absolute ability to derive the correct conclusions

• robustness

• "reasonable" behavior in unforeseen circumstances and incomplete knowledge

• safety

• fault and conflict tolerance, information hiding (need-to-know principle) etc.

• verifiability and validation

• ability to analyze the correctness AG Corporate Semantic Web

(12)

12

Ontology Engineering Phasen

• Anforderungen und Analyse

• Design und

Implementierung

• Testen und Validierung

• Wartung und Pflege

(13)

13

Ontology Design

• Design

• z.B. Design Patterns

–

Best Practices für Ontology Design

–

generalisierte Darstellungen von

Konzeptbeziehungen (z.B. AgentRole)

• Implementierung

– Entwicklung einer Ontologie mit Hilfe eines Werkzeugs in einer bestimmten

Ontologiesprache

• Evaluierung

– Auswertung, wie gut die Anforderungen durch

die Ontologie erfüllt werden (Sehr komplexe

Fragestellung!)

(14)

14

Designkriterien

AG Corporate Semantic Web

Regeln oder

quantifizierbares

exogenes Wissen über den Geschäfts-

/Anwendungskontext, z.B. Gesetze

Wahlmöglichkeiten die durch den

Ontologiedesigner , z.B.

Modularisierung,

Repräsentationssprache etc.

Domänenwissen, das nicht direkt bestimmt oder formal

repräsentiert werden kann, z.B. Vertrauen, Ethische Standards, etc.

Fakten die im Ontologie Engineering Prozess

erfasst werden, z.B.

Kosten und Aufwand, Reduzierung von

Fehlern, Erhöhung der Performanz, etc.

Exogene Kriterien Endogene Kriterien

Explizite Kriterien

Implizite Kriterien

(15)

15

Arten von Designkriterien

• Exogene Kriterien

• Von außen durch den Geschäftskontext vorgegeben

• Können nicht vom Designer geändert werden

• Endogene Kriterien

• Wahlmöglichkeiten und Parameter welche direkt im Design gewählt werden können

• Explizite Kriterien

• Können direkt spezifiziert und quantifiziert werden

• Implizite Kriterien

• Bewerten die Konsequenzen von expliziten Kriterien

• Werden nicht niedergeschrieben sondern zur Laufzeit einer Ontologie / Ontologie-basierten Systems bestimmt

(16)

16

Design Phasen

• Anforderungsanalysephase

•

Erfassung der Notwendigkeiten und Wünsche als mehr oder weniger formales Set an Anforderungen und Beschränkungen

• Synthesis Phase

•

Transformation und Nutzung der Anforderungen in

der Syntesis Phase für das Design der Ontologie

(17)

17

Ontology Design

• Anforderungsanalysephase

– funktionale Anforderungen, Performanz-Anforderungen, Entwurfs-Anforderungen (z.B. mögliche Sprachen…) etc.

• Kompetenzfragen (Competency Questions)

– Liste von Fragen, die eine Knowledge Base beantworten können muss

– Kann ein Student v zu Zeitpunkt w in Raum x sein, in dem Kurs y gehalten wird, für den Kurs z Voraussetzung ist?

• Synthesisphase

• Konzeptualisierung

– Identifikation von Kerntermen aus den CQ

– Festlegung als Konzepte in Form von ersten Ontologieklassen

(18)

18

Design und Implementierung:

Patterns und Wiederverwendung

• Design Pattern: Nutzung erfolgreicher Entwurfsmuster

• Metaphor / Wiederverwendung: Transformation aus bestehenden Ontologien

• Komposition: Transformation und Kombination mehrer kleiner Ontologien

Gemeinsame Features

Ontologie 1 Ontologie 2

Kombinierte Ontologie

(19)

19

(I) Beispiel Designentscheidung:

Ontologiemodularisierung

(20)

20

Motivation für Modularisierung

• Wiederverwendung von relevanten Teilen bereits bestehender Ontologien

• Einfachere Wartbarkeit bei geeignet gewählter Modulgröße

• Effizientere Nutzbarkeit (verkürzen der Inferenzzeit)

• Verbessern der Verständlichkeit für den

Menschen

(21)

21

Verständnis von Modularisierung

• Modularer Entwurf

• Während der Entwicklung werden Ontologien modular aufgebaut

• Modulextraktion

• ein bestimmter Teil einer bestehenden Ontologie wird extrahiert

• Partitionierung

• eine bestehende Ontologie wird in

kleinere Partitionen zerlegt

(22)

22

Modularer Entwurf

• Vertikale Aufteilung nach Abstraktion

• Horizontale Aufteilung nach inhaltlichen Schwerpunkten

Core Ontology Domain Ontology Application Ontology

Domain 1 Domain 2 ….. Domain 3

(23)

23 Integrierte Sicht

Modulare Aufteilung von Ontologien

• Ontologieentwicklung und –modifikation durch nicht- Experten erfordert Unterteilung in überschaubare Module und Integration der Module zu einer

konsistenten Gesamtsicht

• Integration vs. Import von Ontologie Modulen

• Wie löst man mit minimalen Aufwand Inkonsistenzen zwischen asynchron (weiter-)entwickelten Modulen auf?

Modul 1 …

… Modul n

Modul 2

Modul n-1

(24)

24

Modul Extraktion und Partitionierung (1)

• Formaler Ansatz

• Eine Ontologie M ist ein Modul einer

Ontologie O über ein Subvokabular SV, wenn sich aus M alle Fakten über SV herleiten

lassen, die sich auch aus O über SV herleiten

lassen.

(25)

25

Modulextraktion und Partitionierung (2)

• Grafentheoretischer Ansatz

• Betrachte die Ontologie als Graph, identifiziere durch grafentheoretische Ansätze

zusammengehörige Teilgrafen und extrahiere

diese

(26)

26

(II) Beispiel Designentscheidung:

Metaphor/Wiederverwendung

(Ontology Reuse)

(27)

27

Ontology Re-Use

•

^Suche

– Bestehende Ontologien finden, die ähnliche oder gleiche Begriffe enthalten, wie man selbst anhand der CQ

spezifiziert hat

– Suchmaschine: http://watson.kmi.open.ac.uk/WatsonWUI/

(Plug-Ins für Editoren verfügbar)

•

Evaluierung

– Habe ich die beste Ontologie zur wiederverwendung für meine Anforderungen gefunden?

•

Integration

– Verwendung der gefundenen und gewählten Ontologien in der eigenen (z.B. mittels owl:import)

– Verwendung von Teilen fremder Ontologien durch Refactoring und „Nachmodellierung“

(28)

28

Beispiel: Wiederverwendung mit Refactoring

•

Refactoring

• Manuelle oder automatisierte Strukturverbesserung der

Ontologie(n) unter Beibehaltung der Funktionalität und Features

•

Refactoring ist sowohl in der Design als auch Implementierung wichtig

•

Kann genutzt werden um bestehende Ontologien für einen neuen (Anwendungs-)Kontext zu “refaktorisieren”

• oder auch um neue verbesserte Versionen zu erstellen

•

^Beispiele

• Verschieben von Methoden von einer Klasse zur anderen

• z.B. von Subklasse zur Superklasse oder von einer Klasse in Ontologie 1 zu Ontologie 2

• Reifizierung und Rereifizierung: Veränderung der Beziehungen in Klassen oder umgekehrt

• Metalevel Shifting, z.B. durch Reflection

(29)

29

Beispiel für Refactoring

(30)

30

Beispiel für Reifizierung

(31)

31

Ontologieevolution

• Reuse and Refactoring führt häufig zu Ontologieversionen

• Unterschiedliche Anwendungen benötigen

unterschiedlich modellierte Ontologien über die gleiche Domäne

• Wie erhält man die Konsistenz bezüglich gemeinsamer Fakten in asynchron entwickelten Ontologieversionen?

Iteration Iteration n

... n-1 Iteration

Iteration 2 1

Version 1

Version 4

Version Version 3 3.1

Version 2.x Version 1 Version 1

Version 1

Version 2 Version 2.1

(32)

32

Ontologieversionierung

• Ontology Diff/Semantic Diff

– Unterschiedlich strukturierte Dateien können die gleiche Semantik haben

– Komplexes Problem des Branch & Merge (vgl.

SVN macht reinen Text Diff von Sourcecode)

• Lokale Instanz vs. Verteilte Instanz

– Problem, wenn annotierte Daten (Instanzen) unabhängig vom Schema an einem beliebigen Ort vorliegen

– Ändert sich das Schema, können unbekannt viele Instanzen plötzlich inkonsistent oder inhaltlich

falsch sein

(33)

33

(III) Beispiel Designentscheidung:

Design Patterns

(34)

34

Design Pattern

Definition

„Ein Entwurfsmuster beschreibt ein bestimmtes, in einem

gegebenen Kontext immer wiederkehrendes Entwurfsproblem, sowie ein vorgegebenes Schema zu seiner Lösung“

(E. Gamma)

(35)

35

Definitionen (2)

„A pattern is the abstraction from a

concrete form which keeps recurring in specific non-arbitrary contexts.“

(D. Riehle and H. Zullighoven: “Understanding and Using Patterns in Software Development”)

“A design pattern addresses a recurring

design problem that arises in specific design situations and presents a solution to it”

(Buschmann, et. al. 1996)

(36)

36

Design Patterns

• Beschreiben eine vorgeschlagene Lösung eines wiederkehrenden Entwurfsproblems

• Verbreitetes Mittel um Wissen über

erfolgreiche Designs explizit zu erfassen und zu transferieren.

• Semi-formalisierte Spezifikation von

Lösungen zu bestimmten Problemklassen

(37)

37

Pattern Sprachen (vereinfacht)

NameA name used for identification Problem

A repeating problem that occurs in a domain

Solution

Best practice solution to that problem

Consequences

Advantages and disadvantages of the recommended solution

Examples

A few examples where the recommended solution has already been applied

Name

A succinct name to convey the essence of the anti-pattern

Problem / Bad solution

The commonly occurring mistake or bad solution that relates to the anti-pattern Symptoms

The indications or signs of the problem Consequences

The results of applying this anti-pattern Root cause

This provides the context for the anti- pattern, that is, where a pattern was applied incorrectly and resulting in a problem or failed solution

Suggested solution(s)

Refactored solution that solves the problem and ensures more benefits

Pattern Anti-Pattern

(38)

38

Beispiel: Pattern Struktur

Name Intent

Describes the underlying problem and the basic principle of the design solution.

Also Known As

Other names of the pattern, if existing.

Motivation

Depicts a scenario of a concrete design problem and gives a solution.

Applicability

Itemizes the situations or conditions, in which the pattern can be applied.

- Characteristics - Resources

- Other environmental factors Structure

Participants

Lists the classes and objects, which are described by the design pattern.

Consequences

Discusses the advantages and disadvantages of the pattern, and makes suggestions about variations.

Variants

Brief description of variants, extensions or specializations of the design pattern.

Known Uses

Examples of applications, in which the design pattern is used.

Related Patterns

Lists patterns, which describe a similar task, and shows the relations to other patterns.

Adapted from Gamma, E., et al., Design Patterns - Elements of Reusable Software. 1995: Addison-Wesley.

(39)

39

Refactoring Pattern „Smells“

Name

Name of refactoring

Addresses

Problem addressed

Description

General description

Ontology before refactoring

Example ontology

Ontology after refactoring

Refactored ontology

Beispiele „Smell Patterns“

• Redundancy

•redundante Konzepte / Graphfragmente in einem Set von Ontologien welche zusammengeführt werden sollen

• Inconsistencies

• Incompleteness – bestimmte Anfragen können nicht beantwortet werden

• Unused – bestimmte Teile der Ontologie werden nie benützt

(40)

40

Ontology Development Implementation

• Formale Methoden

•

z.B. METHONTOLOGY, OnToKnowledge, NeOn Methodology

• Benutzer-fokusierte Methoden

•

z.B. DILIGENT, HCOME

• Kollaborative Methoden

• Agile Methoden

• z. B. COLM, RapidOWL

• Automatisierte Lernmethoden

• z.B.

• Nathalie Aussenac-Gilles, Brigitte Biébow, Sylvie Szulman: Revisiting Ontology Design: A Method Based on Corpus Analysis

• Paola VELARDI, Roberto NAVIGLI, Alessandro CUCCHIARELLI and Francesca NERI:

Evaluation of OntoLearn, a methodology for automatic learning of domain ontologies

• Paola Velardi, Raúl Poler, José Vicente Tomás: Methodology for the definition of a glossary in a collaborative research project and its application to a European Network of Excellence

(41)

41

Ontology Development

Theoretisch formale Methoden

• Expertenorientiert

• Betrachten den Prozess und alle Aufgaben streng und integrativ

• Eher langläufig und wenig agil

• Betrachten die Ontologieentwicklung anwendungsabhängig oder wenigstens anwendungsteilabhängig

• z.B. METHONTOLOGY, OnToKnowledge,

NeOn Methodology

(42)

42

User-zentrierte Methoden

• fokussieren divers vorgebildete Benutzer und unkontrollierte Verteiltheit

• senken das Abstraktionsniveau durch formale Argumentationsmodelle zur Konsensbildung

• dynamisch

• Betrachten die Ontologieentwicklung Anwendungsunabhängig

• z.B. DILIGENT, HCOME

(43)

43

Agile Methodiken

• fokussieren divers vorgebildete Benutzer (insbes. nicht-Experten)

• Akzeptieren und behandeln häufig

auftretende Änderungen der Anforderungen und des Wissens

• Hochgradig dynamisch

• z.B. RapidOWL, COLM

(44)

44

Kollaborative Methoden

Idee aus Folksonomies: Tagging Tags

car

user1

user2

user3

wheels

wheel travel

vehicle

Presented at ISWC2007

Entwicklung kollektiver Wissenspfade als Basis für eine Ontologie

(45)

45

Extreme Tagging Ansatz

• Extreme Tagging System ist eine Folksonomie.

Idee beschrieben in:

Vlad Tanasescu, Olga Streibel Extreme Tagging: Emergent Semantics through the Tagging of Tags ESOE bei ISWC2007

• Ein Extreme Tagging System erlaubt das Tagging der Tags und der Relationen zwischen diesen

Tags.

• Ein Extreme Tagging System wird zurzeit für

Public Web als Facebook-Applikation realisiert

(noch nicht freigegeben für alle Facebooknutzer,

verstärkt für Geo-Domäne getestet)

(46)

46

Idee: Tagging Tags

car

user1

user2

user3

wheels

wheel travel

vehicle

(47)

47

Idee: Tagging Tags

car

wheels

wheel travel

vehicle is-a

has

singular-of

user4

user6

user5

(48)

48

Idee: Tagging Tags

car

wheels

wheel travel

vehicle is-a

has

singular-of

(49)

49

Experiment mit 5 Personen

Thanks to F. Badra O.Streibel V.Tanasescu K.Wang Y.Wang

(50)

50

Example: tagging tag relations

(51)

51

Example: tagging tag relations

(52)

52

Example: tagging tag relations

(53)

53

Example: tagging tag relations

(54)

54

Example: tagging tag relations

(55)

55

Example: tagging tag relations

(56)

56

Kollektive Wissenspfade

(57)

57

Kollektive Wissenspfade

Wissenspfade sind Basis für eine Ontologieentwicklung

(58)

58

Ontology Learning

(59)

59

28.01.2009

Ontology Learning

Vision : Erkennung des “Weltmodels”

(60)

60

Ontology Learning Layer Cake

(61)

61

Term Extraktion

Bestimmte die relvantesten Phrasen als Terme

•

Linguistische Methoden

• Regeln über linguistisch analysierten Text

• Linguistische Analyse – Part-of-Speech Tagging, Morphological Analysis, Phrase Recognition

• Extraktion von Patterns – Adj-Noun, Noun-Noun, Adj-Noun-Noun  Adj*Noun*

•

Statistische Methoden

• Co-occurrence (collocation) Analyse für die Termextraktion in einem Corpus

• Vergleich von Vorkommen zwischen Domänen und in generellen Textcorpora

•

Hybride Methoden

• Linguistische Regeln

• Statistische (pre- oder post-) Filtering

(62)

62

Ontology Learning Layer Cake

(63)

63

Multilinguale Synonyme

• Finde die Terme die (teil) Semantik teilen,

d.h. Potentiell dasselben Konzept referenzieren

• Synonyme (innerhalb von Sprachen)

• Finde Termpaare mit gleicher Bedeutung

• doctor, medic, physician

• person, patient, subject (domain: clinical trials)

• Übersetzung (zwischen Sprachen)

• Wörterbucher

• doctor, Arzt, médico

• Bilinguale (parallele) Corpora, vergleichbare Corpora z.B. Dokumente welche ähnliches Vokabular in einem gleichen Kontext verwenden

• Beispiel: Zeitungsartikel, Magazine in unterschiedlichen Sprachen

(64)

64

Ontology Learning Layer Cake

(65)

65

Concepts: Intension, Extension, Lexicon

•

A term may indicate a concept, if we can define its

• Intension

• (in)formal definition of the set of objects that this concept describes

• a disease is an impairment of health or a condition of abnormal functioning

• Extension

• a set of objects (instances) that the definition of this concept describes

• influenza, cancer, cardiovascular disease

• Extraction of instances from text – referred to a Ontology Population

• Relates to Knowledge Mark-up – Tagging, Semantic Metadata

• Uses Named-Entity Recognition and Information Extraction techniques

• Lexical Realizations

• the term itself and its multilingual synonyms

• Disease, illness, Krankheit, enfermedad

(66)

66

Concepts: Discussion

• Instances can be e.g.

• Names for objects

• Names connected with events

diabetes patient A has a diabetes

patient patient A and patient B had the symptoms, while patient C seemed to be not infected

person Andrew S. Tannenbaum, Alan Turing, Andrew Z. Fire, Craig C. Mello, the person at the bar

disease with specific patient name, symptoms, date, …

(67)

67

Ontology Learning Layer Cake

(68)

68

Taxonomy Extraktion (1)

•

Lexico-syntactic patterns

• z.B. Hearst Patterns (by M. Hearst 1992) -hyponymy Patterns:

• Vehicles such as cars, trucks and bikes vehicle  car, truck, bike

• Distributional Similarity & Clustering

• Similarity-based , Set-theoretical and probabilistic clustering, Soft clustering

• Linguistische Ansätze

• Dokumentsubsumption

• Subsumption von Termen

• A term t1 subsumes a term t2, i.e. is-a(t2,t1) if t1 appears in all the documents in which t2 appears

(69)

69

Taxonomy Extraktion (2)

• Taxonomy Extension/Refinement

• Kombinationen

(70)

70

Ontology Learning Layer Cake

(71)

71

Idee:

Patterns vom Sentence alignments

• Vom Web mining zum Semantic Web:

Automatische Extraktion von Triples

• Wie können Triples (Relationen) vom Text extrahiert werden?

• ^Idee

• Definiere zwei Lexika (für Subjekt und Objekt)

• Finde Sätze wo Subjekt und Objekt zusammen vorkommen

• Align und Cluster die Sätze

• Leite reguläre Ausdrücke ab um Subjekt Prädikat Objekt Triples zu extrahieren

(72)

72

Idee: Align Sentences

.. P suppressed P ..

.. P helps regulate P ..

.. P recruits the adapter molecule P ..

.. P binding domain of P ..

.. P binds directly to the extracellular domain of P ..

.. P associates with a novel P dependent kinase, P ..

.. while P activation reduces P expression/activation ..

.. P was previously found to interact with the KRAB silencing domain of P and with the P ..

(73)

73

Multiples Sentence Alignment

Initial Phrase:

protein strongly binds to protein

protein interacts with the protein

protein never binds to protein

protein regulates the protein

protein inhibits a protein

Konsenspattern:

PROTEIN {strongly,never} {binds, .., ..} {to, with} {the, a} PROTEIN

Würde exakt mit diesem Satz matchen (Ausschnitt):

protein binds to the protein

(74)

74

Aligning von Sequenzen

•

Levenstein Distance

• Minimale Anzahl von insert/delete Operationen um einen String A in B zu konvertieren

• Longest common subsequence (Lcs)

• Lcs(A,empty) = 0

• Lcs(empty,B)=0

• Lcs(aA,bB) = max{ Lcs(A,bB), Lcs(aA,B),

Lcs(A,B)+1 if a=b }

•

Automatisierung beispielsweise durch Einsatz von Dynamische Programmierung

• Dynamische Programmierung ist eine generelle Technik, welche Probleme durch Zerlegung in Teilprobleme und rekursive Lösung löst

(75)

75

Ontology Learning Layer Cake

(76)

76

Induktive Logik Programmierung

• Deduktion

• aus gegebenen Voraussetzungen schließen

• z.B. "Sokrates ist sterblich" und "Sokrates ist ein Mensch", Konklusion

"Alle Menschen sind sterblich

• Induktion

• Gegenbegriff zur Deduktion

• Induktionslogik befasst sich mit der Frage, ob es ein gültiges Schema gibt, das aus einzelnen Beobachtungen und Fakten auf allgemeine Aussagen schließen lässt.

•

Deduktive Logik Programmierung

• Spezialisierung mittels Anfragen (Goals) bis zum Beweis

•

Induktive Logic Programmierung

• Aus den gegebenen Fakten die gültigen Axiome (Regeln) schließen (Generalisierung)

(77)

77

5694(8756334).

7389(8756334).

16444(8756334).

30234(8756334).

32330(8756334).

32332(8756334).

48532(8756334).

51179(8756334).

5694(2850480).

35282(2850480).

35284(2850480).

50000(2850480).

51179(2850480).

51304(2850480).

7165(15337316).

...

19089(1797745).

42405(1797745).

5694(2575183).

7588(2575183).

7349(2434114).

9405(2434114).

9986(2434114).

16020(2434114).

51050(2434114).

30252(1016017).

30431(1016017).

46879(1016017).

1967(2402276).

32502(1843563).

48479(1843563).

...

Positive Examples Negative Examples

lgg(Term1,Term2,LGG) :-

compute_lgg([Term1],[Term2],[LGG],[],Subst),

!.

compute_lgg([],[],[],Subst,Subst).

compute_lgg([Head1|Tail1],[Head2|Tail2],[Head3|Tail3],Sub st1,Subst3) :-

bound(Head1), % is constant bound(Head2), % is constant Head1=Head2,

Head3=Head1,

compute_lgg(Tail1,Tail2,Tail3,Subst2,Subst3), !. … Prova ILP Program

development(X) :- chromosome(X),

embryonic_development(X), signal_transduction(X).

Coverage=0.3

development(X) :- embryonic_development(X), chromosome(X), signal_transduction(X).

Coverage=0.3

development(X) :- signal_transduction(X), chromosome(X), embryonic_development(X).

Coverage=0.3

Learned Classifier Rules

GO:0005692 snRNP U11 GO:0005693 snRNP U12 GO:0005694 chromosome GO:0005695 chromatid GO:0005696 telomere

Gene Ontology

Beispiel: Gelernte Axiome aus annotierten Daten von PubMed Literaturdatenbank

(78)

78

Zusammenfassung:

Ontology Learning Layer Cake

Einsatz von Web Mining Methoden zum Lernen von Konzepten

Hoher Automatisierungsgrad

Lernen von Axiomen, Relationen und auch

Taxonomien benötigt Hintergrundwissen über z.B.

Anwendungsdomäne, Benutzer etc., Iterative Rückmeldung des Ontology Engineers (z.B. als

„Orakle“ im ILP)

Daher häufig nur Semi-Automatisierung, z.B.

Vorschlagen von Konzepten und Relationen für einen Ontologie – Ontology Engineer entscheidet

(79)

79

Ontology Engineering Phasen

• Anforderungen und Analyse

• Design und

Implementierung

• Testen und Validierung

• Wartung und Pflege

(80)

80

Grundlagen

Test & Validierung

•

Validierung ob Anforderungen erfüllt

•

Testen der Korrektheit, Konistenz etc.

•

V&V&I Pattern:

Validation: ”Entwickeln wir das richtige Programm/Ontologie?”

Verification: ”Entwickeln wir das Programm/Ontologie richtig?”

Integrity: ”Führen wir das Programm/Ontologie richtig aus?”

•

Fehler und Anomalien

• Fehler sind Probleme welche direkt die Ausführung von Ontologien beeinflussen, z.B. Unvollständigkeit, Wiedersprüche, …

• Anomalien sind Symptome von wirklichen Fehlern

•

Taxonomy of Anomalies (Preece and Shinghal)

• Semantische Überprüfung z.B. Konsistenz, Vollständigkeit

• Strukturelle Überprüfung, z.B. Redundanz, Relevanz, Erreichbarkeit

(81)

81

Test-driven Development Feedback Loop

Modeling:

Update Test Cases

Refactoring:

Optimize/Extend Ontology Rules

V&V Testing:

Execute Test Cases + Test Coverage Release

Ontology Program Requirements

feedback

success

failure

often 80-20 success rate

(82)

82

Ontology Maintenance

• Population (Instanzerzeugung)

– neue Ausprägungen zu Konzepten erzeugen (z.B. füge Ferrari als Instanz zu Sportwagen ein)

– unschädliche Änderung

• Schema-Updates

– Neue Klassen oder Beziehungen einfügen

– unschädlich, weil alte Instanzen wenigstens noch

schematisch konsistent dargestellt sind (ob dieses Wissen noch „vollständig richtig“ ist muss Mensch analysieren)

– Klassen oder Beziehungen ändern oder löschen

– gefährlich, weil alte Instanzen nun Inkonsistent sein können

(83)

83

Ontologie Engineering Lebenszyklen

• Möglich sind alle aus dem Software Engineering bekannten Modelle

• Sequentielle Modelle – Wasserfallmodell – V-Modell

• Iterative Modelle – Spiral Modell

• Agile Methoden

– haben grundsätzlich keinen echten

Lebenszyklus sind aber streng iterativ

(84)

84

Probleme des Ontology Engineering

• Methodiken zum Ontology Engineering

• Vernachlässigen die tatsächliche Dynamik von Wissen

• Wissen ist nie vollständig und ändert sich potentiell häufig

• Ignorieren ökonomische Aspekte

• Ontologieentwicklung tritt in den seltensten Fällen nur der Ontologie wegen auf sondern in Verbindung mit

Softwareentwicklung

(85)

85

Lehren aus dem Software Engineering

•

Unterschiedliche SE Ansätze und Methoden

1. „Schwergewichtige“ Ansätze

• z.B. Wasserfall-Model, V-Model

• Führen zu hohen Änderungskosten

• Können dynamische Verhalten nicht überprüfen und Interaktionen zwischen dynamisch geänderten und ausgetauschten Ontologien

2. Einfaches strukturelles / Operationales Debugging

• Führen Ontologie-Programm aus und überwachen Ausführungsablauf (execution trace)

• Hohe kognitive Belastung und tiefes Verständnis der zugrunde liegenden Prozesse auf Seiten des Entwicklers nötig

3. Model Checking, Algebraisch, Graph-basiert, Petri-Net-basierte Methoden

• z.B. Petri-Nets, Process Algebras, ACTL

• Sehr Rechen-aufwendig

• Setzen tiefes Verständnis beider Domänen voraus: Ontologieprache und Testsprache / Verifikationsmodelle

• Oft weitaus komplexer als die Ontologie oder das Ontologie-basierte Programm selbst

(86)

86

Corporate Ontology Lifecycle Methodology – COLM

• Adressiert das Problem der versteckten Kosten von Ontology Maintenance

• 80% der Kosten im Software Engineering (SE) sind Kosten für Maintenance!

• Ist dieser Effekt ist im Ontology Engineering auch zu erwarten?

• Betrachtet man ONTOCOM im Bezug auf andere Ontology Engineering Methodiken, so ist die Kostenentwicklung linear

(87)

87

COLM

• Iterativer Lebenszyklus

• Rapid Prototyping auf Basis einer günstigen Grundontologie

• Verfeinerung des Prototyps durch Feedback-Sammlung

• Änderungen erfolgen nur, wenn günstiges Kosten-

Nutzen-Verhältnis

(88)

88

Selection/Integration/Develop ment

Evaluation Validation

Feedback

Tracking Population

Deployme nt

Reporting

ENGINEERING

USAGE

COLM

Nutzungsbeobachtung

• Nutzung der Ontologie

• Verhalten im gesamten Kontextumfeld

Berichterstattung

• Auswertung eines neuen Konsensmodells

• Darstellung der Differenz

Annotierung

• (semi-)automatisch mit Werkzeugunterst.

• durch Benutzer

Ausbringung

• Verteilung der Version in der Infrastruktur

• Push vs. Pull

Qualitätssicherung

• Anforderungen der

• Domäne

• Anwendung

Auswertung

• Was ist falsch/schwach?

• Was ist neu?

• …

Entscheidungsprozess

• Entwicklungsauftrag

• Wiederverwendung

• Eigenentwicklung

(89)

89

COLM

• Reduziert den Bedarf nach Ontologie- ingenieuren

• Unterstützung von bekannten

Methoden (z.B.

SVN, Test-driven Development)

• Explizite Trennung in Engineering und Usage

• Erreicht

Transparenz der

„teuren“ Phasen

(90)

90

SCRUM für Ontologie Projekte

• Einer der „agilen Prozesse“

• Selbst-Organisierende Teams

• Ontologieprodukt schreitet in Serien von monatlichen “Sprints” fort

• Anforderungen sind als Listeneinträge im “Produkt- Backlog” festgehalten

• Keine spezifischen Entwicklungsvorgehen vorgeschrieben

• Benutzt generative Regeln um ein agiles Umfeld für die Auslieferung von Ontologien /

Ontologieprodukten zu schaffen

(91)

91

Sequentielle vs.

überlappende Entwicklung

Requirements Design Code Test

(92)

92

SCRUM Überblick

(93)

93

Sprints

• Scrum-Projekte schreiten in Serien von “Sprints” voran

• Analog zu XP-Iterationen

• Angestrebte Dauer ist ein Monat

• +/- ein oder zwei Wochen

• Eine konstante Dauer führt zu einem besseren Rhythmus

• Die Ontologie wird während des Sprints entworfen,

kodiert und getestet

(94)

94

Probleme des Ontology Engineering

• Methodiken zum Ontology Engineering

• Vernachlässigen die tatsächliche Dynamik von Wissen

• Wissen ist nie vollständig und ändert sich potentiell häufig

• Ignorieren ökonomische Aspekte

• Ontologieentwicklung tritt in den seltensten Fällen nur der Ontologie wegen auf sondern in Verbindung mit

Softwareentwicklung

(95)

95

Ontologie Kostenmodelle

• Dienen zur Abschätzung der Kosten für die Entwicklung und Pflege einer Ontologie

• Aber: Ohne zusätzliche Nutzenmodelle wirtschaftlich fast

wertlos

(96)

96

ONTOlogy COst Model – ONTOCOM

• Identifikation von “Cost Drivers” durch Studien, Interviews und empirische Analysen

• Adoptiert Ideen von COCOMO II (COnstructive COst

Model) aus dem Software Engineering

(97)

97

Product-related cost drivers I

•

Cost drivers for ontology building

•

Domain Analysis Complexity (DCPLX)

– Application setting influencing the complexity of the engineering outcomes

•

Conceptualization Complexity (CCPLX)

– Impact of a complex conceptual model

•

Implementation Complexity (ICPLX)

– Efforts arisen from the usage of a specific implementation language

•

Instantiation Complexity (DATA)

– Effects of the instance data requirements

•

Required Reusability (REUSE)

– Effort to develop a reusable ontology

•

Complexity of Ontology Evaluation (OE)

– Efforts invested in generating test cases and evaluating test results

•

Complexity of Ontology Integration (OI)

– Effort to integrate ontologies

•

Documentation (DOCU)

– Costs caused by high documentation requirements

(98)

98

Product-related cost drivers II

•

Cost drivers for reuse and maintenance

•

Complexity of the Ontology Evaluation (OE)

– Efforts invested in analyzing an ontology w.r.t project requirements

•

Complexity of the Ontology Modifications (OM)

– Costs caused by modifying an ontology to use it in the project

•

Ontology Translation (OT)

– Cost to translate an ontology to the language used in the project

•

Ontology Understanding (OU)

– Efforts invested to understand the concepts and relationships in an ontology

•

Ontologist/Domain Expert Unfamiliarity (UNFM)

– Efforts invested to get familiar with an application domain

(99)

99

Personnel-related cost drivers

• Role of team experience, ability, and continuity of the engineering process

• Ontologist/Domain Expert Capability (OCAP/DECAP)

– Ability and efficiency of the single actors involved in the

process (ontologist and domain expert) as well as their teamwork capabilities

• Ontologist/Domain Expert Experience (OEXP/DEEXP)

– Experience of the engineering team w.r.t. performing

ontology engineering activities

• Language/Tool Experience (LEXP/TEXP)

– experience of the project team w.r.t. the representation language and the ontology management tools

• Personnel Continuity (PCON)

– frequency of the personnel changes in the team

(100)

100

Project-related cost drivers

• Characteristics of an ontology engineering process

• Support tools for Ontology Engineering (TOOL)

– Effect of using ontology management tools in the

engineering process

• Multisite Development (SITE)

– Usage of the communication support tools in a location- distributed team

(101)

101

Calculating the costs

• Size of the ontology is a key cost factor

• Effort Multipliers

• Modify the costs of ontology development

• Correspond to cost drivers

• Initially assignments followed by calibration

• Example: Expertise with ontology language (LEXP)

Very low Low Nominal High Very high LEXP 2 month 6 month 1 year 3 years 6 years

EM 1.6 1.3 1.0 0.9 0.8

rating levels decision criteria effort multipliers

(102)

102

Cost model

PM = Person Month

PM

_Task

**= A * OntoSize**

^B

* Π EffortMultiplier

• PM = 2 * 1.5^0.9 * (1.6 * 0.6 * 1.3) = 3.6

– A = 2 PM (baseline calibration constant) – Size = 1.5 (in kilo entities)

– B = 0.9 (larger ontologies are cheaper) – EM₁ = 1.6 (e.g. LEXP, 2 months exp.)

– EM₂ = 0.6 – EM₃ = 1.3

(103)

103

Total costs

PM

_B

PM

_R

PM

_M

PM

B = Build R = Reuse

M = Maintenance

(104)

105

Referenzen

Cristani, M; Cuel, R.: A Survey on Ontology Creation Methodologies

Paul Buitelaar, Philipp Cimiano, Marko Grobelnik, Michael Sintek: Ontology Learning from Text. Tutorial at ECML/PKDD, Oct. 2005, Porto, Portugal.

Steffen Staab: Ontology Learning, Inaugural workshop of the language, interaction and computation lab, May 29, 2007, Rovereto, Italy

Links

• http://www.neon-project.org/web-

content/images/Publications/neonglossaryofactivities.pdf

• http://www.neon-toolkit.org/

• http://protege.stanford.edu/

• http://ontologydesignpatterns.org

• http://ontocom.sti-innsbruck.at/

• http://www.corporate-semantic-web.de/

• http://www.aifb.uni-karlsruhe.de/WBS/cte/ontologyengineering/

(105)

106