Ontologiegestütztes Case-Based Reasoning

Stefan Beißel Ontologiegestütztes Case-Based Reasoning

GABLER RESEARCH Information – Organisation – Produktion Herausgegeben von Professor Dr. Hans Corsten, Professor Dr. Michael Reiß, Professor Dr. Claus Steinle und Professor Dr. Stephan Zelewski

Die Schriftenreihe präsentiert Konzepte, Modelle und Methoden zu drei zentralen Domänen der Unternehmensführung. Information, Organisation und Produktion werden als Bausteine eines integriert angelegten Managementsystems verstanden. Der Erforschung dieses Bereiches dienen sowohl theoretische als auch anwendungsorientierte Beiträge.

Stefan Beißel

Ontologiegestütztes Case-Based Reasoning Entwicklung und Beurteilung semantischer Ähnlichkeitsindikatoren für die Wiederverwendung natürlichsprachlich repräsentierten Projektwissens Mit einem Geleitwort von Univ.-Prof. Dr. Stephan Zelewski

RESEARCH

Bibliografische Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über abrufbar.

Dissertation Universität Duisburg-Essen, 2011

1. Auflage 2011 Alle Rechte vorbehalten © Gabler Verlag | Springer Fachmedien Wiesbaden GmbH 2011 Lektorat: Stefanie Brich | Nicole Schweitzer Gabler Verlag ist eine Marke von Springer Fachmedien. Springer Fachmedien ist Teil der Fachverlagsgruppe Springer Science+Business Media. www.gabler.de Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlags unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen. Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften. Umschlaggestaltung: KünkelLopka Medienentwicklung, Heidelberg Gedruckt auf säurefreiem und chlorfrei gebleichtem Papier Printed in Germany ISBN 978-3-8349-3064-4

Geleitwort

V

Geleitwort Das Werk von Herrn Dr. Beißel befasst sich mit einem herausfordernden Problemkomplex, der an der Nahtstelle zwischen Betriebswirtschaftslehre, Wirtschaftsinformatik und Informatik – letztgenannte einschließlich der Erforschung Künstlicher Intelligenz (KI) – angesiedelt ist. Aus betriebswirtschaftlicher Sicht behandelt der Autor ein zentrales Realproblem des Projektmanagements. Es betrifft die Schwierigkeit, zur Vorbereitung (z. B. im Rahmen der Teilnahme an Projektausschreibungen), zur Durchführung und auch zur Kontrolle von neuen Projekten dasjenige Wissen zu nutzen, das über bereits durchgeführte, ältere Projekte in durchaus beachtlichem Umfang zur Verfügung steht. Als Barrieren gegenüber der Wiederverwendung von „an sich“ verfügbarem Projektwissen erweisen sich vor allem zwei Aspekte. Einerseits erreicht das Wissen, das über bereits durchgeführte Projekte sowohl im eigenen Unternehmen als auch in branchenweit oder öffentlich zugänglichen Publikationen grundsätzlich vorhanden ist, oftmals einen derart großem Umfang, dass es von den zuständigen Mitarbeitern eines Unternehmens in „vertretbaren“ Zeiträumen von einigen Stunden oder Tagen bei Weitem nicht vollständig ausgewertet werden kann. Andererseits scheitert der Einsatz der Automatischen Informationsverarbeitung in der Regel daran, dass das einschlägige Wissen über bereits durchgeführte Projekte zum großen Teil in natürlichsprachlicher Form repräsentiert wird, wie z. B. in „Projektberichten“, „Business Cases“ und Protokollen von „Debriefings“. Aus den vorgenannten Gründen stellt es ein betriebswirtschaftliches Desiderat dar, umfangreiches und großenteils natürlichsprachlich repräsentiertes Wissen über alte Projekte computergestützt auswerten und auf neue Projekte anwenden zu können. Die konventionellen Techniken, die seitens der Wirtschaftsinformatik und der Informatik zur Bewältigung solcher Wissensverarbeitungsprobleme angeboten werden, reichen jedoch für die oben skizzierte Aufgabe des Managements von Projektwissen nicht aus. Zu solchen konventionellen Techniken zählen beispielsweise Text- und Dokumentenverarbeitungstechniken sowie Information-Retrieval- und Business-Intelligence-Techniken. Sie leiden alle darunter, dass sie zwar große Informationsmengen zu verarbeiten vermögen, dies jedoch lediglich auf syntaktisch-statistischer Basis. Sie sind aber nicht – zumindest derzeit noch nicht – in der Lage, komplex strukturiertes und natürlichsprachlich repräsentiertes Wissen, wie es etwa im Falle von Wissen über Projekte vorliegt, auf der semantischen Ebene mit inhaltlichem Verständnis für das jeweils repräsentierte Wissen zu verarbeiten.

VI

Geleitwort Aus der Erforschung Künstlicher Intelligenz sind zwei Techniken bekannt, die

grundsätzlich dazu geeignet sind, zwei unterschiedliche Aspekte des zuvor skizzierten Realproblems erfolgreich zu behandeln. Einerseits werden seit längerer Zeit Ontologien erforscht, die Computer in die Lage versetzen, natürlichsprachlich repräsentiertes Wissen mit inhaltlichem Verständnis auf der semantischen Ebene zu verarbeiten. Andererseits wird die Technik des Case-based Reasonings seit Längeren dafür eingesetzt, um Wissen über alte Fälle – wie z. B. Projekte – aufgrund von ähnlichkeitsbasierten Analogieschlüssen auf neue Fälle zu übertragen. Diese Technik bleibt aber in der Regel auf die Verarbeitung numerischen Wissens beschränkt, weil die essenziellen Ähnlichkeitsmetriken numerische Fallattribute vorauszusetzen scheinen. Aufgrund dieser Verschiedenartigkeit von Ontologien einerseits und Case-based Reasoning andererseits sind die beiden Techniken der Ontologien und des Case-based Reasonings bislang noch kaum miteinander kombiniert worden. Darüber hinaus haben sie auch einzeln, bis auf einige wenige „randständige“ Anwendungen außerhalb der „etablierten“ Forschungsstränge, noch keinen substanziellen Eingang in die betriebswirtschaftliche Forschung gefunden. Der Autor hat sich der großen Herausforderung gestellt, die beiden Techniken der Ontologien und des Case-based Reasonings im Rahmen des computergestützten Managements von projektbezogenem Wissen erstmals miteinander zu kombinieren. Damit hat er an der „vordersten Forschungsfront“ einen bemerkenswerten Beitrag zum betriebswirtschaftlichen Erkenntnisfortschritt geleistet. Darüber hinaus hat er mit großer Liebe zum Detail ein Konzept für ein systematisches computergestütztes Wissensmanagement als Teil des betrieblichen Projektmanagements entwickelt. Es ist dabei behilflich, den innovativen Verbund aus Ontologien und Case-based Reasoning in die Geschäftsroutinen des betrieblichen Alltags zu integrieren und unterstreicht auf diese Weise auch die hohe Praxisrelevanz der hier vorgelegten Forschungsergebnisse. Insbesondere die „intelligente“ Lösung des Problems, die Ähnlichkeit zwischen Projekten im Hinblick auf Projektwissen zu ermitteln, das zum größeren Teil nur in natürlichsprachlich repräsentierter Form vorliegt, beeindruckt durch ihren innovativen Charakter. Dazu gehört vor allem der Ansatz des Autors, implizites Ähnlichkeitswissen, das in einer natürlichsprachlichen Projektmanagement-Ontologie verborgen ist, mittels einer inhaltsbezogenen und somit semantischen „Vermessung“ von Ähnlichkeitsabständen in einer Ontologie und darauf aufbauendem Projektwissen zu explizieren. Darüber hinaus beweist der Autor eine beeindruckende Transferkompetenz, indem er seine konzeptionellen Erkenntnisse auf die prototypische Implementierung eines ontologiegestützten Case-based-

Geleitwort

VII

Reasoning-Systems erfolgreich übertragen hat. Diese gut gelungene Implementierung eines Software-Prototyps nötigt dem Verfasser dieses Geleitworts großen Respekt ab. Der Autor sollte in Erwägung ziehen, seinen Prototyp zu einer kommerziell verwertbaren, professionellen Software für die betriebliche Praxis weiterzuentwickeln oder weiterentwickeln zu lassen. Der Autor hat mit seiner hier veröffentlichten Dissertation eine hervorragende interdisziplinäre Forschungsarbeit an der Nahtstelle zwischen Betriebswirtschaftslehre, Wirtschaftsinformatik, Informatik und KI-Forschung geleistet. Seine Untersuchungen beeindrucken nicht nur durch ihren innovativen Charakter, sondern auch die profunden Sachund Methodenkenntnisse des Autors sowie seine bemerkenswerte Liebe zur Detailarbeit. Hierdurch geht der Autor weit über das hinaus, was von einer „üblichen“ betriebswirtschaftlichen Dissertation erwartet werden kann. Aus den vorgenannten Gründen ist den Ausführungen des Autors eine möglichst breite Resonanz sowohl im wissenschaftlichen Bereich als auch in der betrieblichen Praxis zu wünschen. Dies gilt nicht nur für betriebswirtschaftlich interessierte Leserinnen und Lesern aus dem engeren Anwendungsgebiet des Projektmanagements, sondern ebenso für Rezipienten aus Wirtschaftsinformatik, Informatik und KI-Forschung, die sich für betriebswirtschaftliche Anwendungen ihrer Forschungsresultate interessieren. Stephan Zelewski

Vorwort

IX

Vorwort Die vorliegende Dissertation wurde im Dezember 2010 vom Promotionsausschuss der Fakultät für Wirtschaftswissenschaften der Universität Duisburg-Essen angenommen. Die Dissertation befasst sich mit der Entwicklung einer Technik, um die Wiederverwendung von natürlichsprachlich repräsentiertem Projektwissen zu unterstützen. Bei dieser Technik handelt es sich um das ontologiegestützte Case-Based Reasoning, das die Aufgabe der Identifikation von hinreichend ähnlichen Projektfällen und Selektion von mindestens einem ähnlichsten Projektfall computergestützt durchführt. Die Machbarkeit wird anhand eines Prototyps demonstriert, der ein Ontologie-Tool und ein Case-BasedReasoning-Tool beinhaltet und für Projekte aus dem Bereich des IT-Managements angewendet wird. Die Dissertation setzt sich aus zwei Hauptbestandteilen zusammen. Im ersten Teil erfolgt eine Erläuterung der Grundlagen für die Problembearbeitung, speziell zu Projektmanagement, Ontologien und Case-Based Reasoning. Im zweiten Teil erfolgt die Planung, Entwicklung und Anwendung eines ontologiegestützten Case-Based-ReasoningSystems. An dieser Stelle möchte ich mich bei Professor Dr. Stephan Zelewski für seine umfassende Unterstützung bedanken. Seine anregenden und fachlich beeindruckenden Hinweise und Ideen waren mir stets eine große Unterstützung. Außerdem möchte ich mich bei Professor Dr. Heimo H. Adelsberger für die Erstellung des Zweitgutachtens bedanken. Mein Dank gilt auch meiner Frau Andrea für Ihre Geduld und Ermutigung. Stefan Beißel

Inhaltsverzeichnis

XI

Inhaltsverzeichnis

Abkürzungs- und Akronymverzeichnis......................................................................... XV Symbolverzeichnis.......................................................................................................... XXI Abbildungsverzeichnis................................................................................................ XXIII Tabellenverzeichnis.................................................................................................... XXVII 1

Einführung in den Problembereich technikgestützten Managements von Projektwissen............................................................................................................1

1.1

Betriebswirtschaftliches Desiderat.................................................................1

1.2

State-of-the-art der verfügbaren Techniken zur Erfüllung des betriebswirtschaftlichen Desiderats................................................................4

1.3

Wissenschaftliche Problemstellung................................................................6

1.4

Ziele der Untersuchung ................................................................................12

1.5

Aufbau der Untersuchung ............................................................................13

2

Grundlagen für die Problembearbeitung ............................................................17

2.1

Projekte und Projektmanagement als relevanter Realitätsbereich ...............17

2.2

Wissensmanagement ....................................................................................19

2.2.1

Natürlichsprachliche Repräsentation von Projektwissen .............................19

2.2.2

Definition von Wissensmanagement............................................................21

2.3

Übersicht über die Techniken für die Problemlösung..................................22

2.3.1

Ontologiestützung ........................................................................................22

2.3.1.1

Definition von Ontologien ...........................................................................22

2.3.1.2

Repräsentationssprachen ..............................................................................24

2.3.1.3

Abgrenzung von alternativen Techniken .....................................................27

2.3.1.4

Vor- und Nachteile der Ontologie für die Untersuchung .............................30

2.3.2

Case-Based Reasoning .................................................................................32

2.3.2.1

Definition von Case-Based Reasoning.........................................................32

XII

Inhaltsverzeichnis

2.3.2.2

Abgrenzung von alternativen Techniken .....................................................35

2.3.2.3

Vor- und Nachteile des Case-Based Reasonings für die Untersuchung ......37

2.3.3

Eignung des ontologiegestützten Case-Based Reasonings ..........................40

3

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen..........................................................................................................41

3.1

Definition eines Vorgehensmodells für die Erstellung des ontologiegestützten CBR-Systems ...............................................................41

3.2

Anwendung des Vorgehensmodells .............................................................48

3.2.1

Konzept des ontologiegestützten CBR-Systems ..........................................48

3.2.1.1

Umfang des Konzepts ..................................................................................48

3.2.1.2

Anforderungsanalyse für die Softwareauswahl............................................48

3.2.1.2.1

Grundlagen der Softwareauswahl ................................................................48

3.2.1.2.2

Selektion einer Technik zur Softwareauswahl .............................................49

3.2.1.2.3

Anforderungskatalog für ein Ontologie-Tool ..............................................55

3.2.1.2.4

Anforderungskatalog für ein CBR-Tool ......................................................69

3.2.1.3

Systemanalyse ..............................................................................................81

3.2.2

Entwurf des ontologiegestützten CBR-Systems ..........................................84

3.2.2.1

Ziele des Entwurfs........................................................................................84

3.2.2.2

Auswahl eines Ontologie-Tools ...................................................................85

3.2.2.2.1

Marktanalyse zur Identifizierung von Alternativen .....................................85

3.2.2.2.2

Bewertung der Alternativen .........................................................................88

3.2.2.2.3

Selektion der geeignetsten Alternative.......................................................109

3.2.2.3

Auswahl eines CBR-Tools .........................................................................113

3.2.2.3.1

Marktanalyse zur Identifizierung von Alternativen ...................................113

3.2.2.3.2

Bewertung der Alternativen .......................................................................114

3.2.2.3.3

Selektion der geeignetsten Alternative.......................................................130

3.2.2.4

Definition der Schnittstellen zwischen dem Ontologie-Tool und dem CBR-Tool ...................................................................................................133

3.2.2.5

Rückkopplungen durch Schnittstellen-Erkenntnisse..................................133

3.2.2.6

Auswahlentscheidung hinsichtlich des Ontologie-Tools und des CBRTools...........................................................................................................133

3.2.3

Implementierung des ontologiegestützten CBR-Systems ..........................134

3.2.3.1

Ziele der Implementierung .........................................................................134

Inhaltsverzeichnis

XIII

3.2.3.2

Erstellung der Fallbasis ..............................................................................134

3.2.3.3

Erstellung der Ontologie ............................................................................139

3.2.3.3.1

Ziele und Umfang.......................................................................................139

3.2.3.3.2

Methode zur Erstellung der Ontologie .......................................................140

3.2.3.3.3

Anwendung der Methode zur Erstellung der Ontologie ............................140

3.2.3.3.3.1

Bestimmung der Domäne...........................................................................140

3.2.3.3.3.2

Nutzung bestehender Ontologien ...............................................................141

3.2.3.3.3.3

Sammlung wichtiger Begriffe für die Ontologie........................................141

3.2.3.3.3.4

Definition der Klassen und der Klassenhierarchie.....................................143

3.2.3.3.3.5

Definition der Attribute und Relationen.....................................................146

3.2.3.3.3.6

Definition der Wertebereiche und der Kardinalitäten von Attributen und Relationen............................................................................................152

3.2.3.3.3.7

Erzeugung von Instanzen ...........................................................................155

3.2.3.4

Erstellung von Ähnlichkeitsmaßstäben ......................................................159

3.2.3.5

Erstellung eines Algorithmus zur Aggregation von lokalen Ähnlichkeitswerten.....................................................................................167

3.2.3.6

Erstellung eines Prototyps für ontologiegestütztes Case-Based Reasoning ...................................................................................................174

3.2.3.7

Test des Prototyps für ontologiegestütztes Case-Based Reasoning ...........191

4

Fazit.......................................................................................................................217

5

Ausblick ................................................................................................................219

Literaturverzeichnis ........................................................................................................221 Anhang ..............................................................................................................................257

Abkürzungs- und Akronymverzeichnis

Abkürzungs- und Akronymverzeichnis AAAI

Association for the Advancement of Artificial Intelligence

AHP

Analytic Hierarchy Process

AIAI

Artificial Intelligence Applications Institute

AIX

Advanced Interactive eXecutive

AMD

Advanced Micro Devices, Incorporated

ANP

Analytic Network Process

API

Application Programming Interface

ASCII

American Standard Code for Information Interchange

ASWC

Asian Semantic Web Conference

AT&T

American Telephone and Telegraph Company

BMIR

Biomedical Informatics Research

BNCOD

British National Conference on Databases

BSD

Berkeley Software Distribution

BSI

Bundesamt für Sicherheit in der Informationstechnik

bzgl.

bezüglich

bzw.

beziehungsweise

C.I.

Consistency Index

C.R.

Consistency Ratio

CAISE

Conference on Advanced Information Systems Engineering

CASL

Common Algebraic Specification Language

CBR

Case-Based Reasoning

CBR-Tool

Case-Based-Reasoning-Tool

CBR-System

Case-Based-Reasoning-System

CC

Common Criteria for Information Technology Security Evaluation

CHISEL

Computer Human Interaction & Software Engineering Lab

CO-ODE

Collaborative Open Ontology Development Environment

CPU

Central Processing Unit

CSV

Comma-separated Values

DAML

DARPA Agent Markup Language

DARPA

Defense Advanced Research Projects Agency

DEA

Data Envelopment Analysis

DFKI

Deutsches Forschungszentrum für Künstliche Intelligenz

XV

XVI DIN

Abkürzungs- und Akronymverzeichnis Deutsches Institut für Normung

DL

Description Logics

DNS

Domain Name System

DoD

Department of Defense

dt.

deutsch

DV

Datenverarbeitung

e.V.

eingetragener Verein

ECAI

European Conference on Artificial Intelligence

ECCBR

European Conference on Case-Based Reasoning

ECIR

European Conference on Information Retrieval

ER

Entity-Relationship

ERD

Entity-Relationship Diagramm

ESWC

European Semantic Web Conference

et al.

et alii

EWMF

European Web Mining Forum

f.

folgende

ff.

fort folgende

FLAIRS

Florida Artificial Intelligence Research Society

F-Logic

Frame Logic

FTP

File Transfer Protocol

FQAS

Flexible Query Answering Systems

FQDN

Full Qualified Domain Name

FZI

Forschungszentrum Informatik

ggf.

gegebenenfalls

GAIA

Group of Artificial Intelligence Applications

GIS

Geographic Information Systems

GPL

General Public License

GPM

Gesellschaft für Projektmanagement

GUI

Graphical User Interface

H.

Heft

Hrsg.

Herausgeber

HTML

Hypertext Markup Language

IBM

International Business Machines Corporation

ICADL

International Conference on Asian Digital Libraries

Abkürzungs- und Akronymverzeichnis ICCBR

International Conference on Case-Based Reasoning

ICONIP

International Conference on Neural Information Processing

IEC

International Electrotechnical Commission

IEEE

Institute of Electrical and Electronics Engineers

IFM

Institute for Manufacturing

IJCAI

International Joint Conference on Artificial Intelligence

INRECA

Induction and Reasoning from Cases

IP

Internet Protocol

IR

Information Retrieval

ISBMDA

International Symposium on Biological and Medical Data Analysis

ISO

International Organization for Standardization

IST

Information Society Technologies

iSQI

International Software Quality Institute

XVII

IT

Informationstechnologie

IWT

Innovatie door Wetenschap en Technologie

jCOLIBRI

java Cases and Ontology Libraries Integration for Building Reasoning Infrastructure

Jg.

Jahrgang

JVM

Java Virtual Machine

KDO

Knowledge Discovery and Ontologies

KI

Künstliche Intelligenz

KIF

Knowledge Interchange Format

KMU

Klein- und Mittelunternehmen

KSL

Knowledge Systems, AI Laboratory

LP

Limited Partnership

max.

maximal

min.

mindestens

MSDOS

Microsoft Disk Operating System

MyCBR

My Case-Based Reasoning

NAT

Network Address Translation

ncRNA

Non-coding Ribonucleic Acid

NLP

Natural Language Processing

No.

Number

Nr.

Nummer

o.a.

oben angeführt

XVIII OCML

Abkürzungs- und Akronymverzeichnis Operational Conceptual Modelling Language

OIL

Ontology Inference Layer

o.J.

ohne Jahresangabe

OKBC

Open Knowledge Base Connectivity

OntoViz

Ontology Visualization

OSX

Operating System X

o.V.

ohne Verfasser

OWL

Web Ontology Language

OXML

OntoStudio Extensible Markup Language

PAL

Protégé Axiom Language

PC

Personal Computer

PMI

Project Management Institute

PMBOK

Project Management Body of Knowledge

PowerPC

Performance optimization with enhanced RISC Performance Chip

RACER

Renamed Abox and Concept Expression Reasoner

RDF

Resource Description Framework

RDFS

Resource Description Framework Schema

RIF

Rule Interchange Format

RISC

Reduced Instruction Set Computer

RuleML

Rule Markup Language

S.

Seite

SAP R/3

Systeme, Anwendungen und Produkte Real-time data processing/3-tier

SAS

Statement on Auditing Standards

Sek.

Sekunden

s.o.

siehe oben

SPARQL

SPARQL Protocol and RDF Query Language

SPSS

Superior Performing Software System

SWO

Swoop Ontology Object File

SWRL

Semantic Web Rule Language

SQL

Structured Query Language

TCP/IP

Transmission Control Protocol/Internet Protocol

TGViz

Touch-Graph Visualization

TXT

Text

u.

und

Abkürzungs- und Akronymverzeichnis u.a.

unter anderem

UK

United Kingdom

UML

Unified Modeling Language

URI

Uniform Resource Identifier

URL

Uniform Resource Locator

US

United States

USA

United States of America

usw.

und so weiter

v. Chr.

vor Christus

vgl.

vergleiche

VMware

Virtual Machine Ware

Vol.

Volume

VPN

Virtual Private Network

W3C

World Wide Web Consortium

WG

Working Group

WSUS

Windows Server Update Services

XML

Extensible Markup Language

z.B.

zum Beispiel

XIX

Symbolverzeichnis

Symbolverzeichnis

a ij f i

a

Paarvergleichsurteil zwischen Vergleichsobjekt i und j Attributswert des Falls f

a iq

Attributswert des Anfrage-Falls q

A

f i

Attribut des Falls f

A

q i

Attribut des Anfrage-Falls q

A

Evaluationsmatrix (AHP)

cs

Klasse s

f i

Klasse, zu der die Instanz mit dem Attribut A if gehört

c iq

Klasse, zu der die Instanz mit dem Attribut A iq gehört

d

Abstand zwischen numerischen Attributswerten

e

Schwellenwert für hinreichende Ähnlichkeit

f

Fall

F

Menge aus Fällen

Fn

Fall n

Gz

Gewicht des Beurteilungskriteriums z (Nutzwertanalyse)

i

Vergleichsobjekt (AHP)

I

Einheitsmatrix

j

Vergleichsobjekt (AHP)

k

Hilfswert für die Ermittlung der Ähnlichkeit zwischen zwei Klassen

O

Eigenwert

O max

maximaler Eigenwert

M

Menge mit Ähnlichkeitswerten

n

natürliche Zahl

N

normierte Evaluationsmatrix (AHP)

Ny

Nutzwert einer Entscheidungsalternative y (Nutzwertanalyse)

pi

Priorität zum Vergleichsobjekt i (AHP)

c

p

id i

Priorität zum Vergleichsobjekt i im Ideal Mode (AHP)

XXI

XXII

Symbolverzeichnis

Pj

Gesamtpriorität einer Alternative j (AHP)

Pyz

Punktwert, den eine Entscheidungsalternative y beim Beurteilungskriterium z erreicht (Nutzwertanalyse)

q

Anfrage-Fall

rhf

Relationswert des Falls f

q h

r

Relationswert des Anfrage-Falls q

rvi1

relational verknüpfte Instanz 1

rvi2

relational verknüpfte Instanz 2 Zeilensumme zu Vergleichsobjekt i (AHP)

si sim a (a , a )

Wert für die Ähnlichkeit zwischen den Attributswerten a iq und a if

sim c (c qh , c fh )

Wert für die Ähnlichkeit zwischen den Klassen c qh und c fh

sim g (q, f )

Wert für die Ähnlichkeit zwischen einem Anfrage-Fall q und einem Fall f

sim r ( rhq , rhf )

Wert für die Ähnlichkeit zwischen den Relationswerten rhq und rhf

t

Transition (PETRI-Netz)

q i

q i

f i

f i

tab (a , a )

Ähnlichkeitswert im Tabellenfeld mit Zeilenindex a iq und Spaltenindex a if

tax (a iq , a if )

Ähnlichkeitswert in der Taxonomie, der an dem gemeinsamen übergeordneten Knoten der Knoten a iq und a if hinterlegt ist

ui

Gewicht einer Ähnlichkeit

v

Eigenvektor

vi

Bedeutungsurteil (AHP)

wi

aggregiertes Bedeutungsurteil zu Vergleichsobjekt i (AHP)

x

Ähnlichkeit

y

Entscheidungsalternative (Nutzwertanalyse)

z & 0

Beurteilungskriterium (Nutzwertanalyse) Nullvektor

{}

leere Menge

Abbildungsverzeichnis

XXIII

Abbildungsverzeichnis

Abbildung 1:

Aufbau der Untersuchung in Form eines PETRI-Netzes ..........................15

Abbildung 2:

Wissensgebiete im PMBOK-Guide.........................................................18

Abbildung 3:

CBR-Cycle...............................................................................................34

Abbildung 4:

Fallidentifikation und -selektion im ontologiegestützten CaseBased Reasoning .....................................................................................35

Abbildung 5:

Wasserfallmodell .....................................................................................42

Abbildung 6:

Spezifische Ausgestaltung des Wasserfallmodells..................................45

Abbildung 7:

Auswahlverfahren für die Tools im Wasserfallmodell............................46

Abbildung 8:

Qualitätsmodell für externe und interne Softwarequalität.......................57

Abbildung 9:

Kriterienebenen für die Auswahl eines Ontologie-Tools ........................62

Abbildung 10:

Bedeutungsurteile in Expert Choice für die Ontologie-ToolAuswahl ...................................................................................................69

Abbildung 11:

Beispiel für Ähnlichkeitswerte in einer Taxonomie................................75

Abbildung 12:

Kriterienebenen für die Auswahl eines CBR-Tools ................................76

Abbildung 13:

Bedeutungsurteile in Expert Choice für die CBR-Tool-Auswahl ...........81

Abbildung 14:

Ontologiegestütztes CBR-System ...........................................................82

Abbildung 15:

Semantisches Datenmodell zum ontologiegestützten Case-Based Reasoning ................................................................................................83

Abbildung 16:

Hierarchie des Entscheidungsproblems...................................................90

Abbildung 17:

Fehlerzustand in Apollo...........................................................................97

Abbildung 18:

Graphical User Interface von Apollo.......................................................99

Abbildung 19:

Graphical User Interface von OntoStudio ...............................................99

Abbildung 20:

Graphical User Interface von OntoTrack ..............................................100

Abbildung 21:

Graphical User Interface von Protégé ...................................................100

Abbildung 22:

Graphical User Interface von Swoop.....................................................101

Abbildung 23:

Gesamtprioritäten in Expert Choice ......................................................111

Abbildung 24:

Gesamtprioritäten nach Entfernen der Alternative Protégé...................112

Abbildung 25:

Hierarchie des Entscheidungsproblems.................................................116

Abbildung 26:

Fehlerzustand in CASPIAN...................................................................121

Abbildung 27:

Fehlerzustand in CBR-Shell ..................................................................121

XXIV

Abbildungsverzeichnis

Abbildung 28:

Graphical User Interface von CASPIAN...............................................123

Abbildung 29:

Graphical User Interface von CBR-Shell ..............................................123

Abbildung 30:

Graphical User Interface von Induce-It .................................................124

Abbildung 31:

Graphical User Interface von MyCBR als Protégé-Plug-In ..................124

Abbildung 32:

Graphical User Interface vom selbstständigen MyCBR........................125

Abbildung 33:

Gesamtprioritäten in Expert Choice ......................................................132

Abbildung 34:

Darstellung der Klassenhierarchie.........................................................144

Abbildung 35:

Visualisierung der Klassenhierarchie in Protégé mit Jambalaya...........146

Abbildung 36:

Definition von Attributen und Relationen in Protégé............................149

Abbildung 37:

Attribute und Relationen der Ontologie ................................................151

Abbildung 38:

Instanzen der Ontologie.........................................................................158

Abbildung 39:

Beispiel zum Ähnlichkeitsmaßstab Taxonomie ....................................161

Abbildung 40:

Bestimmung der Anzahl von Knoten im Beispiel 1 ..............................163

Abbildung 41:

Bestimmung der gemeinsamen Attribute im Beispiel 1........................164

Abbildung 42:

Bestimmung der Anzahl von Knoten im Beispiel 2 ..............................164

Abbildung 43:

Bestimmung der gemeinsamen Attribute im Beispiel 2........................165

Abbildung 44:

Bestimmung der Anzahl von Knoten im Beispiel 3 ..............................166

Abbildung 45:

Bestimmung der gemeinsamen Attribute im Beispiel 3........................166

Abbildung 46:

Ablauf des Algorithmus.........................................................................173

Abbildung 47:

Taxonomie für das Attribut „Betriebssystemname“..............................178

Abbildung 48:

Taxonomie für das Attribut „Modell“ ...................................................182

Abbildung 49:

Entfernung von Instanzen zur gemeinsamen Oberklasse ......................186

Abbildung 50:

Ontologie mit hinterlegten Ähnlichkeitswerten für die Klassen ...........188

Abbildung 51:

Zuweisung von Ähnlichkeitswerten zu Klassen in Protégé ..................189

Abbildung 52:

Menüpunkt „Options...“ in Protégé .......................................................189

Abbildung 53:

Berücksichtigung unbekannter Attributswerte in Protégé.....................190

Abbildung 54:

Menüpunkt „Configure Special Values...“ in Protégé...........................190

Abbildung 55:

Umgang mit unbekannten Attributs- und Relationswerten in Protégé ...................................................................................................191

Abbildung 56:

Screenshot vom Retrieval-Ergebnis in MyCBR....................................195

Abbildungsverzeichnis

XXV

Abbildung 57:

Positionen der Werte „Microsoft_Windows_XP“ und „Suse_Linux_10“ in der Taxonomie für das Attribut „Betriebssystemname“...........................................................................199

Abbildung 58:

Positionen der Instanzen „Microsoft_Windows_XP“ und „Suse_Linux_10“ in der Ontologie (Auszug) .......................................200

Abbildung 59:

Positionen der Instanzen „WSUS“ und „Webapplikation“ in der Ontologie (Auszug) ...............................................................................201

Abbildung 60:

Screenshot vom Retrieval-Ergebnis in MyCBR....................................205

Abbildung 61:

Positionen der Instanzen „Client_10“ und „Server_A2“ in der Ontologie (Auszug) ...............................................................................209

Abbildung 62:

Positionen der Werte „Red_Hat_Linux_9“ und „Microsoft_Windows_XP“ in der Taxonomie für das Attribut „Betriebssystemname“...........................................................................210

Abbildung 63:

Positionen der Instanzen „Red_Hat_Linux_9“ und „Microsoft_Windows_XP“ in der Ontologie (Auszug) .......................211

Tabellenverzeichnis

XXVII

Tabellenverzeichnis

Tabelle 1:

Relative Bedeutung zweier Beurteilungsobjekte für das übergeordnete Beurteilungsobjekt...........................................................61

Tabelle 2:

Ergebnisse der Paarvergleiche für die Kriterien der ersten Ebene ..........62

Tabelle 3:

Ergebnisse der Paarvergleiche für die Subkriterien der Funktionalität...........................................................................................64

Tabelle 4:

Ergebnisse der Paarvergleiche für die Subkriterien der Benutzbarkeit...........................................................................................65

Tabelle 5:

Inkonsistenzwerte der Evaluationsmatrizen ............................................66

Tabelle 6:

Berechnung der Bedeutungsurteile für die Kriterien der ersten Ebene .......................................................................................................68

Tabelle 7:

Beispiel für Ähnlichkeitswerte in einer Tabelle ......................................74

Tabelle 8:

Ergebnisse der Paarvergleiche für die Kriterien der ersten Ebene ..........77

Tabelle 9:

Ergebnisse der Paarvergleiche für die Subkriterien der Funktionalität...........................................................................................78

Tabelle 10:

Ergebnisse der Paarvergleiche für die Subkriterien der Benutzbarkeit...........................................................................................79

Tabelle 11:

Ergebnisse der Paarvergleiche für die Subkriterien der Übertragbarkeit........................................................................................79

Tabelle 12:

Inkonsistenzwerte der Evaluationsmatrizen ............................................80

Tabelle 13:

Alternativen im AHP-Verfahren .............................................................88

Tabelle 14:

Bewertung der Tools hinsichtlich des Kriteriums Ontologieerstellung .................................................................................91

Tabelle 15:

Bewertung der Tools hinsichtlich des Kriteriums Konsistenzprüfung...................................................................................93

Tabelle 16:

Interne Ontologiesprachen.......................................................................95

Tabelle 17:

Bewertung der Tools hinsichtlich des Kriteriums Ontologiesprachen ...................................................................................95

Tabelle 18:

Bewertung der Tools hinsichtlich des Kriteriums Zuverlässigkeit .........97

Tabelle 19:

Bewertung der Tools hinsichtlich des Kriteriums GUI .........................101

Tabelle 20:

Bewertung der Tools hinsichtlich des Kriteriums Dokumentation .......103

Tabelle 21:

Ontologiesprachen beim Export ............................................................105

Tabelle 22:

Bewertung der Tools hinsichtlich des Kriteriums Übertragbarkeit.......105

XXVIII

Tabellenverzeichnis

Tabelle 23:

Inkonsistenzwerte der Evaluationsmatrizen ..........................................107

Tabelle 24:

Berechnung der Bedeutungsurteile........................................................108

Tabelle 25:

Einzelprioritäten in Expert Choice ........................................................110

Tabelle 26:

Änderung der Rangordnung beim Entfernen von Alternativen.............112

Tabelle 27:

Alternativen im AHP-Verfahren ...........................................................114

Tabelle 28:

Bewertung der Tools hinsichtlich des Kriteriums Algorithmen............117

Tabelle 29:

Bewertung der Tools hinsichtlich des Kriteriums Ähnlichkeitsmaßstab .............................................................................119

Tabelle 30:

Bewertung der Tools hinsichtlich des Kriteriums Fallrepräsentation ...120

Tabelle 31:

Bewertung der Tools hinsichtlich des Kriteriums Zuverlässigkeit .......122

Tabelle 32:

Bewertung der Tools hinsichtlich des Kriteriums GUI .........................125

Tabelle 33:

Bewertung der Tools hinsichtlich des Kriteriums Dokumentation .......127

Tabelle 34:

Bewertung der Tools hinsichtlich des Kriteriums Import von Fallwissen ..............................................................................................128

Tabelle 35:

Bewertung der Tools hinsichtlich des Kriteriums Import von Ontologiewissen ....................................................................................129

Tabelle 36:

Inkonsistenzwerte der Evaluationsmatrizen ..........................................130

Tabelle 37:

Einzelprioritäten in Expert Choice ........................................................131

Tabelle 38:

Änderung der Rangordnung beim Entfernen von Alternativen.............132

Tabelle 39:

Auszug der extrahierten Entitäten .........................................................143

Tabelle 40:

Attribute und Relationen der Ontologie ................................................148

Tabelle 41:

Wertebereiche und Kardinalitäten der Attribute und Relationen ..........154

Tabelle 42:

Instanzen der Klasse „Projekt“ (Teil 1).................................................155

Tabelle 43:

Instanzen der Klasse „Projekt“ (Teil 2).................................................156

Tabelle 44:

Instanzen der Klasse „Betriebssystem“ .................................................156

Tabelle 45:

Instanzen der Klasse „Client“................................................................156

Tabelle 46:

Instanzen der Klasse „Server“ ...............................................................157

Tabelle 47:

Instanzen der Klasse „Individualanwendung“.......................................157

Tabelle 48:

Instanzen der Klasse „Standardanwendung“.........................................157

Tabelle 49:

Beispiel zum Ähnlichkeitsmaßstab Tabelle ..........................................160

Tabelle 50:

Zuordnung der Ähnlichkeitsmaßstäbe...................................................174

Tabelle 51:

Ähnlichkeitstabelle für das Attribut „Projekttyp“ .................................176

Tabellenverzeichnis

XXIX

Tabelle 52:

Ähnlichkeitstabelle für das Attribut „Euro“ ..........................................176

Tabelle 53:

Ähnlichkeitstabelle für das Attribut „Personentage“.............................177

Tabelle 54:

Ähnlichkeitstabelle für das Attribut „Familie“......................................179

Tabelle 55:

Ähnlichkeitstabelle für das Attribut „Anwendungsname“ ....................180

Tabelle 56:

Ähnlichkeitstabelle für das Attribut „Anwendungsbereich“ .................181

Tabelle 57:

Ähnlichkeitstabelle für das Attribut „Typ“ ...........................................183

Tabelle 58:

Gewichtung der lokalen Ähnlichkeiten .................................................185

Tabelle 59:

Bestimmung von k.................................................................................187

Tabelle 60:

Bekannte Instanzen und Werte des Anfrage-Falls 1 .............................193

Tabelle 61:

Erweiterte Ähnlichkeitstabelle für das Attribut „Anwendungsname“..............................................................................194

Tabelle 62:

Retrieval-Ergebnis für Anfrage-Fall 1 gemäß MyCBR ........................195

Tabelle 63:

Gegenüberstellung der Werte von Anfrage-Fall 1 und vom Fall „Online-Banking“..................................................................................197

Tabelle 64:

Lokale Ähnlichkeitswerte für den Anfrage-Fall 1 und den Fall „Online-Banking“..................................................................................202

Tabelle 65:

Bekannte Instanzen und Werte des Anfrage-Falls 2 .............................203

Tabelle 66:

Erweiterte Ähnlichkeitstabelle für das Attribut „Anwendungsname“..............................................................................204

Tabelle 67:

Retrieval-Ergebnis für Anfrage-Fall 2 gemäß MyCBR ........................205

Tabelle 68:

Gegenüberstellung der Werte von Anfrage-Fall 1 und vom Fall „Online-Banking“..................................................................................207

Tabelle 69:

Lokale Ähnlichkeitswerte für den Anfrage-Fall 2 und den Fall „Optimierung_Clientstart“.....................................................................211

Tabelle 70:

Ergebnisse der Relabilitätsprüfung zum Retrieval mit dem Anfrage-Fall 1........................................................................................214

Tabelle 71:

Ergebnisse der Relabilitätsprüfung zum Retrieval mit dem Anfrage-Fall 2........................................................................................214

Einführung in den Problembereich technikgestützten Managements von Projektwissen

1

1.1

1

Einführung in den Problembereich technikgestützten Managements von Projektwissen Betriebswirtschaftliches Desiderat

Die Bedeutung des Projektmanagements für unsere Gesellschaft hat in den letzten Jahren stark zugenommen. 1 Aktuelle Probleme im Projektmanagement, insbesondere das Scheitern von Projekten und eine mangelnde Wertsteigerung durch Projektarbeit, besitzen eine hohe Aufmerksamkeit. Laut einer Studie der TECHNISCHEN UNIVERSITÄT MÜNCHEN waren nur 43% der untersuchten Projekte erfolgreich. 2 Die allgemeine Abbruchquote von ITProjekten wurde mit 20% gemessen. 3 In der aktuellsten Chaos-Studie der STANDISH GROUP 4 wurde für das Jahr 2008 sogar eine Abbruchquote in Höhe von 24% angegeben. Laut einer Studie von GRÖGER 5 trägt lediglich 13% der in der deutschen Wirtschaft geleisteten Projektarbeit zur Wertsteigerung bei. 87% dieser Projektarbeit ist Wertvernichtung. Folglich wurden innerhalb eines Jahres zwischen 112 und 194 Milliarden Euro im Rahmen von Projektarbeit verschwendet. Neben dem Interesse an Projektmanagement nimmt auch das Interesse an Wissensmanagement seit einiger Zeit rapide zu.6 Da es zwischen einem erfolgreichen Wissensmanagement und einem erfolgreichen Projektmanagement enge Beziehungen7 gibt, liegt es nahe, nach neuen Verbesserungsansätzen zu suchen. Die engen Beziehungen zwischen einem erfolgreichen Wissensmanagement und einem erfolgreichen Projektmanagement füh1

Vgl. GPM (2007), S. 67.

2

Im Rahmen der Studie wurden Projekte aus der IT-Domäne über einen Zeitabschnitt von drei Jahren untersucht. Vgl. FRIEDMANN (2006), S. 1.

3

Vgl. RICHTER/BENDER/KLINGER/HERBOLZHEIMER (2008), S. 4.

4

Vgl. STANDISH GROUP (2009), S. 1.

5

Diese Angaben basieren auf einer Studie, in der über einen Zeitraum von fast vier Jahren 962 Führungskräfte zu ihren Erfahrungen mit dem Projektmanagement in deutschen Unternehmen und der öffentlichen Verwaltung befragt wurden. Vgl. GRÖGER (2004), S. 8 f.

6

„Die vielfachen wirtschaftspolitischen und soziologischen Debatten über den Übergang von der Industrie- zur Informations- oder Wissensgesellschaft mögen hierzu ebenso beigetragen haben wie die ökonomische Diskussion über die Erweiterung klassischer Faktorsystematiken um den Produktionsfaktor Wissen.“; ZELEWSKI (2005) S. 133.

7

Diese engen Beziehungen liegen darin begründet, dass Wissen ein primärer Einsatzfaktor für die Bearbeitung eines Projekts ist. Wenn das Wissensmanagement erfolgreich ist, steht Wissen tendenziell in umfangreicherem und qualitativ höherem Maß bereit. Wissen ist als Voraussetzung für eine effektive und effiziente Projektbearbeitung zu betrachten. Maßstäbe hierfür sind die Qualität des Projektergebnisses sowie Zeit und Kosten als Projekt-Inputs.

S. Beißel, Ontologiegestütztes Case-Based Reasoning, DOI 10.1007/978-3-8349-6232-4_1, © Gabler Verlag | Springer Fachmedien Wiesbaden GmbH 2011

2

Einführung in den Problembereich technikgestützten Managements von Projektwissen

ren dazu, dass sowohl die Disziplin „Projektmanagement“ als auch die Disziplin „Wissensmanagement“ von grundlegenden Aufgabenbereichen tangiert werden. Das Spannungsfeld interdisziplinärer Aufgabenbereiche ist daher ein wichtiger Ansatzpunkt für neue Verbesserungen. Die Wiederverwendung von Projektwissen ist einer dieser interdisziplinären Aufgabenbereiche. Bei der Vorbereitung und Durchführung neuer Projekte ist die Wiederverwendung von unternehmensspezifischem Wissen aus bereits durchgeführten Projekten sehr hilfreich, um z.B. Projekt-Erwartungen realistisch zu bewerten und passende Projekt-Anforderungen zu spezifizieren. Laut einer Studie der DEUTSCHEN GESELLSCHAFT NAGEMENT

8

FÜR

PROJEKTMA-

ist das Fehlen einer Wiederverwendung von diesem Wissen eine der größten

Schwachstellen beim Projektmanagement. Wenn z.B. Wissen über Budgetabschätzungen und Zeitplänen aus bereits durchgeführten Projekten nicht wiederverwendet wird, können wiederholte Fehler schwer vermieden werden. Das Wissen ist hauptsächlich in den Erinnerungen und Unterlagen der Akteure gespeichert. Im Rahmen von Dokumentationen und durch die Generierung von Lessons Learned werden Dokumente erstellt, die elektronisch oder papierbasiert im Unternehmen aufbewahrt werden. Daraus entsteht eine unüberschaubare Menge an Dokumenten, die sich mit traditionellen Techniken 9 nur noch mit großem Aufwand verwalten lässt. Das große Volumen ist eine Barriere bei der Wiederverwendung des Wissens. Studien belegen, dass 80% der Informationen eines Unternehmens in Textdokumenten enthalten sind. 10 Daraus folgt, dass Informationen hauptsächlich in Form natürlichsprachlicher Dokumente vorliegen. Die natürlichsprachliche Repräsentation des Wissens ist eine weitere Barriere bei der Wiederverwendung des Wissens. Konventionelle Wissensmanagementtechniken der betrieblichen Praxis reichen zur Überwindung der Barrieren nicht aus, da in der Praxis die relevanten Informationen meist

8

Vgl. ENGEL/TAMDJIDI/QUADEJACOB (2008), S. 5.

9

Unter traditionellen Techniken werden die manuelle Bearbeitung und die in der Praxis verbreitete teilautomatische Bearbeitung mit Hilfe von computergestützten Techniken verstanden, wie z.B. Abfragen von Datenbanken oder Volltextsuchen in Dateiverzeichnissen.

10

Vgl. TAN (1999), S. 1. Obwohl die 80%-Regel vielfach zitiert wird, ist sie durchaus kritisch zu betrachten. Je nach Studie gibt es Abweichungen im gemessenen Verhältnis von unstrukturierten Daten, wie Textdokumenten, zu strukturierten Daten. Vgl. GRIMES (2010). Im Rahmen verschiedener Studien wurde der Anteil der unstrukturierten Daten mit 53% bis 90% angegeben. Für das Verhältnis spielt außerdem die Arbeitsweise im betrachteten Unternehmen eine große Rolle. So wird ein Unternehmen, in dem hauptsächlich mit strukturierten Daten gearbeitet wird, einen höheren Anteil an strukturierten Daten besitzen als ein Unternehmen, in dem hauptsächlich mit unstrukturierten Daten gearbeitet wird.

Einführung in den Problembereich technikgestützten Managements von Projektwissen

3

manuell aus elektronischen Informationsspeichern 11 recherchiert oder mit erfahrenen Akteuren kommuniziert werden. Dadurch ergeben sich mehrere Probleme für ein effektives Auffinden von passenden Informationen. Zum einen sind die Dokumente von unerfahrenen Akteuren schwer zu durchschauen, da anhand der Dokumente das relevante Wissen meist nur implizit ersichtlich und somit auch nicht sofort verfügbar ist. Auch lassen sich viele Informationen nicht ohne Hintergrundwissen aus anderen Texten erschließen. Erschwerend ist außerdem, dass verschiedene Akteure oft auch verschiedene Begriffe benutzen, um dieselben Informationen zu speichern. Auch sind die Beziehungen der Projekte untereinander nicht sofort erkennbar. Z.B. könnte ein abgeschlossenes Projekt nur auf Grund einer starken Synergienutzung mit anderen Projekten erfolgreich gewesen sein. Wenn auch die Dokumente von diesen anderen Projekten gesucht und verstanden werden müssen, führt dies dazu, dass für die Erkennung von Ähnlichkeiten zwischen bereits durchgeführten und aktuellen Projekten eine erhöhte Anzahl von Dokumenten mit natürlichsprachlichem Text strukturiert werden muss. Eine Strukturierung von natürlichsprachlichem Text ist grundsätzlich schwer. 12 Zum anderen ist das Wissen über Ähnlichkeitsmerkmale zwischen Projekten in großem Umfang in den Erinnerungen erfahrener Akteure gespeichert. Solange dieses Ähnlichkeitswissen nicht extern gespeichert wird, kann eine langfristige Verfügbarkeit des Wissens nicht sichergestellt werden. Wissen kann für das Unternehmen verloren gehen, wenn betreffende Akteure ausscheiden. Wissen kann temporär unzugänglich sein, wenn Akteure nicht kooperieren wollen oder aus Zeitmangel nicht können.13 Das betriebswirtschaftliche Desiderat besteht aus einer im Vergleich zu manuellen Techniken kostengünstigeren, zeitlich weniger aufwändigen und qualitativ hochwertigeren Identifikation von hinreichend ähnlichen Fällen und Selektion von einem ähnlichsten Fall im Zuge der Wiederverwendung von Erfahrungswissen aus Projekten. Ein Fall repräsentiert hierbei ein Projekt. Relevante Kosten sind der Ressourceneinsatz von Projektwissen, Sachgütern und Dienstleistungen. Das Ziel der Ressourceneinsparung wird dadurch erreicht, dass der Res-

11

Bei elektronischen Informationsspeichern handelt es sich beispielsweise um Dokumenten-Management-Systeme, die die elektronische Speicherung von Dokumenten ermöglichen. Die aus diesen Systemen abrufbaren Dokumente beinhalten Informationen, die in Form von natürlich- oder formalsprachlichen Elementen repräsentiert werden.

12

Vgl. WOOD/ROSS-KERR (2010), S. 250 u. MOENS (2006), S. 4. Hier wird natürlichsprachlicher Text zur Kategorie der unstrukturierten Daten gezählt.

13

Vgl. PUPPE/STOYAN/STUDER (2004), S. 621.

4

Einführung in den Problembereich technikgestützten Managements von Projektwissen

sourceneinsatz von Projektwissen, Sachgütern und Dienstleistungen geringer ausfällt. Eine neue Technik soll einen geringeren Ressourceneinsatz verursachen als eine herkömmliche manuelle oder automatische Technik. Der Ressourceneinsatz besteht bei einer manuellen Technik primär aus Arbeitskraft. Zeiteinsparungen werden durch Prozessbeschleunigungen erreicht. Die benötigte Zeit zur Durchführung des Prozesses zur Identifikation von hinreichend ähnlichen Fällen und Selektion eines ähnlichsten Falls kann durch eine Änderung des Prozessinhalts reduziert werden, der aus den erforderlichen Tätigkeiten der am Prozess beteiligten Akteure besteht. Nicht allein das Vorhandensein von Projektwissen, sondern vielmehr ein möglichst schneller und einfacher Zugriff darauf sind entscheidend für Wiederverwendung von Projektwissen. Eine Verbesserung der Qualität bedeutet, dass die Merkmale der Fallidentifikation und -selektion dazu geeignet sind, festgelegte Erfordernisse zu erfüllen. Diese Erfordernisse sind die umfangreiche Einbindung von Hintergrundwissen und die Aufhebung der Begrenzung auf das eigene Hintergrundwissen einzelner Akteure. Denn es soll nicht nur das eigene Hintergrundwissen einzelner Akteure, sondern eine gemeinsame Wissensbasis genutzt werden können.

1.2

State-of-the-art der verfügbaren Techniken zur Erfüllung des betriebswirtschaftlichen Desiderats

Zur Erfüllung des vorgenannten betriebswirtschaftlichen Desiderats werden seitens des State-of-the-arts der automatischen Informationsverarbeitung und des computergestützten Wissensmanagements vor allem die Techniken des Information Retrievals (IR) und Natural Language Processings (NLP) angeboten. 14 Die Bedeutung des Begriffs Information Retrieval ist weit gefasst. Eine allgemeine Definition stammt von MANNING 15 , der Information Retrieval als das Finden von unstrukturiertem Material (meistens Dokumente, die Text beinhalten) innerhalb von großen Informationsmengen beschreibt, um einen Informationsbedarf zu befriedigen. Aus den folgenden Gründen ist Information Retrieval für den Untersuchungsgegenstand ungeeignet: Information Retrieval basiert hauptsächlich auf Statistiken über Dokumentensammlungen. Es wird sehr schwierig, innerhalb dieser Technik benutzerdefinierte Ähnlichkeitsmaßstäbe

14

Vgl. z.B. VOORHEES (1999), S. 32 f. u. SMEATON (1999), S. 99 ff.

15

Vgl. MANNING (2008), S. 1.

Einführung in den Problembereich technikgestützten Managements von Projektwissen

5

mit einem vernünftigen zeitlichen und kostenmäßigen Aufwand zu integrieren. Außerdem basiert Ähnlichkeit in den meisten Techniken des Information Retrievals hauptsächlich auf Zeichenfolgen. Es ist nicht geklärt, wie domänenspezifisches Wissen, z.B. domänenspezifische Synonyme und Abkürzungen genutzt werden können. Die Verwendung von zusätzlichem Hintergrundwissen, wie z.B. die Gewichtung von Ähnlichkeiten zwischen Attributswerten, ist beim Information Retrieval nicht möglich.16 Laut MANARIS 17 befasst sich Natural Language Processing mit den sprachlichen Aspekten der Kommunikation zwischen menschlichen Akteuren oder zwischen menschlichen und maschinellen Akteuren sowie der Integration dieser Aspekte in Techniken und Prozesse. Natural Language Processing umfasst Techniken, die den Inhalt von Texten verstehen sollen. Zu diesen Techniken gehören z.B. Spracherkennung, Schnittstellen für natürliche Sprache, Diskursmanagement und interaktive Maschinenübersetzung. 18 Diese Techniken beschränken sich nicht auf rein statistische Verfahren, wie z.B. die Ermittlung von Worthäufigkeiten bei Techniken des Information Retrievals, sondern versuchen die Semantik eines Satzes anhand der Identifikation von Verben, Substantiven usw. herauszufinden. Die Techniken des Natural Language Processings teilen einen Satz mit Hilfe von verschiedenen Algorithmen in seine Hauptbestandteile. Die Algorithmen führen Analysen auf unterschiedlichen Ebenen durch. Die Analysen können oberflächlich oder tiefgehend sein.19 Oberflächliche Analysen berücksichtigen ausschließlich die Syntax des Satzes und nicht die Semantik. Sie ermitteln z.B. Verben, Substantive usw., z.B. mit Part-of-SpeechTagging 20 . Tiefgehende Analysen gehen einen Schritt weiter und versuchen, die Semantik eines Satzes zu deuten. Durch die Offenlegung der Semantik eines Satzes kann der Kontext von Wörtern berücksichtigt werden. Ein negativer Aspekt der tiefgehenden Analysen ist, dass sie oft sehr rechenintensiv sind. 21 Außerdem arbeiten sie meist mit kleinen Wörterbüchern und sind nicht robust, wenn unbekannte Begriffe auftauchen. 22 Im Kontext der Untersuchung ist dies sehr wahrscheinlich, da domänenspezifische Begriffe aus der Domäne

16

Vgl. WATSON (1997), S. 45.

17

Vgl. MANARIS (1998), S. 6.

18

Vgl. MANARIS (1998), S. 3.

19

Vgl. ACHANANUPARP/HU/ZHOU/ZHANG (2008), S. 204.

20

Unter Part-of-Speech-Tagging ist die Zuordnung von Wörtern eines Textes zu Wortarten zu verstehen.

21

Vgl. MOSCHITTI/BASILI (2004), S. 182 u. LENZ/HÜBNER/KUNZE (1998), S. 246.

22

Vgl. LENZ/HÜBNER/KUNZE (1998), S. 246.

6

Einführung in den Problembereich technikgestützten Managements von Projektwissen

IT-Projektmanagement hier relevant sind. Tiefgehenden Analysen sind lediglich in Situationen einsetzbar, wo z.B. die Dokumente in der Form von kurzen Notizen oder Anmerkungen vorliegen und wo die Sätze kurz und grammatikalisch nicht korrekt sind. Natural Language Processing ist für den Untersuchungsgegenstand ungeeignet. Eine wesentliche Komponente eines jeden NLP-Systems ist das Wörterbuch. Für dieses sind nicht nur die Wörter selbst, sondern auch linguistisches Wissen über diese Wörter notwendig. Sobald ein Großteil domänenspezifischer Wörter benötigt wird, würde der Aufbau dieses Wörterbuchs zu viel Aufwand mit sich bringen. Die Ähnlichkeit kann eher an Schlüsselwörtern und weniger am Kontext dieser Schlüsselwörter bestimmt werden. Um die Semantik zu berücksichtigen, ist die Integration einer passenden Technik notwendig. Innerhalb von Natural Language Processing wurden insbesondere Ontologien verwendet, um die Semantik von Texten zu berücksichtigen. 23 In der Literatur sind Ansätze zu finden, die Techniken des Natural Language Processings mit Case-Based Reasoning kombinieren. Mit Hilfe von Natural Language Processing können Begriffe aus natürlichsprachlichen Texten vergleichbar gemacht werden, um sie mit Case-Based Reasoning zu bearbeiten.24

1.3

Wissenschaftliche Problemstellung

Das in Projekten entstehende und verwendete Projektwissen ist meist in unstrukturierten, natürlichsprachlichen Texten gespeichert. Um dieses Projektwissen wiederverwenden zu können, ist eine Technik erforderlich, welche das Wissen formalisiert und analysiert. Diese Technik sollte mit dem Ziel der Verbesserung in Bezug auf betriebswirtschaftliche Maßstäbe computergestützt sein, da ein Computer die Aufgabe unter betriebswirtschaftlichen Maßstäben besser erledigen kann als ein menschlicher Akteur. Es soll immer dort eine Aufgabe von einem menschlichen Akteur auf einen Computer übertragen werden, wo der Computer die Aufgabe unter betriebswirtschaftlichen Maßstäben wie Kosten oder Qualität besser erledigen kann. 25 Durch die Nutzung von Computern sind außerdem erhebliche Zeiteinsparungen möglich. 26 Die Übertragbarkeit einer Aufgabe ist dabei nicht an die Ge-

23

Vgl. WITTE/GITZINGER (2008) S. 366 ff. u. SAIZ-NOEDA/PALOMAR (2000), S. 204.

24

Vgl. PFUHL (2003), S. 22 ff.

25

Vgl. MERTENS/BODENDORF/KÖNIG/PICOT/SCHUMANN/HESS (2005), S. 4.

26

Während menschliche Akteure für Aufgaben mindestens mehrere Sekunden benötigen, können Computer in dieser Zeit Milliarden von Instruktionen ausführen. Vgl. COOPER/REIMANN/CRONIN (2010), S. 251.

Einführung in den Problembereich technikgestützten Managements von Projektwissen

7

samtheit der Aufgabe gebunden. Wenn betriebliche Aufgaben zwingend eine Einbeziehung von Alleinstellungsmerkmalen von menschlichen Akteuren gegenüber Computern erfordern und deshalb nur teilweise von einem Computer übernommen werden können, führt eine Übertragung von Teilaufgaben und damit eine Arbeitsteilung zwischen menschlichen Akteuren und Computern zu einer besseren Erledigung unter betriebswirtschaftlichen Maßstäben als die ausschließliche Bearbeitung der Aufgabe durch menschliche Akteure. Es besteht die Annahme, dass eine große Arbeitsteilung zwischen Akteuren der Grund dafür sein kann, dass ähnlichste Fälle nur schwierig durch einen einzelnen Akteur erkannt werden. Die Lerneffekte, die bei der Suche entstehen können, sind bei der manuellen Suche in ihrer Gesamtheit auf mehrere einzelne menschliche Akteure verteilt. Deshalb soll die Suche auf einen maschinellen Akteur (z.B. einen Computer) konzentriert werden. Dies hat den Vorteil, dass die Lerneffekte zentral vorliegen und vereint werden können. Auf diese Weise stehen sie immer vollständig zur Verfügung, wenn der maschinelle Akteur für die Suche verwendet wird. Die Kommunikation von Akteuren, bei denen es sich um menschliche oder maschinelle Akteure handeln kann, wird von verschiedenen Sichtweisen beeinflusst, die von verschiedenen Bedarfen und Hintergründen geprägt sind. Wenn Akteure gemeinsam eine komplexe Aufgabe bearbeiten, kann diese Divergenz in Bezug auf eine möglichst umfassende Umweltbetrachtung von Vorteil sein. Allerdings führt diese Divergenz zu Problemen in der Kommunikation und im Verstehen. Nach CONKLIN 27 ist die größte Barriere bei einer effektiven Kommunikation das Fehlen von geteiltem Verstehen, besonders von Begriffen, die für eine Aufgabenerfüllung eine Schlüsselrolle besitzen. Ontologien zielen darauf ab, diese Einschränkung zu überwinden. Nach FENSEL 28 ermöglichen Ontologien ein gemeinsames Verstehen von Informationen einer Domäne, die zwischen Akteuren kommuniziert werden. Ontologien ermöglichen dies durch eine Form von semantischer Unabhängigkeit für Informationen: So wie ein Datenbankschema Datenunabhängigkeit dadurch erreicht, dass die Spezifikation und das Management von gespeicherten Daten an einer zentralen Instanz und nicht durch diverse Applikationen durchgeführt werden, so erlauben Ontologien ebenfalls die Spezifikation und das Management von Informationen einer Domäne an einer zentralen Instanz und nicht durch diverse Akteure.29 Die Spezifikation von Informationen wird durch Ontologien 27

Vgl. CONKLIN (2000), S. 13.

28

Vgl. FENSEL (2004), S. 123.

29

Vgl. STARLAB (o.J.).

8

Einführung in den Problembereich technikgestützten Managements von Projektwissen

unter Berücksichtigung der in diesen Informationen enthaltenen Semantik vorgenommen. 30 Durch diese zentrale Spezifikation an einer zentralen Instanz wird eine automatische Verarbeitung von bedeutsamen Begriffen ermöglicht. Bedeutsame Begriffe sind Bestandteile der Falldarstellung von natürlichsprachlichen Dokumenten. Die Ontologie kann dabei helfen, mit eindeutigen Semantiken abweichende Begriffe für identische Informationen zu vereinheitlichen. Sie kann das Wissen über die Inhalte von und Zusammenhänge zwischen natürlichsprachlichen Begriffen beinhalten, die mittels eines maschinellen Akteurs verarbeitet werden können. Durch die Nutzung einer Ontologie wird das Finden von Ähnlichkeiten unter Berücksichtigung des Wissens und des Vokabulars von allen beteiligten Akteuren ermöglicht. Laut ZELEWSKI 31 werden Ontologien abgesehen von einigen Spezialisten wenig beachtet, sind aber aus ökonomischer Sicht, insbesondere im Bereich der Wirtschaftsinformatik, verstärkt als „neuartige“ Erkenntnis- und Gestaltungsobjekte zu würdigen. Ontologien wurden im Projektmanagement z.B. von LIN/HARDING/SHAHBAZ 32 genutzt, um die Interoperabilität zwischen Akteuren im Fertigungsbereich zu verbessern. Zur Unterstützung der Informationssuche wurden Ontologien bereits mehrfach genutzt. VOUROS/EUMERIDOU/TSELIOS/KOTIS 33

haben eine Ontologie in ein System integriert, das eine

kontextbasierte Suche mit Hilfe von SQL-Anfragen an eine Datenbank ermöglicht. LEFEBVRE/GAUTHIER/TADIÉ/DUC/ACHABA 34

haben eine Ontologie im Rahmen der Informati-

onssuche im Telekommunikationsbereich angewendet. BAGLIONI/GIOVANNETTI/MASSEROTTI/RENSO/SPINSANTI 35

haben die ontologiegestützte Suche in geographischen Daten-

banken beschrieben. STAAB 36 untersuchte Ontologien für eine grundsätzliche Anwendung in einem ontologiebasierten Wissensmanagementsystem. Eine Kombination mit CaseBased Reasoning wurde jedoch in keiner der angegebenen Veröffentlichungen erwähnt.

30

Ontologien berücksichtigen die Semantik der Hintergrundinformationen in Bezug auf die Konzepte, die Ontologien beinhalten. Vgl. EIRINAKI/MAVROEIDIS/TSATSARONIS/VAZIRGIANNIS (2005), S. 149.

31

Vgl. ZELEWSKI (2005), S. 115 f.

32

Vgl. LIN/HARDING/SHAHBAZ (2004), S. 5099 ff.

33

Vgl. VOUROS/EUMERIDOU/TSELIOS/KOTIS (2005), S. 691 ff.

34

Vgl. LEFEBVRE/GAUTHIER/TADIE/DUC/ACHABA (2005), S. 845 ff.

35

Vgl. BAGLIONI/GIOVANNETTI/MASSEROTTI/RENSO/SPINSANTI (2008), S. 31 ff.

36

Vgl. STAAB (2002), S. 194 ff.

Einführung in den Problembereich technikgestützten Managements von Projektwissen

9

Das Case-Based Reasoning wurde unter anderem von LEAKE 37 untersucht, der umfangreiche Forschungsarbeiten zu dieser Technik durchgeführt hat und speziell in den Bereichen der Entwicklung und der Erklärung von Anwendungen des Case-Based Reasonings tätig ist. Der Einsatz von Case-Based Reasoning zur Wiederverwendung von Projektwissen wurde von KURBEL/DORNHOFF 38 für die Aufwandschätzungen bei Softwareentwicklungsprojekten untersucht. Die Ähnlichkeit zwischen Softwareentwicklungsprojekten, die als Fälle für die Durchführung des Case-Based Reasonings genutzt wurden, wurde anhand von quantitativen und qualitativen Attributen dieser Fälle beurteilt. Die quantitativen Attribute beinhalteten numerische Werte. Die qualitativen Attribute beinhalteten natürlichsprachliche Formulierungen. Die Berechnung der Werte für die Ähnlichkeit zwischen zwei Attributswerten wird jedoch nicht konkretisiert. Insbesondere die Berechnung dieser Werte bei qualitativen Attributen bleibt offen. Es wird zwar angeführt, dass die Ähnlichkeit zwischen Werten von qualitativen Attributen als asymmetrische Relation 39 betrachtet werden kann, wie man konkret den Ähnlichkeitswert berechnet, bleibt jedoch unklar. Wünschenswert wäre eine Untersuchung, welche gezielt die Verwendung von natürlichsprachlich repräsentiertem Projektwissen behandelt und die Berechnung der Werte für die Ähnlichkeit zwischen Fällen konkretisiert, die auch qualitative Attribute beinhalten. Diese Untersuchung wird im Folgenden durchgeführt. Ansätze zur Berücksichtung der Semantik im Rahmen des Case-Based Reasonings gab es bereits von DE MÁNTARAS/PLAZA 40 , die die Fälle einer Fallbasis als Knoten in einer Hierarchie betrachtet haben. Eine Ontologie wurde hier jedoch nicht verwendet. GÓMEZALBARRÁN/GONZÁLEZ-CALERO 41 haben die Semantik im Rahmen des Case-Based Reaso37

Vgl. LEAKE (1996) u. AAAI (2008). Aktuelle Forschungsergebnisse zum Case-Based Reasoning werden regelmäßig im Rahmen von Konferenzen und Workshops veröffentlicht. Dazu gehören z.B. International Joint Conference on Artificial Intelligence (IJCAI), International Conference on Case-Based Reasoning (ICCBR), Association for the Advancement of Artificial Intelligence (AAAI), New Zealand Case-Based Reasoning Workshop, Florida Artificial Intelligence Research Society Annual Conference (FLAIRS) und European Conference on Artificial Intelligence (ECAI).

38

Vgl. KURBEL/DORNHOFF (1993) u. KURBEL/DORNHOFF (1992).

39

Bei der Erklärung der asymmetrischen Relation verweisen KURBEL/DORNHOFF auf TVERSKY, nach dem die asymmetrische Relation dadurch gekennzeichnet ist, dass die Ähnlichkeit von einem Merkmal a zu einem Merkmal b ungleich zur Ähnlichkeit von diesem Merkmal b zu diesem Merkmal a sein kann. TVERSKY führte beispielhafte Befragungen durch, um die Asymmetrie von Ähnlichkeiten zu untersuchen. Vgl. KURBEL/DORNHOFF (1993), S. 1058 f. u. TVERSKY (1977).

40

Vgl. DE MÁNTARAS/PLAZA (1997), S. 24.

41

Vgl. GÓMEZ-ALBARRÁN/GONZÁLEZ-CALERO (2001), S. 479 ff.

10 Einführung in den Problembereich technikgestützten Managements von Projektwissen nings mit Hilfe der Bereitstellung einer domänenspezifischen Terminologie berücksichtigt, die als Rahmenwerk für die Speicherung von Fällen genutzt wurde. Eine Zusammenführung von einer Ontologie für natürlichsprachlich repräsentiertes Projektwissen mit einem Case-Based Reasoning für die Wiederverwendung dieses Wissens ist hingegen neu. Aus dieser Zusammenführung entsteht die computergestützte Technik des ontologiegestützten Case-Based Reasonings, welche Erkenntnisse über Ontologien und Case-Based Reasoning zur Problemlösung nutzbar macht. Die wissenschaftliche Literatur beschäftigte sich bisher getrennt mit Ontologien und Case-Based Reasoning. Das wissenschaftliche Problem knüpft an die bisherige Trennung von Untersuchungen zur Ontologie und zum Case-Based Reasoning in der Projektmanagementdomäne an. Da gerade im Bereich des Projektmanagements viele natürlichsprachlich verfasste Dokumente erstellt und aufbewahrt werden, bietet sich die Kombination einer Ontologie mit einem Case-Based Reasoning an. Die Technik des ontologiegestützten Case-Based Reasonings eignet sich zur kostenmäßigen, zeitlichen und qualitativen Verbesserung im Vergleich zu herkömmlichen Techniken. Das Ziel der zeitlichen Verbesserung wird durch die Beschleunigung des Prozesses zur Wiederverwendung von Wissen über bereits durchgeführte Projekte erreicht. Durch ontologiegestütztes Case-Based Reasoning kann der Prozess beschleunigt werden, da eine manuelle Sichtung von Dokumenten oder eine nachträgliche Sammlung von Erfahrungen zu bereits durchgeführten Projekten nicht mehr vorgenommen werden braucht. Das Projektwissen ist bereits in der Fallbasis gespeichert. Die Suche innerhalb dieser Fallbasis erfolgt computergestützt und benötigt nur wenige Sekunden. 42 Wenn das Ergebnis dieser Suche in Form eines ähnlichsten Falls vorliegt, können gemäß LUGER 43 Probleme oft mit sehr viel geringerem zeitlichen Aufwand gelöst werden, als zur Erstellung einer regel- oder modellbasierten Technik erforderlich wäre. Die Technik des ontologiegestützten Case-Based Reasonings beinhaltet eine computergestützte Suche. Eine computergestützte Suche, die mit Hilfe umfangreicher Algorithmen relevante Begriffe aus Dokumenten herausfindet, arbeitet laut WEITZER 44 schneller als eine von menschlichen Akteuren durchgeführte Suche.

42

Die genaue Zeit, die für das Retrieval aufgewendet wird, wird im späteren Verlauf der Untersuchung gemessen.

43

Vgl. LUGER (2003), S. 316.

44

WEITZER stellte dies im Rahmen der Untersuchung des Einsatzes von Metadaten für Internetsuchvorgänge fest. Vgl. WEITZER (2000).

Einführung in den Problembereich technikgestützten Managements von Projektwissen 11 Mit der neuen Technik wird der Ressourceneinsatz gegenüber einer herkömmlichen manuellen Suche reduziert. Das ontologiegestützte Case-Based Reasoning ermöglicht durch die Einsparung menschlichen Arbeitsaufwands eine Reduzierung des Werteeinsatzes. Die Anschaffung von Hard- und Software sowie der Arbeitsaufwand für SoftwareNutzung und Fallbasis-Pflege müssen der Einsparung gegengerechnet werden. 45 Die Einsparung menschlichen Arbeitsaufwands ergibt sich dadurch, dass das Case-Based Reasoning die Möglichkeit bietet, Informationen zu bereits durchgeführten Projekten aus diversen Dokumenten 46 computergestützt zu kodieren. Eine intensive, durch menschliche Akteure durchgeführte Wissensakquisition von bereits gespeicherten Informationen wird nicht benötigt. 47 Die gespeicherten Informationen können durch das CBR-System dauerhaft aufbewahrt und zwischen Akteuren geteilt werden. 48 Wenn Lösungen eines menschlichen Akteurs zu einer Reihe von Fällen aufgezeichnet werden, kann ein CBR-System bei einem neuen Fall den ähnlichsten bekannten Fall, der Informationen über die Lösung des Falls enthält, auswählen und wiederverwenden. 49 Im Gegensatz zur Wissensakquisition für ein regelbasiertes System muss das komplette relevante Wissen nicht als Wenn-Dann-Regeln repräsentiert werden. 50 Der Arbeitsaufwand wird auch dadurch verringert, dass eine extensive Analyse des Domänenwissens nicht erforderlich ist. Die Qualität der Fallidentifikation und -selektion wird erhöht, wenn deren Merkmale in größerem Maße als bei einer traditionellen Technik dazu geeignet sind, bestimmte Erfordernisse zu erfüllen. Durch ontologiegestütztes Case-Based Reasoning kann die Qualität der Suchergebnisse im Vergleich zur manuellen Fallidentifikation und -selektion erhöht werden, da Akteure nicht mehr nur das eigene inhaltliche Hintergrundwissen, sondern auch das Hintergrundwissen dritter zur Verfügung haben, um einen ähnlichsten Fall zu finden. Die Ontologiestützung ermöglicht eine weit umfangreichere Einbindung von Hintergrundwissen verschiedener Akteure. Somit ist die Voraussetzung gegeben, dass die At-

45

In den meisten Unternehmen entfallen mindestens 50% der gesamten IT-Kosten auf den menschlichen Arbeitsaufwand. Vgl. ABTS/MÜLDER (2009), S. 411. Daher kann angenommen werden, dass die Einsparungen menschlichen Arbeitsaufwands einen größeren Einfluss auf die Kosten haben als die Anschaffungen der Hard- und Software.

46

Wenn Projekte dokumentiert werden, ist bereits eine grundlegende Aufzeichnung von menschlichen Akteuren geschehen.

47

Vgl. LUGER (2003), S. 316.

48

Vgl. BERGMANN/ALTHOFF/BREEN/WESS/MANAGO/TRAPHÖNER/GÖKER (2003), S. 10.

49

Vgl. LUGER (2003), S. 310.

50

Vgl. PAL/SHIU (2004), S. 9; LUGER (2003), S. 289 u. WATSON (1997), S. 47.

12 Einführung in den Problembereich technikgestützten Managements von Projektwissen tributswerte des gefundenen ähnlichsten Falls höhere Ähnlichkeiten zu den Attributswerten eines neuen Falls besitzen als wenn jeder Akteur nur das eigene Hintergrundwissen nutzt, um ähnliche Fälle zu identifizieren. Zusammenfassend ist die wissenschaftliche Problemstellung die Erstellung einer computergestützten Technik zur Wiederverwendung von Projektwissen, das in unstrukturierten, natürlichsprachlichen Texten gespeichert ist. Diese Technik soll ein ontologiegestütztes Case-Based Reasoning darstellen, um die Aufgabe der Fallidentifikation und -selektion zu erfüllen und die Diskrepanz zwischen dem betriebswirtschaftlichen Desiderat und dem State-of-the-art zu schließen.

1.4

Ziele der Untersuchung

In der Untersuchung wird eine computergestützte Technik zur Durchführung eines ontologiegestützten Case-Based Reasonings entwickelt. Diese Technik soll traditionelle Techniken zur Identifikation von hinreichend ähnlichen Fällen und Selektion von einem ähnlichsten Fall ersetzen können. Im Rahmen der Entwicklung dieser Technik werden Ähnlichkeitsindikatoren und ein Algorithmus zur Aggregation von Ähnlichkeitswerten entwickelt. Die Ähnlichkeitsindikatoren erstrecken sich auf die inhaltliche Dimension des repräsentierten Wissens. Sie sollen die Semantik von Attributswerten offenlegen, um einen Vergleich zwischen diesen zu ermöglichen. Die Attributswerte sollen zuvor aus dem natürlichsprachlich repräsentierten Projektwissen extrahiert und in einer Fallbasis bereitgestellt werden. In Anlehnung an das idealtypische Vorgehen eines CBR-Systems sollen zu einem neuen Fall hinreichend ähnliche Fälle aus der Fallbasis gesucht werden, um ihre Lösungen für den neuen Fall übernehmen oder anpassen zu können. 51 Die Fallidentifikation und -selektion anhand von Ähnlichkeitsindikatoren ist das grundlegende wissenschaftliche Problem der Untersuchung. Das Anschlussproblem, die Fallanpassung, wird nicht betrachtet. Zur Lösung des wissenschaftlichen Problems sollen ein Vorgehensmodell und ein Prototyp für ein ontologiegestütztes CBR-System zur Identifikation von hinreichend ähnlichen Fällen und Selektion von einem ähnlichsten Fall im Bereich des natürlichsprachlich repräsentierten Projektwissens entwickelt werden. Die Machbarkeit des ontologiegestützten Case-Based Reasonings soll mit Hilfe eines zu entwickelnden Prototyps demonstriert werden.

51

Vgl. PUPPE/STOYAN/STUDER (2004), S. 621.

Einführung in den Problembereich technikgestützten Managements von Projektwissen 13 1.5

Aufbau der Untersuchung

Die Untersuchung setzt sich aus zwei Hauptbestandteilen zusammen. Im ersten Teil erfolgt eine Erläuterung der Grundlagen für die Problembearbeitung. Der Schwerpunkt liegt hier auf der Erstellung von Arbeitsdefinitionen zum Projektmanagement, zu Ontologien und zum Case-Based Reasoning. Im zweiten Teil erfolgt die Planung und Durchführung des ontologiegestützten Case-Based Reasonings. Im Rahmen eines Vorgehensmodells wird die Technik entwickelt, um eine Fallidentifikation und -selektion im Rahmen eines ontologiegestützten Case-Based Reasonings für die Wiederverwendung natürlichsprachlich repräsentierten Projektwissens auszuführen. Basierend auf diesem Vorgehensmodell werden in sequentieller Abfolge der Entwurf, das Konzept, die Implementierung und anschließende Tests des ontologiegestützten CBR-Systems vorgenommen. Im Entwurf wird das ontologiegestützte CBR-System analysiert und es werden jeweils für ein Ontologie-Tool und ein CBR-Tool Anforderungen festgelegt. Das Ergebnis sind zwei Anforderungskataloge, die schriftlich fixierte Anforderungen an das jeweilige Tool enthalten. Im Konzept werden auf Grundlage dieser Anforderungskataloge jeweils ein Ontologie-Tool und ein CBR-Tool ausgewählt. Im Rahmen der Implementierung wird eine exemplarische Fallbasis erstellt, die unternehmensspezifisches Projektwissen in Form von Fällen enthält. Mit Hilfe des ausgewählten Ontologie-Tools wird eine domänenspezifische Ontologie erstellt, die Interpretationsvorschriften für das natürlichsprachlich repräsentierte Wissen enthält. Operationale Ähnlichkeitsmaßstäbe werden für die Beurteilung der Ähnlichkeit zwischen Fällen anhand von sowohl quantitativen als auch qualitativen Fallattributen festgelegt. Anschließend erfolgt die Erstellung eines Algorithmus, der ein Verfahren zur Aggregation von lokalen Ähnlichkeitswerten zu globalen Ähnlichkeitswerten enthält. Das Ergebnis der Implementierung ist ein Prototyp, der zur Demonstration der grundsätzlichen Machbarkeit einer ontologiegestützten Fallidentifikation und -selektion genutzt wird. Anhand dieses Prototyps werden Tests mit Fällen aus der Domäne Projektmanagement durchgeführt.

14 Einführung in den Problembereich technikgestützten Managements von Projektwissen Der Aufbau der Untersuchung wird mit Hilfe eines PETRI-Netzes 52 veranschaulicht. Um einen detaillierten, aber nicht zu komplexen Überblick zum Aufbau der Untersuchung zu geben, werden die bedeutensten Kapitel bis zur dritten Ebene des Inhaltsverzeichnisses in Form eines Rechtecks dargestellt, bei welchem es sich um eine Transition handelt. Die Transitionen stehen für die Ausarbeitung eines Kapitels. Alle Vor- und Nachbedingungen der Transitionen werden als Kreise dargestellt. Die Verbindungen zwischen Vorbedingungen und Transitionen und zwischen Transitionen und Nachbedingungen werden mit gerichteten Pfeilen dargestellt. Vorbedingungen sind hier als notwendiger Input zu verstehen, um die Ausarbeitung eines Kapitels durchzuführen. Z.B. kann das betriebswirtschaftliche Desiderat nur ausgearbeitet werden, wenn allgemeine ökonomische Anforderungen gegeben sind.

52

Ein PETRI-Netz ist eine Modellierungsmethode, die zum ersten Mal in der Dissertation von CARL ADAM PETRI mit dem Titel „Kommunikation mit Automaten“ aus dem Jahr 1962 angewendet wurde. Jedes PETRI-Netz besitzt einen von mehreren unterschiedlichen Typen. Die drei Haupttypen sind das Elementary Net System, das Place/Transition System und die High-Level-Models, wie z.B. Predicate/Transition-Nets und Coloured PETRI Nets. Vgl. REISIG/ROZENBERG (1998), S. 12. Place/ Transition-PETRI-Netze sind die verbreiteste Form von PETRI-Netzen. Vgl. REISIG/ROZENBERG (1998), S. 122. Um den Aufbau der Untersuchung zu modellieren, wird daher ein Place/TransitionPETRI-Netz verwendet. Bei diesem handelt es sich um einen endlichen gerichteten Graph. In diesem Graph wechseln sich Knoten des Typs Place und Transition ab. Places werden als Kreise und Transitionen als Balken oder Rechtecke dargestellt. Places, deren gerichtete Pfeile zu einer Transition t hinführen, werden als Vorbedingungen oder Inputplaces von t bezeichnet. Places, zu denen gerichtete Pfeile von einer Transition t hinführen, werden als Nachbedingungen oder Outputplaces von t bezeichnet. Ein Place kann gleichzeitig Vor- und Nachbedingung sein. Bei PETRI-Netzen werden Token berücksichtigt. Wenn auf jeder Vorbedingung der Transition t ein Token liegt, und zwar mindestens k Token auf einer k-fachen Vorbedingung, dann ist t feuerbar. Eine feuerbare Transition feuert, indem sie jeweils ein Token von jeder Vorbedingung entfernt und jeweils einen Token auf jede Nachbedingung legt. Vgl. WIMMEL (2008), S. 20. In der dargestellten Modellierung wird angenommen, dass der Ablauf der Untersuchung jede Transition feuerbar macht. Jede Transition stellt ein Kapitel dar. Das Feuern einer Transition entpricht der Ausarbeitung eines Kapitels, welches die Erfüllung der angegebenen Vorbedingungen voraussetzt und die Erfüllung der angegebenen Nachbedingungen bewirkt. Die Token werden in der Grafik nicht explizit dargestellt. Weitere Informationen zu PETRI-Netzen befinden sich in REISIG/ROZENBERG (1998), WIMMEL (2008), GIRAULT/VALK (2003) u. DAVID/ALLA (2005).

Einführung in den Problembereich technikgestützten Managements von Projektwissen 15

Abbildung 1: Aufbau der Untersuchung in Form eines PETRI-Netzes

Grundlagen für die Problembearbeitung

2 2.1

17

Grundlagen für die Problembearbeitung Projekte und Projektmanagement als relevanter Realitätsbereich

Ein Projekt ist ein Vorhaben, bei dem innerhalb einer definierten Zeitspanne ein definiertes Ziel erreicht werden soll und das sich dadurch auszeichnet, dass es im Wesentlichen durch die Einmaligkeit der Bedingungen und der Vorgaben in ihrer Gesamtheit gekennzeichnet ist. 53 Ein Projekt kann zum Beispiel zur Schaffung eines Sachguts oder einer Dienstleistung dienen. 54 Der Erfolg von Projekten kann essentiell für das Fortbestehen eines Unternehmens sein. Projektmanagement ist eine Methode, die Aktivitäten für Definition, Planung, Kontrolle und Abschluss eines Projekts umfasst, mit dem Ziel, eine sachgerechte, termingerechte und kostengerechte Abwicklung von Projekten zu erreichen. 55 Eine standardisierte Methode für das Projektmanagement wird in dem am PROJECT MANAGEMENT INSTITUTE (PMI) entwickelten PMBOK-Guide (A Guide to the Project Management Body of Knowledge) definiert, der als IEEE Standard (1490-1998) international anerkannt ist. 56 Der PMBOK-Guide fokussiert sich auf die Prozessperspektive im Projektmanagement. 44 Projektmanagement-Prozesse werden in neun Wissensgebieten klassifiziert. Die Klassifizierung durch Wissensgebiete deutet auf die enge Beziehung zwischen Projektmanagement und Wissensmanagement hin. Es liegt nahe, den wissensbasierten Fokus des PMBOK-Guides zu erweitern, indem man Akteure mit einer praktischen Technik unterstützt, um bei der Durchführung neuer Projekte Erfahrungen von bereits durchgeführten Projekten wiederzuverwenden. Case53

Die Definition gemäß DIN 69901 (2009) beinhaltet die Einmaligkeit der Bedingungen in ihrer Gesamtheit. Diese Definition ist nicht unproblematisch. Die Einmaligkeit der Bedingungen, die von außen auf ein Projekt einwirken, ist bei Projekten nur schwer nachweisbar und steht im Widerspruch zu Effizienzinstrumenten des Projektmanagements, wie z.B. bei der Konvoi-Bauweise. Da auch in anderen Definitionen, wie z.B. bei MADAUSS (2000), S. 9 f. u. 37, die Eigenschaft der Einmaligkeit von Bedingungen genannt wird, sind die Definitionen des Begriffs „Projekt“ derzeit nicht zufrieden stellend. Deshalb wurde in dieser Untersuchung eine Arbeitsdefinition erstellt, die die Einmaligkeit von Bedingungen in ihrer Gesamtheit erweitert um die Einmaligkeit von Bedingungen und Vorgaben in ihrer Gesamtheit. Zwei verschiedene Vorhaben können somit selbst dann als Projekte bezeichnet werden, wenn sie denselben äußeren Bedingungen unterliegen, jedoch voneinander abweichende Vorgaben besitzen. Dass zwei verschiedene Vorhaben voneinander abweichend sind, ist z.B. gegeben, wenn unterschiedliche Ressourcen-, Zeit- oder Budgetvorgaben existieren.

54

Vgl. PMI (2004), S. 5.

55

Vgl. BURGHARDT (2007), S. 10 f.

56

Vgl. PMI (2004).

S. Beißel, Ontologiegestütztes Case-Based Reasoning, DOI 10.1007/978-3-8349-6232-4_2, © Gabler Verlag | Springer Fachmedien Wiesbaden GmbH 2011

18

Grundlagen für die Problembearbeitung

Based Reasoning scheint dafür ideal, da eine heterogene Fallbasis ein sehr flexibles Format bietet, um das variierende Wissen, das in Beziehung zu den neun Wissensgebieten steht, und die verschiedenen Entscheidungen der Akteure zu speichern. Dies ermöglicht den Umgang mit verschiedenen Fall-Typen bei der Entscheidungsfindung und eine Verknüpfung von neuen Fällen mit bereits durchgeführten Fällen, um Ähnlichkeiten zwischen diesen zur Unterstützung des Entscheidungsprozesses hervorzuheben.

Abbildung 2: Wissensgebiete im PMBOK-Guide 57 57

Vgl. PMI (2004), S. 11.

Grundlagen für die Problembearbeitung 2.2 2.2.1

19

Wissensmanagement Natürlichsprachliche Repräsentation von Projektwissen

Um Projektwissen begrifflich einzugrenzen, gilt es zunächst, Wissen zu definieren. Wissen ist ein Begriff, der in verschiedenen Disziplinen mit verschiedenen Definitionen belegt wurde. Aus Sicht der Informatik steht Wissen für eine Vernetzung von Informationen, mit welchen ein bestimmter Zweck unter spezifischen Kontextbedingungen verfolgt werden kann. 58 Laut BERGMANN 59 ist Wissen eine Menge verknüpfter Informationen mit Pragmatik und setzt Informationen in einen aufgabenbezogenen oder zielorientierten Kontext. Wissen in der Betriebswirtschaft wird als das Ergebnis der Verarbeitung von Daten und Informationen durch Intelligenz und Lernen verstanden. 60 Wissen ist die Gesamtheit der Kenntnisse und Fähigkeiten, die Akteure zur Lösung von Problemen einsetzen.61 Wissen ist eine zweckorientierte Vernetzung von Informationen 62 und abhängig vom jeweiligen Kontext 63 . In der Philosophie wird Wissen als höchste Stufe der Erkenntnis betrachtet.64 Nach BELL 65 ist Wissen eine Sammlung in sich geordneter Aussagen über Fakten oder Ideen, die ein vernünftiges Urteil oder ein erarbeitetes Ergebnis zum Ausdruck bringen und anderen durch irgendein Kommunikationsmedium in systematischer Form übermittelt werden. In der Psychologie ist Wissen ein weitverzweigtes Netzwerk von Beziehungen zwischen Aussageeinheiten. 66 Zum Wissen gehören laut KRAAK 67 Kenntnisse, Meinungen, Auffassungen, Bewertungen und Ziele. Für den Kontext der Untersuchung gilt es eine Definition zu finden, die die verschiedenen Wissensdefinitionen und den thematischen Schwerpunkt der Untersuchung im

58

Vgl. STEINMÜLLER (1993), S. 236.

59

Vgl. BERGMANN (2002), S. 26. Laut BERGMANN unterscheidet sich Wissen dadurch von Informationen, dass Informationen im Gegensatz zu Wissen unabhängig von Pragmatik sind. Unter Pragmatik ist die Verwendung von Begriffen zu verstehen, z.B. die Verwendung als Behauptung oder Frage. Zur Pragmatik vgl. VOSSENKUHL (1993), S. 85.

60

Vgl. FELBERT (1998), S. 122.

61

Vgl. PROBST/RAUB/ROMHARDT (2010), S. 23.

62

Vgl. REHÄUSER/KRCMAR (1996), S. 5.

63

Vgl. BENDLER (2002), S. 11; GÜLDENBERG (2003), S. 247 u. NONAKA/TAKEUCHI (2001), S. 70.

64

Vgl. KANT (2005), S. 27.

65

Vgl. BELL (1985), S. 180.

66

Vgl. BUDE (1987), S.1229.

67

Vgl. KRAAK (1991), S.12.

20

Grundlagen für die Problembearbeitung

Bereich des Wissensmanagements berücksichtigt. Im weiteren Verlauf der Untersuchung soll Wissen verstanden werden als eine Vernetzung von kontextbezogenen und zweckorientierten Informationen, die zueinander in Beziehung stehen und sich aus den Erkenntnissen 68 von Akteuren oder Gruppen von Akteuren ergeben. Informationen bilden demnach den zentralen Bestandteil des Wissens. Informationen sind ein notwendiges Medium oder Material für die Bildung von Wissen, denn Informationen liefern neue Gesichtspunkte zur Interpretation von Geschehnissen oder Dingen und enthüllen zuvor nicht erkannte Bedeutungen. 69 Projektwissen ist Wissen im Kontext des Projektmanagements. Projektwissen besteht somit aus einer dynamischen Vernetzung von projektbezogenen Informationen, die zueinander in Beziehung stehen und sich aus den Erkenntnissen von Akteuren ergeben. In der Literatur wird Projektwissen aus der zustandsorientierten und prozessorientierten Perspektive betrachtet. 70 Aus der zustandsorientierten Perspektive wird Projektwissen ressourcenorientiert oder ergebnisorientiert betrachtet. Bei der ressourcenorientierten Betrachtung wird Projektwissen als jenes Wissen gesehen, welches für die Ausführung von Projektmanagement notwendig ist und der Zielerreichung des Projektes dient. Die ergebnisorientierte Betrachtung geht davon aus, dass Wissen im Projektergebnis enthalten ist, z.B. in Form einer Projektdokumentation. Gemäß der prozessorientierten Betrachtung verändert der Prozess des Projektmanagements bestehendes Wissen, z.B. die Erfahrungen eines Akteurs. Unter Berücksichtigung der verschiedenen Betrachtungsweisen kann unter Projektwissen jenes Wissen verstanden werden, welches als Ressource für zielgerichtetes Handeln im Projekt eingesetzt wird, im Projektergebnis enthalten ist oder auf Grund des Prozesses der Projektabwicklung einer Veränderung unterworfen ist. Projektwissen kann auch Erfahrungswissen sein. Erfahrungswissen ist spezielles Wissen, das ein Akteur oder eine Gruppe von Akteuren in einem bestimmten Problemlösungskontext erworben hat. 71 Die Gruppe von Akteuren besteht in diesem Fall aus Projektbeteiligten, die Wissen im Problemlösungskontext eines Projekts erworben haben.

68

Erkenntnisse sollen hier als das durch einen Akteur bewertete Ergebnis einer Handlung desselben oder eines anderen Akteurs verstanden werden.

69

Vgl. NONAKA/TAKEUCHI (2001), S. 70.

70

Vgl. HUMPL (2004), S. 91 f.

71

Vgl. BERGMANN (2002), S. 28.

Grundlagen für die Problembearbeitung 2.2.2

21

Definition von Wissensmanagement

Auch für den Begriff Wissensmanagement existieren zahlreiche Definitionsansätze. Laut BELLIGER/KRIEGER 72 beschäftigt sich Wissensmanagement mit allen Aspekten der Wertschöpfungskette, in denen Kommunikation, Verständigung, Kooperation und Umgang mit unstrukturiertem Wissen, Know-how, komplexen Entscheidungsprozessen und voraussehbaren Faktoren eine Rolle spielen. MAIER 73 hat verschiedene Definitionen von Wissensmanagement analysiert und einen übergreifenden Definitionsansatz erstellt. Dabei hat er personenorientierte und technologieorientierte Betrachtungsweisen des Wissensmanagements berücksichtigt. Wissensmanagement wurde definiert als eine Managementfunktion, die verantwortlich ist für die regelmäßige Selektion, Implementierung und Evaluierung von zielorientierten Wissensstrategien, die zum Ziel haben, den Umgang einer Organisation mit internem und externem Wissen zu verbessern, um die Performance der Organisation zu verbessern. Die Implementierung von Wissensstrategien umfasst alle personenorientierten, organisatorischen und technologischen Instrumente, die geeignet sind, um dynamisch den organisationsweiten Stand der Kompetenz, Bildung und Lernfähigkeit der Mitglieder zu verbessern und kollektive Intelligenz zu entwickeln. 74 Nach PETERSON 75 ist Wissensmanagement eine gezielte Steuerung der Teilprozesse der Wissensgenerierung, des Wissenstransfers und der Wissensanwendung im Sinne übergeordneter, unternehmerischer Ziele durch Schaffung geeigneter organisationaler und prozessualer Rahmenbedingungen sowie deren Integration in einen ganzheitlichen Prozess zur Förderung des bewussten Umgangs mit der Ressource Wissen in der unternehmerischen Wertschöpfung. Die Fokussierung der aufgeführten Definitionen liegt auf der Verbesserung des Umgangs mit Wissen durch Akteure mit dem Ziel, die Ergebnisse und Abläufe von Organisationen so zu gestalten, dass Ressourcen effektiv genutzt werden können. Demnach ist auch der Einsatz des ontologiegestützten Case-Based Reasonings als eine Ausgestaltung des Wissensmanagements zu betrachten.

72

Vgl. BELLIGER/KRIEGER (2007), S. 11.

73

Vgl. MAIER (2007), S. 52 ff.

74

Vgl. MAIER (2007), S. 57.

75

Vgl. PETERSON (2001), S. 45 f. Weitere Definitionen zum Begriff Wissensmanagement finden sich zudem bei ECK (1997), SVEIBY (1998) u. PROBST/RAUB/ROMHARDT (2010).

22 2.3 2.3.1

Grundlagen für die Problembearbeitung Übersicht über die Techniken für die Problemlösung Ontologiestützung

2.3.1.1 Definition von Ontologien

Das Case-Based Reasoning wird durch die Verwendung einer Ontologie gestützt, die als Mittel zur Strukturierung von Informationen verwendet wird. Die Ontologie soll in der Untersuchung die Funktion eines „Adapters“ haben, der vorhandenes Wissen strukturiert und für die Nutzung in einer fallbasierten Verarbeitung zur Verfügung stellt. Der Begriff der Ontologie hat seinen Ursprung in der Philosophie, wo er geprägt ist durch die Lehre des Seins oder der Existenz. Die philosophische Quelle der Ontologie geht zurück ins antike Griechenland. ARISTOTELES, der als Erfinder der Metaphysik als eigenständige Disziplin angesehen wird, definierte die Ontologie als die Frage nach dem Sein des Seienden. 76 In der Informatik werden Ontologien nicht so allgemein definiert wie in der Philosophie, da hier eine eher anwendungsbasierte Sichtweise verfolgt wird. Hier dienen Ontologien dazu, das für eine Aufgabenerfüllung benötigte Wissen über Objekte oder Ereignisse der Realität zu erfassen und zu strukturieren. Mit einer Ontologie kann das Wissen von relevanten Begriffen einer Domäne gespeichert werden. Dies geschieht unter Berücksichtigung der Semantik von Begriffen und der Beziehungen zwischen den Begriffen. Ontologien im Kontext der Informatik sind eine formalsprachliche und explizite Spezifikation einer gemeinsam benutzten Konzeptualisierung. 77 Diese Beschreibung kann wie folgt detailliert werden: 78 Eine Konzeptualisierung beschreibt ein abstraktes Modell eines Realweltphänomens. Formalsprachlich bezieht sich auf die Tatsache, dass es sich bei einer Ontologie um eine maschinenlesbare Form der Wissenrepräsentation handelt. Explizit bedeutet, dass alle Konzepte und ihre Beziehungen, die in der Spezifikation genutzt werden, ausdrücklich beschrieben und definiert werden. Gemeinsam benutzt bedeutet, dass das in 76

Vgl. SEIDL (2001), S. 236.

77

Vgl. GRUBER (1993), S. 199 u. STUDER/BENJAMINS/FENSEL (1998), S. 185. Diese Arbeitsdefinition ergibt sich aus den von Gruber aufgeführten Definitionsvarianten: „A specification of a representational vocabulary for a shared domain of discourse - definitions of classes, relations, functions, and other objects - is called an ontology.” und „An ontology is an explicit specification of a conceptualization.“ Dass eine Ontologie formalsprachlich sein muss, ist in den Definitionsvarianten von GRUBER nicht eindeutig gefordert. Es gibt jedoch Andeutungen von GRUBER, die auf eine Formalsprachlichkeit der Ontologie hinweisen. Er benutzt mehrfach den Ausdruck „formal axioms“. Vgl. GRUBER (1993) S. 199 u. GRUBER (1995) S. 908.

78

Vgl. STUDER/BENJAMINS/FENSEL (1998), S. 185 u. DAEMI-AHWAZI (2005), S. 12.

Grundlagen für die Problembearbeitung

23

der Ontologie eingebettete Wissen von einer Gruppe akzeptiert wird und einen Konsens verschiedener individueller Sichtweisen abbildet. Die Definitionsansätze von GRUBER sind jedoch kritisch zu betrachten. In seiner Definition bleibt unbestimmt, was unter Spezifikation zu verstehen ist und ob diese wirklich formalsprachlich verfasst werden muss. 79 Laut GUARINO/GIARETTA 80 handelt es sich bei einer Ontologie nicht generell um eine Spezifikation einer Konzeptualisierung, sondern vielmehr um die Spezifikation einer partitiellen Darstellung einer Konzeptualisierung. In der Definition von GRUBER wird außerdem nicht deutlich, dass die Erstellung einer Ontologie oft ein kooperativer Prozess ist, an dem mehrere Akteure beteiligt sind. 81 Auf Grund dieser Kritikpunkte wird die folgende Arbeitsdefinition von ZELEWSKI als treffender angesehen. Laut ZELEWSKI 82 ist eine Ontologie „eine explizite und formalsprachliche Spezifikation derjenigen sprachlichen Ausdrucksmittel (für die Konstruktion repräsentationaler Modelle), die nach Maßgabe einer von mehreren Akteuren gemeinsam verwendeten Konzeptualisierung von realen Phänomenen, die in einem subjekt- und zweckabhängig eingegrenzten Realitätsausschnitt als wahrnehmbar oder vorstellbar gelten und für die Kommunikation zwischen den o.a. Akteuren benutzt oder benötigt werden, für „sinnvoll“ erachtet werden“. Anhand der Gegenstandsbereiche von Ontologien werden verschiedene Arten von Ontologien unterschieden. ZELEWSKI 83 unterscheidet zwischen fünf Ontologie-Arten: Die Domänen-Ontologie dient der Spezifikation von branchenspezifischem Domänenwissen, die Commonsense-Ontologie beinhaltet allgemeines Weltwissen, die Repräsentations- oder Meta-Ontologie spezifiziert die Ausdrucksmöglichkeiten von Repräsentations- oder Modellierungssprachen, die Aufgaben-Ontologie dient der Spezifikation von allgemeinen Aufgabentypen, und die Methoden-Ontologie beinhaltet Terme und Syntax für Problemlösungsmethoden. Auch FENSEL 84 unterscheidet zwischen denselben fünf Ontologie-Arten wie ZELEWSKI, erwähnt aber darüber hinaus noch Ontologien für Metadaten, die das Vokabular zur Beschreibung von Online-Inhalten liefern.

79

Vgl. ZELEWSKI (2005), S. 144 f. u. Fußnote 77, S. 22.

80

Vgl. GUARINO/GIARETTA (1995), S. 30.

81

Vgl. STUDER/BENJAMINS/FENSEL (1998), S. 186.

82

ZELEWSKI (2005), S. 153. [Die Hervorhebungen wurden nicht übernommen.]

83

Vgl. ZELEWSKI (1999), S. 12.

84

Vgl. FENSEL (2004), S. 5 f.

24

Grundlagen für die Problembearbeitung Eine Domäne ist ein Realitätsausschnitt, der abhängig oder unabhängig von einem

modellierenden Subjekt sein kann. 85 In der Informatik handelt es sich bei einer Domäne zum Beispiel um einen Realitätsausschnitt, in dem ein Computersystem eingesetzt werden kann. Ontologien formalisieren die intensionalen Aspekte einer Domäne, wobei der extensionale Teil von einer Wissensbasis bereitgestellt wird, die Aussagen über Instanzen beinhaltet. 86 Im Fokus der Untersuchung steht eine Domänen-Ontologie, die sich auf die Domäne Projektmanagement bezieht. 2.3.1.2 Repräsentationssprachen

Die Repräsentation von Spezifikationswissen durch ein Ontologie-Tool erfolgt in maschinenlesbarer Form, die als Repräsentationssprache bezeichnet wird. Ein Ontologie-Tool kann entweder eine proprietäre oder eine standardisierte Repräsentationssprache nutzen. Was mit einer Repräsentationssprache ausgesagt werden kann, die Ausdrucksstärke87 , wird durch die Menge der behauptbaren Propositionen 88 bestimmt. 89 Im Folgenden werden verbreitete Standards für Repräsentationssprachen und Unterschiede in deren Ausdrucksstärken erläutert: DAML+OIL setzt sich aus den beiden Sprachen DAML 90 (DARPA Agent Markup Language) und OIL 91 (Ontology Inference Layer) zusammen. Die Entwicklung von DAML wurde durch die DEFENSE ADVANCED RESEARCH

PROJECTS AGENCY (DARPA) durchgeführt, welche die zentrale Forschungs- und

Entwicklungsorganisation des US-amerikanischen DEPARTMENT

OF

DEFENSE (DoD) ist.

Die Sprache DAML wurde als Erweiterung zur Extensible Markup Language (XML) und 85

Vgl. ZELEWSKI/SCHÜTTE/SIEDENTOPF (2001), S. 212.

86

Ontologien können als Zeichensystem angesehen werden, das aus einem Lexikon (u.a. mit alphanumerischen Zeichen), Referenzfunktionen (um die Einträge aus dem Lexikon mit Klassen oder Relationen zu verknüpfen), einer Menge von Klassen, einer Menge von Relationen (u.a. zur Bildung einer Taxonomie) und einer Menge von Axiomen besteht. Eine Wissensbasis besteht aus einem Lexikon (siehe oben), einer Referenzfunktion (um die Einträge aus dem Lexikon mit Instanzen zu verknüpfen), einer Menge von Instanzen, einer Zugehörigkeitsfunktion (zur Zuordnung von Instanzen zu Klassen), einer Menge von Wissensbasis-Axiomen und einer Ontologie (wie oben dargestellt). Vgl. MAEDCHE/STAAB/STOJANOVIC/STUDER/SURE (2001), S. 5 f.

87

Synonyme zur Ausdrucksstärke sind Expressiveness, Expressive Power, Descriptive Power, Modeling Power, Expressibility, Completeness, Flexibility. Vgl. PATIG (2006), S. 59.

88

Im Bereich der Repräsentationssprachen von Ontologien können als Propositionen zur Beurteilung der Ausdrucksstärke z.B. die Unterstützung von Axiomen, Meta-Klassen, Instanzen und die Betrachtung von Eigenschaften genutzt werden. Vgl. hierzu SU/ILEBREKKE (2002), S. 767.

89

Vgl. PATIG (2006), S. 59.

90

Vgl. DARPA (2003).

91

Vgl. VAN HARMELEN/HORROCKS (2000).

Grundlagen für die Problembearbeitung

25

zum Resource Description Framework (RDF) entwickelt. OIL wurde im Rahmen des Information Society Technologies (IST) Programms der EUROPÄISCHEN UNION entwickelt. DAML+OIL wird nicht mehr weiterentwickelt, da die Entwickler zur Unterstützung von OWL übergegangen sind. 92 OWL ist eine Überarbeitung von DAML+OIL. 93 Die Ausdrucksstärke von DAML+OIL ist höher als die des Vorgängers OIL. 94 Zum Beispiel kann man in DAML+OIL im Gegensatz zu OIL ausdrücken, dass alle Personen, die den Wohnort Italien haben, eine Art von Personen sind, die maximal ein Land als Wohnort haben: Person ˆ Wohnort.^Italien` Ž d 1Wohnort 95 OWL steht für Web Ontology Language. 96 Die Versetzung der Buchstaben im Ak-

ronym ergibt das Wort OWL, das im Englischen Eule bedeutet. OWL ist eine Spezifikation des WORLD WIDE WEB CONSORTIUMS (W3C). Das W3C entwickelt in erster Linie Protokolle und Richtlinien für das Internet. 97 OWL wurde für Applikationen entwickelt, die den Inhalt von Informationen verarbeiten, anstatt lediglich die Informationen für menschliche Akteure zu repräsentieren. OWL ermöglicht durch die Bereitstellung von zusätzlichem Vokabular zusammen mit formaler Semantik eine größere Maschineninterpretation von Web-Inhalten als XML, RDF und RDF-Schema (RDFS). OWL besitzt drei Subsprachen: OWL Lite, OWL DL und OWL Full. 98 OWL besitzt eine höhere Ausdrucksstärke als RDF(S), OIL und DAML+OIL. 99 Einige neue Funktionen von OWL umfassen z.B. die Kardinalität (z.B. „genau ein“) und die Symmetrie von Attributen. 100 Aber es sind dennoch Einschränkungen in der Ausdrucksstärke vorhanden, teilweise in Verbindung mit Ei-

92

Vgl. HAHN/ABELS/HAAK (2004), S. 30.

93

Vgl. W3C (2004).

94

Vgl. ARROYO/LARA/DING/STOLLBERG/FENSEL (2004), S. 7.

95

Vgl. HORROCKS/MCGUINNESS/WELTY (2003), S. 446.

96

Vgl. W3C (2004).

97

Vgl. W3C (2009).

98

OWL Lite benutzt lediglich eine Untermenge der Sprachfunktionen von OWL DL und OWL Full und besitzt mehr Einschränkungen als diese. Z.B. können Klassen in OWL Lite nur begrenzt definiert und eingeschränkt werden. Außerdem kann die Kardinalität nur mit Null oder Eins angegeben werden, wenn sie explizit festgelegt wird. OWL DL und OWL Full besitzen dasselbe Vokabular. OWL DL besitzt gegenüber OWL Full jedoch einige Einschränkungen. Z.B. unterliegt OWL DL der Separation von Typen. Eine Klasse kann nicht gleichzeitig eine Instanz oder ein Attribut sein und ein Attribut kann nicht gleichzeitig eine Instanz oder eine Klasse sein. Vgl. W3C (2004).

99

Vgl. ARROYO/LARA/DING/STOLLBERG/FENSEL (2004), S. 7.

100

Vgl. GOLBECK/ALFORD/HENDLER (2005), S. 183.

26

Grundlagen für die Problembearbeitung

genschaften. 101 Z.B. können mit OWL bestimmte Verkettungen nicht mit einer Regel ausgedrückt werden, wie der Onkel ist der Bruder eines Elternteils.102 Hierzu müssen in OWL mehrere Regeln (hatElternteil und hatBruder) kombiniert werden, um diese Regel zu implizieren (hatOnkel). 103 Außerdem wird es nicht unterstützt, dass vererbte Werte als Standardwerte betrachtet werden und durch spezifischere Klassen in der Hierarchie überschrieben werden können (nicht-monotone Vererbung). 104 RDF steht für Resource Description Framework und ist eine formale Sprache zur Repräsentation von Informationen im World Wide Web. 105 RDF ist in XML geschrieben und eine Empfehlung des W3C. 106 RDF wird durch die Auszeichnungssprache RDFSchema (RDFS) erweitert, die es erlaubt, eine Grammatik sowie Interpretationsregeln für RDF-Aussagen festzulegen und RDF um zusätzliche, komplexe Metadaten anzureichern. 107 Die Ausdrucksstärke von RDF(S) gegenüber OIL ist begrenzt, denn RDF(S) ist vollständig als Untersprache von OIL enthalten. 108 OIL besitzt eine höhere Ausdrucksstärke für die Definition von Ontologien als RDF(S). 109 Frame Logic (F-Logic) ist eine formale Repräsentationssprache für Informationen, die ein logisches Fundament für frame-basierte und objekt-orientierte Sprachen bereitstellt. 110 F-Logic beseitigt mit dem logischen Fundament das Problem der fehlenden logischen Semantik bei objektorientierten Sprachen. 111

101

Vgl. HORROCKS/PATEL-SCHNEIDER (2003), Kapitel 4.1.

102

Vgl. HORROCKS/PATEL-SCHNEIDER/VAN HARMELEN (2003), S. 15.

103

Vgl. HORROCKS/PATEL-SCHNEIDER (2003), Kapitel 4.1.

104

Vgl. HORROCKS/PATEL-SCHNEIDER/VAN HARMELEN (2003), S. 25.

105

Vgl. W3SCHOOLS (2010a).

106

Vgl. W3SCHOOLS (2010b).

107

Vgl. E-TEACHING.ORG (2005).

108

Vgl. KLEIN (2004), S.18.

109

Vgl. ARROYO/LARA/DING/STOLLBERG/FENSEL (2004), S. 7.

110

Vgl. W3C (2006).

111

Vgl. KROGSTIE/HALPIN/SIAU (2005), S. 284. Mit der Prädikatenlogik in F-Logic kann Inferenz in objekt-orientierten Datenbanken ermöglicht werden. Vgl. MESTROVIC/CUBRILO (2009), S. 120.

Grundlagen für die Problembearbeitung

27

Die Semantic Web Rule Language (SWRL) ist eine Regelsprache für das semantische Web. 112 Es handelt sich um eine Kombination von OWL DL und OWL Lite mit einer Untersprache der Rule Markup Language. 113 Die Sprachen besitzen unterschiedliche Schlussfolgerungsmöglichkeiten, die für den Verwendungszweck in dieser Untersuchung jedoch nicht relevant sind, da die Schlussfolgerungen durch das CBR-Tool abgebildet werden. 2.3.1.3 Abgrenzung von alternativen Techniken

Neben Ontologien existieren weitere Techniken, die vergleichbare Ziele verfolgen. In diesem Kapitel wird dargestellt, welche Alternativen zur Nutzung von Ontologien in Frage kommen und ob Ontologien für den Untersuchungsgegenstand am besten geeignet sind. Betrachtet werden Metamodelle, Referenzmodelle, Terminologien, Nomenklaturen und Data Dictionaries, Taxonomien, Thesauri und konzeptuelle Modelle. Ein Metamodell ist ein sprachliches Beschreibungsmodell, das die formale Sprache zur formalsprachlichen Modellierung von Realitätsausschnitten spezifiziert. 114 Metamodelle haben genauso wie Ontologien den Zweck, sprachliche Ausdrucksmittel in Bezug auf die Konzeptualisierung von realen Phänomenen zu spezifizieren, unterscheiden sich aber z.B. darin, dass sich in Metamodellen neben der in der Arbeitsdefinition für Ontologien geforderten formalsprachlichen Spezifikation auch eine natürlichsprachliche Spezifikation verwenden lässt und dass Ontologien neben den in Metamodellen verwendeten terminologischen und syntaktischen Spezifikationsmitteln auch semantische Spezifikationsmittel verwenden. 115 Für den Untersuchungsgegenstand bedeutet dies, dass Ontologien auf Grund ihrer Formalsprachlichkeit 116 besser mit Computersystemen verarbeitet werden können. Die Verarbeitung mit einem Computersystem ist ein primärer Bestandteil des Untersuchungsgegenstands. Die zusätzliche Verwendung von semantischen Spezifikationsmitteln in Ontologien erlaubt die Berücksichtigung der Semantik von Begriffen. Zu den semanti-

112

Zu weiteren Informationen vgl. HORROCKS/PATEL-SCHNEIDER (2003) u. HORROCKS/PATEL-SCHNEIDER/BOLEY/TABET/GROSOF/DEAN (2004).

113

Die Rule Markup Language (RuleML) ist eine Auszeichnungssprache, um den Austausch von Regeln mit einer XML-Codierung zwischen Systemen zu spezifizieren. Vgl. RULEML (2010).

114

Vgl. BRUGGER (2005), S. 493 u. ZELEWSKI (1999), S. 7.

115

Vgl. ZELEWSKI (1999), S. 8 f.

116

Gemäß ZELEWSKI können Ontologien als eine formalsprachliche „Radikalisierung“ angesehen werden. Vgl. ZELEWSKI (2005), S. 196.

28

Grundlagen für die Problembearbeitung

schen Spezifikationsmitteln zählen laut ZELEWSKI 117 taxonomische Relationen für Überund Unterordnungsbeziehungen zwischen Begriffen und semantische Konstrukte, wie Inferenz- und Integritätsregeln. Die Semantik von Begriffen stellt ein grundlegendes Merkmal für die Wiederverwendung von Projektwissen dar und ist für den Untersuchungsgegenstand somit eindeutig notwendig. Ontologien sind demnach besser für den Untersuchungsgegenstand geeignet als Metamodelle. Referenzmodelle sind abstrahierte Modelle zur Darstellung eines standardisierten Realitätsausschnitts mit dem Gestaltungsanspruch eines Soll-Modells. 118 Die Unterschiede zwischen Referenzmodellen und Ontologien bestehen in folgenden Ausprägungen: 119 Referenzmodelle besitzen neben der repräsentationalen Semantik, die bei Ontologien vorhanden ist, auch eine normative Semantik. Während die repräsentationale Semantik die betreffende Domäne spezifiziert, besitzt die normative Semantik einen Empfehlungs- oder Sollcharakter. Empfehlungen oder Handlungsanweisungen werden für die Identifikation und Selektion von Projektwissen im Rahmen der Untersuchung jedoch nicht benötigt. Referenzmodelle arbeiten im Gegensatz zu Ontologien nicht ausschließlich mit formalsprachlichen Spezifikationsmitteln. Die Maschinenlesbarkeit ist also weniger stark gewährleistet als bei der rein formalsprachlichen Spezifikation in Ontologien. Die Maschinenlesbarkeit ist fundamental für die Verarbeitung mit Computersystemen, die in der Untersuchung erfolgen soll. Referenzmodelle entsprechen in ihrer materiellen Reichweite den Domänen-Ontologien. Die Ontologien können auch, wie im vorigen Kapitel beschrieben, für andere Gegenstandsbereiche eingesetzt werden. Da in der aktuellen Untersuchung die Domäne Projektmanagement im Vordergrund steht, ist dieser Unterschied für die Untersuchung jedoch belanglos. Insgesamt besitzen auch Referenzmodelle für den aktuellen Untersuchungsgegenstand keine bessere Eignung als Ontologien. Im Vergleich zu Terminologien, Nomenklaturen und Data Dictionaries, die sich inhaltlich auf die Sammlung und Systematisierung von Begriffen beschränken, zeichnen sich Ontologien durch zusätzliche Relationen und zusätzliche semantische Konstrukte wie Inferenz- und Integritätsregeln aus.120 Ontologien erlauben die Berücksichtigung der Semantik und sind für die Wiederverwendung von Projektwissen, das mit semantisch zu deutenden Begriffen repräsentiert wird, besser geeignet. 117

Vgl. ZELEWSKI (2005), S. 196.

118

Vgl. FINK/SCHNEIDEREIT/VOß (2005), S. 101.

119

Vgl. ZELEWSKI (1999), S. 11 f.

120

Vgl. ZELEWSKI (2005), S. 192.

Grundlagen für die Problembearbeitung

29

Taxonomien sind Sammlungen von Entitäten, die durch ein Klassifikationsschema geordnet werden und normalerweise hierarchisch angeordnet sind. Taxonomien besitzen zwar taxonomische Relationen, Ontologien besitzen jedoch auch nicht-taxonomische Relation und zusätzliche semantische Konstrukte.121 Ontologien können semantische Gegebenheiten demnach umfassender als Taxonomien berücksichtigen. Thesauri sind systematisch geordnete Verzeichnisse von Begriffen. 122 Sie enthalten eine möglichst vollständige Terminologie eines Fachgebiets mit Homonym-, Synonymund Äquivalenzbeziehungen. 123 Da Thesauri auch hierarchische Relationen enthalten können, 124 sind sie eng mit Taxonomien verwandt. Auf Grund der umfassenderen Berücksichtigung der Semantik durch Ontologien sind Thesauri nicht so gut geeignet wie Ontologien. Ein konzeptuelles Modell ist ein sprachliches Artefakt für die Repräsentation von Wissen, das aus der Konzeptualisierung eines Realitätsausschnitts hervorgegangen ist. 125 Konzeptuelle Modelle können als inhaltsbezogenes Kommunikationsmedium zwischen Akteuren aus verschiedenen Domänen dienen. 126 Ontologien sind konzeptuelle Modelle, bei denen ein Explikationsvorgang durchgeführt wurde. 127 Im Vergleich zwischen Ontologien und konzeptuellen Modellen hat ZELEWSKI 128 folgende Unterschiede verdeutlicht: Während bei Ontologien die Spezifikation der sprachlichen Ausdrucksmittel für die Konstruktion repräsentationaler Modelle im Vordergrund steht, ist bei konzeptuellen Modellen eher die Strukturierung eines Realitätsausschnitts mittels begrifflicher Konzepte und ihrer Relationen untereinander betont. Da in Projektdokumenten sprachliche Ausdrucksmittel verwendet werden, eignen sich Ontologien stärker für den Untersuchungsbereich, da auch bei Ontologien sprachliche Ausdrucksmittel im Vordergrund stehen. Außerdem werden konzeptuelle Modelle im Allgemeinen nicht auf einen Sprachtyp festgelegt. Ontologien hingegen werden oftmals in stärkerer Nähe zu einer unmittelbaren Verwendung in Computersystemen thematisiert und in Folge dessen häufiger als formalsprachliche Artefakte angesehen. Auch in dieser Untersuchung wird eine Verwendung in Computersystemen 121

Vgl. ZELEWSKI (2005), S. 192.

122

Vgl. MANECKE (2004), S. 131.

123

Vgl. WEDEKIND (2001), S. 409.

124

Vgl. PANYR (1992), S. 286.

125

Vgl. ZELEWSKI (2005), S. 204.

126

Vgl. SCHAUER (2004), S. 304.

127

Vgl. DITTMANN/PENZEL (2004), S. 462.

128

Vgl. ZELEWSKI (2005), S. 204 ff.

30

Grundlagen für die Problembearbeitung

thematisiert, weswegen sich Ontologien besser eignen. Weiterhin wird mit Ontologien der Zweck verfolgt, das Wissen für arbeitsteilig zusammenwirkende Akteure so zu strukturieren und zu kodifizieren, dass die Erfüllung einer gemeinsam bearbeiteten Aufgabe ermöglicht wird. 129 Dieser Zweck fehlt den konzeptuellen Modellen, die auch für einen einzelnen Akteur individuell erstellt worden sein können. Der Zweck von Ontologien, arbeitsteilig zusammenwirkende Akteure zu unterstützen, deckt sich mit der Anforderung aus dem betriebswirtschaftlichen Desiderat, eine gemeinsame Wissensbasis zu nutzen. Zusammenfassend besitzt keine der dargestellten Techniken eine bessere Eignung für den Untersuchungsgegenstand als Ontologien. 2.3.1.4 Vor- und Nachteile der Ontologie für die Untersuchung

Bei der Wiederverwendung von Projektwissen spielt die Berücksichtigung der Semantik von Texten eine große Rolle, denn das Projektwissen wird meist durch Informationen in Textdokumenten repräsentiert, in denen unterschiedliche Begriffe von Akteuren mit unterschiedlichem Hintergrundwissen verwendet wurden. Akteure, welche eine gemeinsame Konzeptualisierung eines Realitätsausschnitts zwecks arbeitsteiliger Erfüllung einer gemeinsam übernommenen Aufgabe 130 verwenden, können über erheblich voneinander abweichendes Hintergrundwissen verfügen. Auf Grund dessen entstehen Divergenzen in der Kommunikation von Akteuren und eine Heterogenität von natürlichsprachlichen Dokumenten, die durch diese Akteure verfasst werden. Um diese Kommunikationsbarrieren zu überwinden und Ähnlichkeiten zwischen den heterogenen natürlichsprachlichen Dokumenten erkennen zu können, muss die Semantik berücksichtigt werden. Die Berücksichtigung der Semantik kann durch eine Ontologie erreicht werden, die verschiedene Begriffe für dieselben Informationen für alle Akteure verständlich macht. Ontologien ermöglichen zwar in gewissen Maßen eine Berücksichtigung der Semantik von Wissensinhalten. Eine vollständige Rekonstruktion aller Begriffe wird jedoch nicht geleistet, auf Grund des gemeinsam geteilten, natürlichsprachlichen Vorverständnisses im Allgemeinen aber auch nicht erwartet. 131 Also ist auch bei der Nutzung von On129

Vgl. ZELEWSKI (2005), S. 125 f.

130

Vgl. ZELEWSKI (2005), S. 133.

131

Vgl. ZELEWSKI (2005), S. 150 u. ZELEWSKI (1999), S. 4. Für die Rekonstruktion von Begriffen aus Dokumenten sind Kontextinformationen notwendig. Vgl. REMUS (2002), S. 123. Eine vollständige Rekonstruktion aller Begriffe könnte nur geleistet werden, wenn eine Ontologie alle existierenden Kontextinformationen beinhalten würde.

Grundlagen für die Problembearbeitung

31

tologien ein gewisses Vorverständnis unabdingbar. Grundsätzlich kann für die Artefakte der KI-Forschung und der Wirtschaftsinformatik, wie etwa Multi-Agenten-Systeme oder Wissensdatenbanken, ein solches begriffliches Vorverständnis nicht immer vorausgesetzt werden. 132 Da es sich im Rahmen dieser Untersuchung um betriebswirtschaftlich geprägtes Wissen handelt, kann ein gewisses Vorverständnis bei der praktischen Wiederverwendung von Projektwissen durchaus vorausgesetzt werden. Insbesondere Akteure aus dem Bereich Projektmanagement besitzen auf Grund ihrer Erfahrungen dieses Vorverständnis bereits. Die Nutzung einer Ontologie ist von großer Bedeutung in der Domäne Projektmanagement. Denn Projekte können nur vollständig verglichen werden, wenn Interpretationsvorschriften für das natürlichsprachlich repräsentierte Wissen in Form einer gemeinsamen Ontologie existieren. Ansonsten führen verschiedene Begriffe für dieselben Informationen dazu, dass Vergleichsprojekte nicht oder nur sehr schwer gefunden werden. Nur wenn Akteure eine gemeinsame Interpretation des in ihrer Kommunikation genutzten Vokabulars teilen, kann eine bedeutungsvolle Interaktion zwischen ihnen auftreten. Eine bedeutungsvolle Interaktion ist entscheidend, um eine Interoperabilität 133 zwischen Akteuren zu ermöglichen. Da es sich auch bei einem System um einen Akteur handelt, kann die Kommunikation von und mit Systemen ebenfalls verbessert werden. Ein System ist durch die Nutzung einer Ontologie dazu im Stande, eine automatische Verarbeitung von relevanten Texten durchzuführen. Für die Nutzung von Systemen zur Problemlösung muss die Maschinenlesbarkeit von Informationen ermöglicht werden. Ontologien sind maschinenlesbar in der Art, dass sie bei der automatischen Erstellung von Antworten zu Anfragen aus dem Themenbereich einer Domäne berücksichtigt werden können. Eine Domänen-Ontologie benennt und beschreibt die Entitäten, die in dieser Domäne existieren können, und die Beziehungen zwischen diesen Entitäten. Dafür stellt sie ein Vokabular bereit, um Informationen über die Domäne zu repräsentieren und zu kommunizieren.

132

Vgl. ZELEWSKI (1999), S. 5.

133

Unter Interoperabilität wird die Fähigkeit zur Zusammenarbeit verstanden. Dies setzt unter anderem abgestimmte Schnittstellen und Verfahren voraus. Vgl. WENDE (2006), S. 1149. Gegenüber der Interoperabilität ist die Kooperation abzugrenzen, die als Zusammenarbeit von Akteuren verstanden wird, die durch Arbeitsteilung getrennt wurden. Vgl. IMMLER (1973), S. 22.

32

Grundlagen für die Problembearbeitung Ontologien sind als explizite Spezifikationen von Domänen-Konzeptualisierungen

essentiell für die Entwicklung und die Nutzung von intelligenten Systemen 134 genauso wie für die Interoperabilität von heterogenen Systemen. Sie versorgen den Systementwickler mit dem Vokabular zur Repräsentation von Domänenwissen und einer Basis von Domänenwissen (z.B. der Beschreibung der Vokabular-Begriffe) zu der Domäne, die repräsentiert werden soll. Ontologien informieren den Systembenutzer über das Vokabular, das verfügbar ist, um mit dem System und über die Domäne zu interagieren, und über die Bedeutung der Begriffe aus diesem Vokabular. 2.3.2

Case-Based Reasoning

2.3.2.1 Definition von Case-Based Reasoning

Das Case-Based Reasoning (CBR) bildet die Basis der Problemlösung in dieser Untersuchung. Die Ontologiestützung ist ein Unterstützungsprozess, der dem Hauptprozess der Identifikation von hinreichend ähnlichen Fällen und Selektion von einem ähnlichsten Fall im Rahmen des Case-Based Reasonings dient. Case-Based Reasoning oder fallbasiertes Schließen ist eine Technik aus dem Bereich der Künstlichen Intelligenz (KI), bei der die Lösung eines Falls auf ein neuen, aktuellen, aber hinreichend ähnlichen Fall angewendet wird. 135 Case-Based Reasoning kann sich das spezifische Wissen von einer zuvor erfahrenen, konkreten Fallsituation und dem Versuch der Lösung dieser Fallsituation zunutze machen. Dieses Wissen wird in Form von Fällen in einer Fallbasis gespeichert. Auch unvollständige oder negative Fälle können in der Fallbasis gespeichert werden. Ein neuer Fall wird dadurch gelöst, dass ein ähnlicher Fall gefunden wird und dessen Lösung bei der Lösung des neuen Falls wieder verwendet wird. 136 Die grundlegende Annahme ist, dass, wenn zwei Fälle ähnlich sind, ihre Lösungen wahrscheinlich ebenfalls ähnlich sind. 137 Case-Based Reasoning löst einen neuen Fall durch die Berechnung des Werts seiner Ähnlichkeit zu einem oder mehreren zuvor gelösten Fällen, die in einer Fallbasis gespeichert wurden, und unter Umständen einer anschließenden Anpassung der Lö134

Intelligente Systeme sollen hier verstanden werden als Systeme, die in ihrem Handeln einem menschlichen Akteur ähnlich sind. Intelligente Systeme sind z.B. dazu befähigt, zu lernen und Entscheidungen zu treffen. Vgl. PRATIHAR/JAIN (2010), S. 1.

135

Vgl. RICHTER (2004), S. 407.

136

Vgl. AAMODT/PLAZA (1994), S. 1 f.

137

Vgl. LEAKE (1996), S. 1.

Grundlagen für die Problembearbeitung

33

sung für den gefundenen ähnlichsten und hinreichend ähnlichen Fall an die Umweltbedingungen des neuen Falls. Die primäre Wissensquelle im Case-Based Reasoning besteht nicht aus generalisierten Regeln, sondern aus einer Sammlung von Erfahrungen in Form von gespeicherten Fällen. 138 Im Case-Based Reasoning werden neue Lösungen nicht durch eine Aneinanderkettung von Regeln generiert, sondern durch das Identifizieren von hinreichend ähnlichen Fällen, das Selektieren von mindestens einem ähnlichsten Fall und dessen Anpassung an einen neuen Fall. Case-Based Reasoning basiert auf der Nutzung von Erfahrungen.139 Die Nutzung von Erfahrungen ist eine Nachbildung des menschlichen Problemlösens. 140 Von AAMODT/PLAZA 141 wird diese Art des Schlussfolgerns als eine mächtige und häufig genutzte Problemlösungsart bezeichnet. Durch den Problemlösungsprozess beim Case-Based Reasoning wird das Wissen, das aus vergangenen Erfahrungen besteht, ständig erweitert. Case-Based Reasoning ist eine Technik, die inkrementelles, anhaltendes Lernen beinhaltet, da eine neue Erfahrung jedes Mal, wenn ein Problem gelöst wurde, aufbewahrt wird, um sie für zukünftige Probleme verfügbar zu machen. 142 Ein CBR-System kann neue Fälle lernen und sich dadurch mit der Zeit entwickeln. Der allgemeingültige Ablauf in einem CBR-System wird in der Literatur auch als CBR-Cycle bezeichnet. Laut AAMODT/PLAZA 143 handelt es sich dabei um einen zyklischen Prozess, der beim Case-Based Reasoning durchlaufen wird und aus vier Phasen besteht. Diese vier Phasen wurden vom Verfasser um eine fünfte, vorgelagerte Phase ergänzt. Diese zusätzliche Phase ist die Anfrage-Phase, die verdeutlicht, dass der neue Fall an das CBR-System übermittelt wird. Diese Übermittlung des neuen Falls an das CBR-System ist Voraussetzung für die folgenden Phasen. Dies wurde jedoch von AAMODT/PLAZA nicht explizit erwähnt. Nach der Anfrage-Phase werden in der Identifikations- und SelektionsPhase hinreichend ähnliche Fälle identifiziert und es wird genau ein ähnlichster Fall aus

138

Vgl. LEAKE (1996), S. 1.

139

Vgl. LEAKE (1996), S. 1.

140

Wenn eine Person mit einem neuen Fall konfrontiert wird, wird sie oft Erfahrungen über einen vergangenen, ähnlichen Fall referenzieren. Diese Erfahrungen können selbst entstanden oder von einer anderen Person erlangt worden sein. Wenn die Erfahrungen von einer anderen Person stammen, müssen sie durch mündliche oder schriftliche Beschreibung in das menschliche Fallgedächtnis eingetragen werden. Vgl. PAL/SHIU (2004), S. 5.

141

Vgl. AAMODT/PLAZA (1994), S. 2.

142

Vgl. AAMODT/PLAZA (1994), S. 2.

143

Vgl. AAMODT/PLAZA (1994), S. 7 ff.

34

Grundlagen für die Problembearbeitung

der Fallbasis selektiert. Falls genau ein hinreichend ähnlicher Fall identifiziert wird, ist die Selektion eines ähnlichsten Falls trivial. In der darauffolgenden Phase kann anhand der Übernahme oder Anpassung der Lösung des ähnlichsten Falls auf Lösungsmerkmale des neuen Falls geschlossen werden. Die Lösung wird in der Prüfungs-Phase auf Korrektheit geprüft und, wenn nötig, überarbeitet. Durch die Aufbewahrungs-Phase wird die neue Lösung als gelernter Fall in der Fallbasis gespeichert.

Abbildung 3: CBR-Cycle 144

Die Fallidentifikation und -selektion ist das Fundamentalproblem des Case-Based Reasonings und stellt den konkreten Untersuchungsgegenstand der hier vorgelegten Dissertation dar. Insbesondere wird die Identifikation von ähnlichen Fällen anhand semantischer Ähnlichkeitsindikatoren eingehend untersucht. Semantische Ähnlichkeitsindikatoren sind Maßstäbe für die Ähnlichkeit zwischen Fällen. Diese Indikatoren basieren auf einer vorangegangenen Offenlegung der Semantik von Fallattributen und deren Werten. Bei der Identifikation von ähnlichen Fällen werden neben den semantischen Ähnlichkeitsindikatoren auch

144

Vgl. AAMODT/PLAZA (1994), S. 8.

Grundlagen für die Problembearbeitung

35

nicht-semantische Ähnlichkeitsindikatoren, z.B. der Abstand bei numerischen Fallattributen, verwendet. Die nicht-semantischen Ähnlichkeitsindikatoren spielen jedoch auf Grund ihrer einfachen Anwendbarkeit eine untergeordnete Rolle. Die Machbarkeit der Fallidentifikation und -selektion wird als Bestandteil des ontologiegestützen Case-Based Reasonings mit einem Prototyp in dieser Untersuchung demonstriert. Wie in der folgenden Grafik schematisch dargestellt, werden bei der Identifikation alle Fälle aus der Fallbasis identifiziert, die eine hinreichende Ähnlichkeit zum neuen Fall besitzen. Die Identifikation erfolgt auf Grundlage der Attributs- und Relationswerte zum aktuellen Fall. Anschließend wird genau ein ähnlichster Fall aus der zuvor identifizierten, nicht leeren Menge aller ähnlichen Fälle selektiert. Die Ontologie hat die Funktion eines „Adapters“, um die Inhalte der Fälle zu strukturieren und um den neuen Fall mit den bereits durchgeführten Fällen vergleichbar zu machen. Da die Ontologie formalsprachlich ist, können Vergleiche zwischen Werten von Attributen und Relationen, die auf der Ontologie basieren, in formalsprachlicher Weise durchgeführt werden.

Abbildung 4: Fallidentifikation und -selektion im ontologiegestützten Case-Based Reasoning

2.3.2.2 Abgrenzung von alternativen Techniken

Im Folgenden wird erläutert, welche alternativen Techniken zum Case-Based Reasoning bekannt sind und wie sie im Vergleich zum Case-Based Reasoning zu bewerten sind. Bei den betrachteten Techniken handelt es sich um Datenbankverfahren, Induktion, Statistik, Mustererkennung und allgemein um regelbasierte oder modellbasierte Systeme. Datenbankverfahren, Induktion und Case-Based Reasoning haben gemeinsam, dass sie den Umgang mit Fällen und großen Datenmengen ermöglichen. Während Datenbankverfahren lediglich der strukturierten Ablage und Bereitstellung von Fällen dienen, kann

36

Grundlagen für die Problembearbeitung

durch die Induktion eine Kompilierung der Fälle in generalisierte Regeln erfolgen. CaseBased Reasoning ist die einzige Technik, die Fälle in Bezug auf die Eignung zur Problemlösung eigenständig interpretieren kann. Der Nachteil, der bei Schlussfolgerungssystemen besteht, die eine Interpretation von Fällen in Bezug auf Ähnlichkeiten beinhalten, liegt darin, dass eine Unsicherheit 145 vorhanden sein kann, die bewusst akzeptiert werden muss. Auch mit Hilfe der Statistik 146 und der Mustererkennung können Fälle basierend auf Ähnlichkeiten betrachtet werden. Der Unterschied zum Case-Based Reasoning liegt darin, dass die mathematischen Ähnlichkeitsfunktionen im Voraus definiert werden und unabhängig von der zu Grunde liegenden Fallbasis angewendet werden. Beim Case-Based Reasoning hingegen spielen die laufende Erweiterung und das inkrementelle Lernen mit der Fallbasis eine wichtige Rolle. Eine Integration neuer Fälle und Anpassungen von Fällen aus der Fallbasis führen zu einem Lernen, das dem Lernen beim menschlichen Problemlösen nahe kommt. In einem Vergleich zwischen Case-Based Reasoning und statistischen Verfahren wurden durch das Case-Based Reasoning qualitativ bessere Ergebnisse erzielt. 147 Das für regel- und modellbasierte Systeme notwendige Zusammenstellen von domänenspezifischen Informationen und deren Überführung in eine formale Repräsentation kann in wenig verstandenen Domänen nicht durchgeführt werden, da hierzu umfassendes Wissen über die Problemlösung notwendig ist. 148 Die Nutzung von CBR-Systemen hingegen ist ohne Wissen über die Problemlösung möglich, denn sie können eine Lösung für

145

Eine Unsicherheit bei der Interpretation von Fällen kann dann auftreten, wenn notwendiges Hintergrundwissen nicht in der Fallrepräsentation enthalten ist oder nicht eindeutig interpretiert werden kann.

146

Dies umfasst die Teilbereiche deskriptive, induktive und explorative Statistik. Insbesondere die induktive Statistik weist Überschneidungen zur Induktion auf, da hier ebenfalls Generalisierungen vorgenommen werden.

147

Im Jahr 1995 wurde durch die WOLVERHAMPTON UNIVERSITY und das HEARTLANDS HOSPITAL eine Vergleichsmessung zwischen den beiden Verfahren durchgeführt. Grundlage waren Daten über die Behandlung von Patienten mit einem Blutverdünnungswirkstoff. Es wurden über 1200 Patientengespräche als Datenbasis genutzt. Die Patientengespräche beinhalteten jeweils eine von drei möglichen Ergebnissen: Erhöhung, Reduzierung oder Beibehaltung der Medikation. Das CBR-System, das einen Nearest-Neighbour-Algorithmus beinhaltete, klassifizierte zu 87% eine korrekte Behandlung, während die Diskriminantenanalyse, die zu den statistischen Verfahren zählt, lediglich 67% erreichte. Vgl. WATSON (1997), S. 45. Eine weitere Vergleichsmessung, die im Jahr 2005 veröffentlicht wurde, behandelt die Vorhersage von Grippe-Epidemien in Mecklenburg-Vorpommern. Hier wurde festgestellt, dass die Ergebnisse des Case-Based Reasonings oft besser waren als die Ergebnisse des statistischen Verfahrens. Vgl. WALIGORA/SCHMIDT (2005), S. 202 ff. Eine Verallgemeinerung dieser Vergleichsmessungen ist sehr kritisch zu betrachten. Allerdings kann die Tendenz des Case-Based Reasonings zu besseren Ergebnissen beobachtet werden.

148

Vgl. PAL/SHIU (2004), S. 5 u. WATSON (1997), S. 46.

Grundlagen für die Problembearbeitung

37

diese Art von Problemen bereitstellen, indem sie vergangene Lösungen zu ähnlichen Problemen anpassen. 149 Außerdem kann mit Case-Based Reasoning die Wiederholung von Fehlern verhindert werden, da Fehler genauso wie Erfolge gespeichert werden und somit eine Lernfähigkeit vorhanden ist. Regel- und modellbasierte Systeme hingegen besitzen keine Lernfähigkeit und können nur manuell angepasst werden. Zusammengefasst besitzen die aufgeführten alternativen Techniken keine bessere Eignung als das Case-Based Reasoning. 2.3.2.3 Vor- und Nachteile des Case-Based Reasonings für die Untersuchung

Sinnvolle Anwendungsbereiche für Case-Based Reasoning sind dadurch gekennzeichnet, dass Erfahrungen vorliegen, eine erfahrungsbasierte Technik gegenüber einer direkten Problemlösung 150 einfacher nutzbar ist, die Verwendung der Lösungen der Fallbasis sicherheitskritischen Anforderungen nicht widerspricht, Informationen unvollständig, unsicher oder ungenau sind und eine Modellierung im Sinne traditioneller wissensbasierter Systeme nicht oder nur schwer möglich ist.151 Projektwissen erfüllt die Voraussetzungen sinnvoller Anwendungsbereiche für Case-Based Reasoning. Erfahrungen liegen durch die bereits durchgeführte Bearbeitung von Projekten vor. Bei der Projektarbeit ist die erfahrungsbasierte Technik gegenüber einer direkten Problemlösung einfacher nutzbar, denn auf Grund der ähnlichen Vorgehensweise von Projekten sind Erfahrungen sehr wichtig. Die Verwendung der Lösungen der Fallbasis widerspricht keinen sicherheitskritischen Anforderungen, da das spezifische Projektwissen im Unternehmen verbleibt und von diesem neu verwendet wird. Projektinformationen sind oft unvollständig, unsicher oder ungenau. Projektanforderungen können oft nicht bis ins Detail vorgegeben werden und Budget- und Terminpläne beinhalten immer eine begrenzte Unsicherheit oder Ungenauigkeit. Die Nutzung einer Technik zur Wiederverwendung des Projektwissens im Sinne traditioneller wissensbasierter Systeme ist schwer möglich, denn eine Technik, die ein regelbasiertes System nutzt, wäre wenig robust und könnte nicht mit unerwarteten Datenwerten umgehen, ohne Regelanpassungen vorzunehmen. 152 Und unerwartete Datenwerte können Bestandteil von Projekten sein. Ein modellbasiertes System

149

Vgl. WATSON (1997), S. 47.

150

Unter einer direkten Problemlösung soll die Problemlösung ohne Einbeziehung von Erfahrungen zu ähnlichen Problemen verstanden werden.

151

Vgl. RICHTER (2004), S. 409.

152

Vgl. LUGER (2003), S. 315.

38

Grundlagen für die Problembearbeitung

würde ein explizites Domänenmodell erfordern. 153 Jedoch ist es schwierig, im Projektmanagement auf Grund der Vielfalt an Modellen154 und der weitverbreiteten Orientierung an Best Practices 155 ein repräsentatives umfassendes Modell zu definieren. Dadurch, dass Case-Based Reasoning auf Erfahrungen basiert und nicht auf Regeln, ist Case-Based Reasoning geeignet, Probleme in solchen Domänen zu lösen, die nicht vollständig zu verstehen sind. 156 Case-Based Reasoning erlaubt Akteuren, mit vergangenen Erfahrungen zu arbeiten, ohne die Hintergrundmechanismen komplett zu verstehen. Dies bedeutet, dass auch die vorliegende Domäne nicht vollständig verstanden sein muss, um Case-Based Reasoning in dieser Domäne anzuwenden. Case-Based Reasoning scheint ideal für die Domäne Projektmanagement zu sein, da eine heterogene Fallbasis ein sehr flexibles Format für das Speichern von Wissen bietet, das mit den neun Projektmanagement-Wissensgebieten verbunden sein kann und die verschiedenen Arten von Entscheidungen, die von verschiedenen Akteuren getroffen werden, beinhalten kann. Ein spezifischer Vorteil des Case-Based Reasonings gegenüber anderen KI-basierten Techniken ist, dass eine Fallbasis mit dem ersten Fall nützlich wird. 157 Außerdem ist das Erfassen von Wissen für eine Fallbasis einfach, denn es gibt keine Notwendigkeit, komplexe Beziehungen zwischen Fällen für denselben Zweck aufzudecken. Die Natur der Entscheidungsfindung im Projektmanagement ist für ein beispielbasiertes Paradigma geeignet, da verschiedene Akteure verschiedene Management-Stile haben und da Akteure es grundsätzlich vorziehen, im Projektmanagement auf bisherige Erfahrungen zurückzugreifen. 158 Außerdem leitet sich Projektwissen von einem weiten Umfang an Wissensquellen ab und ist oft idiosynkratisch. Dadurch entsteht eine Heterogenität, die dazu führt, dass eine einheitliche Vorverarbeitung wichtige Aspekte der getroffenen Entscheidungen eliminieren kann. Da beim Case-Based Reasoning das Wissen nur begrenzt im Rahmen einer Text-Extraktion vorverarbeitet wird, ist eine Eliminierung wichti-

153

Vgl. LUGER (2003), S. 317.

154

Beispiele für Modelle im Projektmanagement sind Vorgehensmodelle und Simulationsmodelle.

155

Vgl. z.B. ANDONGNDOU/LAXTON/MARSH/PRESSLER (2009), S. 17 u. KERZNER (2009), S. 374.

156

Vgl. FREUDENTHALER (2008), S. 69.

157

Die Nützlichkeit einer Fallbasis mit wenigen Fällen ist durch die einfache Skalierung von CBRSystemen gegeben. Vgl. FREUDENTHALER (2008), S. 70.

158

Vgl. ANDERSEN/GRUDE/HAUG (2004), S. 186 u. AUCOIN (2007), S. 262.

Grundlagen für die Problembearbeitung

39

ger Aspekte weniger gegeben. Das Fall-Format ist flexibel und kann mit der Zeit modifiziert werden, ohne sich auf die Technik auszuwirken. Die Problemlösung mit Hilfe des Case-Based Reasonings im Projektmanagement entspricht dem allgemein verbreiteten Vorgehen, bei einem neuen Projekt auf bisherige Erfahrungen zurückzugreifen, die in der Domäne Projektmanagement auch als Lessons Learned bezeichnet werden. Mit Hilfe des Case-Based Reasonings können pro Zeiteinheit mehr nützliche Erfahrungen gefunden werden als bei einer manuellen Suche, was die zeitliche Effizienz erhöht. Außerdem können durch Case-Based Reasoning zusätzliche Erfahrungen aus der Fallbasis berücksichtigt werden, die durch Ad-hoc-Befragungen von Akteuren nur schwierig oder gar nicht verfügbar wären, was die Effektivität 159 beim Abruf von Erfahrungen erhöht. Bei der Nutzung von Case-Based Reasoning muss man sich allerdings der bestehenden Nachteile bewusst sein. Eine Fallbasis muss zur praktischen Nutzung repräsentativ160 sein. Wenn der ähnlichste Fall aus der Fallbasis auf Grund mangelnder Repräsentativität nur geringe Ähnlichkeiten aufweist, ist ein erfahrungsbasiertes Vorgehen nicht sehr vielversprechend. Die Fallbasis muss außerdem ständig gepflegt werden, um aktuelle Erfahrungen berücksichtigen zu können und Fehler zu minimieren. Da im Gegensatz zur Induktion keine Generalisierung der Fälle vorgenommen wird, ist die Aussagekraft des Case-Based Reasonings wenig allgemein. Es kann jeweils nur zu spezifischen Fällen nach Ähnlichkeiten gesucht werden. Im Allgemeinen sind die Ergebnisse des Case-Based Reasonings unsicher. 161 Es wird jeweils anhand von Indikatoren auf die Ähnlichkeit zwischen Fällen geschlossen. Ob die Fälle aber tatsächlich ähnlich sind, kann nicht ohne eine verbleibende Unsicherheit ausgesagt werden. In dieser Untersuchung werden die möglichen Nachteile des Case-Based Reasonings in Bezug auf Repräsentativität und Pflege der Fallbasis bewusst akzeptiert, da die Vorteile in Bezug auf die erfahrungsbasierte Problemlösung, die Adäquanz für die Domäne Projektmanagement und das einfache Erfassen von Wissen überwiegen.

159

Ein Abruf von Erfahrungen wird als effektiv betrachtet, wenn diese Erfahrungen zu einem aktuellen Problem ähnlich sind.

160

Eine Fallbasis wird hier als repräsentativ angesehen, wenn Fälle enthalten sind, die eine hinreichende Ähnlichkeit zu neuen Fällen aus der festgelegten Domäne besitzen.

161

Insbesondere, wenn komplexe Anpassungen notwendig sind, um eine präzise Antwort zu generieren, wird Case-Based Reasoning nicht primär empfohlen. Vgl. WATSON (1997), S. 49.

40 2.3.3

Grundlagen für die Problembearbeitung Eignung des ontologiegestützten Case-Based Reasonings

Die Durchführung des ontologiegestützten Case-Based Reasonings basiert auf der Entwicklung und Beurteilung semantischer Ähnlichkeitsindikatoren. Diese Indikatoren werden genutzt, um die Ähnlichkeit zwischen Fällen unter Berücksichtigung der Semantik von natürlichsprachlich repräsentiertem Wissen zu bestimmen. Diese Semantik erstreckt sich auf die inhaltliche Dimension des repräsentierten Wissens. Ähnlichkeiten sind anhand der Werte von Attributen und Relationen, die im natürlichsprachlich repräsentierten Wissen enthalten sind, erkennbar. Ontologien sind nützlich für die Fallidentifikation und -selektion des Case-Based Reasonings, weil sie die Nutzung von bereits akquiriertem Wissen erlauben, das konzeptualisiert und in einer formalen Sprache implementiert wurde. Die Ontologie stellt eine Wissensbasis über die Semantik von Begriffen, über das Domänenwissen und über die Beziehungen zwischen diesen Begriffen dar, die eine automatische Verarbeitung erlaubt und die Ergebnisse des Case-Based Reasonings durch eine umfassendere Berücksichtigung der Semantik von Begriffen verbessert. Dadurch, dass Ontologien die Beziehungen zwischen verschiedenen Begriffen in einer spezifischen Domäne definieren, basiert die Bestimmung von Ähnlichkeiten auf Informationen aus einem eingegrenzten Bereich, was die Präzision der Fallidentifikation und -selektion innerhalb eines CBR-Systems erhöhen kann.

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

3

3.1

41

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen Definition eines Vorgehensmodells für die Erstellung des ontologiegestützten CBR-Systems

Das in der Untersuchung genutzte Vorgehensmodell orientiert sich am klassischen Wasserfallmodell aus dem Bereich des Software-Engineerings.162 Das Vorgehensmodell, das heute als Wasserfallmodell bekannt ist, wurde von WINSTON W. ROYCE entwickelt und im Jahre 1970 veröffentlicht. Der Name Wasserfallmodell wurde im Jahr 1981 durch den USamerikanischen Software-Ingenieur BARRY W. BOEHM geprägt. 163 Das Wasserfallmodell wird auf Grund der abgeschlossenen Phasen und dem strukturierten Vorgehen ausgewählt. 164 Die Phasen des Wasserfallmodells unterteilen den Entwicklungsprozess einer Software. Wie in der Abbildung 5 dargestellt, handelt es sich bei diesen Phasen um Initialisierung, Konzept, Entwurf, Implementierung, Test, Installation und Wartung. Die Initialisierung, die den Start des geplanten Entwicklungsprojekts beinhaltet, wurde bereits durch den Beginn der Untersuchung durchgeführt. Im weiteren Verlauf der Untersuchung, in der die Machbarkeit des ontologiegestützten Case-Based Reasonings aufgezeigt werden soll, bilden die Phasen Konzept, Entwurf, Implementierung und Test das Fundament des hier genutzten Vorgehensmodells. Zwischen diesen Phasen ist im Wasserfallmodell die Möglichkeit einer Rückkopplung vorgesehen, die eine nachträgliche Anpassung bereits durchlaufener Phasen zulässt. Diese Rückkopplungen sind nicht erwünscht, erlauben jedoch einen flexiblen Umgang mit Abweichungen von Vorgaben aus vorangegangenen Phasen. Im klassischen Wasserfallmodell gab es zunächst keine Rückkopplungen zwischen den einzelnen Phasen, sondern nur eine sequentielle Abarbeitung. Erweiterungen des Modells haben dann dazu geführt, dass Rückkopplungen möglich sind. 165

162

Zu weiteren Informationen vgl. ZÖLLER-GREER (2002), S. 5 ff. u. POMBERGER/PREE (2004), S. 17 ff.

163

Vgl. BOEHM (1981), S. 35 ff. u. HOFFMANN (2008), S. 493.

164

Das strukturierte Vorgehen des Wasserfallmodells beinhaltet vorab definierte Ergebnisse der einzelnen Phasen und eine genaue Dokumentation. Vgl. MOTUS (2009), S. 20. Auf Grund der sequentiellen Durchführung der einzelnen Phasen ist der Fortschritt einfach messbar und der Verlauf gut kontrollierbar. Vgl. FERSTL/SINZ (2006) S. 469 u. ABTS/MÜLDER (2009), S. 305.

165

Vgl. BÖHM (2005) , S. 11.

S. Beißel, Ontologiegestütztes Case-Based Reasoning, DOI 10.1007/978-3-8349-6232-4_3, © Gabler Verlag | Springer Fachmedien Wiesbaden GmbH 2011

42

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

Abbildung 5: Wasserfallmodell 166

In der Konzept-Phase wird ein detailliertes Konzept erstellt, das die Grundlage für Datenmodelle und Programmablaufpläne bilden kann. Das Konzept besteht grundsätzlich aus einer Anforderungsanalyse und einer Systemanalyse. 167 In der vorliegenden Untersuchung beinhaltet die Anforderungsanalyse die Spezifikation von Anforderungen an das ontologiegestützte CBR-System. Ein Ontologie-Tool und ein CBR-Tool bilden die primären Bestandteile des ontologiegestützten CBR-Systems. Bei der Anforderungsanalyse handelt es sich um die Festlegung von fachlichen und technischen Anforderungen, die eine Grundlage für eine spätere Auswahl bilden. Im Rahmen der Systemanalyse wird eine semantische Datenmodellierung vorgenommen, die beschreibt, was durch das ontologiegestützte CBRSystem und speziell von den integrierten Tools geleistet werden soll. Im Entwurf beginnt die eigentliche Entwicklung der Lösung zur Wiederverwendung von Projektwissen mit Hilfe eines ontologiegestützten CBR-Systems. Diese Lösung hat eine Spezifikation aller Einzelheiten zum Ergebnis, die für eine Erstellung des Systems

166

Vgl. ZÖLLER-GREER (2002), S. 6.

167

Vgl. ZÖLLER-GREER (2002), S. 9.

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

43

erforderlich sind. 168 In dieser Phase werden jeweils ein anforderungsgerechtes OntologieTool und CBR-Tool ausgewählt. Außerdem werden die Schnittstellen festgelegt, welche die Eingabe und Ausgabe der einzelnen Module ermöglichen. Im der Zuge der Implementierung wird das ontologiegestützte CBR-System erstellt. Bei der Implementierung kann z.B. eine Programmierung oder ein Einsatz von speziellen Tools stattfinden. 169 Für das ontologiegestützte Case-Based Reasoning werden die ausgewählten Tools installiert und konfiguriert. Es werden operationale Ähnlichkeitsmaßstäbe erstellt, die für die Beurteilung der Ähnlichkeit von Fällen anhand von sowohl quantitativen als auch qualitativen Fallattributen genutzt werden. Ein Algorithmus wird erstellt, der lokale Ähnlichkeitswerte zu einem globalen Ähnlichkeitswert aggregiert. Die Erstellung einer Ontologie und die Sammlung von exemplarischen Fällen für eine Fallbasis, die aus natürlichsprachlichen Texten besteht, werden außerdem in dieser Phase durchgeführt. Das Ergebnis der Implementierung ist ein Prototyp 170 , der für die Durchführung von Tests genutzt werden kann. Die Test-Phase besteht aus einem Programmtest, der die einzelnen Programm-Module auf logische Konsistenz und Übereinstimmung mit dem Entwurf überprüft, und einem Benutzertest, der den Test unter Produktionsbedingungen vorsieht. 171 Anhand einer eingegrenzten Fallsammlung wird geprüft, ob die Ziele des ontologiegestützten Case-Based Reasonings praktisch umgesetzt werden können. Zum Inhalt der Phase zählt die Durchführung eines ontologiegestützten Case-Based Reasonings. Der Test beinhaltet die Prüfung der Machbarkeit und ist keine abschließende und vollumfängliche Testphase für ein finales Softwareprodukt. Die Erstellung eines finalen Produkts erfordert ein evolutionäres Vorgehen, das unter anderem die Erweiterung von Ontologie und Fallbasis beinhalten kann. Dies kann in einer weiteren Untersuchung durchgeführt werden. Denkbar wäre die Erweiterung

168

Vgl. ZÖLLER-GREER (2002), S.10 f.

169

Vgl. ZÖLLER-GREER (2002), S.12.

170

Ein Prototyp im Bereich der Softwareentwicklung ist ein ausführbares Software-System, das einem Benutzer die Möglichkeit bietet, wesentliche Systemeigenschaften zu prüfen. Ein Prototyp kann geändert oder um weitere Eigenschaften ergänzt werden, bevor er in ein fertiges Software-System überführt wird. Vgl. POMBERGER/PREE (2004), S. 27.

171

Vgl. ZÖLLER-GREER (2002), S.12 f.

44

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

des hier genutzten Vorgehens um ein Spiralmodell 172 , das eine Form von Prototyping 173 integriert. Installations- und Wartungs-Phase richten sich an den produktiven Einsatz des Systems und stehen nicht im Fokus der vorliegenden Untersuchung. Diese Phasen können im Anschluss an die vorliegende Untersuchung bearbeitet werden, wenn das geplante System in einem produktiven Umfeld eingesetzt werden soll. Ein großes Gewicht innerhalb der Phasen besitzt die Auswahl der passenden Software-Tools. Jeweils ein Ontologie-Tool und ein CBR-Tool sind im Rahmen eines Auswahlverfahrens zu identifizieren und zu selektieren. Das Auswahlverfahren ist Bestandteil der Phasen Konzept und Entwurf. Im Konzept werden die Anforderungen an die beiden Tools definiert und in zwei Anforderungskatalogen festgehalten, die aus Ausschluss- und Vergleichskriterien bestehen. In der Entwurfs-Phase wird zunächst jeweils für das Ontologie-Tool und das CBR-Tool eine Marktübersicht erstellt. Die Marktübersicht beschreibt am Markt zugängliche Produkte, die für die Nutzung als Ontologie-Tool oder CBR-Tool grundsätzlich in Frage kommen. Der resultierende Marktbericht aggregiert die Erkenntnisse aus der Marktübersicht. Im Rahmen der Bewertung werden für jedes Tool zunächst die Ausschlusskriterien, bei denen ein Teil der Tools nach dem Prinzip der Negativselektierung durch das Raster fallen kann, und dann die Vergleichskriterien beurteilt. Nach dieser Beurteilung liegen für die Tools, die durch die Negativselektion nicht ausgeschlossen wurden, Vergleichsurteile in Bezug auf die Vergleichskriterien vor. Die aggregierten Vergleichsurteile werden in einem darauffolgenden Ranking genutzt, um die Tools in eine Reihenfolge zu bringen. Diese Reihenfolge bestimmt die Eignung der Tools im Hinblick 172

Das Spiralmodell wurde 1988 von BARRY W. BOEHM beschrieben und ist ein Softwareentwicklungsmodell, dessen zyklisches Vorgehen eine laufende Bewertung der Risiken während der Softwareentwicklung ermöglicht. Vgl. BOEHM (1988), S. 65. Das Spiralmodell ermöglicht die Einbettung anderer Modelle, um diese mehrmals zyklisch durchlaufen zu können. Vgl. POMBERGER/PREE (2004), S. 32. Das Spiralmodell wird als Metamodell für Softwareentwicklungen angesehen, da die Entwicklung der Software in die Entwicklung mehrerer Teilprodukte zerlegt wird. Vgl. FREUND (2007), S. 77. Das Spiralmodell eignet sich gut für die Einbettung von Qualitätssicherungsmaßnahmen in den SoftwareEntwicklungsprozess und orientiert sich an dem Ziel, möglichst früh Fehler zu erkennen und verschiedene Lösungsalternativen zu erwägen. Dadurch, dass die Softwareentwicklung beim Spiralmodell als kontinuierlicher Wartungsprozess angesehen wird, sind keine verschiedenen Ansätze für Entwicklung und Wartung notwendig. Vgl. POMBERGER/PREE (2004), S. 34.

173

Unter Prototyping ist die Umsetzung eines inkrementellen Prozesses für die Softwareentwicklung zu verstehen. Dies trägt zur Qualitätssicherung und Risikominderung im Entwicklungsprozess bei. Die bekanntesten Arten des Prototypings sind exploratives, experimentelles und evolutionäres Prototyping. Vgl. POMBERGER/PREE (2004), S. 26 f. Prototyping besitzt allerdings auch Nachteile, wie z.B. erhöhter Entwicklungsaufwand durch eine hohe Anzahl Prototypen und das Risiko der Integration mangelhafter Prototypen in das Endprodukt auf Grund von Termindruck. Vgl. FREUND (2007), S. 63.

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

45

auf den Einsatz im vorliegenden Untersuchungsbereich. Anhand dieser Eignung wird unter Berücksichtigung einer computergestützten Zusammenführung der beiden Tools die finale Entscheidung zur Nutzung ausgewählter Tools getroffen. Die folgende Abbildung 6 stellt einen Überblick über die untersuchungsspezifischen Ausprägungen der Phasen des Wasserfallmodells dar, die im Fokus der Untersuchungen stehen.

Abbildung 6: Spezifische Ausgestaltung des Wasserfallmodells

46

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

Das Auswahlverfahren für jeweils ein Ontologie-Tool und ein CBR-Tool wird in der folgenden Abbildung 7 nochmals veranschaulicht.

Abbildung 7: Auswahlverfahren für die Tools im Wasserfallmodell

Der Einsatz des Wasserfallmodells ist grundsätzlich nicht unkritisch zu betrachten. Problematisch ist beim Wasserfallmodell, dass das Konzept und der Entwurf zunächst nur auf

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

47

dem Papier bestehen. Benutzer haben dadurch unter Umständen Verständnisprobleme. 174 Bei der Befolgung des Wasserfallmodells kann es beim sequentiellen Durchschreiten des Prozesses durch eine funktional arbeitsteilige Organisation auch zu Problemen in der Zusammenarbeit, zu einer nicht einheitlichen Modellierungsmethode und zu Know-howVerlusten an den Phasengrenzen kommen. 175 Im Rahmen der Untersuchung werden die Phasen des Wasserfallmodells ausschließlich durch den Autor dieser Untersuchung durchlaufen. Daher sind die dargestellten Probleme nicht vorhanden. Außerdem ist es problematisch, dass die sequentielle Abarbeitung der Phasen zu einer Unflexibilität gegenüber Änderungen im Vorgehen führt. Da es sich jedoch um ein überschaubares und gut geplantes Vorgehen handelt, sind Änderungen nicht zu erwarten. Demgegenüber stehen Vorteile des Wasserfallmodells, wie z.B. eine einfache Möglichkeit der Planung und Kontrolle, eine klare Abgrenzung der einzelnen Phasen und die hohe Effizienz des Modells bei stabilen Anforderungen. Das Wasserfallmodell ist laut HEINRICH 176 bestens geeignet, um ein strukturiertes Vorgehen umzusetzen. Es macht den Entwicklungsprozess erkennbar und leichter handhabbar.177 Laut HINDEL/HÖRMANN/MÜLLER/SCHMIED 178

ist die Verwendung des Wasserfallmodells nur anzuraten, wenn es sich um

ein stabiles Projekt handelt, das nach einheitlichem Ablauf durchgeführt werden kann, die Projektanforderungen zu Beginn vorhanden und stabil sind und wenn es sich um ein eher kleines Projekt handelt. Diese Bedingungen sind für die vorliegende Untersuchung erfüllt. 179

174

Vgl. SPECKER (2004), S. 177. Zu beachten ist die abweichende Begriffsverwendung von SPECKER bei den Phasen des Wasserfallmodells. Es wird jedoch deutlich, dass die von ihm mit „Anforderungsanalyse“ (als Bestandteil der Konzept-Phase) und „Design“ bezeichneten Phasen der Implementierung vorausgehen. Vgl. SPECKER (2004), S. 176. Diese Phasen entsprechen den Phasen „Konzept“ und „Entwurf“ in dieser Untersuchung.

175

Vgl. SPECKER (2004) , S. 177 f.

176

Vgl. HEINRICH (2007), S. 65.

177

Vgl. HAREL/FELDMAN (2006), S. 422.

178

Vgl. HINDEL/HÖRMANN/MÜLLER/SCHMIED (2009), S. 18.

179

Obwohl es sich bei Ontologien und Case-Based Reasoning um innovative Techniken handelt, wird das Projekt als stabil angesehen. Stabilität bezieht sich hier darauf, dass die Anforderungen klar sind und im Laufe des Projekts stabil bleiben.

48 3.2 3.2.1

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen Anwendung des Vorgehensmodells Konzept des ontologiegestützten CBR-Systems

3.2.1.1 Umfang des Konzepts

Die Konzept-Phase besteht aus Anforderungsanalyse und Systemanalyse. In der Anforderungsanalyse werden jeweils für ein Ontologie-Tool und ein CBR-Tool Anforderungen festgelegt und in Anforderungskatalogen schriftlich fixiert. Die Anforderungsanalyse ist die Voraussetzung, um die Eignung der zu betrachtenden Software im Rahmen eines späteren Auswahlprozesses 180 beurteilen zu können. In der Systemanalyse wird eine semantische Datenmodellierung vorgenommen, die das CBR-System zur Identifikation von hinreichend ähnlichen Fällen und Selektion eines ähnlichsten Falls im Rahmen des ontologiegestützten Case-Based Reasonings definiert und veranschaulicht. 3.2.1.2 Anforderungsanalyse für die Softwareauswahl 3.2.1.2.1 Grundlagen der Softwareauswahl

Die Auswahl von Software soll anhand von Auswahlkriterien durchgeführt werden. Die Auswahlkriterien dienen der Bewertung der einzelnen Software-Tools und bedingen die Entscheidung für die Auswahl der Software, die den Anforderungen des Betrachters am stärksten entspricht. Die Anforderungen des Betrachters können qualitativ oder quantitativ sein. Qualitative Anforderungen, wie z.B. die Unterstützung eines bestimmten Betriebssystems, werden auf nominalen oder ordinalen Skalen gemessen. Quantitative Anforderungen, wie z.B. die CPU-Nutzung durch die Software, werden auf kardinalen Skalen gemessen. 181

180

Auswahlprozess ist hier synonym zu Evaluierung oder Evaluation zu verstehen. Die allgemeinen Anforderungen an eine Evaluierung, die auch in dieser Untersuchung gelten, sind ein methodischer, regelbasierter Ablauf, eine Zielorientierung, ein Aufbau auf einem System von Regeln und eine intersubjektive Nachvollziehbarkeit. Vgl. HEINRICH/LEHNER (2005), S. 393.

181

Die Messung auf einer nominalen Skala erlaubt die Prüfung auf Gleichheit oder Ungleichheit in Bezug auf vorgegebene Skalenwerte, wie z.B. Farben. Auf einer ordinalen Skala erfolgt die Prüfung in Bezug auf Wertigkeiten, wie z.B. geringe, mittlere oder hohe Qualität. Kardinale Skalen beinhalten Werte, die den Rechenregeln der Zahlenarithmetik unterliegen, z.B. Temperatur oder Preis. Vgl. GÖTZE/DEUTSCHMANN/LINK (2002) S. 3. Bei einer kardinalen Skala sind Rangordnung und Abstand zwischen den Skalenwerten klar definiert. Bei einer ordinalen Skala ist nur eine Rangordnung erkennbar. Bei einer nominalen Skala sind weder Abstand noch Rangordnung definiert. Vgl. HÜBLER (2005), S. 22.

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

49

Die Erfüllung der Anforderungen des Betrachters spiegelt die Qualität der Software für den Betrachter wider. Qualität ist die Gesamtheit von Eigenschaften einer Software, die dazu geeignet sind, festgelegte Anforderungen zu erfüllen.182 Software-Qualität kann einerseits während des Prozesses der Entwicklung und andererseits anhand der Güte des Endprodukts sichergestellt werden. Software-Qualität ist vom Betrachter abhängig, da jeder Betrachter andere Anforderungen an eine Software haben kann. 3.2.1.2.2 Selektion einer Technik zur Softwareauswahl

Die Softwareauswahl soll durch eine Technik gestützt werden, die eine Bewertung von Alternativen in Bezug auf festgelegte Auswahlkriterien ermöglicht. Da die einzelnen Auswahlkriterien eine unterschiedlich hohe Bedeutung für die Auswahl eines passenden Tools haben können, soll die Technik zur Softwareauswahl eine Möglichkeit bieten, um diese unterschiedlich hohen Bedeutungen der einzelnen Kriterien zu berücksichtigen. Eine Aggregation der Auswahlkriterien zu einer Gesamtbewertung soll ermöglicht werden, um die Grundlage für ein Ranking bilden zu können. Außerdem sollen bei der Nutzung von Rechenverfahren, die über die Grundrechenarten hinausgehen, Tools verfügbar sein, die eine computergestützte Anwendung der Technik ermöglichen. Zur Lösung von Entscheidungsproblemen, bei denen mehrere, zum Teil nicht kardinal messbare Kriterien zu berücksichtigen sind, können die Nutzwertanalyse und der Analytic Hierarchy Process (AHP) herangezogen werden. 183 Da es sich beim Anwendungszweck der benötigten Tools um die Lösung eines solchen Entscheidungsproblem handelt, werden zunächst die Techniken Nutzwertanalyse und AHP genauer betrachtet. Die Nutzwertanalyse 184 stellt ein bekanntes und unkompliziertes Verfahren für Entscheidungsfindungen dar und wird auch als Punktbewertungsmodell oder Scoringmodell bezeichnet.185 Sie ist ein formalisiertes Verfahren zur Entscheidungsvorbereitung oder -fin-

182

Vgl. ABTS/MÜLDER (2009), S. 77. Die Definition von Qualität findet sich auch in verschiedenen Normen wieder. Die Definition von Qualität in der DIN-Norm 55350 und der ISO-Norm 9000 gleichen inhaltlich der Definition von ABTS/MÜLDER. In den Normen werden zwar abweichende Begriffe genutzt, die hier jedoch als synonym betrachtet werden. Anstatt „Eigenschaften“ werden in den Normen „Merkmale“ und anstatt „Anforderungen“ werden „Erfordernisse“ oder „Forderungen“ verwendet. Da die Definitionen in den Normen nicht speziell auf Software-Qualität ausgerichtet sind, wird außerdem anstatt „Software“ in den Normen „Einheit oder Produkt“ verwendet. Vgl. DIN 55350 (2008) u. ISO-9000 (2005).

183

Vgl. ZELEWSKI/PETERS (2003), S. 1210.

184

Vgl. ZANGEMEISTER (1976), S. 45 ff.

185

Vgl. ADAM (1996), S. 413.

50

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

dung, wenn es um eine Auswahl von Handlungsalternativen unter Berücksichtigung eines mehrdimensionalen Zielsystems geht. Im Rahmen der Nutzwertanalyse werden aus den Ausprägungen der Beurteilungskriterien Nutzwerte abgeleitet, die den zahlenmäßigen Ausdruck für die subjektive Vorziehenswürdigkeit eines Vorhabens ausdrücken.186 Die Grundvariante der Nutzwertanalyse mit additiver Verknüpfung der Kriterien lässt sich mit dieser Formel darstellen:

Ny

n

¦G

z

Pyz

(3.1)

z 1

Mit N y wird der Nutzwert einer Entscheidungsalternative y bezeichnet. Pyz steht für den Punktwert, den eine Entscheidungsalternative y beim Beurteilungskriterium z auf Grund einer Beurteilung erreicht, und G z entspricht dem Gewicht, das dem Kriterium z beigemessen wird. Der Nutzwert einer Entscheidungsalternative ergibt sich aus der Summe der gewichteten Punktwerte. Der Ablauf der Nutzwertanalyse besteht laut ADAM 187 aus der Kriterienselektion, der Auswahl möglicher Kriteriumsausprägungen, der Definition von Gewichten, den Bewertungen durch Berechnung der Nutzwerte, der Reihung der Entscheidungsalternativen nach den Nutzwerten und der Auswahl einer Entscheidungsalternative. Zusätzlich zum angegebenen Ablauf kann eine Unterscheidung der Kriterien in Ausschluss- und Vergleichskriterien erfolgen, um die Grundlage für ein zweistufiges Bewertungsverfahren zu schaffen und das Problem der Substituierbarkeit für ausgewählte Kriterien untereinander zu beseitigen. Das Problem der Substituierbarkeit liegt vor, wenn eine überaus schlechte Beuteilung, also ein sehr niedriger Punktwert einer Alternative in Bezug auf ein bestimmtes Kriterium durch gute Beuteilungen, also hohe Punktwerte einer Alternative in Bezug auf ein oder mehrere andere Kriterien ausgeglichen werden kann. Die Nutzwertanalyse ermöglicht eine Bewertung von Entscheidungsalternativen in Bezug auf festgelegte Auswahlkriterien, berücksichtigt unterschiedlich hohe Bedeutungen der einzelnen Kriterien, ermöglicht eine Aggregation der Auswahlkriterien zu einer Gesamtbewertung und ist auf Grund der Beschränkung auf Grundrechenarten ohne ein spezielles Tool praktisch anwendbar. Von einigen Autoren wird die Nutzwertanalyse speziell für die Softwareauswahl empfohlen. 188 Auf Grund einiger Probleme ist die Benutzung der Nutzwertanalyse jedoch sehr kritisch zu betrachten. Die additive Verknüpfung der Punkt186

Vgl. ADAM (1996), S. 412.

187

Vgl. ADAM (1996), S. 413.

188

Vgl. ABTS/MÜLDER (2009), S. 374 u. BIETHAHN/MUCKSCH/RUF (2004), S. 373.

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

51

werte setzt die Unabhängigkeit der Kriterien voraus. Abhängigkeiten, wie z.B. Konkurrenz- oder Komplementaritätsbeziehungen zwischen Kriterien, lassen sich häufig wegen definitorischer Zusammenhänge und der generell gegebenen Interdependenz wirtschaftlicher Größen jedoch nicht ganz vermeiden. 189 Die Interdependenz wirtschaftlicher Größen entsteht durch die gegenseitige Abhängigkeit dieser Größen. Beispielsweise ist der Absatz eines Produkts vom Absatz eines anderen komplementären Produkts abhängig und der Beschaffungsbedarf ist vom Produktionsbedarf abhängig. Bei stark abhängigen Kriterien besteht die Gefahr, dass Alternativen positiv oder negativ überbewertet werden. Die Nutzwertanalyse bietet darüber hinaus eine große Menge an Manipulationsmöglichkeiten. Durch die auf subjektiven Urteilen beruhende Gewichtung der Beurteilungskriterien und deren Bewertung kann das Ergebnis entscheidend beeinflusst werden. 190 Man kann zwar mit Hilfe von zeit- und kostenaufwändigen Befragungen von Akteuren die Subjektivität verringern, indem man ein möglichst heterogenen und breiten Kreis von Akteuren einbezieht, beseitigen kann man diese bei einer Nutzwertanalyse jedoch nicht. Für die Kriterienauswahl existieren zwar Kriterienkataloge191 und ISO-Empfehlungen, wie z.B. ISO 9126, allerdings obliegt die endgültige Auswahl der Kriterien den Entscheidungsträgern. Außerdem besteht das Problem der möglichen Substituierbarkeit der Kriterien untereinander, das durch die Addition der Punktwerte und die Linearität der Bewertung ermöglicht wird. 192 Durch die Unterscheidung von Ausschlusskriterien und Vergleichskriterien kann das Problem nur teilweise beseitigt werden. Die Vergleichskriterien sind weiterhin von der möglichen Substituierbarkeit betroffen. Bei der Nutzwertanalyse kann durch genaue Zahlen und Rechenverfahren eine Objektivität vorgetäuscht werden, die jedoch gar nicht vorhanden ist. Das Gesamtergebnis der Nutzwertanalyse unterliegt zudem einer Nivellierung. Es ist wahrscheinlich, dass die Schwächen der besten Alternative nicht mehr zu erkennen sind. Je mehr Kriterien in Betracht genommen werden, desto eher stehen die Endergebnisse im mittleren Wertebereich. Eine Differenzierung der Alternativen in Bezug auf ihre Endergebnisse kann daher nur in Relation zu den Teilergebnissen erfolgen. Durch die Beurteilung von Alternativen in Bezug auf einzelne Kriterien erfolgt eine Zerlegung des Gesamtproblems in Einzelprobleme. Diese Zerlegung ist fragwürdig, denn zum einen ist das Gesamtproblem in seinen zielrelevanten Wirkungszusammenhängen ganzheitlich nicht mehr 189

Vgl. ADAM (1996), S. 415.

190

Vgl. JUNG (2006), S. 76.

191

Vgl. BLOHM/LÜDER (1995), S. 179 f.

192

Vgl. BIETHAHN/MUCKSCH/RUF (2004), S. 373.

52

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

überschaubar und zum anderen besteht die Gefahr, dass Teilbetrachtungen zu unerwünschten Gesamtwirkungen des Systems führen. 193 Unter anderem kann bei konkurrierenden Kriterien die Verbesserung einer Alternative in Bezug auf ein Kriterium dazu führen, dass die Alternative in Bezug auf ein konkurrierendes Kriterium schlechter beurteilt werden muss. So kann z.B. bei einer entwickelten Software die alleinige Minimierung der Festplattenzugriffe bei Ausführung der Software dazu führen, dass der Bedarf an Arbeitsspeicher durch die Software zunimmt. Der Analytic Hierarchy Process (AHP) wurde durch den Mathematiker SAATY 194 entwickelt. Der AHP ist eine Technik, mittels derer komplexe Entscheidungssituationen hierarchisch modelliert, relative Wichtigkeiten von Kriterien evaluiert und vorziehenswürdige Entscheidungsalternativen rational identifiziert werden können. 195 Der AHP ermöglicht eine Bewertung von Alternativen in Bezug auf festgelegte Auswahlkriterien, berücksichtigt unterschiedlich hohe Bedeutungen der einzelnen Kriterien und ermöglicht eine Aggregation der Auswahlkriterien zu einer Gesamtbewertung. Der Gesamtbewertung liegt eine Hierarchie zu Grunde, die aus einer Ziel-, einer Kriterien-, einer oder mehrerer Subkriterien- und einer Alternativenebene besteht. 196 Bei der AHP-Technik wird ein multikriterielles Entscheidungsproblem analog zur Nutzwertanalyse zunächst in Teilprobleme dekomponiert. Die Lösungen der Teilprobleme werden aggregiert, um das ursprüngliche Entscheidungsproblem zu lösen. 197 Die relative Bedeutung von Beurteilungsobjekten wird im Hinblick auf das jeweils übergeordnete Beurteilungsobjekt mit Hilfe von paarweisen Vergleichen beurteilt.198 Im Gegensatz zur Nutzwertanalyse werden durch die Iteration von MatrizenMultiplikationen im Rahmen der Power-Methode199 erweiterte Rechenverfahren angewendet. Durch verfügbare Tools, wie z.B. Expert Choice200 , können diese Rechenverfahren computergestützt durchgeführt werden.

193

Vgl. ZANGEMEISTER (1976), S. 8.

194

Vgl. z.B. SAATY (1994b).

195

Vgl. AHLERT (2003), S. 35.

196

Vgl. ZELEWSKI/PETERS (2002), S. 5.

197

Vgl. ZELEWSKI/PETERS (2003), S. 1210.

198

Vgl. ZELEWSKI/PETERS (2003), S. 1211.

199

Zu weiteren Details über die Power-Methode im AHP-Verfahren vgl. SAATY (2001c), S. 55; LUSTI (2002), S. 40 f. u. MEIXNER/HAAS (2002), S. 147 ff.

200

Vgl. EXPERT CHOICE (2009).

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

53

Der AHP besitzt zum Teil ähnliche Nachteile wie die Nutzwertanalyse. Auch beim AHP besteht bei stark abhängigen Kriterien die Gefahr, dass Alternativen positiv oder negativ überbewertet werden. Ähnlich wie bei der Nutzwertanalyse bietet der AHP Manipulationsmöglichkeiten, da die Beurteilung der relativen Bedeutungen der Beurteilungsobjekte die Beurteilungen und somit das Ergebnis beeinflussen kann. Die Evaluierung und sachlogische hierarchische Strukturierung relevanter Ziele, Kriterien und Entscheidungsalternativen bleibt dem Entscheidungsträger überlassen. Dies stellt aber keine Schwäche des AHP-Verfahrens dar, weil es keine Technik gibt, die dem Entscheidungsträger diese Arbeit abnehmen kann. 201 Das Problem der möglichen Substituierbarkeit der Kriterien untereinander besteht ebenfalls wie bei der Nutzwertanalyse. Zu den Vorteilen von AHP zählen, dass mit dem AHP Ungereimtheiten und Widersprüche im Entscheidungsverhalten aufgedeckt werden können. 202 Dies wird durch die Konsistenzprüfung der Beurteilungen ermöglicht. Im Vergleich zur Nutzwertanalyse sind auf Grund der größeren Bandbreite von Beurteilungsmöglichkeiten für Beurteilungsobjekte differenziertere Bewertungen möglich. Die Bandbreite von Beurteilungsmöglichkeiten besteht aus fein abgestuften203 und einer hohen Anzahl 204 an Paarvergleichsurteilen. Der AHP erfordert durch den paarweisen Vergleich ein gründliches Nachdenken bei der Bewertung von den Beurteilungskriterien der Entscheidungsalternativen. Neben der Nutzwertanalyse und dem AHP existieren zahlreiche weitere Techniken, wie die ebenfalls von SAATY 205 konzipierte Technik Analytic Network Process (ANP), die eine Weiterentwicklung des AHP darstellt. Beim ANP lassen sich Entscheidungsprobleme nicht nur in Form einer Hierarchie, sondern auch in Form eines sogenannten Entscheidungsnetzwerks modellieren. 206 Der ANP besitzt die Möglichkeit, eine präferenzielle Abhängigkeit 207 zwischen Beurteilungskriterien zu berücksichtigen. 208 Die Anwendung des ANP-Verfahrens ist aufwendiger als die des AHP-Verfahrens und es sind für das ANP-

201

Vgl. AHLERT (2003), S. 36.

202

Vgl. ZELEWSKI/PETERS (2003), S. 1210.

203

Vgl. Tabelle 1, S. 61.

204

Zur Anzahl der Paarvergleiche beim AHP vgl. Kapitel 3.2.1.2.3, S. 61.

205

Vgl. SAATY (2001a), S. 83 ff.

206

Vgl. PETERS (2008), S. 447.

207

Eine präferenzielle Abhängigkeit liegt vor, wenn sich die Beurteilungsobjekte gegenseitig beeinflussen. Vgl. PETERS (2008), S. 445.

208

Vgl. PETERS (2008), S. 459.

54

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

Verfahren keine Tools für eine computergestützte Anwendung vorhanden. Durch den Ausschluss des ANP wird bewusst darauf verzichtet, mögliche horizontale innere Abhängigkeiten zwischen den Beurteilungsobjekten zu berücksichtigen. 209 Die Technik Data Envelopment Analysis (DEA)210 ist eine nicht-parametrische Effizienzanalysetechnik. Bei der DEA muss der Anwender keine Urteile über die relativen Bedeutungen der Inputs und Outputs des Entscheidungsprozesses fällen, da diese Bedeutungen modellendogen und alternativenspezifisch nach dem Dominanzprinzip ermittelt werden. 211 Auf diese Weise lassen sich aggregierte Effizienzwerte für jede Alternative bestimmen. Die DEA unterstützt die Festlegung unterschiedlich hoher relativer Bedeutungen von Beurteilungskriterien durch den Anwender nicht vollständig, da der Anwender lediglich untere und obere Grenzen für Bedeutungsgewichte festlegen kann und nicht direkt die Bedeutungsgewichte. 212 Auf Grundlage der obigen Beurteilungen von verschiedenen Techniken wird AHP zur Verwendung bei der Softwareauswahl selektiert. Die Nachteile des AHP-Verfahrens, wie z.B. die Manipulationsmöglichkeiten bei der Bewertung und die mögliche Überbewertung von stark abhängigen Kriterien, werden bewusst akzeptiert. Obwohl zahlreiche Modifikationen des AHP-Verfahrens existieren, wird auf Grund des begrenzten Zeitrahmens das AHP-Basisverfahren verwendet. Die Modifikationen des AHP-Verfahrens bleiben unberücksichtigt. Der ANP wird wegen der aufwendigen Anwendung und der fehlenden Verfügbarkeit von Tools nicht genutzt. Die DEA wird nicht genutzt, da sie für eine vollständige Festlegung unterschiedlich hoher relativer Bedeutungen von Auswahlkriterien durch den Anwender nicht ausgelegt ist. Die Anwendung des AHP wird nach dem Vorgehensmodell von ZELEWSKI/ PETERS 213 durchgeführt. Dieses besteht aus den fünf Phasen: Konstruktion des Entscheidungsproblems, Festlegung der Kriterien, Selektion von Alternativen, Bewertung der Alternativen und Selektion der günstigsten Alternative. Das Vorgehensmodell entspricht in 209

Beim Analytic Network Process (ANP) können Abhängigkeiten zwischen Alternativen und Kriterien sowie zwischen den Alternativen und zwischen den Kriterien berücksichtigt werden. Insbesondere kann der ANP auch horizontale innere Abhängigkeiten zwischen den Kriterien berücksichtigen. Vgl. PETERS (2008), S. 470 f. u. SAATY (2001b), S. 1.

210

Vgl. CHARNES/COOPER/RHODES (1978), S. 429 ff.

211

Vgl. PETERS (2008), S. 449 f. Die Bedeutungsgewichte werden innerhalb des Modells und nicht direkt vom Benutzer bestimmt. Das Dominanzprinzip beinhaltet einen Vergleich von Beurteilungsobjekten in Bezug auf ihre Effizienz.

212

Vgl. PETERS (2008), S. 459.

213

Vgl. ZELEWSKI/PETERS (2002), S. 2.

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

55

großem Maße dem von MEIXNER/HASS 214 empfohlenen Vorgehen, das zusätzlich noch die Phasen „Umsetzung der Entscheidung“ sowie „Kontrolle und Feedback“ vorsieht. Diese zusätzlichen Phasen sind für die Untersuchung nicht relevant. Da die Umsetzung der Entscheidung im Rahmen der Erstellung des Prototyps vorgenommen wird, ist dies in dieser Untersuchung nicht als dedizierte Phase der Softwareauswahl zu sehen. Die Kontrolle wird durch die Prüfung von Konsistenzwerten parallel zu den anderen Phasen ausgeführt. 3.2.1.2.3 Anforderungskatalog für ein Ontologie-Tool

Im Folgenden wird zunächst ein passendes Ontologie-Tool für das ontologiegestützte CBR-System mit Hilfe des AHP ausgewählt. Es gilt, am Markt verfügbare Tools zu identifizieren und anhand von zuvor festzulegenden Kriterien zu bewerten. Das Entscheidungsproblem, ein Ontologie-Tool auszuwählen, wird hierarchisch in Teilprobleme dekomponiert. Durch die Zerlegung in Teilprobleme wird die durch die Vielschichtigkeit eines Entscheidungsproblems bedingte Komplexität reduziert, indem das Entscheidungsproblem durch das schrittweise Lösen der Teilprobleme gelöst wird.215 Die Dekomposition des Entscheidungsproblems erfolgt in einer Hierarchie aus einer Ziel-, einer Kriterien- und einer Alternativenebene. Die Kriterienebene kann ggf. Subkriterien zur Ausdifferenzierung der Kriterien enthalten. Auf der Zielebene ist das Ziel der Auswahl eines Ontologie-Tools für ontologiegestütztes Case-Based Reasoning vermerkt. Als nächstes gilt es, die Kriterien und ggf. die Subkriterien zu definieren. Als Grundlage für die Ableitung von Kriterien werden international anerkannte Normen des ISO/IEC genutzt. Die INTERNATIONAL ORGANIZATION FOR STANDARDIZATION (ISO) und die INTERNATIONAL ELECTROTECHNICAL COMMISSION (IEC) bilden zusammen eine Vereinigung von Normungsorganisationen für weltweite Standardisierungen. Speziell die Norm ISO/IEC 9126 beschreibt ein Modell für die Bewertung von Produktqualität im Bereich Software Engineering. Inhalt der Norm ist ein Qualitätsmodell, das interne und externe Qualität in sechs verschiedenen Merkmalsbereichen umfasst. Diese Bereiche lauten Funktionalität, Zuverlässigkeit, Benutzbarkeit, Effizienz, Instandhaltbarkeit und Übertragbarkeit. 216 Für jeden Merkmalsbereich sind Merkmale definiert, die als Kriterium in einem 214

Vgl. MEIXNER/HAAS (2002), S. 19 ff.

215

Vgl. ZELEWSKI/PETERS (2002), S. 5.

216

Vgl. ISO-9126-1 (2001), S. 7 ff. In der englischen Ausgabe der ISO-Norm werden die Merkmalsbereiche mit Functionality (dt.: Funktionalität), Reliability (dt.: Zuverlässigkeit), Usability (dt.: Benutzbarkeit), Efficiency (dt.: Effizienz), Maintainability (dt.: Instandhaltbarkeit) und Portability (dt.: Übertragbarkeit) bezeichnet.

56

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

Auswahlverfahren dienen können. Die Messung der Qualität kann mit Metriken erfolgen, die sich auf eine interne Sichtweise (in Bezug auf die Einsicht in den Quellcode), z.B. Anzahl Zeilen im Programmcode, oder auf eine externe Sichtweise, z.B. Erlernbarkeit, beziehen. Die interne Sichtweise ist in erster Linie für noch nicht ausführbare SoftwareProdukte während der Entwicklung gedacht. Die externe Sichtweise bezieht sich auf das Systemverhalten bei Test oder Routinebetrieb des ausführbaren Software-Produkts. 217 Die meisten Merkmalsbereiche besitzen sowohl interne als auch externe Aspekte. Z.B. kann die Zuverlässigkeit extern mit der Fehleranzahl innerhalb einer bestimmten Ausführungszeit gemessen werden und intern mittels einer Quellcodeanalyse.218 Für die vorliegende Untersuchung sind allein die externe Sichtweise und somit externe Merkmale von Bedeutung, da ausschließlich fertig entwickelte und vertriebene Standardsoftware evaluiert wird. Die Norm beschreibt außerdem Bewertungsmöglichkeiten für die Quality-In-Use. Die Quality-In-Use ist die Qualität eines Software-Produkts, das innerhalb eines bestimmten Kontexts für bestimmte Ziele genutzt wird, aus Sicht ausgewählter Benutzer.219 Die Quality-In-Use bewertet das Ausmaß, inwieweit genau diese Benutzer in genau diesem Kontext genau diese Ziele erreichen können. Im Unterschied zur Quality-In-Use ist die Benutzbarkeit in Bezug auf Benutzer, Kontext und Ziele allgemeingültig. Bei der QualityIn-Use werden die Eigenschaften des Software-Produkts nicht direkt gemessen. Die Quality-In-Use kann erst nach längerer Benutzung des Software-Produkts durch festgelegte Benutzer gemessen werden und besitzt eine sehr subjektive Aussagekraft. Ein Makel in der Quality-In-Use kann immer auf Makel in externen Qualitätsmerkmalen zurückgeführt werden. 220 Für eine Auswahl von Standardsoftware ist die Messung der Quality-In-Use nicht von primärer Bedeutung, denn falls ein Makel in der Quality-In-Use vorhanden sein sollte, würde dies anhand eines Makels in den zu beurteilenden externen Qualitätsmerkmalen offengelegt werden. Eine Übersicht der Bereiche und zugehöriger Kriterien für interne und externe Softwarequalität nach ISO 9126 ist in der folgenden Abbildung 8 ersichtlich.

217

Vgl. ISO 9126-1 (2001), S. 15.

218

Vgl. ISO 9126-1 (2001), S. 14.

219

Vgl. ISO 9126-1 (2001), S. 15.

220

Vgl. ISO 9126-1 (2001), S. 14.

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

57

Abbildung 8: Qualitätsmodell für externe und interne Softwarequalität 221

Die Norm DIN 66272 beinhaltete ebenfalls Qualitätsmerkmale für Software. Im Mai 2006 wurde sie durch das DEUTSCHE INSTITUT FÜR NORMUNG (DIN) jedoch ersatzlos zurückgezogen. Die Hauptqualitätsmerkmale, die durch die DIN-Norm beschrieben wurden, entsprechen den sechs Merkmalsbereichen der Softwarequalität nach ISO/IEC 9126. Die Normenreihe ISO 9000-2005 definiert Vorgaben zum Qualitätsmanagement. Diese Vorgaben sind prozessorientiert und auf die Erstellung von Produkten unter Berücksichtigung von Qualität ausgerichtet. Für eine Qualitätsbewertung eines fertigen Produkts sind die Normen nicht vorgesehen. Prozessqualität bei der Erstellung eines Produkts beeinflusst zwar die Qualität des Endprodukts, erlaubt jedoch nicht zwingend eine direkte Aussage zur tatsächlichen Produktqualität. Im Rahmen eines Softwareauswahlverfahrens sind die Inhalte dieser Normenreihe somit nicht von primärer Bedeutung. Die Norm ISO/IEC 12207 222 beschreibt Prozesse im Lebenszyklus einer Software. Die Prozesse betreffen unter anderem die Beschaffung, Lieferung, Entwicklung, Betrieb und Wartung der Software. Diese Norm ist primär für neu entwickelte Software geeignet. Für die Auswahl von Standardsoftware ist sie ungeeignet. Die Berücksichtigung von Zertifizierungen kann ebenfalls Teil eines Auswahlverfahrens sein. Zertifizierungen können für Software-Produkte oder die herstellenden Unternehmen vergeben worden sein. Zertifizierungen für Software-Produkte sind z.B. die COMMON

CRITERIA

FOR INFORMATION

TECHNOLOGY SECURITY EVALUATION (CC) für Sicher-

heitsaspekte. Das herstellende Unternehmen kann die Qualität der Herstellungsprozesse nach ISO 9000-2005 zertifizieren. Die Erfüllung von Sicherheitsanforderungen kann nach ISO 27001 223 zertifiziert werden, die die Anforderungen an ein Informationssicherheits-

221

Vgl. ISO 9126-1 (2001), S. 7.

222

Vgl. ISO-12207 (2008).

223

Vgl. ISO-27001 (2005).

58

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

Managementsystem beschreiben. Das STATEMENT ON AUDITING STANDARDS NO. 70 (SAS 70) beschreibt als Auditierungsstandard spezielle Anforderungen für Service-Provider. Da Zertifizierungen lediglich einen indirekten und unspezifischen Einfluss auf die hergestellte Software haben, sind sie für die Softwareauswahl in dieser Untersuchung nicht von Bedeutung. Insgesamt ist die ISO-Norm 9126 am ehesten für die Ableitung von Auswahlkriterien für Software geeignet. Die allgemein gehaltenen Empfehlungen müssen mit den spezifischen Anforderungen des Entscheidungsträgers abgeglichen werden. Außerdem gilt es, für jedes Auswahlkriterium anforderungsgerechte Subkriterien in Betracht zu ziehen. Die Merkmalsbereiche aus der ISO-Norm 9126 wurden als Orientierung genutzt, um passende Kriterien und ggf. zugehörige Subkriterien zu identifizieren. Nach der Identifikation dieser Kriterien und Subkriterien erfolgen anschließende Definitionen. Der Merkmalsbereich Funktionalität wird als Kriterium mit den Subkriterien Ontologieerstellung, Konsistenzprüfungen und Ontologiesprachen genutzt. Die Zuverlässigkeit wird ohne zusätzliche Subkriterien mit der Reife des Tools abgebildet. Das Kriterium Benutzbarkeit besitzt die Subkriterien Dokumentation zum Tool und grafische Benutzeroberfläche (englisch: Graphical User Interface - GUI). Die Bereiche Effizienz und Instandhaltbarkeit fließen nicht in den Bewertungsrahmen ein, da diese Bereiche in erster Linie für den regelmäßigen praktischen Einsatz von Bedeutung sind. Da in dieser Untersuchung ein Prototyp entwickelt werden soll, um die Machbarkeit zu demonstrieren, werden Effizienz und Instandhaltbarkeit nicht beurteilt. Die Übertragbarkeit besitzt keine zusätzlichen Subkriterien und wird durch die Möglichkeit zum Export von Ontologiewissen abgebildet. Mit Hilfe von Ausschlusskriterien kann bei der Bearbeitung des Entscheidungsproblems der Arbeitsaufwand im Rahmen einer Detailanalyse reduziert werden.224 Als Ausschlusskriterien wurden die Sprachunterstützung 225 auf der Benutzeroberfläche, die zum Bereich Benutzbarkeit zählt, die Betriebssystemunterstützung und die Verfügbarkeit festgelegt. Das Tool wird aus dem weiteren Auswahlverfahren ausgeschlossen, wenn mindestens ein Ausschlusskriterium nicht erfüllt wird. Unter den festgelegten Kriterien ist im Detail folgendes zu verstehen: Funktionalität ist die Fähigkeit des Tools, bestimmte Aufgaben zu lösen. Diese Aufgaben werden durch die Subkriterien Ontologieerstellung, Konsistenzprüfungen und Ontologiesprachen abge224

Vgl. ZELEWSKI/PETERS (2002), S. 21 u. SCHÜTTE/VERING/WIESE (2000), S. 37 ff.

225

Mit „Sprache“ ist hier eine von menschlichen Akteuren verwendete Einzelsprache wie Deutsch oder Englisch gemeint.

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

59

bildet. Ontologieerstellung steht für die Anforderung, Ontologien neu zu erstellen und zu bearbeiten. Dies beinhaltet die Erstellung und Bearbeitung von Instanzen, Klassen, Slots, Attributen, Relationen, Prozeduren, Funktionen und Axiomen. Außerdem soll ein möglichst automatisches Zusammenfügen von mehreren Ontologien (Merging) angeboten werden. Konsistenzprüfungen sollen die Konsistenz der Beurteilungen von Beurteilungsobjekten prüfen und auf Inkonsistenzen aufmerksam machen. Die Konsistenzprüfungen sollen möglichst umfangreich und vollständig sein und Inkonsistenzen für den Benutzer hervorheben. Ontologiesprachen sind formale Darstellungsmöglichkeiten für Ontologien. Diese Ontologiesprachen erfüllen die Aufgabe, eine Ontologie in maschinenlesbarer Form zu speichern. Die Anzahl und Art der unterstützten Sprachen und die Konformität zu bestehenden Standards sind ausschlaggebend für eine hohe Erfüllung dieser Aufgabe. Es sollen OWL, RDF(S), F-Logic 226 und eine oder mehrere proprietäre Sprachen für die interne Verwendung durch das Ontologie-Tool unterstützt werden. Die Zuverlässigkeit, die mit der Reife des Tools abgebildet wird, wird anhand der Anzahl an Fehlerzuständen pro Stunde gemessen. Während des Starts und des Betriebs des Tools sollen keine Fehlerzustände, z.B. in Form von Abstürzen oder Darstellungsfehlern, auftreten. Die Benutzbarkeit ist die Eignung des Tools, beim Betrieb durch Benutzer eine effektive Zielerreichung zu unterstützen. Das Subkriterium GUI wird durch das Vorhandensein und die Qualität 227 einer grafischen Benutzeroberfläche bei der Ontologieerstellung beurteilt. Das GUI beeinflusst die Bedienbarkeit des Tools. Das GUI soll verständlich strukturiert sein, eindeutige Menü-Bezeichnungen und Icons beinhalten und eine benutzerfreundliche Navigation bieten. Das Subkriterium Dokumentation zum Tool bezieht sich auf die Verfügbarkeit, Verständlichkeit und Vollständigkeit einer Anleitung zum Tool. Die Bestandteile des Tools sollen möglichst umfassend erklärt und mit Screenshots verständlich gemacht werden. Auch häufig gestellte Fragen, Tutorials, Präsentationen und weitergehende Informationen sollen für den Benutzer zugreifbar sein.

226

Laut CARDOSO gehören OWL, RDF(S) und F-Logic zu den am meisten genutzten Ontologiesprachen. Vgl. CARDOSO (2007), S. 5. Neben diesen Ontologiesprachen werden laut CARDOSO außerdem Description Logic und DAML+OIL oft genutzt. Diese Sprachen werden hier nicht berücksichtigt, da Description Logic eine Familie von Sprachen ist und DAML+OIL, wie in Kapitel 2.3.1.2 erläutert, nicht mehr unterstützt wird.

227

Die Qualität einer grafischen Benutzeroberfläche wird daran gemessen, inwieweit eine intuitive und benutzerfreundliche Bedienung des Tools mit Hilfe grafischer Bedienelemente angeboten wird.

60

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen Für die Ausschlusskriterien Sprachunterstützung, Betriebssystemunterstützung und

Verfügbarkeit gelten folgende Anforderungen: Für die Sprachunterstützung ist gefordert, dass das Tool die Sprache Englisch oder Deutsch für alle Menütexte und Dialogboxen unterstützen soll. Die Dokumentation zum Tool soll, falls verfügbar, in Englisch oder Deutsch verfasst sein. Für die Betriebssystemunterstützung gilt, dass Windows oder Linux unterstützt werden müssen. Die Verfügbarkeit ist erfüllt, wenn eine Testversion des Tools zum Zeitpunkt des Auswahlverfahrens unentgeltlich vom Hersteller bereitgestellt werden kann. Zur computergestützten Kriterienbeurteilung wird die Software Expert Choice genutzt. Expert Choice ist ein kommerzielles Produkt des gleichnamigen Unternehmens. 228 Die Software ermöglicht die Durchführung des AHP-Verfahrens und von Sensitivitätsanalysen. Die aktuelle Version lautet 11.5 und ist auf Windows-Systemen lauffähig. Laut der UNIVERSITÄT VON CAMBRIDGE in England wurde EXPERT CHOICE von THOMAS SAATY gegründet und ist der weltweit führende Software-Anbieter für AHP-Verfahren. 229 Die Beurteilung der relativen Bedeutung der Beurteilungsobjekte auf ihr jeweils übergeordnetes Beurteilungsobjekt erfolgt durch einen paarweisen Vergleich von Beurteilungsobjekten, die sich auf derselben Ebene der Hierarchie des Entscheidungsproblems befinden. 230 In einer Evaluationsmatrix, wie sie in Formel 3.2 dargestellt ist, können die Ergebnisse aller paarweisen Vergleiche formal dargestellt werden.231

A

§ a 11 ¨ ¨ ... ¨a ¨ i1 ¨ ... ¨a © n1

... a 1 j ... ... ... a ij ... ... ... a nj

... a 1n · ¸ ... ... ¸ ... a in ¸ mit ¸ ... ... ¸ ... a nn ¸¹

i 1,..., n

j 1,..., n :

i

1

j : a ij

i 1,..., n

j 1,..., n :

a ij ! 0

(3.2) a ij

a

1 ji

Wenn zwei Elemente paarweise verglichen werden, kann das Ergebnis in die Evaluationsmatrix eingetragen werden. Das Ergebnis zeigt auf, um wie viel ein Beurteilungsobjekt im Hinblick auf das Beurteilungsobjekt der darüber liegenden Ebene bedeutender als das mit diesem Beurteilungsobjekt verglichene Beurteilungsobjekt derselben Hierarchieebene des

228

Vgl. EXPERT CHOICE (2009).

229

Vgl. IFM (2004).

230

Vgl. SAATY (1994b), S. 23.

231

Vgl. ZELEWSKI/PETERS (2002), S. 8.

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

61

Entscheidungsproblems ist.232 Das Ergebnis kann die Werte annehmen, die in der Tabelle 1 auf dieser Seite aufgeführt sind. Um die Evaluationsmatrix vollständig mit Ergebnissen

n ˜ (n  1) paarweise Vergleiche nötig. Auf der Hauptdiagona2

auszufüllen, sind insgesamt

len der Evaluationsmatrix sind alle Werte gleich Eins233 und unterhalb der Hauptdiagonalen ist der Reziprokwert 234 des ursprünglichen Werts oberhalb der Hauptdiagonalen einzutragen, der bei einer Spiegelung entlang der Hauptdiagonalen zum Wert unterhalb der Hauptdiagonalen korrespondiert. 235 Die Eignung der neunstufigen Intervallskala von SAATY wurde anhand von empirischen Tests 236 gegenüber anderen Skaleneinteilungen nachgewiesen. Allerdings wurde die Intervallskala auch kritisiert, da z.B. die verbale Beschreibung der Bedeutungsurteile als unscharf angesehen werden kann. 237 mögliche Werte für a ij

Bedeutung der möglichen Werte für a ij

1

gleiche Bedeutung der beiden Beurteilungsobjekte

3

etwas höhere Bedeutung eines Beurteilungsobjekts

5

deutlich höhere Bedeutung eines Beurteilungsobjekts

7

viel höhere Bedeutung eines Beurteilungsobjekts

9

sehr viel höhere Bedeutung eines Beurteilungsobjekts

2, 4, 6, 8

Zwischenwerte

1 1 1 1 1 1 1 1 , , , , , , , 2 3 4 5 6 7 8 9

Wenn a ij einen der Werte von 1 bis 9 annimmt, ist a ji der Reziprokwert.

Tabelle 1: Relative Bedeutung zweier Beurteilungsobjekte für das übergeordnete Beurteilungsobjekt 238

232

Vgl. SAATY (1994b), S. 23.

233

Dies setzt die hier verwendete Prämisse voraus, dass die Paarvergleiche reflexiv zueinander sind.

234

Dies setzt die hier verwendete Prämisse voraus, dass die Paarvergleiche symmetrisch zueinander sind.

235

Vgl. ZELEWSKI/PETERS (2002), S. 8 u. WEBER (1993), S. 84 f.

236

Vgl. WEBER (1993), S. 85 f. WEBER hat die Anwendung von alternativen Skalen untersucht. Mit diesen wurden jedoch fast identische Ergebnisse erreicht. Vgl. WEBER (1993), S. 88.

237

Zur Kritik bei Nutzung verbaler Skalen vgl. z.B. DRAKE (1998), S. 195.

238

Vgl. SAATY (2000), S. 73; SAATY/MU (1997), S. 168; SAATY/VARGAS (2001), S. 6.

62

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

Die Beurteilung der Bedeutungen der Kriterien werden mit paarweisen Vergleichen zunächst innerhalb der obersten Kriterienebene und dann auf der Ebene der Subkriterien durchgeführt. Die Hierarchie der Kriterien ist anhand folgender Abbildung 9 ersichtlich.

Abbildung 9: Kriterienebenen für die Auswahl eines Ontologie-Tools

Die folgenden Tabellen entsprechen den Evaluationsmatrizen nach den Beurteilungen mit paarweisen Vergleichen. Die Index-Bezeichnungen entsprechen den Positionen der Paarvergleichsurteile in der jeweiligen Evaluationsmatrix und in den folgenden Tabellen. Zu a ij ist a ji der Reziprokwert. Auf der Hauptdiagonalen der Tabelle sind alle Werte gleich Eins, da hier die Alternativen mit sich selbst verglichen werden und die gleiche Bedeutung zu sich selbst haben. In der Tabelle 2 sind die Paarvergleichsurteile über die relativen Bedeutungen der Kriterien Funktionalität, Zuverlässigkeit, Benutzbarkeit und Übertragbarkeit aufgeführt. Dem Kriterium Funktionalität wird hier eine viel höhere Bedeutung zugeordnet als dem Kriterium Zuverlässigkeit ( a 12 = 7) und eine etwas höhere Bedeutung als dem Kriterium Benutzbarkeit ( a 13 = 3). Weiterhin gilt a 14 = 5, a 23 = 1/5, a 24 = 1/3 und a 34 = 3. Die Reziprokwerte werden wie folgt festgelegt: a 21 = 1/7, a 31 = 1/3, a 32 = 5, a 41 = 1/5, a 42 = 3 und a 43 = 1/3. Beurteilungsobjekt

Funktionalität Zuverlässigkeit Benutzbarkeit Übertragbarkeit

Funktionalität

1

7

3

5

Zuverlässigkeit

1/7

1

1/5

1/3

Benutzbarkeit

1/3

5

1

3

Übertragbarkeit

1/5

3

1/3

1

Tabelle 2: Ergebnisse der Paarvergleiche für die Kriterien der ersten Ebene

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

63

Die Begründungen für die Ergebnisse der Paarvergleiche aus Tabelle 2 sind im Folgenden zu jedem Paarvergleichsurteil aufgeführt: a 11 )

Da jedes Beurteilungsobjekt unter der Prämisse der Reflexivität von Paarvergleichen zu sich selbst gleich ist, besitzt jedes Paarvergleichsurteil a ji mit i

j den

Wert 1. a 12 )

Bei unzureichender Funktionalität können wichtige Aufgaben, wie z.B. das Editieren der Ontologie, grundsätzlich nicht durch das Tool gelöst werden. Bei unzureichender Zuverlässigkeit treten lediglich Unterbrechungen bei der Aufgabenerfüllung auf, da das Tool z.B. abstürzen könnte und Tätigkeiten unter Umständen wiederholt werden müssen. Die Funktionalität besitzt daher eine sehr viel höhere Bedeutung als die Zuverlässigkeit.

a 13 )

Bei unzureichender Funktionalität können wichtige Aufgaben grundsätzlich nicht durch das Tool gelöst werden. Bei unzureichender Benutzbarkeit können die Aufgaben durchgeführt werden, sind aber dauerhaft umständlich. Die Funktionalität besitzt daher eine etwas höhere Bedeutung als die Benutzbarkeit.

a 14 )

Bei unzureichender Funktionalität können wichtige Aufgaben grundsätzlich nicht durch das Tool gelöst werden. Bei unzureichender Übertragbarkeit ist eine Verbindung zum CBR-Tool im Rahmen des ontologiegestützten Case-Based Reasonings technisch erschwert, da das Ontologiewissen z.B. nicht exportiert werden kann. Die Aufgabenerfüllung kann über Umwege, wie z.B. eine technische Umgehungslösung oder eine manuelle Übertragung dennoch erreicht werden. Dies führt zu einer deutlich höheren Bedeutung der Funktionalität gegenüber der Übertragbarkeit.

a 21 )

Unter der Prämisse der Symmetrie von Paarvergleichen ist a ij der Reziprokwert zu a ji . Somit gilt: a ij

1 / a ji mit i  ^1,..,4` und j  ^1,..,4` .

a 22 )

Siehe a 11 .

a 23 )

Bei unzureichender Zuverlässigkeit treten Unterbrechungen bei der Aufgabenerfüllung auf, die sich im Moment der Unterbrechung störend auswirken, z.B. durch einen Absturz des Tools. Bei unzureichender Benutzbarkeit wird die Nutzung des Tools dauerhaft gestört und nicht nur temporär. Die Zuverlässigkeit besitzt durch die eher temporären Auswirkungen eine deutlich geringere Bedeutung als die Benutzbarkeit.

a 24 )

Bei unzureichender Übertragbarkeit ist eine Verbindung zum CBR-Tool im Rahmen des ontologiegestützten Case-Based Reasonings technisch erschwert. In diesem Fall können Konfiguration und Nutzung aufwendiger sein und dadurch nega-

64

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen tiver ins Gewicht fallen als temporäre Unterbrechungen, die bei unzureichender Zuverlässigkeit entstehen. Die Zuverlässigkeit besitzt daher eine etwas geringere Bedeutung als die Übertragbarkeit.

a 31 )

Siehe a 21 .

a 32 )

Siehe a 21 .

a 33 )

Siehe a 11 .

a 34 )

Bei unzureichender Benutzbarkeit ist die Nutzung des Tools dauerhaft umständlich. Bei unzureichender Übertragbarkeit ist eine Verbindung zum CBR-Tool technisch erschwert, wird im günstigsten Fall aber durch eine einmalige Erstellung einer Umgehungslösung beseitigt und hat nicht zwingend eine dauerhafte Auswirkung. Die Benutzbarkeit besitzt daher eine etwas höhere Bedeutung als die Übertragbarkeit.

a 41 )

Siehe a 21 .

a 42 )

Siehe a 21 .

a 43 )

Siehe a 21 .

a 44 )

Siehe a 11 .

Bei allen folgenden Paarvergleichsergebnissen sind nur noch die Paarvergleichsurteile a ij mit i  j erklärungsbedürftig. Diese sind in den folgenden Tabellen fett gedruckt. Für die Paarvergleichsurteile a ij mit i ! j gilt unter der Prämisse der Symmetrie von Paarvergleichen: a ij

1 / a ji . Für die Paarvergleichsurteile a ij mit i

flexivität von Paarvergleichen: a ij

j gilt unter der Prämisse der Re-

1.

Beurteilungsobjekt

Ontologieerstellung

Konsistenzprüfung

Ontologiesprachen

Ontologieerstellung

1

8

4

Konsistenzprüfung

1/8

1

1/2

Ontologiesprachen

1/4

2

1

Tabelle 3: Ergebnisse der Paarvergleiche für die Subkriterien der Funktionalität

Die Begründungen für die Ergebnisse der Paarvergleiche aus Tabelle 3 sind im Folgenden zu jedem erklärungsbedürftigen Paarvergleichsurteil aufgeführt:

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen a 12 )

65

Die Ontologieerstellung ist die primäre Aufgabe des Tools und hat daher eine viel bis sehr viel höhere Bedeutung 239 als die Konsistenzprüfung, die eine nützliche Zusatzaufgabe ist, die alternativ durch manuelle Prüfungen erfolgen kann.240

a 13 )

Wie bereits dargestellt, ist die Ontologieerstellung die primäre Aufgabe des Tools. Die Unterstützung von Ontologiesprachen ist grundlegend für die Erstellung standardisierter Ontologien. Allerdings beeinträchtigt eine begrenzte Unterstützung von Ontologiesprachen nicht zwingend die Aufgabenerfüllung. Eine ungünstige Ontologiesprache könnte dazu führen, dass die Ausdrucksstärke eingeschränkt oder die Übertragbarkeit zwischen den Tools erschwert wird. Die Ontologieerstellung besitzt daher eine etwas bis deutlich höhere Bedeutung als die Ontologiesprachen.

a 23 )

Die Konsistenzprüfung ist eine nützliche Zusatzaufgabe, auf die unter Umständen verzichtet oder die alternativ manuell erfolgen könnte, und die daher eine gleiche bis etwas geringere Bedeutung besitzt als die Unterstützung von Ontologiesprachen, die Einfluss auf die Ausdrucksstärke und die Übertragbarkeit haben. Beurteilungsobjekt

GUI

Dokumentation

GUI

1

7

Dokumentation

1/7

1

Tabelle 4: Ergebnisse der Paarvergleiche für die Subkriterien der Benutzbarkeit

Die Begründung für das Ergebnis des Paarvergleichs aus Tabelle 4 ist im Folgenden zum erklärungsbedürftigen Paarvergleichsurteil a 12 aufgeführt: a 12 )

Ein selbsterklärendes und verständliches GUI hat starken Einfluss auf den Aufwand, der zur Ontologieerstellung mit dem Tool notwendig ist. Die Dokumentation sollte weitere Hilfestellung und Nachschlagemöglichkeiten bieten. Ein selbsterklärendes GUI kann eine Dokumentation optional machen oder sogar ersetzen. Das GUI besitzt daher eine viel höhere Bedeutung als die Dokumentation.

239

Die Bedeutung mit dem Wert 8 ist ein Zwischenwert, für den keine verbale Bezeichnung definiert wurde. Da es sich beim Wert 9 um eine sehr viel höhere und beim Wert 7 um eine viel höhere Bedeutung handelt, wird hier der Wert 8 als eine viel bis sehr viel höhere Bedeutung bezeichnet. Wenn im Folgenden Zwischenwerte angegeben sind, wird analog hierzu verfahren.

240

Zur Prüfung der Konsistenz von Ontologien vgl. z.B. HAASE/STOJANOVIC (2005), 182 ff. u. VÖLKER/ HAASE/HITZLER (2008), S. 60.

66

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

Um Inkonsistenzen zwischen den Paarvergleichsurteilen über die Bedeutungen der Kriterien in einer Evaluationsmatrix festzustellen, hat SAATY einen Konsistenzindex (C.I.: Consistency Index) sowie einen Konsistenzwert (C.R.: Consistency Ratio) entwickelt. Bei Hinweisen auf Inkonsistenzen sollten die Paarvergleichsurteile überarbeitet werden. Die Hintergründe zur Konsistenzprüfung können in Veröffentlichungen von ZELEWSKI/PETERS und SAATY nachgelesen werden. 241 Zur Überprüfung der Konsistenz wird die Software Expert Choice genutzt. Die Inkonsistenzwerte zwischen den Paarvergleichsurteilen werden in der folgenden Tabelle 5 dargestellt. Kriterien der

Ebene in der Hierarchie des

Paarvergleichsurteile

Entscheidungsproblems

Funktionalität, Zuverlässigkeit, Benutzbarkeit, Übertragbarkeit Ontologieerstellung, Konsistenzprüfung, Ontologiesprachen GUI, Dokumentation

Inkonsistenzwert

1

0,04

2

0,00

2

0,00

Tabelle 5: Inkonsistenzwerte der Evaluationsmatrizen

Sowohl in Veröffentlichungen von SAATY 242 als auch innerhalb der Dokumentation von Expert Choice 243 ist angegeben, dass die Paarvergleichsurteile überarbeitet werden müssen, wenn der Wert der Inkonsistenz größer oder gleich 0,1 ist.244 Deshalb wird der Schwellenwert für die Akzeptanz des Werts der Inkonsistenz für diese und die folgenden Konsistenzprüfungen auf 0,1 festgelegt. Da alle berechneten Werte der Inkonsistenz der oben angegeben Paarvergleichsurteile kleiner 0,1 sind, ist keine Überarbeitung der Paarvergleichsurteile notwendig. Die Paarvergleichsurteile über die Bedeutungen der Beurteilungsobjekte müssen aggregiert werden. Jedes (Sub-)Kriterium wird im Hinblick auf ein übergeordnetes (Sub-)

241

Vgl. ZELEWSKI/PETERS (2002), S. 12; SAATY (2000), S. 47 ff.; SAATY (2001a), S. 80 ff.

242

Vgl. SAATY (1994b), S. 27; SAATY (2000), S. 84 f.; SAATY/VARGAS (2001), S. 9.

243

Vgl. EXPERT CHOICE (2009), Help & Understanding Inconsistency.

244

Dies ist von der Anzahl der Beurteilungsobjekte abhängig. Ein Inkonsistenzwert kleiner oder gleich 0,1 ist akzeptabel, wenn bis zu 9 Beurteilungsobjekte vorliegen. Vgl. MENDOZA/MACOUN/PRABHU/ SUKADRI/PURNOMO/HARTANTO (1999), S. 56 f.

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

67

Kriterium aggregiert, indem die Summe jeder Spalte in der Evaluationsmatrix berechnet wird. 245 Die Berechnung kann mit folgender Formel dargestellt werden: n

¦a

ij

j 1,..., n

(3.3)

i 1

Als nächstes muss die Evaluationsmatrix normiert werden. Die Normierung erfolgt, indem jedes Paarvergleichsurteil durch seine jeweilige Spaltensumme dividiert wird:246 § a 11 ¨ n ¨ a i1 ¨¦ ¨ i 1... ¨ ¨ a i1 ¨ n ¨ ¦ a i1 ¨i1 ¨ ... ¨ a n1 ¨ n ¨ ¦ a i1 ©i1

N

...

a 1j

¦a ... a ij

... ...

n

¦a

ij

i 1

... ...

ij

i 1

... ...

...

n

... a nj

... ...

n

¦ a ij i 1

a 1n · ¸ ¸ a ¦ in ¸ i 1 ... ¸ ¸ a in ¸ n ¸ a in ¸ ¦ i 1 ¸ ... ¸ a nn ¸ n ¸ a in ¸ ¦ i 1 ¹ n

(3.4)

Für jedes (Sub-)Kriterium ist ein Bedeutungsurteil v i zu berechnen. Dies erfolgt durch die Bildung der Zeilensummen der normierten Evaluationsmatrix N und die Division jeder Zeilensumme durch die Anzahl der Beurteilungsobjekte (n). Die Bedeutungsurteile v i entsprechen näherungsweise dem normierten Eigenvektor der Evaluationsmatrix A. 247 Für diese Bedeutungsurteile gilt: n

¦a vi

norm ij

j 1

n

mit a ijnorm

a ij

und i 1,..., n

n

¦a

(3.5)

ij

i 1

Die Aggregation der Paarvergleichsurteile zu Bedeutungsurteilen wird durch Expert Choice automatisiert durchgeführt. Diese Aggregation kann - wie zuvor beschrieben - näherungsweise aus den durchschnittlichen normalisierten Spaltenwerten ermittelt werden. Die Ergebnisse der näherungsweisen Aggregation werden in der folgenden Tabelle 6 veranschaulicht. Die Werte

245

Vgl. ZELEWSKI/PETERS (2002), S. 18.

246

Vgl. ZELEWSKI/PETERS (2002), S. 18 f.

247

Vgl. ZELEWSKI/PETERS (2002), S. 19 u. WEBER (1993), S. 94.

68

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

werden dabei auf drei Nachkommastellen gerundet. Die Evaluationsmatrix A entspricht der Tabelle 2. Die Spaltensummen aus A werden anhand der Evaluationsmatrix mit Formel 3.3 berechnet. Die normierten Paarvergleichsurteile zwischen zwei Beurteilungsobjekten werden anhand der normierten Evaluationsmatrix aus Formel 3.4 bestimmt. Die Bedeutungsurteile v i werden mit der Formel 3.5 berechnet.

Spaltensummen

1,676

16,000

4,533

9,333

Beurteilungs-

Funktio-

Zuverläs-

Benutz-

Übertrag-

Zeilen-

Bedeutungs-

objekt

nalität

sigkeit

barkeit

barkeit

summe

urteile v i

Funktionalität

0,597

0,438

0,662

0,536

2,233

0,558

Zuverlässigkeit

0,085

0,063

0,044

0,036

0,228

0,057

Benutzbarkeit

0,199

0,313

0,221

0,321

1,054

0,264

Übertragbarkeit

0,119

0,188

0,074

0,107

0,488

0,122

aus A

Tabelle 6: Berechnung der Bedeutungsurteile für die Kriterien der ersten Ebene

Im Vergleich zwischen den berechneten Werten und den Werten in Expert Choice (siehe Abbildung 10) ist eine Abweichung zu erkennen, die sich in der zweiten bis dritten Nachkommastelle bemerkbar macht. Der Grund für die Abweichung liegt darin, dass die manuelle Berechnung lediglich Näherungswerte liefert. Expert Choice hingegen berechnet exaktere Werte durch die Berechnung des Eigenwerts und der Anwendung der PowerMethode 248 . Im Rahmen dieser Methode wird die Potenz der Evaluationsmatrix erhöht und anschließend erneut der Eigenvektor gebildet. Diese Schritte werden so lange wiederholt, bis sich die Bedeutungsurteile bis zu einer festgelegten Nachkommastelle nicht mehr ändern. 249 Die Bildung des Eigenvektors erfolgt durch die nichttriviale Lösung, das heißt & v z 0 , der folgenden Gleichung. 250 O max ist der maximale Eigenwert, I ist die Einheitsmatrix und v ist der Eigenvektor. 248

Laut HÜGENS wird in Expert Choice die Power Methode verwendet. Vgl. HÜGENS (2008), S. 227. Zur Power-Methode vgl. Fußnote 199, S. 52.

249

Da die Bedeutungsurteile nur bis auf eine festgelegte Anzahl Nachkommastellen „exakt“ bestimmt werden, handelt es sich bei der Power-Methode um ein Approximationsverfahren. Vgl. PETERS (2008), S. 510.

250

Vgl. AHLERT (2003), S. 44 u. PETERS (2008), S. 509.

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen ( A  O max ˜ I) ˜ v

& 0

69 (3.6)

Im Entscheidungsproblem zur Auswahl je eines Tools für die Gestaltung von Ontologien und für die Gestaltung von CBR-Systemen gibt es zwei Kriterienebenen. Um auf der untersten Subkriterienebene jeweils ein aggregiertes Bedeutungsurteil zu bestimmen, werden die Bedeutungsurteile, die sich auf einem Weg von der obersten bis zur untersten Kriterienebene befinden, miteinander multipliziert. 251 Die Aggregation wird automatisiert mit Hilfe von Expert Choice durchgeführt. Aus den einzelnen Bedeutungsurteilen aus Abbildung 10 ergibt sich z.B. für das Subkriterium Ontologieerstellung das aggregierte Bedeutungsurteil 0,565 ˜ 0,727

0,411 .

Abbildung 10: Bedeutungsurteile in Expert Choice für die Ontologie-Tool-Auswahl

3.2.1.2.4 Anforderungskatalog für ein CBR-Tool

Wie in Kapitel 3.1 beschrieben, sind zur Durchführung der Identifikation von hinreichend ähnlichen Fällen und der Selektion eines ähnlichsten Falls im Rahmen des ontologiegestützten Case-Based Reasonings sowohl ein Ontologie-Tool als auch ein CBR-Tool notwendig. Nachdem bereits ein Ontologie-Tool ausgewählt wurde, wird im Folgenden ein CBR-Tool ausgewählt. Analog zur Auswahl des Ontologie-Tools wird wieder das AHPVerfahren genutzt. Das Entscheidungsproblem, ein CBR-Tool auszuwählen, wird hierarchisch in Teilprobleme dekomponiert. Wie bei der Ontologie-Tool-Auswahl erfolgt die Dekomposition

251

Vgl. ZELEWSKI/PETERS (2002), S. 20. Außerdem existieren alternative Vorgehensweisen zur Aggregation der Bedeutungsurteile. Da die alternativen Vorgehensweisen nur marginal von der in diesem Beitrag dargestellten Vorgehensweise abweichen, wird auf die Darstellung verzichtet. Vgl. für alternative Vorgehensweisen z.B. SAATY (2000), S. 112 ff.

70

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

des Entscheidungsproblems in eine Hierarchie aus einer Ziel-, einer Kriterien- und einer Alternativenebene. Auf der Zielebene ist das Ziel für die Auswahl eines CBR-Tools für ontologiegestütztes Case-Based Reasoning vermerkt. Die Kriterien- und Alternativenebene werden im Folgenden definiert. Analog zur Auswahl des Ontologie-Tools wurden die Merkmalsbereiche aus der ISO-Norm 9126 als Orientierung genutzt, um passende Kriterien und ggf. zugehörige Subkriterien zu identifizieren. Dabei wurden folgende Kriterien festgelegt: Das Kriterium Funktionalität soll die Subkriterien Algorithmen, Ähnlichkeitsmaßstab und Fallrepräsentation beinhalten. Die Zuverlässigkeit soll wie beim ersten Auswahlverfahren mit der Reife des Tools abgebildet werden, die anhand der Anzahl von Fehlerzuständen gemessen werden kann. Das Kriterium Benutzbarkeit besitzt die Subkriterien Dokumentation und GUI. Die Bereiche Effizienz und Instandhaltbarkeit fließen nicht in den Bewertungsrahmen ein. Die Übertragbarkeit wird durch die Subkriterien Import von Fallwissen und Import von Ontologiewissen abgebildet. Da im Rahmen dieser Untersuchung die Identifikation von hinreichend ähnlichen Fällen und die Selektion eines ähnlichsten Falls im Vordergrund stehen, werden Funktionen zur Anpassung von Fällen nicht im Auswahlverfahren berücksichtigt. Als Ausschlusskriterien wurden die Sprachunterstützung der Benutzeroberfläche, die zum Bereich Benutzbarkeit zählt, die Betriebssystemunterstützung und die Verfügbarkeit festgelegt. Das Tool wird aus dem weiteren Auswahlverfahren ausgeschlossen, wenn mindestens ein Ausschlusskriterium nicht erfüllt wird. Die Kriterien Funktionalität, Zuverlässigkeit, Benutzbarkeit inkl. der Subkriterien GUI und Dokumentation, Sprachunterstützung, Betriebssystemunterstützung und Verfügbarkeit wurden bereits in Kapitel 3.2.1.2.3 definiert. Noch zu definieren sind die Subkriterien der Funktionalität, und zwar Algorithmen, Ähnlichkeitsmaßstab und Fallrepräsentation, und die Subkriterien der Übertragbarkeit, und zwar Import von Ontologiewissen und Import von Fallwissen. Im Detail sind in Bezug zum Kriterium Algorithmen 252 die Bereitstellung vorgefertigter und Möglichkeiten zum Erstellen benutzerdefinierter Algorithmen zur Aggregation von Ähnlichkeiten im Rahmen des Case-Based Reasonings zu verstehen. Es wird gefordert, dass möglichst viele Algorithmen durch das CBR-Tool unterstüzt werden. Diese sol252

Ein Algorithmus wird hier verstanden als eine wohldefinierte Rechenvorschrift, die eine Menge von Größen als Eingabe verwendet und in endlicher Zeit eine Menge von Größen als Ausgabe erzeugt. Vgl. CORMEN/LEIERSON/RIVEST/STEIN (2007), S. 5. Als Eingabe fungieren hier die lokalen Ähnlichkeitswerte und als Ausgabe die daraus berechneten globalen Ähnlichkeitswerte.

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

71

len nachvollziehbar spezifiziert sein und angepasst werden können. Für die Ausgestaltung von Algorithmen sind Funktionen relevant, die im Rahmen der Aggregation von lokalen Ähnlichkeitswerten zu globalen Ähnlichkeitswerten genutzt werden können. Grundsätzlich wird der globale Ähnlichkeitswert sim g (q , f ) zwischen zwei Fällen q und f unter Einbeziehung der lokalen Ähnlichkeitswerte sim a (a 1q , a 1f ) , sim a (a q2 , a f2 ) , ..., sim a (a qn , a fn ) zwischen jeweils zwei Attributswerten von Fällen durch eine Funktion g berechnet. Es handelt sich bei a 1q , a q2 ,..., a qn um Attributswerte des Anfrage-Falls q und bei a 1f , a f2 ,..., a fn um Attributswerte des Falls f. Die Funktion g hat folgenden Aufbau: sim g (q , f )

g (sim a (a 1q , a 1f ), sim a (a q2 , a f2 ),..., sim a (a qn , a fn ))

(3.7)

Verbreitete Funktionen 253 sind die euklidische Ähnlichkeit, die Hamming-Ähnlichkeit 254 und die Nearest Neighbor Similarity 255 . Die euklidische Ähnlichkeit, die durch den griechischen Mathematiker EUKLID 256 definiert wurde, wird durch folgende Formel dargestellt mit u i als Gewicht der Ähnlichkeit zwischen zwei Attributswerten. Es handelt sich bei u i um n

¦u

normalisierte Gewichte mit u i  [0,1] und

i

1 . Das Gewicht steht für die relative

i 1

Wichtigkeit der korrespondierenden Attributswerte aus den Fällen. sim g (q , f )

n

¦u

2 i

sim a2 (a iq , a if )

(3.8)

i 1

Die Hamming-Ähnlichkeit, die auch als gewichtete Summe bezeichnet wird, berechnet sich mit der Formel: sim g (q , f )

n

¦u

i

˜ sim a (a iq , a if )

(3.9)

i 1

253

Vgl. PAL/SHIU (2004), S. 76 f.

254

Vgl. HAMMING (1950), 147 ff.

255

Vgl. BREMNER/DEMAINE/ERICKSON/IACONO/LANGERMAN/MORIN/TOUSSAINT (2005), S. 593 ff.

256

Es ist nicht mit Sicherheit überliefert, dass die Monographien zur Mathematik und Physik, die EUKLID zugeschrieben werden, tatsächlich von einer einzigen Person namens EUKLID verfasst wurden. Unter Wirtschaftshistorikern werden verschiedene Thesen diskutiert: EUKLID hat schon in der ersten Hälfte des vierten Jahrhunderts v. Chr. in Athen gelebt und war Schüler von PLATON oder ARISTOTELES. Oder EUKLID ist das Pseudonym von einer Gruppe von Mathematikern, die im vierten oder dritten Jahrhundert v. Chr. gemeinsam die Grundlagen der euklidischen Geometrie verfasst haben. Oder EUKLID hat gegen Ende des dritten Jahrhunderts v. Chr. in Alexandria als Mathematiker und Didaktiker gewirkt. Vgl. SCHÖNBECK (2002), S. VII.

72

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

Die Nearest Neighbor Similarity berechnet sich mit der Formel: sim g (q , f )

¦

n i 1

u i ˜ sim a (a iq , a if )

¦

n i 1

ui

(3.10)

Weitere Algorithmen sind Minimum, Maximum, Kosinusfunktion und Fuzzy-Funktion. Minimum bedeutet, dass von allen Attribut-Ähnlichkeitswerten einer Instanz der minimale gewichtete Attribut-Ähnlichkeitswert ausgewählt und als globaler Ähnlichkeitswert genutzt wird. Es gilt: sim g (q , f )

min( u 1 ˜ sim a (a 1q , a 1f ), u 2 ˜ sim a (a q2 , a f2 ),..., u n ˜ sim a (a qn , a fn ))

(3.11)

Analog dazu bedeutet Maximum, dass von allen Attribut-Ähnlichkeitswerten einer Instanz der maximale gewichtete Attribut-Ähnlichkeitswert ausgewählt und als globaler Ähnlichkeitswert genutzt wird. Es gilt: sim g (q , f )

max( u 1 ˜ sim a (a 1q , a 1f ), u 2 ˜ sim a (a q2 , a f2 ),..., u n ˜ sim a (a qn , a fn ))

(3.12)

Beim Kosinuswert 257 wird diese Formel verwendet:

¦ u ˜ sim (a ¦ u ˜ ¦ sim n

sim g (q , f )

i 1

n

i 1

2 i

a

i

n

i 1

q i

, a if )

2 a

(a iq , a if )

(3.13)

Die Fuzzy-Funktion 258 besteht aus einer Anwendung von definierten Regeln, die anstatt statischer Gewichte mit unscharfen Gewichtungen arbeiten kann.

257

Vgl. PAL/SHIU (2004), S. 79. Bei der Nutzung des Kosinuswerts als Maßstab für die Ähnlichkeit wird der Grad zwischen Vektoren einbezogen. Vgl. DEMIRIZ/CIHAN/KULA (2009), S. 849. In diesem Fall werden die lokalen Ähnlichkeiten zwischen Attributswerten als Vektoren betrachtet.

258

Vgl. INDUCTIVE SOLUTIONS (2000), Section 2, S. 27. Die Fuzzy Logik (deutsch: unscharfe Logik) ist eine Erweiterung der klassischen binären Logik. Die Fuzzy Logik findet ihre Ursprünge schon in der alten griechischen Philosophie. Der Vorläufer der Fuzzy Logik ist PLATONs Vermutung, dass es eine dritte Region zwischen wahr und falsch geben müsse. Vgl. LIPPE (2006), S. 245. Die Mathematik der Fuzzy-Set-Theorie (deutsch: unscharfe Mengenlehre) wurde 1965 durch ZADEH beschrieben. Vgl. ZADEH (1965). Ein Hauptmerkmal der Fuzzy Logik ist, dass weiche Grenzen zwischen Wertebereichen existieren. Vgl. MUKAIDONO/KIKUCHI (2001), S. 29. Zur Anwendung der Fuzzy Logik im CaseBased Reasoning vgl. XIONG (2008), S. 2359 ff. Mit Hilfe der Fuzzy Logik ist es z.B. möglich, mit Unschärfen bei verbalen Werten umzugehen. Wenn z.B. die Gewichte für lokale Ähnlichkeitswerte für die Aggregation zu einem globalen Ähnlichkeitswert im Gegensatz zur eindeutigen numerischen Gewichtung in dieser Untersuchung verbal beschrieben worden wären und unscharf wären, hätte die Fuzzy Logik eingesetzt werden können.

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

73

Das Kriterium Ähnlichkeitsmaßstab dient der Bewertung der Möglichkeiten des Tools, um vorgefertigte oder benutzerdefinierte lokale Ähnlichkeitsmaßstäbe 259 nutzen zu können. Mit Hilfe von Ähnlichkeitsmaßstäben können lokale Ähnlichkeitswerte zwischen zwei Attributswerten von zwei zu vergleichenden Fällen gemessen werden. Bei numerischen Attributswerten wird grundsätzlich der Abstand zwischen den Attributswerten einbezogen. 260 Der maximale Abstand max d ist der Abstand zwischen dem kleinsten Attributswert a imin und dem größten Attibutswert a imax . Es gilt: sim a (a iq , a if )

259

1

a iq  a if max d

mit max d

a imax  a imin

(3.14)

Ein Ähnlichkeitsmaßstab wird hier als mathematische Funktion verstanden, deren Wert zunimmt, wenn die Ähnlichkeit zwischen den untersuchten Objekten zunimmt. Der Ähnlichkeitsmaßstab soll nur Ergebnisse aus dem Intervall [0,1] liefern. Daraus folgt, dass die Ähnlichkeitswerte nicht negativ sein dürfen und normiert sein müssen. Vgl. PFUHL (2003), S. 54. Außerdem besteht die Annahme, dass jedes Objekt zu sich selbst gleich ist und damit den maximalen Ähnlichkeitswert von 1 besitzt. Dadurch entsteht die Forderung nach Reflexivität. Vgl. PERNER (2008), S. 10 u. PAL/DILLON/YEUNG (2000), S. 33. In dieser Untersuchung bedeutet dies, dass, wenn ein Fall, der für das Attribut „Projekttyp“ den Attributswert „Migration“ besitzt, mit einem anderen Fall, der für das Attribut „Projekttyp“ ebenfalls den Attributswert „Migration“ besitzt, verglichen wird, die lokale Ähnlichkeit zwischen den Fällen in Bezug auf das Attribut „Projekttyp“ den Wert 1 besitzt. Zusätzlich wird die Annahme getroffen, dass die Ähnlichkeit zwischen zwei Objekten symmetrisch ist. Damit gilt, dass der Attributswert a iq zu dem Attributswert a if dieselbe Ähnlichkeit besitzt wie a if zu a iq . Vgl. PAL/DILLON/ YEUNG (2000), S. 33 u. PFUHL (2003), S. 54. Ein Beispiel für symmetrische Ähnlichkeit in dieser Untersuchung ist der Vergleich zwischen zwei Fällen mit unterschiedlichen Attributswerten für das Attribut „Projekttyp“. Angenommen, ein Fall I besitzt für das Attribut „Projekttyp“ den Attributswert „Migration“ und ein Fall II besitzt für das Attribut „Projekttyp“ den Attributswert „Installation“. Der Ähnlichkeitswert zwischen den Attributswerten „Migration“ und „Installation“ sei 0,7. Unter der Prämisse, dass eine Symmetrie der Ähnlichkeit vorliegt, besitzt die Ähnlichkeit in Bezug auf das Attribut „Projekttyp“ sowohl bei einem Vergleich von Fall I zu Fall II als auch bei einem Vergleich von Fall II zu Fall I denselben Wert 0,7.

260

Diese Metrik wird auch Canberra-Metrik genannt. Vgl. PAL/SHIU (2004), S. 117; AVRAMENKO/ KRASLAWSKI (2008), S. 80; FINNIE/SUN (2004), S. 115.

74

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

Bei symbolischen Attributswerten werden die Werte für die Ähnlichkeit zwischen den Beurteilungsobjekten im Voraus festgelegt und tabellarisch 261 oder taxonomisch 262 dargestellt. Eine Tabelle ermöglicht Paarvergleiche zwischen allen vorhandenen Attributswerten. Da auf der Diagonalen jeder Attributswert mit sich selbst verglichen wird, ist der Ähnlichkeitswert hier Eins. Wenn es sich um eine symmetrische Ähnlichkeit handelt und daher der Attributswert a iq zu dem Attributswert a if dieselbe Ähnlichkeit besitzt wie der Attributswert a if zu dem Attributswert a iq , dann werden die Ähnlichkeitswerte in der Tabelle anhand der Diagonalen gespiegelt. Für symbolische Attributswerte, die mit keiner ordinalen oder kardinalen Skala gemessen werden können und nicht hierarchisch strukturiert werden können, ist die Nutzung einer Tabelle als Ähnlichkeitsmaßstab die einzige Möglichkeit.263 In der folgenden Beispieltabelle werden die Werte für die Ähnlichkeit zwischen den Attributswerten a 1f und a 1q dargestellt.

Beurteilungsobjekt

a 1f

a 1q

a 1f

1

0,5

a 1q

0,5

1

Tabelle 7: Beispiel für Ähnlichkeitswerte in einer Tabelle

Die Taxonomie ist für die Ähnlichkeitsberechnung bei symbolischen Attributswerten, die mit keiner ordinalen oder kardinalen Skala gemessen werden können, jedoch hierarchisch strukturiert werden können, die vorrangige Möglichkeit. Sie ist ein mehrstufiger Baum, dessen Knoten die Instanzen und Relationen einer Domäne repräsentieren. Jeder Knoten

261

Die tabellarische Darstellung von Ähnlichkeitswerten entspricht der Umsetzung der von KOLODNER beschriebenen Messung der Ähnlichkeitswerte auf einer qualitativen Skala, auf der sich qualitative Bereiche befinden. Der Wert für die Ähnlichkeit zwischen zwei Beurteilungsobjekten, die jeweils einem dieser qualitativen Bereiche angehören, wird anhand der Entfernung zwischen diesen Bereichen bestimmt. Vgl. KOLODNER (1993), S. 347.

262

Bei einer Taxonomie handelt es sich um einen hierarchischen Baum. Ein hierachischer Baum kann für die Bestimmung der Ähnlichkeitswerte benutzt werden, indem alle diskreten Attributswerte in Klassen eingeordnet werden und Attributswerte und Klassen von Attributswerten durch Knoten in diesem hierachischen Baum repräsentiert werden. Die Ähnlichkeitsbestimmung zwischen zwei Knoten basiert auf deren Positionen in der Hierarchie. Um Ähnlichkeitswerte in numerischer Form vorzugeben, wird jedem Knoten in der Hierarchie ein korrespondierender Ähnlichkeitswert zugewiesen. Vgl. AVRAMENKO/KRASLAWSKI (2008), S. 74.

263

Vgl. PERNER (2008), S. 45.

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

75

repräsentiert eindeutig eine Instanz aus dieser Domäne. Durch die Baumstrukturen besteht die Möglichkeit, durch Vater-Sohn- und Geschwister-Beziehungen Relationen zwischen Instanzen zu modellieren. Die Anordnung der Knoten innerhalb der Taxonomie erfolgt auf Grund des sachlichen Zusammenhangs der durch sie repräsentierten Attributswerte der Domäne. An jedem Knoten der Taxonomie, der Nachfolger hat, wird ein Ähnlichkeitswert hinterlegt, um die Ähnlichkeit zwischen jeweils zwei direkt untergeordneten Nachfolgern des betrachteten Knotens zu repräsentieren. Sollte ein Knoten mehr als zwei direkt untergeordnete Nachfolger besitzen, so wird die Ähnlichkeit zwischen jeweils zwei dieser Nachfolger mit demselben Ähnlichkeitswert repräsentiert. Knoten, die untereinander verschiedene Ähnlichkeiten besitzen, müssen daher auch verschiedenen Knoten untergeordnet sein. Wenn man sich in der Taxonomie von der Wurzel kommend in einem Ast nach unten bewegt, so wird der Ähnlichkeitswert immer größer, da die Nachfolger eines Knotens jeweils Spezialisierungen darstellen.264 In der Abbildung 11 ist ein Beispiel für Ähnlichkeitswerte in einer Taxonomie dargestellt. Knoten mit Nachfolgern [0,2] Knoten mit Nachfolgern [0,5] Knoten ohne Nachfolger Knoten ohne Nachfolger Knoten mit Nachfolgern [0,3] Knoten ohne Nachfolger Knoten mit Nachfolgern [0,5] Knoten ohne Nachfolger Knoten ohne Nachfolger

Legende:

Relation „istEin“: Knoten: Ähnlichkeitswert: [ ]

Abbildung 11: Beispiel für Ähnlichkeitswerte in einer Taxonomie

264

Vgl. PFUHL (2003), S. 45 f.

76

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

Das Kriterium Fallrepräsentation umfasst die formale Darstellung von Fallwissen innerhalb des Tools. Es ist insbesondere zu betrachten, ob für die Repräsentation von Fallwissen standardisierte Dateiformate, wie z.B. CSV- oder XML-Dateien, angeboten werden. Das Kriterium Import von Fallwissen dient der Beurteilung des Tools in Bezug auf Möglichkeiten, extern gespeichertes Fallwissen in das Tool zu integrieren. Eine Importmöglichkeit für Fallwissen aus Dateien, die durch andere Tools erstellt wurden, soll vorhanden sein. Sollte das Fallwissen lediglich durch die Erstellung einer neuen Datei in das Tool integriert werden können, ist eine möglichst einfache und benutzerfreundliche Datei gefordert. Das Kriterium Import von Ontologiewissen dient der Beurteilung des Tools in Bezug auf Möglichkeiten, eine extern gespeicherte Ontologie mittels eines Importvorgangs in das Tool zu integrieren. Der Importvorgang soll durch einen Datei-Import oder durch die Nutzung einer Schnittstelle zu einem Ontologie-Tool ermöglicht werden. Die Bereiche Effizienz und Instandhaltbarkeit fließen nicht in den Betrachtungsrahmen ein, da diese Bereiche in erster Linie für den regelmäßigen praktischen Einsatz von Bedeutung sind. Da in dieser Untersuchung ein Prototyp entwickelt werden soll, um die Machbarkeit zu demonstrieren, werden Effizienz und Instandhaltbarkeit nicht beurteilt. Insgesamt liegt folgende Hierarchie von Kriterien und Subkriterien vor, die in Bezug auf ihre relativen Bedeutungen beurteilt werden.

Abbildung 12: Kriterienebenen für die Auswahl eines CBR-Tools

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

77

Die Beurteilung der relativen Bedeutungen der Kriterien erfolgt analog zur OntologieTool-Auswahl. Auch hier werden paarweise Vergleiche von Kriterien auf derselben Ebene durchgeführt. Die Software Expert Choice wird wieder genutzt.

Beurteilungsobjekt Funktionalität Zuverlässigkeit Benutzbarkeit

Übertragbarkeit

Funktionalität

1

7

3

5

Zuverlässigkeit

1/7

1

1/5

1/3

Benutzbarkeit

1/3

5

1

3

Übertragbarkeit

1/5

3

1/3

1

Tabelle 8: Ergebnisse der Paarvergleiche für die Kriterien der ersten Ebene

Die Begründungen für die Ergebnisse der Paarvergleiche aus Tabelle 8 sind im Folgenden zu jedem erklärungsbedürftigen Paarvergleichsurteil aufgeführt: a 12 )

Wenn notwendige Funktionalitäten, wie z.B. das Retrieval von Fällen, nicht durch das CBR-Tool unterstützt werden, ist das Tool nur mit Hilfe von Umgehungslösungen oder sogar überhaupt nicht anwendbar. Bei unzureichender Zuverlässigkeit treten zwar Unterbrechungen bei der Aufgabenerfüllung auf, diese sind jedoch nur temporär. Die Funktionalität besitzt daher eine viel höhere Bedeutung als die Zuverlässigkeit.

a 13 )

Wenn die Funktionalität des Tools unzureichend ist, ist die Durchführung von wichtigen Aufgaben unter Umständen nicht möglich. Die Aufgabenerfüllung ist bei unzureichender Benutzbarkeit zwar erschwert, kann jedoch grundsätzlich erreicht werden. Die Funktionalität besitzt daher eine etwas höhere Bedeutung als die Benutzbarkeit.

a 14 )

Wenn die Funktionalität des Tools unzureichend ist, ist die Durchführung von wichtigen Aufgaben unter Umständen nicht möglich. Daher besitzt sie eine deutlich höhere Bedeutung als die Übertragbarkeit, da bei unzureichender Übertragbarkeit, hier speziell beim Import von Ontologiewissen, eine Verbindung zum CBR-Tool im Rahmen des ontologiegestützten Case-Based Reasonings erschwert ist, aber durch eine technische Umgehungslösung oder ein manuelles Vorgehen ersetzt werden kann.

78

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

a 23 )

Bei unzureichender Zuverlässigkeit treten Unterbrechungen bei der Aufgabenerfüllung auf, z.B. der Abbruch des Retrievals von ähnlichen Fällen. Da die Unterbrechungen temporär sind, besitzt die Zuverlässigkeit eine deutlich geringere Bedeutung als die Benutzbarkeit, da bei unzureichender Benutzbarkeit die Nutzung des Tools dauerhaft gestört wird.

a 24 )

Die Zuverlässigkeit besitzt eine etwas geringere Bedeutung als die Übertragbarkeit, da Unterbrechungen bei unzureichender Zuverlässigkeit unter Umständen akzeptiert werden können, bei unzureichender Übertragbarkeit aber eine technische Umgehungslösung oder ein manuelles Vorgehen erforderlich ist.

a 34 )

Bei unzureichender Benutzbarkeit wird die Nutzung des Tools dauerhaft gestört. Daher wird die Benutzbarkeit mit einer etwas höheren Bedeutung belegt als die Übertragbarkeit, die, falls unzureichend, im günstigen Fall durch eine technische Umgehungslösung ausgebessert werden kann.

Beurteilungsobjekt

Algorithmen

Ähnlichkeitsmaßstab

Fallrepräsentation

Algorithmen

1

1/3

1/3

Ähnlichkeitsmaßstab

3

1

1

Fallrepräsentation

3

1

1

Tabelle 9: Ergebnisse der Paarvergleiche für die Subkriterien der Funktionalität

Die Begründungen für die Ergebnisse der Paarvergleiche aus Tabelle 9 sind im Folgenden zu jedem erklärungsbedürftigen Paarvergleichsurteil aufgeführt: a 12 )

Die Algorithmen, die eine Aggregation lokaler Ähnlichkeitswerte in Bezug auf Attribute zu einem globalen Ähnlichkeitswert in Bezug auf Fälle ermöglichen, besitzen eine etwas geringere Bedeutung als die Ähnlichkeitsmaßstäbe, die zur Berechnung der lokalen Ähnlichkeitswerte genutzt werden. Auf Grund der höheren Anzahl und der Heterogenität der Berechnungen von lokalen Ähnlichkeitswerten im Gegensatz zur einheitlichen Berechnung von aggregierten globalen Ähnlichkeitswerten ist der manuelle Aufwand für die Berechnungen von lokalen Ähnlichkeitswerten höher als bei der Berechnung von aggregierten globalen Ähnlichkeitswerten. Die Aggregation lokaler Ähnlichkeitswerte kann, falls nicht durch das Tool unterstützt, daher eher manuell durchgeführt werden als die Berechnungen aller benö-

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

79

tigten lokalen Ähnlichkeitswerte, die auf verschiedenen Ähnlichkeitsmaßstäben beruhen. a 13 )

Der Algorithmus, der alternativ manuell durchgeführt werden kann, hat eine etwas geringere Bedeutung als die Fallrepräsentation, denn ohne diese können die Fälle unter Umständen nicht vollständig oder eindeutig mit dem Tool formalisiert werden.

a 23 )

Ähnlichkeitsmaßstab und Fallrepräsentation werden in Bezug auf die Funktionalität des CBR-Tools gleich beurteilt, da beide grundlegend für das CBR-Tool sind und die Berechnung von Ähnlichkeitswerten mit Hilfe von Ähnlichkeitsmaßstäben sowie die vollständige und eindeutige Fallrepräsentation schwer bis überhaupt nicht manuell durchgeführt werden können. Beurteilungsobjekt

GUI

Dokumentation

GUI

1

7

Dokumentation

1/7

1

Tabelle 10: Ergebnisse der Paarvergleiche für die Subkriterien der Benutzbarkeit

Die Begründung für das Ergebnis des Paarvergleichs a 12 aus Tabelle 10 ist im Folgenden aufgeführt: a 12 )

Ein selbsterklärendes und verständliches GUI hat starken Einfluss auf den Aufwand, der zur Ontologieerstellung mit dem Tool notwendig ist, und kann eine Dokumentation optional machen. Wenn z.B. ein Hilfetext automatisch eingeblendet wird, wenn man mit dem Mauszeiger über das Icon zum Erstellen einer Instanz geht, muss man nicht in der Dokumentation nachsehen, wie dies ausgeführt werden kann. Die Dokumentation sollte weitere Hilfestellungen und Nachschlagemöglichkeiten bieten. Das GUI besitzt daher eine sehr viel höhere Bedeutung als die der Dokumentation. Beurteilungsobjekt

Import Fallwissen

Import Ontologiewissen

Import Fallwissen

1

1/3

Import Ontologiewissen

3

1

Tabelle 11: Ergebnisse der Paarvergleiche für die Subkriterien der Übertragbarkeit

80

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

Die Begründung für das Ergebnis des Paarvergleichs a 12 aus Tabelle 11 ist im Folgenden aufgeführt: a 12 )

Die Möglichkeiten zum Import von Ontologiewissen haben im Kontext des ontologiegestützten Case-Based Reasonings eine etwas höhere Bedeutung als die Möglichkeiten zum Import von Fallwissen, da CBR-Tools grundsätzlich eine alternative, manuelle Eingabe von Fallwissen ermöglichen, aber nicht für die manuelle Eingabe von Ontologiewissen ausgelegt sind.

Analog zu Kapitel 3.2.1.2.3 sollten die Paarvergleichsurteile bei Hinweisen auf Inkonsistenzen überarbeitet werden. Mit Expert Choice wurden die in der folgenden Tabelle 12 dargestellten Inkonsistenzwerte zwischen den Paarvergleichsurteilen berechnet.

Kriterien der

Ebene in der Hierarchie des

Paarvergleichsurteile

Entscheidungsproblems

Funktionalität, Zuverlässigkeit, Benutzbarkeit, Übertragbarkeit Algorithmen, Ähnlichkeitsmaßstab, Fallrepräsentation GUI, Dokumentation Import von Fallwissen, Import von Ontologiewissen

Inkonsistenzwert

1

0,04

2

0,00

2

0,00

2

0,00

Tabelle 12: Inkonsistenzwerte der Evaluationsmatrizen

Da alle berechneten Werte kleiner als der vorgegebene Schwellenwert 0,1 sind, ist keine Überarbeitung der Paarvergleichsurteile notwendig. Die Aggregation der Paarvergleichsurteile zu Bedeutungsurteilen wird automatisiert mit Hilfe von Expert Choice durchgeführt. Details zu den Hintergründen der Aggregation der Paarvergleichsurteile zu Bedeutungsurteilen können dem Kapitel 3.2.1.2.3 entnommen werden. Die Aggregation der Bedeutungsurteile wird ebenfalls mit Expert Choice durchgeführt. Die Ergebnisse sind in der folgenden Abbildung 13 ersichtlich. Aus den einzelnen Bedeutungsurteilen, die in der Abbildung dargestellt sind, können die aggregierten Be-

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

81

deutungsurteile bestimmt werden. Z.B. ergibt sich für das Subkriterium Algorithmen das aggregierte Bedeutungsurteil 0,143 ˜ 0,565 0,081 .

Abbildung 13: Bedeutungsurteile in Expert Choice für die CBR-Tool-Auswahl

3.2.1.3 Systemanalyse

Im Rahmen der Systemanalyse wird eine semantische Datenmodellierung vorgenommen. Die semantische Datenmodellierung besteht aus einer verbalen Beschreibung von Daten und deren Zusammenhängen. 265 Es handelt sich um eine Beschreibung von Datenstrukturen, bei der Elemente eines Entity-Relationship-Diagramms benutzt werden können.266 Diese Beschreibung von Datenstrukturen geschieht zunächst in einer allgemeinen Form, die im Entwurf detailliert wird. Das System soll zwei Tools beinhalten, ein Ontologie-Tool und ein CBR-Tool. Das Ontologie-Tool soll die Erstellung und den Export der Ontologie ermöglichen. Das CBRTool soll den Import der Ontologie, die Erstellung einer Fallbasis, die Konfiguration eines Algorithmus und von Ähnlichkeitsmaßstäben sowie die Identifikation von hinreichend ähnlichen Fällen und die Selektion eines ähnlichsten Falls ermöglichen. Die Verbindung zwischen den beiden Tools wird über die Ontologie aufgebaut. Das Ontologie-Wissen muss vom Ontologie-Tool exportiert und vom CBR-Tool importiert werden. Hierbei gilt es noch festzulegen, ob Import und Export über Dateischnittstellen oder über eine direkte Verbindung erfolgen können. In der folgenden Abbildung 14 werden die beiden Tools und deren funktionale Bestandteile veranschaulicht.

265

Vgl. ZÖLLER-GREER (2002), S. 9.

266

Vgl. ZÖLLER-GREER (2002), S. 49 f.

82

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

Abbildung 14: Ontologiegestütztes CBR-System

Die Eingabedaten bestehen aus einem neuen Fall, der in Form von natürlichsprachlichen Texten repräsentiert wird. Diese Texte sind in maschinell lesbaren Dateien gespeichert und enthalten Informationen über ein Projekt. Die Dateien werden an ein Textanalyse-System übermittelt, um die in den Texten enthaltenen Informationen in eine strukturierte Form zu bringen, die zur Speicherung in einer Fallbasis verwendet werden kann. Das TextanalyseSystem besteht aus einem Textanalyse-Tool oder alternativ aus einem manuellen Arbeitsschritt. Die strukturierten Informationen aus dem neuen Fall werden dem ontologiegestützten CBR-System zur Eingabe übermittelt. Das CBR-Tool vergleicht die strukturierten Informationen aus dem neuen Fall mit den in der Fallbasis gespeicherten Informationen aus alten Fällen. Dieser Vergleich wird mit Hilfe von globalen Ähnlichkeitswerten für die Ähnlichkeit zwischen Fällen durchgeführt. Diese Werte werden mit einem Algorithmus berechnet, indem dieser lokale Ähnlichkeitswerte für die Ähnlichkeit zwischen Attributsund Relationswerten aggregiert. Die lokalen Ähnlichkeitswerte werden mit Ähnlichkeitsmaßstäben für sowohl quantitative als auch qualitative Attributswerte gemessen. Eine Ontologie, die ebenfalls im Rahmen der Implementierung erstellt wird, macht verschiedene Begriffe mit ähnlicher Bedeutung vergleichbar und ist fester Bestandteil des Vergleichs-

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

83

prozesses. Ziel des Vergleichsprozesses ist die Erstellung einer sortierten Menge von globalen Ähnlichkeitswerten, die zur Identifikation hinreichend ähnlicher Fälle und zur Selektion eines ähnlichsten Falls genutzt werden. Das semantische Datenmodell zum ontologiegestützten Case-Based Reasoning wird in einem Entity-Relationship-Diagramm (ERD) nach der Notation von CHEN 267 grafisch dargestellt:

Abbildung 15: Semantisches Datenmodell zum ontologiegestützten Case-Based Reasoning

267

Zu weiteren Informationen zur Technik und Notation des Entity-Relationship-Diagramms und dessen Einbeziehung der Semantik von Datenmodellen vgl. CHEN (1976), S. 19 ff. Für die Darstellung des semantischen Datenmodells zum ontologiegestützten Case-Based Reasoning wurde das EntityRelationship-Diagramm gewählt, da dieses einen Ausschnitt der Realität mit Hilfe von Objekten und Relationen darstellt und damit eine Generalisierung erreicht, von der andere Formen von Datenmodellen grundsätzlich abgeleitet werden können. Vgl. hierzu CHEN (1976), S. 9 f.

84

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

3.2.2

Entwurf des ontologiegestützten CBR-Systems

3.2.2.1 Ziele des Entwurfs

Innerhalb des Entwurfs sollen Standardsoftware-Produkte unter Berücksichtigung der festgelegten Auswahlkriterien ausgewählt werden. Durch die Betrachtung von Standardsoftware-Produkten ergeben sich verschiedene Vorteile: Gegenüber einer Eigenentwicklung sind die Standardsoftware-Produkte fertig entwickelt. Durch den Wegfall der Entwicklung entstehen Kosten- und Zeitersparnisse. Lediglich für die Auswahl, Anpassung und Inbetriebnahme müssen Ressourcen aufgewendet werden. Durch die Nutzung von Standardsoftware kann externes Wissen, das durch die Sortwarehersteller in die Software eingebracht wurde, hinzugewonnen werden. Die Nachteile von Standardsoftware bestehen in der mangelnden Flexibilität der Software bei der Anpassung an spezielle Bedürfnisse, einem unter Umständen hohen Anpassungsaufwand und je nach Lizenzmodell Lizenzkosten, die einmalig oder kontinuierlich anfallen können. Im Betrachtungsbereich der Untersuchung überwiegen die Vorteile gegenüber den Nachteilen. Der Nachteil der mangelnden Flexibilität kann durch die Nutzung von standardisierten Schnittstellen verringert werden. Spezielle Anpassungen sind voraussichtlich kaum notwendig, da die geforderten Funktionalitäten zu den Standardfunktionalitäten der betreffenden Software zählen. Die Ontologieerstellung besitzt einen starken Zusammenhang mit der Fallbasis, da beides an den extrahierten Entitäten aus den natürlichsprachlichen Texten orientiert ist. Alle Daten aus der Fallbasis sollen den Knoten 268 der Ontologie zugeordnet werden können.

268

Die Knoten der Ontologie können hierarchisch oder heterarchisch angeordnet sein.

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

85

3.2.2.2 Auswahl eines Ontologie-Tools 3.2.2.2.1 Marktanalyse zur Identifizierung von Alternativen

Aus der hohen Anzahl verfügbarer Ontologie-Tools wurden fünf aktuelle Ontologie-Tools selektiert, um als Alternativen im Auswahlprozess untersucht zu werden. 269 Apollo ist ein Entwicklungs-Tool für Wissensmodelle, das vom KNOWLEDGE MEDIA INSTITUTE

der OPEN UNIVERSITY in Walton Hall in England zur Verfügung gestellt

wird. Apollo ist als freie Software verfügbar, die von der Apollo Webseite270 heruntergeladen werden kann. Die aktuelle Version lautet V01a18. Die Funktionalität von Apollo wird durch Plug-Ins erweitert. Exporte können mit Hilfe von Output-Plug-Ins durchgeführt werden. 271 Apollo nutzt ein eigenes proprietäres Wissensmodell für die Repräsentation von Ontologien. 272 Dieses Modell basiert auf Frames, die von MARVIN MINSKY definiert wurden. 273 Das Ontologie-Tool OntoStudio wurde durch das Unternehmen ONTOPRISE GMBH mit Sitz in Karlsruhe entwickelt. OntoStudio ist der Nachfolger von OntoEdit und eine kommerzielle Modellierungsumgebung zum Aufbau und zur Pflege von Ontologien. OntoStudio basiert auf dem Open-Source-Framework Eclipse und bietet Extension Points. Die Funktionen von OntoStudio können durch das Erstellen eigener Plug-Ins erweitert werden. OntoStudio besitzt verschiedene Integrationsmöglichkeiten. Es können Datenban-

269

Auf dem Markt ist eine sehr hohe Anzahl von Ontologie-Tools verfügbar. So wurden z.B. in einem Marktbericht von DENNY 94 Tools identifiziert. Vgl. DENNY (2004). Außerdem gibt es ständig neue Entwicklungen von Ontologie-Tools. Dies ist z.B. daran zu erkennen, dass in einem zwei Jahre älteren Marktbericht von DENNY nur 52 Tools identifiziert wurden. Vgl. DENNY (2002). Auf Grund der hohen Anzahl von Ontologie-Tools und der starken Marktveränderungen werden exemplarisch fünf Ontologie-Tools selektiert. In dieser Selektion sollen die drei mit den größten Marktanteilen enthalten sein. Laut einer Studie von CARDOSO besitzen die Tools Protégé mit 68,2%, Swoop mit 13,6% und OntoEdit mit 12,2% die größten Marktanteile. Vgl. CARDOSO (2007), S. 4. OntoEdit wurde von ONTOPRISE, dem Hersteller von OntoStudio, übernommen und nicht mehr eigenständig weitergeführt. Vgl. ONTOPRISE (2010a). Daher werden die drei Tools Protégé, Swoop und OntoStudio (als Ersatz für OntoEdit) für die Untersuchung selektiert. Außerdem sollen zwei weitere Ontologie-Tools selektiert werden, die eigenständig betrieben werden können, ein GUI besitzen und an Universitäten entwickelt wurden. Daher werden exemplarisch auch die beiden Ontologie-Tools Apollo und OntoTrack selektiert.

270

Vgl. KMI (2005).

271

Vgl. MATOUŠEK/KRÁL/FALC (2004), S. 9.

272

Vgl. MATOUŠEK/KRÁL/FALC (2004), S. 4.

273

Vgl. MATOUŠEK/KRÁL/FALC (2004), S. 6.

86

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

ken, Dokumente, Dateisysteme, Applikationen und Webservices integriert werden. Eine Demonstrations-Version kann von der Webseite heruntergeladen werden. 274 OntoTrack 275 ist ein frei verfügbares Tool, um Ontologien in OWL zu durchsuchen und zu editieren. OntoTrack ist eine Java-Applikation und wurde am INSTITUT FÜR KÜNSTLICHE INTELLIGENZ

der FAKULTÄT FÜR INGENIEURWISSENSCHAFTEN UND INFORMATIK der

UNIVERSITÄT ULM entwickelt. Der externe Reasoner RACER 276 kann über eine proprietäre Schnittstelle in OntoTrack eingebunden werden. Protégé 277 ist ein Ontologie-Tool, das vom STANFORD CENTER FOR BIOMEDICAL INFORMATICS

RESEARCH (BMIR) 278 , zuvor als STANFORD MEDICAL INFORMATICS bekannt,

entwickelt wurde. Das BMIR ist eine Forschungseinrichtung an der STANFORD UNIVERSITY SCHOOL OF MEDICINE,

die zur STANFORD UNIVERSITY gehört, und befindet sich in

Stanford, Kalifornien, USA. Das Tool wird als Open Source angeboten. Der Quelltext ist offen für Bearbeitung und darf beliebig verbreitet werden. Die aktuellen stabilen Versionen lauten 3.4.4 und 4.0.2. 279 Die Protégé-Plattform unterstützt mit den Editoren ProtégéFrames and Protégé-OWL zwei Möglichkeiten, um Ontologien zu modellieren. ProtégéFrames ist ein Editor, der ein Benutzer-Interface und einen Knowledge-Server bereitstellt, um Benutzer bei der Konstruktion und beim Speichern von frame-basierten Domänenontologien zu unterstützten, Dateneingabe-Formulare anzupassen und Daten von Instanzen einzugeben. Protégé-Frames ist kompatibel zum Open Knowledge Base Connectivity Protocol (OKBC). Protégé-Frames besitzt eine Plug-In-Architektur, die durch angepasste Plug-Ins erweitert werden kann. Ein Java basiertes Application Programming Interface (API) ermöglicht die Anbindung von Applikationen an von Protégé-Frames erstellte Ontologien. Der Protégé-OWL-Editor ist eine Erweiterung von Protégé, die OWL unterstützt. Mit dem Protégé-OWL-Editor ist es möglich, OWL- und RDF-Ontologien zu bearbeiten und zu speichern sowie Klassen, Eigenschaften und SWRL-Regeln zu editieren und zu visualisie-

274

Vgl. ONTOPRISE (2010b).

275

Vgl. LIEBIG/NOPPENS (2004).

276

RACER steht für „Renamed Abox and Concept Expression Reasoner“ und ist ein Programm, das Schlussfolgerungsfunktionen für Ontologie-Programme bietet. Vgl. RACER (2010).

277

Vgl. SMI (2010a).

278

Vgl. STANFORD CENTER FOR BIOMEDICAL INFORMATICS RESEARCH (2010).

279

Neben der 4er-Version wird auch die 3er-Version von Protégé weiterentwickelt, da nur die 3erVersion OWL 1.0, RDF(S) und Frames unterstützt und nur die 4er-Version OWL 2.0. Ein umfassender Vergleich zwischen den beiden Versionen ist bei SMI (2009) aufgeführt.

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

87

ren. Protégé-OWL wurde mit Jena 280 , einem mit Java geschriebenen Semantic-WebFramework, entwickelt und besitzt eine Open-Source-Java-API für die Entwicklung von angepassten Benutzer-Interfaces oder beliebigen Semantic Web Services. Swoop 281 ist ein Editor und Browser für OWL-Ontologien, der das Design eines Web-Browsers besitzt. Der englische Begriff „Swoop“ bedeutet in deutsch „herabschießen“. Swoop wurde von der MINDSWAP RESEARCH GROUP im DEPARTMENT OF COMPUTER

SCIENCE an der UNIVERSITY OF MARYLAND entwickelt. Bei dem Tool handelt es sich

um eine frei verfügbare Software, die von einer durch den Hersteller betreuten Webseite heruntergeladen werden kann. 282 Die aktuelle Version lautet 2.3 Beta 4. In diesem Fall wird die Beta-Version des Tools betrachtet, da die Nutzung der letzten stabilen Version 2.2.2 vom Hersteller nicht empfohlen wird. 283 In einer Adresszeile kann der Uniform Resource Identifier (URI) einer Ontologie angegeben werden. Die Navigation erfolgt auf Basis von Hyperlinks. Es sind History-Buttons und Bookmarks verfügbar. Das Editieren von Ontologien wird durch den HTML-Renderer umgesetzt. Ein Debug-Modus zur Erkennung von Inkonsistenzen und ein Kommentar-Plug-In zur Verwaltung von Kommentaren in Gruppen sind vorhanden.

280

Jena ist ein Rahmenwerk für die Entwicklung von Applikationen für das semantische Web und wurde in Java geschrieben. Jena wird als Open Source angeboten. Vgl. HEWLETT-PACKARD (2003).

281

Vgl. MINDSWAP (2004). Eine Anfrage, ob es sich bei Swoop um ein Akronym handelt, wurde am 24.10.2010 per E-Mail von BIJAN PARSIA, einem Entwickler von Swoop, wie folgt beantwortet: „There's some controversy. IIRC, Aditya and I liked the name "Swoop" (I don't recall who coined it) because it captured the navigational feel we were aiming for. (Originally, it was just a browser and we were going to have a separate editor called SwoopEd). Jim Hendler liked everything to have an acronym or backronym, so we kicked around a few ("Semantic Web Ontologies, Only Prettier" was one) but I don't think we settled on any. That's also why you'll see it spelled both "SWOOP" and "Swoop". In generally, I spell it "Swoop" and don't give an acronym for it.”

282

Zum Download von Swoop vgl. MINDSWAP (2007).

283

Auf der Webseite ist die Version 2.3 Beta 4 als „Featured“ (deutsch: befähigt) gekennzeichnet. Wenn man die Suche auf „All downloads“ umstellt, wird auch die Version 2.2.2 angezeigt, die als „Deprecated“ (deutsch: abgelehnt) gekennzeichnet ist. Vgl. MINDSWAP (2007).

88

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

Ontologie-Tool

Apollo

Hersteller

OPEN UNIVERSITY in Walton Hall

OntoStudio

ONTOPRISE GMBH

OntoTrack

UNIVERSITÄT ULM

Protégé

Swoop

Webseite

http://apollo.open.ac.uk/ http://www.ontoprise.de/deutsch/ start/produkte/ontostudio/ http://www.informatik.uniulm.de/ki/ontotrack/

STANFORD UNIVERSITY

http://protege.stanford.edu/index.

SCHOOL OF MEDICINE

html

UNIVERSITY OF MARYLAND

http://www.mindswap.org/2004/ SWOOP/

Tabelle 13: Alternativen im AHP-Verfahren

3.2.2.2.2 Bewertung der Alternativen

Die Bewertung der Ontologie-Tools hinsichtlich der Ausschlusskriterien und Vergleichskriterien basiert auf den Anforderungen aus Kapitel 3.2.1.2.3. Zunächst werden die Ausschlusskriterien betrachtet. Die Alternativen werden hinsichtlich des Ausschlusskriteriums Sprachunterstützung daran bewertet, ob die Benutzeroberfläche und die Dokumentation, falls verfügbar, in deutscher oder englischer Sprache verfasst sind. In allen Menütexten und Dialogboxen von Apollo, OntoTrack, Protégé und Swoop wird die Sprache Englisch verwendet. In Apollo kann alternativ Tschechisch verwendet werden. Die Dokumentationen zu Apollo, OntoTrack und Protégé sind in Englisch verfügbar. Eine Dokumentation zu Swoop ist nicht verfügbar. Das Ausschlusskriterium Sprachunterstützung ist für alle fünf Alternativen erfüllt. Das Ausschlusskriterium Betriebssystemunterstützung ist erfüllt, wenn Windows oder Linux unterstützt wird. Apollo ist vollständig in Java programmiert und kann daher grundsätzlich auf allen Computerarchitekturen, unter anderem Intel, AMD, PowerPC284 , und auf allen Betriebssystemen, unter anderem Windows und Linux, betrieben werden, die die Ausführung von Java-Programmen ermöglichen. OntoStudio ist auf verschiedenen 284

PowerPC-Architekturen kamen hauptsächlich auf den PCs des US-amerikanischen Unternehmens Apple zum Einsatz. Apple wechselte im Jahr 2006 jedoch zur Intel-Architektur. Vgl. SURENDORF (2009), S. 297.

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

89

Computerarchitekturen (Intel- und AMD-Prozessor) und auf verschiedenen Betriebssystemen (Windows, Linux) ausführbar. Für die Installation von OntoStudio wird Java in der Version 5 oder höher vorausgesetzt. OntoTrack ist wie Apollo eine reine Java-Applikation und kann ebenfalls auf jedem Betriebssystem, das Java unterstützt, ausgeführt werden. Protégé kann als ausführbare Datei (EXE für Windows und BIN für Linux) heruntergeladen werden und menügestützt installiert werden. Die einzige zusätzliche Systemvoraussetzung ist eine Java Virtual Machine (JVM), bei der es sich um frei verfügbare Standardsoftware handelt. Es sind zusätzliche Installationspakete von Protégé vorhanden, die eine Java Virtual Machine eingebettet haben. Swoop basiert auf Java und ist auf verschiedenen Computerarchitekturen (Intel-, AMD- und PowerPC-Prozessor) und auf verschiedenen Betriebssystemen (Windows, Linux und Mac OSX) ausführbar. Swoop kann als ZIP-Archiv und als OSX-Image heruntergeladen werden und muss zur Installation nur in ein beliebiges Verzeichnis entpackt werden. Die einzige zusätzliche Systemvoraussetzung ist eine Java Virtual Machine. Das Ausschlusskriterium Betriebssysteme ist für alle fünf Alternativen erfüllt. Das Ausschlusskriterium Verfügbarkeit ist erfüllt, wenn eine Testversion oder alternativ eine Vollversion des Tools zum Zeitpunkt des Auswahlverfahrens unentgeltlich vom Hersteller bereitgestellt wird. Die Tools Apollo, OntoTrack, Protégé und Swoop sind alle frei verfügbar und können von der jeweiligen Webseite des Herstellers als Vollversion heruntergeladen werden. Das kommerzielle Tool OntoStudio kann von der Webseite des Herstellers als Demonstrations-Version heruntergeladen werden. Somit ist auch das Ausschlusskriterium Verfügbarkeit für alle fünf Alternativen erfüllt. Um die Alternativen hinsichtlich der weiteren Kriterien, bei denen es sich nicht um Ausschlusskriterien handelt, zu bewerten, können zwei verschiedene Bewertungsarten verwendet werden. Hierbei handelt es sich um die relative und absolute Bewertung. 285 Bei der relativen Bewertung werden die Alternativen paarweise jeweils im Hinblick auf ihre Bedeutungen für ein Kriterium miteinander verglichen.286 Diese Bewertungsart wurde bereits zuvor bei der Beurteilung der Bedeutungen der Kriterien durchgeführt. Bei der absoluten Bewertung, welche teilweise auch als Rating bezeichnet wird,287 vergleicht der Ent-

285

Vgl. ZELEWSKI/PETERS (2002), S. 22; MILLET/SAATY (2000), S. 206 ff.; SAATY (1994a), S. 430 f.; SAATY (1994b), S. 33.

286

Vgl. ZELEWSKI/PETERS (2002), S. 22; SAATY (1994b), S. 33.

287

Vgl. ZELEWSKI/PETERS (2002), S. 22; SAATY (1994b), S. 33; MILLET/SAATY (2000), S. 209; SAATY (2001a), S. 136.

90

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

scheider die Alternativen mit einem Standard, den er auf Grund seiner Erfahrung gebildet hat. 288 Der absoluten Bewertung muss also ein Benchmark zu Grunde gelegt werden. Da für die Bewertung der Ontologie-Tools keine Benchmarks existieren, wird ausschließlich die relative Bewertung verwendet. Ein Überblick über die Vergleichskriterien und Alternativen wird anhand der Hierarchie in Abbildung 16 gegeben.

Abbildung 16: Hierarchie des Entscheidungsproblems

Das Kriterium Funktionalität wird dadurch bewertet, dass alle zugehörigen Subkriterien bewertet und aggregiert werden. Begonnen wird mit dem Subkriterium Ontologieerstellung: Apollo unterstützt die Erstellung von Ontologien mit Objekten und Beziehungen. Die Erstellung von Instanzen, Klassen, Slots, Facetten, Relationen, Regeln, Prozeduren, Funktionen und Axiomen wird ermöglicht. 289 Funktionen zum Zusammenfügen von mehreren Ontologien (Merging) sind nicht vorhanden. OntoStudio ist eine Modellierungsumgebung zum Aufbau und zur Pflege von Ontologien und beinhaltet Funktionen für die Erstellung einer Ontologie mit Objekten und Beziehungen. Einfaches Zusammenfügen von Ontologien ist möglich. OntoTrack beinhaltet ebenfalls alle grundlegenden Funktionen für die 288

Vgl. ZELEWSKI/PETERS (2002), S. 22; SAATY (1994b), S. 33.

289

Vgl. MATOUŠEK/KRÁL/FALC (2004), S. 7.

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

91

Ontologieerstellung. Zum Starten des Programms ist es erforderlich, dass das externe Schlussfolgerungssystem RACER im Hintergrund läuft. Ansonsten gibt OntoTrack beim Erstellen einer neuen Ontologie die Fehlermeldung „An Exception occured“ aus. Funktionen zum Zusammenfügen von mehreren Ontologien sind nicht vorhanden. Die ProtégéPlattform unterstützt mit den Editoren Protégé-Frames und Protégé-OWL zwei Möglichkeiten, um Ontologien zu modellieren, Dateneingabe-Formulare anzupassen und Daten von Instanzen einzugeben. Protégé-Frames ist ein Editor, um Benutzer bei der Konstruktion und beim Speichern von frame-basierten Domänenontologien zu unterstützten. Mit dem Protégé-OWL-Editor ist es möglich, OWL- und RDF-Ontologien zu bearbeiten und zu speichern sowie Klassen, Eigenschaften und SWRL-Regeln zu editieren und zu visualisieren. Über ein Plug-In (PROMPT Plug-In) wird das semi-automatische Zusammenfügen von Ontologien unterstützt. Swoop ist ein Editor und Browser für OWL-Ontologien. Das Anlegen von Ontologien und Bestandteilen von Ontologien wird unterstützt. Swoop bietet eine form-basierte, thesaurus-ähnliche Oberfläche, um Ontologien zu erstellen und zu editieren. Swoop unterstützt Hyperlinking zwischen in Verbindung stehenden Begriffen von unabhängigen Ontologien. Funktionalitäten zum Zusammenfügen von Ontologien sind vorhanden, wie z.B. der Vergleich von Begriffen basierend auf Begriffsbeschreibungen.

Beurteilungsobjekt

Apollo

OntoStudio OntoTrack

Protégé

Swoop

Apollo

1

1/3

1

1/7

1/5

OntoStudio

3

1

3

1/4

1/2

OntoTrack

1

1/3

1

1/7

1/5

Protégé

7

4

7

1

2

Swoop

5

2

5

1/2

1

Tabelle 14: Bewertung der Tools hinsichtlich des Kriteriums Ontologieerstellung

Die Begründungen für die Ergebnisse der Paarvergleiche aus Tabelle 14 sind im Folgenden zu jedem erklärungsbedürftigen Paarvergleichsurteil aufgeführt: a12 )

Apollo und OntoStudio besitzen einen ähnlichen Funktionsumfang zur Ontologieerstellung. OntoStudio ermöglicht im Gegensatz zu Apollo einfaches Zusammenfügen von Ontologien. Daher wird Apollo etwas schlechter beurteilt als OntoStudio.

92

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

a13 )

Die Funktionen der beiden Tools zur Ontologieerstellung werden gleich beurteilt, da beide die grundlegenden Funktionen ermöglichen und beide das Zusammenfügen von mehreren Ontologien nicht unterstützen.

a14 )

Protégé bietet zwei Editoren und ein Plug-In für semi-automatisches Zusammenfügen von Ontologien. Apollo hingegen bietet nur einen Editor und keine Plug-Ins, um z.B. das Zusammenfügen von Ontologien zu ermöglichen, und wird daher viel schlechter beurteilt.

a15 )

Swoop besitzt neben zusätzlichen Funktionalitäten zum Zusammenfügen von Ontologien auch die Möglichkeit zum Hyperlinking. Apollo bietet beides nicht und wird daher deutlich schlechter beurteilt als Swoop.

a 23 )

OntoStudio ermöglicht im Gegensatz zu OntoTrack auch einfaches Zusammenfügen von Ontologien und wird daher etwas besser beurteilt.

a 24 )

Protégé ermöglicht semi-automatisches Zusammenfügen von Ontologien, während bei OntoStudio manuell vorzugehen ist. OntoStudio wird daher etwas bis deutlich schlechter beurteilt als Protégé.

a 25 )

Swoop besitzt im Gegensatz zu OntoStudio auch die Möglichkeit zum Hyperlinking. OntoStudio wird daher gleich bis etwas schlechter beurteilt als Swoop.

a 34 )

Protégé bietet zwei Editoren und ein Plug-In für semi-automatisches Zusammenfügen von Ontologien. OntoTrack hingegen bietet nur einen Editor und kein Zusammenfügen von Ontologien und wird daher viel schlechter beurteilt als Protégé.

a 35 )

Swoop besitzt neben zusätzlichen Funktionalitäten zum Zusammenfügen von Ontologien auch die Möglichkeit zum Hyperlinking. OntoTrack bietet beides nicht und wird daher deutlich schlechter beurteilt als Swoop.

a 45 )

Protégé ermöglicht semi-automatisches Zusammenfügen von Ontologien, während bei Swoop manuell vorzugehen ist. Protégé wird daher gleich bis etwas besser beurteilt als Swoop.

Das zum Kriterium Funktionalität gehörige Subkriterium Konsistenzprüfung wird im Folgenden bewertet: Apollo beinhaltet eine vollständige Konsistenzprüfung, die z.B. die Kompatibilität von Attributswerten zu Wertebereichen und Kardinalitäten prüft.290 Der Ontologie-Browser von OntoStudio hebt Objekte grafisch hervor, bei denen ein Konsistenz-

290

Vgl. MATOUŠEK/KRÁL/FALC (2004), S. 4.

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

93

problem festgestellt wurde, z.B. bei Attributen, Werten oder Kardinalitäten. 291 Das GUI von OntoTrack prüft die syntaktische Konsistenz von eingegebenen Statements. Protégé prüft ebenfalls die Konsistenz von Benutzereingaben z.B. in Bezug auf Namenskonventionen. Es kann eine Konsistenzprüfung gestartet werden, die logisch inkonsistente Klassen mit einer roten Markierung versieht. Zusätzlich werden benutzerdefinierte Einschränkungen (constraints) mittels eines Plug-Ins geprüft (PAL Plug-In). Swoop ermöglicht Prüfungen auf Konsistenz ausschließlich über ein Plug-In (Pellet Reasoner Plug-In). Die Inhalte dieser Prüfungen müssen zuvor durch den Benutzer definiert werden.

Beurteilungsobjekt

Apollo

OntoStudio OntoTrack

Protégé

Swoop

Apollo

1

1

1

1/3

3

OntoStudio

1

1

1

1/3

3

OntoTrack

1

1

1

1/3

3

Protégé

3

3

3

1

6

Swoop

1/3

1/3

1/3

1/6

1

Tabelle 15: Bewertung der Tools hinsichtlich des Kriteriums Konsistenzprüfung

Die Begründungen für die Ergebnisse der Paarvergleiche aus Tabelle 15 sind im Folgenden zu jedem erklärungsbedürftigen Paarvergleichsurteil aufgeführt: a 12 )

Beide Tools besitzen Konsistenzprüfungen, z.B. von Attributen, Werten und Kardinalitäten, und werden somit gleich beurteilt.

a 13 )

Auch OntoTrack besitzt diese Konsistenzprüfungen und wird daher gleich beurteilt

a 14 )

Protégé ermöglicht zusätzlich zu den Konsistenzprüfungen, die Apollo beinhaltet,

zu Apollo. benutzerdefinierte Einschränkungen, die durch die Ontologie erfüllt werden müssen und dadurch zu „strengeren“ Konsistenzprüfungen führen. Apollo wird daher etwas schlechter beurteilt als Protégé. a 15 )

Swoop benötigt im Gegensatz zu Apollo ein Plug-In zur Konsistenzprüfung, das lediglich durch den Benutzer definierte Prüfungen ausführt. Apollo wird daher etwas besser beurteilt als Swoop.

291

Vgl. hierzu die Inhalte der Online-Hilfe zu OntoStudio unter ONTOPRISE (2009).

94

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

a 23 )

Beide Tools besitzen Konsistenzprüfungen, z.B. von Attributen, Werten und Kardinalitäten, und werden daher gleich beurteilt.

a 24 )

Protégé ermöglicht zusätzlich zu den Konsistenzprüfungen, die OntoStudio beinhaltet, benutzerdefinierte Einschränkungen. OntoStudio wird daher etwas schlechter beurteilt als Protégé.

a 25 )

Swoop benötigt im Gegensatz zu OntoStudio ein Plug-In zur Konsistenzprüfung, das lediglich durch den Benutzer definierte Prüfungen ausführt. OntoStudio wird daher etwas besser beurteilt als Swoop.

a 34 )

Protégé ermöglicht zusätzlich zu den Konsistenzprüfungen, die OntoStudio beinhaltet, benutzerdefinierte Einschränkungen. OntoTrack wird daher etwas schlechter beurteilt als Protégé.

a 35 )

Swoop benötigt im Gegensatz zu OntoTrack ein Plug-In zur Konsistenzprüfung, das lediglich durch den Benutzer definierte Prüfungen ausführt. OntoTrack wird daher etwas besser beurteilt als Swoop.

a 45 )

Protégé ermöglicht zusätzlich zu den Konsistenzprüfungen, die in Swoop definiert werden können, benutzerdefinierte Einschränkungen. Außerdem ist für die Konsistenzprüfung in Swoop ein Plug-In notwendig. Protégé wird daher deutlich bis viel besser beurteilt als Swoop.

In diesem Abschnitt werden die Alternativen hinsichtlich des zum Kriterium Funktionalität gehörigen Subkriteriums Ontologiesprachen 292 bewertet: Ontologiesprachen werden zur internen Darstellung der Ontologien verwendet. Diejenigen Ontologiesprachen, die durch Exportfunktionen der Tools unterstützt werden, werden beim Kriterium Übertragbarkeit betrachtet. Importfunktionen sind für die Untersuchung nicht relevant, da die zu erstellende Ontologie nicht importiert, sondern innerhalb des ausgewählten Tools manuell eingegeben wird. Beim Subkriterium Ontologiesprachen werden somit ausschließlich die intern verwendeten Ontologiesprachen der Tools betrachtet. Apollo nutzt ein eigene proprietäre Ontologiesprache für die Repräsentation von Ontologien. 293 Mit OntoStudio können OWL-, RDF(S)- und F-Logic-Ontologien editiert werden. Außerdem kann OXML (OntoStudioeigenes XML-Format zur Datenspeicherung) genutzt werden. OntoTrack unterstützt OWL Lite und RDF(S). Protégé-Frames unterstützt frame-basierte Domänenontologien. Mit dem Protégé-OWL-Editor ist es möglich, OWL- und RDF(S)-Ontologien zu bearbeiten und zu 292

Zu den am meisten genutzten Ontologiesprachen vgl. Fußnote 226, S. 59.

293

Vgl. MATOUŠEK/KRÁL/FALC (2004), S. 4.

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

95

speichern. Außerdem wird die Semantic Web Rule Language (SWRL) unterstützt. Swoop nutzt die Sprachen RDF(S) und OWL.

Sprache Tool OWL

RDF(S)

F-Logic

sonstige

Apollo

0

0

0

X

OntoStudio

X

X

X

X

OntoTrack

X

X

0

0

Protégé

X

X

X

X

Swoop

X

X

0

0

Legende: X = unterstützte Sprache, 0 = nicht unterstützte Sprache Tabelle 16: Interne Ontologiesprachen

Beurteilungsobjekt

Apollo

OntoStudio OntoTrack

Protégé

Swoop

Apollo

1

1/7

1/3

1/6

1/4

OntoStudio

7

1

4

2

3

OntoTrack

3

1/4

1

1/3

1/2

Protégé

6

1/2

3

1

2

Swoop

4

1/3

2

1/2

1

Tabelle 17: Bewertung der Tools hinsichtlich des Kriteriums Ontologiesprachen

Die Begründungen für die Ergebnisse der Paarvergleiche aus Tabelle 17 sind im Folgenden zu jedem erklärungsbedürftigen Paarvergleichsurteil aufgeführt: a 12 )

Apollo unterstützt ausschließlich ein proprietäres Wissensmodell. OntoStudio hingegen unterstützt wahlweise die Standards OWL, RDF(S), F-Logic, Rule Interchange Format (RIF), SPARQL und ObjectLogic. Apollo wird daher viel schlechter beurteilt als OntoStudio.

a 13 )

Apollo unterstützt ausschließlich ein proprietäres Wissensmodell. OntoTrack unterstützt OWL Lite und RDF(S). Apollo wird daher etwas schlechter beurteilt als OntoTrack.

96

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

a 14 )

Apollo unterstützt ausschließlich ein proprietäres Wissensmodell. Protégé unterstützt OWL, RDF(S), F-Logic und außerdem SWRL. Apollo wird daher deutlich bis viel schlechter beurteilt als Protégé.

a 15 )

Apollo unterstützt ausschließlich ein proprietäres Wissensmodell. Swoop unterstützt die Sprachen RDF(S) und OWL. Apollo wird daher etwas bis deutlich schlechter beurteilt als Swoop.

a 23 )

OntoStudio unterstützt neben proprietären Formaten auch OWL, RDF(S) und FLogic. OntoTrack unterstützt auschließlich OWL Lite und RDF(S). OntoStudio wird daher etwas bis deutlich besser beurteilt als OntoTrack.

a 24 )

Beide Tools unterstützten OWL, RDF(S) und F-Logic. OntoStudio unterstützt außerdem RIF, SPARQL und ObjectLogic. Protégé unterstützt auch SWRL. OntoStudio wird daher gleich bis etwas besser beurteilt als Protégé.

a 25 )

Beide Tools unterstützen OWL und RDF(S). OntoStudio unterstützt auch F-Logic und andere Formate. OntoStudio wird daher etwas besser beurteilt als Swoop.

a 34 )

OntoTrack unterstützt OWL Lite und RDF(S). Protégé unterstützt OWL, RDF(S), F-Logic und außerdem SWRL. OntoTrack wird daher etwas schlechter beurteilt als Protégé.

a 35 )

Beide Tools unterstützen RDF(S). OntoTrack unterstützt auch OWL Lite und Swoop OWL. Beide Tools haben keine proprietären Sprachen. OntoTrack wird daher gleich bis etwas schlechter beurteilt als Swoop.

a 45 )

Beide Tools unterstützten OWL. Protégé unterstützt auch F-Logic und außerdem SWRL. Protégé wird daher gleich bis etwas besser beurteilt als Swoop.

Es folgt die Bewertung des Kriteriums Zuverlässigkeit: Das Starten von Apollo war mit der aktuellen Java-Version 1.6 Update 7 nicht möglich. Nach Ausführung des Startskripts und der Einblendung des Apollo-Logos wurde der Start-Prozess auf Grund einer Zugriffsverletzung abgebrochen.294 Mit der Java-Version 1.5 Update 15 konnte das Programm gestartet werden. Die Menüdarstellung wird im normalen Betrieb mit fehlerhaften Grafiken dargestellt (siehe Abbildung 17).

294

Die genaue Fehlermeldung lautet: An unexpected error has been detected by Java Runtime Environment: EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6d02c40d, pid=3912, tid=3976, Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode, sharing windows-x86), Problematic frame: C [awt.dll+0x2c40d].

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

97

Abbildung 17: Fehlerzustand in Apollo

Während der Bedienung von OntoStudio, OntoTrack, Protégé und Swoop sind keine Fehlerzustände aufgetreten.

Beurteilungsobjekt

Apollo

OntoStudio OntoTrack

Protégé

Swoop

Apollo

1

1/5

1/5

1/5

1/5

OntoStudio

5

1

1

1

1

OntoTrack

5

1

1

1

1

Protégé

5

1

1

1

1

Swoop

5

1

1

1

1

Tabelle 18: Bewertung der Tools hinsichtlich des Kriteriums Zuverlässigkeit

Die Begründungen für die Ergebnisse der Paarvergleiche aus Tabelle 18 sind im Folgenden zu jedem erklärungsbedürftigen Paarvergleichsurteil aufgeführt: a 12 )

Apollo hat Kompatibilitätsprobleme mit der neusten Java-Version. Die anderen Tools ließen sich fehlerfrei betreiben. Apollo wird daher deutlich schlechter beurteilt als die anderen Tools.

a 13 )

Siehe a 12 .

a 14 )

Siehe a 12 .

a 15 )

Siehe a 12 .

98

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

a 23 )

Alle Tools außer Apollo ließen sich fehlerfrei betreiben und werden demnach in den Paarvergleichen untereinander gleich beurteilt.

a 24 )

Siehe a 23 .

a 25 )

Siehe a 23 .

a 34 )

Siehe a 23 .

a 35 )

Siehe a 23 .

a 45 )

Siehe a 23 .

Es folgt die Bewertung des zum Kriterium Benutzbarkeit gehörenden Subkriteriums GUI: Die Benutzeroberfläche von allen betrachteten Tools ist verständlich strukturiert. Bei Apollo werden neben eindeutigen Menü-Bezeichnungen Icons zum direkten Anlegen von Ontologie-Bestandteilen angezeigt. Wenn man mit dem Mauszeiger über Icons geht, werden Erklärungen angezeigt, wie z.B. „create a new instance“. Bei OntoStudio werden mehrere Unterfenster verwendet, die dem Aufbau eines Dateibrowsers ähneln. Die MenüBezeichnungen sind eindeutig. Icons erlauben eine benutzerfreundliche Navigation. OntoTrack ermöglicht das grafische Editieren von Klassen in UML-Form. Bei Protégé werden „Kartenreiter“ für Editoren verwendet, die nach Ontologiebestandteilen, wie Klassen und Instanzen, gruppiert sind. Neben eindeutigen Menü-Bezeichnungen werden Icons zur Navigation angezeigt. Wenn man mit dem Mauszeiger über Icons geht, werden Erklärungen angezeigt, wie z.B. „Revert to a Previous Version“. Zusätzlich können Plug-Ins in Protégé genutzt werden, die das Browsen von Klassen und Eigenschaften (Plug-Ins OntoViz, TGViz) oder eine Baumstruktur als Ansicht (Jambalaya Plug-In) ermöglichen. Der Aufbau der grafischen Oberfläche von Swoop ähnelt ebenfalls einem Dateibrowser. Es werden eindeutige Menü-Bezeichnungen verwendet. Es sind Icons zum Einfügen oder Entfernen von Bestandteilen der Ontologie vorhanden. Einen Eindruck über die verschiedenen GUIs wird über die unten aufgeführten Abbildungen 18-22 vermittelt.

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

Abbildung 18: Graphical User Interface von Apollo

Abbildung 19: Graphical User Interface von OntoStudio

99

100

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

Abbildung 20: Graphical User Interface von OntoTrack

Abbildung 21: Graphical User Interface von Protégé

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

101

Abbildung 22: Graphical User Interface von Swoop

Beurteilungsobjekt

Apollo

OntoStudio OntoTrack

Protégé

Swoop

Apollo

1

1/3

1/3

1/5

1/3

OntoStudio

3

1

1

1/2

1

OntoTrack

3

1

1

1/2

1

Protégé

5

2

2

1

2

Swoop

3

1

1

1/2

1

Tabelle 19: Bewertung der Tools hinsichtlich des Kriteriums GUI

Die Begründungen für die Ergebnisse der Paarvergleiche aus Tabelle 19 sind im Folgenden zu jedem erklärungsbedürftigen Paarvergleichsurteil aufgeführt: a 12 )

Die Existenz von mehreren Unterfenstern wird als Vorteil von OntoStudio gegenüber Apollo gesehen. Apollo wird daher etwas schlechter beurteilt als OntoStudio.

102

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

a 13 )

Die grafische Modellierung in UML-Form in OntoTrack ist vielfältiger als die statische Hierarchie bei Apollo. Apollo wird daher etwas schlechter beurteilt als OntoTrack.

a 14 )

Protégé bietet im Gegensatz zu Apollo neben Kartenreitern auch diverse Plug-Ins für das GUI. Apollo wird daher deutlich schlechter beurteilt als Protégé.

a 15 )

Die Existenz von mehreren Unterfenstern wird als Vorteil von Swoop gegenüber Apollo gesehen. Apollo wird daher etwas schlechter beurteilt als Swoop.

a 23 )

Die beiden Tools wurden in Bezug auf das GUI gleich beurteilt. OntoStudio besitzt umfassendere Menüseiten. Bei OntoTrack ist dagegen die grafische Ansicht vielfältiger.

a 24 )

Der Vorteil von Protégé gegenüber OntoStudio ist die Möglichkeit, Plug-Ins für das GUI zu nutzen. OntoStudio wird daher gleich bis etwas schlechter beurteilt als Protégé.

a 25 )

Die beiden Tools werden in Bezug auf das GUI gleich beurteilt. Beide Tools besitzen umfassende Menüseiten.

a 34 )

Der Vorteil von Protégé gegenüber OntoTrack ist die Möglichkeit, Plug-Ins für das GUI zu nutzen. OntoTrack wird daher gleich bis etwas schlechter beurteilt als Protégé.

a 35 )

Die beiden Tools werden in Bezug auf das GUI gleich beurteilt. Swoop besitzt umfassendere Menüseiten. Bei OntoTrack ist dagegen die grafische Ansicht vielfältiger.

a 45 )

Der Vorteil von Protégé gegenüber Swoop ist die Möglichkeit, Plug-Ins für das GUI zu nutzen. Protégé wird daher gleich bis etwas besser beurteilt als Swoop.

Es folgt die Bewertung des zum Kriterium Benutzbarkeit gehörenden Subkriteriums Dokumentation: Die Dokumentation von Apollo ist online verfügbar.295 Sie beinhaltet die Erklärung der grafischen Oberfläche des Tools, des zu Grunde liegenden Wissensmodells und der entsprechenden Funktionalitäten des Tools. Die Bestandteile des Menüs werden mit Screenshots erklärt. Die Dokumentation von OntoStudio ist ebenfalls online verfügbar. 296 Sie beinhaltet die Benutzerhandbücher zu den aktuellen Produkten von ONTOPRISE und kann menügestützt durchsucht werden. Auch die Dokumentation von OntoTrack ist

295

Vgl. MATOUŠEK/KRÁL/FALC (2004).

296

Vgl. ONTOPRISE (2009).

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

103

online verfügbar. 297 Die Funktionen des Tools werden mit Screenshots erklärt. Und auch die Dokumentation von Protégé ist online verfügbar. 298 Sie umfasst häufig gestellte Fragen, Tutorials, Präsentationen und weitergehende Informationen. Für Swoop ist keine Dokumentation verfügbar. Dies erschwert die Einarbeitung in das Tool in hohem Maße. Da keine Hilfetexte zu den Icons vorhanden sind, muss man teilweise nach dem Prinzip Trialand-Error 299 verfahren.

Beurteilungsobjekt

Apollo

OntoStudio OntoTrack

Protégé

Swoop

Apollo

1

1/3

1

1/5

9

OntoStudio

3

1

3

1/2

9

OntoTrack

1

1/3

1

1/5

9

Protégé

5

2

5

1

9

Swoop

1/9

1/9

1/9

1/9

1

Tabelle 20: Bewertung der Tools hinsichtlich des Kriteriums Dokumentation

Die Begründungen für die Ergebnisse der Paarvergleiche aus Tabelle 20 sind im Folgenden zu jedem erklärungsbedürftigen Paarvergleichsurteil aufgeführt: a 12 )

Die Dokumentation von OntoStudio ist umfangreicher und kann menügestützt durchsucht werden. Apollo wird daher etwas schlechter beurteilt als OntoStudio.

a 13 )

Die beiden Tools werden in Bezug auf die Dokumentation gleich beurteilt, da zu beiden Tools Dokumentationen im Internet zur Verfügung stehen, die einen ungefähr gleichen Umfang besitzen.

a 14 )

Die Dokumentation von Protégé besitzt einen sehr viel größeren Umfang als die von Apollo und umfasst außerdem häufig gestellte Fragen, Tutorials, Präsentationen und weitergehende Informationen. Apollo wird daher deutlich schlechter beurteilt als Protégé.

297

Vgl. LIEBIG/NOPPENS (2004).

298

Vgl. SMI (2010b).

299

Beim Trial-and-Error-Prinzip handelt es sich um eine von DARWIN beschriebene Lernstrategie, bei der zuerst gehandelt wird und später die Handlung beurteilt wird. Vgl. TRAILL (2008), S. 27 u. 30. Im vorliegenden Fall bedeutet dies, dass zunächst auf die Icons von Swoop geklickt werden musste und im Nachhinein die Auswirkungen beobachtet werden konnten.

104

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

a 15 )

Die fehlende Dokumentation von Swoop ist als gravierender Nachteil zu sehen und daher wird Apollo sehr viel besser beurteilt als Swoop. 300

a 23 )

Die Dokumentation von OntoStudio ist umfangreicher und kann menügestützt durchsucht werden. OntoStudio wird daher etwas besser beurteilt als OntoTrack.

a 24 )

Beide Tools besitzen eine umfangreiche Dokumentation. Die Dokumentation von Protégé umfasst zusätzlich auch häufig gestellte Fragen, Tutorials, Präsentationen und weitergehende Informationen. OntoStudio wird daher gleich bis etwas schlechter beurteilt als Protégé.

a 25 )

Die fehlende Dokumentation von Swoop ist als gravierender Nachteil zu sehen und daher wird OntoStudio sehr viel besser beurteilt als Swoop.

a 34 )

Die Dokumentation von Protégé besitzt einen sehr viel größeren Umfang und umfasst auch häufig gestellte Fragen, Tutorials, Präsentationen und weitergehende Informationen. OntoTrack wird daher deutlich schlechter beurteilt als Protégé.

a 35 )

Die fehlende Dokumentation von Swoop ist als gravierender Nachteil zu sehen und daher wird OntoTrack sehr viel besser beurteilt als Swoop.

a 45 )

Die fehlende Dokumentation von Swoop ist als gravierender Nachteil zu sehen und daher wird Protégé sehr viel besser beurteilt als Swoop.

Das Kriterium der Übertragbarkeit wird in Bezug auf die Funktionen zum Export von Ontologiewissen bewertet. Das Ontologie-Tool soll bei Exporten von Ontologien konform zu standardisierten Repräsentationssprachen sein. Zu den am meisten genutzten standardisierten Repräsentationssprachen von Ontologien zählen OWL, RDF(S) und F-Logic.301 Ontologien können von Apollo in die Formate RDF(S), XML, Meta und OCML exportiert werden. Die Exporte werden durch Output-Plug-Ins umgesetzt.302 Die ExportFunktion von OntoStudio ermöglicht das Speichern von Ontologien in den Formaten FLogic, OWL, RDF(S) und dem proprietären Format OXML. OntoTrack kann Ontologien als RDF(S), XML oder N-Triple303 speichern. Mit Protégé erstellte Ontologien können in 300

Obwohl alle Tools untereinander in Bezug zur Dokumentation unterschiedlich beurteilt werden, besitzen sie zu Swoop durchgehend eine sehr viel vorteilhaftere Kriterienausprägung. Zu Swoop ist keine Dokumentation verfügbar, was so negativ beurteilt wird, dass im Vergleich stets die schlechsteste Beurteilung zum Tragen kommt.

301

Vgl. Fußnote 226, S. 59.

302

Vgl. MATOUŠEK/KRÁL/FALC (2004), S. 9.

303

N-Triple ist ein Format, das die Speicherung von Antworten zu RDF-Testfällen im Klartext vorsieht. Vgl. W3C (2001).

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

105

die Formate RDF(S), OWL und XML exportiert werden. Durch Swoop können Ontologien in die Formate SWO (Swoop Ontology Object File), OWL, RDF(S), XML und TXT exportiert werden.

Sprache Tool OWL

RDF(S)

F-Logic

sonstige

Apollo

0

X

0

X

OntoStudio

X

X

X

X

OntoTrack

0

X

0

X

Protégé

X

X

0

X

Swoop

X

X

0

X

Legende: X = unterstützte Sprache, 0 = nicht unterstützte Sprache Tabelle 21: Ontologiesprachen beim Export

Beurteilungsobjekt

Apollo

OntoStudio OntoTrack

Protégé

Swoop

Apollo

1

1/5

1

1/3

1/3

OntoStudio

5

1

5

3

3

OntoTrack

1

1/5

1

1/3

1/3

Protégé

3

1/3

3

1

1

Swoop

3

1/3

3

1

1

Tabelle 22: Bewertung der Tools hinsichtlich des Kriteriums Übertragbarkeit

Die Begründungen für die Ergebnisse der Paarvergleiche aus Tabelle 22 sind im Folgenden zu jedem erklärungsbedürftigen Paarvergleichsurteil aufgeführt: a 12 )

OntoStudio unterstützt zwei der am meisten genutzten Ontologiesprachen mehr als Apollo. Apollo wird daher deutlich schlechter beurteilt als OntoStudio.

a 13 )

Beide Tools werden hier auf Grund der gleichen Unterstützung der am meisten genutzten Ontologiesprachen gleich beurteilt.

a 14 )

Protégé unterstützt eine der am meisten genutzten Ontologiesprachen mehr als Apollo. Apollo wird daher etwas schlechter beurteilt als Protégé.

106

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

a 15 )

Swoop unterstützt eine der am meisten genutzten Ontologiesprachen mehr als Apollo. Swoop wird daher etwas schlechter beurteilt als Apollo.

a 23 )

OntoStudio unterstützt zwei der am meisten genutzten Ontologiesprachen mehr als OntoTrack und wird daher deutlich besser beurteilt als OntoTrack.

a 24 )

OntoStudio unterstützt eine der am meisten genutzten Ontologiesprachen mehr als

a 25 )

OntoStudio unterstützt eine der am meisten genutzten Ontologiesprachen mehr als

Protégé und wird daher etwas besser beurteilt als Protégé. Swoop und wird daher etwas besser beurteilt als Swoop. a 34 )

Protégé unterstützt eine der am meisten genutzten Ontologiesprachen mehr als On-

a 35 )

Swoop unterstützt eine der am meisten genutzten Ontologiesprachen mehr als On-

toTrack. OntoTrack wird daher etwas schlechter beurteilt als Protégé. toTrack. OntoTrack wird daher etwas schlechter beurteilt als Swoop. a 45 )

Beide Tools werden hier auf Grund der gleichen Unterstützung der am meisten genutzten Ontologiesprachen gleich beurteilt.

In Kapitel 3.2.1.2.3 wurde die Konsistenz der Paarvergleichsurteile in den Evaluationsmatrizen zur Beurteilung der relativen Bedeutung der Kriterien und Subkriterien geprüft. Die Evaluationsmatrizen bei der Bewertung der Alternativen können ebenfalls auf Konsistenz der Paarvergleichsurteile geprüft werden. Die Paarvergleichsurteile müssen bei zu hohen Inkonsistenzwerten überarbeitet werden, bis der Inkonsistenzwert kleiner oder gleich dem festgelegten Schwellenwert ist. 304 Die Durchführung der Konsistenzprüfung erfolgt wieder mit dem Tool Expert Choice. Es wurden folgende Inkonsistenzwerte festgestellt:

304

Vgl. ZELEWSKI/PETERS (2002), S. 24.

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen Bezug der

Übergeordnetes

Paarvergleichsurteile

Kriterium

Ontologieerstellung

Funktionalität

0,01

Konsistenzprüfung

Funktionalität

0,01

Ontologiesprachen

Funktionalität

0,02

Zuverlässigkeit

nicht vorhanden

0,00

GUI

Benutzbarkeit

0,00

Dokumentation

Benutzbarkeit

0,09

Übertragbarkeit

nicht vorhanden

0,02

107

Inkonsistenzwert

Tabelle 23: Inkonsistenzwerte der Evaluationsmatrizen

Da der festgelegte Schwellenwert 305 0,10 bei keiner Evaluationsmatrix erreicht wurde, ist eine Überarbeitung der Paarvergleichsurteile nicht notwendig. Die gesamte Inkonsistenz (Overall Inconsistency) wird mit dem Wert 0,03 angegeben. Die Paarvergleichsurteile aus den Evaluationsmatrizen werden zur Bewertung der Alternativen zu Bedeutungsurteilen aggregiert, die nachfolgend als Prioritäten bezeichnet werden. Die beiden Vorgehensweisen, die hierzu von SAATY entwickelt wurden, werden als Distributive Mode und Ideal Mode bezeichnet.306 Das Vorgehen beim Distributive Mode entspricht dem Vorgehen aus Abschnitt 3.2.1.2.3. Beim Ideal Mode wird analog zum Distributive Mode zunächst eine normierte Evaluationsmatrix N gebildet und anschließend werden alle Zeilensummen s i durch die maximale Zeilensumme max( s i ) dividiert, um die Prioritäten p i zu erhalten. 307 si

n

¦a

ij

p idi

j 1

si max(s i )

i 1,...., n

(3.15)

Wenn festgestellt werden soll, in welchem Ausmaß eine Alternative die anderen Alternativen dominiert, sollte der Distributive Mode und, wenn festgestellt werden soll, wie eine Alternative im Vergleich zu einem festgelegten Benchmark eingestuft wird, sollte der Ideal 305

Vgl. Kapitel 3.2.1.2.3, S. 66.

306

Vgl. ZELEWSKI/PETERS (2002), S. 24; MILLET/SAATY (2000), S. 206 ff.; SAATY (1994a), S. 442 ff.; SAATY (1994b), S. 29 ff.; SAATY (2000), S. 138 ff.

307

Vgl. ZELEWSKI/PETERS (2002), S. 25.

108

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

Mode gewählt werden. 308 Weitere Vorgehensweisen zur Bestimmung der Prioritäten können in der Literatur nachgeschlagen werden. 309 Da im vorliegenden Fall eine Antwort darauf gesucht wird, in welchem Ausmaß eine Alternative die anderen Alternativen dominiert, und kein Benchmark genutzt wird, ist hier der Distributive Mode zu wählen. Um die Prioritäten nach dem Distributive Mode berechnen zu können, müssen die Evaluationsmatrizen normiert werden. Um dies zu verdeutlichen, wird eine exemplarische Normierung für die Evaluationsmatrix A hinsichtlich des Kriteriums Ontologieerstellung aus Tabelle 14 durchgeführt. Für eine Approximation der Bedeutungsurteile wird jedes Paarvergleichsurteil durch seine jeweilige Spaltensumme dividiert. Für jede Alternative ist ein Bedeutungsurteil v i zu berechnen, das dem normierten Eigenvektor der Evaluationsmatrix näherungsweise entspricht. Dies erfolgt durch die Bildung der Zeilensummen der normierten Evaluationsmatrix und die Division jeder Zeilensumme durch n, die Anzahl an Alternativen.

Spaltensummen aus A Beurteilungsobjekt

10,143

Apollo

7,667

17,000

Onto-

Onto-

Studio

Track

2,036

3,900

Protégé

Swoop

Zeilen-

Bedeutungs-

summe

urteile v i

Apollo

0,099

0,043

0,059

0,070

0,051

0,322

0,064

OntoStudio

0,296

0,130

0,176

0,123

0,128

0,853

0,171

OntoTrack

0,099

0,043

0,059

0,070

0,051

0,322

0,064

Protégé

0,014

0,522

0,412

0,491

0,513

1,952

0,390

Swoop

0,493

0,261

0,294

0,246

0,256

1,550

0,310

Tabelle 24: Berechnung der Bedeutungsurteile

Wie bereits in Kapitel 3.2.1.2.3 beschrieben, werden in Expert Choice exaktere Werte durch die Berechnung des Eigenwerts und der Anwendung der Power-Methode verwendet.

308

Vgl. MILLET/SAATY (2000), S. 208.

309

Vgl. z.B. ZELEWSKI/PETERS (2002), S. 25; MILLET/SAATY (2000), S. 208; SAATY (2000), S. 140 ff.

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

109

3.2.2.2.3 Selektion der geeignetsten Alternative

Um die Gesamtpriorität einer Alternative zu erhalten, müssen die Bewertungen der Alternativen, also die Einzelprioritäten zu den Subkriterien der untersten Ebene, aggregiert werden. Mit Hilfe der für jede Alternative ermittelten Gesamtpriorität kann die geeignetste Alternative identifiziert werden. Um die Gesamtpriorität Pj für jede Alternative j zu berechnen, werden die Einzelprioritäten p ij der Alternativen gewichtet, indem sie mit dem aggregierten Bedeutungsurteil w ij für das jeweilige (Sub-)Kriterium i auf der untersten Stufe der Kriterienhierarchie multipliziert (gewogenes arithmetisches Mittel) werden, und über alle Kriterien auf der jeweils untersten Stufe der Kriterienhierarchie addiert: 310 n

Pj

¦w

ij

˜ p ij

(3.16)

i 1

Die Gesamtpriorität Pj beinhaltet die Bewertungen einer Alternative im Hinblick auf Kriterien unter Berücksichtigung ihrer Bedeutungen. 311 In der letzten Spalte der Tabelle 25 sind alle gewichteten Einzelprioritäten w ij ˜ p ij dargestellt.312 Die Gesamtprioritäten Pj der einzelnen Alternativen wurden dadurch berechnet, dass die gewichteten Einzelprioritäten für alle Subkriterien auf der zweiten Kriterienebene (Ebene 2) und anschließend für alle Kriterien auf der ersten Kriterienebene (Ebene 1) kumuliert wurden. „L“ ist die Abkürzung für „Leverage“ (deutsch: Hebel) und steht für die Bedeutungsurteile w ij .

310

Vgl. ZELEWSKI/PETERS (2002), S. 26.

311

Vgl. ZELEWSKI/PETERS (2002), S. 26.

312

Diese Ergebnisse entsprechen den Ergebnissen von Expert Choice, die im Fenster „Synthesis Results“ dargestellt wurden. Hier gibt es eine Karteikarte „Details“, auf der die Einzelprioritäten und Gesamtprioritäten nach Alternativen sortiert werden können. Die hier aufgeführten Gesamtprioritäten unterscheiden sich von den Gesamtprioritäten, die im rechten Teil des Hauptfensters von Expert Choice dargestellt werden. Diese Abweichung liegt darin begründet, dass im Fenster „Synthesis Results“ genau bis zur dritten Nachkommastelle gerechnet wird. Im Hauptfenster existiert diese Begrenzung nicht und daher entstehen Abweichungen auf der Ebene der dritten Nachkommastelle.

110

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

Alternative

Ebene 1

Ebene 2

kumuliert Benutzbarkeit (L: ,262) Apollo Funktionalität (L: ,565) Übertragbarkeit (L: ,118) Zuverlässigkeit (L: ,055) kumuliert Benutzbarkeit (L: ,262) OntoStudio Funktionalität (L: ,565) Übertragbarkeit (L: ,118) Zuverlässigkeit (L: ,055) kumuliert Benutzbarkeit (L: ,262) OntoTrack Funktionalität (L: ,565) Übertragbarkeit (L: ,118) Zuverlässigkeit (L: ,055) kumuliert Benutzbarkeit (L: ,262) Protégé Funktionalität (L: ,565) Übertragbarkeit (L: ,118) Zuverlässigkeit (L: ,055) kumuliert Benutzbarkeit (L: ,262) Swoop Funktionalität (L: ,565) Übertragbarkeit (L: ,118) Zuverlässigkeit (L: ,055)

kumuliert GUI (L: ,875) Dokumentation (L: ,125) kumuliert Ontologieerstellung (L: ,727) Konsistenzprüfung (L: ,091) Ontologiesprachen (L: ,182) [keine Subkriterien vorhanden] [keine Subkriterien vorhanden] kumuliert GUI (L: ,875) Dokumentation (L: ,125) kumuliert Ontologieerstellung (L: ,727) Konsistenzprüfung (L: ,091) Ontologiesprachen (L: ,182) [keine Subkriterien vorhanden] [keine Subkriterien vorhanden] kumuliert GUI (L: ,875) Dokumentation (L: ,125) kumuliert Ontologieerstellung (L: ,727) Konsistenzprüfung (L: ,091) Ontologiesprachen (L: ,182) [keine Subkriterien vorhanden] [keine Subkriterien vorhanden] kumuliert GUI (L: ,875) Dokumentation (L: ,125) kumuliert Ontologieerstellung (L: ,727) Konsistenzprüfung (L: ,091) Ontologiesprachen (L: ,182) [keine Subkriterien vorhanden] [keine Subkriterien vorhanden] kumuliert GUI (L: ,875) Dokumentation (L: ,125) kumuliert Ontologieerstellung (L: ,727) Konsistenzprüfung (L: ,091) Ontologiesprachen (L: ,182) [keine Subkriterien vorhanden] [keine Subkriterien vorhanden]

Tabelle 25: Einzelprioritäten in Expert Choice

Priorität 6,7% 1,9% 1,5% 0,4% 3,6% 2,3% 0,8% 0,5% 0,9% 0,3% 23,2% 5,2% 4,3% 0,9% 11,2% 6,0% 0,8% 4,4% 5,5% 1,3% 11,0% 4,7% 4,3% 0,4% 4,1% 2,3% 0,8% 1,0% 0,9% 1,3% 38,0% 9,9% 8,4% 1,5% 24,5% 19,4% 2,3% 2,8% 2,3% 1,3% 21,0% 4,4% 4,3% 0,1% 13,0% 11,1% 0,3% 1,6% 2,3% 1,3%

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

111

Apollo; 6,7% OntoStudio; 23,2% OntoStudio; 23,2% OntoTrack; OntoTrack; 11,0% 11,0% Protégé; 38,0% Swoop; 21,0%

0%

10%

20%

30%

40%

50%

Abbildung 23: Gesamtprioritäten in Expert Choice

Die Alternativen können beim AHP-Verfahren einer Rangvertauschung („Rank Reversal“) unterliegen. Dies äußert sich dadurch, dass sich der Rang der Alternativen ändert, wenn bei der Bewertung von Alternativen im Hinblick auf mehrere Kriterien zu den bestehenden Alternativen weitere Alternativen hinzugefügt oder Alternativen entfernt werden.313 Auf Grund der Rangvertauschung wurden neben dem ursprünglich von SAATY entwickelten Distributive Mode weitere Vorgehensweisen zur Aggregation der Paarvergleichsurteile zu Prioritäten, wie beispielsweise der Ideal Mode, entwickelt.314 Allerdings wurde bewiesen, dass eine Rangvertauschung z.B. durch den Ideal Mode nicht grundsätzlich verhindert werden kann. 315 Die Möglichkeit einer Rangvertauschung wird im Folgenden durch das schrittweise Entfernen jeder einzelnen Alternative untersucht. Das Entfernen einer Alternative ist in Expert Choice mit dem Deaktivieren einer Alternative gleichzusetzen. Das Hinzufügen neuer Alternativen entspricht dem entgegengesetzten Vorgehen. Die Rangfolge der fünf Alternativen wird als Ausgangspunkt betrachtet und mit der Rangfolge von beliebigen vier Alternativen verglichen.

313

Vgl. ZELEWSKI/PETERS (2002), S. 27; SAATY (1994a), S. 441 ff.; SAATY (1994b), S. 36 ff.; SAATY (2000), S. 129 ff.; SAATY (2001a), S.146 f.; SAATY/VARGAS (2001), S. 40 ff.

314

Vgl. ZELEWSKI/PETERS (2002), S. 27.

315

Vgl. ZELEWSKI/PETERS (2002), S. 33.

112

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

Alternativen

Rang

Rang

Rang

Rang

Rang

Rang

Apollo

5

inaktiv

4

4

4

4

OntoStudio

2

2

inaktiv

2

2

2

OntoTrack

4

4

3

inaktiv

3

3

Protégé

1

1

1

1

inaktiv

1

Swoop

3

3

2

3

1

inaktiv

Tabelle 26: Änderung der Rangordnung beim Entfernen von Alternativen

Beim Entfernen der Alternative Protégé hat sich die Rangfolge der verbleibenden Alternativen geändert. Swoop steht in der Rangfolge nun vor OntoStudio und nicht, wie bei der Betrachtung aller Alternativen, nach OntoStudio. Analog dazu ändert sich die Rangfolge der vier anderen Alternativen, wenn Protégé hinzugefügt wird. Da eine Rangvertauschung in der vorliegenden Bewertung nicht erwünscht ist, handelt es sich bei diesem Effekt um einen Nachteil des AHP-Verfahrens, der bewusst akzeptiert werden muss.

Apollo; 10,7%

OntoTrack; OntoTrack; 17,5% 17,5%

OntoStudio; OntoStudio; OntoStudio; 35,8% 35,8% 35,8%

Swoop; 35,9%

0%

10%

20%

30%

40%

50%

Abbildung 24: Gesamtprioritäten nach Entfernen der Alternative Protégé

Das Ontologie-Tool, das für die Verwendung innerhalb des ontologiegestützten CBRSystems ausgewählt wird, ist Protégé.

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

113

3.2.2.3 Auswahl eines CBR-Tools 3.2.2.3.1 Marktanalyse zur Identifizierung von Alternativen

CASPIAN 316 ist ein MSDOS-Programm, das von der UNIVERSITY

OF

WALES in Abe-

rystwyth, England entwickelt wurde. Das CBR-Tool ist frei verfügbar und kann von der Webseite der Universität kostenlos heruntergeladen werden. CBR-Shell 317 ist ein CBR-Tool des ARTIFICIAL INTELLIGENCE APPLICATIONS INSTITUTE

(AIAI) der UNIVERSITY OF EDINBURGH in England. Es handelt sich um ein Java-

Applet, das unter Windows 2000 und XP betrieben werden kann. Induce-It 318 ist ein kommerzielles Produkt des US-amerikanischen Unternehmens INDUCTIVE SOLUTIONS INC. Das Tool ist ein Excel-Plug-In, das in Excel gespeichertes Fallwissen verarbeiten kann. jCOLIBRI 2 319 ist ein Framework in Java zur Erstellung von CBR-Systemen. jCOLIBRI steht für java Cases and Ontology Libraries Integration for Building Reasoning Infrastructures und wurde von der GROUP

FOR

ARTIFICIAL INTELLIGENCE APPLICATIONS

(GAIA) der UNIVERSITÄT VON MADRID entwickelt. Das Framework ist frei verfügbar und kann von der Webseite heruntergeladen werden. Da es sich bei jCOLIBRI um kein CBRTool im engeren Sinn handelt, sondern eher um eine Entwicklungsumgebung für ein zu entwickelndes CBR-Tool, wird jCOLIBRI nicht als mögliche Alternative betrachtet und somit nicht in das Auswahlverfahren einbezogen. MyCBR 320 vom DEUTSCHEN FORSCHUNGSZENTRUM FÜR KÜNSTLICHE INTELLIGENZ GMBH (DFKI) 321 kann selbstständig oder als Protégé-Plug-In genutzt werden. Das Tool ist frei verfügbar. MyCBR ist Open Source und wurde unter der GPL-Lizenz entwickelt. Die Ziele des Projekts sind einfache Bedienbarkeit, schnelle Erstellung von Prototypen, Erweiterbarkeit, Adaptierbarkeit und die Integration aktueller CBR-Funktionalitäten. MyCBR unterstützt den Import von CSV-Dateien, die Modellierung von Ähnlichkeiten, ähnlichkeitsbasiertes Retrieval, den Export eines Domänenmodells in XML und eine zusätzliche selbstständige Retrieval-Engine. 316

Vgl. ABERYSTWYTH UNIVERSITY (2001a).

317

Vgl. ARTIFICIAL INTELLIGENCE APPLICATIONS INSTITUTE (2002a).

318

Vgl. INDUCTIVE SOLUTIONS (2006).

319

Vgl. GROUP FOR ARTIFICIAL INTELLIGENCE APPLICATIONS (2010).

320

Vgl. DFKI (2007).

321

Vgl. DFKI (2010).

114

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen KAIDARA Advisor ist ein kommerzielles Produkt des US-amerikanischen Unter-

nehmens KAIDARA SOFTWARE INC. Das Tool bietet diverse fallbasierte Suchmechanismen, um Problemfälle zu lösen.

CBR-Tool

Hersteller

CASPIAN

UNIVERSITY OF WALES

CBR-Shell Induce-It

weitere Informationen

ARTIFICIAL INTELLIGENCE APPLICATIONS INSTITUTE

(AIAI)

INDUCTIVE SOLUTIONS INC.

http://www.aber.ac.uk/compsci/Research/ mbsg/cbrprojects/getting_caspian.shtml http://www.aiai.ed.ac.uk/project/cbr/ http://www.inductive.com/softcase.htm

GROUP FOR ARTIFICIAL INTELjColibri

LIGENCE APPLICATIONS

(GAIA), UNIVERSITÄT VON

http://gaia.fdi.ucm.es/projects/jcolibri/

MADRID DEUTSCHES FORMyCBR

SCHUNGSZENTRUM FÜR

KÜNSTLICHE INTELLIGENZ

http://mycbr-project.net/

GMBH (DFKI) KAIDARA Advisor

KAIDARA SOFTWARE INC.

http://www.kaidara.com/

Tabelle 27: Alternativen im AHP-Verfahren

3.2.2.3.2 Bewertung der Alternativen

Die Bewertung der CBR-Tools erfolgt in Bezug auf die Anforderungen aus Kapitel 3.2.1.2.4. Die Bewertung der Alternativen beginnt mit der Betrachtung der Ausschlusskriterien. Als Ausschlusskriterien wurden die Sprachunterstützung der Benutzeroberfläche, die Betriebssystemunterstützung und die Verfügbarkeit festgelegt. Die Alternativen werden hinsichtlich des Ausschlusskriteriums Sprachunterstützung daran bewertet, ob die Benutzeroberfläche und Dokumentation in deutscher oder englischer Sprache verfügbar sind. Die CBR-Tools CASPIAN, CBR-Shell, Induce-It und MyCBR unterstützen sowohl auf der Benutzeroberfläche als auch in der Dokumentation ausschließlich Englisch. KAIDARA Advisor konnte nicht betrachtet werden, da keine Test-

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

115

version zur Verfügung stand. Das Ausschlusskriterium Sprachunterstützung ist für die Alternativen CASPIAN, CBR-Shell, Induce-It und MyCBR erfüllt. Für KAIDARA Advisor konnte das Kriterium nicht bewertet werden. Das Ausschlusskriterium Betriebssystemunterstützung ist erfüllt, wenn Windows oder Linux unterstützt werden. CASPIAN ist auf Windows 2000 und Windows XP installierbar. CBR-Shell wird als Applet ausgeführt, erfordert keine Installation und kann unter Windows, Mac OS und Linux ausgeführt werden. Induce-It unterstützt Windows, Mac OS und Sun Solaris. MyCBR ist eine Java-Applikation und kann selbstständig oder als Protégé-Plug-In unter Windows oder Linux betrieben werden. KAIDARA Advisor konnte nicht betrachtet werden, da keine Testversion zur Verfügung stand. Das Ausschlusskriterium Betriebssystemunterstützung ist für die Alternativen CASPIAN, CBR-Shell, Induce-It und MyCBR erfüllt. Für KAIDARA Advisor konnte das Kriterium nicht bewertet werden. Die Verfügbarkeit ist erfüllt, wenn eine Testversion des Tools zum Zeitpunkt des Auswahlverfahrens unentgeltlich vom Hersteller bereitgestellt wird. Die CBR-Tools CASPIAN, CBR-Shell und MyCBR sind frei verfügbar und können von der jeweiligen Webseite des Herstellers heruntergeladen werden. Von Induce-It wurde eine Testversion für die Untersuchung durch den Hersteller zur Verfügung gestellt. Für KAIDARA Advisor wurden hingegen keine Testversionen zur Verfügung gestellt. Laut Aussage von KAIDARA ist die Herausgabe einer Testversion nicht möglich. 322 Aus diesem Grund konnten die obigen Kriterien nicht bewertet werden. KAIDARA Advisor wird somit aus dem weiteren Auswahlverfahren ausgeschlossen, da mindestens ein Ausschlusskriterium nicht erfüllt wurde. Für die Bewertung der CBR-Tools wird analog zur Bewertung der Ontologie-Tools ausschließlich die relative und nicht die absolute Bewertung verwendet. In der unten dargestellten Abbildung 25 ist die Hierarchie des Entscheidungsproblems, der Auswahl eines CBR-Tools für ontologiegestütztes Case-Based Reasoning, ersichtlich.

322

Eine schriftliche Anfrage bzgl. der Verfügbarkeit einer Testversion wurde durch KAIDARA am 05.09.2008 beantwortet. Sie enthielt den Text „Unfortunately we do no have a demo version of the software”.

116

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

Abbildung 25: Hierarchie des Entscheidungsproblems

Im Folgenden wird dargestellt, in welcher Ausprägung die einzelnen CBR-Tools eine Unterstützung der verschiedenen Algorithmen anbieten: In CASPIAN kann kein benutzerdefinierter Algorithmus verwendet werden. Stattdessen muss in CASPIAN ein hinterlegter Algorithmus verwendet werden, der jedoch nicht spezifiziert ist. Aus der Dokumentation geht lediglich hervor, dass ein gewichtetes Mittel verwendet wird. In CBR-Shell ist eine benutzerdefinierte Anpassung der Parameter des Algorithmus möglich. Z.B. können Gewichte manuell gesetzt oder durch einen genetischen Algorithmus 323 verändert werden. Die

323

Die Forschungen zu genetischen Algorithmen wurden durch den natürlichen Prozess der Evolution von Pflanzen- und Tierarten inspiriert. Vgl. FALKENAUER (1998), S. 26. Ein Aspekt davon ist die Idee, dass Charakteristiken, die während der Lebensdauer eines Organismus erlangt werden, auf die Nachkommen vererbbar sind. Vgl. CHAMBERS (1999), S. 1. Ein genetischer Algorithmus kann grob als Vorgang bezeichnet werden, um von einer Population zu einer anderen zu gelangen. Zu diesem Zweck werden genetische Operatoren verwendet, z.B. Überführung, Reproduktion, Mutation und Inversion. Vgl. FALKENAUER (1998), S. 37 ff.

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

117

Genauigkeit des Algorithmus wird durch eine Leave-One-Out-Evaluation 324 gemessen. Induce-It unterstützt diverse Algorithmen, um die lokalen Ähnlichkeitswerte325 zu einem globalen Ähnlichkeitswert326 zu aggregieren. Es handelt sich bei diesen Algorithmen um eine gewichtete Summe (hier: Weighted Score), eine euklidische Summe (hier: Euclidean Score), eine Kosinusfunktion (hier: Cosinus Score) und eine Fuzzy-Funktion (hier: Fuzzy Logic Score). MyCBR unterstützt als Algorithmen die gewichtete Summe 327 (hier: Weighted Sum), die euklidische Summe (hier: Euclidean), Minimum und Maximum.

Beurteilungsobjekt

CASPIAN

CBR-Shell

Induce-It

MyCBR

CASPIAN

1

1/3

1/7

1/5

CBR-Shell

3

1

1/5

1/3

Induce-It

7

5

1

3

MyCBR

5

3

1/3

1

Tabelle 28: Bewertung der Tools hinsichtlich des Kriteriums Algorithmen

Die Begründungen für die Ergebnisse der Paarvergleiche aus Tabelle 28 sind im Folgenden zu jedem erklärungsbedürftigen Paarvergleichsurteil aufgeführt: a 12 )

CBR-Shell erlaubt im Gegensatz zu CASPIAN benutzerdefinierte Anpassungen des

a 13 )

Induce-It unterstützt eine Vielzahl an Algorithmen, während CASPIAN lediglich

Algorithmus. CASPIAN wird daher etwas schlechter beurteilt als CBR-Shell. einen unspezifizierten Algorithmus verwendet. CASPIAN wird daher viel schlechter beurteilt als Induce-It.

324

Bei der Leave-One-Out-Evaluation wird jeder einzelne Fall aus der Fallbasis nacheinander ausgeschlossen. Die jeweils verbleibenden Fälle werden als Grundlage für die Lösung des ausgeschlossenen Falls genutzt. Dieses Verfahren wird für alle Fälle wiederholt und die Qualität des Algorithmus wird aus dem Durchschnitt der Qualität der einzelnen Leave-One-Out-Schritte bestimmt. Dadurch kann eine Fokussierung auf die vielversprechenden Fälle erfolgen. Vgl. KONONENKO/KUKAR (2007), S. 83 u. BIRATTARI (2009), S. 63.

325

In Induce-It werden die lokalen Ähnlichkeitswerte als Feld-Ähnlichkeiten (field similarities) bezeichnet.

326

Der globale Ähnlichkeitswert entspricht dem in Induce-It verwendeten Begriff der Fall-Ähnlichkeit (case similarity).

327

In dem GUI von MyCBR werden nicht-normalisierte Gewichte angegeben. Die Normalisierung erfolgt erst bei Berechnung der globalen Ähnlichkeitswerte mit Hilfe der angegebenen Funktion.

118

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

a 14 )

MyCBR unterstützt mehrere Algorithmen, während CASPIAN nur einen unspezifizierten Algorithmus verwendet. CASPIAN wird daher deutlich schlechter beurteilt als MyCBR.

a 23 )

Induce-It unterstützt eine Vielzahl an Algorithmen, während CBR-Shell lediglich einige Anpassungen zulässt. CBR-Shell wird daher deutlich schlechter beurteilt als Induce-It.

a 24 )

MyCBR unterstützt mehrere Algorithmen, während CBR-Shell lediglich einige Anpassungen zulässt. CBR-Shell wird daher etwas schlechter beurteilt als MyCBR.

a 34 )

Induce-It unterstützt eine höhere Anzahl an Algorithmen als MyCBR. Induce-It wird daher etwas besser beurteilt als MyCBR.

Es folgt die Bewertung des zum Kriterium Funktionalität gehörenden Subkriteriums Ähnlichkeitsmaßstab. Der Ähnlichkeitsmaßstab ist die Grundlage für die Bestimmung der Ähnlichkeit zwischen zwei Attributswerten. Der Ähnlichkeitsmaßstab bei CASPIAN ist genauso wie der hinterlegte Algorithmus nicht spezifiziert. In CBR-Shell definiert eine Schlüssel-Datei (Key File) den Ähnlichkeitsmaßstab, der für jedes Feld eines jeden Falls zu Grunde gelegt wird. Als Ähnlichkeitsmaßstab können ein numerischer Vergleich oder ein Textvergleich (Vergleich von Text, Sätzen und Paragraphen) mit Hilfe eines Trigramm-Vergleichs328 genutzt werden. Induce-It unterstützt als Ähnlichkeitsmaßstab bei numerischen Attributswerten den Abstand und den Bereich329 und bei symbolischen Werten Textanalysen330 und Taxonomien 328

Beim Trigramm-Vergleich wird die Anzahl der Zeichenfolgen, die eine Länge von drei Buchstaben besitzen und in beiden miteinander verglichenen Attributswerten enthalten sind, als Ähnlichkeitsmaßstab genutzt.

329

Beim Bereich (englisch: Range) ist jedem Attributswert ein Wertebereich zugeordnet, der als Basis des Vergleichs genutzt wird. Sofern die Attributswerte zwar verschieden sind, aber demselben Wertebereich angehören, werden sie als gleich angesehen.

330

Zu den Textanalysen in Induce-It gehören Choice, Rank und Scale. Vgl. INDUCTIVE SOLUTIONS (2000), Section 2, S. 13 ff. Bei Choice wird geprüft, ob zwei zu vergleichende Attributswerte denselben Textabschnitt enthalten. Ein Beispiel für einen betreffenden Ähnlichkeitsmaßstab lautet „If text f1 appears in text f2 then Similarity (f1,f2):=1 else Similarity (f1,f2):=0:“. Angenommen, es gilt: f1=„Notebook“ und f2=„Desktops und Notebooks“. Dann besitzt die Ähnlichkeit zwischen f1 und f2 den Wert 1. Bei Rank repräsentieren die Zeichen im Text eine Rangfolge. Angenommen, es gilt: f1=„abc” und f2=„cb”. „a“ ist nicht in beiden Werten vertreten. „c“ ist an dritter Stelle und an erster Stelle. „b“ ist zweimal an zweiter Stelle. Dann besitzt die Ähnlichkeit zwischen f1 und f2 den Wert 3 ˜ 1 + 2 ˜ 2 = 7 . Bei Scale wird jeder Buchstabe aus einem Text einer Zahl zugeordnet. Angenommen, es gilt die Zuordnung: „a“=4 und „b“=3. Außerdem gelten „if m1m2 then Similarity (f1,f2):= min(m1,m2)/max(m1,m2)“ und „if m1=m2 then Similarity (f1,f2):=1“. Angenommen, es gilt: f1=„a” und f2=„b”. Dann besitzt die Ähnlichkeit zwischen f1 und f2 den Wert min(4,3)/max(4,3)=3/4.

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

119

(hier: Hierarchies). Außerdem sind benutzerdefinierte Ähnlichkeitsmaßstäbe möglich. MyCBR kann in Abhängigkeit vom Feldtyp verschiedene Ähnlichkeitsmaßstäbe nutzen. Es sind Abstände, Tabellen und Taxonomien möglich. Neue Ähnlichkeitsmaßstäbe können durch die Erweiterung bestimmter Java-Klassen hinzugefügt werden.

Beurteilungsobjekt

CASPIAN

CBR-Shell

Induce-It

MyCBR

CASPIAN

1

1/3

1/5

1/5

CBR-Shell

3

1

1/3

1/3

Induce-It

5

3

1

1

MyCBR

5

3

1

1

Tabelle 29: Bewertung der Tools hinsichtlich des Kriteriums Ähnlichkeitsmaßstab

Die Begründungen für die Ergebnisse der Paarvergleiche aus Tabelle 29 sind im Folgenden zu jedem erklärungsbedürftigen Paarvergleichsurteil aufgeführt: a 12 )

Bei CASPIAN ist der Ähnlichkeitsmaßstab nicht spezifiziert. Bei CBR-Shell können verschiedene Ähnlichkeitsmaßstäbe genutzt werden. CASPIAN wird daher etwas schlechter beurteilt als CBR-Shell.

a 13 )

Bei CASPIAN ist der Ähnlichkeitsmaßstab nicht spezifiziert. Bei Induce-It können komplexe Ähnlichkeitsmaßstäbe genutzt werden. CASPIAN wird daher deutlich schlechter beurteilt als Induce-It.

a 14 )

Bei CASPIAN ist der Ähnlichkeitsmaßstab nicht spezifiziert. Bei MyCBR können verschiedene Ähnlichkeitsmaßstäbe genutzt werden und auch neue definiert werden. Daher wird CASPIAN deutlich schlechter beurteilt als MyCBR.

a 23 )

Bei Induce-It können komplexere Ähnlichkeitsmaßstäbe genutzt werden als bei CBR-Shell. Deshalb wird CBR-Shell etwas schlechter beurteilt als Induce-It.

a 24 )

Bei CBR-Shell und MyCBR können verschiedene Ähnlichkeitsmaßstäbe genutzt werden. Bei MyCBR können zusätzlich auch neue definiert werden. CBR-Shell wird daher etwas schlechter beurteilt als MyCBR.

a 34 )

Bei Induce-It können komplexere Ähnlichkeitsmaßstäbe genutzt werden als bei MyCBR. Bei MyCBR können zusätzlich auch neue definiert werden. Beide Tools werden daher gleich beurteilt.

120

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

Es folgt die Bewertung des zum Kriterium Funktionalität gehörenden Subkriteriums Fallrepräsentation: Die Fallrepräsentation in CASPIAN erfolgt mit der proprietären Fallsprache Common Algebraic Specification Language (CASL). In CBR-Shell wird ein Fall durch eine mit Kommas getrennte Liste von Werten (comma-separated values - CSV) beschrieben. Induce-It nutzt als Excel-Makro das in Excel-Dateien gespeicherte Fallwissen. MyCBR kann Fallwissen verarbeiten, das als XML-Datei gespeichert wurde oder in Protégé enthalten ist.

Beurteilungsobjekt

CASPIAN

CBR-Shell

Induce-It

MyCBR

CASPIAN

1

1/3

1/5

1/3

CBR-Shell

3

1

1/3

1

Induce-It

5

3

1

3

MyCBR

3

1

1/3

1

Tabelle 30: Bewertung der Tools hinsichtlich des Kriteriums Fallrepräsentation

Die Begründungen für die Ergebnisse der Paarvergleiche aus Tabelle 30 sind im Folgenden zu jedem erklärungsbedürftigen Paarvergleichsurteil aufgeführt: a 12 )

CASPIAN nutzt eine proprietäre Fallsprache. Leichter zu verstehen ist die CSVListe von CBR-Shell. CASPIAN wird daher etwas schlechter beurteilt als CBRShell.

a 13 )

Für Induce-It ist eine zu Excel kompatible Datei erforderlich, die z.B. eine CSVListe sein kann. Eine zu Excel kompatible Datei ist sehr viel benutzerfreundlicher als die proprietäre Fallsprache von CASPIAN. CASPIAN wird daher deutlich schlechter beurteilt als Induce-It.

a 14 )

Die XML-Datei für MyCBR ist benutzerfreundlicher als die proprietäre Fallsprache von CASPIAN. CASPIAN wird daher etwas schlechter beurteilt als MyCBR.

a 23 )

Die CSV-Liste von CBR-Shell ist nicht so benutzerfreundlich wie die Excel-Datei für Induce-It. CBR-Shell wird daher etwas schlechter beurteilt als Induce-It.

a 24 )

CBR-Shell und MyCBR werden für dieses Kriterium gleich beurteilt, da XML-Dateien und CSV-Listen hier als sehr ähnlich in Bezug auf die Benutzerfreundlichkeit angesehen werden.

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen a 34 )

121

Die Excel-Datei für Induce-It ist etwas benutzerfreundlicher als die XML-Datei für MyCBR. Induce-It wird daher etwas besser beurteilt als MyCBR.

In diesem Abschnitt wird das Kriterium Zuverlässigkeit bewertet: In der Dokumentation von CASPIAN wird beschrieben, dass der Start des Programms unter Windows durch ein Ziehen der Datei mit Fallwissen auf die Programmdatei „caspian.exe“ innerhalb des Dateibrowsers erfolgt. Dies führt jedoch zu einem Anwendungsfehler (siehe Abbildung 26). Mit dem Kommandozeilen-Befehl „caspian.exe Datei” kann CASPIAN ohne Probleme gestartet werden.

Abbildung 26: Fehlerzustand in CASPIAN

CBR-Shell soll laut Beschreibung auf der Webseite mit dem Kommandozeilen-Befehl „Javaw CBRApplet.jar“ gestartet werden. Dies führt zu einer Fehlermeldung durch Java (siehe Abbildung 27). Das Tool kann durch einen Doppelklick auf „CBRApplet.jar“ ohne Probleme gestartet werden.

Abbildung 27: Fehlerzustand in CBR-Shell

Bei Induce-It und MyCBR gab es keine Fehlerzustände beim Start oder während des Betriebs.

122

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen Beurteilungsobjekt

CASPIAN

CBR-Shell

Induce-It

MyCBR

CASPIAN

1

1

1/7

1/7

CBR-Shell

1

1

1/7

1/7

Induce-It

7

7

1

1

MyCBR

7

7

1

1

Tabelle 31: Bewertung der Tools hinsichtlich des Kriteriums Zuverlässigkeit

Die Begründungen für die Ergebnisse der Paarvergleiche aus Tabelle 31 sind im Folgenden zu jedem erklärungsbedürftigen Paarvergleichsurteil aufgeführt: a 12 )

Beide Tools verursachen Fehlerzustände beim empfohlenen Programmstart und

a 13 )

CASPIAN verursacht beim empfohlenen Programmstart einen Fehlerzustand. In-

werden daher gleich beurteilt. duce-It verursachte keinen Fehlerzustand. CASPIAN wird daher viel schlechter beurteilt als Induce-It. a 14 )

CASPIAN verursacht beim empfohlenen Programmstart einen Fehlerzustand. MyCBR verursachte keinen Fehlerzustand. CASPIAN wird daher viel schlechter beurteilt als MyCBR.

a 23 )

CBR-Shell verursacht beim empfohlenen Programmstart einen Fehlerzustand. Induce-It verursachte keinen Fehlerzustand. CBR-Shell wird daher viel schlechter beurteilt als Induce-It.

a 24 )

CBR-Shell verursacht beim empfohlenen Programmstart einen Fehlerzustand. MyCBR verursachte keinen Fehlerzustand. CBR-Shell wird daher viel schlechter beurteilt als MyCBR.

a 34 )

Beide Tools konnten ohne Fehler gestartet und betrieben werden und werden daher gleich beurteilt.

Das Kriterium Benutzbarkeit setzt sich aus mehreren Subkriterien zusammen. Zunächst wird das Subkriterium GUI bewertet: CASPIAN ist ein MSDOS-Programm, das eine rein textbasierte Benutzeroberfläche besitzt. CBR-Shell besitzt eine rudimentäre grafische Oberfläche mit Menü-Elementen. Induce-It nutzt die Benutzeroberfläche von Excel, die durch neue Menüstrukturen erweitert wird. MyCBR kann selbstständig mit einem eigenen GUI mit Menü-Elementen oder als Protégé-Plug-In genutzt werden. In Protégé wird das

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

123

GUI um zusätzliche Fenster erweitert. Die folgenden Abbildungen 28-32 vermitteln einen Eindruck von den verschiedenen GUIs.

Abbildung 28: Graphical User Interface von CASPIAN

Abbildung 29: Graphical User Interface von CBR-Shell

124

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

Abbildung 30: Graphical User Interface von Induce-It

Abbildung 31: Graphical User Interface von MyCBR als Protégé-Plug-In

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

125

Abbildung 32: Graphical User Interface vom selbstständigen MyCBR

Beurteilungsobjekt

CASPIAN

CBR-Shell

Induce-It

MyCBR

CASPIAN

1

1/5

1/3

1/7

CBR-Shell

5

1

3

1/3

Induce-It

3

1/3

1

1/5

MyCBR

7

3

5

1

Tabelle 32: Bewertung der Tools hinsichtlich des Kriteriums GUI

Die Begründungen für die Ergebnisse der Paarvergleiche aus Tabelle 32 sind im Folgenden zu jedem erklärungsbedürftigen Paarvergleichsurteil aufgeführt: a 12 )

Im Gegensatz zu der rein textbasierten Benutzeroberfläche von CASPIAN nutzt CBR-Shell ein eigenes GUI. CASPIAN wird daher deutlich schlechter beurteilt als CBR-Shell.

a 13 )

Die Benutzeroberfläche von CASPIAN ist rein textbasiert. Induce-It nutzt das GUI von Excel. CASPIAN wird daher etwas schlechter beurteilt als Induce-It.

a 14 )

Die Benutzeroberfläche von CASPIAN ist rein textbasiert. MyCBR besitzt ein eigenes GUI und kann auch das GUI von Protégé nutzen. CASPIAN wird daher viel schlechter beurteilt als MyCBR.

a 23 )

CBR-Shell besitzt ein eigenes GUI. Induce-It nutzt das GUI von Excel. Da das GUI von CBR-Shell passende Fenster mit passenden Menü-Elementen für die Konfigu-

126

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen ration des Case-Based Reasonings besitzt und Induce-It lediglich die MenüBezeichnungen von Excel verändert, wird CBR-Shell etwas besser beurteilt als Induce-It.

a 24 )

Beide Tools nutzen ein eigenes GUI mit Menü-Elementen. MyCBR kann alternativ auch das GUI von Protégé nutzen. CBR-Shell wird daher etwas schlechter beurteilt als MyCBR.

a 34 )

Induce-It nutzt das GUI von Excel. MyCBR nutzt das GUI von Protégé oder alternativ ein eigenes GUI. Induce-It wird daher deutlich schlechter beurteilt als MyCBR.

Das zweite Subkriterium des Kriteriums Benutzbarkeit ist die Dokumentation: Die Dokumentation von CASPIAN ist im Internet abrufbar. 331 Es handelt sich um ein PDFDokument, das eine kurze Einleitung enthält und einen Umfang von lediglich vier Seiten besitzt. CBR-Shell bietet ebenfalls eine kurze Einleitung zum Tool in Form einer Webseite, die in ausgedruckter Form fünf Seiten umfasst. 332 Die Webseite enthält neben reinem Text auch Screenshots, die die Beschreibungen veranschaulichen. Der Hersteller von Induce-It hat neben dem Tool auch eine Dokumentation zur Verfügung gestellt, die aus mehreren PDF-Dateien besteht. Diese beinhalten Installations- und Bedienungsanleitungen mit einem Umfang von 117 Seiten. Die Anleitungen enthalten Screenshots zur Veranschaulichung. MyCBR bietet im Rahmen der Dokumentation, die als Webseite 333 abrufbar ist, ein Tutorial, welches mit Screenshots veranschaulicht wurde. Das Tutorial besitzt einen Umfang von 10 ausgedruckten Seiten. Über das Tutorial sind weitere Hintergrundinformationen über Hyperlinks zu anderen Webseiten erreichbar.

331

Vgl. ABERYSTWYTH UNIVERSITY (2001b).

332

Vgl. ARTIFICIAL INTELLIGENCE APPLICATIONS INSTITUTE (2002b).

333

Vgl. DFKI (2009).

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen Beurteilungsobjekt

CASPIAN

CBR-Shell

Induce-It

MyCBR

CASPIAN

1

1/3

1/5

1/5

CBR-Shell

3

1

1/3

1/3

Induce-It

5

3

1

1

MyCBR

5

3

1

1

127

Tabelle 33: Bewertung der Tools hinsichtlich des Kriteriums Dokumentation

Die Begründungen für die Ergebnisse der Paarvergleiche aus Tabelle 33 sind im Folgenden zu jedem erklärungsbedürftigen Paarvergleichsurteil aufgeführt: a 12 )

Beide Tools bieten lediglich eine kurze Einleitung in die Bedienung der Tools. Bei CBR-Shell sind zusätzlich Screenshots vorhanden und daher wird CASPIAN etwas schlechter beurteilt als CBR-Shell.

a 13 )

Die Dokumentation von Induce-It ist umfangreicher und enthält im Gegensatz zur Dokumentation von CASPIAN auch Screenshots. CASPIAN wird daher deutlich schlechter beurteilt als Induce-It.

a 14 )

Die Dokumentation von MyCBR ist umfangreicher und enthält im Gegensatz zur Dokumentation von CASPIAN auch Screenshots. CASPIAN wird daher deutlich schlechter beurteilt als MyCBR.

a 23 )

Die Dokumentation von Induce-It ist umfangreicher als die von CBR-Shell und daher wird CBR-Shell etwas schlechter beurteilt als Induce-It.

a 24 )

Die Dokumentation von MyCBR ist umfangreicher als die von CBR-Shell und daher wird CBR-Shell etwas schlechter beurteilt als MyCBR.

a 34 )

Zu beiden Tools wurden Dokumentationen veröffentlicht. Induce-It besitzt zwar eine umfangreichere Dokumentation, dafür bietet die Dokumentation von MyCBR eine übersichtliche Webseite mit vielen Screenshots und Hintergrundinformationen. Daher werden die beiden Tools gleich beurteilt.

Die CBR-Tools werden hinsichtlich des Kriteriums Übertragbarkeit mit zwei Subkriterien bewertet. Die Betrachtung des Subkriteriums „Import von Fallwissen“ wird zuerst durchgeführt: Für CASPIAN muss das Fallwissen manuell in der proprietären Sprache CASL gespeichert werden. Ein Import aus einem anderen Format ist nicht möglich. CBR-Shell erfordert ebenfalls eine manuelle Erstellung einer Datei mit Fallwissen. Diese Datei muss per Komma getrennte Werte (CSV) enthalten. Außerdem muss ein Verweis auf die Schlüs-

128

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

sel-Datei enthalten sein. Ein Import von Fallwissen ist auch bei CBR-Shell nicht möglich. Induce-It verarbeitet Fallwissen, das in Excel gespeichert ist. Daher können grundsätzlich alle Dateien, die von Excel importiert werden können, z.B. Textdateien und Datenbankdateien, mit Induce-It verarbeitet werden. MyCBR unterstützt den Import von CSV-Dateien und die Nutzung von Protégé-Daten für den Aufbau einer Fallbasis.

Beurteilungsobjekt

CASPIAN

CBR-Shell

Induce-It

MyCBR

CASPIAN

1

1/3

1/7

1/5

CBR-Shell

3

1

1/5

1/3

Induce-It

7

5

1

3

MyCBR

5

3

1/3

1

Tabelle 34: Bewertung der Tools hinsichtlich des Kriteriums Import von Fallwissen

Die Begründungen für die Ergebnisse der Paarvergleiche aus Tabelle 34 sind im Folgenden zu jedem erklärungsbedürftigen Paarvergleichsurteil aufgeführt: a 12 )

Beide Tools ermöglichen keinen Import von Fallwissen. Bei einer manuellen Erstellung ist das Format von CBR-Shell einfacher zu handhaben. CASPIAN wird daher etwas schlechter beurteilt als CBR-Shell.

a 13 )

CASPIAN ermöglicht keinen Import. Induce-It kann alle Daten verarbeiten, die durch Excel importiert werden können. CASPIAN wird daher viel schlechter beurteilt als Induce-It.

a 14 )

CASPIAN ermöglicht keinen Import. MyCBR ermöglicht den Import von CSVund Protégé-Daten. CASPIAN wird daher deutlich schlechter beurteilt als MyCBR.

a 23 )

CBR-Shell ermöglicht keinen Import, sondern erfordert eine manuelle Erstellung einer Fall-Datei im CSV-Format. Induce-It kann alle Daten verarbeiten, die durch Excel importiert werden können. CBR-Shell wird daher deutlich schlechter beurteilt als Induce-It.

a 24 )

CBR-Shell ermöglicht keinen Import. MyCBR ermöglicht den Import von CSVListen und Protégé-Dateien. Da für CBR-Shell eine einfach handhabbare CSVDatei erstellt werden kann, wird CBR-Shell lediglich etwas schlechter beurteilt als MyCBR.

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen a 34 )

129

Induce-It kann alle Daten verarbeiten, die durch Excel importiert werden können. MyCBR ermöglicht nur den Import von CSV- und Protégé-Daten. Induce-It wird daher etwas besser beurteilt als MyCBR.

Das zweite Subkriterium zum Kriterium Übertragbarkeit lautet „Import von Ontologiewissen“: Die Tools CASPIAN, CBR-Shell und Induce-It unterstützten den Import von Ontologiewissen nicht. Lediglich MyCBR kann Ontologiewissen aus Protégé heraus für die Durchführung von Case-Based Reasoning nutzen.

Beurteilungsobjekt

CASPIAN

CBR-Shell

Induce-It

MyCBR

CASPIAN

1

1

1

1/7

CBR-Shell

1

1

1

1/7

Induce-It

1

1

1

1/7

MyCBR

7

7

7

1

Tabelle 35: Bewertung der Tools hinsichtlich des Kriteriums Import von Ontologiewissen

Die Begründungen für die Ergebnisse der Paarvergleiche aus Tabelle 35 sind im Folgenden zu jedem erklärungsbedürftigen Paarvergleichsurteil aufgeführt: a 12 )

CASPIAN und CBR-Shell unterstützten den Import von Ontologiewissen nicht und werden daher gleich beurteilt.

a 13 )

CASPIAN und Induce-It unterstützten den Import von Ontologiewissen nicht und werden daher gleich beurteilt.

a 14 )

Nur MyCBR unterstützt den Import von Ontologiewissen. CASPIAN wird daher viel schlechter beurteilt als MyCBR.

a 23 )

CBR-Shell und Induce-It unterstützten den Import von Ontologiewissen nicht und werden daher gleich beurteilt.

a 24 )

Nur MyCBR unterstützt den Import von Ontologiewissen. CBR-Shell wird daher viel schlechter beurteilt als MyCBR.

a 34 )

Nur MyCBR unterstützt den Import von Ontologiewissen. Induce-It wird daher viel schlechter beurteilt als MyCBR.

130

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

Die Überprüfung der Konsistenz in Bezug auf die Paarvergleichsurteile wird über die Bewertung der Alternativen durchgeführt. Bei der Konsistenzprüfung mit dem Tool Expert Choice wurden folgende Inkonsistenzwerte festgestellt:

Bezug der Paarvergleichsurteile

Übergeordnetes Kriterium

Inkonsistenzwert

Algorithmen

Funktionalität

0,04

Ähnlichkeitsmaßstab

Funktionalität

0,02

Fallrepräsentation

Funktionalität

0,02

Zuverlässigkeit

nicht vorhanden

0,00

GUI

Benutzbarkeit

0,04

Dokumentation

Benutzbarkeit

0,02

Import von Fallwissen

Übertragbarkeit

0,04

Import von Ontologiewissen

Übertragbarkeit

0,00

Tabelle 36: Inkonsistenzwerte der Evaluationsmatrizen

Da der festgelegte Schwellenwert 334 0,10 bei keiner Evaluationsmatrix erreicht wurde, ist eine Überarbeitung der Paarvergleichsurteile nicht notwendig. Wie bereits in Kapitel 3.2.2.2.2 beschrieben, werden die Paarvergleichsurteile aus den Evaluationsmatrizen zur Bewertung der Alternativen zu Prioritäten aggregiert. Da auch bei der Auswahl eines CBR-Tools eine Antwort darauf gesucht wird, in welchem Ausmaß eine Alternative die anderen Alternativen dominiert, ist hier ebenfalls der Distributive Mode und nicht der Ideal Mode zu wählen. Die Aggregation der Paarvergleichsurteile aus den Evaluationsmatrizen erfolgt mit Hilfe von Expert Choice. Die Ergebnisse werden im nächsten Kapitel dargestellt. 3.2.2.3.3 Selektion der geeignetsten Alternative

Die Gesamtpriorität für jede Alternative wird berechnet, indem innerhalb von Expert Choice im Rahmen mehrfacher Iterationen die Formel 3.16 verwendet wird. In der unten stehenden Tabelle 37 sind alle gewichteten Prioritäten w ij ˜ pij dargestellt. 335 334

Vgl. Kapitel 3.2.1.2.3, S. 66.

335

Diese Tabelle ist analog zur Tabelle 25 zu lesen. Zu den Abweichungen im rechten Teil des Hauptfensters von Expert Choice vgl. Fußnote 312, S. 109.

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen Alternative

Ebene 1

Ebene 2

kumuliert Benutzbarkeit (L: ,262)

CASPIAN

Funktionalität (L: ,565)

Übertragbarkeit (L: ,118) Zuverlässigkeit (L: ,055) kumuliert Benutzbarkeit (L: ,262)

CBR-Shell

Funktionalität (L: ,565)

Übertragbarkeit (L: ,118) Zuverlässigkeit (L: ,055) kumuliert Benutzbarkeit (L: ,262)

Induce-It

Funktionalität (L: ,565)

Übertragbarkeit (L: ,118) Zuverlässigkeit (L: ,055) kumuliert Benutzbarkeit (L: ,262)

MyCBR

Funktionalität (L: ,565)

Übertragbarkeit (L: ,118) Zuverlässigkeit (L: ,055)

kumuliert GUI (L: ,875) Dokumentation (L: ,125) kumuliert Algorithmen (L: ,143) Ähnlichkeitsmaßstab (L: ,429) Fallpräsentation (L: ,429) kumuliert Import Fallwissen (L: ,250) Import Ontologiewissen (L: ,750) [keine Subkriterien vorhanden] kumuliert GUI (L: ,875) Dokumentation (L: ,125) kumuliert Algorithmen (L: ,143) Ähnlichkeitsmaßstab (L: ,429) Fallpräsentation (L: ,429) kumuliert Import Fallwissen (L: ,250) Import Ontologiewissen (L: ,750) [keine Subkriterien vorhanden] kumuliert GUI (L: ,875) Dokumentation (L: ,125) kumuliert Algorithmen (L: ,143) Ähnlichkeitsmaßstab (L: ,429) Fallpräsentation (L: ,429) kumuliert Import Fallwissen (L: ,250) Import Ontologiewissen (L: ,750) [keine Subkriterien vorhanden] kumuliert GUI (L: ,875) Dokumentation (L: ,125) kumuliert Algorithmen (L: ,143) Ähnlichkeitsmaßstab (L: ,429) Fallpräsentation (L: ,429) kumuliert Import Fallwissen (L: ,250) Import Ontologiewissen (L: ,750) [keine Subkriterien vorhanden]

Tabelle 37: Einzelprioritäten in Expert Choice

131

Priorität 6,8% 1,5% 1,3% 0,2% 3,9% 0,4% 1,6% 1,9% 1,1% 0,2% 0,9% 0,3% 17,4% 6,5% 6,0% 0,5% 9,4% 0,9% 3,7% 4,8% 1,2% 0,3% 0,9% 0,3% 35,7% 4,0% 2,7% 1,3% 26,7% 4,6% 9,4% 12,6% 2,6% 1,7% 0,9% 2,4% 40,1% 14,3% 13,0% 1,3% 16,3% 2,1% 9,4% 4,8% 7,0% 0,8% 6,2% 2,4%

132

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

CASPIAN; CASPIAN; 6,8% 6,8% CBR-Shell; CBR-Shell; 17,4% 17,4% Induce-It; Induce-It; 35,7% 35,7% MyCBR; 40,1%

0%

10%

20%

30%

40%

50%

Abbildung 33: Gesamtprioritäten in Expert Choice

Wie bereits in Kapitel 3.2.2.2.3 erläutert, können die Alternativen beim AHP-Verfahren einer Rangvertauschung („Rank Reversal“) unterliegen. Analog zu Kapitel 3.2.2.2.3 wird die Möglichkeit einer Rangvertauschung durch das schrittweise Entfernen jeder einzelnen Alternative untersucht, was in Expert Choice mit dem Deaktivieren einer Alternative gleichzusetzen ist.

Alternativen

Rang

Rang

Rang

Rang

Rang

CASPIAN

4

inaktiv

3

3

3

CBR-Shell

3

3

inaktiv

2

2

Induce-It

2

2

2

inaktiv

1

MyCBR

1

1

1

1

inaktiv

Tabelle 38: Änderung der Rangordnung beim Entfernen von Alternativen

Beim Entfernen der einzelnen Alternativen hat sich die Rangfolge der verbleibenden Alternativen nicht geändert. Die Ergebnisse sind stabil. Das CBR-Tool, das für die Verwendung innerhalb des ontologiegestützten CBR-Systems ausgewählt wird, ist MyCBR.

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

133

3.2.2.4 Definition der Schnittstellen zwischen dem Ontologie-Tool und dem CBR-Tool

Um das ontologiegestützte Case-Based Reasoning mit Hilfe der ausgewählten Tools durchzuführen, ist die Nutzung einer Schnittstelle zwischen diesen Tools notwendig. Die Schnittstelle soll dazu dienen, das Ontologie-Wissen innerhalb des ontologiegestützten CBR-Systems aus dem Ontologie-Tool zu exportieren und in das CBR-Tool zu importieren. Im vorliegenden Fall bietet das Ontologie-Tool Protégé die Nutzung des CBR-Tools MyCBR als Plug-In an. Dies bedeutet, dass MyCBR in Protégé integriert wird und dessen Funktionalität erweitert. Das Ontologie-Wissen in Protégé kann dadurch für das CBR-Tool verfügbar gemacht werden und damit bei der Durchführung des Case-Based Reasonings und bei der Definition von Ähnlichkeitsmaßstäben und des Algorithmus genutzt werden. 3.2.2.5 Rückkopplungen durch Schnittstellen-Erkenntnisse

Rückkopplungen durch Schnittstellen-Erkenntnisse sind notwendig, wenn keine Schnittstellen zwischen dem gewählten Ontologie- und dem CBR-Tool geschaffen werden können oder wenn die Schnittstellen eine unzureichende Kombination der Tools ermöglichen. Dies ist hier nicht der Fall, da das ausgewählte Ontologie-Tool Protégé die Nutzung des ausgewählten CBR-Tools MyCBR als Plug-In anbietet. Es ergeben sich folglich keine notwendigen Rückkopplungen. 3.2.2.6 Auswahlentscheidung hinsichtlich des Ontologie-Tools und des CBR-Tools

Die Auswahlentscheidung berücksichtigt mögliche Rückkopplungen auf Grund der Schnittstellen-Erkenntnisse. Da keine notwendigen Rückkopplungen vorhanden sind, wird die anfängliche Auswahlentscheidung für das Ontologie-Tool Protégé und das CBR-Tool MyCBR beibehalten. Für eine fehlerfreie Kombination von MyCBR und Protégé wird vom DFKI, dem Entwickler von MyCBR, empfohlen, dass das interne Protégé-Format als Repräsentationssprache für die Ontologie verwendet wird.336 Daher wird diesem Format der Vorrang gegeben. Eine weitere Besonderheit bei der Kombination von MyCBR mit Pro-

336

Als nach der Erstellung einer OWL-Ontologie in Protégé über das Konfigurationsmenü die MyCBRTabs aktiviert wurden, blieben diese Tabs leer. Außerdem konnte Protégé nicht mehr geschlossen werden, da eine Fehlermeldung dies verhinderte. Eine diesbezügliche Supportanfrage per E-Mail wurde am 29.06.2009 durch das DFKI wie folgt beantwortet: „Dear Mr. Beissel, MyCBR is designed to use the standard protege files .pprj, .pins, .pont. The idea is to use MyCBR on tree-like structured domains to compute similarities of objects in a class hierarchy. With owl projects you can model complex dependencies which makes the computation of similarities very difficult. MyCBR crashes most likely because of cyclic dependencies.”

134

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

tégé ist, dass MyCBR eine Protégé-Version erfordert, die mit 3 beginnt. Protégé ist bereits in der Version 4 erschienen, wird jedoch in der Version 3 noch weiterentwickelt. Die aktuelle 3er-Version von Protégé, welche auch in dieser Untersuchung genutzt wird, ist die Version 3.4.4. Die aktuelle, in der Untersuchung genutzte MyCBR-Version lautet 2.6.6. 3.2.3

Implementierung des ontologiegestützten CBR-Systems

3.2.3.1 Ziele der Implementierung

Die Implementierung beinhaltet die Umsetzung des semantischen Datenmodells zum ontologiegestützten Case-Based Reasoning gemäß Abbildung 15 in eine lauffähige Anwendung. 337 Für die vorliegende Untersuchung bedeutet dies, dass eine Fallsammlung und eine Ontologie erstellt werden. Außerdem wird ein Algorithmus erstellt, der für die Aggregation der lokalen Ähnlichkeitswerte zu globalen Ähnlichkeitswerten genutzt wird. Die Werte für die lokalen Ähnlichkeiten zwischen Attributswerten werden anhand von Ähnlichkeitsmaßstäben berechnet. Anhand der Werte für die globalen Ähnlichkeiten zwischen Fällen können die Identifikation hinreichend ähnlicher Fälle und die Selektion eines ähnlichsten Falls durchgeführt werden. 3.2.3.2 Erstellung der Fallbasis

Die Fallbasis ist die Grundlage für die Nutzung von Case-Based Reasoning. Die Fallbasis besteht aus einer zentralen Sammlung von unternehmensspezifischem Projektwissen in Form von Fällen. 338 Es wurden exemplarisch zehn Fälle zur Repräsentation von Projektwissen nicht-zufallsgesteuert ausgewählt (siehe Anhang). Eine vollständige Repräsentativität durch die Fälle ist gegeben, wenn durch die Struktur der Fallbasis eine Aussage über die Grundgesamtheit getroffen werden kann. Die Grundgesamtheit kann z.B. die Gesamtheit aller möglichen Fälle in einer spezifischen Domäne sein. In dieser Untersuchung sollen jedoch keine Aussagen über die Grundgesamtheit getroffen werden, sondern es soll eine Technik untersucht werden, welche unabhängig von der Grundgesamtheit qualitative Aussagen zu spezifischen Fällen treffen kann. Daher wird auf eine vollständige Repräsentativi-

337

Vgl. ZÖLLER-GREER (2002), S. 120.

338

Ein Fall enthält die problembezogene Darstellung von Erfahrungen, die in einer bestimmten Situation erworben wurden. Vgl. KURBEL/DORNHOFF (1993), S. 1052. Ein Fall kann als schematische Beschreibung eines Problems, dessen Lösung und Angaben zur Güte der Lösung verstanden werden. Diese Beschreibung besteht aus einer Anzahl von Tupeln zur Charakterisierung des Problems innerhalb einer Domäne. Vgl. HAHN/RAMSCAR (2001), S. 133. In dieser Untersuchung stammen die Probleme, die mit Hilfe von Fällen beschrieben werden, aus der Domäne des IT-Projektmanagements.

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

135

tät bewusst verzichtet. Die Erfassung von Fällen wird durch eine Fallakquisition durchgeführt. Zunächst sind die relevanten Fallattribute festzulegen. Ein Grundgerüst relevanter Fallattribute für die Fallakquisition ermöglicht eine strukturierte Erfassung der Fallkomponenten. Auch unvollständige Fälle können berücksichtigt werden. Der Umgang mit unvollständigen Fällen wird in Kapitel 3.2.3.5 erläutert. Die Nützlichkeit der Fallbasis hängt grundsätzlich von ihrer Quantität, Qualität und dem Grad der Formalisierung ab.339 Die Quantität bezieht sich auf die Anzahl der Fälle in der Fallbasis. In der vorliegenden Untersuchung wird mit zehn Fällen gearbeitet, um die Machbarkeit zu zeigen. Da auf eine vollständige Repräsentativität verzichtet wird, wird bewusst akzeptiert, dass die Repräsentativität mit einer höheren Anzahl an Fällen höher wäre. Die Qualität bezieht sich auf die Korrektheit und Vollständigkeit der Fälle in der Fallbasis. Die Korrektheit wurde im Rahmen der manuellen Extraktion von Schlüsselwörtern aus der Fallbasis sichergestellt. Die Vollständigkeit wurde auf gleichem Weg sichergestellt, jedoch bewusst nicht auf alle Fälle angewendet. Die Nützlichkeit für die Praxis wird dadurch zwar negativ beeinträchtigt, aber es soll aufgezeigt werden, dass auch der Umgang mit unvollständigen Fällen machbar ist. Der Grad der Formalisierung bezieht sich darauf, dass Klassen, Instanzen, Relationen, Attribute und Attributswerte identifiziert und in formalsprachlicher Weise zur Repräsentation der Fälle genutzt werden. Dies wird in dieser Untersuchung umgesetzt. Die Inhalte der zehn Fälle werden im Folgenden kurz dargestellt: Der erste Fall handelt von einem Projekt zur Härtung von Unix-Systemen. Unter Härtung ist eine Maßnahme zur Absicherung eines Systems gegen Angriffe von Dritten zu verstehen. Das BUNDESAMT FÜR SICHERHEIT IN DER INFORMATIONSTECHNIK

(BSI) 340 definiert Härtung als Ent-

fernung aller Softwarebestandteile und Funktionen, die zur Erfüllung der vorgesehenen Aufgabe durch das Programm nicht notwendig sind. Bei den Unix-Systemen handelt es

339

Vgl. PUPPE/STOYAN/STUDER (2004), S. 621.

340

Vgl. BSI (2009), S.25.

136

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

sich um Server des Modells IBM iSeries 341 , auf denen ein Unix-basiertes 342 Betriebssystem betrieben wird. Der zweite Fall beinhaltet Informationen über den Serverwechsel eines Planungstools. Bei diesem Planungstool handelt es sich um Global One 343 von SUNGARD. Das Tool dient dem Management von Wertpapieren und der Unterstützung von Handelsaktionen. Es wurde auf einem Server zur Nutzung bereitgestellt, welcher auf Grund erhöhter Leistungsanforderungen ausgewechselt werden sollte. Der dritte Fall beinhaltet Informationen zur Integration einer Firewall344 in ein bestehendes Netzwerk. Die Firewall ist vom Hersteller CHECK POINT 345 und dient der Kontrolle des ein- und ausgehenden Datenverkehrs und des Datenverkehrs zwischen Subnetzen. Die Firewall wurde auf einem Server mit einer für den Betrieb der Firewall konfigurierten Linux-Installation betrieben. Der vierte Fall handelt von der Migration der Börsensysteme 346 eines Unternehmens auf neue Server mit dem Betriebssystem Sun Solaris 347 10. Das Unternehmen nutzte die Börsensysteme speziell in Bezug auf eigens herausgegebene und verwaltete Aktienfonds.

341

IBM iSeries ist eine Computer-Baureihe des 1896 gegründeten US-amerikanischen Unternehmens INTERNATIONAL BUSINESS MACHINES CORPORATION (IBM).

342

Die Entwicklung von Unix begann Ende der sechziger Jahre unter der Leitung von KEN THOMPSON und DENNIS RITCHIE ET AL. Unix ist das Warenzeichen des nordamerikanischen Telekommunikationskonzerns AMERICAN TELEPHONE AND TELEGRAPH COMPANY (AT&T). Basierend auf dem UnixSystempaket von AT&T sind zahlreiche Varianten und Derivate entstanden. Hierzu zählen z.B. AIX, SunOS und BSD. Vgl. KANNEMANN (1992), S.1 f.

343

Global One besitzt einen modularen Applikationsaufbau und bietet eine Softwareplattform für internationale Wertpapierleihe, Transaktionsprozesse, Kommunikation mit Wertpapierhändlern, Schnittstellen zu anderen Systemen und die Generierung von Analysen und Reports. Vgl. SUNGARD (2008).

344

Eine Firewall hat die Aufgabe, durch Kontrollen und Filterungen von Datenpaketen die Weiterleitung solcher Pakete zu verhindern, die eine Bedrohung für die Daten und Komponenten eines Netzsegments sind. Vgl. ECKERT (2007), S. 646.

345

CHECK POINT ist ein Softwareunternehmen, das 1993 in Isreal gegründet wurde und sich auf Firewallund VPN-Produkte spezialisiert hat.

346

Unter Börsensystemen werden Systeme verstanden, die der Abwicklung von Börsengeschäften auf der Basis von Geschäftsmodellen und unter Beachtung rechtlicher Anforderungen dienen. Grundlegende Funktionen sind Auftragsannahme, Auftragsweiterleitung, Preisbildung, Auftragsausführung, Handelsreporting und Bereitstellen von Marktinformationen. Vgl. SCHMIDT (2008).

347

Sun Solaris ist ein Unix-Betriebssystem vom Unternehmen SUN MICROSYSTEMS, einem 1982 gegründeten US-amerikanischen Hardware- und Software-Hersteller.

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

137

Der fünfte Fall handelt von der Einführung neuer virtueller Clients 348 für die Nutzung als Internet-PCs. Die Internet-PCs waren eine Ergänzung zu den Standard-PCs, die ausschließlich für geschäftliche Tätigkeiten genutzt werden durften. Die Internet-PCs sollten allen Akteuren für private Tätigkeiten im Internet zur Verfügung stehen. Diese Tätigkeiten sollten nicht durch das Unternehmen überwacht oder eingeschränkt werden. Die virtuellen Clients waren VMWARE-Systeme 349 , die über das Unternehmensnetzwerk an jedem Arbeitsplatz abrufbar waren. Nach der einmaligen Nutzung wurde das System in den Ursprungszustand zurückgesetzt. Der sechste Fall handelt vom Aufbau von Hardware und Software für Disaster Recovery . Diese Hardware und Software sollte dazu dienen, im Notfall eine Wiederherstel350

lung des Betriebs des Unternehmens zu ermöglichen. In dieser Umgebung sollten die dazu notwendigen Daten wiederhergestellt werden können und eine Infrastruktur für die Fortsetzung des Betriebs bereitgestellt werden können. Der siebte Fall handelt von der Stabilisierung der Vertriebsdatenbank eines Unternehmens durch eine Konfigurationsänderung. Bei dieser Vertriebsdatenbank handelte es sich um eine Eigenentwicklung durch das betreibende Unternehmen. Sie beinhaltete

348

349

Unter einem virtuellen Client wird ein System verstanden, das einer Virtualisierung unterliegt. Virtualisierung entkoppelt die physische Hardware vom Betriebssystem und ermöglicht die Ausführung mehrerer virtueller Maschinen auf derselben Hardware. Durch eine Abstraktionsschicht, die das System von der eigentlichen Hardware isoliert, werden die Hardware-Ressourcen aufgeteilt. Vgl. RUNGE/STURM/WIßKIRCHEN/EBEL/GROH/HÖLLER/MEWES (2008), S. 50. Ein virtuelles System verhält sich wie ein vollwertiger Computer mit eigenen Komponenten. Vgl. AHNERT (2009), S. 24. VMWARE-Systeme sind Systeme, die auf einer Virtualisierungs-Software des Unternehmens VMWAbasieren. VMWARE ist ein US-amerikanisches Unternehmen, das 1998 gegründet wurde und auf Softwareentwicklung im Bereich Virtualisierung spezialisiert ist.

RE

350

Disaster Recovery ist ein Teilbereich des Business Continuity Managements, bei dem es sich um ein Konzept handelt, um einen Plan für die Aufrechterhaltung von Geschäftsprozessen im Fall von Katastrophen oder Störungen zu erstellen. Disaster Recovery behandelt die direkte Auswirkung eines solchen Ereignisses, wie z.B. eines Serverausfalls. Das Ziel des Disaster Recoverys ist der Umgang mit den direkten Nachwirkungen. Vgl. SNEDAKER (2007), S. 3 f. Disaster Recovery läßt sich als Fähigkeit definieren, bei größeren Unterbrechungen mit den Leistungen eines Unternehmens fortfahren zu können. Typischer Weise sind für die Fortfahrung der Leistungen manuelle Aktivitäten notwendig. Vgl. SCHMIDT (2006), S. 26.

138

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

Stammdaten 351 von Kunden. Diese Stammdaten wurden im Rahmen von Vertriebstätigkeiten genutzt. Die Stabilität der Vertriebsdatenbank ist z.B. auf Grund von Deadlocks 352 negativ beeinträchtigt. Die Stabilität wurde erhöht, indem verschiedene Konfigurationsänderungen an der Datenbank vorgenommen wurden, z.B. eine geeignete Sequentialisierung von Datenbankprozessen. Der achte Fall handelt von der Einführung eines Internet-basierten Online-Bankings

353

für Zahlungsverkehrsgeschäfte. Dieses Projekt diente dem Aufbau einer Applika-

tion und der Bereitstellung der benötigten Infrastruktur, um Kontoinformationen einzusehen, elektronisch gestützte Zahlungsverkehrsgeschäfte durchzuführen, am bargeldlosen Zahlungs- und Abrechnungsverkehr teilzunehmen und Geld- sowie und Kreditkarten zu verwalten. Der neunte Fall handelt von der Einführung eines Projektmanagement-Tools des Unternehmens AUGEO SOFTWARE mit der Bezeichnung Augeo5. 354 Das Tool sollte dazu

351

Zu Stammdaten können Kunden-, Material- und Vertriebsdaten gehören. Stammdaten bleiben grundsätzlich unverändert und werden genutzt, um Bewegungsdaten besser zu analysieren, indem die Stammdaten zusätzliche Attribute zu den relevanten Informationsobjekten anbieten. Bei der Erstellung von Abfragen werden Stammdaten genutzt, um die beschreibenden Eigenschaften von Informationsobjekten anzuzeigen oder diese zu strukturieren. Demgegenüber sind Bewegungsdaten grundsätzlich veränderlich und repräsentieren meist quantitative Aussagen. Es handelt sich um Daten aus den laufenden Geschäftsvorfällen, die aus dem Rechnungswesen resultieren. Vgl. CHAMONI/GLUCHOWSKI/HAHNE (2005), S. 46 f. u. WILLINGER/GRADL (2003), S. 19.

352

Bei einem Deadlock handelt es sich um einen unerwünschten Zustand, bei dem in einer Datenbank die Transaktion A eine Sperre auf eine Ressource anfordert, die Transaktion B derzeit gesperrt hat, und zugleich Transaktion B auf eine Ressource wartet, für die Transaktion A eine Sperre errichtet hat. Bei einer Ressource handelt es sich z.B. um eine bestimmte Tabelle in der Datenbank. Vgl. BAUDER (2008), S. 499. Ein Deadlock ist ein Zugriffskonflikt, dessen Auftreten durch ein hohes Aufkommen von Datenbankkommandos begünstigt wird. Maßnahmen, um das Auftreten von Deadlocks zu reduzieren, sind z.B. das Verhindern des Sperrens von Tabellen durch ausschließlich lesende Informationssysteme. Vgl. MERTENS (2000), S. 116.

353

Online-Banking ist ein Synonym für Electronic-Banking, Home-Banking, Internet-Banking und PCBanking. Es existieren grundsätzlich drei verschiedene Möglichkeiten für das Durchführen von Online-Banking: Beim Internet-basierten Online-Banking wird der Zugang zu den Kontoinformationen über einen beliebigen Webbrowser ermöglicht. Bei Benutzung einer Banksoftware versorgt die Bank ihre Kunden mit einer proprietären Software, die auf dem PC des Kunden installiert werden muss und die Verbindung zu den Banksystemen herstellt. Mit einer Personal Finance Software kann ebenfalls Online-Banking durchgeführt werden. Hierbei wird kompatible Software eines Dritten genutzt, z.B. Quicken oder Microsoft Money. Vgl. SCN EDUCATION B.V. (2001), S. 19.

354

AUGEO SOFTWARE ist ein Softwareunternehmen, das 1991 in Frankreich gegründet wurde. AUGEO SOFTWARE hat sich auf die Entwicklung von Projekt- und Portfoliomanagement spezialisiert. Das Kernprodukt des Unternehmens ist Augeo5, das Akteuren die Verwaltung von Projektinformationen über ein zentrales Webportal ermöglicht. Vgl. AUGEO SOFTWARE (2008).

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

139

dienen, Projektinformationen und Ressourcen mit Hilfe eines zentralen Datenmanagements zu verwalten. Der zehnte Fall handelt von der Verbesserung des Clientstarts. Unter Verbesserung war hier die Reduzierung der Startzeit des Clients zu verstehen. Die Startzeit, die benötigt wurde, um den Client vom ausgeschalteten Zustand in einen betriebsbereiten Zustand zu versetzen, wurde durch die Beseitigung unnötiger Startprozesse und durch die Identifikation und Beseitigung negativer Wechselwirkungen zwischen verschiedenen Startprozessen reduziert. 3.2.3.3 Erstellung der Ontologie 3.2.3.3.1 Ziele und Umfang

Die zu erstellende Ontologie bezieht sich auf die Domäne Projektmanagement mit der Spezialisierung auf IT-Projekte. Die Ontologie basiert auf den Begriffen, die aus der exemplarischen Sammlung von Projektdokumenten extrahiert wurden. Bei diesen Dokumenten handelt es sich um Texte, die aus natürlichsprachlich repräsentiertem Projektwissen bestehen. Um die Machbarkeit aufzuzeigen, wurden zehn Dokumente gesammelt (siehe Anhang 1). Bei einem praktischen Einsatz ist von einer weitaus höheren Anzahl an Dokumenten auszugehen, die mit derselben Technik bearbeitet und ausgewertet werden können. Die Extraktion von Begriffen stellt den ersten Verarbeitungsschritt der Dokumente dar. Diese Extraktion erfolgte manuell.355 Eine automatische Vorverarbeitung mit Hilfe spezieller Tools wurde nicht gewählt, da die Konfiguration am Markt verfügbarer Textanalyse-Tools und die Programmierung eines neuen Textanalyse-Tools einen erheblichen Arbeitsaufwand voraussetzen würden. Außerdem wäre dann eine Unsicherheit bei der Extraktion zu akzeptieren, da z.B. wichtige Schlüsselwörter nicht erkannt werden könnten. Die automatische Extraktion von Fällen aus Texten wird in der Literatur als sehr komplexes Thema aufgefasst.356 Zweckreich wäre der Einsatz eines automatischen Verfahrens insbesondere bei einer großen Datenmenge. Da hier jedoch mit einer exemplarischen, kleinen Datenmenge gearbeitet wird, ist dem manuellen Verfahren Vorrang zu geben. Ziel der Vorverarbeitung war die Identifikation aller Begriffe und Relationen zwischen den Begriffen, die eine spezifische Bedeutung für die entsprechenden Projekte besitzen. Begriffe, die keine Relevanz für die Erfassung des Dokumenteninhalts besitzen, sollten dabei entfernt

355

Vgl. S. 265 ff.

356

Vgl. HAHN/RAMSCAR (2001), S. 120.

140

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

werden (Entfernung von Stoppwörtern) und die Begriffe sollten zu ihrer Grundform reduziert werden (Stemming). Das Ergebnis der manuellen Vorverarbeitung war die Gesamtheit aller Begriffe für die Ontologie. Die Schritte der Vorverarbeitung und die Darstellung der Ontologie sind im Anhang aufgeführt. 3.2.3.3.2 Methode zur Erstellung der Ontologie

Die Erstellung der Ontologie für das ontologiegestützte Case-Based Reasoning ist an eine Methode der STANFORD UNIVERSITY angelehnt.357 Diese beinhaltet die Arbeitsschritte Bestimmung der Domäne, Nutzung bestehender Ontologien, Sammlung wichtiger Bestandteile der Ontologie, Definition der Klassen, der Klassenhierarchie und der Relationen zwischen den Klassen, Definition der Attribute, Definition der Wertebereiche und Erzeugung von Instanzen sowie die Zuordnung der Instanzen zu den definierten Klassen. Die Ontologie setzt sich aus Klassen, Instanzen, Attributen, Relationen und Restriktionen zu Klasseneigenschaften zusammen. Für die Klassen werden Instanzen erstellt. Die Instanzen bilden eine Fallbasis. Da für die Ontologie-Erstellung das Tool Protégé ausgewählt wurde, das zur formalen Speicherung im Rahmen der Ontologie-Erstellung genutzt wird, bildet das Handbuch zur Erstellung einer OWL-Ontologie mit Protégé von der STANFORD UNIVERSITY und der UNIVERSITY

OF

MANCHESTER 358 ebenfalls eine Grundlage für die nächsten Schritte. Ob-

wohl dieses Handbuch speziell auf die Ontologiesprache OWL und nicht auf die in dieser Untersuchung genutzte Protégé-interne Ontologiesprache ausgerichtet ist, werden einige allgemeine Empfehlungen für die Ontologieerstellung übernommen. Die Nutzung der Protégé-internen Ontologiesprache ist notwendig, um die Stabilität 359 des CBR-Tools MyCBR zu gewährleisten, das als Plug-In in Protégé integriert wird. 3.2.3.3.3 Anwendung der Methode zur Erstellung der Ontologie 3.2.3.3.3.1 Bestimmung der Domäne

Die Domäne der Ontologie ist bereits durch die Dokumente in der Fallbasis vorgegeben. Die Dokumente stammen aus dem Bereich IT-Projektmanagement. Somit ist die zu erstellende Ontologie eine Domänenontologie für die Domäne IT-Projektmanagement. Die On357

Vgl. NOY/MCGUINNESS (2006), S. 4 ff.

358

Vgl. KNUBLAUCH/RECTOR/STEVENS/WROE (2004), S. 1 ff.

359

Mit Stabilität ist gemeint, dass keine Fehlerzustände innerhalb von MyCBR auftreten. Die Fehlerzustände werden vermieden, indem die Protégé-interne Ontologiesprache genutzt wurde, für die MyCBR laut dem DFKI entwickelt wurde. Vgl. Fußnote 336, S. 133.

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

141

tologie soll dazu genutzt werden, um das Case-Based Reasoning mit natürlichsprachlichen Dokumenten zu stützen. Da viele Fachbegriffe im IT- und auch im ProjektmanagementBereich in englischer Sprache geläufig sind, sollte auch dies in der Ontologie berücksichtigt werden. 3.2.3.3.3.2 Nutzung bestehender Ontologien

Bei der Erstellung einer neuen Ontologie sollte zunächst überlegt werden, ob bestehende Ontologien genutzt werden können. In der vorliegenden Untersuchung ist die Nutzung einer bestehenden Ontologie nicht sinnvoll, da zum einen keine Ontologie zu dieser speziellen Domäne in bekannten Online-Ressourcen360 verfügbar ist und zum anderen die exemplarische Sammlung der Dokumente aus der Fallbasis sehr spezifisch ist und eine vollumfängliche Berücksichtigung der Dokumenteninhalte nur bei der Neuerstellung der Ontologie möglich ist. 3.2.3.3.3.3 Sammlung wichtiger Begriffe für die Ontologie

Jeder Text aus den zehn Dokumenten mit Projektwissen muss nach Schlüsselwörtern durchsucht werden. Dieser Vorgang wird auch Parsing genannt. Ein Schlüsselwort ist eine Entität 361 , die eine hohe Relevanz für die Offenlegung der Semantik der Dokumente besitzt. Die Zuordnung von Wörtern zu Schlüsselwörtern kann mit n:1 charakterisiert werden. Das Parsing identifiziert ein Wort, grammatikalische Ableitungen, Abkürzungen und ausländische Übersetzungen. Diese werden alle einem bestimmten Schlüsselwort zugeordnet. Die Identifikation einer Entität als Klasse oder Instanz wird in den darauffolgenden Schritten durchgeführt. Wenn es sich bei einer Entität um eine Instanz handelt, bleiben die Attributswerte der Entität als Attributswerte der Instanz bestehen. Bei der Identifikation von Entitäten wird ein Wertebereich für die Attributswerte festgelegt. Das Parsing kann grundsätzlich automatisiert werden. Dies kann durch die Nutzung von Tools zur Extraktion

360

Bekannte Online-Ressourcen für bestehende Ontologien sind z.B. die Ontolingua Ontology Library (vgl. KSL (2008)), die DAML Ontology Library (vgl. DARPA (2004)) und das SchemaWeb mit einem Verzeichnis für RDF-Schemas in den Sprachen RDFS, OWL and DAML+OIL (vgl. SCHEMAWEB (2005)).

361

Eine Entität wird hier als Oberbegriff für Klassen und Instanzen verstanden. Eine Entität ist eine abstrakte Repräsentation eines Objekts der Realität. Vgl. hierzu ZÖLLER-GREER (2002), S. 64.

142

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

ermöglicht werden. 362 Da die Nutzung von Tools jedoch eine arbeitsintensive Konfiguration und ein umfassendes Training erfordert, um korrekte Extraktionen durchzuführen, würde der Implementierungsaufwand erhöht werden. Um z.B. Klassen zu erkennen und Instanzen zuzuordnen, müsste dem Tool zuvor „beigebracht“ werden, nach welchen Kriterien Textbausteine analysiert werden sollen. Auch für eine Grundformreduktion (Stemming) und das Entfernen von nicht relevanten Wörtern (Stoppwörtern) müssten Regeln im Tool definiert sein. Entitäten können sich aus mehreren Wörtern zusammensetzen, z.B. „Disaster Recovery“ oder „Windows XP“. Dies würde die automatische Extraktion der Entitäten mit Hilfe eines Tools zusätzlich erschweren. Außerdem kann durch die automatische Extraktion grundsätzlich nur eine Annäherung an eine präzise Ontologie erstellt werden. Um die Ontologie zu präzisieren wäre eine manuelle Nachbearbeitung erforderlich. Daher wurde entschieden, das Parsing manuell durchzuführen. Die Schaffung eines Automatismus kann im Rahmen anschließender Untersuchungen betrachtet werden. Die Methoden, die fürs Parsing genutzt werden können, sind die Brute-Force-Methode, die alle vorkommenden Wörter nutzt, die statistisch orientierte Methode, bei der Schlüsselwörter basierend auf Statistiken über alle Dokumente ausgewählt werden, und die wissensintensive Methode, bei der ein Akteur mit Domänenwissen bedeutungsvolle Schlüsselwörter spezifiziert. In dieser Untersuchung wird die wissensintensive Methode genutzt, da die Ergebnisse dieser Methode am zuverlässigsten sind. 363 Anbei ist ein Auszug der extrahierten Entitäten, bei denen es sich um Klassen oder Instanzen handelt, in alphabetischer Reihenfolge dargestellt:

362

Beispiele für Tools zur Extraktion von Entitäten aus Texten sind die kommerziellen Produkte von ATLAS.TI, MEGAPUTER, CLEARFOREST, SAP (durch den Kauf von INXIGHT), LIVING-E (ehemals XTRAMIND), LEXIMANCER, SAS, ATTENSITY und SPSS (Tochtergesellschaft von IBM). Die Erstellung von Ontologien auf Basis von Textextraktionen ist auch Bestandteil des Forschungsprojekts OntoBasis des belgischen Unternehmens IWT. Vgl. WISE (2004). Außerdem gibt es das Tool TextToOnto, das vom FZI FORSCHUNGSZENTRUM INFORMATIK und KARLSRUHER INSTITUT FÜR TECHNOLOGIE entwickelt wurde, um die Erstellung einer Ontologie durch Text Mining zu unterstützen. Vgl. FZI/AIFB (2004). OntoGen ist ein von slovenischen Forschern entwickelter semi-automatischer Ontologie-Editor, der ebenfalls Text Mining nutzt. Vgl. INSTITUT „JOŽEF STEFAN“ (2007). Außerdem existiert ein Repository der NATIONAL UNIVERSITY OF SINGAPORE für Software aus den Bereichen Natural Language Processing und Information Retrieval. Vgl. NATIONAL UNIVERSITY OF SINGAPORE (2005).

363

Die höhere Zuverlässigkeit ist dadurch gegeben, dass bei der wissensintensiven Methode die menschliche Sprachverarbeitung direkt genutzt wird. Automatische Parsing-Methoden verfolgen den Zweck, die menschliche Sprachverarbeitung nachzustellen. Vgl. GARROD/PICKERING (1999), S. 198. HUYCK bezeichnet die Interpretation von natürlichsprachlichem Text durch einen menschlichen Akteur als korrekte Interpretation, der das Ergebnis eines automatischen Parsings angenähert werden soll. Vgl. HUYCK (2000), S. 436.

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

143

AIX

Anwendungsbereich

Augeo

Betriebssystem

Börsensysteme

Client

Clientstart

Dauer

Disaster Recovery

Fremdentwicklung

Hardware

Hersteller

IBM iSeries

Installation

Internet

Konfiguration

Linux

Migration

Modell

Online-Banking

Personentage

Projekt

Projektmanagement

Server

Serverwechsel

Software

Unix

Version

Vertriebsdatenbank

Vertriebspartner

Webapplikation

Windows XP

Tabelle 39: Auszug der extrahierten Entitäten

3.2.3.3.3.4 Definition der Klassen und der Klassenhierarchie

Um die Klassen festzulegen und die Klassenhierarchie aufzubauen, werden die extrahierten Entitäten genauer untersucht. Alle Entitäten, zu denen andere Entitäten als Instanzen oder Subklassen zugeordnet werden können, werden als Klassen identifiziert. Alle übrigen Entitäten werden als Instanzen identifiziert. Die Klassenhierarchie kann mit drei verschiedenen Verfahren erstellt werden: Topdown, Bottom-up und einer Kombination aus diesen beiden. 364 Beim Top-down-Verfahren werden zuerst die generellsten Klassen der Domäne definiert und dann untergeordnete Spezialisierungen dieser Klassen. Beim Bottom-Up-Verfahren werden zuerst die speziellsten Klassen definiert und dann Gruppierungen vorgenommen, um die Klassen zu Klassen höherer Ebenen zusammenzufassen. Bei der Kombination aus Top-down- und Bottom-up-Verfahren werden zuerst einige auffällige Klassen definiert. Anschließend werden generelle Klassen und spezielle Klassen durch Klassen mittlerer Ebene miteinander verbunden. Keines dieser drei Verfahren ist grundsätzlich besser als die anderen. Die Wahl des Verfahrens hängt stark von der Sichtweise des Autors auf die Domäne ab. 365 In der aktuellen Untersuchung wird das Top-down-Verfahren genutzt, da die generellen Klassen eine geringere Anzahl aufweisen als die speziellen Klassen und somit die Komplexität der Hierarchie schrittweise erhöht werden kann. Die Identifikation und hierarchische Einordnung der Klassen verläuft iterativ. Der Aufbau der erstellten Klassenhierarchie ist in Ab364

Vgl. NOY/MCGUINNESS (2006), S. 6 f.

365

Vgl. NOY/MCGUINNESS (2006), S. 7.

144

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

bildung 34 dargestellt. In der abgebildeten Hierarchie werden ausschließlich die Klassen und ihre Relationen zueinander aufgeführt. Ein Rechteck steht für eine Klasse und ein Pfeil für eine Relation.

Projekt

betrifftAnwendung

Anwendung

betrifftBetriebssystem

Betriebssystem

betrifftHardware

Hardware

System istBestandteilVon

istBestandteilVon

Software istEin

Hardware istEin Betriebssystem

istEin Client

istEin

Server

Anwendung

istEin

Individualanwendung

istEin

Standardanwendung Legende:

Relation: Klasse:

Abbildung 34: Darstellung der Klassenhierarchie

Eine Instanz ist eine spezifische Ausprägung einer Klasse in Bezug auf die Werte der Attribute und Relationen, die von dieser Klasse vererbt wurden. Eine Instanz besitzt keine untergeordneten Objekte in der Ontologie. Daher ist eine Instanz ausschließlich auf der

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

145

niedrigsten Stufe der Granularität zu finden. 366 Bei den Entitäten höherer Stufen handelt es sich um Klassen. Auch auf der niedrigsten Stufe sind Klassen möglich. Diese besitzen keine Instanzen. Die Klasse „Projekt“ ist grundlegend für jeden Fall, da in dieser Untersuchung ein Fall stets dazu dient, ein Projekt zu beschreiben. Die Klasse „System“ besitzt auf Grund der IT-basierten Domäne ebenfalls eine tragende Bedeutung. Da sich ein System immer aus „Software“ und „Hardware“ zusammensetzt, stehen diese beiden Klassen in Relation zu der Klasse „System“. Bei der Klasse „Software“ wird weiter differenziert in „Betriebssystem“ und „Anwendung“, welche sich weiter in „Individualanwendung“ und „Standardanwendung“ gliedert. Individualanwendungen sind dabei als für ein Unternehmen individuell angefertigte Anwendungssoftware zu verstehen. Standardanwendungen können als vorgefertigte Anwendungssoftware im Handel erworben werden. Die Erstellung von Klassen mit Hilfe von Protégé erfolgt durch das Anlegen von Unterklassen (in Protégé: subclasses) zum Konzept „Thing“. Alle Klassen werden durch „Thing“ zusammengefasst. Daher sind alle neuen Klassen Unterklassen von „Thing“.367 Eine neu angelegte Klasse erhält in Protégé zunächst einen vorgegebenen Namen, der sich aus „Class_“ und einer fortlaufenden Nummer zusammensetzt, z.B. „Class_1“. Der Name der Klasse kann in der Namenszeile in Protégé geändert werden. Gemäß dem Handbuch zu Protégé 368 werden alle Klassen-Namen mit einem Großbuchstaben begonnen und enthalten keine Leerzeichen. Zu jeder Klasse können weitere Unterklassen angelegt werden, so dass eine Hierarchie von Klassen entsteht. Z.B. ist „Software“ eine Unterklasse von „System“. Die hierarchischen Beziehungen der Klassen und Instanzen der Ontologie sind transitiv. Wenn z.B. „Betriebssystem“ eine Unterklasse von „Software“ ist, bedeutet dies, dass eine Instanz von „Betriebssystem“ automatisch auch eine Instanz von „Software“ ist. Die Instanz „Microsoft_Windows_XP“ ist demnach eine Instanz von „Betriebssystem“ und gleichzeitig eine Instanz von „Software“. In der folgenden Abbildung 35 ist die mit dem Protégé-Plug-In Jambalaya 369 visualisierte Klassenhierarchie dargestellt. Die Kanten stehen für die Relation „hatUnterklasse“. Daher ist die Richtung der Kanten zu Abbildung 34 entgegengesetzt. 366

Vgl. NOY/MCGUINNESS (2006), S. 18.

367

Vgl. KNUBLAUCH/RECTOR/STEVENS/WROE (2004), S. 16.

368

Vgl. KNUBLAUCH/RECTOR/STEVENS/WROE (2004), S. 18.

369

Jambalaya ist ein Plug-In für Protégé, das der Visualisierung von in Protégé modelliertem Wissen dient. Der Hersteller des Plug-Ins ist das kanadische Unternehmen COMPUTER HUMAN INTERACTION & SOFTWARE ENGINEERING LAB (CHISEL). Vgl. CHISEL (2004).

146

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

Abbildung 35: Visualisierung der Klassenhierarchie in Protégé mit Jambalaya

3.2.3.3.3.5 Definition der Attribute und Relationen

Im nächsten Schritt werden die Slots, bei denen es sich um Attribute und Relationen handeln kann, auf der Ebene der Klassen definiert. Die Slots können in dem GUI von Protégé über die Karteikarte „Slots“ erstellt werden. Alle Attribute und Relationen einer Klasse werden auf alle Unterklassen und Instanzen dieser Klasse vererbt. Ein Attribut oder eine Relation kann sowohl für Klassen definiert werden, die direkte Instanzen besitzen, wie z.B. das Attribut „Euro“ der Klasse „Projekt“, als auch für Klassen, deren Unterklassen Instanzen besitzen, wie z.B. das Attribut „Anwendungsbereich“ für die Klasse „Anwendung“. Die Attribute und Relationen werden durch die Definition von Instanzen mit Werten belegt. Eine Instanz ist eine spezifische Ausprägung einer Klasse. Die Attribute und Relationen sowie deren Werte werden ebenfalls im Rahmen einer Extraktion aus den Textdokumenten ausgewählt. Im Rahmen der Ontologieerstellung wird zunächst für jede Klasse, die keine weiteren Unterklassen besitzt, nach Werten für Attribute gesucht, die in den Dokumenten beschrieben werden. Anschließend werden die gefundenen Attributswerte generalisiert, um

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

147

auf Attribute zu schließen. 370 Wenn alle zu einer Klasse gehörenden Unterklassen dasselbe Attribut besitzen, wird das Attribut der übergeordneten Klasse zugeordnet. Dies ist z.B. beim Attribut „Anwendungsbereich“ der Klasse „Anwendung“ der Fall. Durch die Vererbung besitzen alle Unterklassen ebenfalls dieses Attribut. In der Tabelle 40 werden festgelegte Attribute mit exemplarisch extrahierten Attributswerten aufgeführt. Die Relationen „istEin“ und „istBestandteilVon“ werden durch die Hierarchie der Ontologie abgebildet. Diese Relationen sind durch das Verhältnis von Unterklasse zu Oberklasse oder von Instanz zu Klasse gekennzeichnet. Die Relation „istEin“ verknüpft z.B. die Unterklasse „Anwendung“ mit der Oberklasse „Software“. Die Relation „istBestandteilVon“ verknüpft z.B. die Klasse „Software“ mit der Klasse „System“. Bei den festgelegten Attributen und Relationen handelt es um einen Auszug zur Erstellung einer Ontologie, die zur Demonstration der Machbarkeit des ontologiegestützten Case-Based Reasonings verwendet werden soll. In einem späteren praktischen Einsatz ist es möglich, die Menge der Attribute und Relationen zu erweitern. Die Klasse „Projekt“ könnte z.B. die zusätzlichen Attribute „Projektmitglieder“, „Sponsor“, „Projektleiter“ oder „Umfang“ besitzen. In der folgenden Tabelle 40 werden die Klassen in der Reihenfolge aufgeführt, in der sie in der Klassenhierarchie positioniert sind. Wenn mehrere Klassen auf derselben Hierarchieebene positioniert sind, werden sie alphabetisch aufgeführt.

370

Bei der Generalisierung von Attributswerten zu Attributen wird jeder Attributswert einem allgemeinen Attribut zugeordnet. Die Generalisierung wird am Beispiel des Attributs „Projekttyp“ verdeutlicht: Die Attributswerte „Installation“, „Migration“ und „Konfiguration“ werden zusammengefasst und anhand ihrer Gemeinsamkeit wird ein übergeordnetes Attribut gewählt. Die Werte haben gemeinsam, dass sie eine Eigenschaft eines Projekts beschreiben. Das Attribut wird daher der Klasse „Projekt“ zugeordnet. Da der Zweck der Attributswerte die Beschreibung des Typs eines Projekts ist, erhält das Attribut den Namen „Projekttyp“.

148

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen Klasse

Slot

Slot-Typ

Beispielwert

Name

Attribut

Unix-Härtung

Projekttyp

Attribut

Migration

Euro

Attribut

150.000

Personentage

Attribut

200

betrifftHardware

Relation

Dell_PowerEdge

betrifftBetriebssystem

Relation

Microsoft_ Windows_XP

betrifftAnwendung

Relation

Sungard_GlobalOne

System

istGrundlageVon

Relation

Projekt

Hardware

istBestandteilVon

Relation

System

Software

istBestandteilVon

Relation

System

Anwendung

istEin

Relation

Software

Projekt

Betriebssystem

Client

Server

Individualanwendung

Standardanwendung

Betriebssystemname Attribut

Microsoft_ Windows_XP

Familie

Attribut

Linux

istEin

Relation

Software

Modell

Attribut

Samsung_X50

Typ

Attribut

Desktop

istEin

Relation

Hardware

Modell

Attribut

Dell_PowerEdge

Typ

Attribut

Rack

istEin

Relation

Hardware

Anwendungsname

Attribut

Sungard_GlobalOne

Anwendungsbereich Attribut

Handel

istEin

Relation

Anwendung

Anwendungsname

Attribut

Vertriebsdatenbank

Anwendungsbereich Attribut

Handel

istEin

Anwendung

Relation

Tabelle 40: Attribute und Relationen der Ontologie

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

149

In Anlehnung an die Empfehlungen des Handbuchs zu Protégé 371 werden Namen für Attribute und Relationen mit einem Kleinbuchstaben begonnen und enthalten keine Leerzeichen. Weitere Wörter, die im selben Namen vorkommen, werden mit einem Großbuchstaben begonnen. Ein Beispiel ist „istBestandteilVon“. Optional können Unterstriche anstatt Leerzeichen genutzt werden.

Abbildung 36: Definition von Attributen und Relationen in Protégé

Im Eingabefeld „Value-Type“ wird der Wertebereich angegeben. Diese Angabe muss erfolgen. Ein Beispiel für einen Wertebereich ist Integer. Die Definition der Wertebereiche wird im nächsten Kapitel vorgenommen. Das Feld „Allowed Values“ erscheint nur, wenn als Wertebereich Class, Instance oder Symbol gewählt wurde. Bei diesen Wertebereichen müssen die erlaubten Werte explizit angegeben werden. Ein Beispiel für erlaubte Werte, wenn der Wertebereich Symbol angegeben wurde, ist „Windows, Linux“. Wenn als Wertebereich Integer oder Float gewählt wurde, können in den Feldern „Minimum“ und „Maximum“ der minimal und der maximal erlaubte Wert angegeben werden. Hierdurch kann der Bereich der erlaubten Zahlen eingegrenzt werden. Wenn z.B. das 371

Vgl. KNUBLAUCH/RECTOR/STEVENS/WROE (2004), S. 28.

150

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

Attribut „Euro“ eingegrenzt werden soll, können als Minimum 10100 und als Maximum 452000 angegeben werden. Im Feld „Documentation“ kann optional ein freier Text mit Bemerkungen eingetragen werden. Z.B. kann für das Attribut „Euro“ folgender Text eingetragen werden: Dieses Attribut repräsentiert die Kosten, die im Rahmen des betreffenden Projekts entstanden. Unter „Cardinality“ wird die Kardinalität des Slots angegeben. Standardmäßig ist minimal („at least“) Null und maximal („at most“) Eins vorgegeben. Für das Attribut „Euro“ bedeutet dies, dass das Attribut keinen Wert besitzen muss und maximal einen Wert besitzen kann. Das Attribut kann also nicht zugleich die Werte 20000 und 30000 besitzen, da sonst die erlaubte Kardinalität verletzt wird. Im nächsten Kapitel werden alle verwendeten Kardinalitäten definiert. Jeder Slot mit dem Wertebereich „Instance“ oder „Class“ ist eine Relation und kann Instanzen oder Klassen relational verknüpfen. Zu einer Relation, die das Objekt a mit dem Objekt b verbindet, kann eine inverse Relation existieren, die das Objekt b mit dem Objekt a verbindet. Z.B. besitzt die Relation „istBestandteilVon“ die inverse Relation „hatBestandteil“. Wenn gilt: „Linux“ „istBestandteilVon“ „Mailgateway“, dann gilt auch: „Mailgateway“ „hatBestandteil“ „Linux“. Inverse Relationen können in Protégé auf der Karteikarte „Slots“ unter dem Punkt „Inverse Slot“ angegeben werden. Das Feld „Template Values” erlaubt die Vorgabe von Standardwerten für Attribute oder Relationen, die in Unterklassen oder Instanzen nicht mehr geändert werden können. Wenn z.B. für das Attribut „Euro“ hier der Wert 50000 eingetragen wird, besitzt jede Instanz für das Attribut „Euro“ zwingend den unveränderlichen Wert 50000. Das Feld „Default Values” erlaubt die Vorgabe von Standardwerten für Attribute oder Relationen, die in Unterklassen oder Instanzen bei Bedarf geändert werden können. Der hier angegebene Wert wird automatisch bei jeder neu erstellten Instanz eingetragen. Wenn z.B. für das Attribut „Euro“ der Wert 60000 eingetragen wird, besitzt jede Instanz zum Zeitpunkt der Neuanlage für das Attribut „Euro“ diesen Wert. Der Benutzer kann den Wert bei Bedarf ändern. Unter „Domain” werden die Klassen angegeben, für die das Attribut oder die Relation gültig sein sollen. Das Attribut oder die Relation werden auf die Unterklassen und Instanzen dieser Klassen vererbt. Wenn für das Attribut „Euro“ die Klasse „Projekt“ angegeben wird, besitzen alle Instanzen der Klasse „Projekt“ und alle Instanzen von Unterklassen der Klasse „Projekt“ das Attribut „Euro“.

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

151

In der folgenden Abbildung werden alle Attribute und Relationen der Ontologie veranschaulicht:

Abbildung 37: Attribute und Relationen der Ontologie

152

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

3.2.3.3.3.6 Definition der Wertebereiche und der Kardinalitäten von Attributen und Relationen

Die Definition der Wertebereiche lässt sich direkt aus den extrahierten Attributswerten und Relationswerten ableiten. Die Wertebereiche werden so definiert, dass mindestens alle gefundenen Werte abgebildet werden können. Mögliche Wertebereiche, die mit Protégé vorgegeben werden können, sind Boolean, Class, Float, Instance, Integer, String, Symbol und Any. Boolean wird für Attribute verwendet, die als Werte falsch oder wahr annehmen können. Der Wertebereich Class wird für Relationen zwischen Klassen verwendet. Im Feld mit den erlaubten Oberklassen („Allowed Superclasses“) werden alle Oberklassen der Klassen angegeben, die durch die Relation verknüpft werden können. Float wird für Attribute verwendet, die als Wert eine Gleitkommazahl annehmen können. Der Wertebereich kann mit den Feldern „Minimum“ und „Maximum“ eingegrenzt werden. Der Wertebereich Instance wird für Relationen zwischen Instanzen verwendet. Im Feld mit den erlaubten Klassen („Allowed Classes“) werden die Klassen aufgeführt, deren Instanzen durch die Relation verknüpft werden können. Integer wird für Attribute verwendet, die als Werte eine ganze Zahl annehmen können. Auch hier kann der Wertebereich mit den Feldern „Minimum“ und „Maximum“ eingegrenzt werden. String wird für Attribute verwendet, die Text als Werte annehmen können. Der Text besteht aus beliebigen ASCII-Zeichen. Bei SymbolAttributen müssen alle erlaubten Werte („Allowed Values“) explizit angegeben werden. Für die erlaubten Werte können beliebige String-Werte eingegeben werden. Wenn eine Eingrenzung des Wertebereichs nicht möglich ist, kann Any gewählt werden. Dann können Werte aus allen anderen Wertebereichen genutzt werden. Die Kardinalität des Attributs oder der Relation einer Instanz gibt vor, wie viele Werte dieses Attribut oder diese Relation gleichzeitig annehmen können. Z.B. hat das Attribut „Euro“ der Klasse „Projekt“ eine Kardinalität von Eins, da für ein Projekt nur ein Wert für „Euro“ korrekt sein kann. Demgegenüber hätte z.B. die Schnittstelle einer Komponente eine multiple Kardinalität, da z.B. eine Tastatur über eine PS2- und eine USBSchnittstelle verfügen kann. Durch die Spezifikation einer minimalen und maximalen Kardinalität kann die Anzahl der möglichen Attributs- oder Relationswerte präzise vorgegeben werden. 372 In der vorliegenden Untersuchung wird für jedes Attribut und jede Relation eine maximale Kardinalität von Eins festgelegt. Ein Attribut oder eine Relation mit einer Kardinalität von Null besitzt keinen zugewiesenen Wert. Die Wahl dieser Kardinalitäten eignet 372

Vgl. NOY/MCGUINNESS (2006), S. 9.

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

153

sich am besten, um die Machbarkeit des ontologiegestützten Case-Based Reasonings zu demonstrieren. Die korrekten lokalen Ähnlichkeitswerte können berechnet werden, ohne dass eine zu hohe Komplexität durch den Vergleich zwischen Werten von Attributen oder Relationen mit höheren Kardinalitäten entsteht. Wenn eine höhere Kardinalität zugelassen würde, wäre eine umfassendere Berechnung notwendig. Dann müsste zunächst bestimmt werden, ob z.B. ein pessimistischer, optimistischer oder durchschnittlicher Ansatz 373 gewählt wird. Bei einem pessimistischen Ansatz wäre nur der Attributswert mit dem geringeren Ähnlichkeitswert zu betrachten. Wenn z.B. eine Instanz, die für das Attribut „Euro“ die Werte 100 und 200 besitzt, mit einer Instanz verglichen wird, die für das Attribut „Euro“ den Wert 300 besitzt, wird die lokale Ähnlichkeit in Bezug auf das Attribut „Euro“ zwischen den Attributswerten 100 und 300 bestimmt. Der Attributswert 200 wird nicht berücksichtigt, da dieser einen geringeren Abstand zum Attributswert 300 besitzt und somit zu einem höheren lokalen Ähnlichkeitswert führt. Bei einem optimistischen Ansatz wäre nur der Attributswert mit dem höheren Ähnlichkeitswert zu betrachten. Bei oben stehendem Beispiel wird die lokale Ähnlichkeit dann in Bezug auf das Attribut „Euro“ zwischen den Attributswerten 200 und 300 bestimmt. Beim durchschnittlichen Ansatz wäre der durchschnittliche Ähnlichkeitswert aller gegebenen Attributswerte zu betrachten. Bei oben stehendem Beispiel wird die lokale Ähnlichkeit in Bezug auf das Attribut „Euro“ als Durchschnitt von dem Wert der Ähnlichkeit zwischen den Attributswerten 100 und 300 und dem Wert der Ähnlichkeit zwischen den Attributswerten 200 und 300 bestimmt. Auch bei anderen Wertebereichen sind die verschiedenen Ansätze nutzbar. Hierbei würde der Ähnlichkeitswert lediglich mit einem anderen Ähnlichkeitsmaßstab, z.B. einer Taxonomie, berechnet. Die Wertebereiche und Kardinalitäten der Attribute sind in der Tabelle 41 auf der folgenden Seite aufgeführt. Der Wertebereich von Relationen setzt sich aus allen Instanzen der Klasse zusammen, die mit der Ursprungsinstanz in Beziehung stehen können.

373

Vgl. BERGMANN (1998), S. 8 f.

154

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen Klasse

Projekt

Attribut/Relation

Wertebereich

Kardinalität

Name

Symbol

min. 0, max. 1

Projekttyp

Symbol

min. 0, max. 1

Euro

Integer (10100...452000)

min. 0, max. 1

Personentage

Integer (12...504)

min. 0, max. 1

betrifftHardware

Instance (aus der Klasse „Hardware“)

min. 0, max. 1

betrifftBetriebssystem Instance (aus der Klasse „Betriebssystem“)

min. 0, max. 1

betrifftAnwendung

Instance (aus der Klasse „Anwendung“)

min. 0, max. 1

System

istGrundlageVon

Instance (aus der Klasse „Projekt“)

min. 0, max. 1

Hardware

istBestandteilVon

Class

min. 0, max. 1

Software

istBestandteilVon

Class

min. 0, max. 1

Anwendung Betriebssystem

Client

Server

Individualanwendung

Standardanwendung

istEin

Class

min. 0, max. 1

Betriebssystemname

Symbol

min. 0, max. 1

Familie

Symbol

min. 0, max. 1

istEin

Class

min. 0, max. 1

Modell

Symbol

min. 0, max. 1

Typ

Symbol

min. 0, max. 1

istEin

Class

min. 0, max. 1

Modell

Symbol

min. 0, max. 1

Typ

Symbol

min. 0, max. 1

istEin

Class

min. 0, max. 1

Anwendungsname

Symbol

min. 0, max. 1

Anwendungsbereich

Symbol

min. 0, max. 1

istEin

Class

min. 0, max. 1

Anwendungsname

Symbol

min. 0, max. 1

Anwendungsbereich

Symbol

min. 0, max. 1

istEin

Class

min. 0, max. 1

Tabelle 41: Wertebereiche und Kardinalitäten der Attribute und Relationen

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

155

3.2.3.3.3.7 Erzeugung von Instanzen

Die Erzeugung von Instanzen hat bereits im Rahmen der Extraktion der Attributs- und Relationswerte begonnen. Die Werte müssen anschließend zu Instanzen gruppiert werden. Da nicht für jede Instanz alle Attributs- und Relationswerte in den Dokumenten vorkommen, existieren Instanzen, die nicht für alle Attribute und Relationen zugehörige Werte besitzen. In den folgenden Tabellen werden alle Instanzen mit den zugehörigen bekannten Attributsund Relationswerten dargestellt. Das Attribut „Dokument“ wird in der Ontologie nicht verwendet, sondern dient allein der besseren Orientierung in den folgenden Tabellen. Die Dokumenten-Nummer erlaubt die Zuordnung der Instanzen zu einem Dokument, das einen Fall repräsentiert. In der Ontologie sind Instanzen, die dieselbe Dokumenten-Nummer besitzen, durch Relationen miteinander verbunden. Z.B. besitzt die Instanz aus der Klasse „Projekt“ mit dem Namen „Unix-Härtung“ durch die Relation „betrifftBetriebssystem“ eine Verbindung mit der Instanz aus der Klasse „Betriebssystem“ mit dem Namen „Red_Hat_Linux_9“. Im Folgenden werden alle Instanzen in tabellarischer Form aufgeführt. Die Klassen „System“, „Hardware“, „Software“ und „Anwendung“ wurden ausgelassen, da diese Klassen ausschließlich Subklassen und damit keine direkt untergeordneten Instanzen besitzen.

Projekt (Teil 1) Dokument

Name

Personentage

Projekttyp

Euro

1 Unix-Härtung

Konfiguration

452000

320

2 Serverwechsel_Planungstool

Migration

12200

16

3 Firewall-Integration

Installation

65000

77

4 Migration_Börsensysteme

Migration

10100

12

5 Virtuelle_Internet-PCs

Installation

37500

45

6 Disaster_Recovery

Installation

382000

504

7 Stabilisierung_Vertriebsdatenbank

Konfiguration

34000

55

8 Online-Banking

Installation

290000

250

9 Projektmanagement-Tool

Installation

130000

110

25000

28

10 Verbesserung_Clientstart

Konfiguration

Tabelle 42: Instanzen der Klasse „Projekt“ (Teil 1)

156

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen Projekt (Teil 2)

Dokument

betrifftHardware

bestrifftBetriebssystem

betrifftAnwendung

1 Server_1

Red_Hat_Linux_9

unbekannt

2 Server_2

AIX_4.3.3

Sungard_Global_One

3 Server_3

Integrity_Linux

Check_Point_Firewall

4 Server_4

Sun_Solaris_10

Börsensysteme

5 Client_5

Microsoft_Windows_XP

Internet_Explorer

6 Client_6

Microsoft_Windows_XP

unbekannt

7 Server_7

Red_Hat_Linux_9

Vertriebsdatenbank

8 Server_8

Suse_Linux_10

Webapplikation

9 Client_9

Microsoft_Windows_XP

Augeo

Microsoft_Windows_Vista

unbekannt

10 Client_10

Tabelle 43: Instanzen der Klasse „Projekt“ (Teil 2)

Betriebssystem Dokument

Betriebssystemname

Familie

1, 7 Red_Hat_Linux_9

istEin

Unix

Betriebssystem

2 AIX_4.3.3

Unix

Betriebssystem

3 Integrity_Linux

Unix

Betriebssystem

4 Sun_Solaris_10

Unix

Betriebssystem

Windows

Betriebssystem

Unix

Betriebssystem

Windows

Betriebssystem

5, 6, 9 Microsoft_Windows_XP 8 Suse_Linux_10 10 Microsoft_Windows_Vista

Tabelle 44: Instanzen der Klasse „Betriebssystem“

Client Dokument

Name

Typ

Modell

istEin

5 Client_5

Virtuell

VMWare_ESX

Client

6 Client_6

Notebook

Samsung_X50

Client

9 Client_9

Desktop

Dell_Optiplex

Client

Notebook

Samsung_X20

Client

10 Client_10

Tabelle 45: Instanzen der Klasse „Client“

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

157

Server Dokument

Name

Typ

Modell

istEin

1 Server_1

Rack

IBM_iSeries

Server

2 Server_2

Virtuell

VMWare_ESX

Server

3 Server_3

Rack

Dell_PowerEdge

Server

4 Server_4

Tower

Dell_PowerEdge

Server

7 Server_7

Virtuell

VMWare_ESX

Server

8 Server_8

Rack

Dell_PowerEdge

Server

Tabelle 46: Instanzen der Klasse „Server“

Individualanwendung Dokument

Anwendungsname

Anwendungsbereich

istEin

4 Börsensysteme

Handel

Individualanwendung

7 Vertriebsdatenbank

Handel

Individualanwendung

8 Webapplikation

Internet

Individualanwendung

Tabelle 47: Instanzen der Klasse „Individualanwendung“

Standardanwendung Dokument

Anwendungsname

Anwendungsbereich

istEin

2 Sungard_Global_One

Handel

Standardanwendung

3 Check_Point_Firewall

Netzwerk

Standardanwendung

5 Internet_Explorer

Internet

Standardanwendung

9 Augeo

Projekte

Standardanwendung

Tabelle 48: Instanzen der Klasse „Standardanwendung“

In der folgenden Abbildung werden alle Instanzen der Ontologie veranschaulicht:

158

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

Abbildung 38: Instanzen der Ontologie

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

159

3.2.3.4 Erstellung von Ähnlichkeitsmaßstäben

Grundlegend für die Funktionsfähigkeit des Case-Based Reasonings ist die Spezifikation der lokalen Ähnlichkeiten. 374 Für die Beurteilung der Ähnlichkeiten zwischen Attributswerten von Instanzen und zwischen Relationswerten von Instanzen anhand von sowohl quantitativen als auch qualitativen Fallattributen müssen operationale Ähnlichkeitsmaßstäbe erstellt werden. Ein Ähnlichkeitsmaßstab für die Ähnlichkeit zwischen Attributswerten wird durch die Ähnlichkeitsfunktion sim a (a iq , a if ) definiert, die jeweils den Attributswert a iq des neuen Falls q und den Attributswert a if des alten Falls f aus der Fallbasis in Bezug auf deren Ähnlichkeit vergleicht; mit a iq  {a 1q ,..., a qI } , a if  {a 1f ,..., a fI } und i  {1,..., I} und I

An-

zahl der Attributswerte. Die lokale Ähnlichkeit besitzt bei numerischen Attributswerten den Ähnlichkeitsmaßstab Abstand, der mit Formel 3.14 berechnet wird. Wenn z.B. für den größten Attributswert max (a iq ) i

452000 und für den kleinsten Attributswert min (a if ) i

dann gilt für den maximalen Abstand max d

max (a iq )  min (a if ) i

441900. Die Ähnlichkeit zwischen den Attributswerten a iq

i

10100 gilt,

452000  10100

65000 und a if

12200 be-

trägt dann: sim a (a iq , a if )

1

a iq  a if max d

1

65000  12200 441900

0,881

Bei symbolischen Attributswerten können zwei Attributswerte selbst dann ähnlich sein, wenn sie komplett verschiedene Wörter enthalten, jedoch inhaltlich ähnlich sind. Z.B. können die Attributswerte „Debian“ und „Red Hat Linux“ als ähnlich angesehen werden,

374

Ein Objekt kann zu einem anderen Objekt eine hohe oder eine niedrige Ähnlichkeit besitzen. Die Höhe der Ähnlichkeit zwischen zwei Objekten ist von der Spezifikation der Ähnlichkeit abhängig. Vgl. HAHN/RAMSCAR (2001), S. 3. Ähnlichkeit gilt immer in Bezug auf spezifizierte Ähnlichkeitsmaßstäbe. Zu beachten ist, dass sich die Aussagekraft der Ähnlichkeit verschlechtern kann, wenn irrelevante Fälle in der Fallbasis gespeichert werden. Vgl. HAHN/RAMSCAR (2001), S. 136. Irrelevante Fälle in einer Fallbasis sind Fälle, die z.B. dazu führen, dass der Wertebereich eines Attributs stark vergrößert werden muss, damit alle auftretenden Werte des Attributs in der Fallbasis berücksichtigt werden können. Wenn es sich bei den relevanten Fällen in der Fallbasis um alle Fälle handelt, deren Werte dieses Attributs nahe beieinander liegen, ist die lokale Ähnlichkeit zwischen den relevanten Fällen sehr hoch und annähernd gleich. Dies führt dazu, dass in Bezug auf dieses Attribut eine schlechtere Aussagekraft der lokalen Ähnlichkeit für die Abgrenzung zwischen Fällen innerhalb der Menge der relevanten Fälle vorliegt.

160

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

da es sich bei beiden um Betriebssysteme handelt, die einen Unix-Kernel verwenden. Um symbolische Attributswerte vergleichbar zu machen, wird ein Ähnlichkeitsmaßstab genutzt, der aus einer Tabelle oder Taxonomie besteht. Wenn der Ähnlichkeitsmaßstab aus einer Tabelle besteht, werden alle bekannten Ähnlichkeiten zwischen den Attributswerten a iq und a if anhand des Tabellenfelds mit dem Wert tab (a iq , a if ) bestimmt, bei dem der Zeilenindex dem Attributswert a iq und der Spaltenindex dem Attributswert a if entspricht. Da die Tabelle symmetrisch ist und somit ein Attributswert a iq zu einem Attributswert a if dieselbe Ähnlichkeit besitzt wie ein Attributswert a if zu einem Attributswert a iq , können Zeilen- und Spaltenindex auch vertauscht werden. Es gilt: sim a (a iq , a if )

tab (a iq , a if )

tab (a if , a iq )

(3.17)

Wenn z.B. die zwei Attributswerte „Windows“ und „Unix“ mit den zugehörigen Ähnlichkeitswerten bekannt sind, dann wird folgende Tabelle mit zwei Zeilenindizes und mit zwei Spaltenindizes erstellt.

Windows

Attributswert

Unix

Windows Unix

1

0,2

0,2

1

Tabelle 49: Beispiel zum Ähnlichkeitsmaßstab Tabelle

Wenn die Attributswerte a 1q

Windows und a 1f

Ähnlichkeitswert: sim a (a 1q , a 1f )

tab (a 1q , a 1f )

Unix verglichen werden, gilt für den

tab (a 1f , a 1q )

0,2 .

Wenn der Ähnlichkeitsmaßstab aus einer Taxonomie besteht, sind alle bekannten Ähnlichkeiten an den Knoten der Taxonomie hinterlegt, die untergeordnete Knoten besitzen. Die Ähnlichkeit zwischen den Attributswerten a iq und a if wird anhand des Ähnlichkeitswerts tax (a iq , a if ) in der Taxonomie bestimmt, der an dem gemeinsamen übergeordneten Knoten der Knoten a iq und a if hinterlegt ist. Es gilt: sim a (a iq , a if )

tax (a iq , a if )

(3.18)

Wenn z.B. die zwei Attributswerte „Microsoft_Windows_XP“ und „AIX_4.3.3“ mit den zugehörigen Ähnlichkeitswerten bekannt sind, dann wird folgende Taxonomie (Abbildung 39) mit den notwendigen Knoten erstellt. Die Attributswerte werden als Knoten in der Ta-

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

161

xonomie dargestellt. An den Knoten mit Nachfolgern werden die Ähnlichkeitswerte hinterlegt. Betriebssystemname [0,2] Microsoft_Windows [0,8] Microsoft_Windows_XP Unix [0,5] AIX_4.3.3

Legende:

Relation „istEin“: Klasse: Instanz: Ähnlichkeitswert: [ ]

Abbildung 39: Beispiel zum Ähnlichkeitsmaßstab Taxonomie

Die Ähnlichkeit zwischen den beiden Attributswerten wird durch den Ähnlichkeitswert bestimmt, der an dem gemeinsamen übergeordneten Knoten hinterlegt ist. Hierbei handelt es sich um den Ähnlichkeitswert 0,2, der an dem Knoten „Betriebssystemname“ hinterlegt ist. Der Ähnlichkeitsmaßstab für die Ähnlichkeit zwischen Relationswerten wird durch die Ähnlichkeitsfunktion sim r ( rhq , rhf ) definiert, die jeweils den Relationswert rhq des neuen Falls q und den Relationswert rhf des alten Falls f aus der Fallbasis in Bezug auf deren Ähnlichkeit vergleicht. Es gilt: rhq  {r1q ,..., rHq } , rhf  {r1f ,..., rHf } und h  {1,..., H} und

H

Anzahl der Relationswerte. Bei Relationswerten entspricht die lokale Ähnlichkeit

sim r ( rhq , rhf ) der Ähnlichkeit zwischen den relational verknüpften Instanzen. Die Ähnlich-

keit zwischen den Instanzen wird durch eine Aggregation der lokalen Ähnlichkeitswerte dieser Instanzen mit Hilfe des im nächsten Kapitel dargestellten Algorithmus berechnet.

162

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen Der Wert der Ähnlichkeit zwischen Klassen wird anhand der Anzahl der gemein-

samen Attribute 375 der Instanzen dieser Klassen und anhand des Abstands376 zwischen den Instanzen der betroffenen Klassen in der Klassenhierarchie der Ontologie berechnet. Je mehr Attribute die Instanzen dieser Klassen gemeinsam haben und je geringer der Abstand zwischen den Instanzen der betroffenen Klassen in der Klassenhierarchie ist, desto ähnlicher sind die beiden Klassen. 377 Die Berücksichtigung der Hierarchie der Ontologie ist notwendig, da in der Klassenhierarchie Wissen über die Ähnlichkeit von Instanzen vorhanden ist. Instanzen, die in der Hierarchie enger zusammen liegen, sind ähnlicher als Instanzen, die in der Hierarchie weiter auseinander liegen. Jede Klasse wird mit einem Ähnlichkeitswert k zwischen Null und Eins belegt, der umso höher ist, je mehr gemeinsame Attribute die Instanzen der Klassen besitzen und je geringer der Abstand der Instanzen der Klassen ist. k berechnet sich danach, wie viele Attribute die beiden zu vergleichenden Instanzen der Klassen gemeinsam haben im Verhältnis zu allen vorhandenen Attributen der Instanzen der beiden zu vergleichenden Klassen. Wenn kein gemeinsames Attribut vorhanden ist, ist der Hebel für die Ähnlichkeit zwischen den Klassen so gering wie möglich, also ist der Wert Null. Wenn alle vorhanden Attribute gemeinsame Attribute sind, ist der Hebel für die Ähnlichkeit zwischen den Klassen so hoch wie möglich, also ist der Wert Eins. Dieser Hebel wird mit dem Reziprokwert der Anzahl der Knoten multipliziert, die in der Hierarchie der Ontologie von der gemeinsamen Oberklasse zu einer Instanz der am weitesten entfernten Klasse aus dem Vergleich zurückgelegt werden müssen. Die Anzahl der Knoten ist mindestens Eins, denn die geringste Anzahl liegt vor, wenn eine Klasse mit sich selbst verglichen wird. In diesem Fall muss genau ein Knoten auf dem Weg von einer Instanz der Klasse zur gemeinsamen Oberklasse zurückgelegt werden. Da die Instanzen der Klasse auch alle Attribute gemeinsam haben, wenn eine Klasse mit sich selbst verglichen wird, ist k=1. Allgemein gilt: (3.19)

375

Laut LUGER ist die Definition von Ähnlichkeit neben den Attributswerten grundsätzlich auch von der Anzahl gemeinsamer Attribute zwischen zwei Vergleichsobjekten abhängig. Vgl. LUGER (2003), S. 312. Auch laut BERGMANN kann die Ähnlichkeit zwischen Objekten danach bestimmt werden, wie viele Attribute diese Objekte gemeinsam haben. Vgl. BERGMANN (1998), S. 5.

376

Zur Nutzung des Abstands zwischen Knoten in einer Hierarchie zur Berechnung von Ähnlichkeitswerten vgl. AVRAMENKO/KRASLAWSKI (2008), S. 86 u. PFUHL (2003), S. 60 ff. Hier werden jedoch nicht explizit Ontologien genutzt.

377

Zur operationalsprachlichen Definition der Ähnlichkeit siehe Formel 3.20.

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

163

Im Folgenden wird ein Auszug aus der Ontologie dargestellt und es wird erläutert, wie die Anzahl der Knoten berechnet wird, wenn die Klassenähnlichkeit im Rahmen des Vergleichs von Instanzen aus verschiedenen Klassen berechnet wird. Im Beispiel 1 wird angenommen, dass die Instanz „Server_1“ mit dem neuen Fall q und die Instanz „Server_2“ mit dem alten Fall f relational verknüpft sind. Im Rahmen des Vergleichs dieser Instanzen muss die Klasse „Server“ mit sich selbst verglichen werden. Die Anzahl der Knoten, die in der Hierarchie der Ontologie von der gemeinsamen Oberklasse „Server“ zu der am weitesten entfernten Instanz aus dem Vergleich zurückgelegt werden müssen, beträgt Eins. Beide Instanzen sind gleich weit von der gemeinsamen Oberklasse „Server“ entfernt, und zwar genau einen Knoten.

Abbildung 40: Bestimmung der Anzahl von Knoten im Beispiel 1

Die Instanzen „Server_1“ und „Server_2“ besitzen beide die gleichen Attribute A 1q A 1f

„Modell“ und A q2

A f2

„Typ“. Die Anzahl der gemeinsamen Attribute beträgt wie

die Anzahl aller vorhandenen Attribute dieser Instanzen Vier. Die vier Attribute können unterschiedliche Attributswerte a1q , a q2 , a1f und a f2 besitzen.

164

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

Abbildung 41: Bestimmung der gemeinsamen Attribute im Beispiel 1

Für k gilt im Beispiel 1 somit:

Im Beispiel 2 wird angenommen, dass die Instanzen „Server_1“ und „Client_1“ verglichen werden und daher auch die Klassen „Server“ und „Client“ verglichen werden müssen. Die Anzahl der Knoten, die in der Hierarchie der Ontologie von der gemeinsamen Oberklasse „Hardware“ zu der am weitesten entfernten Instanz der Klassen aus dem Vergleich zurückgelegt werden müssen, beträgt Zwei. Beide Instanzen sind gleich weit von der gemeinsamen Oberklasse „Hardware“ entfernt, und zwar genau zwei Knoten.

Abbildung 42: Bestimmung der Anzahl von Knoten im Beispiel 2

Die Instanzen „Server_1“ und „Client_1“ besitzen beide die gleichen Attribute A 1q A 1f

„Modell“ und A q2

A f2

„Typ“. Die Anzahl der gemeinsamen Attribute beträgt wie

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

165

die Anzahl aller vorhandenen Attribute dieser Instanzen Vier. Die vier Attribute können unterschiedliche Attributswerte a1q , a q2 , a1f und a f2 besitzen.

Abbildung 43: Bestimmung der gemeinsamen Attribute im Beispiel 2

Für k gilt im Beispiel 2 somit:

Im Beispiel 3 wird angenommen, dass die Instanzen „Red_Hat_Linux_9“ und „Internet_Explorer“ verglichen werden und daher auch die Klassen „Betriebssystem“ und „Standardanwendung“ verglichen werden müssen. Die Anzahl der Knoten, die in der Hierarchie der Ontologie von der gemeinsamen Oberklasse „Software“ zu der am weitesten entfernten Instanz aus dem Vergleich zurückgelegt werden müssen, beträgt Drei. Die Instanz „Red_Hat_Linux_9“ ist zwei Knoten von der Oberklasse „Software“ entfernt. Die Instanz „Internet_Explorer“ ist drei Knoten von der Oberklasse „Software“ und somit am weitesten entfernt.

166

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

Abbildung 44: Bestimmung der Anzahl von Knoten im Beispiel 3

Die Instanzen „Red_Hat_Linux_9“ und „Internet_Explorer“ besitzen unterschiedliche Attribute mit A 1q und A

f 2

„Betriebssystemname“, A 1f

„Anwendungsbereich“, A q2

„Familie“

„Anwendungsname“. Die Anzahl der gemeinsamen Attribute beträgt Null und

die Anzahl aller vorhandenen Attribute dieser Instanzen beträgt Vier. Die vier Attribute können unterschiedliche Attributswerte a1q , a q2 , a1f und a f2 besitzen.

Abbildung 45: Bestimmung der gemeinsamen Attribute im Beispiel 3

Für k gilt im Beispiel 3 somit:

Die Ähnlichkeit zwischen Klassen lässt sich mit folgender Formel abbilden. Hier gilt: c qh ist die Klasse, zu der die Instanz mit der Attributsmenge {A 1q ,..., A qI } gehört, und c fh ist

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

167

die Klasse, zu der die Instanz mit der Attributsmenge {A 1f ,..., A fI } gehört. Die Schnittmenge von {A 1q ,..., A qI } und {A 1f ,..., A fI } ist ungleich der leeren Menge, wenn mindestens ein Attribut existiert, das die relational verknüpften Instanzen gemeinsam besitzen. q h

f h

sim c ( c , c )

­1 ° ®k °0 ¯

wenn ciq cif wenn {A1f ,..., A fI } ˆ {A1q ,..., A qI } z {}

(3.20)

wenn {A1f ,..., A fI } ˆ {A1q ,..., A qI } {}

Das Ergebnis des Schritts besteht aus mehreren lokalen Ähnlichkeitswerten pro Instanz. Nach Anwendung der Ähnlichkeitsmaßstäbe erfolgt die Aggregation der lokalen Ähnlichkeitswerte mit Hilfe des im nächsten Kapitel beschriebenen Algorithmus zu einem globalen Ähnlichkeitswert. 3.2.3.5 Erstellung eines Algorithmus zur Aggregation von lokalen Ähnlichkeitswerten

Die lokalen Ähnlichkeitswerte für die Ähnlichkeit zwischen Attributswerten und zwischen Relationswerten werden mit Hilfe eines Algorithmus zu einem globalen Ähnlichkeitswert zwischen zwei Fällen aggregiert. Um den globalen Ähnlichkeitswert eines neuen Falls zu jedem vorhandenen Fall aus der Fallbasis zu bestimmen, muss ein Algorithmus benutzt werden, der alle globalen Ähnlichkeitswerte berechnet. Angenommen, rvi1 und rvi2 seien Instanzen, die durch die Relationswerte rhq und rhf mit dem Anfrage-Fall q und dem Fall f verknüpft wurden. Dann entspricht der lokale Ähnlichkeitswert sim r (rhq , rhf ) für die Ähnlichkeit zwischen den Relationswerten rhq und rhf dem globalen Ähnlichkeitswert für die Ähnlichkeit zwischen den relational verknüpften Instanzen rvi1 und rvi2. Dieser Ähnlichkeitswert wird durch eine Aggregation der lokalen Ähnlichkeitswerte sim (a irvi1 , a irvi 2 ) für die Ähnlichkeit zwischen den Attributswerten a irvi1 und a irvi1 dieser Instanzen mit Hilfe einer gewichteten Summe berechnet. Die Gewichte u i werden durch den Benutzer vorgegeben. sim r ( rhq , rhf )

¦ u I

i

˜ sim a (a irvi1 , a irvi 2 )



(3.21)

i 1

Die Aggregation der lokalen Ähnlichkeitswerte für Attributswerte sim a (a iq , a if ) mit Gewichten u i und der lokalen Ähnlichkeitswerte für Relationswerte sim r ( rhq , rhf ) gemäß Formel 3.21 mit Gewichten u h und dem Wert für die Klassenähnlichkeit sim c (c qh , c fh )

168

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

gemäß Formel 3.20 zum globalen Ähnlichkeitswert sim g (q, f ) basiert auf der folgenden Formel. Durch die multiplikative Verknüpfung mit sim c (c qh , c fh ) wird die ontologiegestützte Ähnlichkeit zwischen den relational verknüpften Instanzen berücksichtigt. Die Gewichte u i und u h werden durch den Benutzer vorgegeben.

sim g (q, f )

¦ u I

i 1

˜ sim a (a iq , a if )  ¦ u h ˜ sim r (rhq , rhf ) ˜ sim c (c qh , c fh ) H

i

(3.22)

h 1

Wenn die Werte in einem neuen Fall oder in einem Fall aus der Fallbasis nicht vollständig vorliegen, muss das Case-Based Reasoning mit einer Unsicherheit umgehen. Bei einem fehlenden Attributswert wird die lokale Ähnlichkeit mit Null angegeben. Sollte ein Relationswert fehlen und somit einer Relation keine Instanz zugewiesen sein, kommt dies einer fehlenden Instanz gleich. Eine fehlende Instanz führt dazu, dass stattdessen die Klasse selbst, also ein abstraktes Objekt mit einer Instanz, dem konkreten Objekt, verglichen werden muss. Der Vergleich zwischen einer Instanz und einer Klasse wird so durchgeführt, dass die Instanz mit allen Instanzen jener Klasse verglichen wird. Anschließend wird eine Instanz mit einem repräsentativen Ähnlichkeitswert aus der Klasse gewählt. Welcher Ähnlichkeitswert repräsentativ ist, hängt davon ab, ob man einen optimistischen, pessimistischen oder durchschnittlichen Ansatz wählt. Beim optimistischen Ansatz wird die Instanz mit dem höchsten Ähnlichkeitswert gewählt, beim pessimistischen die Instanz mit dem niedrigsten Ähnlichkeitswert und beim durchschnittlichen die Instanz mit dem durchschnittlichen Ähnlichkeitswert. In dieser Untersuchung wird der pessimistische Ansatz verfolgt, um die Sicherheit zu bieten, dass die berechnete Ähnlichkeit maximal der Ähnlichkeit entspricht, die vorliegt, wenn unbekannte Attribute Werte besitzen, die zu den kleinstmöglichen lokalen Ähnlichkeitswerten führen. Das Ergebnis des Retrievals für die obersten Fälle des Rankings wird dadurch möglichst sicher. Denn wenn das pessimistische Verfahren gewählt wird, erhalten die Fälle mit unvollständigen Daten tendenziell eine niedrigere Position im Ranking, als wenn das optimistische oder das durchschnittliche Verfahren gewählt wird. Angenommen, der Wertebereich für das Attribut „Euro“ sei von 100 bis 200 definiert. Wenn nun ein unvollständiger Fall, dessen Wert für das Attribut „Euro“ unbekannt ist, mit einem Fall verglichen wird, der für das Attribut „Euro“ den Wert 200 besitzt, dann wird im Rahmen des pessimistischen Verfahrens angenommen, dass der unvollständige Fall für das Attribut „Euro“ den Wert 100 besitzt, da dieser zum Wert 200 den größsten Abstand und somit die geringste Ähnlichkeit besitzt. Im Ranking in Bezug auf die berechneten globalen Ähnlichkeitswerte nimmt der unvollständige Fall somit eine niedri-

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

169

gere Position ein, als wenn dieser nach dem optimistischen oder durchschnittlichen Ansatz behandelt worden wäre. Das Risiko, dass der tatsächliche Ähnlichkeitswert, der bei Bekanntwerden des unbekannten Attributswerts berechnet werden kann, geringer ist als der Ähnlichkeitswert nach dem pessimistischen Verfahren, ist deshalb Null. Die Berechnung des globalen Ähnlichkeitswerts erfolgt für die Ähnlichkeit zwischen dem neuen Fall q, der als Anfrage bezeichnet wird, und allen alten Fällen aus der Fallbasis, die als Fälle F1 bis FN bezeichnet werden mit Fn  F {F1 ,..., FN } und n  {1,..., N} und N

10 . Um den globalen Ähnlichkeitswert für die Ähnlichkeit zwi-

schen einem neuen Fall q und einem alten Fall f mit f  F {F1 ,..., FN } aus der Fallbasis zu berechnen, werden die Fälle als Instanzen der Klasse „Projekt“ betrachtet. Durch die Eingabe eines Schwellenwerts e für den Ähnlichkeitswert zwischen zwei Fällen durch den Benutzer werden nur Fälle aus der Fallbasis berücksichtigt, die eine hinreichende Ähnlichkeit zu dem neuen Fall q aufweisen. Wenn ein globaler Ähnlichkeitswert sim gn (q, f ) nicht kleiner als der vorgegebene Schwellenwert e und nicht kleiner als der bisher größte globale Ähnlichkeitswert ist, wird jener globale Ähnlichkeitswert sim gn (q, f ) in der Menge M gespeichert. Sollte dieser globale Ähnlichkeitswert sim gn (q, f ) größer als die in der Menge M enthaltenen Ähnlichkeitswerte sein, wird die Menge M geleert, bevor der globale Ähnlichkeitswert in der Menge M gespeichert wird. Der Ablauf des Algorithmus wird im Folgenden dargestellt: [1]

Der Algorithmus startet.

[2]

Zunächst erfolgt die Eingabe des neuen Falls q.

[3]

Die Eingabe des Schwellenwerts e erfolgt.

[4]

Die Eingabe der Gewichte u i und u h erfolgt.

[5]

Die Menge M wird initialisiert. Es gilt: M : {} .

[6]

Der globale Ähnlichkeitswert, der beim ersten Durchlauf der Schritte [25] und [26] benötigt wird, wird initialisiert. Es gilt: sim 0g (q, F0 ) : 0 .

[7]

Dem Index n für die alten Fälle aus der Fallbasis wird der Wert 1 zugewiesen.

[8]

Der Variablen N wird als Wert die Anzahl der alten Fälle aus der Fallbasis zugewiesen. Da in dieser Untersuchung eine Fallbasis mit 10 Fällen genutzt wird, gilt hier: N : 10 .

[9]

Die Variable f wird mit einem beliebigen Fall aus der Menge F belegt. Es gilt: f : Fn mit Fn  F .

170

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

[10]

Aus der Menge F wird der Fall entfernt, mit dem die Variable f belegt wurde. Es gilt: F : F \ f .

[11]

Die globale Ähnlichkeit sim gn (q, f ) wird mit dem Wert 0 vorbelegt. Es gilt: sim gn (q, f ) : 0 .

[12] [13]

Dem Index i für die Attributswerte einer Instanz wird der Wert 1 zugewiesen. Der Variablen I wird als Wert die Anzahl der Attributswerte der beiden zu vergleichenden Instanzen zugewiesen.

[14]

Die Attributswerte a iq und a if werden eingegeben.

[15]

Die lokalen Ähnlichkeitswerte sim a (a iq , a if ) für die Ähnlichkeit zwischen den Attributswerten a iq und a if werden zum globalen Ähnlichkeitswert sim gn (q, f ) aggregiert. Diese Aggregation, bei der es sich um ein Bottom-Up-Verfahren handelt, wird durchgeführt, indem in jeder Iterationsschleife nach Erhöhung des Index i der jeweilige lokale Ähnlichkeitswert sim a (a iq , a if ) unter Berücksichtigung des Gewichts u i mit u i  [0,1] zum bisher berechneten, vorläufigen globalen Ähnlichkeitswert sim gn (q, f ) hinzuaddiert wird. Der lokale Ähnlichkeitswert sim a (a iq , a if ) für die Ähnlichkeit zwischen den Attributswerten a iq und a if wird mit Hilfe des passenden Ähnlichkeitsmaßstabs (siehe Kapitel 3.2.3.4) berechnet. Es gilt: sim gn (q, f ) : sim gn (q, f )  u i ˜ sim a (a iq , a if ) .

[16]

Der Index i für die Attributswerte wird um den Wert 1 erhöht.

[17]

Hier kann der Algorithmus in eine von zwei verschiedenen Richtungen verzweigen. Wenn die Bedingung i d I erfüllt ist, sind weitere zu vergleichende Attributswerte vorhanden und es wird mit dem Schritt [14] fortgefahren. Wenn diese Bedingung nicht erfüllt ist, sind keine weiteren zu vergleichenden Attributswerte vorhanden und es wird mit dem Schritt [18] fortgefahren.

[18]

Dem Index h für die Relationswerte einer Instanz wird der Wert 1 zugewiesen.

[19]

Der Variablen H wird als Wert die Anzahl der Relationswerte der beiden zu vergleichenden Instanzen zugewiesen.

[20]

Die Relationswerte rhq und rhf werden eingegeben.

[21]

Die lokalen Ähnlichkeitswerte sim r ( rhq , rhf ) für die Ähnlichkeit zwischen den Relationswerten rhq und rhf werden analog zur Aggregation der lokalen Ähnlichkeitswerte sim a (a iq , a if ) mit einem Bottom-Up-Verfahren zum globalen Ähnlichkeits-

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

171

wert sim gn (q, f ) aggregiert. Bei der Aggregation der lokalen Ähnlichkeitswerte für die Ähnlichkeit zwischen den Relationswerten werden neben dem Gewicht u h mit u h  [0,1] zusätzlich die Positionen der relational verknüpften Instanzen innerhalb

der Klassenhierarchie der Ontologie berücksichtigt. Eine Ähnlichkeit zwischen relational verknüpften Instanzen aus demselben Zweig der Klassenhierarchie wird durch den Ähnlichkeitswert sim c (c qh , c fh ) für die Ähnlichkeit zwischen den Klassen der relational verknüpften Instanzen verstärkt und eine Ähnlichkeit zwischen Instanzen aus verschiedenen Zweigen der Klassenhierarchie wird durch diesen Ähnlichkeitswert abgeschwächt. Der lokale Ähnlichkeitswert sim a (a iq , a if ) für die Ähnlichkeit zwischen den Relationswerten rhq und rhf wird mit Hilfe des passenden Ähnlichkeitsmaßstabs (siehe Kapitel 3.2.3.4) berechnet. Es gilt: sim gn (q, f ) : sim gn (q, f )  u h ˜ sim r ( rhq , rhf ) ˜ sim c (c qh , c fh ) .

[22]

Der Index h für die Relationswerte wird um den Wert 1 erhöht.

[23]

Wenn die Bedingung h d H erfüllt ist, sind weitere zu vergleichende Relationswerte vorhanden und es wird mit dem Schritt [20] fortgefahren. Wenn diese Bedingung nicht erfüllt ist, sind keine weiteren zu vergleichenden Relationswerte vorhanden und es wird mit dem Schritt [24] fortgefahren.

[24]

Wenn der globale Ähnlichkeitswert sim gn (q, f ) für die Ähnlichkeit zwischen dem neuen Fall q und dem alten Fall f aus der Fallbasis unter dem Schwellenwert e für hinreichende Ähnlichkeit liegt, also die Bedingung sim gn (q, f )  e erfüllt ist, wird mit dem Schritt [29] fortgefahren. Sollte die Bedingung nicht erfüllt sein, wird mit dem Schritt [25] fortgefahren.

[25]

Wenn die Bedingung sim gn (q, f )  max (sim gp (q, Fp )) erfüllt ist , also der globale p{0 ,..., n 1}

n g

Ähnlichkeitswert sim (q, f ) für die Ähnlichkeit zwischen dem neuen Fall q und dem alten Fall f aus der Fallbasis kleiner als alle bisher berechneten globalen Ähnlichkeitswerte für die Ähnlichkeit zwischen dem neuen Fall q und den alten Fällen

F1 bis Fn ist, wird mit dem Schritt [29] fortgefahren. Sollte die Bedingung nicht erfüllt sein, wird mit dem Schritt [26] fortgefahren. [26]

Wenn die Bedingung sim gn (q, f ) ! max (sim gp (q, Fp )) erfüllt ist, also der globale p{0 ,..., n 1}

n g

Ähnlichkeitswert sim (q, f ) für die Ähnlichkeit zwischen dem neuen Fall q und

172

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen dem alten Fall f aus der Fallbasis größer als alle bisher berechneten globalen Ähnlichkeitswerte für die Ähnlichkeit zwischen dem neuen Fall q und den alten Fällen

F1 bis Fn ist, wird mit dem Schritt [27] fortgefahren. Sollte die Bedingung nicht erfüllt sein, wird mit dem Schritt [28] fortgefahren. [27]

Dieser Schritt wird ausgeführt, wenn der globale Ähnlichkeitswert sim gn (q, f ) aus der aktuellen Iteration des Algorithmus der bisher größte Wert aller berechneten globalen Ähnlichkeitswerte ist. Die Menge M, die die maximalen globalen Ähnlichkeitswerte beinhalten soll, wird geleert. Es gilt: M : {} .

[28]

Die Menge M wird mit der Menge vereinigt, die den vorläufig maximalen globalen Ähnlichkeitswert beinhaltet. Es gilt: M : M ‰ {sim gn (q, f )} .

[29]

Der Index n für die Fälle aus der Fallbasis wird um den Wert 1 erhöht.

[30]

Wenn die Bedingung n d N erfüllt ist, sind weitere zu vergleichende alte Fälle aus der Fallbasis vorhanden und es wird mit dem Schritt [9] fortgefahren. Wenn diese Bedingung nicht erfüllt ist, sind keine weiteren zu vergleichenden Fälle vorhanden und es wird mit dem Schritt [31] fortgefahren.

[31]

Die Menge M, die jetzt die endgültig maximalen globalen Ähnlichkeitswerte enthält, wird ausgegeben. Die Menge M enthält mindestens einen maximalen globalen Ähnlichkeitswert mit hinreichender Ähnlichkeit oder ist leer, wenn kein Ähnlichkeitswert hinreichend groß gewesen ist und stets sim gn (q, f )  e gegolten hat. Wenn zwei oder mehr Elemente in der Menge enthalten sind, bedeutet dies, dass zwei oder mehr Fälle mit dem gleichen maximalen globalen Ähnlichkeitswert existieren. Die Selektion genau eines ähnlichsten Falls muss dann von weiteren Indikatoren, z.B. dem Alter des Falls, abhängig gemacht werden. Das Fallresultat des selektierten Falls kann entweder direkt auf den aktuellen Fall übertragen oder zuvor mit Hilfe spezieller Regeln angepasst werden.378 Die Erstellung von Regeln zur Anpassung von Fällen kann in einer anschließenden Untersuchung betrachtet werden.

[32]

Der Algorithmus stoppt.

Der Ablauf des Algorithmus zur Ähnlichkeitsmessung zwischen Fällen wird im folgenden Flussdiagramm auf Basis der Notation von DIN-Norm 66001 379 grafisch dargestellt.

378

Vgl. KURBEL/DORNHOFF (1993), S. 1060.

379

Vgl. DIN 66001 (1983).

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

Abbildung 46: Ablauf des Algorithmus

173

174

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

3.2.3.6 Erstellung eines Prototyps für ontologiegestütztes Case-Based Reasoning

Die Erstellung des Prototyps besteht aus der Eingabe der Ontologie und der projektbeschreibenden Fälle in Protégé sowie der Konfiguration der Ähnlichkeitsmaßstäbe und des Algorithmus in MyCBR. Der erste Schritt wurde bereits im Rahmen der Ontologieerstellung durchgeführt. Der zweite Schritt wird in diesem Kapitel im Detail erläutert. Die grundlegende Definition der Ähnlichkeitsmaßstäbe erfolgte bereits im Kapitel 3.2.3.4. Die Zuordnung der Ähnlichkeitsmaßstäbe ist abhängig vom Wertebereich und von der Kardinalität der Attribute. Zum Beispiel ist das Attribut „Projekttyp“ der Klasse „Projekt“ ein freies Textfeld. Hier wird ein Ähnlichkeitsmaßstab für symbolische Werte zugeordnet. Symbolische Werte können mit Hilfe einer Tabelle gemäß Formel 3.17 oder einer Taxonomie gemäß Formel 3.18 verglichen werden. Eine Tabelle wird benutzt, wenn eine Hierarchie im Wertebereich eine geringe Rolle spielt oder nicht vorhanden ist. Die Taxonomie wird genutzt, wenn die Hierarchie die Hauptrolle bei der Bestimmung von Ähnlichkeiten bildet. Beim Attribut „Projekttyp“ wird eine Tabelle genutzt, da eine Hierarchie in den Attributswerten, die in der Fallbasis für das Attribut „Projekttyp“ vorkommen, nicht vorhanden ist. Das Attribut „Name“ dient lediglich der Bezeichnung des entsprechenden Projekts für externe Zwecke. Im Prototyp selbst wird das Attribut nicht genutzt und erhält daher auch keinen Ähnlichkeitsmaßstab zugewiesen. Die Zuordnung der Ähnlichkeitsmaßstäbe zu den anderen Attributen im Betrachtungsbereich erfolgt in der folgenden Tabelle:

Klasse

Projekt

Betriebssystem

Anwendung

Hardware

Attribut

Ähnlichkeitsmaßstab

Name

nicht vorhanden

Projekttyp

Tabelle

Euro

Abstand

Personentage

Abstand

Betriebsystemname

Taxonomie

Familie

Tabelle

Anwendungsname

Tabelle

Anwendungsbereich

Tabelle

Modell

Taxonomie

Typ

Tabelle

Tabelle 50: Zuordnung der Ähnlichkeitsmaßstäbe

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

175

Die Ähnlichkeitsmaßstäbe für den Abstand zwischen zwei Attributswerten a iq und a if wurden durch Formel 3.14 definiert. Wenn Tabellen als Ähnlichkeitsmaßstäbe genutzt werden, muss jedes Tabellenfeld mit dem Wert tab (a iq , a if ) belegt werden, bei dem der Spaltenindex dem Attributswert a iq und der Zeilenindex dem Attributswert a if entspricht. Wenn Taxonomien als Ähnlichkeitsmaßstäbe genutzt werden, muss für jeden Knoten der Taxonomie, der untergeordnete Knoten besitzt, der Wert tax (a iq , a if ) bestimmt werden. Diese Schritte werden in der Benutzeroberfläche von MyCBR durchgeführt. Dabei wird der symmetrische Modus für alle Definitionen genutzt. Die Ähnlichkeit zwischen den Attributswerten a iq und a if ist demnach gleich der Ähnlichkeit zwischen den Attributswerten a if und a iq . Für das Attribut „Projekttyp“ der Klasse „Projekt“ wird zunächst im Slot-Editor der Value-Type „Symbol“ ausgewählt. Anschließend wird im Similarity-Measure-Editor als Similarity Mode „Table“ ausgewählt. Die Tabelle enthält die Ergebnisse von Paarvergleichen. Es sind Werte von Null bis Eins möglich. Null bedeutet keine Ähnlichkeit und Eins bedeutet Gleichheit. In der Tabelle ist auf der Diagonalen eine Eins einzutragen, da hier jeweils jeder Wert mit sich selbst verglichen wird. Gespiegelt entlang der Diagonalen ist jeweils der gleiche Wert einzutragen. Denn wenn der Attributswert a iq zum Attributswert a if eine Ähnlichkeit mit Wert x besitzt mit x  >0,1@ , dann besitzt der Attributswert a if zum Attributswert a iq ebenfalls eine Ähnlichkeit mit Wert x. Der Ähnlichkeitswert für die Ähnlichkeit zwischen „Konfiguration“ und „Installation“ wird mit 0,2 angegeben, da eine Konfiguration meist Teil einer Installation ist, aber in den seltensten Fällen eine Installation zwingend mit sich führt. Der Ähnlichkeitswert für die Ähnlichkeit zwischen „Installation“ und „Migration“ wird mit 0,7 angegeben, da eine Installation Hauptbestandteil einer Migration sein kann, aber nicht zwingend sein muss. Die Arbeitsschritte bei einer Installation und einer Migration können zum Teil gleich sein oder sich überschneiden. Der Ähnlichkeitswert für die Ähnlichkeit zwischen „Konfiguration“ und „Migration“ wird mit 0,5 angegeben, da eine Konfiguration meist Teil einer Migration ist. Eine Konfiguration kann unter Umständen zu einer Migration führen.

176

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

Attributswert

Installation

Konfiguration

Installation

Migration

1

0,2

0,7

Konfiguration

0,2

1

0,5

Migration

0,7

0,5

1

Tabelle 51: Ähnlichkeitstabelle für das Attribut „Projekttyp“

Für das Attribut „Euro“ der Klasse „Projekt“ wird zunächst im Slot-Editor der Value-Type „Integer“ ausgewählt. Anschließend wird im Similarity-Measure-Editor als Similarity Mode „Standard“ und als Distance Function „Difference“ ausgewählt. Für die Berechnung des Abstands wird die Formel 3.14 genutzt. max d ist in dieser Wertemenge 452000 – 10100 = 441900. Dies führt zu folgenden Ähnlichkeitswerten:

452000

12200

65000

10100

37500

382000

34000

290000

130000

20000

452000

Wert

1,000

0,005

0,124

0,000

0,062

0,842

0,054

0,633

0,271

0,022

12200

0,005

1,000

0,881

0,995

0,943

0,163

0,951

0,371

0,733

0,982

65000

0,124

0,881

1,000

0,876

0,938

0,283

0,930

0,491

0,853

0,898

10100

0,000

0,995

0,876

1,000

0,938

0,158

0,946

0,367

0,729

0,978

37500

0,062

0,943

0,938

0,938

1,000

0,220

0,992

0,429

0,791

0,960

382000

0,842

0,163

0,283

0,158

0,220

1,000

0,212

0,792

0,430

0,181

34000

0,054

0,951

0,930

0,946

0,992

0,212

1,000

0,421

0,783

0,968

290000

0,633

0,371

0,491

0,367

0,429

0,792

0,421

1,000

0,638

0,389

130000

0,271

0,733

0,853

0,729

0,791

0,430

0,783

0,638

1,000

0,751

20000

0,022

0,982

0,898

0,978

0,960

0,181

0,968

0,389

0,751

1,000

Tabelle 52: Ähnlichkeitstabelle für das Attribut „Euro“

Für das Attribut „Personentage“ der Klasse „Projekt“ wird zunächst im Slot-Editor der Value-Type „Integer“ ausgewählt. Anschließend wird im Similarity-Measure-Editor als Similarity Mode „Standard“ und als Mode „Difference“ ausgewählt. Die Berechnung des Abstands wurde durch die Formel 3.14 definiert. max d ist in dieser Wertemenge 504 – 12 = 492. Dies führt zu folgenden Ähnlichkeitswerten:

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

177

320

16

77

12

45

504

55

250

110

28

320

1,000

0,382

0,506

0,374

0,441

0,626

0,461

0,858

0,573

0,407

16

0,382

1,000

0,876

0,992

0,941

0,008

0,921

0,524

0,809

0,976

77

0,506

0,876

1,000

0,868

0,935

0,132

0,955

0,648

0,933

0,900

12

0,374

0,992

0,868

1,000

0,933

0,000

0,913

0,516

0,801

0,967

45

0,441

0,941

0,935

0,933

1,000

0,067

0,980

0,583

0,868

0,965

504

0,626

0,008

0,132

0,000

0,067

1,000

0,087

0,484

0,199

0,033

Wert

55

0,461

0,921

0,955

0,913

0,980

0,087

1,000

0,604

0,888

0,945

250

0,858

0,524

0,648

0,516

0,583

0,484

0,604

1,000

0,715

0,549

110

0,573

0,809

0,933

0,801

0,868

0,199

0,888

0,715

1,000

0,833

28

0,407

0,976

0,900

0,967

0,965

0,033

0,945

0,549

0,833

1,000

Tabelle 53: Ähnlichkeitstabelle für das Attribut „Personentage“

Für das Attribut „Betriebssystemname“ der Klasse „Betriebssystem“ werden der ValueType „Symbol“ und der Similarity Mode „Taxonomy“ ausgewählt. Die Werte „Microsoft_ Windows_Vista“ und „Microsoft_Windows_XP“ sind dem Knoten „Microsoft_ Windows“ untergeordnet, da beide Betriebssysteme vom selben Hersteller entwickelt wurden und Windows 2003 Server eine Servervariante und Windows XP eine Clientvariante des Betriebssystems Windows ist. „AIX_4.3.3“ und „Sun_Solaris_10“ sind dem Knoten „Unix“ untergeordnet, da diese Betriebssysteme auf dem Unix Kernel basieren. „Integrity_Linux“, „Red_Hat_Linux_9“ und „Suse_Linux_10“ sind dem Knoten „Linux“ untergeordnet, da es sich bei diesen Betriebssystemen um Linux handelt. Da Linux eine Spezialisierung von Unix ist, ist der Knoten „Linux“ dem Knoten „Unix“ untergeordnet. Für alle in der Taxonomie enthaltenen Knoten, die untergeordnete Knoten besitzen, können Ähnlichkeitswerte angegeben werden. Diese Ähnlichkeitswerte definieren die Ähnlichkeit zwischen den jeweiligen direkt untergeordneten Knoten. Ein Ähnlichkeitswert kann mit einer Zahl von Null bis Eins belegt werden. Ein übergeordneter Knoten darf maximal den höchsten Ähnlichkeitswert der jeweils untergeordneten Knoten besitzen, da die untergeordneten Knoten Spezialisierungen sind. Für die Ähnlichkeit zwischen dem Knoten „Windows“ und dem Knoten „Unix“ wird der Wert 0,2 angegeben. Daher erhält der gemeinsame übergeordnete Knoten den Ähnlichkeitswert 0,2 zugewiesen. Für die Ähnlichkeit zwischen den untergeordneten Knoten zu „Microsoft_Windows“ wird der Wert 0,8 angegeben, da die Betriebssysteme bis auf einige Serverfunktionalitäten sehr ähnlich sind. Für die Ähnlichkeit zwischen den untergeordneten Knoten zu „Unix“ wird der Wert 0,5 angegeben, da die Kernel zwar ähnlich sind, aber dennoch viele Unterschiede zwischen Unix-Betriebssystemen existieren können. Für die Ähnlichkeit zwischen den untergeordne-

178

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

ten Knoten zu „Linux“ wird der Wert 0,6 angegeben, da die es sich bei den betroffenen Betriebssystemen um Spezialisierungen von Unix-Systemen handelt, die weiterhin große Unterschiede besitzen können. Der Knoten „Linux“ besitzt drei untergeordnete Knoten. Der Ähnlichkeitswert 0,6 ist immer gültig, wenn zwei beliebige Knoten von diesen drei vorhandenen Knoten miteinander verglichen werden. Es sind drei symmetrische Vergleiche möglich: „Red_Hat_Linux_9“ mit „Suse_Linux_10“, „Red_Hat_Linux_9“ mit „Integrity_Linux“ und „Suse_Linux_10“ mit „Integrity_Linux“. In der folgenden Abbildung 47 ist die Taxonomie mit den Ähnlichkeitswerten dargestellt. Betriebssystemname [0,2] Microsoft_Windows [0,8] Microsoft_Windows_Vista Microsoft_Windows_XP Unix [0,5] AIX_4.3.3 Sun_Solaris_10 Linux [0,6] Red_Hat_Linux_9 Suse_Linux_10 Integrity_Linux

Legende:

Relation „istEin“: Klasse: Instanz: Ähnlichkeitswert: [ ]

Abbildung 47: Taxonomie für das Attribut „Betriebssystemname“

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

179

Für das Attribut „Familie“ der Klasse „Betriebssystem“ werden der Value-Type „Symbol“ und der Similarity Mode „Table“ ausgewählt. Da es sich lediglich um zwei Werte handelt, ist es nicht sinnvoll, eine Taxonomie zu erstellen. Die beiden Werte können direkt miteinander verglichen werden, indem sie in einer Tabelle aufgeführt werden. Windows und Unix sind insofern ähnlich, als es sich um Betriebssysteme handelt, die jedoch grundsätzlich anders programmiert sind. Sie haben z.B. unterschiedliche Kernel, Dateisysteme und Benutzeroberflächen. Für die Ähnlichkeit zwischen dem Attributswert „Windows“ und dem Attributswert „Unix“ wird daher der Wert 0,2 angegeben.

Attributswert

Unix Windows

Unix

Windows 1

0,2

0,2

1

Tabelle 54: Ähnlichkeitstabelle für das Attribut „Familie“

Für das Attribut „Anwendungsname“ der Klasse „Anwendung“ werden der Value-Type „Symbol“ und der Similarity Mode „Table“ ausgewählt. Die Attributswerte besitzen keine hinreichende hierarchische Struktur zur Einordnung in eine Taxonomie. Eine Tabelle ist deshalb eher geeignet. Die Attributswerte, die eine Ähnlichkeit untereinander besitzen, sind „Börsensysteme“ und „Sungard_Global_One“, da es sich hierbei um Anwendungen für den Handel von Wertpapieren handelt. Für die Ähnlichkeit zwischen diesen Attributswerten wird der Wert 0,2 angegeben. Außerdem sind „Internet_Explorer“ und „Webapplikation“ ähnlich, da beide Anwendungen für die Kommunikation über Webseiten genutzt werden. Der „Internet_Explorer“ wird zum Abruf und die „Webapplikation“ wird zur Bereitstellung von Webseiten genutzt. Für die Ähnlichkeit zwischen diesen Attributswerten wird der Wert 0,3 angegeben.

180

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

Tabelle 55: Ähnlichkeitstabelle für das Attribut „Anwendungsname“

Für das Attribut „Anwendungsbereich“ der Klasse „Anwendung“ werden der Value-Type „Symbol“ und der Similarity Mode „Table“ ausgewählt. Der Ähnlichkeitswert für die Ähnlichkeit zwischen „Handel“ und „Projekte“ wird mit Null angegeben, da die Eigenschaften einer Handelssoftware keine Gemeinsamkeiten mit den Eigenschaften einer Projektmanagementsoftware aufweisen. Der Ähnlichkeitswert für die Ähnlichkeit zwischen „Handel“ und „Netzwerk“ wird mit Null angegeben, da eine Handelssoftware keine Gemeinsamkeiten mit einer Netzwerksoftware aufweist. Der Ähnlichkeitswert für die Ähnlichkeit zwischen „Handel“ und „Internet“ wird mit Null angegeben, da eine Handelssoftware keine Gemeinsamkeiten mit einer Internetsoftware aufweist. Der Ähnlichkeitswert für die Ähnlichkeit zwischen „Projekte“ und „Netzwerk“ wird mit Null angegeben, da eine Projektmanagementsoftware keine Gemeinsamkeiten mit einer Netzwerksoftware aufweist. Der Ähnlichkeitswert für die Ähnlichkeit zwischen „Projekte“ und „Internet“ wird mit Null angegeben, da eine Projektmanagementsoftware keine Gemeinsamkeiten mit einer Internetsoftware aufweist. Der Ähnlichkeitswert für die Ähnlichkeit zwischen „Netzwerk“ und „Internet“ wird mit 0,6 angegeben, da eine Internet-Anwendung zur Bereitstellung eines Zugriffs über das Internet zum Teil Netzwerkfunktionalitäten integriert oder voraussetzt. Z.B. kann die Anwendung über den TCP-Port 80 Netzwerkverbindungen aufbauen und somit eine Netzwerkverbindung zu der Internet-Anwendung erlauben.

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen Attributswert

Handel

Netzwerk

Internet

181

Projekte

Handel

1

0

0

0

Netzwerk

0

1

0,6

0

Internet

0

0,6

1

0

Projekte

0

0

0

1

Tabelle 56: Ähnlichkeitstabelle für das Attribut „Anwendungsbereich“

Für das Attribut „Modell“ der Klasse „Hardware“ und somit auch für die Unterklassen „Client“ und „Server“ werden der Value-Type „Symbol“ und der Similarity Mode „Taxonomy“ ausgewählt. Die Werte „Samsung_X50“ und „Samsung_X20“ sind dem Knoten „Samsung_Notebook“ zugeordnet, da es sich bei beiden um Notebooks des Herstellers SAMSUNG handelt. „Asus_P2“ und „IBM_iSeries“ sind Systeme ohne weitere Gemeinsamkeiten. Die Werte „Dell_PowerEdge“ und „Dell_Optiplex“ sind dem Knoten „Dell_ System“ zugeordnet, da es sich bei beiden um Systeme des Herstellers DELL handelt. Alle bisher aufgeführten Werte werden dem Knoten „physikalisches_System“ untergeordnet. „VMWare_ESX“ ist ein virtuelles System, das sich grundsätzlich beliebige Hardware mit anderen virtuellen Systemen teilt. Der Knoten „VMWare_ESX“ wird daher dem Knoten „virtuelles_System“ untergeordnet. Analog zum Attribut „Betriebssystemname“ können für alle in der Taxonomie enthaltenen Knoten, die Unterknoten besitzen, Ähnlichkeitswerte angegeben werden. Der Ähnlichkeitswert für die Ähnlichkeit zwischen den untergeordneten Knoten zu „Modell“ wird mit 0,2 angegeben, da jedes System als Gesamtheit von grundsätzlich ähnlichen Bestandteilen, wie Betriebssystem, Treiber und Anwendungen, angesehen werden kann. Allerdings benötigt ein physikalisches System separate Hardware, während ein virtuelles System neben anderen virtuellen Systemen auf derselben Hardware betrieben werden kann. Der Ähnlichkeitswert für die Ähnlichkeit zwischen den untergeordneten Knoten zu „physikalisches_System“ wird mit 0,5 angegeben, da jedes physikalische System Hardwarekomponenten aus denselben Kategorien benötigt, z.B. Gehäuse und CPU. Innerhalb der Kategorien können dennoch große Unterschiede bestehen, z.B. im Design der Gehäuse und der Architektur der CPU. Der Ähnlichkeitswert für die Ähnlichkeit zwischen den untergeordneten Knoten zu „Samsung_Notebook“ wird mit 0,8 angegeben, da die Notebooks vom selben Hersteller stammen und im Design sehr ähnlich sind. Das „Samsung_X50“ ist der Nachfolger des „Samsung_X20“. Der Ähnlichkeitswert für die Ähnlichkeit zwischen den untergeordneten Knoten zu „Dell_System“ wird mit 0,6 angege-

182

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

ben, da diese Systeme ebenfalls vom selben Hersteller hergestellt wurden. Unterschiede resultieren aus abweichenden Modellen, die verschiedene Einsatzzwecke haben. Der Ähnlichkeitswert für die Ähnlichkeit des untergeordneten Knotens „virtuelles_System“ zu sich selbst wird mit Eins angegeben, da nur ein untergeordneter Knoten vorhanden ist und dieser zu sich selbst gleich ist. In der folgenden Abbildung 48 ist die Taxonomie mit den Ähnlichkeitswerten dargestellt.

Modell [0,2] physikalisches_System [0,5] Samsung_Notebook [0,8] Samsung_X20 Samsung_X50 Asus_P2 IBM_iSeries Dell_System [0,6] Dell_PowerEdge Dell_Optiplex virtuelles_System [1] VMWare_ESX

Legende:

Relation „istEin“: Klasse: Instanz: Ähnlichkeitswert: [ ]

Abbildung 48: Taxonomie für das Attribut „Modell“

Für das Attribut „Typ“ der Klassen „Client“ und „Server“ werden der Value-Type „Symbol“ und der Similarity Mode „Table“ ausgewählt. Der Ähnlichkeitswert für die Ähnlichkeit zwischen „Virtuell“ und den anderen Attributswerten wird jeweils mit Null angegeben, da ein virtuelles System keine eigene Hardware besitzt, sondern auf jeder beliebigen Hardware laufen kann, die mit anderen virtuellen Systemen geteilt wird. Der Ähnlich-

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

183

keitswert für die Ähnlichkeit zwischen „Notebook“ und „Desktop“ wird mit 0,5 angegeben, da Notebooks auch als Desktop-Rechner verwendet werden können. Der grundsätzliche Unterschied zwischen einem Notebook und einem Desktop-Rechner besteht vorrangig in der Mobilität. Notebooks können auf Grund ihrer geringeren Größe und ihres geringeren Gewichts einfacher transportiert werden. Zwischen „Notebook“ und „Rack“ liegen größere Unterschiede, da sich hier die meisten Hardwarekomponenten stark unterscheiden und ein Rack für einen festen Einbau vorgesehen ist. Der Ähnlichkeitswert wird daher mit 0,2 angegeben. Zwischen „Notebook“ und „Tower“ ist der Ähnlichkeitswert gering, da die Hardware des Notebooks für eine mobile Verwendung konzipiert wurde und der Tower immobil verwendet wird. Der Ähnlichkeitswert beträgt 0,3. Zwischen „Rack“ und „Notebook“ oder „Desktop“ liegen große Unterschiede, da sich hier die meisten Hardwarekomponenten stark unterscheiden. Der Ähnlichkeitswert wird daher jeweils mit 0,2 angegeben. Die Ähnlichkeit zwischen „Desktop“ und „Tower“ besitzt einen hohen Ähnlichkeitswert mit 0,8, da die meisten Bestandteile der Hardware ähnlich oder gleich sein können, z.B. das Gehäuse und Netzteil. Der Ähnlichkeitswert für die Ähnlichkeit zwischen „Rack“ und „Tower“ wird mit 0,6 angegeben, da sich die Systeme primär in der Form des Gehäuses unterscheiden. Ein Rack ist für den Einbau in einen 19-Zoll-Schrank konzipiert, während ein Tower beliebig auf eine freie Fläche gestellt werden kann.

Attributswert

Virtuell

Notebook

Desktop

Rack

Tower

Virtuell

1

0

0

0

0

Notebook

0

1

0,5

0,2

0,3

Desktop

0

0,5

1

0,2

0,8

Rack

0

0,2

0,2

1

0,6

Tower

0

0,3

0,8

0,6

1

Tabelle 57: Ähnlichkeitstabelle für das Attribut „Typ“

Die Relationen „betrifftHardware“, „betrifftBetriebssystem“ und „betrifftAnwendung“ verknüpfen die Klasse „Projekt“ mit den Klassen „Hardware“, „Betriebssystem“ und „Anwendung“ oder deren Unterklassen. Die drei Relationen werden im Slot-Editor definiert und erhalten als Wertebereich „Instance“ und als Domäne die Klasse „Projekt“ zugewiesen. Anschließend wird im Editor mittels dieser Relationen zu jeder Instanz der Klasse

184

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

„Projekt“ die jeweils relational verknüpfte Instanz aus den Klassen „Hardware“, „Betriebssystem“ oder „Anwendung“ oder deren Unterklassen zugeordnet. Nachdem in MyCBR die Ähnlichkeitsmaßstäbe für die Berechnung der lokalen Ähnlichkeitswerte für die Ähnlichkeit zwischen Attributs- und Relationswerten definiert wurden, muss im Folgenden der Algorithmus definiert werden. Der Algorithmus beinhaltet eine Funktion zur Aggregation von lokalen Ähnlichkeitswerten zu globalen Ähnlichkeitswerten mit Hilfe einer gewichteten Summe. 380 Die lokalen Ähnlichkeitswerte der Relationswerte werden mit dem Ähnlichkeitswert für die Ähnlichkeit zwischen den betroffenen Klassen multipliziert, wenn die zu vergleichenden Instanzen aus unterschiedlichen Klassen stammen. Die Ähnlichkeit zwischen den betroffenen Klassen wird durch sim c (c qh , c fh ) aus Formel 3.20 repräsentiert.

Anschließend werden die Gewichte festgelegt. Da das Attribut „Name“ nicht für die Ähnlichkeitsberechnung verwendet wird, erhält es ein Gewicht von Null. Das Attribut „Projekttyp“ erhält ein doppelt so hohes Gewicht wie die anderen Attribute, da es die höchste Relevanz für die Beschreibung des Inhalts eines Projekts besitzt. Die restlichen Attribute erhalten ein Gewicht von 1/7, da diese Attribute als gleich wichtig betrachtet werden. Die Relationen „istGrundlageVon“, „istBestandteilVon“ und „istEin“ erhalten ein Gewicht von Null, da diese Relationen durch die Ontologie umgesetzt werden und daher nicht explizit im Rahmen der Aggregation von Ähnlichkeitswerten gewichtet werden. In der Tabelle 58 auf der folgenden Seite sind die Slots mit ihren Gewichten aufgeführt und mittels übergeordneter Klassen gruppiert.

380

Die gewichtete Summe wurde hier für die Aggregation der lokalen Ähnlichkeitswerte gewählt, da sie die gebräuchlichste Methode zur Attribut-basierten Berechnung der Ähnlichkeitswerte für die Ähnlichkeit zwischen Fällen ist, mit Skalierungsproblemen umgehen (die Gewichtung kann dazu genutzt werden, unterschiedlich skalierte Summanden auf dasselbe Skalenniveau anzuheben) und intuitiv gedeutet werden kann. Vgl. PAL/SHIU (2004), S. 75 u. PAL/DILLON/YEUNG (2000), S. 42. PERNER empfiehlt die Verwendung der gewichteten Summe beim Case-Based Reasoning speziell auf Grund der schnellen und unproblematischen Anwendbarkeit. Vgl. PERNER (2008), S. 51. Dies ist jedoch auch kritisch zu betrachten, da Probleme in Form einer willkürlichen Festlegung von Gewichten oder einer Substituierbarkeit auftreten können. Dies muss bei der Anwendung der gewichteten Summe bewusst akzeptiert werden.

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen Klasse

Projekt

Slot

Gewicht

Name

0/7

Projekttyp

2/7

Euro

1/7

Personentage

1/7

betrifftHardware

1/7

betrifftBetriebssystem

1/7

betrifftAnwendung

1/7

System

istGrundlageVon

0

Hardware

istBestandteilVon

0

Software

istBestandteilVon

0

Anwendung

istEin

0

Betriebssystem

Client

Server

Betriebssystemname

1/2

Familie

1/2

istEin

0

Modell

1/2

Typ

1/2

istEin

0

Modell

1/2

Typ

1/2

istEin Individualanwendung

Anwendungsname

1/2

Anwendungsbereich

1/2

istEin

Standardanwendung

0

0

Anwendungsname

1/2

Anwendungsbereich

1/2

istEin Tabelle 58: Gewichtung der lokalen Ähnlichkeiten

0

185

186

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

Die ontologiegestützte Berechnung der Ähnlichkeitswerte wird mit Hilfe der Vererbung von Ähnlichkeiten durchgeführt. Hier wird analog zur taxonomischen Ähnlichkeitsberechnung jeweils die Ähnlichkeit zwischen den Klassen des betrachteten Zweigs der Ontologie festgelegt. Die Ähnlichkeit zwischen zwei Klassen wird durch den Ähnlichkeitswert bestimmt, der an der gemeinsamen übergeordneten Klasse in der Ontologie hinterlegt ist. Für jede Klasse wird ein Ähnlichkeitswert zwischen Null und Eins vergeben. Null bedeutet keine Ähnlichkeit und Eins bedeutet Gleichheit. Die Ontologie kann in MyCBR hierarchisch strukturiert werden, indem die Klassen mittels Drag&Drop angeordnet werden. In der Hierarchie der Ontologie darf der Ähnlichkeitswert einer Klasse maximal so groß sein wie der höchste Ähnlichkeitswert, der an den Unterklassen dieser Klasse in der Ontologie hinterlegt wurde. Der Ähnlichkeitswert zwischen zwei Klassen ist durch die Formel 3.20 definiert. k wird gemäß Formel 3.19 danach berechnet, wie viele Attribute die Instanzen aus den beiden zu vergleichenden Klassen gemeinsam haben im Verhältnis zu den insgesamt vorhandenen Attributen. Außerdem wird der Reziprokwert der Anzahl der Knoten berücksichtigt, die in der Hierarchie der Ontologie auf dem Weg von der am weitesten entfernten Instanz zur gemeinsamen übergeordneten Klasse liegen. Z.B. beträgt der Wert für k, der die Ähnlichkeit zwischen einer Instanz der Klasse „Standardanwendung“ und einer Instanz der Klasse „Individualanwendung“ zur gemeinsamen übergeordneten Klasse „Anwendung“ abbildet, 0,5. Der Wert ergibt sich daraus, dass die Instanzen der Klassen ausschließlich vier (siehe Tabelle 58) zueinander gemeinsame Attribute besitzen. Die Entfernung in Knotenpunkten beträgt Zwei. Die Entfernung wird anhand des Wegs von der am weitesten entfernten Instanz der Klassen zur gemeinsamen Oberklasse der verglichenen Instanzen bestimmt. In diesem Fall sind die Instanzen der beiden Klassen gleich weit entfernt, und zwar zwei Knoten.

Abbildung 49: Entfernung von Instanzen zur gemeinsamen Oberklasse

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen Damit ergibt sich k

4 1 ˜ 4 2

187

0,5 . Dieser Wert wird jeweils in der nächst übergeordneten

Klasse „Anwendung“ in der Ontologie (vgl. Abbildung 50 auf S. 188) vermerkt. Die anderen Werte wurden analog berechnet. In der folgenden Tabelle 59 werden alle Oberklassen dargestellt, die gemeinsame übergeordnete Klassen bei einem Vergleich zwischen zwei Instanzen sein können. Außerdem wird das Verhältnis gemeinsamer Attribute der Instanzen zu allen vorhandenen Attributen dieser Instanzen dargestellt. Die Entfernung in Knoten gibt die Entfernung von der am weitesten entfernten Instanz zur gemeinsamen Oberklasse an. Der Wert k wird basierend auf den angegebenen Werten mit Formel 3.19 berechnet.

übergeord-

Beispiele für vergli-

Verhältnis gemein-

Entfernung

nete Klasse

chene Instanzen

samer Attribute

in Knoten

4:4

2

0,5

0:4

2

0

4:4

2

0,5

0:2

2

0

Anwendung

Software

Hardware

System

Vertriebsdatenbank, Internet_Explorer Suse_Linux_10, Webapplikation Samsung_X20, IBM_iSeries VMWare_ESX, Augeo

k

Tabelle 59: Bestimmung von k

In MyCBR kann an einer Oberklasse nur ein Ähnlichkeitswert hinterlegt werden. Da die Instanzen der Unterklassen jedoch unterschiedliche Entfernungen zu einer gemeinsamen Oberklasse besitzen können, müsste dieser Ähnlichkeitswert variieren können. Da in MyCBR ausschließlich ein statischer Wert angegeben werden kann, wird der pessimistische Ansatz gewählt. Daher wird der minimal mögliche Ähnlichkeitswert eingetragen. Wenn z.B. eine Instanz mit einer Entfernung von fünf Knoten und eine Instanz mit einer Entfernung von vier Knoten zur übergeordneten Klasse existieren, wird bei der Festlegung des Ähnlichkeitswerts die maximale Entfernung in Höhe von fünf Knoten verwendet. Die Ähnlichkeitswerte werden wie folgt in der Ontologie hinterlegt:

188

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen System [0] Hardware [0,5] Client Server Software [0] Betriebssystem Anwendung [0,5] Standardanwendung Individualanwendung

Legende:

Relation „istEin“: Klasse: Ähnlichkeitswert: [ ]

Abbildung 50: Ontologie mit hinterlegten Ähnlichkeitswerten für die Klassen

Diese Zuweisung von Ähnlichkeitswerten zu Klassen wird in MyCBR über den Button „Configure Inheritance Similarity“ auf der Karteikarte „Similarity Measure Editor“ umgesetzt. Ein neues Fenster wird geöffnet, das die Ontologie für die Zuweisung von Ähnlichkeitswerten zu Klassen anzeigt.

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

189

Abbildung 51: Zuweisung von Ähnlichkeitswerten zu Klassen in Protégé

Auch unvollständige Fälle werden berücksichtigt. Diese sind dadurch gekennzeichnet, dass nicht für alle Attribute oder Relationen Werte vorhanden sind. In diesem Fall sind die nicht vorhandenen Attributs- oder Relationswerte unbekannt. In MyCBR kann man unter dem Menüpunkt „Options...“ unter „Ignore "_undefinied_" in retrieval“ festlegen, ob Attribute und Relationen mit unbekannten Werten im Anfrage-Fall („in query“) und in den Fällen aus der Fallbasis („in case“) ignoriert werden sollen. Diese Attribute und Relationen fallen dann ganz aus der Ähnlichkeitsberechnung heraus.

Abbildung 52: Menüpunkt „Options...“ in Protégé

190

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

Abbildung 53: Berücksichtigung unbekannter Attributswerte in Protégé

Da Attribute und Relationen mit unbekannten Werten berücksichtigt werden sollen, werden die entsprechenden Haken nicht gesetzt. Welche Ähnlichkeitswerte bei Attributen und Relationen mit unbekannten Werten verwendet werden, muss unter dem Menüpunkt „Configure Special Values...“ festgelegt werden.

Abbildung 54: Menüpunkt „Configure Special Values...“ in Protégé

Unbekannte Werte führen dazu, dass mit einer Unsicherheit beim Case-Based Reasoning umgegangen werden muss. Die hierzu in Frage kommenden Ansätze wurden in Kapitel 3.2.3.5 erläutert. Dementsprechend wird der pessimistische Ansatz durch einen Ähnlichkeitswert von Null und der optimistische Ansatz durch einen Ähnlichkeitswert von Eins umgesetzt. Den durchschnittlichen Ansatz kann man mit einem Zwischenwert realisieren, wie z.B. 0,5. In dieser Untersuchung wird der pessimistische Ansatz umgesetzt, gemäß dem angenommen wird, dass ein unbekannter Wert den geringst möglichen lokalen Ähnlichkeitswert besitzt und damit Null beträgt. Daher wird für den Ähnlichkeitswert für die

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

191

Ähnlichkeit zwischen einem bekannten und einem unbekannten Wert Null angegeben. Falls beide der zu vergleichenden Fälle zu einem Attribut oder zu einer Relation unbekannte Werte besitzen, bedeutet dies nicht, dass die Fälle in Bezug auf dieses Attribut oder diese Relation ähnlich oder gleich sind. Ein fehlender Wert bedeutet, dass der betreffende Fall nicht vollständig bekannt ist. Wenn also zwei unbekannte Werte miteinander verglichen werden, ist die Ähnlichkeit nicht bekannt und wird gemäß dem pessimistischen Ansatz ebenfalls mit dem Wert Null angegeben. Im Eingabefenster für den Umgang mit unbekannten Werten wird daher genau da eine Null eingetragen, wo ein unbekannter Wert (im Eingabefenster „undefined“) mit einem bekannten Wert (im Eingabefenster „Non-Special Value“) oder zwei unbekannte Werte miteinander verglichen werden. Lediglich beim Vergleich zwischen zwei bekannten Werten wird eine Eins eingetragen, die als „Hebel“ zu verstehen ist und somit den berechneten lokalen Ähnlichkeitswert zwischen zwei Werten nicht verändert. (Nach der Multiplikation mit Eins bleibt der lokale Ähnlichkeitswert unverändert.)

Abbildung 55: Umgang mit unbekannten Attributs- und Relationswerten in Protégé

Die Definition des Schwellenwerts e für die hinreichende Ähnlichkeit zwischen einem neuen Fall q und einem alten Fall f ist von der Präferenz des Benutzers abhängig. Ein tendenziell hoher Schwellenwert führt dazu, dass dem Benutzer Fälle mit geringer Ähnlichkeit nicht präsentiert werden. Ein tendenziell niedriger Schwellenwert führt dazu, dass dem Benutzer Fälle mit geringer Ähnlichkeit ebenfalls präsentiert werden. Für den Prototyp wird exemplarisch der Wert e = 0,5 genutzt. 3.2.3.7 Test des Prototyps für ontologiegestütztes Case-Based Reasoning

Im Folgenden werden mit zwei verschiedenen Anfrage-Fällen Retrievals mit dem erstellten ontologiegestützten CBR-System durchgeführt und anschließend eine manuelle Berechnung anhand der definierten Ähnlichkeitsmaßstäbe und des Algorithmus vorgenommen, um die Retrieval-Ergebnisse für ausgewählte Fälle zu verifizieren. Alle Attributswerte aus

192

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

den Anfrage-Fällen müssen bei der Definition des Wertebereichs und bei der Festlegung der Ähnlichkeitsmaßstäbe berücksichtigt werden. Dies gilt insbesondere für die Attribute des Typs Symbol, da hier jeder mögliche Wert explizit angegeben werden muss. Bei Attributen des Typs Integer muss der Wertebereich nur angepasst werden, wenn Werte aus dem neuen Fall außerhalb des festgelegten Wertebereichs liegen. Grundsätzlich müssen die Wertebereiche manuell erweitert werden, wenn in Anfrage-Fällen Werte enthalten sind, die noch nicht durch die definierten Wertebereiche berücksichtigt wurden. Dieser manuelle Vorgang ist für neue Benutzer ohne Hintergrundwissen über Ähnlichkeitsmaßstäbe ggf. schwer verständlich, da sich die Ähnlichkeitsmaßstäbe hinsichtlich der Werteskalierung und Ähnlichkeitsmessung stark unterscheiden können. Daher wäre eine benutzerfreundliche Eingabemaske für die Anpassung der Wertebereiche von Vorteil. Da in dieser Untersuchung ausschließlich Standardsoftware genutzt wird, wird eine entsprechende Anpassung des Quellcodes der Software nicht durchgeführt. In weiterführenden Untersuchungen kann erörtert werden, ob der Entwicklungsaufwand für eine entsprechende Anpassung des Quellcodes oder eventuell für eine Neuentwicklung zur Erweiterung des ontologiegestützten CBR-Systems in Bezug auf eine Erhöhung der Benutzerfreundlichkeit wirtschaftlich vertretbar wäre. Der Anfrage-Fall 1 handelt von der Einführung eines Patchmanagements mit Windows Server Update Services (WSUS) 381 für das Patchmanagement382 von Windows-Systemen. Die Attributswerte des Falls sind in der Tabelle 60 auf der folgenden Seite aufgeführt:

381

Vgl. MICROSOFT (2010).

382

Gemäß dem BUNDESAMT FÜR SICHERHEIT IN DER INFORMATIONSTECHNIK handelt es sich beim Patchmanagement um das Einspielen von Softwarepaketen der Softwarehersteller, um Sicherheitslücken in Programmen zu schließen oder andere Verbesserungen vorzunehmen. Unter Sicherheitslücken sind Schwachstellen in Programmen zu verstehen, die es Angreifern beispielsweise ermöglichen, bösartige Programme einzuschleusen und die Kontrolle über fremde Systeme zu übernehmen. Vgl. BSI (2003).

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen Instanzen:

Einführung_ Patchmanagement

Microsoft_Windows_XP

WSUS

Attribute:

193

Attributswerte:

Projekttyp

Installation

Euro

420000

Personentage

300

Betriebssystemname

Microsoft_Windows_XP

Familie

Windows

Anwendungsname

WSUS

Anwendungsbereich

Netzwerk

Tabelle 60: Bekannte Instanzen und Werte des Anfrage-Falls 1

Der Attributswert „WSUS“ aus dem Anfrage-Fall 1 ist noch nicht in der vorgegebenen Wertemenge enthalten. Daher müssen die Wertemenge des Attributs „Anwendungsname“ und die entsprechende Tabelle zur Ähnlichkeitsberechnung erweitert werden. „WSUS“ besitzt lediglich eine geringe Ähnlichkeit zur Webapplikation, die mit dem Ähnlichkeitswert 0,1 in der Tabelle ausgedrückt wird. Die Verteilung der Patches mit WSUS erfolgt von einem zentralen System, ähnlich wie bei der Verteilung der Inhalte von Webseiten bei der Webapplikation. Die anderen Attributswerte aus dem Anfrage-Fall 1 sind bereits in den definierten Wertemengen der jeweiligen Attribute enthalten.

194

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

Tabelle 61: Erweiterte Ähnlichkeitstabelle für das Attribut „Anwendungsname“

Im Rahmen des CBR-Retrievals in MyCBR werden die Attributswerte des Anfrage-Falls 1 eingegeben. Anschließend wird mit dem Retrieve-Button eine Berechnung der globalen Ähnlichkeitswerte für die Ähnlichkeit zwischen dem Anfrage-Fall 1 und den Fällen aus der Fallbasis durchgeführt. Als Ergebnis werden die globalen Ähnlichkeitswerte angezeigt, deren Wertebereich von Null (keine Ähnlichkeit) bis Eins (Gleichheit) geht. Bei den fehlenden Attributswerten wird eine pessimistische Ähnlichkeitsberechnung verwendet. Das Retrieval nach Eingabe des Anfrage-Falls 1 wurde innerhalb von 0,109 Sekunden durchgeführt und ergab folgende Ähnlichkeitswerte:

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

195

Abbildung 56: Screenshot vom Retrieval-Ergebnis in MyCBR

Unter Berücksichtigung des Schwellenwerts e für hinreichende Ähnlichkeit mit e = 0,5 werden die Positionen 5 bis 10 im Ranking des abschließenden Retrieval-Ergebnisses nicht berücksichtigt, da die globalen Ähnlichkeitswerte der dort positionierten Fälle unter dem festgelegten Schwellenwert liegen.

Fall

Ranking

Ähnlichkeit

Disaster Recovery

1

0,64

Online-Banking

2

0,57

Virtuelle Internet-PCs

3

0,57

Projektmanagement-Tool

4

0,56

Tabelle 62: Retrieval-Ergebnis für Anfrage-Fall 1 gemäß MyCBR

196

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

Anhand der Ähnlichkeit zwischen dem Anfrage-Fall 1 und dem ähnlichsten Fall „Disaster_Recovery“ kann die ontologiegestützte Ähnlichkeitsberechnung nicht verdeutlicht werden. 383 Daher wird die Ähnlichkeit zwischen dem Anfrage-Fall 1 und dem zweitähnlichsten Fall „Online-Banking“ im Detail überprüft. In diesem Vergleich werden Instanzen betrachtet, die aus verschiedenen Zweigen der Ontologie stammen. Auch der Umgang mit unvollständigen Fällen auf Grund unbekannter Ähnlichkeitswerte kann in diesem Vergleich erläutert werden. Um die gewichtete Summe über die lokalen Ähnlichkeitswerte zu berechnen, müssen zunächst die Werte für die lokalen Ähnlichkeiten zwischen den in der folgenden Tabelle 63 dargestellten Attributs- und Relationswerten bestimmt werden.

383

Die Ähnlichkeit zwischen dem Anfrage-Fall 1 und dem ähnlichsten Fall „Disaster_Recovery“ beinhaltet den Vergleich von Instanzen, die ausschließlich aus demselben Zweig der Ontologie stammen. Die Berechnung der lokalen Ähnlichkeitswerte wird im Folgenden detailliert dargestellt: Die Ähnlichkeit zwischen den Attributswerten des Attributs „Projekttyp“ wird gemäß Formel 3.17 und der Ähnlichkeitstabelle 51 festgelegt. Der Attributswert „Installation“ besitzt zu sich selbst die Ähnlichkeit mit dem Wert Eins. Der Wert für die Ähnlichkeit zwischen den Werten des Attributs „Euro“ mit max d = 441900 ergibt sich gemäß Formel 3.14 aus dem Abstand zwischen den beiden Werten 420000 und 382000 und beträgt 0,914. Der Wert für die Ähnlichkeit zum Attribut „Personentage“ mit max d = 492 ergibt sich gemäß Formel 3.14 aus dem Abstand zwischen den Attributswerten 300 und 504 und beträgt 0,585. Bei den Relationen werden die Ähnlichkeitswerte durch die Ähnlichkeit zwischen den relational verknüpften Instanzen bestimmt. Bei den Relationen „betrifftHardware“ und „betrifftAnwendung“ ist jeweils nur bei einem Fall eine relational verknüpfte Instanz angegeben. Beim zu vergleichenden Fall ist der Wert der Relation unbekannt. Da für den Umgang mit unbekannten Werten der pessimistische Ansatz gewählt wurde, wird der Wert für die Ähnlichkeit hier mit jeweils Null angegeben. Der Wert für die Ähnlichkeit zwischen den Werten der Relation „betrifftBetriebssystem“ wird gemäß Formel 3.21 durch die Berechnung des Werts für die Ähnlichkeit zwischen den relational verknüpften Instanzen „Microsoft_Windows_XP“ und „Microsoft_Windows_ XP“ festgelegt. Da es sich um dieselbe Instanz handelt, die zu sich selbst gleich ist, beträgt der Wert für die Ähnlichkeit Eins. Da Instanzen aus unterschiedlichen Zweigen der Ontologie hier nicht verglichen wurden, konnte die Ontologiestützung in diesem Vergleich nicht verdeutlicht werden. Insgesamt ergibt sich gemäß Formel 3.22 aus der Summe der lokalen Ähnlichkeiten, die mit den Gewichten aus Tabelle 58 gewichtet wurden, eine globale Ähnlichkeit von: sim gn (q, f )

¦ u I

i 1

i



H



˜ sim a (a iq , a if )  ¦ u h ˜ sim r ( rhq , rhf ) ˜ sim c (c qh , c fh )



h 1

( 2 / 7 ˜ 1  1 / 7 ˜ 0,914  1 / 7 ˜ 0,585)  (1 / 7 ˜ 0 ˜ 0  1 / 7 ˜ 0 ˜ 0  1 / 7 ˜ 1 ˜ 1)

(gerundet 0,64 in Tabelle 62).

0,643

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

Klassen

Attribute/

Werte des

Werte des Falls

Relationen

Anfrage-Falls 1

„Online-Banking“

Projekttyp

Installation

Installation

Euro

420000

290000

Personentage

300

250

betrifftHardware

unbekannt

Server_8

betrifftBetriebs-

Microsoft_

Suse_Linux_10

system

Windows_XP

betrifftAnwendung

WSUS

Webapplikation

Unterklasse von

Modell

unbekannt

Dell_PowerEdge

Hardware

Typ

unbekannt

Rack

Projekt

197

Betriebssystemname Microsoft_

Suse_Linux_10

Windows_XP

Betriebssystem Familie

Windows

Unix

Unterklasse von

Anwendungsname

WSUS

Webapplikation

Anwendung

Anwendungsbereich Netzwerk

Internet

Tabelle 63: Gegenüberstellung der Werte von Anfrage-Fall 1 und vom Fall „Online-Banking“

Der Wert für die Ähnlichkeit zwischen den Attributswerten des Attributs „Projekttyp“ wird gemäß Formel 3.17 und Ähnlichkeitstabelle 51 festgelegt. Die Ähnlichkeit zwischen „Installation“ und „Installation“ besitzt den Wert Eins, da es sich um denselben Attributswert handelt. Der Wert für die Ähnlichkeit zwischen den Attributswerten des Attributs „Euro“ ergibt sich gemäß Formel 3.14 aus dem Abstand zwischen den beiden Werten 420000 und 290000. Da max d hier den Wert 441900 besitzt, 384 beträgt die Ähnlichkeit: sim a (a iq , a if )

384

1

420000  290000 441900

Dieser Wert wurde auf S. 176 berechnet.

1  0,294

0,706

198

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

Die Ähnlichkeit zwischen den Attributswerten des Attributs „Personentage“ ergibt sich ebenfalls gemäß Formel 3.14 aus dem Abstand zwischen den Attributswerten. Da max d hier den Wert 492 besitzt, 385 berechnet sich der Abstand zwischen 300 und 250 mit: sim a (a iq , a if )

1

300  250 492

1  0,102

0,898

Bei den Relationen wird die Ähnlichkeit wieder über die relational verknüpften Instanzen bestimmt. Bei der Relation „betrifftHardware“ ist für nur einen der beiden zu vergleichenden Fälle der Wert der Relation bekannt. Auf Grund des pessimistischen Ansatzes wird der Wert für die Ähnlichkeit hier mit Null angegeben. Der Wert für die Ähnlichkeit zwischen den Werten der Relation „betrifftBetriebssystem“ wird gemäß Formel 3.21 durch die Berechnung der Ähnlichkeit zwischen den relational verknüpften Instanzen „Microsoft_Windows_XP“ und „Suse_Linux_10“ festgelegt. Hierzu wird jeweils die mit den Gewichten aus Tabelle 58 gewichtete Summe über die lokalen Ähnlichkeitswerte der relational verknüpften Instanzen gebildet. Die Instanzen besitzen die beiden Attribute „Betriebssystemname“ und „Familie“. Beim Attribut „Betriebssystemname“ ergibt sich zwischen den Attributswerten „Microsoft_Windows_XP“ und „Suse_Linux_10“ gemäß Formel 3.18 und der definierten Taxonomie in den Abbildungen 47 und 57 ein Ähnlichkeitswert von 0,2. Es wird der Ähnlichkeitswert genutzt, der bei dem Knoten hinterlegt ist, bei dem die beiden Knoten der Instanzen auf dem Weg der Hierarchie von unten nach oben zusammenlaufen. Dies ist der Knoten „Betriebssystemname“, bei dem der Ähnlichkeitswert 0,2 hinterlegt ist. In der folgenden Abbildung 57 sind die hier betrachteten Instanzen grau hinterlegt und deren Wege zum gemeinsamen übergeordneten Knoten „Betriebssystemname“ mit einer dickeren Verbindung hervorgehoben.

385

Dieser Wert wurde auf S. 176 berechnet.

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

199

Betriebssystemname [0,2] Microsoft_Windows [0,8] Microsoft_Windows_Vista Microsoft_Windows_XP Unix [0,5] AiX_4.3.3 Sun_Solaris_10 Linux [0,6] Red_Hat_Linux_9 Suse_Linux_10 Integrity_Linux

Legende:

Relation „istEin“: Klasse: Instanz: Ähnlichkeitswert: [ ]

Abbildung 57: Positionen der Werte „Microsoft_Windows_XP“ und „Suse_Linux_10“ in der Taxonomie für das Attribut „Betriebssystemname“

Beim Attribut „Familie“ ergibt sich zwischen „Windows“ und „Unix“ gemäß Formel 3.17 und der Tabelle 54 ein Ähnlichkeitswert von 0,2. Die mit den Gewichten aus Tabelle 58 gewichtete Summe und somit der Ähnlichkeitswert für die Relation „betrifftBetriebssystem“ lautet 0,2. Da die beiden relational verknüpften Instanzen zum selben Zweig der Ontologie gehören, erfolgt hier keine ontologiegestützte Anpassung der Ähnlichkeit.

200

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

Abbildung 58: Positionen der Instanzen „Microsoft_Windows_XP“ und „Suse_Linux_10“ in der Ontologie (Auszug)

Die Ähnlichkeit zwischen den Werten der Relation „betrifftAnwendung“ wird durch die Berechnung des Werts für die Ähnlichkeit zwischen den relational verknüpften Instanzen „WSUS“ und „Webapplikation“ festgelegt. Da diese beiden Instanzen in verschiedenen Zweigen der Ontologie positioniert sind, wird hier eine ontologiegestützte Anpassung der Ähnlichkeit verwendet. Die Instanz „WSUS“ ist dem Zweig „Standardanwendung“ und die Instanz „Webapplikation“ dem Zweig „Individualanwendung“ zugeordnet. Zunächst wird die mit den Gewichten aus Tabelle 58 gewichtete Summe über die Werte für die lokalen Ähnlichkeiten der relational verknüpften Instanzen gebildet. Die Ähnlichkeit zwischen den Werten des Attributs „Anwendungsbereich“ wird gemäß Formel 3.17 und Tabelle 56 bestimmt. Der Attributswert „Internet“ besitzt zu „Netzwerk“ die Ähnlichkeit mit dem Wert 0,6. Die Ähnlichkeit zwischen den Werten des Attributs „Anwendungsname“ wird gemäß Formel 3.17 und Tabelle 61 bestimmt. Zwischen „WSUS“ und „Webapplikation“ besitzt die Ähnlichkeit demnach den Wert 0,1. Die mit den Gewichten aus Tabelle 58 gewichtete Summe der Werte für die lokalen Ähnlichkeiten zwischen den Attributswerten der relational verknüpften Instanzen lautet 1 / 2 ˜ 0,6  1 / 2 ˜ 0,1 0,35 . Zu berücksichtigen ist nun die ontologiegestützte Ähnlichkeit zwischen den relational verknüpften Instanzen „WSUS“ und „Webapplikation“:

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

201

Abbildung 59: Positionen der Instanzen „WSUS“ und „Webapplikation“ in der Ontologie (Auszug)

Die Instanz „WSUS“ gehört zur Klasse „Standardanwendung“ und die Instanz „Webapplikation“ zur Klasse „Individualanwendung“. Da die beiden relational verknüpften Instanzen somit zu verschiedenen Klassen der Ontologie gehören, muss die Ähnlichkeit zwischen den Klassen der Instanzen gemäß der Formel 3.20 mit sim c (c qh , c fh ) multipliziert werden. Da die beiden Instanzen eine gemeinsame Schnittmenge von Attributen besitzen, wird sim c (c qh , c fh ) mit k gemäß Formel 3.19 berechnet. Die Instanzen der beiden Klassen „Standardanwendung“ und „Individualanwendung“ besitzen jeweils die beiden Attribute „Anwendungsbereich“ und „Anwendungsname“. Es sind pro Instanz zwei Attribute und insgesamt vier Attribute vorhanden. Da jedes Attribut in beiden Instanzen vorkommt, handelt es sich bei allen vier Attributen um gemeinsame Attribute der beiden Instanzen. Die Entfernung von einer der beiden Instanzen der beiden Klassen zur gemeinsamen Oberklasse „Anwendung“ beträgt jeweils Zwei. Somit besitzt k den Wert

4 1 ˜ 4 2

0,5 .

Für die Ähnlichkeit zwischen den Attributen der relational verknüpften Instanzen ergibt sich insgesamt der Wert 0,35 ˜ 0,5

0,175 .

202

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen Slot

lokaler Ähnlichkeitswert

Gewicht

Projekttyp

1

2/7

Euro

0,706

1/7

Personentage

0,898

1/7

betrifftHardware

0

1/7

betrifftBetriebssystem

0,2

1/7

betrifftAnwendung

0,175

1/7

Tabelle 64: Lokale Ähnlichkeitswerte für den Anfrage-Fall 1 und den Fall „Online-Banking“

Aus der mit den Gewichten aus Tabelle 58 gewichteten Summe der in Tabelle 64 dargestellten lokalen Ähnlichkeitswerte ergibt sich gemäß Formel 3.22 der globale Ähnlichkeitswert:

sim gn (q , f )

¦ u I

i 1

i



H



˜ sim a (a iq , a if )  ¦ u h ˜ sim r ( rhq , rhf ) ˜ sim c (c qh , c fh )



h 1

( 2 / 7 ˜ 1  1 / 7 ˜ 0,706  1 / 7 ˜ 0,898)  (1 / 7 ˜ 0 ˜ 0  1 / 7 ˜ 0,2 ˜ 1  1 / 7 ˜ 0,35 ˜ 0,5)

0,568

(gerundet 0,57 in Tabelle 62) Der Anfrage-Fall 2 handelt von einer Konfiguration von Netzwerk-Interfaces ausgewählter Linux-Systeme. Die Konfiguration beinhaltete die Änderung der IP-Adressen386 und der Hostnamen 387 der Systeme. Außerdem wurden lokale Firewalls auf den Systemen genutzt,

386

Die IP-Adresse ist ein 32-Bit-Wert, der jedes Gerät, das an ein TCP/IP-Netzwerk angeschlossen ist, eindeutig identifiziert und normalerweise in Form von vier Dezimalzahlen geschrieben wird. IPAdressen werden Netzwerkschnittstellen zugeschrieben, so dass ein Gerät mit mehreren Netzwerkschnittstellen auch mehrere IP-Adressen besitzen kann. Vgl. HUNT (2003), S. 28. Die IP-Adresse stellt auch einen Zugangspunkt zum Dienst für die Übermittlung der IP-Pakete dar. Vgl. BADACH/HOFFMANN (2007), S. 24. Die IP-Adresse wird zur Adressierung auf der IP-Ebene genutzt, die im IPHeader durch das 32-Bit lange Source Address Field und das 32-Bit lange Destination Address Field erfolgt. Vgl. RECH (2008), S. 372.

387

Ein Hostname ist ein Name, der jedem Gerät zugewiesen werden kann, das eine IP-Adresse besitzt. Im Vergleich zu den numerischen Werten einer IP-Adresse kann ein Hostname leichter gemerkt werden. Vgl. HUNT (2003), S. 56. Innerhalb eines Domain Name Systems (DNS) findet der Hostname seine Entsprechung im Full Qualified Domain Name (FQDN) und auf dem DNS-Server wird der Hostname als zonenspezifischer AName oder CName hinterlegt. Vgl. BADACH/HOFFMANN (2007), S. 158. Der FQDN, z.B. „pc0001.einkauf.netz.de.“, wird genutzt, um ein Gerät im DNS weltweit eindeutig zu referenzieren. Die Auflösung von Namen zu IP-Adressen wird Forward-Lookup genannt und die Auflösung in die andere Richtung Reverse-Lookup. Vgl. SCHREINER (2007), S. 97 f.

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

203

deren Konfiguration angepasst wurde. Bei den lokalen Firewalls handelte es sich um die Software Iptables. 388

Instanzen:

Aktualisierung_ Netzwerkkonfiguration

Server_A2

Red_Hat_Linux_9

Iptables

Attribute:

Attributswerte:

Projekttyp

Konfiguration

Euro

26000

Personentage

30

Modell

Dell_PowerEdge

Typ

Tower

Betriebssystemname

Red_Hat_Linux_9

Familie

Unix

Anwendungsname

Iptables

Anwendungsbereich

Netzwerk

Tabelle 65: Bekannte Instanzen und Werte des Anfrage-Falls 2

Die Attributswerte aus dem Anfrage-Fall 2 müssen ebenfalls bei der Definition der Wertebereiche und bei der Festlegung der Ähnlichkeitsmaßstäbe berücksichtigt werden. Beim Anfrage-Fall 2 ist der Attributswert „Iptables“ noch nicht definiert. Analog zum AnfrageFall 1 müssen die Wertemenge des Attributs „Anwendungsname“ und die entsprechende Tabelle zur Ähnlichkeitsberechnung erweitert werden. „Iptabes“ besitzt eine hohe Ähnlichkeit zur „Check_Point_Firewall“. Bei beiden Applikationen handelt es sich um Firewalls, die sich jedoch neben einer unterschiedlichen Konfigurationsoberfläche dadurch unterscheiden, dass Iptables lediglich Paketfilterungen für die Pakete übernimmt, die auf den Systemen, auf denen es betrieben wird, ankommen oder versendet werden, und die Check Point Firewall Paketfilterungen für einen Netzwerkbereich übernimmt, in welchem sich

388

Iptables erlaubt die Definition von Firewall-Regeln in Tabellen, um Paketfilterfunktionen umzusetzen. Jede Tabelle besteht aus mehreren Ketten, die von Iptables an die verschiedenen Ankerpunkte (Hooks) von Netfilter gebunden werden. Netfilter ist eine Software, die in Linux diese Ankerpunkte anbietet und somit eine Struktur für Iptables bereitstellt. Vgl. SPENNEBERG (2006), S. 81. Die Regeln in Iptables entscheiden anhand der Header-Informationen eines Pakets, was mit diesem Paket geschehen soll, z.B. Akzeptieren oder Verwerfen des Pakets. Neben Paketfilterfunktionen kann mit Iptables auch Network Address Translation (NAT) umgesetzt werden, für welche Regeln in der Tabelle „nat“ definiert werden. Vgl. LESSIG (2006), S. 307 f.

204

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

mehrere Systeme befinden. Basierend darauf wird die Ähnlichkeit mit dem Ähnlichkeitswert 0,6 ausgedrückt. Die Attributswerte der anderen Attribute sind bereits in den definierten Wertemengen der jeweiligen Attribute enthalten.

Tabelle 66: Erweiterte Ähnlichkeitstabelle für das Attribut „Anwendungsname“

Im Rahmen des CBR-Retrievals in MyCBR werden die Attributswerte des Anfrage-Falls 2 eingegeben. Anschließend wird mit dem Retrieve-Button eine Berechnung der Ähnlichkeiten zwischen dem Anfrage-Fall 2 und den Fällen aus der Fallbasis durchgeführt. Als Ergebnis werden die Ähnlichkeitswerte mit Wertebereich von Null bis Eins angezeigt. Bei den unbekannten Attributswerten wird eine pessimistische Ähnlichkeitsberechnung verwendet. Das Retrieval nach Eingabe des Anfrage-Falls 2 wurde innerhalb von 0,047 Sekunden durchgeführt und ergab folgende Ähnlichkeitswerte:

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

205

Abbildung 60: Screenshot vom Retrieval-Ergebnis in MyCBR

Unter Berücksichtigung des Schwellenwerts e für hinreichende Ähnlichkeit mit e = 0,5 werden die Positionen 7 bis 10 im abschließenden Ranking des Retrieval-Ergebnisses nicht berücksichtigt, da die globalen Ähnlichkeitswerte der dort positionierten Fälle unter dem festgelegten Schwellenwert liegen.

Fall

Ranking

Ähnlichkeit

Stabilisierung_Vertriebsdatenbank

1

0,72

Migration_Börsensysteme

2

0,67

Firewall-Integration

3

0,66

Verbesserung_Clientstart

4

0,63

Unix-Härtung

5

0,57

Serverwechsel_Planungstool

6

0,54

Tabelle 67: Retrieval-Ergebnis für Anfrage-Fall 2 gemäß MyCBR

206

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

Um mit dem Anfrage-Fall 2 eine ontologiegestützte Ähnlichkeitsberechnung durchzuführen, wird dieser mit dem viertähnlichsten Fall „Verbesserung_Clientstart“ verglichen.389 Bei diesem Vergleich werden die relational verknüpften Instanzen „Client_10“ und „Server_A2“ sowie „Red_Hat_Linux_9“ und „Microsoft_Windows_XP“ miteinander vergli389

Die Ähnlichkeit zwischen dem Anfrage-Fall 2 und dem ähnlichsten Fall „Stabilisierung_Vetriebsdatenbank“ eignet sich nicht für die Demonstration der ontologiegestützten Ähnlichkeitsberechnung. Grundsätzlich findet diese zwar für eine lokale Ähnlichkeit Anwendung, die betroffene lokale Ähnlichkeit besitzt jedoch den Wert Null. Im Folgenden werden alle lokalen Ähnlichkeitswerte des Vergleichs erläutert: Die Ähnlichkeit zwischen den Attributswerten des Attributs „Projekttyp“ wird gemäß Formel 3.17 und Ähnlichkeitstabelle 51 festgelegt und beträgt Eins, da der Attributswert „Konfiguration“ zu sich selbst gleich ist. Der Wert für die Ähnlichkeit zwischen den Attributswerten des Attributs „Euro“ mit max d = 441900 ergibt sich gemäß Formel 3.14 aus dem Abstand zwischen den beiden Werten 34000 und 26000 und beträgt 0,982. Der Wert für die Ähnlichkeit zwischen den Attributswerten des Attributs „Personentage“ mit max d = 492 ergibt sich gemäß Formel 3.14 aus dem Abstand zwischen den beiden Attributswerten 55 und 30 und beträgt 0,949. Bei den Relationen werden die Ähnlichkeitswerte durch die Ähnlichkeit zwischen den relational verknüpften Instanzen bestimmt. Die Ähnlichkeit zwischen den Werten der Relation „betrifftHardware“ wird über die lokalen Ähnlichkeiten zwischen den relational verknüpften Instanzen „Server_A2“ und „Server_7“ berechnet. Beim Attribut „Modell“ ergibt sich gemäß der Taxonomie in Abbildung 48 ein Ähnlichkeitswert von 0,2. Beim Attribut „Typ“ ergibt sich zwischen „Tower“ und „virtuell“ gemäß der Tabelle 57 ein Ähnlichkeitswert von Null. Die mit den Gewichten aus Tabelle 58 gewichtete Summe und somit der Ähnlichkeitswert für die Werte der Relation „betrifftHardware“ lautet 1 / 2 ˜ 0,2  1 / 2 ˜ 0 0,1 . Die Instanzen „Server_A2“ und „Server_7“ gehören zur Klasse „Server“. Gemäß der Formel 3.22 erfolgt eine Multiplikation mit sim c (c qh , c fh ) . Gemäß Formel 3.20 gilt hier sim c (c qh , c fh ) 1, denn es gilt: c qh c fh . Der Wert für die Ähnlichkeit zwischen den Werten der Relation „betrifftBetriebssystem“ wird durch die Berechnung der Ähnlichkeitswerte für die Ähnlichkeit zwischen den relational verknüpften Instanzen „Red_Hat_Linux_9“ und „Red_Hat_Linux_9“ festgelegt. Da es sich um dieselbe Instanz handelt, die zu sich selbst gleich ist, lautet der Wert für die Ähnlichkeit zwischen den Werten der Relation „betrifftBetriebssystem“ Eins. Der Wert für die Ähnlichkeit zwischen den Werten der Relation „betrifftAnwendung“ wird durch die Berechnung der Ähnlichkeit zwischen den relational verknüpften Instanzen „Iptables“ und „Vertriebsdatenbank“ festgelegt. Da diese beiden Instanzen in verschiedenen Zweigen der Ontologie positioniert sind, wird hier eine ontologiegestützte Ähnlichkeitsberechnung verwendet. Die Instanz „Iptables“ ist dem Zweig „Standardanwendung“ und die Instanz „Vertriebsdatenbank“ dem Zweig „Individualanwendung“ zugeordnet. Daher gilt gemäß Abbildung 50: sim c (c qh , c fh ) 0,5 . Zunächst wird die mit den Gewichten aus Tabelle 58 gewichtete Summe über die lokalen Ähnlichkeitswerte der relational verknüpften Instanzen gebildet. Der Wert für die Ähnlichkeit zwischen den Werten des Attributs „Anwendungsbereich“ wird anhand der Tabelle 56 bestimmt. Der Attributswert „Netzwerk“ besitzt zu „Handel“ auf Grund dieser Tabelle die Ähnlichkeit mit dem Wert Null. Der Wert für die Ähnlichkeit zwischen den Werten des Attributs „Anwendungsname“ wird anhand der Tabelle 66 bestimmt. Zwischen den Instanzen „Iptables“ und „Vertriebsdatenbank“ besitzt die Ähnlichkeit demnach auch den Wert Null. Die ontologiegestützte Ähnlichkeit zwischen den relational verknüpften Instanzen lautet folglich Null. Insgesamt ergibt sich gemäß Formel 3.22 eine globale Ähnlichkeit von: sim gn (q , f )

¦ u I

i

˜ sim a (a iq , a if ) 

i 1

¦ u H

h

˜ sim r ( rhq , rhf ) ˜ sim c (c qh , c fh )

h 1

( 2 / 7 ˜ 1  1 / 7 ˜ 0,982  1 / 7 ˜ 0,949)  (1 / 7 ˜ 0,1 ˜ 1  1 / 7 ˜ 1 ˜ 1  1 / 7 ˜ 0 ˜ 0,5)

(gerundet 0,72 in Tabelle 67).

0,719

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

207

chen, die in verschiedenen Zweigen der Ontologie positioniert sind. Der Fall „Verbesserung_Clientstart“ ist unvollständig, da der Wert der Relation „betrifft-Anwendung“ unbekannt ist, und erlaubt erneut die Demonstration des Umgangs mit unbekannten Werten.

Klassen

Projekt

Attribute/

Werte des

Relationen

Anfrage-Falls 2

Konfiguration

Konfiguration

Euro

26000

25000

Personentage

30

28

betrifftHardware

Server_A2

Client_10

system

Hardware

Clientstart“

Projekttyp

betrifftBetriebs-

Unterklasse von

Werte des Falls „Verbesserung_

Red_Hat_Linux_9

Microsoft_ Windows_Vista

betrifftAnwendung

Iptables

unbekannt

Modell

Dell_PowerEdge

Samsung_X20

Typ

Tower

Notebook

Betriebssystemname Red_Hat_Linux_9

Microsoft_ Windows_Vista

Betriebssystem Familie

Unix

Windows

Unterklasse von

Anwendungsname

Iptables

unbekannt

Anwendung

Anwendungsbereich Netzwerk

unbekannt

Tabelle 68: Gegenüberstellung der Werte von Anfrage-Fall 1 und vom Fall „Online-Banking“

Die lokalen Ähnlichkeitswerte werden einzeln betrachtet: Die Ähnlichkeit zwischen den Werten des Attributs „Projekttyp“ besitzt gemäß Formel 3.17 und Tabelle 51 den Wert Eins, da der Wert „Konfiguration“ zu sich selbst gleich ist. Der Wert für die Ähnlichkeit zwischen den Werten des Attributs „Euro“ ergibt sich aus dem Abstand zwischen den bei-

208

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

den Werten 25000 und 26000. Da max d den Wert 441900 besitzt, 390 beträgt die Ähnlichkeit gemäß der Formel 3.14: sim a (a iq , a if ) 1 

25000  26000 441900

1  0,002

0,998

Die Ähnlichkeit zwischen den Werten des Attributs „Personentage“ ergibt sich aus dem Abstand zwischen den beiden Attributswerten 28 und 30. Da max d den Wert 492 besitzt, 391 berechnet sich die Ähnlichkeit mit: sim a (a iq , a if )

1

28  30 492

1  0,004

0,996

Bei den Relationen wird der Ähnlichkeitswert über die relational verknüpften Instanzen bestimmt. Die Ähnlichkeit zwischend den Werten der Relation „betrifftHardware“ wird über die Berechnung des Werts für die Ähnlichkeit zwischen den relational verknüpften Instanzen „Dell_PowerEdge“ und „Samsung_X20“ bestimmt. Für die Ähnlichkeit zwischen den Werten des Attributs „Modell“ ergibt sich zwischen „Dell_PowerEdge“ und „Samsung_X20“ gemäß der Taxonomie in Abbildung 48 ein Ähnlichkeitswert von 0,5. Für die Ähnlichkeit zwischen den Werten des Attributs „Typ“ ergibt sich zwischen „Tower“ und „Notebook“ gemäß der Tabelle 57 ein Ähnlichkeitswert von 0,3. Die mit den Gewichten aus Tabelle 58 gewichtete Summe und damit der Wert für die Ähnlichkeit zwischen den relational verknüpften Instanzen lautet 1 / 2 ˜ 0,5  1 / 2 ˜ 0,3

0,4 . Es handelt sich hier-

bei um einen Zwischenwert, da noch berücksichtigt werden muss, dass die beiden Instanzen in verschiedenen Zweigen der Ontologie positioniert sind:

390

Dieser Wert wurde auf S. 176 berechnet.

391

Dieser Wert wurde auf S. 176 berechnet.

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

209

Abbildung 61: Positionen der Instanzen „Client_10“ und „Server_A2“ in der Ontologie (Auszug)

Die Instanz „Server_A2“ gehört zur Klasse „Server“ und die Instanz „Client_10“ zur Klasse „Client“. Da die beiden relational verknüpften Instanzen somit zu verschiedenen Klassen der Ontologie gehören, muss die Ähnlichkeit zwischen den Instanzen gemäß der Formel 3.20 mit sim c (c qh , c fh ) multipliziert werden. Da die beiden Instanzen eine nicht leere Schnittmenge der Attribute besitzen, wird sim c (c qh , c fh ) mit k gemäß Formel 3.19 berechnet. Die Instanzen der beiden Klassen „Server“ und „Client“ besitzen jeweils die beiden Attribute „Modell“ und „Typ“ und somit sind insgesamt vier Attribute vorhanden. Da jedes Attribut in beiden Instanzen vorkommt, handelt es sich bei allen vier Attributen um gemeinsame Attribute der beiden Instanzen. Die Entfernung von einer der beiden Instanzen zur gemeinsamen Oberklasse „Hardware“ beträgt jeweils Zwei. Somit besitzt k den Wert 4 1 ˜ 4 2

0,5 .

Für die Ähnlichkeit zwischen den Attributswerten der relational verknüpften Instanzen ergibt sich insgesamt der Wert 0,4 ˜ 0,5

0, 2 .

Der Wert für die Ähnlichkeit zwischen den Werten der Relation „betrifftBetriebssystem“ wird durch die Berechnung der Ähnlichkeit zwischen den relational verknüpften Instanzen „Red_Hat_Linux_9“ und „Microsoft_Windows_XP“ festgelegt. Deren Ähnlichkeit zwischen den Werten des Attributs „Betriebssystemname“ besitzt gemäß der Taxono-

210

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

mie in den Abbildungen 47 und 62 den Wert 0,2 und zwischen den Werten des Attributs „Familie“ gemäß der Tabelle 54 ebenfalls den Wert 0,2.

Betriebssystemname [0,2] Microsoft_Windows [0,8] Microsoft_Windows_Vista Microsoft_Windows_XP Unix [0,5] AIX_4.3.3 Sun_Solaris_10 Linux [0,6] Red_Hat_Linux_9 Suse_Linux_10 Integrity_Linux

Legende:

Relation „istEin“: Klasse: Instanz: Ähnlichkeitswert: [ ]

Abbildung 62: Positionen der Werte „Red_Hat_Linux_9“ und „Microsoft_Windows_XP“ in der Taxonomie für das Attribut „Betriebssystemname“

Die mit den Gewichten aus Tabelle 58 gewichtete Summe und damit der Wert für die Ähnlichkeit zwischen den Werten der Relation „betrifftBetriebssystem“ beträgt 1 / 2 ˜ 0,2  1 / 2 ˜ 0, 2

0,2 . Da die beiden Instanzen „Red_Hat_Linux_9“ und „Microsoft_Windows_

XP“ zum selben Zweig der Ontologie gehören, erfolgt keine ontologiegestützte Anpassung der Ähnlichkeit.

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

211

Abbildung 63: Positionen der Instanzen „Red_Hat_Linux_9“ und „Microsoft_Windows_XP“ in der Ontologie (Auszug)

Der Wert für die Ähnlichkeit zwischen den Werten der Relation „betrifftAnwendung“ wird durch die Berechnung des Werts für die Ähnlichkeit zwischen den relational verknüpften Instanzen festgelegt. Da beim Fall „Optimierung_Clientstart“ keine Instanz für die Relation angegeben ist, wird auf Grund des pessimistischen Ansatzes die Ähnlichkeit hier mit dem Wert Null angegeben.

Attribut

lokaler Ähnlichkeitswert

Gewicht

Projekttyp

1

2/7

Euro

0,998

1/7

Personentage

0,996

1/7

betrifftHardware

0,2

1/7

betrifftBetriebssystem

0,2

1/7

betrifftAnwendung

0

1/7

Tabelle 69: Lokale Ähnlichkeitswerte für den Anfrage-Fall 2 und den Fall „Optimierung_Clientstart“

Aus der mit den Gewichten aus Tabelle 58 gewichteten Summe der in Tabelle 69 dargestellten lokalen Ähnlichkeitswerte ergibt sich gemäß Formel 3.22 der globale Ähnlichkeitswert:

212

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

sim gn (q , f )

¦ u I

i 1

i



H



˜ sim a (a iq , a if )  ¦ u h ˜ sim r ( rhq , rhf ) ˜ sim c (c qh , c fh )



h 1

( 2 / 7 ˜1  1 / 7 ˜ 0,998  1 / 7 ˜ 0,996)  (1 / 7 ˜ 0,4 ˜ 0,5  1 / 7 ˜ 0,2 ˜ 1  1 / 7 ˜ 0 ˜ 0)

0,628

(gerundet 0,63 in Tabelle 67) Ein Teil des Tests besteht darin, für die Anwendung des Systems das Eingabe- und Ausgabeverhalten wie im Ergebnis des Konzepts aufzuzeigen. 392 Die Validität der Ergebnisse des ontologiegestützten Case-Based Reasonings soll anhand von drei Validitätsarten beurteilt werden. Die drei Validitätsarten sind laut BORTZ/DÖRING 393 die Inhaltsvalidität, die Kriteriumsvalidität und die Konstruktvalidität. Die Inhaltsvalidität ist gegeben, wenn der Inhalt des Prototyps das zu Grunde liegende semantische Datenmodell in seinen wichtigsten Aspekten erschöpfend erfasst. Da der Inhalt des Prototyps eine exemplarisch gefüllte Fallbasis besitzt, wird die Grundgesamtheit der in der Praxis möglichen Fälle bewusst nicht vollständig repräsentiert. Ziel bei der exemplarischen Füllung der Fallbasis war es, eine Grundlage für die Durchführung des ontologiegestützten Case-Based Reasonings zu schaffen. Dies wurde erreicht. Die Repräsentativität der exemplarisch gefüllten Fallbasis in Bezug zu den heterogenen Fallbasen, die in der Praxis von Relevanz sind, war daher nicht von Belang. Die Kriteriumsvalidität ist vorhanden, wenn das Ergebnis der Anwendung des Prototyps mit korrespondierenden manifesten Kriterien übereinstimmt. Die korrespondierenden Kriterien können entweder später (prognostische Validität) oder gleichzeitig (Übereinstimmungsvalidität) erhoben werden. Innerhalb der Anwendung des Prototyps handelt es sich bei der Ähnlichkeit zwischen den Fällen um ein Kriterium, das mit der manuellen Berechnung der lokalen und globalen Ähnlichkeitswerte basierend auf den spezifizierten Ähnlichkeitsmaßstäben übereinstimmen soll (Übereinstimmungsvalidität). Zu diesem Zweck wurden die globalen Ähnlichkeitswerte zwischen den Anfrage-Fällen und den exemplarischen Fällen aus der Fallbasis manuell berechnet und anschließend mit den Berechnungen des Prototyps verglichen (siehe oben). Die Ergebnisse der manuellen Berechnungen stimmten mit den Berechnungen des Prototyps überein. Daher wird die Kriteriumsvalidität als erfüllt angesehen.

392

Vgl. ZÖLLER-GREER (2002), S. 216. Bei ZÖLLER-GREER wird der Begriff Spezifikation verwendet, der als Ergebnis des Konzepts zu verstehen ist.

393

Vgl. BORTZ/DÖRING (2006), S. 200 ff.

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

213

Die Konstruktvalidität ist gegeben, wenn aus dem Zielkonstrukt des Prototyps Hypothesen ableitbar sind, die anhand der Ergebnisse des Prototyps bestätigt werden können. Wenn die begründeten Hypothesen mit den Werten des überprüfenden Instruments nicht bestätigt werden können, muss die Konstruktvalidität angezweifelt werden. Die Hypothese, die aus dem Zielkonstrukt des Prototyps abgeleitet werden kann, besteht darin, dass der globale Ähnlichkeitswert zwischen zwei Fällen durch das ontologiegestützte CBR-System unter Berücksichtigung aller vorhandenen Attributswerte und Relationswerte mit Hilfe der definierten Algorithmen und Ähnlichkeitsmaßstäbe berechnet werden kann. Das überprüfende Instrument ist eine experimentelle Methode. Die globalen Ähnlichkeitswerte zwischen den Anfrage-Fällen und den exemplarischen Fällen aus der Fallbasis wurden unter Berücksichtigung aller vorhandenen Attributswerte und Relationswerte dieser Fälle berechnet (siehe oben). Die Konstruktvalidität wird daher als gegeben angesehen. Die Reliabilität des Prototyps ist gegeben, da bei jeweils zehn Durchführungen des ontologiegestützten Case-Based Reasonings mit denselben Eingabedaten stets dieselben Ergebnisse ausgegeben wurden. Speziell bedeutet dies, dass die Identifikation hinreichend ähnlicher Fälle und die Selektion eines ähnlichsten Falls zu demselben gegebenen Anfrage-Fall stets denselben Fall als Ergebnis geliefert hat. Die Methode, die hierbei für die Prüfung der Reliabilität genutzt wurde, ist die Testwiederholungsmethode. 394 Die Ergebnisse der Relabilitätsprüfung sind in den beiden folgenden Tabellen 70-71 dargestellt. Die Nummer ist eine laufende Nummer bei der Durchführung des Retrievals durch das ontologiegestützte CBR-System. Die Retrieval-Werte für die Ähnlichkeit zu einem der beiden Anfrage-Fälle geben in absteigender Reihenfolge jeweils den Wert der Ähnlichkeit zwischen dem betreffenden Anfrage-Fall und einem Fall aus der Fallbasis an. Die Reihenfolge der Fälle aus der Fallbasis entsprach bei jeder Durchführung der Reihenfolge beim ersten Retrieval (siehe Abbildungen 56 und 60). Die Zeitdauer in Sekunden (Sek.), die das ontologiegestützte CBR-System für die jeweilige Berechnung der Ähnlichkeitswerte benötigt hat, ist in der letzten Spalte aufgeführt.

394

Bei der Testwiederholungsmethode wird die Reliabilität dadurch gemessen, dass die Ergebnisse einer Stichprobe nach wiederholter Vorgabe derselben Eingabedaten miteinander korreliert werden. Gemäß LIENERT/RAATZ (1998), S.180 ff. existieren neben der Testwiederholungsmethode drei weitere Methoden, um die Reliabilität zu bestimmen. Hierbei handelt es sich um die Paralleltestmethode, die Testhalbierungsmethode und die Methode der Konsistenzanalyse. Diese Methoden sind für die Untersuchung nicht von Bedeutung, da sie eine Abwandlung der Testwiederholungsmethode sind und dazu dienen, eine Scheinreliabilität im Rahmen psychologischer Untersuchungen zu verringern.

214

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

Nummer

Retrieval-Werte für die Ähnlichkeit zum Anfrage-Fall 1

Sek.

1

0,64 0,57 0,57 0,56 0,49 0,36 0,30 0,30 0,26 0,18

0,094

2

0,64 0,57 0,57 0,56 0,49 0,36 0,30 0,30 0,26 0,18

0,124

3

0,64 0,57 0,57 0,56 0,49 0,36 0,30 0,30 0,26 0,18

0,126

4

0,64 0,57 0,57 0,56 0,49 0,36 0,30 0,30 0,26 0,18

0,103

5

0,64 0,57 0,57 0,56 0,49 0,36 0,30 0,30 0,26 0,18

0,135

6

0,64 0,57 0,57 0,56 0,49 0,36 0,30 0,30 0,26 0,18

0,100

7

0,64 0,57 0,57 0,56 0,49 0,36 0,30 0,30 0,26 0,18

0,129

8

0,64 0,57 0,57 0,56 0,49 0,36 0,30 0,30 0,26 0,18

0,108

9

0,64 0,57 0,57 0,56 0,49 0,36 0,30 0,30 0,26 0,18

0,103

10

0,64 0,57 0,57 0,56 0,49 0,36 0,30 0,30 0,26 0,18

0,122

Tabelle 70: Ergebnisse der Relabilitätsprüfung zum Retrieval mit dem Anfrage-Fall 1

Nummer

Retrieval-Werte für die Ähnlichkeit zum Anfrage-Fall 2

Sek.

1

0,72 0,67 0,66 0,63 0,57 0,54 0,44 0,41 0,36 0,15

0,098

2

0,72 0,67 0,66 0,63 0,57 0,54 0,44 0,41 0,36 0,15

0,129

3

0,72 0,67 0,66 0,63 0,57 0,54 0,44 0,41 0,36 0,15

0,096

4

0,72 0,67 0,66 0,63 0,57 0,54 0,44 0,41 0,36 0,15

0,143

5

0,72 0,67 0,66 0,63 0,57 0,54 0,44 0,41 0,36 0,15

0,106

6

0,72 0,67 0,66 0,63 0,57 0,54 0,44 0,41 0,36 0,15

0,110

7

0,72 0,67 0,66 0,63 0,57 0,54 0,44 0,41 0,36 0,15

0,121

8

0,72 0,67 0,66 0,63 0,57 0,54 0,44 0,41 0,36 0,15

0,106

9

0,72 0,67 0,66 0,63 0,57 0,54 0,44 0,41 0,36 0,15

0,120

10

0,72 0,67 0,66 0,63 0,57 0,54 0,44 0,41 0,36 0,15

0,104

Tabelle 71: Ergebnisse der Relabilitätsprüfung zum Retrieval mit dem Anfrage-Fall 2

Ontologiegestütztes Case-Based Reasoning für das Management von Projektwissen

215

Für eine kritische Betrachtung der Ergebnisse wird außerdem die Möglichkeit einer Rangvertauschung untersucht. Grundsätzlich ist eine Rangvertauschung möglich, da die Ähnlichkeitsberechnung zwischen zwei Fällen abhängig von anderen Fällen aus der Fallbasis sein kann. Sollten sich die Wertebereiche, z.B. der minimale und maximale Wert für das Attribut „Euro“, ändern, hätte dies Auswirkungen auf die Ähnlichkeitsberechnung beim betroffenen Attribut, da sich der Wert für max d gemäß der Formel 3.14 ändert. Die Wertebereiche ändern sich jedoch nicht automatisch, wenn Fälle aus der Fallbasis gelöscht werden, sondern bleiben konstant, bis sie manuell geändert werden. Eine automatische Rangvertauschung beim Retrieval-Ergebnis durch das Hinzufügen oder Löschen von Fällen aus der Fallbasis ist damit ausgeschlossen. Die Ergebnisse sind stabil, allerdings nicht korrekt, solange eine notwendige manuelle Anpassung der Wertebereiche noch nicht vorgenommen wurde. Die Test-Phase besteht grundsätzlich aus einem Programmtest und einem Benutzertest. Beim Programmtest werden die einzelnen Programm-Module auf logische Konsistenz und Übereinstimmung mit dem Konzept überprüft. Die Prüfung wird vom Programmierer bereits während der Programmierung durchgeführt.395 Da das ontologiegestützte CBR-System, das im Rahmen der vorliegenden Untersuchung erstellt wurde, aus Standardsoftware zusammengesetzt wurde, die bereits vom Softwarehersteller kodiert wurde, ist die Durchführung des Programmtests in Bezug auf die Software bereits durch den Softwarehersteller erfolgt. Der Benutzertest sieht den Test unter Produktionsbedingungen vor, um folgenreiche Fehler aufzudecken, die den Produktionsprozess behindern können. 396 Im Mittelpunkt der Untersuchung steht ausschließlich die Darstellung der Machbarkeit und keine abschließende und voll umfängliche Testphase für ein finales Softwareprodukt. Ein Benutzertest wird daher nicht durchgeführt und sollte vor einem potentiellen Einsatz in einer Produktionsumgebung nachgeholt werden.

395

Vgl. ZÖLLER-GREER (2002), S. 12.

396

Vgl. ZÖLLER-GREER (2002), S. 13.

Fazit

4

217

Fazit

Auf Grund von hohen Abbruchquoten und Wertvernichtungen im derzeitigen Projektmanagement sollte eine Technik erstellt werden, die eine der größten Schwachstellen beim Projektmanagement, das Fehlen einer Wiederverwendung von Projektwissen, beseitigt. Daher war das intendierte Ergebnis dieser Untersuchung die Erstellung einer Technik, die eine Wiederverwendung von Projektwissen ermöglicht und mit Barrieren umgeht, die sich aus dem großen Volumen und der meist natürlichsprachlichen Repräsentation von Projektwissen ergeben. Die Technik, die mit diesen Barrieren umgehen kann, ist das ontologiegestützte Case-Based Reasoning, das die Vorteile von Ontologien und Case-Based Reasoning vereint. Die Ontologie für die Domäne Projektmanagement ermöglicht ein gemeinsames Verstehen des Projektwissens, da sie als Adapter einen Konsens verschiedener individueller Sichtweisen von verschiedenen Akteuren schafft und somit das Projektwissen unter Berücksichtigung der Semantik vergleichbar macht. Das Case-Based Reasoning ermöglicht die Sammlung und Suche von Erfahrungen aus Projekten in Form von gespeicherten Fällen in der von Unsicherheiten geprägten Domäne Projektmanagement. In dieser Untersuchung wurde speziell das Fundamentalproblem des ontologiegestützen Case-Based Reasonings, die Identifikation von hinreichend ähnlichen Fällen und die Selektion mindestens eines ähnlichsten Falls anhand semantischer Ähnlichkeitsindikatoren, untersucht. Die Lösbarkeit des Fundamentalproblems wurde in dieser Untersuchung anhand eines Prototyps demonstriert. Der Prototyp besteht aus dem Ontologie-Tool Protégé, das in Kapitel 3.2.2.2, und dem CBR-Tool MyCBR, das in Kapitel 3.2.2.3 ausgewählt wurde. Die jeweilige Auswahl wurde mit Hilfe des Analytic Hierarchy Process zur Erfüllung der in Kapitel 3.2.1.2 spezifizierten Anforderungen an das ontologiegestützte Case-Based Reasoning durchgeführt. Der Prototyp basiert auf einer Fallbasis, einer Ontologie, Ähnlichkeitsmaßstäben für die Berechnung der lokalen Ähnlichkeitswerte und einem Algorithmus für die Aggregation von lokalen zu globalen Ähnlichkeitswerten. Die Fallbasis, die in Kapitel 3.2.3.2 erstellt und exemplarisch mit zehn manuell vorverarbeiteten Fällen gefüllt wurde, dient der Bereitstellung des Projektwissens. Die Ontologie wurde in Kapitel 3.2.3.3 erstellt und beinhaltet Klassen, Instanzen, Attribute und Relationen, die aus dem natürlichsprachlich repräsentierten Projektwissen extrahiert wurden, und dient der Offenlegung der Semantik des Projektwissens, um einen Vergleich zwischen Fällen zu ermöglichen. Die Ähnlichkeitsmaßstäbe wurden in Kapitel 3.2.3.4 erstellt und ermöglichen die Berechnungen der lokalen Ähnlichkeitswerte für die Ähnlichkeit zwiS. Beißel, Ontologiegestütztes Case-Based Reasoning, DOI 10.1007/978-3-8349-6232-4_4, © Gabler Verlag | Springer Fachmedien Wiesbaden GmbH 2011

218

Fazit

schen jeweils zwei Attributswerten oder zwei Relationswerten. Bei numerischen Attributswerten wird der Abstand, bei symbolischen Attributswerten eine Taxonomie oder Tabelle und bei Relationen die Ähnlichkeit zwischen den relational verknüpften Instanzen unter Berücksichtigung der Ontologie als Ähnlichkeitsmaßstab genutzt. Bei unbekannten Attributswerten wird ein pessimistischer Ansatz genutzt. Der Algorithmus wurde in Kapitel 3.2.3.5 erstellt und besteht aus einem Bottom-Up-Verfahren, bei dem alle lokalen Ähnlichkeitswerte aggregiert werden. Die lokalen Ähnlichkeitswerte werden unter Einbeziehung der Ontologie zu globalen Ähnlichkeitswerten aggregiert und entsprechen der FallÄhnlichkeit. Der Grundgedanke bei der Berechnung von Ähnlichkeitswerten unter Berücksichtigung der Ontologie ist, dass Instanzen, die in der Hierarchie der Ontologie enger zusammen liegen und mehr Attribute gemeinsam haben, ähnlicher zueinander sind als Instanzen, die in der Ontologie weiter auseinander liegen und weniger Attribute gemeinsam haben. Ein Test mit zwei Anfrage-Fällen in Kapitel 3.2.3.7 zeigte die Machbarkeit und die Validität der Technik.

Ausblick

5

219

Ausblick

Nachdem in dieser Untersuchung die Machbarkeit des ontologiegestützten Case-Based Reasonings aufgezeigt wurde, können anschließende Untersuchungen folgen, um das ontologiegestützte CBR-System möglichst vollständig zu automatisieren. Speziell die Eingabe von Projektwissen, die Vorverarbeitung von Projektwissen, die Ontologieerstellung und die Pflege der Fallbasis können automatisiert werden. Um die Eingabe von Projektwissen zu automatisieren, können mögliche Schnittstellen zu bestehenden Systemen in einem Unternehmen untersucht werden. Z.B. würde sich ein Dokumentenmanagementsystem anbieten, um Dokumente ohne manuelle Aktion an das CBR-System zu übertragen. Im Rahmen einer automatisierten Vorverarbeitung von Projektwissen aus natürlichsprachlichen Texten können die Attributs- und Relationswerten von Fällen zur Repräsentation von Projekten ohne manuelle Aktion extrahiert werden. Aufgaben im Rahmen der Extraktion sind insbesondere die Identifikation relevanter Entitäten, die Entfernung von Stoppwörtern und die Reduzierung von Begriffen zu ihrer Grundform. Dazu bietet sich ein Textanalyse-Tool an. Der Markt für Textanalyse-Tools 397 ist jedoch sehr heterogen und es ist fraglich, ob eine Extraktion mit Hilfe eines Textanalyse-Tools vollständig automatisierbar ist. Ein beispielhaftes Problem ist dabei, Gruppen zusammengehörender Wörter richtig zu identifizieren, z.B. „Windows XP“. Außerdem sollte bei der Vorverarbeitung der Umgang mit Rechtschreibfehlern festgelegt werden. Die automatisierte Ontologieerstellung umfasst die Definition der Klassen, der Klassenhierarchie, der Attribute, der Relationen, der Wertebereiche und der Kardinalitäten von Attributen und Relationen sowie die anschließende Erzeugung von Instanzen. Die automatisierte Pflege der Fallbasis beinhaltet die Einarbeitung neuer Fälle basierend auf neuen Dokumenten, die über die Input-Schnittstelle in das System gelangen. Die Ontologie muss erweitert werden, wenn auf Grund neuer Entitäten neue Klassen, neue Attribute, neue Relationen oder Anpassungen von Wertebereichen erforderlich sind. Neben der Zielstellung, das ontologiegestützte CBR-System möglichst vollständig zu automatisieren, gibt es auch potentielle Erweiterungen in der Technik, die untersucht werden können. Es kann z.B. von Vorteil sein, Ruckschlüsse von der Struktur der Dokumente zu erhalten. Die Rückschlüsse könnten unter anderem darauf hindeuten, dass die Relevanz von Entwurfsdokumenten gegenüber finalen Dokumenten als geringer eingeschätzt wird.

397

Zu bekannten Textanalyse-Tools vgl. Fußnote 362, S. 142.

S. Beißel, Ontologiegestütztes Case-Based Reasoning, DOI 10.1007/978-3-8349-6232-4_5, © Gabler Verlag | Springer Fachmedien Wiesbaden GmbH 2011

220

Ausblick Für den produktiven Einsatz des CBR-Systems kann eine Orientierung an den wei-

teren Phasen des Wasserfallmodells, speziell Installation und Wartung, erfolgen. Zuvor sollte der Benutzertest aus der Test-Phase, der den Test innerhalb der Wertschöpfungskette eines Unternehmens vorsieht, unter Berücksichtigung einer vorhandenen Prozessumgebung sowie Hardware- und Software-Infrastruktur durchgeführt werden. Auf diese Weise können mögliche Behinderungen der Wertschöpfungsaktivitäten aufgedeckt werden. Ob die Einführung des ontologiegestützten Case-Based Reasonings betriebswirtschaftlich vorteilhaft ist, richtet sich primär nach dem Aufwand, der für eine zuverlässige Text-Extraktion erbracht werden muss. Die Durchführung des ontologiegestützten CaseBased Reasonings, basierend auf einer vorhandenen Fallbasis und einer implementierten Technik, kann demgegenüber im Bruchteil einer Sekunde durchgeführt werden. 398

398

MyCBR benötigte für die Ähnlichkeitsberechnung innerhalb der exemplarischen Fallbasis ca. 0,1 Sekunden. Vgl. Kapitel 3.2.3.7, S. 214.

Literaturverzeichnis

221

Literaturverzeichnis AAAI (2008) ASSOCIATION FOR THE ADVANCEMENT OF ARTIFICIAL INTELLIGENCE: Case-Based Reasoning, 2008. Online-Publikation im Internet unter der URL „http://www.aaai.org/AITopics/ html/casebased.html“, Zugriff am 26.05.2010. AAMODT/PLAZA (1994) AAMODT, A.; PLAZA, E.: Case-Based Reasoning: Foundational Issues, Methodological Variations, and System Approaches. In: AI Communications, IOS Press, Vol. 7 (1994), No. 1, S. 39-59. Online-Publikation im Internet unter der URL „http://www.iiia.csic.es/ People/enric/AICom.pdf“, Zugriff am 26.05.2010. ABERYSTWYTH UNIVERSITY (2001a) ABERYSTWYTH UNIVERSITY: Getting CASPIAN by FTP, 2001. Online-Publikation im Internet unter der URL „http://www.aber.ac.uk/~dcswww/Research/mbsg/cbrprojects/ getting_caspian.shtml“, Zugriff am 08.06.2010. ABERYSTWYTH UNIVERSITY (2001b) ABERYSTWYTH UNIVERSITY: An Introductory Guide to CASPIAN, 2001. OnlinePublikation im Internet unter der URL „http://www.aber.ac.uk/~dcswww/Research/mbsg/ cbrprojects/Caspianv1pt3.pdf“, Zugriff am 08.06.2010. ABTS/MÜLDER (2009) ABTS, D./ MÜLDER, W.: Grundkurs Wirtschaftsinformatik: Eine kompakte und praxisorientierte Einführung, 6. Auflage, Wiesbaden 2009. ACHANANUPARP/HU/ZHOU/ZHANG (2008) ACHANANUPARP, P./HU, X./ZHOU, X./ZHANG, X. : Utilizing Semantic, Syntactic, and Question Category Information for Automated Digital Reference Services. In: BUCHANAN, G./MASOODIAN, M./CUNNINGHAM, S. J. (Hrsg.): Digital Libraries: Universal and Ubiquitous Access to Information: 11th International Conference on Asian Digital Libraries, ICADL 2008, Bali, Indonesia, December 2008, Proceedings, Berlin und Heidelberg 2008, S. 203-214. S. Beißel, Ontologiegestütztes Case-Based Reasoning, DOI 10.1007/978-3-8349-6232-4, © Gabler Verlag | Springer Fachmedien Wiesbaden GmbH 2011

222

Literaturverzeichnis

ADAM (1996) ADAM, D.: Planung und Entscheidung: Modelle - Ziele - Methoden. Mit Fallstudien und Lösungen, 4. Auflage, Wiesbaden 1996. AHLERT (2003) AHLERT, M.: Einsatz des Analytic Hierarchy Process im Relationship Marketing: Eine Analyse strategischer Optionen bei Dienstleistungsunternehmen, Wiesbaden 2003. AHNERT (2009) AHNERT, S.: Virtuelle Maschinen mit VMware und Microsoft: Für Entwicklung, Schulung, Test und Produktion, 3. Auflage, München 2009. ANDERSEN/GRUDE/HAUG (2004) ANDERSEN, E. S./GRUDE, K. V./HAUG, T.: Goal Directed Project Management - Effective Techniques and Strategies, 3. Auflage, London und Sterling 2004. ANDONGNDOU/LAXTON/MARSH/PRESSLER (2009) ANDONGNDOU, W./LAXTON, D./MARSH, R./PRESSLER, R.: Project Management, Kapstadt 2009. ARROYO/LARA/DING/STOLLBERG/FENSEL (2004) ARROYO, S./LARA, R./DING, Y./STOLLBERG, M./FENSEL, D.: Semantic Web Languages Strengths And Weakness, INSTITUT FÜR INFORMATIK, UNIVERSITÄT INNSBRUCK, 2004. Online-Publikation im Internet unter der URL „http://citeseerx.ist.psu.edu/viewdoc/summary? doi=10.1.1.88.5910“, Zugriff am 26.05.2010. ARTIFICIAL INTELLIGENCE APPLICATIONS INSTITUTE (2002a) ARTIFICIAL INTELLIGENCE APPLICATIONS INSTITUTE, SCHOOL VERSITY OF

OF INFORMATICS,

THE UNI-

EDINBURGH: CBR Tools from AIAI, 2002. Online-Publikation im Internet un-

ter der URL „http://www.aiai.ed.ac.uk/project/cbr/cbrtools.html“, Zugriff am 08.06. 2010.

Literaturverzeichnis

223

ARTIFICIAL INTELLIGENCE APPLICATIONS INSTITUTE (2002b) ARTIFICIAL INTELLIGENCE APPLICATIONS INSTITUTE, SCHOOL VERSITY OF

OF INFORMATICS,

THE UNI-

EDINBURGH: AIAI CBR Shell, 2002. Online-Publikation im Internet unter der

URL „http://www.aiai.ed.ac.uk/project/cbr/CBRDistrib/“, Zugriff am 08.06.2010. AUCOIN (2007) AUCOIN, B. M.: Right-Brain Project Management - A Complementary Approach, Vienna 2007. AUGEO SOFTWARE (2008) AUGEO SOFTWARE: Augeo Software | Projektportfolio Management | Unternehmen | über uns, 2008. Online-Publikation im Internet unter der URL „http://www.augeo.com/de/ unternehmen.html“, Zugriff am 08.06.2010. AVRAMENKO/KRASLAWSKI (2008) AVRAMENKO, Y./KRASLAWSKI, A.: Case Based Design: Applications in Process Engineering, Berlin und Heidelberg 2008. BADACH/HOFFMANN (2007) BADACH, A./HOFFMANN, E.: Technik der IP-Netze. TCP/IP incl. IPv6. Funktionsweise, Protokolle und Dienste, 2. Auflage, München und Wien 2007. BAGLIONI/GIOVANNETTI/MASSEROTTI/RENSO/SPINSANTI (2008) BAGLIONI, M./GIOVANNETTI, E./MASSEROTTI, M. V./RENSO, C./SPINSANTI, L.: Ontologysupported Querying of Geographical Databases. In: Transactions in GIS, Vol. 12 (2008), Supplement 1, S. 31-44. BAUDER (2008) BAUDER, I.: Microsoft SQL Server 2008 für Administratoren, München 2008. BELL (1985) BELL, D.: Die nachindustrielle Gesellschaft, 2. Auflage, Frankfurt am Main 1985.

224

Literaturverzeichnis

BELLIGER/KRIEGER (2007) BELLIGER, A./KRIEGER, D.: Wissensmanagement für KMU, Zürich 2007. BENDLER (2002) BENDLER, A.: Wissensmanagement im internationalen Vertrieb produzierender Unternehmen - Ein Modell zur Auswahl von Wissensmanagement-Maßnahmen in Abhängigkeit unterschiedlicher Internationalisierungsstrategien, Aachen 2002. BERGMANN (1998) BERGMANN, R.: On the Use of Taxonomies for Representing Case Features and Local Similarity Measures, 1998. Online-Publikation im Internet unter der URL „http://citeseerx. ist.psu.edu/viewdoc/summary?doi=10.1.1.24.9767“, Zugriff am 29.10.2010. BERGMANN (2002) BERGMANN, R.: Experience Management: Foundations, Development Methodology, and Internet Based Applications, Berlin 2002. BERGMANN/ALTHOFF/BREEN/WESS/MANAGO/TRAPHÖNER/GÖKER (2003) BERGMANN, R./ALTHOFF, K.-D./BREEN, S./WESS, S./MANAGO, M./TRAPHÖNER, R./GÖKER, M.: Developing Industrial Case-Based Reasoning Applications: The INRECA Methodology, 2. Auflage, Berlin und Heidelberg 2003. BIETHAHN/MUCKSCH/RUF (2004) BIETHAHN, J./MUCKSCH, H./RUF, W.: Ganzheitliches Informationsmangement - Band I: Grundlagen, 6. Auflage, München 2004. BIRATTARI (2009) BIRATTARI, M.: Tuning Metaheuristics: A Machine Learning Perspective, 2. Auflage, Berlin und Heidelberg 2009. BLOHM/LÜDER (1995) BLOHM, H./LÜDER, K.: Investition: Schwachstellenanalyse des Investitionsbereichs und Investitionsrechnung, 8. Auflage, München 1995.

Literaturverzeichnis

225

BOEHM (1981) BOEHM, B. W.: Software Engineering Economics, Reihe: Prentice Hall Advances in Computing Science and Technology, London, Sydney, Toronto et. al. 1981. BOEHM (1988) BOEHM, B. W.: A Spiral Model of Software Development and Enhancement. In: IEEE Computer, Vol. 21 (1988), No. 5, S. 61-72.

BÖHM (2005) BÖHM, R.: Methoden und Techniken der Systementwicklung, Zürich 2005. BORTZ/DÖRING (2006) BORTZ J./DÖRING, N.: Forschungsmethoden und Evaluation, 4. Auflage, Heidelberg 2006. BREMNER/DEMAINE/ERICKSON/IACONO/LANGERMAN/MORIN/TOUSSAINT (2005) BREMNER, D./DEMAINE, E./ERICKSON, J./IACONO, J./LANGERMAN, S./MORIN, P./TOUSSAINT,

G.: Output-Sensitive Algorithms for Computing Nearest-Neighbour Decision

Boundaries. In: Discrete and Computational Geometry, Vol. 33 (2005), No. 4, S. 593-604. BRUGGER (2005) BRUGGER, R.: IT-Projekte strukturiert realisieren: Situationen analysieren, Lösungen konzipieren, Vorgehen systematisieren, Sachverhalte visualisieren, UML und EPKs nutzen, 2. Auflage, Wiesbaden 2005. BSI (2003) BUNDESAMT FÜR SICHERHEIT IN DER INFORMATIONSTECHNIK: Patch- und Update-Management, 2003. Online-Publikation im Internet unter der URL „https://www.bsi.bund.de/ BSIFB/DE/ITSicherheit/SchuetzenAberWie/PatchManagement/patchmanagement_node. html“, Zugriff am 09.06.2010.

226

Literaturverzeichnis

BSI (2009) BUNDESAMT

FÜR

SICHERHEIT

IN DER INFORMATIONSTECHNIK:

Leitfaden Informationssi-

cherheit - IT-Grundschutz kompakt, 2009. Online-Publikation im Internet unter der URL „https://www.bsi.bund.de/cae/servlet/contentblob/540280/publicationFile/34662/GS-Leitfa den_pdf.pdf“, Zugriff am 26.05.2010. BUDE (1987) BUDE, H.: Wissen. In: GRUBITZSCH, S./REXILIUS, G. (Hrsg.): Psychologische Grundbegriffe, Hamburg 1987, S. 1228-1230. BURGHARDT (2007) BURGHARDT, M.: Einführung in Projektmanagement: Definition, Planung, Kontrolle und Abschluss, 5. Auflage, Erlangen 2007. CARDOSO (2007) CARDOSO, J.: The Semantic Web Vision: Where are We?, 2007. Online-Publikation im Internet unter der URL „http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.97.4906“, Zugriff am 24.10.2010. CHAMBERS (1999) CHAMBERS , L. D.: Practical Handbook of Genetic Algorithms: Complex Coding Systems, Volume III, Florida 1999. CHAMONI/GLUCHOWSKI/HAHNE (2005) CHAMONI, P./GLUCHOWSKI, P./HAHNE, M.: Business Information Warehouse: Perspektiven betrieblicher Informationsversorgung und Entscheidungsunterstützung auf der Basis von SAP-Systemen, Berlin, Heidelberg und New York 2005. CHARNES/COOPER/RHODES (1978) CHARNES, A./COOPER, W. W./RHODES, E.: Measuring the efficiency of decision making units. In: European Journal of Operational Research, Vol. 2 (1978), No. 6, S. 429-444.

Literaturverzeichnis

227

CHEN (1976) CHEN, P. P.-S.: The Entity-Relationship Modell - Toward a Unified View of Data, 1976. Online-Publikation im Internet unter der URL „http://csc.lsu.edu/news/erd.pdf“, Zugriff am 26.05.2010. CHISEL (2004) COMPUTER HUMAN INTERACTION & SOFTWARE ENGINEERING LAB (CHISEL), UNIVERSITY OF

VICTORIA: Jambalaya, 2004. Online-Publikation im Internet unter der URL „http://

www.thechiselgroup.org/jambalaya“, Zugriff am 08.06.2010. CONKLIN (2000) CONKLIN, E. J.: Designing Organisational Memory: Preserving Intellectual Assets in a Knowledge Economy, 2000. Online-Publikation im Internet unter der URL „http:// cognexus.org/dom.pdf“, Zugriff am 26.05.2010. COOPER/REIMANN/CRONIN (2010) COOPER/REIMANN/CRONIN: About Face: Interface und Interaction Design, Heidelberg, München, Landsberg, Frechen und Hamburg 2010. CORMEN/LEIERSON/RIVEST/STEIN (2007) CORMEN, T. H./LEIERSON, C. E./RIVEST, R./STEIN, C.: Algorithmen - Eine Einführung, 2. Auflage, München 2007. DAEMI-AHWAZI (2005) DAEMI-AHWAZI, A.: Entropiebasierte Bewertung von Ontologien, Dissertation, Karlsruhe 2005. DARPA (2003) DEFENSE ADVANCED RESEARCH PROJECTS AGENCY: The DARPA Agent Markup Language Homepage, 2003. Online-Publikation im Internet unter der URL „http://www.daml. org/about.html“, Zugriff am 26.05.2010.

228

Literaturverzeichnis

DARPA (2004) DEFENSE ADVANCED RESEARCH PROJECTS AGENCY: DAML Ontology Library, 2004. Online-Publikation im Internet unter der URL „http://www.daml.org/ontologies/“, Zugriff am 08.06.2010. DAVID/ALLA (2005) DAVID, R./ALLA, H.: Discrete, Continuous, and Hybrid PETRI Nets, Berlin und Heidelberg 2005. DE MÁNTARAS/PLAZA (1997) DE MÁNTARAS, R. L./PLAZA, E.: Case-Based

Reasoning: an Overview. In: AI Communica-

tions, Vol. 10 (1997), No. 1, S. 21-29. DEMIRIZ/CIHAN/KULA (2009) DEMIRIZ, A./CIHAN, A./KULA, U.: Analyzing Price Data to Determine Positive and Negative Product Associations. In: LEUNG, C. S./LEE, M./CHAN, J. H. (Hrsg.): Neural Information Processing: 16th International Conference, ICONIP 2009, Bangkok, Thailand, December 1-5, 2009, Proceedings, Part I, Berlin und Heidelberg 2009, S. 846-855. DENNY (2002) DENNY, M.: Ontology editor survey results, 2002. Online-Publikation im Internet unter der URL „http://www.xml.com/2002/11/06/Ontology_Editor_Survey.html“, Zugriff am 24.10. 2010. DENNY (2004) DENNY, M.: Ontology editor survey results, 2004. Online-Publikation im Internet unter der URL „www.nitrc.org/docman/view.php/10/31/Ontology_Editor_Survey_2004.pdf“, Zugriff am 24.10.2010. DFKI (2007) DEUTSCHES FORSCHUNGSZENTRUM

FÜR

KÜNSTLICHE INTELLIGENZ GMBH (DFKI):

MyCBR, 2007. Online-Publikation im Internet unter der URL „http://mycbr-project.net/“, Zugriff am 08.06.2010.

Literaturverzeichnis

229

DFKI (2009) DEUTSCHES FORSCHUNGSZENTRUM

FÜR

KÜNSTLICHE INTELLIGENZ GMBH (DFKI):

MyCBR Tutorial, 2009. Online-Publikation im Internet unter der URL „http://mycbrproject.net/tutorial.html“, Zugriff am 08.06.2010. DFKI (2010) DEUTSCHES FORSCHUNGSZENTRUM FÜR KÜNSTLICHE INTELLIGENZ GMBH (DFKI): Intelligente Lösungen für die Wissensgesellschaft - DFKI, 2010. Online-Publikation im Internet unter der URL „http://www.dfki.de/web“, Zugriff am 08.06.2010. DIN 55350 (2008) DEUTSCHES INSTITUT FÜR NORMUNG E.V.: DIN 55350, Auflage 2008-05, Berlin 2008. DIN 66001 (1983) DEUTSCHES INSTITUT FÜR NORMUNG E.V.: DIN 66001, Auflage 1983-12, Berlin 1983. DIN 69901 (2009) DEUTSCHES INSTITUT FÜR NORMUNG E.V.: DIN 69901, Auflage 2009-01, Berlin 2009.

DITTMANN/PENZEL (2004) DITTMANN, L./PENZEL, J.: PLATONS Gütekriterium für Ontologien. In: ULRICH, F. (Hrsg.): Wissenschaftstheorie in Ökonomie und Wirtschaftsinformatik - Theoriebildung und -bewertung, Ontologien, Wissensmanagement, Wiesbaden 2004, S. 457-478. DRAKE (1998) DRAKE, P. R.: Using the Analytic Hierarchy Process in Engineering Education. In: International Journal of Engineering Education, Vol. 14 (1998), No. 3, S. 191-196. ECK (1997) ECK, C.D.: Wissen - ein neues Paradigma des Managements: Wissensmanagement und Lernfähigkeit der Organisation als Schlüsselkonzept des Managements. In: Die Unternehmung, 51. Jg. (1997), H. 3, S. 155-179.

230

Literaturverzeichnis

ECKERT (2007) ECKERT, C.: IT-Sicherheit: Konzepte - Verfahren - Protokolle, 5., überarbeitete Auflage, München 2007. EIRINAKI/MAVROEIDIS/TSATSARONIS/VAZIRGIANNIS (2005) EIRINAKI, M./MAVROEIDIS, D./TSATSARONIS, G./VAZIRGIANNIS, M.: Introducing Semantics in Web Personalization: The Role of Ontologies.. In: ACKERMANN, M./BERENDT, B./ GROBELNIK, M./HOTHO, A./MLADENIC, D./SEMERARO, G./SPILIOPOULOU, M./STUMME, G./SVATEK, V./VAN SOMEREN, M. (Hrsg.): Semantics, Web and Mining - Joint International Workshops, EWMF 2005 and KDO 2005, Porto, Portugal, October 3-7, 2005, Revised Selected Papers, Berlin und Heidelberg 2005, S. 147-162. ENGEL/TAMDJIDI/QUADEJACOB (2008) ENGEL, C./TAMDJIDI, A./QUADEJACOB, N.: Ergebnisse der Projektmanagement Studie 2008 - Erfolg und Scheitern im Projektmanagement -, Frankfurt am Main 2008. Online-Publikation im Internet unter der URL „http://www.gpm-ipma.de/fileadmin/user_upload/KnowHow/Ergebnisse_Erfolg_und_Scheitern-Studie_2008.pdf“, Zugriff am 26.05.2010. E-TEACHING.ORG (2005) E-TEACHING.ORG:

Glossar: RDFS, 2005. Online-Publikation im Internet unter der URL

„http://www.e-teaching.org/glossar/rdfs“, Zugriff am 26.05.2010. EXPERT CHOICE (2009) EXPERT CHOICE INC.: Robust Decision-Support and Analysis Platform - Expert Choice, 2009. Online-Publikation im Internet unter der URL „http://www.expertchoice.com/ products/ec11.html“, Zugriff am 26.05.2010. FALKENAUER (1998) FALKENAUER, E.: Genetic Algorithms and Grouping Problems, West Sussex 1998. FELBERT (1998) FELBERT, D.: Wissensmanagement in der unternehmerischen Praxis. In: PAWLOWSKY, P. (Hrsg.): Wissensmanagement - Erfahrungen und Perspektiven, Wiesbaden 1998, S. 119141.

Literaturverzeichnis

231

FENSEL (2004) FENSEL, D.: Ontologies: A Silver Bullet for Knowledge Management and Electronic Commerce, 2. Auflage, Berlin und Heidelberg 2004. FERSTL/SINZ (2006) FERSTL, O. K./SINZ, E. J.: Grundlagen der Wirtschaftsinformatik, 5. Auflage, München 2006. FINK/SCHNEIDEREIT/VOß (2005) FINK, A./SCHNEIDEREIT, G./VOß, S.: Grundlagen der Wirtschaftsinformatik, 2. Auflage, Heidelberg 2005. FINNIE/SUN (2004) FINNIE, G. R./SUN, Z.: Intelligent Techniques in E-Commerce: A Case Based Reasoning Perspective, Berlin und Heidelberg 2004. FREUDENTHALER (2008) FREUDENTHALER, B.: Case-Based Reasoning (CBR): Grundlagen und ausgewählte Anwendungsgebiete des fallbasierten Schließens, Saarbrücken 2008. FREUND (2007) FREUND, T.: Software Engineering durch Modellierung wissensintensiver Entwicklungsprozesse, Berlin 2007. FRIEDMANN (2006) FRIEDMANN, K.: Deutsche IT-Manager planen schlecht, 2006. Online-Publikation im Internet unter der URL „http://www.tcw.de/uploads/html/news/pressespiegel/IT-Manage ment.pdf“, Zugriff am 19.10.2010.

232

Literaturverzeichnis

FZI/AIFB (2004) FORSCHUNGSZENTRUM INFORMATIK (FZI)/INSTITUT

FÜR

ANGEWANDTE INFORMATIK

UND

FORMALE BESCHREIBUNGSVERFAHREN (AIFB) der UNIVERSITÄT KARLSRUHE (TH): TextToOnto | Download TextToOnto software for free at SourceForge.net, 2004. OnlinePublikation im Internet unter der URL „http://sourceforge.net/projects/texttoonto/“, Zugriff am 08.06.2010. GARROD/PICKERING (1999) GARROD, S./PICKERING, M.: Language Processing, East Sussex 1999. GIRAULT/VALK (2003) GIRAULT, C./VALK, R.: PETRI Nets for Systems Engineering: A Guide to Modeling, Verification, and Applications, Berlin und Heidelberg 2003. GÖTZE/DEUTSCHMANN/LINK (2002) GÖTZE, W./DEUTSCHMANN, C./LINK, H.: Statistik, München 2002. GÓMEZ-ALBARRÁN/GONZÁLEZ-CALERO (2001) GÓMEZ-ALBARRÁN, M./GONZÁLEZ-CALERO, P. A.: Applying Case-Based Reasoning to support Dynamic Framework Documentation. In: International Journal of Software Engineering and Knowledge Engineering, Vol. 11 (2001), No. 4, S. 479-502. GOLBECK/ALFORD//HENDLER (2005) GOLBECK, J./ALFORD, A. und R./HENDLER, J.: Organization and Structure of Information Using Semantic Web Technologies. In: PROCTOR, R. W./VU, K.-P. L. (Hrsg.): Handbook of Human Factors in Web Design, New Jersey 2005, S. 176-189. GPM (2007) GPM DEUTSCHE GESELLSCHAFT

FÜR

PROJEKTMANAGEMENT E. V.: „Der Projektmanage-

ment-Boom setzt sich fort“, 2007. Online-Publikation im Internet unter der URL „http:// www.pmaktuell.org/uploads/PMAktuell-200701/PMAktuell-200701-091-Public.pdf“, Zugriff am 26.05.2010.

Literaturverzeichnis

233

GRIMES (2010) GRIMES, S.: Unstructured Data and the 80 Percent Rule, 2010. Online-Publikation im Internet unter der URL „http://clarabridge.com/default.aspx?tabid=137&ModuleID=635& ArticleID=551“, Zugriff am 18.10.2010. GRÖGER (2004) GRÖGER, M.: Projektmanagement: Abenteuer Wertvernichtung - Eine Wirtschaftlichkeitsstudie zum Projektmanagement in deutschen Organisationen - Kurzversion, 2004. OnlinePublikation im Internet unter der URL „http://www.mba-beratung.de/download/MBA_ 001_s.pdf“, Zugriff am 18.10.2010. GROUP FOR ARTIFICIAL INTELLIGENCE APPLICATIONS (2010) GROUP

FOR

ARTIFICIAL INTELLIGENCE APPLICATIONS, DEPARTMENT

OF

SOFTWARE ENGI-

NEERING AND ARTIFICIAL INTELLIGENCE, UNIVERSIDAD COMPLUTENSE DE MADRID: GAIA -

GROUP OF ARTIFICIAL INTELLIGENCE APPLICATIONS. Online-Publikation im Internet unter der URL „http://gaia.fdi.ucm.es/“, Zugriff am 08.06.2010. GRUBER (1993) GRUBER, T. R.: A Translation Approach to Portable Ontology Specifications. In: Knowledge Acquisition, Vol. 5 (1993), No. 2, S. 199-220. GRUBER (1995) GRUBER, T. R.: Toward Principles for the Design of Ontologies Used for Knowledge Sharing. In: International Journal of Human-Computer Studies, Vol. 43 (1995), No. 5-6, S. 907928. GUARINO/GIARETTA (1995) GUARINO, N./GIARETTA, P.: Ontologies and Knowledge Bases - Towards a Terminological Clarification. In: MARS, N. (Hrsg.): In Towards Very Large Knowledge Bases: Knowledge Building and Knowledge Sharing, Amsterdam 1995, S. 25-32.

234

Literaturverzeichnis

GÜLDENBERG (2003) GÜLDENBERG, S.: Wissensmanagement und Wissenscontrolling in lernenden Organisationen - Ein systemtheoretischer Ansatz, 4. Auflage, Wiesbaden 2003. HAASE/STOJANOVIC (2005) HAASE, P./STOJANOVIC, L.: Consistent Evolution of OWL Ontologies. In: EUZENAT, J./ GÓMEZ-PÉREZ, A. (Hrsg.): The Semantic Web: Research and Applications: Second European Semantic Web Conference, ESWC 2005, Heraklion, Crete, Greece, May 29-June 1, 2005, Proceedings, Heidelberg und Berlin 2005, S. 182-197. HAHN/ABELS/HAAK (2004) HAHN, A./ABELS, S./HAAK, L.: Web Intelligence: Veröffentlichungen zum Seminar, 2004. Online-Publikation im Internet unter der URL „http://oops.uni-oldenburg.de/frontdoor. php?source_opus=497“, Zugriff am 16.10.2010. HAHN/RAMSCAR (2001) HAHN, U./RAMSCAR, M.: Similarity and Categorization, Oxford und New York 2001. HAMMING (1950) HAMMING, R. W.: Error Detecting and Error Correcting. In: Bell System Technical Journal, Vol. 29 (1950), No. 2, S. 147-160. HAREL/FELDMAN (2006) HAREL, D./FELDMAN, Y.: Algorithmik: Die Kunst des Rechnens, Berlin und Heidelberg 2006. HEINRICH (2007) HEINRICH, G.: Allgemeine Systemanalyse, München 2007. HEINRICH/LEHNER (2005) HEINRICH L. J./LEHNER, F.: Informationsmanagement, 8. Auflage, München 2005.

Literaturverzeichnis

235

HEWLETT-PACKARD (2003) HEWLETT-PACKARD DEVELOPMENT COMPANY, LP: Jena Semantic Web Framework, 2003. Online-Publikation im Internet unter der URL „http://jena.sourceforge.net/index.html“, Zugriff am 08.06.2010. HINDEL/HÖRMANN/MÜLLER/SCHMIED (2009) HINDEL, B./HÖRMANN, K./MÜLLER, M./SCHMIED, J.: Basiswissen Software-Projektmanagement: Aus- und Weiterbildung zum Certified Professional for Project Management nach iSQI-Standard, 3. Auflage, Heidelberg 2009. HOFFMANN (2008) HOFFMANN, D. W.: Software-Qualität, Berlin 2008. HORROCKS/MCGUINNESS/WELTY (2003) HORROCKS, I./MCGUINNESS, D. L./WELTY, A. C.: Digital Libraries and Web-Based Information Systems. In: BAADER, F./CALVANESE, D./MCGUINNESS, D. L./ NARDI, D. PATELSCHNEIDER, P. F. (Hrsg.): The Description Logic Handbook: Theory, Implementation and Applications, Cambridge 2003, S. 427-449. HORROCKS/PATEL-SCHNEIDER (2003) HORROCKS, I./PATEL-SCHNEIDER, P. F.: A Proposal for an OWL Rules Language, Draft Version of 16 October 2003. Online-Publikation im Internet unter der URL „http://www. cs.manchester.ac.uk/~horrocks/DAML/Rules/“, Zugriff am 26.05.2010. HORROCKS/PATEL-SCHNEIDER/BOLEY/TABET/GROSOF/DEAN (2004) HORROCKS, I./PATEL-SCHNEIDER, P. F./BOLEY, H./TABET, S./GROSOF, B./DEAN, M.: SWRL: A Semantic Web Rule Language Combining OWL and RuleML, W3C Member Submission 21 May 2004. Online-Publikation im Internet unter der URL „http://www.w3. org/Submission/SWRL/“, Zugriff am 26.05.2010.

236

Literaturverzeichnis

HORROCKS/PATEL-SCHNEIDER/VAN HARMELEN (2003) HORROCKS, I./PATEL-SCHNEIDER, P. F./VAN HARMELEN, F.: From SHIQ and RDF to OWL: The Making of a Web Ontology Language, 2003. Online-Publikation im Internet unter der URL „http://www.cs.manchester.ac.uk/~horrocks/Publications/download/2003/HoPH03a. pdf“, Zugriff am 26.05.2010. HÜBLER (2005) HÜBLER, O.: Einführung in die empirische Wirtschaftsforschung: Probleme, Methoden und Anwendungen, München 2005. HÜGENS (2008) HÜGENS, T.: Balanced Scorecard und Ursache-Wirkungsbeziehungen - Kausale Modellierung und Simulation von Ursache-Wirkungsbeziehungen in Balanced Scorecards mithilfe von Methoden des Qualitative Reasoning, Dissertation, Wiesbaden 2008. HUMPL (2004) HUMPL, B.: Transfer von Erfahrungen: Ein Beitrag zur Leistungssteigerung in projektorientierten Organisationen, Wiesbaden 2004. HUNT (2003) HUNT, C.: TCP/IP Netzwerk-Administration, 3. Auflage, Köln 2003. HUYCK (2000) HUYCK, C. R.: A Practical System for Human-Like Parsing. In: HORN, W. (Hrsg.): ECAI 2000: 14th European Conference on Artificial Intelligence, August 20-25, 2000, Berlin, S. 436-440. IFM (2004) INSTITUE

FOR

MANUFACTURING, UNIVERSITY

OF

CAMBRIDGE: Analytical Hierarchy Pro-

cess, 2004. Online-Publikation im Internet unter der URL „http://www.ifm.eng.cam.ac.uk/ dstools/choosing/ahp.html“, Zugriff am 26.05.2010. IMMLER (1973) IMMLER, H.: Arbeitsteilung, Kooperation und Wirtschaftssystem, Berlin 1973.

Literaturverzeichnis

237

INDUCTIVE SOLUTIONS (2000) INDUCTIVE SOLUTIONS, INC.:

Induce-It - User Manual, New York 2000.

INDUCTIVE SOLUTIONS (2006) INDUCTIVE SOLUTIONS, INC.: INDUCTIVE SOLUTIONS, INC. - Induce-It - Case Based Reasoning FAQ, 2006. Online-Publikation im Internet unter der URL „http://www.inductive.com/ softcase.htm“, Zugriff am 08.06.2010. INSTITUT „JOŽEF STEFAN“ (2007) INSTITUT „JOŽEF STEFAN“: OntoGen » About, 2007. Online-Publikation im Internet unter der URL „http://ontogen.ijs.si/“, Zugriff am 08.06.2010. ISO-12207 (2008) INTERNATIONAL ORGANIZATION

FOR

STANDARDIZATION (ISO): ISO/IEC 12207 - Systems

and software engineering - Software life cycle processes, Auflage 2008, Geneva 2008. ISO-27001 (2005) INTERNATIONAL ORGANIZATION FOR STANDARDIZATION (ISO): ISO/IEC 27001 - Information technology - Security techniques - Information security management systems - Requirements, Auflage 2005, Geneva 2005. ISO-9000 (2005) INTERNATIONAL ORGANIZATION FOR STANDARDIZATION (ISO): ISO/IEC 9000 - Qualitätsmanagementsysteme - Grundlagen und Begriffe, Auflage 2005, Geneva 2005. ISO-9126-1 (2001) INTERNATIONAL ORGANIZATION FOR STANDARDIZATION (ISO): ISO/IEC 9126-1 - Software Engineering - Product quality - Part 1: Quality model, Auflage 2001, Geneva 2001. JUNG (2006) JUNG, H.: Allgemeine Betriebswirtschaftslehre, 10. Auflage, München 2006.

238

Literaturverzeichnis

KANNEMANN (1992) KANNEMANN, K.: Unix. Das Betriebssystem und die Shells. Eine grundlegende Einführung, Braunschweig und Wiesbaden 1992. KANT (2005) KANT, I.: Kritik der reinen Vernunft. In: GODMAN, P. (Hrsg.): IMMANUEL KANT: Kritik der reinen Vernunft, Wiesbaden 2005. KERZNER (2009) KERZNER, H.: Project Management - A Systems Approach to Planning, Scheduling, and Controlling, 10. Auflage, New Jersey 2009. KLEIN (2004) KLEIN, M.: Change Management for Distributed Ontologies, Dissertation, Amsterdam 2004. KMI (2005) KNOWLEDGE MEDIA INSTITUTE, THE OPEN UNIVERSITY: Apollo Home Page, 2005. OnlinePublikation im Internet unter der URL „http://apollo.open.ac.uk/“, Zugriff am 08.06.2010. KNUBLAUCH/RECTOR/STEVENS/WROE (2004) KNUBLAUCH, H./RECTOR, A./STEVENS, R./WROE, C.: A Practical Guide To Building OWL Ontologies Using The Protégé-OWL Plugin and CO-ODE Tools - Edition 1.0, 2004. Online-Publikation im Internet unter der URL „http://www.co-ode.org/resources/tutorials/ ProtegeOWLTutorial.pdf“, Zugriff am 26.05.2010. KOLODNER (1993) KOLODNER, J. L.: Case-Based Reasoning, San Mateo 1993. KONONENKO/KUKAR (2007) KONONENKO, I./KUKAR, M.: Machine Learning and Data Mining: Introduction to Principles and Algorithms, West Sussex 2007.

Literaturverzeichnis

239

KRAAK (1991) KRAAK, B.: Der riskante Weg von der Information zum Wissen: über dogmatische und konformistische Urteilsbildung, Göttingen 1991. KROGSTIE/HALPIN/SIAU (2005) KROGSTIE, H./HALPIN, T. /SIAU, K.: Information Modeling Methods and Methodologies, Hershey und London 2005. KSL (2008) KNOWLEDGE SYSTEMS, AI LABORATORY (KSL), DEPARTMENT

OF

COMPUTER SCIENCE,

STANFORD UNIVERSITY: Ontolingua Home Page, 2008. Online-Publikation im Internet unter der URL „http://www.ksl.stanford.edu/software/ontolingua/“, Zugriff am 07.11.2010. KURBEL/DORNHOFF (1992) KURBEL, K./DORNHOFF, P.: Aufwandsplanung zur Unterstützung des Managements von Softwareentwicklungsprojekten, Arbeitsbericht Nr. 11 des INSTITUTS FÜR WIRTSCHAFTSINFORMATIK,

Münster 1992.

KURBEL/DORNHOFF (1993) KURBEL, K./DORNHOFF, P.: Aufwandschätzung für Software-Entwicklungsprojekte mit Hilfe fallbasierter Wissensverarbeitung. In: Zeitschrift für Betriebswirtschaft, 63. Jg. (1993), H. 10, Wiesbaden 1993, S. 1047-1065. LEAKE (1996) LEAKE, D. B.: CBR in Context: The Present and Future. In: LEAKE, D. B. (Hrsg.): CaseBased Reasoning: Experiences, Lessons, and Future Directions, Menlo Park, Kalifornien 1996, S. 3-30. Online-Publikation im Internet unter der URL „http://www.cs.indiana.edu/~ leake/papers/p-96-01.pdf“, Zugriff am 26.05.2010. LEFEBVRE/GAUTHIER/TADIE/DUC/ACHABA (2005) LEFEBVRE, B./GAUTHIER, G./TADIE, S./DUC, T. H./ACHABA, H.: Competence Ontology for Domain Knowledge Dissemination and Retrieval. In: Applied Artificial Intelligence, Vol. 19 (2005), No. 9-10, S. 845-859.

240

Literaturverzeichnis

LENZ/HÜBNER/KUNZE (1998) LENZ, M./HÜBNER, A./KUNZE, M.: Question Answering with Textual CBR. In: ANDREASEN,

T./LARSEN, H. L./CHRISTIANSEN, H. (Hrsg.): Flexible Query Answering Systems:

Third International Conference, FQAS'98, Roskilde, Denmark, May 13-15, 1998, Proceedings, Berlin und Heidelberg 1998, S. 236-247. LESSIG (2006) LESSIG, A. G.: Linux Firewalls - Ein praktischer Einstieg, 2. Auflage, Köln 2006. LIEBIG/NOPPENS (2004) LIEBIG, T./NOPPENS, O.: OntoTrack, INSTITUT FÜR

INGENIEURWISSENSCHAFTEN

UND

FÜR

KÜNSTLICHE INTELLIGENZ, FAKULTÄT

INFORMATIK, UNIVERSITÄT ULM, 2004. Online-

Publikation im Internet unter der URL „http://www.informatik.uni-ulm.de/ki/ontotrack/“, Zugriff am 08.06.2010. LIENERT/RAATZ (1998) LIENERT, G. A./RAATZ, U.: Testaufbau und Testanalyse, 6. Auflage, Weinheim 1998. LIN/HARDING/SHAHBAZ (2004) LIN, H.-K./HARDING, J. A./SHAHBAZ, M.: Manufacturing System Engineering Ontology for Semantic Interoperability across Extended Project Teams. In: International Journal of Production Research, Vol. 42 (2004), No. 24, S. 5099-5118. LIPPE (2006) LIPPE, W.-M.: Soft-Computing: mit Neuronalen Netzen, Fuzzy-Logic und evolutionären Algorithmen, Berlin und Heidelberg 2006. LUGER (2003) LUGER, G. F.: Künstliche Intelligenz - Strategien zur Lösung komplexer Probleme, 4. Auflage, München 2003. LUSTI (2002) LUSTI, M.: Data Warehousing und Data Mining: Eine Einführung in entscheidungsunterstützende Systeme, 2. Auflage, Berlin, Heidelberg und New York 2002.

Literaturverzeichnis

241

MADAUSS (2000) MADAUSS, B. J.: Handbuch Projektmanagement, 6. Auflage, Stuttgart 2000. MAEDCHE/STAAB/STOJANOVIC/STUDER/SURE (2001) MAEDCHE, A./STAAB, S./STOJANOVIC, N./STUDER, R./SURE, Y.: A Framework for Developing Semantic Web Portals. In: READ, B. (Hrsg.): Advances in Databases: 18th British National Conference on Databases, BNCOD 18, Chilton, UK, July 9-11, 2001, Proceedings, Berlin und Heidelberg 2001, S. 1-22. MAIER (2007) MAIER, R.: Knowledge Management Systems: Information and Communication Technologies for Knowledge Management, 3. Auflage, Berlin 2007.

MANARIS (1998) MANARIS, B.: Natural Language Processing: a Human-Computer Interaction Perspective. In: ZELKOWITZ, M. (Hrsg.): Applications of Artificial Intelligence, Advances in Computers - Volume 47, San Diego und London 1998, S. 1-66. MANECKE (2004) MANECKE, H.: Klassifikation, Klassieren. In: KUHLEN, R./LAISIEPEN, K. (Hrsg.): Handbuch zur Einführung in die Informationswissenschaft und -praxis, 5. Auflage, München 2004, S. 127-140. MANNING (2008) MANNING, C.D.: Introduction to Information Retrieval, New York 2008. MATOUŠEK/KRÁL/FALC (2004) MATOUŠEK, K./KRÁL, L./FALC, M.: Apollo Manual, 2004. Online-Publikation im Internet unter der URL „http://apollo.open.ac.uk/docs/Apollo_manual.pdf“, Zugriff am 26.05.2010. MEIXNER/HAAS (2002) MEIXNER, O./HAAS, R.: Computergestützte Entscheidungsfindung: Expert Choice und AHP - innovative Werkzeuge zur Lösung komplexer Probleme, Frankfurt am Main 2002.

242

Literaturverzeichnis

MENDOZA/MACOUN/PRABHU/SUKADRI/PURNOMO/HARTANTO (1999) MENDOZA, G. A./MACOUN, P./PRABHU, R./SUKADRI, D./PURNOMO, H./HARTANTO, H.: Guidelines for Applying Multi-Criteria Analysis to the Assessment of Criteria and Indicators, Jakarta 1999. MERTENS (2000) MERTENS, P.: Data X Strategien, Berlin und Heidelberg 2000. MERTENS/BODENDORF/KÖNIG/PICOT/SCHUMANN/HESS (2005) MERTENS, P./BODENDORF, F./KÖNIG, W./PICOT, A./SCHUMANN, M./HESS, T.: Grundzüge der Wirtschaftsinformatik, 9. Auflage, Berlin, Heidelberg und New York 2005. MESTROVIC/CUBRILO (2009) MESTROVIC, A./CUBRILO, M.: F-Logic Data and Knowledge Reasoning in the Semantic Web Context. In: MACHADO, J. A. T./PATKAI, B./RUDAS, I. J. (Hrsg.): Intelligent Engineering Systems and Computational Cybernetics, Dordrecht 2009, S. 119-136. MICROSOFT (2010) MICROSOFT CORPORATION: MICROSOFT Windows Server Update Services, 2010. OnlinePublikation im Internet unter der URL „http://technet.microsoft.com/de-de/wsus/default. aspx“, Zugriff am 09.06.2010. MILLET/SAATY (2000) MILLET, I./SAATY, T.L.: On the relativity of relative measures – accommodating both rank preservation and rank reversals in the AHP. In: European Journal of Operational Research, Vol. 121 (2000), No. 1, S. 205-212. MINDSWAP (2004) MINDSWAP RESEARCH GROUP, UNIVERSITY OF MARYLAND: Swoop - Hypermedia-based OWL Ontology Browser and Editor, 2004. Online-Publikation im Internet unter der URL „http://www.mindswap.org/2004/SWOOP/“, Zugriff am 08.06.2010.

Literaturverzeichnis

243

MINDSWAP (2007) MINDSWAP RESEARCH GROUP, UNIVERSITY OF MARYLAND: Downloads - Swoop - Project Hosting on Google Code, 2007. Online-Publikation im Internet unter der URL „http:// code.google.com/p/swoop/downloads/list“, Zugriff am 08.06.2010. MOENS (2006) MOENS, M.-F.: Information Extraction: Algorithms and Prospects in a Retrieval Context, Dordrecht 2006. MOSCHITTI/BASILI (2004) MOSCHITTI, A./BASILI, R.: Complex Linguistic Features of Text Classification: A Comprehensive Study. In: TAIT, J./MCDONALD, S. (Hrsg.): Advances in Information Retrieval: 26th European Conference on IR Research, ECIR 2004, Sunderland, UK, April 5-7, 2004, Proceedings, Berlin und Heidelberg 2004, S. 181-196. MOTUS (2009) MOTUS, D.: Referenzmodell für die Montageplanung in der Automobilindustrie, München 2009. MUKAIDONO/KIKUCHI (2001) MUKAIDONO, M./KIKUCHI, H.: Fuzzy Logic for Beginners, Singapore 2001. NATIONAL UNIVERSITY OF SINGAPORE (2005) NATIONAL UNIVERSITY

OF

SINGAPORE: Natural Language Processing / Information Re-

trieval Software Repository, 2005. Online-Publikation im Internet unter der URL „http:// www.comp.nus.edu.sg/~rpnlpir/“, Zugriff am 08.06.2010. NONAKA/TAKEUCHI (2001) NONAKA, I./TAKEUCHI, H.: Die Organisation des Wissens: Wie japanische Unternehmen eine brachliegende Ressource nutzbar machen, Frankfurt 2001.

244

Literaturverzeichnis

NOY/MCGUINNESS (2006) NOY, N. F./MCGUINNESS, D. L.: Ontology Development 101: A Guide to Creating Your First Ontology, 2006. Online-Publikation im Internet unter der URL „http://protege. stanford.edu/publications/ontology_development/ontology101.pdf“, Zugriff am 26.05. 2010. ONTOPRISE (2009) ONTOPRISE GMBH: Help - Ontoprise Helpsystem, 2009. Online-Publikation im Internet unter der URL „http://www.ontoprise.de/help/index.jsp“, Zugriff am 08.06.2010. ONTOPRISE (2010a) ONTOPRISE GMBH: ONTOPRISE: Rechtliche Hinweise, 2010. Online-Publikation im Internet unter der URL „http://www.ontoprise.de/deutsch/footer/rechtliche-hinweise/“, Zugriff am 24.10.2010. ONTOPRISE (2010b) ONTOPRISE GMBH: ONTOPRISE: Download OntoStudio, 2010. Online-Publikation im Internet unter der URL „http://www.ontoprise.de/deutsch/start/produkte/ontostudio/downloadontostudio/“, Zugriff am 08.06.2010. PAL/DILLON/YEUNG (2000) PAL, S. K./DILLON, T.S./YEUNG, D.S.: Soft Computing in Case Based Reasoning, 1. Auflage, London, Berlin und Heidelberg 2000. PAL/SHIU (2004) PAL, S. K./SHIU, S. C. K.: Foundations of Soft Case-Based Reasoning, Hoboken 2004. PANYR (1992) PANYR, J.: Frames, Thesauri und automatische Klassifikation (Clusteranalyse). In: KUHLEN,

R. (Hrsg.): Experimentelles und praktisches Information Retrieval, Konstanz 1992, S.

277-295. PATIG (2006) PATIG, S.: Die Evolution von Modellierungssprachen, Habilitationsschrift, Berlin 2006.

Literaturverzeichnis

245

PERNER (2008) PERNER, P.: Case-Based Reasoning on Images and Signals, Berlin und Heidelberg 2008. PETERS (2008) PETERS, M. L.: Vertrauen in Wertschöpfungspartnerschaften zum Transfer von retentivem Wissen, Dissertation, Wiesbaden 2008. PETERSON (2001) PETERSON, M.: Wissensmanagement in der strategischen Unternehmensberatung: Erfolgsfaktoren, Methoden und Konzepte, Wiesbaden 2001. PFUHL (2003) PFUHL, M.: Case-Based Reasoning auf der Grundlage relationaler Datenbanken: Eine Anwendung zur strukturierten Suche in Wirtschaftsnachrichten, Dissertation, Wiesbaden 2003. PMI (2004) PROJECT MANAGEMENT INSTITUTE, INC.: A Guide to the Project Management Body of Knowledge, 3. Auflage, Pennsylvania 2004. POMBERGER/PREE (2004) POMBERGER, G./PREE, W.: Software Engineering: Architektur-Design und Prozessorientierung, 3. Auflage, München und Wien 2004. PRATIHAR/JAIN (2010) PRATIHAR, D. K./JAIN, L. C.: Towards Intelligent Autonomous Systems. In: PRATIHAR, D. K./JAIN, L. C. (Hrsg.): Intelligent Autonomous Systems: Foundations and Applications, Berlin und Heidelberg 2010, S. 1-4. PROBST/RAUB/ROMHARDT (2010) PROBST, G./RAUB, S./ROMHARDT, K.: Wissen managen. Wie Unternehmen ihre wertvollste Ressource optimal nutzen, 6. Auflage, Frankfurt und Wiesbaden 2010.

246

Literaturverzeichnis

PUPPE/STOYAN/STUDER (2004) PUPPE, F./STOYAN, H./STUDER, R.: Knowledge Engineering. In: GÖRZ, G./ROLLINGER, C.R./SCHNEEBERGER, J. (Hrsg.): Handbuch der Künstlichen Intelligenz, 4. Auflage, München 2004, S. 599-641. RACER (2010) RACER SYSTEMS GMBH & CO. KG: RACER SYSTEMS GMBH & CO. KG, 2010. OnlinePublikation im Internet unter der URL „http://www.racer-systems.com/de/index.phtml? lang“, Zugriff am 08.06.2010. RECH (2008) RECH, J.: Ethernet: Technologien und Protokolle für die Computervernetzung, 2. Auflage, Hannover 2008. REHÄUSER/KRCMAR (1996) REHÄUSER, J./KRCMAR, H.: Wissensmanagement im Unternehmen. In: SCHREYÖGG, G. (Hrsg.): Wissensmanagement, Berlin 1996, S. 1-40. REISIG/ROZENBERG (1998) REISIG, W./ROZENBERG, G.: Lectures on PETRI Nets I: Basic Models: Advances in PETRI Nets, Berlin, Heidelberg und New York 1998. REMUS (2002) REMUS, U.: Prozessorientiertes Wissensmanagement - Konzepte und Modellierung, Dissertation, Regensburg 2002. RICHTER (2004) RICHTER, M. M.: Fallbasiertes Schließen. In: GÖRZ, G./ROLLINGER, C.-R./SCHNEEBERGER, J. (Hrsg.): Handbuch der Künstlichen Intelligenz, 4. Auflage, München 2004, S. 407-430.

Literaturverzeichnis

247

RICHTER/BENDER/KLINGER/HERBOLZHEIMER (2008) RICHTER, G./BENDER, K./KLINGER, M./HERBOLZHEIMER, C.: Projekte mit Launch Management auf Kurs halten - Warum IT-Großprojekte häufig kentern und Projekterfolg kein Glücksspiel ist, 2008. Online-Publikation im Internet unter der URL „http://www. rolandberger.com/media/pdf/rb_press/Roland_Berger_launch_management_de_20080723 .pdf“, Zugriff am 19.10.2010. RULEML (2010) RULEML: The Rule Markup Initiative, UNIVERSITY

OF

NEW BRUNSWICK, 2010. Online-

Publikation im Internet unter der URL „http://ruleml.org/“, Zugriff am 16.10.2010. RUNGE/STURM/WIßKIRCHEN/EBEL/GROH/HÖLLER/MEWES (2008) RUNGE, R./STURM, C./WIßKIRCHEN, S. /EBEL, N./GROH, J./HÖLLER, O./MEWES, C.: VMware Infrastructure 3 im Business-Umfeld: Virtualisierung von mittleren und großen Umgebungen mit VMware ESX 3.5 und ESXi 3.5, München 2008. SAATY (1994a) SAATY, T.L.: Highlights and Critical Points in the Theory and Application of the Analytic Hierarchy Process. In: European Journal of Operational Research, Vol. 74 (1994), No. 3, S. 426-447. SAATY (1994b) SAATY, T.L.: How to Make a Decision: The Analytic Hierarchy Process. In: Interfaces, Vol. 24 (1994), No. 6, S. 19-43. SAATY (2000) SAATY, T.L.: Fundamentals of Decision Making and Priority Theory with the Analytic Hierarchy Process, 2. Auflage, Pittsburgh 2000. SAATY (2001a) SAATY, T. L.: Decision Making with Dependence and Feedback - The Analytic Network Process, 2. Auflage, Pittsburgh 2001.

248

Literaturverzeichnis

SAATY (2001b) SAATY, T. L.: THOMAS SAATY’S ANP Powerpoint Slide Show (July 2001). OnlinePublikation im Internet unter der URL „http://www.creativedecisions.net/papers/papers_ etc/ANP_Slideshow_July_2001.ppt“, Zugriff am 28.10.2010. SAATY (2001c) SAATY, T. L.: Decision Making for Leaders - The Analytic Hierarchy Process for Decisions in a Complex World, 3. Auflage, 4. Druck, Pittsburgh 2001. SAATY/MU (1997) SAATY, T. L./MU, E.: The Peruvian Hostage Crisis of 1996-1997: What Should the Government Do? In: Socio-Economic Planning Sciences, Vol. 31 (1997), No. 3, S. 165-172. SAATY/VARGAS (2001) SAATY, T.L./VARGAS, L.G.: Models, Methods, Concepts & Applications of the Analytic Hierarchy Process, Pittsburgh 2001. SAIZ-NOEDA/PALOMAR (2000) SAIZ-NOEDA, N./PALOMAR, M.: Semantic Knowledge-Driven Method to Solve Pronominal Anaphora in Spanish Texts. In: CHRISTODOULAKIS, D. N. (Hrsg.): Natural Language Processing - NLP 2000: Second International Conference, Patras, Greece, June 2-4, 2000 Proceedings, Berlin und Heidelberg 2000.

SCHAUER (2004) SCHAUER, H.: Impulse der Erkenntnistheorie und des Wissenschaftsbetriebs für eine betriebliche Wissensbewertung. In: ULRICH, F. (Hrsg.): Wissenschaftstheorie in Ökonomie und Wirtschaftsinformatik - Theoriebildung und -bewertung, Ontologien, Wissensmanagement, Wiesbaden 2004, S. 289-310. SCHEMAWEB (2005) O.V.:

SCHEMAWEB - RDF Schemas Directory, 2005. Online-Publikation im Internet unter

der URL „http://www.schemaweb.info“, Zugriff am 08.06.2010.

Literaturverzeichnis

249

SCHMIDT (2006) SCHMIDT, K.: High Availability and Disaster Recovery: Concepts, Design, Implementation, Berlin und Heidelberg 2006. SCHMIDT (2008) SCHMIDT, G.: Börsensystem, 2008. In: KURBEL, K./BECKER, J./GRONAU, N./EINZ, E./SUHL, L. (Hrsg.): Enzyklopädie der Wirtschaftsinformatik. Online-Publikation im Internet unter der URL „http://www.enzyklopaedie-der-wirtschaftsinformatik.de/wi-enzyklopaedie/lexik on/informationssysteme/Sektorspezifische-Anwendungssysteme/Finanzsektor--Anwendun gssysteme-im/Borsensystem“, Zugriff am 26.05.2010. SCHÖNBECK (2002) SCHÖNBECK, J.: EUKLID - Vita Mathematica, Basel, Boston und Berlin 2002. SCHREINER (2007) SCHREINER, R.: Computernetzwerke. Von den Grundlagen zur Funktion und Anwendung, 2. Auflage, München 2007. SCHÜTTE/VERING/WIESE (2000) SCHÜTTE, R./VERING, O./WIESE, J.: Erfolgreiche Geschäftsprozesse durch standardisierte Warenwirtschaftssysteme - Marktanalyse, Produktübersicht, Auswahlprozess, Berlin, Heidelberg, New York et al. 2000. SCN EDUCATION B.V. (2001) SCN EDUCATION B.V.: Electronic Banking: The Ultimate Guide to Online Banking, Braunschweig und Wiesbaden 2001. SEIDL (2001) SEIDL, H.: Sein und Bewußtsein, Hildesheim 2001. SMEATON (1999) SMEATON, A. F.: Using NLP or NLP Resources for Information Retrieval Tasks. In: STRZALKOWSKI, T. (Hrsg.): Natural Language Information Retrieval, Dordrecht 1999, S. 99-112.

250

Literaturverzeichnis

SMI (2009) STANFORD MEDICAL INFORMATICS: From Protege Wiki - Choosing between versions of Protege, 2009. Online-Publikation im Internet unter der URL „http://protegewiki.stanford. edu/wiki/Protege4Migration“, Zugriff am 08.06.2010. SMI (2010a) STANFORD MEDICAL INFORMATICS: Welcome to Protégé, 2010. Online-Publikation im Internet unter der URL „http://protege.stanford.edu/“, Zugriff am 26.05.2010. SMI (2010b) STANFORD MEDICAL INFORMATICS: Protégé User Documentation, 2010. OnlinePublikation im Internet unter der URL „http://protege.stanford.edu/doc/users.html“, Zugriff am 08.06.2010. SNEDAKER (2007) SNEDAKER, S: Business Continuity & Disaster Recovery Planning for IT Professionals, Burlington 2007.

SPECKER (2004) SPECKER, A.: Modellierung von Informationssystemen. Ein methodischer Leitfaden zur Projektabwicklung, 2. Auflage, Zürich 2004. SPENNEBERG (2006) SPENNEBERG, R.: Linux-Firewalls mit Iptables & Co., München 2006. STAAB (2002) STAAB, S.: Wissensmanagement mit Ontologien und Metadaten. In: Informatik Spektrum, 25. Jg. (2002), H. 3, S. 194-209. STANDISH GROUP (2009) STANDISH GROUP INTERNATIONAL, INC.: CHAOS Summary 2009. Online-Publikation im Internet unter der URL „http://www.statelibrary.state.pa.us/portal/server.pt/document/ 690719/chaos_summary_2009_pdf“, Zugriff am 19.10.2010.

Literaturverzeichnis

251

STANFORD CENTER FOR BIOMEDICAL INFORMATICS RESEARCH (2010) STANFORD CENTER CENTER

FOR

FOR

BIOMEDICAL INFORMATICS RESEARCH: Homepage of STANFORD

BIOMEDICAL INFORMATICS RESEARCH, 2010. Online-Publikation im Internet

unter der URL „http://bmir.stanford.edu/“, Zugriff am 08.06.2010. STARLAB (o.J.) STARLAB, SEMANTICS TECHNOLOGY ULTY OF

SCIENCES, DEPARTMENT

OF

AND

APPLICATIONS RESEARCH LABORATORY, FAC-

COMPUTER SCIENCE, VRIJE UNIVERSITEIT BRUSSEL:

DOGMA, o.J. Online-Publikation im Internet unter der URL „http://www.starlab.vub.ac. be/website/node/45“, Zugriff am 26.05.2010. STEINMÜLLER (1993) STEINMÜLLER, W.: Informationstechnologie und Gesellschaft, Einführung in die angewandte Informatik, Darmstadt 1993. STUDER/BENJAMINS/FENSEL (1998) STUDER, R./BENJAMINS, V. R./FENSEL, D.: Knowledge Engineering: Principles and Methods. In: IEEE Transactions on Data and Knowledge Engineering, Vol. 25 (1998), No. 1-2, S. 161-197.

SU/ILEBREKKE (2002) SU, X./ILEBREKKE, L.: A Comparative Study of Ontology Languages and Tools. In: PIDDUCK, A. B./OZSU, M. T./WOO, C.

C./MYLOPOULOS, J. (Hrsg): Advanced Information Sys-

tems Engineering: 14th International Conference, CAISE 2002 Toronto, Canada, May 2731, 2002 Proceedings, Lecture Notes in Computer Science, Vol. 2348, Berlin, Heidelberg, New York 2002, S. 761-765. SUNGARD (2008) SUNGARD: SUNGARD - Global One, Securities Administration, 2008. Online-Publikation im Internet unter der URL „http://www.sungard.com/financialsystems/brands/globalone. aspx“, Zugriff am 08.06.2010. SURENDORF (2009) SURENDORF, K.: Mac OS X Snow Leopard: Das umfassende Handbuch, Bonn 2009.

252

Literaturverzeichnis

SVEIBY (1998) SVEIBY, K. E.: The New Organizational Wealth: Managing & Measuring KnowledgeBased Assets, San Francisco 1998. TAN (1999) TAN, A.-H.: Text Mining: The state of the art and the challenges, Singapore 1999. OnlinePublikation im Internet unter der URL „http://www3.ntu.edu.sg/home/asahtan/papers/tm_ pakdd99.pdf“, Zugriff am 26.05.2010. TRAILL (2008) TRAILL, R. R.: Thinking by Molecule, Synapse, or both? - From Piaget’s Schema, to the Selecting/Editing of ncRNA, 2008. Online-Publikation im Internet unter der URL „http:// www.ondwelle.com/OSM02.pdf“, Zugriff am 26.05.2010. TVERSKY (1977) TVERSKY, A. (1977): Features of Similarity. In: Psychological Review, Vol. 84 (1977), No. 4, S. 327–352. VAN HARMELEN/HORROCKS (2000) VAN HARMELEN, F./HORROCKS, I.:

Questions and Answers on OIL: the Ontology Inference

Layer for the Semantic Web, 2000. Online-Publikation im Internet unter der URL „http:// web.squ.edu.om/med-Lib/med/net/e-pathways-net/Docs/OIL%20FAQ.htm“, Zugriff am 26.05.2010. VÖLKER/HAASE/HITZLER (2008) VÖLKER, J./HAASE, P./HITZLER, P.: Learning Expressive Ontologies. In: BUITELAAR, P./ CIMIANO, P. (Hrsg.): Ontology Learning and Population: Bridging the Gap Between Text and Knowledge, Amsterdam 2008, S. 45-70. VOORHEES (1999) VOORHEES, E. M.: Natural Language Processing and Information Retrieval. In: PAZIENZA, M. T. (Hrsg.): Information Extraction: Towards Scalable, Adaptable Systems, Berlin und Heidelberg 1999, S. 32-48.

Literaturverzeichnis

253

VOSSENKUHL (1993) VOSSENKUHL, W.: Sprachpragmatik. In: STACHOWIAK, H. (Hrsg.): Pragmatik - Handbuch pragmatischen Denkens - Band IV: Sprachphilosophie, Sprachpragmatik und formative Pragmatik, Hamburg 1993, S. 85-103. VOUROS/EUMERIDOU/TSELIOS/KOTIS (2005) VOUROS, G. A./EUMERIDOU, E./TSELIOS, P./KOTIS, K.: Multilangual, Ontology-Driven, Content-Based Search and Navigation of Information Items. In: Applied Artificial Intelligence, Vol. 19 (2005), No. 7, S. 691-719. W3C (2001) W3C, WORLD WIDE WEB CONSORTIUM: N-Triples, 2001. Online-Publikation im Internet unter der URL „http://www.w3.org/2001/sw/RDFCore/ntriples/“, Zugriff am 24.10.2010. W3C (2004) W3C, WORLD WIDE WEB CONSORTIUM: OWL Web Ontology Language Overview, 2004. Online-Publikation im Internet unter der URL „http://www.w3.org/TR/owl-features/“, Zugriff am 26.05.2010. W3C (2006) W3C, WORLD WIDE WEB CONSORTIUM: RIF-WG Wiki: F-logic, 2006. Online-Publikation im Internet unter der URL „http://www.w3.org/2005/rules/wg/wiki/F-logic“, Zugriff am 26.05.2010. W3C (2009) W3C, WORLD WIDE WEB CONSORTIUM: W3C, WORLD WIDE WEB CONSORTIUM, 2009. Online-Publikation im Internet unter der URL „http://www.w3.org/Consortium/“, Zugriff am 26.05.2010. W3SCHOOLS (2010a) W3SCHOOLS: W3C RDF and OWL Activities, 2010. Online-Publikation im Internet unter der URL „http://www.w3schools.com/w3c/w3c_rdf.asp“, Zugriff am 26.05.2010.

254

Literaturverzeichnis

W3SCHOOLS (2010b) W3SCHOOLS: RDF Tutorial, 2010. Online-Publikation im Internet unter der URL „http:// www.w3schools.com/rdf/default.asp“, Zugriff am 26.05.2010. WALIGORA/SCHMIDT (2005) WALIGORA, T./SCHMIDT, R.: Influenca Forecast: Comparison of Case-Based Reasoning and Statistical Methods. In: OLIVERA, J. L./MAOJO, V./MARTIN-SANCHEZ, F./PEREIRA, A. S. (Hrsg.): Biological and Medical Data Analysis - 6th International Symposium, ISBMDA 2005, Aveiro, Portugal, November 10-11, 2005, Proceedings, Berlin und Heidelberg 2005, S. 202-210. WATSON (1997) WATSON, I.: Applying Case-Based Reasoning: Techniques for Enterprise Systems, San Francisco 1997. WEBER (1993) WEBER, K.: Mehrkriterielle Entscheidungen, München und Wien 1993. WEDEKIND (2001) WEDEKIND, H.: Thesaurus. In: MERTENS, P./BACK, A./BECKER, J./KÖNIG, W./KRALLMANN, H./RIEGER, B./SCHEER, A.-W./SEIBT, D./STAHLKNECHT, P./STRUNZ, H./THOME, R./WEDEKIND, H. (Hrsg.):

Lexikon der Wirtschaftsinformatik, 4. Auflage, Berlin 2001, S. 474.

WEITZER (2000) WEITZER, J.: Verwendung von Qualitäts-Metadaten zur verbesserten Wissensauffindung und Testimplementierung im xFIND System, INSTITUT FÜR INFORMATIONSVERARBEITUNG UND COMPUTERGESTÜTZTE NEUE

MEDIEN, TECHNISCHE UNIVERSITÄT GRAZ, Graz 2000.

Online-Publikation im Internet unter der URL „http://www.iicm.tu-graz.ac.at/Teaching/ theses/2000/_idba2_/jweitzer/html/node11.html“, Zugriff am 26.05.2010. WENDE (2006) WENDE, I.: Grundlagen der Normung und Spezifikation. In: RECHENBERG, P./POMBERGER, G. (Hrsg.): Informatik-Handbuch, 4. Ausgabe, München und Wien 2006.

Literaturverzeichnis

255

WILLINGER/GRADL (2003) WILLINGER, M./GRADL, J. (2003): Datenmigration in SAP R/3, Bonn 2003. WIMMEL (2008) WIMMEL, H.: PETRI-Netze, 2. Auflage, Berlin und Heidelberg 2008. WISE (2004) WEB & INFORMATION SYSTEM ENGINEERING (WISE) LABORATORY, DEPARTMENT

OF

COMPUTER SCIENCE, FREIE UNIVERSITÄT BRÜSSEL: The OntoBasis Project, 2004. OnlinePublikation im Internet unter der URL „http://wise.vub.ac.be/ontobasis/index.html“, Zugriff am 08.06.2010. WITTE/GITZINGER (2008) WITTE, R./GITZINGER, T.: Semantic Assistants - User-Centric Natural Language Processing Services for Desktop Clients. In: DOMINGUE, J./ANUTARIYA, C. (Hrsg.): The Semantic Web: 3rd Asian Semantic Web Conference, ASWC 2008, Bangkok, Thailand, December 8-11, 2008, Proceedings, Berlin und Heidelberg 2008, S. 360-374. WOOD/ROSS-KERR (2010) WOOD, M. J./ROSS-KERR, J. C.: Basic Steps in Planning Nursing Research: From Question to Proposal, 7. Auflage, Sudbury, Ontario und London 2010. XIONG (2008) XIONG, N.: Generating Fuzzy Rules to Identify Relevant Cases in Case-Based Reasoning. In: IEEE International Conference on Fuzzy Systems, FUZZ-IEEE 2008, S. 2359-2364. ZADEH (1965) ZADEH, L.: Fuzzy Sets. In: Information and Control, Vol. 8 (1965), S. 338-353. ZANGEMEISTER (1976) ZANGEMEISTER, C.: Nutzwertanalyse in der Systemtechnik: Eine Methodik zur multidimensionalen Bewertung und Auswahl von Projektalternativen, 4. Auflage, München 1976.

256

Literaturverzeichnis

ZELEWSKI (1999) ZELEWSKI, S.: Ontologien zur Strukturierung von Domänenwissen - Ein Annäherungsversuch aus betriebswirtschaftlicher Perspektive -, Arbeitsbericht Nr. 3, INSTITUT DUKTION UND

FÜR

PRO-

INDUSTRIELLES INFORMATIONSMANAGEMENT, UNIVERSITÄT DUISBURG-

ESSEN, Essen 1999. ZELEWSKI (2005) ZELEWSKI, S.: Einführung in das Themenfeld „Ontologien“ aus informations- und betriebswirtschaftlicher Perspektive. In: ZELEWSKI, S./ALAN, Y./ALPARSLAN, A./DITTMANN, L./WEICHELT, T. (Hrsg.): Ontologiebasierte Kompetenzmanagementsysteme - Grundlagen, Konzepte, Anwendungen, Berlin 2005, S. 115-228. ZELEWSKI/PETERS (2002) ZELEWSKI, S./PETERS, M. L.: Analytical Hierarchy Process (AHP) - dargestellt am Beispiel der Auswahl von Projektmanagement-Software zum Multiprojektmanagement, Arbeitsbericht Nr. 14, INSTITUT FÜR PRODUKTION UND INDUSTRIELLES INFORMATIONSMANAGEMENT, UNIVERSITÄT DUISBURG-ESSEN, Essen 2002. ZELEWSKI/PETERS (2003) ZELEWSKI, S./PETERS, M. L.: Lösung multikriterieller Entscheidungsprobleme mit Hilfe des Analytic Hierarchy Process. In: Wisu - das Wirtschaftsstudium, 32. Jg. (2003), H. 10, S. 1210-1218.

ZELEWSKI/SCHÜTTE/SIEDENTOPF (2001) ZELEWSKI, S./SCHÜTTE, R./SIEDENTOPF, J.: Ontologien zur Repräsentation von Domänen. In: SCHREYÖGG, G. (Hrsg.): Wissen in Unternehmen, Berlin 2001, S. 183-221. ZÖLLER-GREER (2002) ZÖLLER-GREER, P.: Softwareengineering für Ingenieure und Informatiker, Braunschweig und Wiesbaden 2002.

257

Anhang

Inhaltsverzeichnis des Anhangs

259

Inhaltsverzeichnis des Anhangs Abbildungsverzeichnis des Anhangs ..............................................................................261 Tabellenverzeichnis des Anhangs...................................................................................263 Anhang 1:

Exemplarische Fälle zur Repräsentation von Projektwissen...............265

Anhang 2:

Erstellung des Prototyps..........................................................................283

Anhang 2.1: Installation von Protégé..............................................................................283 Anhang 2.2: Installation von MyCBR als Plug-In von Protégé......................................287 Anhang 2.3: Start und Konfiguration von Protégé .........................................................288 Anhang 2.4: Erstellen der Klassen..................................................................................290 Anhang 2.5: Import der Instanzen...................................................................................291 Anhang 2.6: Konfiguration der lokalen Ähnlichkeitsmaßstäbe......................................297 Anhang 2.7: Import der Anfrage-Fälle ...........................................................................306 Anhang 2.8: Durchführung der Fallidentifikation ..........................................................308 Anhang 2.9: Probleme bei der Speicherung der Ähnlichkeitsmaßstäbe in Protégé........309 Anhang 3:

Formalsprachliche Darstellungen...........................................................311

Anhang 3.1: CSV-Listen zum Import von Fallwissen....................................................311 Anhang 3.2: Klassen der Ontologie im Protégé-Format.................................................312 Anhang 3.3: Instanzen der Ontologie im Protégé-Format ..............................................316 Anhang 3.4: Konfigurationsdatei für Protégé .................................................................321 Anhang 3.5: Fallbasis im MyCBR-Format .....................................................................341 Anhang 3.6: Erklärungen im MyCBR-Format ...............................................................347 Anhang 3.7: Konfiguration zum Umgang mit unbekannten Attributswerten.................348 Anhang 3.8: Ähnlichkeitsmaßstäbe im MyCBR-Format................................................349

S. Beißel, Ontologiegestütztes Case-Based Reasoning, DOI 10.1007/978-3-8349-6232-4, © Gabler Verlag | Springer Fachmedien Wiesbaden GmbH 2011

Abbildungsverzeichnis des Anhangs

261

Abbildungsverzeichnis des Anhangs Abbildung A-1:

„Introduction“ .....................................................................................283

Abbildung A-2:

„Choose Install Set“............................................................................284

Abbildung A-3:

„Choose Install Folder“ ......................................................................284

Abbildung A-4:

„Choose Shortcut Folder“...................................................................285

Abbildung A-5:

„Choose Java Virtual Machine“ .........................................................286

Abbildung A-6:

„Pre-Installation Summary“................................................................286

Abbildung A-7:

„Install Complete“ ..............................................................................287

Abbildung A-8:

Plug-In-Ordner....................................................................................287

Abbildung A-9:

„Welcome to Protégé“ ........................................................................288

Abbildung A-10: „Create New Project“ .........................................................................288 Abbildung A-11: Aufruf des Konfigurationsmenüs .......................................................289 Abbildung A-12: Auswahl der Kartenreiter....................................................................289 Abbildung A-13: „Create Class“.....................................................................................290 Abbildung A-14: „Class Editor“ .....................................................................................290 Abbildung A-15: „Import Instances from CSV...“ .........................................................291 Abbildung A-16: Auswahl einer CSV-Liste ...................................................................291 Abbildung A-17: „Importer“...........................................................................................292 Abbildung A-18: „Create Slots?“....................................................................................293 Abbildung A-19: „How to generate its names?“.............................................................293 Abbildung A-20: „Create Symbol“ .................................................................................294 Abbildung A-21: „Value Type“ ......................................................................................295 Abbildung A-22: „Select Classes“ ..................................................................................296 Abbildung A-23: „Select Instance“.................................................................................296 Abbildung A-24: Ähnlichkeitsmaßstab für den Slot „Projekttyp“ .................................298 Abbildung A-25: Ähnlichkeitsmaßstab für den Slot „Familie“ ......................................298

262

Abbildungsverzeichnis des Anhangs

Abbildung A-26: Ähnlichkeitsmaßstab für den Slot „Anwendungsname“ ....................299 Abbildung A-27: Ähnlichkeitsmaßstab für den Slot „Anwendungsbereich“ .................299 Abbildung A-28: Ähnlichkeitsmaßstab für den Slot „Typ“............................................299 Abbildung A-29: Ähnlichkeitsmaßstab für den Slot „Euro“ ..........................................300 Abbildung A-30: Ähnlichkeitsmaßstab für den Slot „Personentage“.............................301 Abbildung A-31: Ähnlichkeitsmaßstab für den Slot „Betriebssystemname“ .................302 Abbildung A-32: Ähnlichkeitsmaßstab für den Slot „Modell“.......................................302 Abbildung A-33: Aggregationsfunktion für die Klasse „Projekt“ ..................................303 Abbildung A-34: „Configure Inheritance Similarity“.....................................................304 Abbildung A-35: Menüpunkt „Options...“ in Protégé ....................................................304 Abbildung A-36: „Project Options“................................................................................305 Abbildung A-37: Menüpunkt „Configure Special Values...“ in Protégé ........................305 Abbildung A-38: „Configure Special Values...“.............................................................306 Abbildung A-39: Erweiterung des Wertebereichs des Slots „Anwendungsname“ ........306 Abbildung A-40: Import der CSV-Listen .......................................................................307 Abbildung A-41: Erweiterung des lokalen Ähnlichkeitsmaßstabs für den Slot „Anwendungsname“ ...........................................................................308 Abbildung A-42: „CBR Retrieval“ .................................................................................309

Tabellenverzeichnis des Anhangs

263

Tabellenverzeichnis des Anhangs Tabelle A-1:

Extrahierte Instanzen des Falls 1 ........................................................266

Tabelle A-2:

Extrahierte Instanzen des Falls 2 ........................................................268

Tabelle A-3:

Extrahierte Instanzen des Falls 3 ........................................................269

Tabelle A-4:

Extrahierte Instanzen des Falls 4 ........................................................271

Tabelle A-5:

Extrahierte Instanzen des Falls 5 ........................................................272

Tabelle A-6:

Extrahierte Instanzen des Falls 6 ........................................................274

Tabelle A-7:

Extrahierte Instanzen des Falls 7 ........................................................275

Tabelle A-8:

Extrahierte Instanzen des Falls 8 ........................................................277

Tabelle A-9:

Extrahierte Instanzen des Falls 9 ........................................................278

Tabelle A-10:

Extrahierte Instanzen des Falls 10 ......................................................280

Tabelle A-11:

Extrahierte Instanzen des Anfrage-Falls 1..........................................281

Tabelle A-12:

Extrahierte Instanzen des Anfrage-Falls 2..........................................282

Tabelle A-13:

Werte der Relationen ..........................................................................297

Exemplarische Fälle zur Repräsentation von Projektwissen

265

Anhang 1: Exemplarische Fälle zur Repräsentation von Projektwissen

Fall 1: Natürlichsprachlich repräsentiertes Projektwissen: Die Umsetzung von Härtungsanforderungen an Unix-Systeme wurde in mehreren Phasen durchgeführt. In der ersten Phase erfolgte eine Bestandsaufnahme der Systeme, die auf Servern des Modells IBM iSeries mit dem Betriebssystem Red Hat Linux 9 aus der Familie Unix betrieben wurden und in Racks eingebaut waren. Zur Bestandsaufnahme gehörte insbesondere die Aufnahme der Konfigurationen der Systeme. In der zweiten Phase erfolgte die Erstellung von Sollvorgaben basierend auf Sicherheitsstandards und White Papers. In der dritten Phase wurden die technischen Voraussetzungen für die Sollvorgaben geprüft und mit den technischen Möglichkeiten der Unix-Systeme abgeglichen. Unter Berücksichtigung von möglichen technischen Einschränkungen wurden endgültige Härtungsstandards für Unix-Systeme definiert. Abschließend wurden die Konfigurationen der Unix-Systeme in der Art angepasst, dass sie den Härtungsstandards entsprachen. Für die Durchführung des Projekts stand ein Budget in Höhe von 452000 Euro zur Verfügung. Es wurden 320 Personentage benötigt. Entfernung von Stoppwörtern und nicht relevanten Begriffen: Die Umsetzung von Härtungsanforderungen an Unix-Systeme wurde in mehreren Phasen durchgeführt. In der ersten Phase erfolgte eine Bestandsaufnahme der Systeme, die auf Servern des Modells IBM iSeries mit dem Betriebssystem Red Hat Linux 9 aus der Familie Unix betrieben wurden und in Racks eingebaut waren. Zur Bestandsaufnahme gehörte insbesondere die Aufnahme der Konfigurationen der Systeme. In der zweiten Phase erfolgte die Erstellung von Sollvorgaben basierend auf Sicherheitsstandards und White Papers. In der dritten Phase wurden die technischen Voraussetzungen für die Sollvorgaben geprüft und mit den technischen Möglichkeiten der Unix-Systeme abgeglichen. Unter Berücksichtigung von möglichen technischen Einschränkungen wurden endgültige Härtungsstandards für Unix-Systeme definiert. Abschließend wurden die Konfigurationen der Unix-Systeme in der Art angepasst, dass sie den Härtungsstandards entsprachen. Für die Durchführung des Projekts stand ein Budget in Höhe von 452000 Euro zur Verfügung. Es wurden 320 Personentage benötigt.

266

Exemplarische Fälle zur Repräsentation von Projektwissen

Begriffe nach Normalformreduktion und Korrektur: Härtung, Unix, System, Server, Modell, IBM_iSeries, Betriebssystem, Red_Hat_Linux_9, Familie, Unix, Rack, Konfiguration, Projekt, 452000, Euro, 320, Personentage. Extrahierte Klassen: Betriebssystem, Projekt, Server, System.

extrahierte Instanzen: Unix-Härtung

Server_1

Red_Hat_Linux_9

Attribute der

Attributswerte der

extrahierten Instanzen:

extrahierten Instanzen:

Projekttyp

Konfiguration

Euro

452000

Personentage

320

Modell

IBM_iSeries

Typ

Rack

Betriebssystemname

Red_Hat_Linux_9

Familie

Unix

Tabelle A-1: Extrahierte Instanzen des Falls 1

Fall 2: Natürlichsprachlich repräsentiertes Projektwissen: In diesem Projekt wurden die Server, auf denen das Planungstool Sungard Global One betrieben wurde, gegen neue leistungsfähigere Server gewechselt. Sungard Global One ist eine Standardapplikation, die der Unterstützung des Handels von Wertpapieren dient. Die obsolete Hardware für Sungard Global One bestand aus zwei AIX-Systemen, die die aktuellen Leistungsanforderungen in Bezug auf die Ausführungsgeschwindigkeit von regelmäßigen Aktionen mit Hilfe des Tools nicht mehr erfüllen konnten. Die verwendete Betriebssystem-Version AIX 4.3.3 wurde im Rahmen der Migration von Global One von den alten auf die neuen Server aktualisiert. Die neuen Server waren virtuell und wurden als VMWare von einem VMWare-ESX-System bereitgestellt. Die aufgewendeten Ressourcen bestanden aus 12200 Euro Kosten und 16 Personentagen.

Exemplarische Fälle zur Repräsentation von Projektwissen

267

Entfernung von Stoppwörtern und nicht relevanten Begriffen: In diesem Projekt wurden die Server, auf denen das Planungstool Sungard Global One betrieben wurde, gegen neue leistungsfähigere Server gewechselt. Sungard Global One ist eine Standardapplikation, die der Unterstützung des Handels von Wertpapieren dient. Die obsolete Hardware für Sungard Global One bestand aus zwei AIX-Systemen, die die aktuellen Leistungsanforderungen in Bezug auf die Ausführungsgeschwindigkeit von regelmäßigen Aktionen mit Hilfe des Tools nicht mehr erfüllen konnten. Die verwendete Betriebssystem-Version AIX 4.3.3 wurde im Rahmen der Migration von Global One von den alten auf die neuen Server aktualisiert. Die neuen Server waren virtuell und wurden als VMWare von einem VMWare-ESX-System bereitgestellt. Die aufgewendeten Ressourcen bestanden aus 12200 Euro Kosten und 16 Personentagen. Begriffe nach Normalformreduktion und Korrektur: Projekt, Planungstool, Sungard_Global_One, Server, Wechsel, Standardapplikation, Handel, Hardware, System, Betriebssystem, AIX_4.3.3, Migration, VMWare, VMWare-ESX, 12200, Euro, 16, Personentage. Extrahierte Klassen: Betriebssystem, Hardware, Projekt, Server, Standardapplikation, System.

268

Exemplarische Fälle zur Repräsentation von Projektwissen

extrahierte Instanzen:

Attribute der

Attributswerte der

extrahierten Instanzen:

extrahierten Instanzen:

Serverwechsel_Planungstool Projekttyp

Server_2

AiX_4.3.3

Sungard_Global_One

Migration

Euro

12200

Personentage

16

Modell

VMWare_ESX

Typ

Virtuell

Betriebssystemname

AIX_4.3.3

Familie

Unix

Anwendungsname

Sungard_Global_One

Anwendungsbereich

Handel

Tabelle A-2: Extrahierte Instanzen des Falls 2

Fall 3: Natürlichsprachlich repräsentiertes Projektwissen: Zur Integration einer Firewall in ein bestehendes Netzwerk wurde ein Projekt mit Kosten in Höhe von 65000 Euro durchgeführt. Das Projekt wurde mit einem Aufwand von 77 Personentagen abgeschlossen. Inhalt dieses Projekts war die Installation einer Check Point Firewall auf einem Server des Modells Dell PowerEdge. Der Server wurde in ein Rack eingebaut. Bestandteil der Firewall-Installation war die Installation von Integrity Linux. Hierbei handelte es sich um ein für Firewall-Zwecke angepasstes Linux-Betriebssystem. Entfernung von Stoppwörtern und nicht relevanten Begriffen: Zur Integration einer Firewall in ein bestehendes Netzwerk wurde ein Projekt mit Kosten in Höhe von 65000 Euro durchgeführt. Das Projekt wurde mit einem Aufwand von 77 Personentagen abgeschlossen. Inhalt dieses Projekts war die Installation einer Check Point Firewall auf einem Server des Modells Dell PowerEdge. Der Server wurde in ein Rack eingebaut. Bestandteil der Firewall-Installation war die Installation von Integrity Linux. Hierbei handelte es sich um ein für Firewall-Zwecke angepasstes Linux-Betriebssystem.

Exemplarische Fälle zur Repräsentation von Projektwissen

269

Begriffe nach Normalformreduktion und Korrektur: Integration, Firewall, Netzwerk, Projekt, 65000, Euro, 77, Personentage, Check_Point_ Firewall, Server, Modell, Dell_PowerEdge, Rack, Installation, Integrity_Linux, Linux, Betriebssystem. Extrahierte Klassen: Betriebssystem, Linux, Projekt, Server.

extrahierte Instanzen: Firewall-Integration

Server_3

Integrity_Linux

Check_Point_Firewall

Attribute der

Attributswerte der

extrahierten Instanzen:

extrahierten Instanzen:

Projekttyp

Installation

Euro

65000

Personentage

77

Modell

Dell_PowerEdge

Typ

Rack

Betriebssystemname

Integrity_Linux

Familie

Unix

Anwendungsname

Check_Point_Firewall

Anwendungsbereich

Netzwerk

Tabelle A-3: Extrahierte Instanzen des Falls 3

Fall 4: Natürlichsprachlich repräsentiertes Projektwissen: Es wurde ein Projekt zur Migration von individuell entwickelten Börsensystemen durchgeführt. Die Börsensysteme dienten der Unterstützung von Handelsaktivitäten. Unter Gewährleistung eines ausfallsicheren Betriebs wurden die Börsensysteme auf einen Server des Modells Dell PowerEdge migriert. Dieser Server stand als Tower bereit und wurde mit dem Betriebssystem Sun Solaris 10 betrieben. Damit sollte dem Betriebssystemstand entsprochen werden, der von der Gruppe „Deutsche Börse“ vorgegeben wurde. Für das Pro-

270

Exemplarische Fälle zur Repräsentation von Projektwissen

jekt wurden Kosten in Höhe von 10100 Euro aufgewendet. Insgesamt wurden 12 Personentage für das Projekt benötigt. Entfernung von Stoppwörtern und nicht relevanten Begriffen: Es wurde ein Projekt zur Migration von individuell entwickelten Börsensystemen durchgeführt. Die Börsensysteme dienten der Unterstützung von Handelsaktivitäten. Unter Gewährleistung eines ausfallsicheren Betriebs wurden die Börsensysteme auf einen Server des Modells Dell PowerEdge migriert. Dieser Server stand als Tower bereit und wurde mit dem Betriebssystem Sun Solaris 10 betrieben. Damit sollte dem Betriebssystemstand entsprochen werden, der von der Gruppe „Deutsche Börse“ vorgegeben wurde. Für das Projekt wurden Kosten in Höhe von 10100 Euro aufgewendet. Insgesamt wurden 12 Personentage für das Projekt benötigt. Begriffe nach Normalformreduktion und Korrektur: Projekt, Migration, Individualanwendung, Börsensysteme, Handel, Server, Modell, Dell_ PowerEdge, Tower, Betriebssystem, Sun_Solaris_10, 10100, Euro, 12, Personentage. Extrahierte Klassen: Betriebssystem, Individualanwendung, Projekt, Server.

Exemplarische Fälle zur Repräsentation von Projektwissen

extrahierte Instanzen: Migration_Börsensysteme

Server_4

Sun_Solaris_10

Börsensysteme

271

Attribute der

Attributswerte der

extrahierten Instanzen:

extrahierten Instanzen:

Projekttyp

Migration

Euro

10100

Personentage

12

Modell

Dell_PowerEdge

Typ

Tower

Betriebssystemname

Sun_Solaris_10

Familie

Unix

Anwendungsname

Börsensysteme

Anwendungsbereich

Handel

Tabelle A-4: Extrahierte Instanzen des Falls 4

Fall 5: Natürlichsprachlich repräsentiertes Projektwissen: Für die Bereitstellung eines abgesicherten Zugangs zum Internet für private MitarbeiterTätigkeiten wurde ein Projekt mit Kosten in Höhe von 37500 Euro und 45 Personentagen durchgeführt. Es wurden virtuelle Clients auf einem VMWare-ESX-System installiert. Jeder Mitarbeiter sollte direkt von seinem Arbeitsplatz auf einen dieser virtuellen InternetPCs zugreifen können. Dort sollte das Betriebssystem Microsoft Windows XP zusammen mit der Standardanwendung Internet Explorer genutzt werden können. Der virtuelle Client wurde so eingerichtet, dass keine vertraulichen Daten von Mitarbeitern gespeichert werden. Außerdem sollten die privaten Tätigkeiten nicht überwacht oder eingeschränkt werden. Der virtuelle Client sollte nach jeder Nutzung durch den nutzenden Mitarbeiter in seinen Ursprungszustand zurückgesetzt werden. Entfernung von Stoppwörtern und nicht relevanten Begriffen: Für die Bereitstellung eines abgesicherten Zugangs zum Internet für private MitarbeiterTätigkeiten wurde ein Projekt mit Kosten in Höhe von 37500 Euro und 45 Personentagen

272

Exemplarische Fälle zur Repräsentation von Projektwissen

durchgeführt. Es wurden virtuelle Clients auf einem VMWare-ESX-System installiert. Jeder Mitarbeiter sollte direkt von seinem Arbeitsplatz auf einen dieser virtuellen InternetPCs zugreifen können. Dort sollte das Betriebssystem Microsoft Windows XP zusammen mit der Standardanwendung Internet Explorer genutzt werden können. Der virtuelle Client wurde so eingerichtet, dass keine vertraulichen Daten von Mitarbeitern gespeichert werden. Außerdem sollten die privaten Tätigkeiten nicht überwacht oder eingeschränkt werden. Der virtuelle Client sollte nach jeder Nutzung durch den nutzenden Mitarbeiter in seinen Ursprungszustand zurückgesetzt werden. Begriffe nach Normalformreduktion und Korrektur: Internet, Projekt, 37500, Euro, 45, Personentage, virtuell, Client, VMWare-ESX, System, Internet-PCs, Betriebssystem, Microsoft_Windows_XP, Standardanwendung, Internet_Explorer. Extrahierte Klassen: Client, Betriebssystem, Projekt, Standardanwendung, System.

extrahierte Instanzen: Virtuelle_Internet-PCs

Client_5

Microsoft_Windows_XP

Internet_Explorer

Attribute der

Attributswerte der

extrahierten Instanzen:

extrahierten Instanzen:

Projekttyp

Installation

Euro

37500

Personentage

45

Modell

VMWare_ESX

Typ

Virtuell

Betriebssystemname

Microsoft_Windows_XP

Familie

Windows

Anwendungsname

Internet_Explorer

Anwendungsbereich

Internet

Tabelle A-5: Extrahierte Instanzen des Falls 5

Exemplarische Fälle zur Repräsentation von Projektwissen

273

Fall 6: Natürlichsprachlich repräsentiertes Projektwissen: Das Projekt Disaster Recovery beinhaltete die Bereitstellung von Hardware und Software, um in einem Notfall eine Wiederinbetriebnahme von Anwendungen mit hoher Priorität zu ermöglichen. Auf diese Weise sollten wichtige Betriebsprozesse wiederhergestellt werden. Notebooks des Modells Samsung X50 wurden mit dem Betriebssystem Microsoft Windows XP und der zusätzlich benötigten Software installiert und für die Nutzung bei einem Notfall bereitgestellt. Dieses Projekt wurde mit geplanten Kosten in Höhe von 382000 Euro und 504 Personentagen durchgeführt. Entfernung von Stoppwörtern und nicht relevanten Begriffen: Das Projekt Disaster Recovery beinhaltete die Bereitstellung von Hardware und Software, um in einem Notfall eine Wiederinbetriebnahme von Anwendungen mit hoher Priorität zu ermöglichen. Auf diese Weise sollten wichtige Betriebsprozesse wiederhergestellt werden. Notebooks des Modells Samsung X50 wurden mit dem Betriebssystem Microsoft Windows XP und der zusätzlich benötigten Software installiert und für die Nutzung bei einem Notfall bereitgestellt. Dieses Projekt wurde mit geplanten Kosten in Höhe von 382000 Euro und 504 Personentagen durchgeführt. Begriffe nach Normalformreduktion und Korrektur: Projekt, Disaster_Recovery, Hardware, Software, Anwendung, Notebook, Modell, Samsung_X50, Betriebssystem, Microsoft_Windows_XP, 382000, Euro, 504, Personentage. Extrahierte Klassen: Anwendung, Betriebssystem, Hardware, Projekt, Software.

274

Exemplarische Fälle zur Repräsentation von Projektwissen

extrahierte Instanzen: Disaster_Recovery

Client_6

Microsoft_Windows_XP

Attribute der

Attributswerte der

extrahierten Instanzen:

extrahierten Instanzen:

Projekttyp

Installation

Euro

382000

Personentage

504

Modell

Samsung_X50

Typ

Notebook

Betriebssystemname

Microsoft_Windows_XP

Familie

Windows

Tabelle A-6: Extrahierte Instanzen des Falls 6

Fall 7: Natürlichsprachlich repräsentiertes Projektwissen: Dieses Projekt beinhaltete die Stabilisierung der Vetriebsdatenbank, die für den Bereich Handel des betreibenden Unternehmens individuell entwickelt wurde und Stammdaten von Kunden speicherte. Durch eine Stabilisierung der Vetriebsdatenbank sollten Fehlerzustände reduziert werden. Fehlerzustände sind jegliche Zustände, die die Nutzung der Datenbank stören, z.B. Deadlocks. Die Stabilisierung wurde durch eine Änderung der Konfiguration der Datenbank erreicht. Diese Konfigurationsänderung wurde von einem verbesserten Datenbank-Design abgeleitet. Die Datenbank wurde auf einem virtuellen Server auf einem VMWare-ESX-System betrieben. Auf diesem System wurde das Linux-Betriebssystem Red Hat Linux 9 installiert. Das Projekt wurde mit Kosten in Höhe von 34000 Euro und 55 Personentagen abgeschlossen. Entfernung von Stoppwörtern und nicht relevanten Begriffen: Dieses Projekt beinhaltete die Stabilisierung der Vetriebsdatenbank, die für den Bereich Handel des betreibenden Unternehmens individuell entwickelt wurde und Stammdaten von Kunden speicherte. Durch eine Stabilisierung der Vetriebsdatenbank sollten Fehlerzustände reduziert werden. Fehlerzustände sind jegliche Zustände, die die Nutzung der Datenbank stören, z.B. Deadlocks. Die Stabilisierung wurde durch eine Änderung der Konfigu-

Exemplarische Fälle zur Repräsentation von Projektwissen

275

ration der Datenbank erreicht. Diese Konfigurationsänderung wurde von einem verbesserten Datenbank-Design abgeleitet. Die Datenbank wurde auf einem virtuellen Server auf einem VMWare-ESX-System betrieben. Auf diesem System wurde das Linux-Betriebssystem Red Hat Linux 9 installiert. Das Projekt wurde mit Kosten in Höhe von 34000 Euro und 55 Personentagen abgeschlossen. Begriffe nach Normalformreduktion und Korrektur: Projekt, Stabilisierung, Vetriebsdatenbank, Handel, Individualanwendung, Datenbank, Konfiguration, virtuell, Server, VMWare-ESX, System, Linux, Betriebssystem, Red_Hat_ Linux_9, 34000, Euro, 55, Personentage. Extrahierte Klassen: Betriebssystem, Individualanwendung, Projekt, Server, System.

extrahierte Instanzen: Stabilisierung_ Vertriebsdatenbank

Server_7

Red_Hat_Linux_9

Vertriebsdatenbank

Attribute der

Attributswerte der

extrahierten Instanzen:

extrahierten Instanzen:

Projekttyp

Konfiguration

Euro

34000

Personentage

55

Modell

VMWare_ESX

Typ

Virtuell

Betriebssystemname

Red_Hat_Linux_9

Familie

Unix

Anwendungsname

Vertriebsdatenbank

Anwendungsbereich

Handel

Tabelle A-7: Extrahierte Instanzen des Falls 7

276

Exemplarische Fälle zur Repräsentation von Projektwissen

Fall 8: Natürlichsprachlich repräsentiertes Projektwissen: Dieses Projekt beinhaltete die Einführung eines Internet-basierten Online-Bankings. Beim Online-Banking handelte es sich um eine Webapplikation, die den Kunden die Durchführung von Zahlungsverkehrstransaktionen ermöglicht. Diese Webbapplikation wurde individuell für das Unternehmen entwickelt und auf einem Server des Modells Dell PowerEdge installiert. Der Server wurde in ein Rack innerhalb des Rechenzentrums montiert. Auf dem Server wurde das Betriebssystem Suse Linux 10 betrieben. Das Projekt wurde mit einem Budget von 290000 Euro und 250 Personentagen abgeschlossen. Entfernung von Stoppwörtern und nicht relevanten Begriffen: Dieses Projekt beinhaltete die Einführung eines Internet-basierten Online-Bankings. Beim Online-Banking handelte es sich um eine Webapplikation, die den Kunden die Durchführung von Zahlungsverkehrstransaktionen ermöglicht. Diese Webbapplikation wurde individuell für das Unternehmen entwickelt und auf einem Server des Modells Dell PowerEdge installiert. Der Server wurde in ein Rack innerhalb des Rechenzentrums montiert. Auf dem Server wurde das Betriebssystem Suse Linux 10 betrieben. Das Projekt wurde mit einem Budget von 290000 Euro und 250 Personentagen abgeschlossen. Begriffe nach Normalformreduktion und Korrektur: Projekt, Internet, Online-Banking, Webapplikation, Individualanwendung, Server, Modell, Dell_PowerEdge, Rack, Betriebssystem, Suse_Linux_10, 290000, Euro, 250, Personentage. Extrahierte Klassen: Betriebssystem, Individualanwendung, Projekt, Server.

Exemplarische Fälle zur Repräsentation von Projektwissen

extrahierte Instanzen: Online-Banking

Server_8

Suse_Linux_10

Webapplikation

277

Attribute der

Attributswerte der

extrahierten Instanzen:

extrahierten Instanzen:

Projekttyp

Installation

Euro

290000

Personentage

250

Modell

Dell_PowerEdge

Typ

Rack

Betriebssystemname

Suse_Linux_10

Familie

Unix

Anwendungsname

Webapplikation

Anwendungsbereich

Internet

Tabelle A-8: Extrahierte Instanzen des Falls 8

Fall 9: Natürlichsprachlich repräsentiertes Projektwissen: Zur Einführung der Standardanwendung Augeo wurde ein Projekt durchgeführt. Augeo ist ein Projektmanagement-Tool, das für Projekte innerhalb des Unternehmens genutzt werden sollte. Ressourcenplanungen und Projektinformationen sollten über dieses Tool gespeichert und verwaltet werden. Das Tool wurde auf Clients von Projektmitarbeitern installiert. Bei diesen Clients handelte es sich um Desktop-Geräte des Modells Dell Optiplex mit dem Betriebssystem Microsoft Windows XP. Für das Projekt wurden Kosten in Höhe von 130000 Euro aufgewendet. Insgesamt wurden 110 Personentage für das Projekt benötigt. Entfernung von Stoppwörtern und nicht relevanten Begriffen: Zur Einführung der Standardanwendung Augeo wurde ein Projekt durchgeführt. Augeo ist ein Projektmanagement-Tool, das für Projekte innerhalb des Unternehmens genutzt werden sollte. Ressourcenplanungen und Projektinformationen sollten über dieses Tool gespeichert und verwaltet werden. Das Tool wurde auf Clients von Projektmitarbeitern installiert. Bei diesen Clients handelte es sich um Desktop-Geräte des Modells Dell Optiplex mit dem Be-

278

Exemplarische Fälle zur Repräsentation von Projektwissen

triebssystem Microsoft Windows XP. Für das Projekt wurden Kosten in Höhe von 130000 Euro aufgewendet. Insgesamt wurden 110 Personentage für das Projekt benötigt. Begriffe nach Normalformreduktion und Korrektur: Standardanwendung, Augeo, Projekt, Client, Desktop, Modell, Dell_Optiplex, Betriebssystem, Microsoft_Windows_XP, 130000, Euro, 110, Personentage. Extrahierte Klassen: Betriebssystem, Client, Projekt, Standardanwendung.

extrahierte Instanzen: Projektmanagement-Tool

Client_9

Microsoft_Windows_XP

Augeo

Attribute der

Attributswerte der

extrahierten Instanzen:

extrahierten Instanzen:

Projekttyp

Installation

Euro

130000

Personentage

110

Modell

Dell_Optiplex

Typ

Desktop

Betriebssystemname

Microsoft_Windows_XP

Familie

Windows

Anwendungsname

Augeo

Anwendungsbereich

Projekte

Tabelle A-9: Extrahierte Instanzen des Falls 9

Exemplarische Fälle zur Repräsentation von Projektwissen

279

Fall 10: Natürlichsprachlich repräsentiertes Projektwissen: Auf Grund von langen Wartezeiten beim Starten von Notebooks des Modells Samsung X20 sollte eine Verbesserung der Startgeschwindigkeit erreicht werden. Die Notebooks wurden durch die Mitarbeiter als Clients benutzt und mit dem Betriebssystem Microsoft Windows Vista betrieben. Die Verbesserung erfolgte durch eine Konfiguration der Clients, die die Reihenfolge und die Notwendigkeit von vorhandenen Startprozessen berücksichtigte. Das Projekt wurde mit Kosten in Höhe von 25000 Euro und 28 Personentagen abgeschlossen. Entfernung von Stoppwörtern und nicht relevanten Begriffen: Auf Grund von langen Wartezeiten beim Starten von Notebooks des Modells Samsung X20 sollte eine Verbesserung der Startgeschwindigkeit erreicht werden. Die Notebooks wurden durch die Mitarbeiter als Clients benutzt und mit dem Betriebssystem Microsoft Windows Vista betrieben. Die Verbesserung erfolgte durch eine Konfiguration der Clients, die die Reihenfolge und die Notwendigkeit von vorhandenen Startprozessen berücksichtigte. Das Projekt wurde mit Kosten in Höhe von 25000 Euro und 28 Personentagen abgeschlossen. Begriffe nach Normalformreduktion und Korrektur: Notebook, Modell, Samsung_X20, Verbesserung, Startgeschwindigkeit, Client, Betriebssystem, Microsoft_Windows_Vista, Konfiguration, Projekt, 25000, Euro, 28, Personentage. Extrahierte Klassen: Betriebssystem, Client, Notebook, Projekt.

280

Exemplarische Fälle zur Repräsentation von Projektwissen

extrahierte Instanzen: Verbesserung_Clientstart

Client_10

Microsoft_Windows_Vista

Attribute der

Attributswerte der

extrahierten Instanzen:

extrahierten Instanzen:

Projekttyp

Konfiguration

Euro

25000

Personentage

28

Modell

Samsung_X20

Typ

Notebook

Betriebssystemname

Microsoft_Windows_Vista

Familie

Windows

Tabelle A-10: Extrahierte Instanzen des Falls 10

Anfrage-Fall 1: Natürlichsprachlich repräsentiertes Projektwissen: Die Einführung von Patchmanagement für alle Systeme, die mit Microsoft Windows XP betrieben wurden, beinhaltete die Installation eines zentralen Verteilmechanismus für Patches. Hierzu wurde die Standardanwendung WSUS installiert, mit deren Hilfe neue Patches über das Netzwerk an alle betroffenen Clients übertragen werden konnten. Das Projekt wurde mit Kosten von 420000 Euro und 300 Personentagen durchgeführt. Entfernung von Stoppwörtern und nicht relevanten Begriffen: Die Einführung von Patchmanagement für alle Systeme, die mit Microsoft Windows XP betrieben wurden, beinhaltete die Installation eines zentralen Verteilmechanismus für Patches. Hierzu wurde die Standardanwendung WSUS installiert, mit deren Hilfe neue Patches über das Netzwerk an alle betroffenen Clients übertragen werden konnten. Das Projekt wurde mit Kosten von 420000 Euro und 300 Personentagen durchgeführt. Begriffe nach Normalformreduktion und Korrektur: Einführung, Patchmanagement, System, Microsoft_Windows_XP, Installation, Standardanwendung, WSUS, Netzwerk, Clients, Projekt, 420000, Euro, 300, Personentagen.

Exemplarische Fälle zur Repräsentation von Projektwissen

281

Extrahierte Klassen: System, Standardanwendung, Clients, Projekt.

extrahierte Instanzen: Einführung_ Patchmanagement

Microsoft_Windows_XP

WSUS

Attribute der

Attributswerte der

extrahierten Instanzen:

extrahierten Instanzen:

Projekttyp

Installation

Euro

420000

Personentage

300

Betriebssystemname

Microsoft_Windows_XP

Familie

Windows

Anwendungsname

WSUS

Anwendungsbereich

Netzwerk

Tabelle A-11: Extrahierte Instanzen des Anfrage-Falls 1

Anfrage-Fall 2: Natürlichsprachlich repräsentiertes Projektwissen: Das Projekt zur Aktualisierung der Netzwerkkonfiguration beinhaltete die Konfiguration von lokalen Firewalls auf festgelegten Servern im Netzwerk. Bei den festgelegten Servern handelte es sich um Tower des Modells Dell PowerEdge, die mit dem Betriebssystem Red Hat Linux 9 betrieben wurden. Bei den lokalen Firewalls handelte es sich um die Standardapplikation Iptables. Das Projekt wurde mit Kosten in Höhe von 26000 Euro und 30 Personentagen durchgeführt. Entfernung von Stoppwörtern und nicht relevanten Begriffen: Das Projekt zur Aktualisierung der Netzwerkkonfiguration beinhaltete die Konfiguration von lokalen Firewalls auf festgelegten Servern im Netzwerk. Bei den festgelegten Servern handelte es sich um Tower des Modells Dell PowerEdge, die mit dem Betriebssystem Red Hat Linux 9 betrieben wurden. Bei den lokalen Firewalls handelte es sich um die Standardapplikation Iptables. Das Projekt wurde mit Kosten in Höhe von 26000 Euro und 30 Personentagen durchgeführt.

282

Exemplarische Fälle zur Repräsentation von Projektwissen

Begriffe nach Normalformreduktion und Korrektur: Projekt, Aktualisierung, Netzwerkkonfiguration, Konfiguration, Server, Netzwerk, Tower, Modell, Dell_PowerEdge, Betriebssystem, Red_Hat_Linux_9, Standardapplikation, Iptables, 26000, Euro, 30, Personentage. Extrahierte Klassen: Projekt, Server, Betriebssystem, Standardapplikation.

extrahierte Instanzen: Aktualisierung_ Netzwerkkonfiguration

Server_A2

Red_Hat_Linux_9

Iptables

Attribute der

Attributswerte der

extrahierten Instanzen:

extrahierten Instanzen:

Projekttyp

Konfiguration

Euro

26000

Personentage

30

Modell

Dell_PowerEdge

Typ

Tower

Betriebssystemname

Red_Hat_Linux_9

Familie

Unix

Anwendungsname

Iptables

Anwendungsbereich

Netzwerk

Tabelle A-12: Extrahierte Instanzen des Anfrage-Falls 2

Erstellung des Prototyps

283

Anhang 2: Erstellung des Prototyps Anhang 2.1: Installation von Protégé Die Installation von Protégé wird durch das Ausführen der Installationsdatei „install_protege_3.4.4.exe“ gestartet. Im ersten Fenster (Abbildung A-1) wird auf „Next“ geklickt.

Abbildung A-1: „Introduction“

Die beiden folgenden Installationsvarianten stehen zur Auswahl (Abbildung A-2): typisch und minimal. Die typische Installation bleibt ausgewählt, da sie im Vergleich zur minimalen Installation zusätzliche Plug-Ins beinhaltet. Anschließend wird auf „Next“ geklickt.

284

Erstellung des Prototyps

Abbildung A-2: „Choose Install Set“

Im nächsten Fenster (Abbildung A-3) kann das Zielverzeichnis für die Installation geändert werden. Die Vorgabe wird hier beibehalten. Anschließend wird auf „Next“ geklickt.

Abbildung A-3: „Choose Install Folder“

Erstellung des Prototyps

285

Im folgenden Fenster (Abbildung A-4) kann ausgewählt werden, an welchem Speicherort die Icons von Protégé hinterlegt werden sollen. Die Vorgabe wird hier beibehalten. Anschließend wird auf „Next“ geklickt.

Abbildung A-4: „Choose Shortcut Folder“

Im folgenden Fenster (Abbildung A-5) kann ausgewählt werden, welche Java-Version durch Protégé genutzt werden sollen. Hier wird „Use the Java VM installed with this application“ ausgewählt, um eine möglichst hohe Kompatibilität zwischen Protégé und der genutzten Java-Version zu erhalten. Anschließend wird auf „Next“ geklickt.

286

Erstellung des Prototyps

Abbildung A-5: „Choose Java Virtual Machine“

Im folgenden Fenster (Abbildung A-6) können die vorherigen Angaben nochmals geprüft werden. Anschließend wird auf „Install“ geklickt.

Abbildung A-6: „Pre-Installation Summary“

Erstellung des Prototyps

287

Nach der Installation erscheint ein Fenster (Abbildung A-7) mit einer Fertigstellungsmeldung der Installation. Anschließend wird auf „Done“ geklickt.

Abbildung A-7: „Install Complete“

Anhang 2.2: Installation von MyCBR als Plug-In von Protégé Um das Tool MyCBR in Protégé als Plug-In einzubinden, wird das Tool im Programmverzeichnis von Protégé gespeichert. Hierzu wird aus der gepackten Datei „myCBR-2.6.6bin.zip“ der Ordner „de.dfki.mycbr“ (Unterordner von „protege_plugin“) entpackt und unter „C:\Programme\Protege_3.4.4\plugins“ (Abbildung A-8) gespeichert.

Abbildung A-8: Plug-In-Ordner

288

Erstellung des Prototyps

Anhang 2.3: Start und Konfiguration von Protégé Protégé wird durch das Ausführen der Datei „C:\Programme\Protege_3.4.4\Protege.exe“ gestartet, die über das Protégé-Icon aus dem Startmenü aufgerufen werden kann. Im Willkommens-Fenster (Abbildung A-9) wird ein neues Protégé-Projekt über „New Project“ geöffnet.

Abbildung A-9: „Welcome to Protégé“

Im folgenden Fenster (Abbildung A-10) wird die Ontologiesprache ausgewählt. Hier wird das Format „Protégé Files (.pont and .pins)“ ausgewählt und anschließend auf „Finish“ geklickt.

Abbildung A-10: „Create New Project“

Nach dem Starten von Protégé müssen die Kartenreiter über das Menü „Project“ unter „Configure...“ aktiviert werden (Abbildung A-11).

Erstellung des Prototyps

289

Abbildung A-11: Aufruf des Konfigurationsmenüs

Hierdurch öffnet sich ein Unterfenster (Abbildung A-12), in dem die Kartenreiter (Tab Widgets) mit den Namen „MyCbr_Similarities_Tab“ und „MyCbr_Retrieval_Tab“ ausgewählt werden müssen.

Abbildung A-12: Auswahl der Kartenreiter

290

Erstellung des Prototyps

Anhang 2.4: Erstellen der Klassen Die Erstellung der Klassen der Ontologie erfolgt über die Karteikarte „Classes“ (Abbildung A-13). Durch einen Rechtsklick auf eine Klasse öffnet sich ein Menü, das die Erstellung einer Unterklasse mittels „Create Class“ zulässt. Klassen, die sich in der Klassenhierarchie der Ontologie ganz oben befinden, werden als Unterklassen der Klasse „Thing“ angelegt.

Abbildung A-13: „Create Class“

In Protégé erhält jede angelegte Klasse einen automatisch generierten Namen, z.B. „Class_1“. Daher werden anschließend die Namen der Klassen im „Class Editor“ im Feld „Name“ geändert (Abbildung A-14).

Abbildung A-14: „Class Editor“

Erstellung des Prototyps

291

Anhang 2.5: Import der Instanzen Unter dem Menüpunkt „MyCBR“ & „Import Instances from CSV...“ wird das Fallwissen aus den Tabellen A-1 bis A-10, das in Form von CSV-Listen gespeichert wurde, importiert (Abbildung A-15).

Abbildung A-15: „Import Instances from CSV...“

Für jede Klasse, die Instanzen enthält, muss ein Import der zugehörigen CSV-Liste durchgeführt werden (Abbildung A-16).

Abbildung A-16: Auswahl einer CSV-Liste

Sollte die Fehlermeldung „Sorry, could not import some rows“ erscheinen, ist zu prüfen, ob Instanzen, die importiert werden sollen, bereits existierende Slots benutzen und diese

292

Erstellung des Prototyps

Slots eine restriktive Wertemenge besitzen. Eine restriktive Wertemenge kann der Grund dafür sein, dass neue Werte aus den importierten Instanzen nicht akzeptiert werden. In diesem Fall muss der Wertebereich eines Attributs vor dem Import der neuen Instanzen manuell über den Slot-Editor erweitert werden. Wenn beim Import der CSV-Listen alphabetisch vorgegangen wird, müssen Wertebereiche vor dem Import der Instanzen der Klassen „Server“ und „Standardanwendung“ erweitert werden (siehe unten). Das Importer-Fenster (Abbildung A-17) zeigt eine Vorschau der zu importierenden Werte.

Abbildung A-17: „Importer“

Im zweiten Schritt des Importvorgangs werden neu angelegte Slots aufgeführt (Abbildung A-18). Hier ist zu prüfen, ob die Slot-Typen durch Protégé korrekt erkannt wurden. Die Relationen werden hier fälschlicher Weise als Attribute des Typs „Symbol“ erkannt. Dies muss nach dem Importvorgang im Slot-Editor korrigiert werden. Durch die Umstellung des Slot-Typs auf „Instance“ wird ein Slot zur Relation.

Erstellung des Prototyps

293

Abbildung A-18: „Create Slots?“

Im dritten Schritt des Importvorgangs (Abbildung A-19) wird ausgewählt, wie die Namen der Instanzen generiert werden sollen. Hier wird bei den Klassen „Client“, „Projekt“ und „Server“ das Feld „Name“, bei der Klasse „Betriebssystem“ das Feld „Betriebssystemname“ und bei den Klassen „Individualanwendung“ und „Standardanwendung“ das Feld „Anwendungsname“ ausgewählt.

Abbildung A-19: „How to generate its names?“

Nach dem Import der Instanzen der Klasse „Client“ wurden automatisch die Wertebereiche für die Slots „Typ“ und „Modell“ definiert. Vor dem Import der Instanzen der Klasse „Server“ müssen diese Slots erweitert werden (Abbildung A-20). Der Wertebereich des

294

Erstellung des Prototyps

Slots „Typ“ muss um die Werte „Tower“, „Virtuell“ und „Rack“ erweitert werden. Der Wertebereich des Slots „Modell“ muss um die Werte „IBM_iSeries“, „VMWare_ESX“ und „Dell_PowerEdge“ erweitert werden. Außerdem muss die Domäne der beiden Slots von der Klasse „Client“ auf die Oberklasse „Hardware“ geändert werden, da diese Slots auch von der Klasse „Server“ genutzt werden. Nach dem Import der Instanzen der Klasse „Individualanwendung“ wurden automatisch die Wertebereiche für die Slots „Anwendungsname“ und „Anwendungsbereich“ definiert. Vor dem Import der Instanzen der Klasse „Standardanwendung“ müssen diese Slots erweitert werden. Der Wertebereich des Slots „Anwendungsname“ muss um die Werte „Sungard_Global_One“, „Check_Point_Firewall“, „Internet_Explorer“ und „Augeo“ erweitert werden. Der Wertebereich des Slots „Anwendungsbereich“ muss um die Werte „Netzwerk“ und „Projekte“ erweitert werden. Außerdem muss die Domäne der beiden Slots von der Klasse „Individualanwendung“ auf die Oberklasse „Anwendung“ geändert werden, da diese Slots auch von der Klasse „Standardanwendung“ genutzt werden.

Abbildung A-20: „Create Symbol“

Jeweils nach einem Import von Instanzen wird im Slot-Editor der Slot „Name“ gelöscht, da dieser nur für die Benennung der Instanzen genutzt wird und keine Relevanz für die weite-

Erstellung des Prototyps

295

ren Schritte besitzt. Die Wertetypen (Value Type) der Slots „betrifftAnwendung“, „betrifftBetriebssystem“ und „betrifftHardware“ werden auf „Instance“ geändert (Abbildung A-21). Dadurch werden diese Slots zu Relationen.

Abbildung A-21: „Value Type“

Für die Relationen müssen anschließend die Wertebereiche definiert werden. Hierzu werden im Feld „Allowed Classes“ (Abbildung A-22) alle Klassen eingetragen, deren Instanzen durch die Relationen miteinander verknüpft werden können. Für den Slot „betrifftAnwendung“ werden die Klassen „Individualanwendung“ und „Standardanwendung“ ausgewählt, für den Slot „bestrifftBetriebssystem“ wird die Klasse „Betriebssystem“ ausgewählt und für den Slot „betrifftHardware“ werden die Klassen „Client“ und „Server“ ausgewählt.

296

Erstellung des Prototyps

Abbildung A-22: „Select Classes“

Durch die Änderung der Wertetypen der Slots wurden die Werte dieser Slots innerhalb der Instanzen gelöscht. Deshalb müssen die Werte der Relationen für alle Instanzen der Klasse „Projekt“ im Instance-Browser neu belegt werden (Abbildung A-23).

Abbildung A-23: „Select Instance“

Erstellung des Prototyps

297

Die Werte der Relationen für alle Instanzen der Klasse „Projekt“ können der Tabelle A-13 entnommen werden.

Projekt Name

betrifftHardware

betrifftBetriebssystem

betrifftAnwendung

Unix-Härtung

Server_1

Red_Hat_Linux_9

unbekannt

Serverwechsel_ Planungstool

Server_2

AiX_4.3.3

Sungard_Global_One

Firewall-Integration

Server_3

Integrity_Linux

Check_Point_Firewall

Migration_ Börsensysteme

Server_4

Sun_Solaris_10

Börsensysteme

Virtuelle_ Internet-PCs

Client_5

Microsoft_ Windows_XP

Internet_Explorer

Disaster_Recovery

Client_6

Microsoft_ Windows_XP

unbekannt

Stabilisierung_ Vertriebsdatenbank

Server_7

Red_Hat_Linux_9

Vertriebsdatenbank

Online-Banking

Server_8

Suse_Linux_10

Webapplikation

ProjektmanagementTool

Client_9

Microsoft_ Windows_XP

Augeo

Verbesserung_ Clientstart

Client_10

Microsoft_ Windows_Vista

unbekannt

Tabelle A-13: Werte der Relationen

Anhang 2.6: Konfiguration der lokalen Ähnlichkeitsmaßstäbe Die Konfiguration der lokalen Ähnlichkeitsmaßstäbe wird über den Similarity-MeasureEditor durchgeführt. Es werden drei verschiedene Typen von Ähnlichkeitsmaßstäben genutzt: „Table“, „Standard“ und „Taxonomy“. Die Details zu den Inhalten der Ähnlichkeitsmaßstäbe sind dem Kapitel 3.2.3.4 zu entnehmen.

298

Erstellung des Prototyps Der Typ „Table“ wird für die Slots „Projekttyp“, „Familie“, „Anwendungsname“,

„Anwendungsbereich“ und „Typ“ verwendet. Die Ähnlichkeiten zwischen jeweils zwei Attributswerten werden in Form einer Tabelle hinterlegt (Abbildungen A-24 bis A-28).

Abbildung A-24: Ähnlichkeitsmaßstab für den Slot „Projekttyp“

Abbildung A-25: Ähnlichkeitsmaßstab für den Slot „Familie“

Erstellung des Prototyps

Abbildung A-26: Ähnlichkeitsmaßstab für den Slot „Anwendungsname“

Abbildung A-27: Ähnlichkeitsmaßstab für den Slot „Anwendungsbereich“

Abbildung A-28: Ähnlichkeitsmaßstab für den Slot „Typ“

299

300

Erstellung des Prototyps

Der Typ „Standard“ wird für die Slots „Euro“ und „Personentage“ verwendet. Die Ähnlichkeiten zwischen jeweils zwei Attributswerten werden durch den Abstand (englisch: difference) zwischen diesen Werten berechnet (Abbildungen A-29 bis A-30).

Abbildung A-29: Ähnlichkeitsmaßstab für den Slot „Euro“

Erstellung des Prototyps

301

Abbildung A-30: Ähnlichkeitsmaßstab für den Slot „Personentage“

Der Typ „Taxonomy“ wird für die Slots „Betriebssystemname“ und „Modell“ verwendet (Abbildungen A-31 bis A-32). Die Ähnlichkeiten zwischen jeweils zwei Attributswerten werden durch die Position der Knoten für diese Werte innerhalb der Taxonomie und durch die hinterlegten Ähnlichkeitswerte an den Verzweigungen der Taxonomie berechnet. Um die Taxonomien vollständig zu erstellen, müssen alle benötigten Werte, die nicht mit Hilfe der CSV-Listen importiert wurden, mittels des Slot-Editors angelegt werden. Dies betrifft speziell Werte, die innerhalb der Taxonomie als Knoten mit Nachfolgern genutzt werden. Für den Slot „Betriebssystemname“ müssen die Werte „Microsoft_Windows“, „Unix“, und „Linux“ ergänzt werden. Für den Slot „Modell“ müssen die Werte „physikalisches_ System“, „virtuelles_System“, „Samsung_Notebook“ und „Dell_System“ ergänzt werden.

302

Erstellung des Prototyps

Abbildung A-31: Ähnlichkeitsmaßstab für den Slot „Betriebssystemname“

Abbildung A-32: Ähnlichkeitsmaßstab für den Slot „Modell“

Erstellung des Prototyps

303

Um die Aggregation von lokalen zu globalen Ähnlichkeitswerten einzurichten, wird im Similarity-Measure-Editor bei jeder Klasse als Aggregationsfunktion „Weighted Sum“ ausgewählt (Abbildung A-33). Für die Klasse „Projekt“ wird außerdem das Gewicht des Slots „Projekttyp“ von 1 auf 2 angepasst, um die Gewichte gemäß Tabelle 58 zu belegen.

Abbildung A-33: Aggregationsfunktion für die Klasse „Projekt“

Für die Klasse „System“ wird definiert, wie der Wert für die Ähnlichkeit zwischen Klassen innerhalb der Klassenhierarchie berechnet werden soll. Im Similarity-Measure-Editor ist oben rechts ein Button mit dem Titel „Configure Inheritance Similarity” vorhanden (Abbildung A-34). Nach dem Anklicken des Buttons öffnet sich eine Hierarchie, deren Knoten mit Drag & Drop verschoben werden können. Mit einem Rechtsklick auf eine Klasse mit Unterklassen werden Ähnlichkeitswerte eingegeben.

304

Erstellung des Prototyps

Abbildung A-34: „Configure Inheritance Similarity“

Über den Menüpunkt „Options...“ (Abbildung A-35) wird ein Fenster geöffnet, in dem festgelegt wird, dass Attribute und Relationen mit unbekannten Werten im Anfrage-Fall und in den Fällen aus der Fallbasis nicht ignoriert werden sollen (Abbildung A-36). Hierzu werden die Häkchen im Bereich „Ignore "_undefined_" in retrieval“ entfernt.

Abbildung A-35: Menüpunkt „Options...“ in Protégé

Erstellung des Prototyps

305

Abbildung A-36: „Project Options“

Über den Menüpunkt „Configure Special Values...“ (Abbildung A-37) wird ein Fenster geöffnet, in dem festegelegt wird, welche Ähnlichkeiten bei Attributen und Relationen mit unbekannten Werten verwendet werden (Abbildung A-38). Die Werte für die Ähnlichkeit zwischen einem unbekannten Wert (undefined) und einem bekannten Wert (Non-Special Value) und für die Ähnlichkeit zwischen zwei unbekannten Werten wird auf Null geändert. Der Wert für die Ähnlichkeit zwischen zwei bekannten Werten wird auf Eins geändert.

Abbildung A-37: Menüpunkt „Configure Special Values...“ in Protégé

306

Erstellung des Prototyps

Abbildung A-38: „Configure Special Values...“

Anhang 2.7: Import der Anfrage-Fälle Der Import der neuen Anfrage-Fälle kann analog zum Import der alten Fälle durch den Import von CSV-Listen durchgeführt werden. Vor dem Import der neuen Anfrage-Fälle muss der Wertebereich des Slots „Anwendungsname“ erweitert werden. In den Anfrage-Fällen sind für diesen Slot neue Werte enthalten. Der Slot muss um die Werte „WSUS“ und „Iptables“ erweitert werden (Abbildung A-39), weil diese Werte von Protégé sonst nicht für den Slot erlaubt werden.

Abbildung A-39: Erweiterung des Wertebereichs des Slots „Anwendungsname“

Erstellung des Prototyps

307

Anschließend werden folgende CSV-Listen importiert (Abbildung A-40): x

Anfrage_Fall_1_Projekt.csv

x

Anfrage_Fall_1_Standardanwendung.csv

x

Anfrage_Fall_2_Projekt.csv

x

Anfrage_Fall_2_Server.csv

x

Anfrage_Fall_2_Standardanwendung.csv

Abbildung A-40: Import der CSV-Listen

Der erweiterte Wertebereich des Slots „Anwendungsname“ führt dazu, dass auch der lokale Ähnlichkeitsmaßstab für diesen Slot mit Hilfe des Similarity-Measure-Editors erweitert werden muss (Abbildung A-41). Gemäß Tabelle 66 auf S. 204 wird der Wert für die Ähnlichkeit zwischen den Attributswerten „IpTables“ und „Check_Point_Firewall“ mit 0,6 und der Wert für die Ähnlichkeit zwischen den Attributswerten „WSUS“ und „Webapplikation“ mit 0,1 angegeben.

308

Erstellung des Prototyps

Abbildung A-41: Erweiterung des lokalen Ähnlichkeitsmaßstabs für den Slot „Anwendungsname“

Anhang 2.8: Durchführung der Fallidentifikation Zur Durchführung der Fallidentifikation wird die Karteikarte „MyCBR-Retrieval“ ausgewählt (Abbildung A-42). Hier wird die Klasse „Projekt“ ausgewählt. Anschließend können die Attributswerte eines Anfrage-Falls über den Button „Load“ in die Suchmaske geladen werden. Anschließend wird die Fallidentifikation mit einem Klick auf den Button „Retrieval“ gestartet.

Erstellung des Prototyps

309

Abbildung A-42: „CBR Retrieval“

Anhang 2.9: Probleme bei der Speicherung der Ähnlichkeitsmaßstäbe in Protégé Ähnlichkeitswerte, die am obersten Knoten in einer Taxonomie eingegeben werden, werden im GUI von Protégé nicht angezeigt (vgl. Abbildungen A-31 und A-32). Außerdem werden die Ähnlichkeitswerte trotz Speicherung nach dem Beenden von Protégé verworfen. Dieses Problem kann man dadurch umgehen, dass man nach jedem Starten von Protégé eine erneute Eingabe dieser Ähnlichkeitswerte vornimmt. Hier handelt es sich um den Ähnlichkeitswert 0,2 des obersten Knotens der Taxonomie des Slots „Modell“ für die Instanzen der Klassen „Server“ und „Client“ sowie um den Ähnlichkeitswert 0,2 des obersten Knotens der Taxonomie des Slots „Betriebssystemname“ für die Instanzen der Klasse „Betriebssystem“.

Formalsprachliche Darstellungen

311

Anhang 3: Formalsprachliche Darstellungen Anhang 3.1: CSV-Listen zum Import von Fallwissen Die folgenden CSV-Listen enthalten das Fallwissen, das in dieser Arbeit genutzt wurde. Betriebssystem.csv: Betriebssystemname;Familie Red_Hat_Linux_9;Unix AiX_4.3.3;Unix Integrity_Linux;Unix Sun_Solaris_10;Unix Microsoft_Windows_XP;Windows Microsoft_Windows_Vista;Windows Suse_Linux_10;Unix Client.csv: Name;Typ;Modell Client_5;Virtuell;VMWare_ESX Client_6;Notebook;Samsung_X50 Client_9;Desktop;Dell_Optiplex Client_10;Notebook;Samsung_X20 Individualanwendung.csv: Anwendungsname;Anwendungsbereich Börsensysteme;Handel Vertriebsdatenbank;Handel Webapplikation;Internet Projekt.csv: Name;Projekttyp;Euro;Personentage;betrifftHardware;bestrifftBetriebssystem;betrifftAnwendung Unix-Härtung;Konfiguration;452000;320;Server_1;Red_Hat_Linux_9; Serverwechsel_Planungstool;Migration;12200;16;Server_2;AiX_4.3.3;Sungard_Global_One Firewall-Integration;Installation;65000;77;Server_3;Integrity_Linux;Check_Point_Firewall Migration_Börsensysteme;Migration;10100;12;Server_4;Sun_Solaris_10;Börsensysteme Virtuelle_Internet-PCs;Installation;37500;45;Client_5;Microsoft_Windows_XP;Internet_Explorer Disaster_Recovery;Installation;382000;504;Client_6;Microsoft_Windows_XP; Stabilisierung_Vertriebsdatenbank;Konfiguration;34000;55;Server_7;Red_Hat_Linux_9;Vertriebsdatenbank Online-Banking;Installation;290000;250;Server_8;Suse_Linux_10;Webapplikation Projektmanagement-Tool;Installation;130000;110;Client_9;Microsoft_Windows_XP;Augeo Verbesserung_Clientstart;Konfiguration;25000;28;Client_10;Microsoft_Windows_Vista; Server.csv: Name;Typ;Modell Server_1;Rack;IBM_iSeries Server_2;Virtuell;VMWare_ESX Server_3;Rack;Dell_PowerEdge Server_4;Tower;Dell_PowerEdge

312

Formalsprachliche Darstellungen

Server_7;Virtuell;VMWare_ESX Server_8;Rack;Dell_PowerEdge Standardanwendung.csv: Anwendungsname;Anwendungsbereich Sungard_Global_One;Handel Check_Point_Firewall;Netzwerk Internet_Explorer;Internet Augeo;Projekte Anfrage_Fall_1_Projekt.csv: Name;Projekttyp;Euro;Personentage;betrifftHardware;bestrifftBetriebssystem;betrifftAnwendung Einführung_Patchmanagement;Installation;420000;300;;Microsoft_Windows_XP;WSUS Anfrage_Fall_1_Standardanwendung.csv: Anwendungsname;Anwendungsbereich WSUS;Netzwerk Anfrage_Fall_2_Projekt.csv: Name;Projekttyp;Euro;Personentage;betrifftHardware;bestrifftBetriebssystem;betrifftAnwendung Aktualisierung_Netzwerkkonfiguration;Konfiguration;26000;30;Dell_PowerEdge;Red_Hat_Linux_9; Iptables Anfrage_Fall_2_Server.csv: Name;Typ;Modell Server_A2;Tower;Dell_PowerEdge Anfrage_Fall_2_Standardanwendung.csv: Anwendungsname;Anwendungsbereich Iptables;Netzwerk

Anhang 3.2: Klassen der Ontologie im Protégé-Format Die folgende Datei enthält die formalsprachliche Darstellung aller Klassen der Ontologie. Implementierung.pont: ; Tue Jun 29 14:41:41 CEST 2010 ; ;+ (version "3.4.4") ;+ (build "Build 579")

(defclass %3ACLIPS_TOP_LEVEL_SLOT_CLASS "Fake class to save top-level slot information" (is-a USER) (role abstract) (single-slot Anwendungsname

Formalsprachliche Darstellungen

313

(type SYMBOL) (allowed-values Webapplikation Vertriebsdatenbank B%C3%B6rsensysteme Sungard_Global_One Check_Point_Firewall Internet_Explorer Augeo WSUS Iptables) ;+ (cardinality 0 1) (create-accessor read-write)) (single-slot Anwendungsbereich (type SYMBOL) (allowed-values Handel Internet Netzwerk Projekte) ;+ (cardinality 0 1) (create-accessor read-write)) (single-slot Projekttyp (type SYMBOL) (allowed-values Konfiguration Migration Installation) ;+ (cardinality 0 1) (create-accessor read-write)) (single-slot Modell (type SYMBOL) (allowed-values Samsung_X20 Dell_Optiplex VMWare_ESX Samsung_X50 IBM_iSeries Dell_PowerEdge physikalisches_System virtuelles_System Samsung_Notebook Dell_System) ;+ (cardinality 0 1) (create-accessor read-write)) (single-slot Typ (type SYMBOL) (allowed-values Desktop Notebook Tower Virtuell Rack) ;+ (cardinality 0 1) (create-accessor read-write)) (single-slot betrifftHardware (type INSTANCE) ;+ (allowed-classes Hardware) ;+ (cardinality 0 1) (create-accessor read-write)) (single-slot betrifftAnwendung (type INSTANCE) ;+ (allowed-classes Anwendung) ;+ (cardinality 0 1) (create-accessor read-write)) (single-slot Betriebssystemname (type SYMBOL) (allowed-values Integrity_Linux Microsoft_Windows_Vista Red_Hat_Linux_9 Suse_Linux_10 AiX_4.3.3 Microsoft_Windows_XP Sun_Solaris_10 Unix Linux Microsoft_Windows) ;+ (cardinality 0 1) (create-accessor read-write)) (single-slot Familie (type SYMBOL) (allowed-values Windows Unix) ;+ (cardinality 0 1) (create-accessor read-write)) (single-slot Euro (type INTEGER) (range 10100 452000) ;+ (cardinality 0 1) (create-accessor read-write)) (single-slot bestrifftBetriebssystem

314

;+ ;+

;+

Formalsprachliche Darstellungen (type INSTANCE) (allowed-classes Betriebssystem) (cardinality 0 1) (create-accessor read-write)) (single-slot Personentage (type INTEGER) (range 12 504) (cardinality 0 1) (create-accessor read-write)))

(defclass Projekt (is-a USER) (role concrete) (single-slot betrifftHardware (type INSTANCE) ;+ (allowed-classes Hardware) ;+ (cardinality 0 1) (create-accessor read-write)) (single-slot betrifftAnwendung (type INSTANCE) ;+ (allowed-classes Anwendung) ;+ (cardinality 0 1) (create-accessor read-write)) (single-slot Euro (type INTEGER) (range 10100 452000) ;+ (cardinality 0 1) (create-accessor read-write)) (single-slot Projekttyp (type SYMBOL) (allowed-values Konfiguration Migration Installation) ;+ (cardinality 0 1) (create-accessor read-write)) (single-slot bestrifftBetriebssystem (type INSTANCE) ;+ (allowed-classes Betriebssystem) ;+ (cardinality 0 1) (create-accessor read-write)) (single-slot Personentage (type INTEGER) (range 12 504) ;+ (cardinality 0 1) (create-accessor read-write))) (defclass System (is-a USER) (role concrete)) (defclass Hardware (is-a System) (role concrete) (single-slot Modell (type SYMBOL)

Formalsprachliche Darstellungen

315

(allowed-values Samsung_X20 Dell_Optiplex VMWare_ESX Samsung_X50 IBM_iSeries Dell_PowerEdge physikalisches_System virtuelles_System Samsung_Notebook Dell_System) ;+ (cardinality 0 1) (create-accessor read-write)) (single-slot Typ (type SYMBOL) (allowed-values Desktop Notebook Tower Virtuell Rack) ;+ (cardinality 0 1) (create-accessor read-write))) (defclass Server (is-a Hardware) (role concrete)) (defclass Client (is-a Hardware) (role concrete)) (defclass Software (is-a System) (role concrete)) (defclass Betriebssystem (is-a Software) (role concrete) (single-slot Betriebssystemname (type SYMBOL) (allowed-values Integrity_Linux Microsoft_Windows_Vista Red_Hat_Linux_9 Suse_Linux_10 AiX_4.3.3 Microsoft_Windows_XP Sun_Solaris_10 Unix Linux Microsoft_Windows) ;+ (cardinality 0 1) (create-accessor read-write)) (single-slot Familie (type SYMBOL) (allowed-values Windows Unix) ;+ (cardinality 0 1) (create-accessor read-write))) (defclass Anwendung (is-a Software) (role concrete) (single-slot Anwendungsname (type SYMBOL) (allowed-values Webapplikation Vertriebsdatenbank B%C3%B6rsensysteme Sungard_Global_One Check_Point_Firewall Internet_Explorer Augeo WSUS Iptables) ;+ (cardinality 0 1) (create-accessor read-write)) (single-slot Anwendungsbereich (type SYMBOL) (allowed-values Handel Internet Netzwerk Projekte) ;+ (cardinality 0 1) (create-accessor read-write))) (defclass Standardanwendung

316

Formalsprachliche Darstellungen (is-a Anwendung) (role concrete))

(defclass Individualanwendung (is-a Anwendung) (role concrete))

Anhang 3.3: Instanzen der Ontologie im Protégé-Format Die folgende Datei enthält die formalsprachliche Darstellung aller Instanzen der Ontologie. Implementierung.pins: ; Tue Jun 29 14:41:41 CEST 2010 ; ;+ (version "3.4.4") ;+ (build "Build 579") ([AiX_4.3.3] of Betriebssystem (Betriebssystemname AiX_4.3.3) (Familie Unix)) ([Aktualisierung_Netzwerkkonfiguration] of Projekt (bestrifftBetriebssystem [Red_Hat_Linux_9]) (betrifftAnwendung [Iptables]) (betrifftHardware [Server_A2]) (Euro 26000) (Personentage 30) (Projekttyp Konfiguration)) ([Augeo] of Standardanwendung (Anwendungsbereich Projekte) (Anwendungsname Augeo)) ([B%C3%B6rsensysteme] of Individualanwendung (Anwendungsbereich Handel) (Anwendungsname B%C3%B6rsensysteme)) ([Check_Point_Firewall] of Standardanwendung (Anwendungsbereich Netzwerk) (Anwendungsname Check_Point_Firewall)) ([Client_10] of Client (Modell Samsung_X20) (Typ Notebook))

Formalsprachliche Darstellungen ([Client_5] of Client (Modell VMWare_ESX) (Typ Virtuell)) ([Client_6] of Client (Modell Samsung_X50) (Typ Notebook)) ([Client_9] of Client (Modell Dell_Optiplex) (Typ Desktop)) ([Disaster_Recovery] of Projekt (bestrifftBetriebssystem [Microsoft_Windows_XP]) (betrifftHardware [Client_6]) (Euro 382000) (Personentage 504) (Projekttyp Installation)) ([Einf%C3%BChrung_Patchmanagement] of Projekt (bestrifftBetriebssystem [Microsoft_Windows_XP]) (betrifftAnwendung [WSUS]) (Euro 420000) (Personentage 300) (Projekttyp Installation)) ([Firewall-Integration] of Projekt (bestrifftBetriebssystem [Integrity_Linux]) (betrifftAnwendung [Check_Point_Firewall]) (betrifftHardware [Server_3]) (Euro 65000) (Personentage 77) (Projekttyp Installation)) ([Integrity_Linux] of Betriebssystem (Betriebssystemname Integrity_Linux) (Familie Unix)) ([Internet_Explorer] of Standardanwendung (Anwendungsbereich Internet) (Anwendungsname Internet_Explorer)) ([Iptables] of Standardanwendung (Anwendungsbereich Netzwerk)

317

318

Formalsprachliche Darstellungen (Anwendungsname Iptables))

([Microsoft_Windows_Vista] of Betriebssystem (Betriebssystemname Microsoft_Windows_Vista) (Familie Windows)) ([Microsoft_Windows_XP] of Betriebssystem (Betriebssystemname Microsoft_Windows_XP) (Familie Windows)) ([Migration_B%C3%B6rsensysteme] of Projekt (bestrifftBetriebssystem [Sun_Solaris_10]) (betrifftAnwendung [B%C3%B6rsensysteme]) (betrifftHardware [Server_4]) (Euro 10100) (Personentage 12) (Projekttyp Migration)) ([Online-Banking] of Projekt (bestrifftBetriebssystem [Suse_Linux_10]) (betrifftAnwendung [Webapplikation]) (betrifftHardware [Server_8]) (Euro 290000) (Personentage 250) (Projekttyp Installation)) ([Projektmanagement-Tool] of Projekt (bestrifftBetriebssystem [Microsoft_Windows_XP]) (betrifftAnwendung [Augeo]) (betrifftHardware [Client_9]) (Euro 130000) (Personentage 110) (Projekttyp Installation)) ([Red_Hat_Linux_9] of Betriebssystem (Betriebssystemname Red_Hat_Linux_9) (Familie Unix)) ([Server_1] of Server (Modell IBM_iSeries) (Typ Rack)) ([Server_2] of Server (Modell VMWare_ESX) (Typ Virtuell))

Formalsprachliche Darstellungen

([Server_3] of Server (Modell Dell_PowerEdge) (Typ Rack)) ([Server_4] of Server (Modell Dell_PowerEdge) (Typ Tower)) ([Server_7] of Server (Modell VMWare_ESX) (Typ Virtuell)) ([Server_8] of Server (Modell Dell_PowerEdge) (Typ Rack)) ([Server_A2] of Server (Modell Dell_PowerEdge) (Typ Tower)) ([Serverwechsel_Planungstool] of Projekt (bestrifftBetriebssystem [AiX_4.3.3]) (betrifftAnwendung [Sungard_Global_One]) (betrifftHardware [Server_2]) (Euro 12200) (Personentage 16) (Projekttyp Migration)) ([Stabilisierung_Vertriebsdatenbank] of Projekt (bestrifftBetriebssystem [Red_Hat_Linux_9]) (betrifftAnwendung [Vertriebsdatenbank]) (betrifftHardware [Server_7]) (Euro 34000) (Personentage 55) (Projekttyp Konfiguration)) ([Sun_Solaris_10] of Betriebssystem (Betriebssystemname Sun_Solaris_10) (Familie Unix)) ([Sungard_Global_One] of Standardanwendung (Anwendungsbereich Handel) (Anwendungsname Sungard_Global_One))

319

320

Formalsprachliche Darstellungen

([Suse_Linux_10] of Betriebssystem (Betriebssystemname Suse_Linux_10) (Familie Unix)) ([Unix-H%C3%A4rtung] of Projekt (bestrifftBetriebssystem [Red_Hat_Linux_9]) (betrifftHardware [Server_1]) (Euro 452000) (Personentage 320) (Projekttyp Konfiguration)) ([Verbesserung_Clientstart] of Projekt (bestrifftBetriebssystem [Microsoft_Windows_Vista]) (betrifftHardware [Client_10]) (Euro 25000) (Personentage 28) (Projekttyp Konfiguration)) ([Vertriebsdatenbank] of Individualanwendung (Anwendungsbereich Handel) (Anwendungsname Vertriebsdatenbank)) ([Virtuelle_Internet-PCs] of Projekt (bestrifftBetriebssystem [Microsoft_Windows_XP]) (betrifftAnwendung [Internet_Explorer]) (betrifftHardware [Client_5]) (Euro 37500) (Personentage 45) (Projekttyp Installation)) ([Webapplikation] of Individualanwendung (Anwendungsbereich Internet) (Anwendungsname Webapplikation)) ([WSUS] of Standardanwendung (Anwendungsbereich Netzwerk) (Anwendungsname WSUS))

Formalsprachliche Darstellungen Anhang 3.4: Konfigurationsdatei für Protégé Diese Konfigurationsdatei enthält grundlegende Konfigurationen für Protégé. Implementierung.pprj: ; Tue Jun 29 14:41:41 CEST 2010 ; ;+ (version "3.4.4") ;+ (build "Build 579") ([ANNOTATED_INSTANCE_WIDGET] of Widget (name ":ANNOTATED-INSTANCE")) ([ANNOTATION_TEXT_WIDGET] of Widget (height 100) (is_hidden FALSE) (name ":ANNOTATION-TEXT") (widget_class_name "edu.stanford.smi.protege.widget.YellowStickyWidget") (width 200) (x 0) (y 0)) ([BROWSER_SLOT_NAMES] of Property_List (properties [Implementierung_ProjectKB_Class4] [Implementierung_ProjectKB_Class5] [Implementierung_ProjectKB_Class6])) ([CLSES_TAB] of Widget (is_hidden FALSE) (widget_class_name "edu.stanford.smi.protege.widget.ClsesTab")) ([CREATION_TIMESTAMP_WIDGET] of Widget (name ":CREATION-TIMESTAMP")) ([CREATOR_WIDGET] of Widget (name ":CREATOR")) ([FORMS_TAB] of Widget (is_hidden FALSE) (widget_class_name "edu.stanford.smi.protege.widget.FormsTab")) ([Implementierung_ProjectKB_Class151] of String (name "SearchTab_Query"))

321

322

Formalsprachliche Darstellungen

([Implementierung_ProjectKB_Class4] of String (name ":INSTANCE-ANNOTATION") (string_value "%3AANNOTATION-TEXT")) ([Implementierung_ProjectKB_Class5] of String (name ":META-CLASS") (string_value "%3ANAME")) ([Implementierung_ProjectKB_Class6] of String (name ":PAL-CONSTRAINT") (string_value "%3APAL-NAME")) ([Implementierung_ProjectKB_Class7] of Map_Entry (key "suppress_instance_counting") (key_class "java.lang.String") (value "false") (value_class "java.lang.String")) ([Implementierung_ProjectKB_Class8] of Map_Entry (key "change_tracking_active") (key_class "java.lang.String") (value "false") (value_class "java.lang.String")) ([Implementierung_ProjectKB_Class9] of Map_Entry (key "add_name_on_instance_form") (key_class "java.lang.String") (value "false") (value_class "java.lang.String")) ([INSTANCE_ANNOTATION_FORM_WIDGET] of Widget (height 476) (is_hidden FALSE) (name ":INSTANCE-ANNOTATION") (property_list [INSTANCE_ANNOTATION_PROPERTY_LIST]) (widget_class_name "edu.stanford.smi.protege.widget.FormWidget") (width 603) (x 0) (y 0)) ([INSTANCE_ANNOTATION_PROPERTY_LIST] of Property_List (properties [ANNOTATED_INSTANCE_WIDGET] [CREATOR_WIDGET]

Formalsprachliche Darstellungen [CREATION_TIMESTAMP_WIDGET] [ANNOTATION_TEXT_WIDGET])) ([INSTANCES_TAB] of Widget (is_hidden FALSE) (widget_class_name "edu.stanford.smi.protege.widget.InstancesTab")) ([KB_698196_Class3] of Map ) ([KB_772086_Class0] of String (name "factory_class_name") (string_value "edu.stanford.smi.protege.storage.clips.ClipsKnowledgeBaseFactory")) ([KB_772086_Class1] of Map (entries [Implementierung_ProjectKB_Class7] [Implementierung_ProjectKB_Class8] [Implementierung_ProjectKB_Class9])) ([KB_772086_Class10] of Property_List ) ([KB_772086_Class100] of Property_List ) ([KB_772086_Class101] of Property_List ) ([KB_772086_Class102] of Property_List ) ([KB_772086_Class103] of Property_List ) ([KB_772086_Class104] of Property_List ) ([KB_772086_Class105] of Property_List ) ([KB_772086_Class106] of Property_List ) ([KB_772086_Class107] of Property_List ) ([KB_772086_Class108] of Property_List )

323

324

Formalsprachliche Darstellungen

([KB_772086_Class109] of Property_List ) ([KB_772086_Class11] of Widget (is_hidden TRUE) (property_list [KB_772086_Class12]) (widget_class_name "edu.stanford.smi.protegex.owl.ui.metadatatab.OWLMetadataTab")) ([KB_772086_Class110] of Property_List (properties [Implementierung_ProjectKB_Class151])) ([KB_772086_Class12] of Property_List ) ([KB_772086_Class13] of Widget (is_hidden TRUE) (property_list [KB_772086_Class14]) (widget_class_name "org.protege.owl.mm.ssm.ui.MappingMasterTab")) ([KB_772086_Class14] of Property_List ) ([KB_772086_Class149] of String (name "classes_file_name") (string_value "Implementierung.pont")) ([KB_772086_Class15] of Widget (is_hidden TRUE) (property_list [KB_772086_Class16]) (widget_class_name "edu.stanford.smi.protegex.owl.swrl.ui.tab.SWRLTab")) ([KB_772086_Class150] of String (name "instances_file_name") (string_value "Implementierung.pins")) ([KB_772086_Class16] of Property_List ) ([KB_772086_Class17] of Widget (is_hidden TRUE) (property_list [KB_772086_Class18]) (widget_class_name "edu.stanford.smi.protegex.fctab.FacetConstraintsTab")) ([KB_772086_Class18] of Property_List )

Formalsprachliche Darstellungen ([KB_772086_Class19] of Widget (is_hidden TRUE) (property_list [KB_772086_Class20]) (widget_class_name "edu.stanford.smi.protegex.xml.tab.XMLTab")) ([KB_772086_Class20] of Property_List ) ([KB_772086_Class21] of Widget (is_hidden FALSE) (property_list [KB_772086_Class22]) (widget_class_name "de.dfki.mycbr.modelprovider.protege.similaritymodeling.MyCbr_Similarities_Tab")) ([KB_772086_Class22] of Property_List ) ([KB_772086_Class23] of Widget (is_hidden TRUE) (property_list [KB_772086_Class24]) (widget_class_name "edu.stanford.smi.protege.widget.KAToolTab")) ([KB_772086_Class24] of Property_List ) ([KB_772086_Class25] of Widget (is_hidden TRUE) (property_list [KB_772086_Class26]) (widget_class_name "edu.stanford.smi.protege.widget.ProtegePropertiesTab")) ([KB_772086_Class26] of Property_List ) ([KB_772086_Class27] of Widget (is_hidden TRUE) (property_list [KB_772086_Class28]) (widget_class_name "edu.stanford.smi.protege.widget.instance_tree.KnowledgeTreeTab")) ([KB_772086_Class28] of Property_List ) ([KB_772086_Class29] of Widget (is_hidden TRUE) (property_list [KB_772086_Class30]) (widget_class_name "edu.stanford.smi.protege.query.LuceneQueryPlugin")) ([KB_772086_Class3] of Widget

325

326

Formalsprachliche Darstellungen

(is_hidden TRUE) (property_list [KB_772086_Class4]) (widget_class_name "TGViztab.TGVizTab")) ([KB_772086_Class30] of Property_List ) ([KB_772086_Class31] of Widget (is_hidden TRUE) (property_list [KB_772086_Class32]) (widget_class_name "edu.stanford.smi.protegex.datamaster.DataMasterTab")) ([KB_772086_Class32] of Property_List ) ([KB_772086_Class33] of Widget (is_hidden TRUE) (property_list [KB_772086_Class34]) (widget_class_name "uk.ac.man.cs.mig.coode.debugger.test.DebuggerTestTab")) ([KB_772086_Class34] of Property_List ) ([KB_772086_Class35] of Widget (is_hidden TRUE) (property_list [KB_772086_Class36]) (widget_class_name "edu.stanford.smi.protegex.owl.ui.cls.OWLClassesTab")) ([KB_772086_Class36] of Property_List ) ([KB_772086_Class37] of Widget (is_hidden TRUE) (property_list [KB_772086_Class38]) (widget_class_name "org.algernon.kb.okbc.protege.plugins.AlgernonTab")) ([KB_772086_Class38] of Property_List ) ([KB_772086_Class39] of Widget (is_hidden TRUE) (property_list [KB_772086_Class40]) (widget_class_name "edu.stanford.smi.protegex.widget.pal.PalQueriesTab")) ([KB_772086_Class4] of Property_List )

Formalsprachliche Darstellungen

327

([KB_772086_Class40] of Property_List ) ([KB_772086_Class41] of Widget (is_hidden TRUE) (property_list [KB_772086_Class42]) (widget_class_name "edu.stanford.smi.RemoteKBTab.UMLSTab")) ([KB_772086_Class42] of Property_List ) ([KB_772086_Class43] of Widget (is_hidden TRUE) (property_list [KB_772086_Class44]) (widget_class_name "edu.stanford.smi.protegex.server_changes.prompt.UsersTab")) ([KB_772086_Class44] of Property_List ) ([KB_772086_Class45] of Widget (is_hidden FALSE) (property_list [KB_772086_Class46]) (widget_class_name "de.dfki.mycbr.modelprovider.protege.retrieval.MyCbr_Retrieval_Tab")) ([KB_772086_Class46] of Property_List ) ([KB_772086_Class47] of Widget (is_hidden TRUE) (property_list [KB_772086_Class48]) (widget_class_name "de.dfki.mycbr.modelprovider.protege.explanation.MyCbr_Explanation_Tab")) ([KB_772086_Class48] of Property_List ) ([KB_772086_Class49] of Widget (is_hidden TRUE) (property_list [KB_772086_Class50]) (widget_class_name "uk.ac.man.ac.mig.coode.individuals.ui.OWLDLIndividualsTab")) ([KB_772086_Class5] of Widget (is_hidden TRUE) (property_list [KB_772086_Class6]) (widget_class_name "dfki.protege.ontoviz_tab.OntovizTab")) ([KB_772086_Class50] of Property_List )

328

Formalsprachliche Darstellungen

([KB_772086_Class51] of Widget (is_hidden TRUE) (property_list [KB_772086_Class52]) (widget_class_name "uk.ac.man.cs.mig.coode.owlviz.ui.OWLVizTab")) ([KB_772086_Class52] of Property_List ) ([KB_772086_Class53] of Widget (is_hidden TRUE) (property_list [KB_772086_Class54]) (widget_class_name "script.ProtegeScriptTab")) ([KB_772086_Class54] of Property_List ) ([KB_772086_Class55] of Widget (is_hidden TRUE) (property_list [KB_772086_Class56]) (widget_class_name "edu.stanford.smi.protegex.evaluation.MetaAnalysis")) ([KB_772086_Class56] of Property_List ) ([KB_772086_Class57] of Widget (is_hidden TRUE) (property_list [KB_772086_Class58]) (widget_class_name "edu.stanford.smi.protege.keywordsearch.StringSearch")) ([KB_772086_Class58] of Property_List ) ([KB_772086_Class59] of Widget (is_hidden TRUE) (property_list [KB_772086_Class60]) (widget_class_name "edu.stanford.smi.protegex.changes.ChangesTab")) ([KB_772086_Class6] of Property_List ) ([KB_772086_Class60] of Property_List ) ([KB_772086_Class61] of Widget (is_hidden TRUE) (property_list [KB_772086_Class62])

Formalsprachliche Darstellungen (widget_class_name "edu.stanford.smi.protegex.owl.ui.widget.OWLFormsTab")) ([KB_772086_Class62] of Property_List ) ([KB_772086_Class63] of Widget (is_hidden TRUE) (property_list [KB_772086_Class64]) (widget_class_name "ezpal.EZPalTab")) ([KB_772086_Class64] of Property_List ) ([KB_772086_Class65] of Widget (is_hidden TRUE) (property_list [KB_772086_Class66]) (widget_class_name "edu.stanford.smi.protegex.changes.changesKBViewTab.ChangesKBViewTab")) ([KB_772086_Class66] of Property_List ) ([KB_772086_Class67] of Widget (is_hidden TRUE) (property_list [KB_772086_Class68]) (widget_class_name "edu.stanford.smi.protegex.prompt.PromptTab")) ([KB_772086_Class68] of Property_List ) ([KB_772086_Class69] of Widget (is_hidden TRUE) (property_list [KB_772086_Class70]) (widget_class_name "edu.stanford.smi.protegex.owl.ui.properties.OWLPropertiesTab")) ([KB_772086_Class7] of Widget (is_hidden TRUE) (property_list [KB_772086_Class8]) (widget_class_name "edu.stanford.smi.protege.widget.ClsesAndInstancesTab")) ([KB_772086_Class70] of Property_List ) ([KB_772086_Class71] of Widget (is_hidden TRUE) (property_list [KB_772086_Class72]) (widget_class_name "edu.stanford.smi.protegex.widget.pal.PalConstraintsTab"))

329

330

Formalsprachliche Darstellungen

([KB_772086_Class72] of Property_List ) ([KB_772086_Class73] of Widget (is_hidden TRUE) (property_list [KB_772086_Class74]) (widget_class_name "edu.stanford.smi.protege.widget.instance_tree.InstanceTreeTab")) ([KB_772086_Class74] of Property_List ) ([KB_772086_Class75] of Widget (is_hidden TRUE) (property_list [KB_772086_Class76]) (widget_class_name "edu.stanford.smi.protegex.changes.stats.ChangeStatisticsTab")) ([KB_772086_Class76] of Property_List ) ([KB_772086_Class77] of Widget (is_hidden TRUE) (property_list [KB_772086_Class78]) (widget_class_name "se.liu.ida.JessTab.JessTab")) ([KB_772086_Class78] of Property_List ) ([KB_772086_Class79] of Widget (is_hidden TRUE) (property_list [KB_772086_Class80]) (widget_class_name "ca.uvic.csr.shrimp.jambalaya.JambalayaTab")) ([KB_772086_Class8] of Property_List ) ([KB_772086_Class80] of Property_List ) ([KB_772086_Class81] of Widget (is_hidden TRUE) (property_list [KB_772086_Class82]) (widget_class_name "edu.stanford.smi.protegex.changeanalysis.ChangeAnalysisTab")) ([KB_772086_Class82] of Property_List ) ([KB_772086_Class83] of Widget

Formalsprachliche Darstellungen

(is_hidden TRUE) (property_list [KB_772086_Class84]) (widget_class_name "edu.stanford.smi.protegex.owl.ui.individuals.OWLIndividualsTab")) ([KB_772086_Class84] of Property_List ) ([KB_772086_Class85] of Widget (is_hidden TRUE) (property_list [KB_772086_Class86]) (widget_class_name "org.protege.owl.axiome.ui.AxiomeTab")) ([KB_772086_Class86] of Property_List ) ([KB_772086_Class87] of Widget (is_hidden TRUE) (property_list [KB_772086_Class88]) (widget_class_name "edu.stanford.smi.protegex.chatPlugin.ChatTab")) ([KB_772086_Class88] of Property_List ) ([KB_772086_Class89] of Property_List (properties [KB_772086_Class90] [KB_772086_Class91])) ([KB_772086_Class9] of Widget (is_hidden TRUE) (property_list [KB_772086_Class10]) (widget_class_name "edu.stanford.smi.RemoteKBTab.WordNetTab")) ([KB_772086_Class90] of Boolean (boolean_value FALSE) (name "ButtonDisplayed-View References to Value")) ([KB_772086_Class91] of Boolean (boolean_value FALSE) (name "ButtonDisplayed-Delete Instance")) ([KB_772086_Class92] of Property_List ) ([KB_772086_Class93] of Property_List )

331

332

Formalsprachliche Darstellungen

([KB_772086_Class94] of Property_List (properties [KB_772086_Class95] [KB_772086_Class96])) ([KB_772086_Class95] of Boolean (boolean_value FALSE) (name "ButtonDisplayed-Move up")) ([KB_772086_Class96] of Boolean (boolean_value FALSE) (name "ButtonDisplayed-Move down")) ([KB_772086_Class97] of Property_List ) ([KB_772086_Class98] of Property_List (name "layout properties")) ([KB_772086_Class99] of Property_List ) ([LAYOUT_PROPERTIES] of Property_List (name "layout properties") (properties [VERTICAL_STRETCHER])) ([option_instance] of Options (confirm_on_remove FALSE) (display_abstract_class_icon TRUE) (display_hidden_classes TRUE) (display_multi_parent_class_icon TRUE) (is_readonly FALSE) (tabbed_instance_form_layout FALSE) (undo_enabled TRUE) (update_modification_slots FALSE)) ([PAL_DESCRIPTION_WIDGET] of Widget (height 180) (is_hidden FALSE) (label "Description") (name ":PAL-DESCRIPTION") (widget_class_name "edu.stanford.smi.protege.widget.TextAreaWidget") (width 250) (x 275) (y 0))

Formalsprachliche Darstellungen

([PAL_FORM_WIDGET] of Widget (height 476) (is_hidden FALSE) (name ":PAL-CONSTRAINT") (property_list [PAL_PROPERTY_LIST]) (widget_class_name "edu.stanford.smi.protege.widget.FormWidget") (width 603) (x 0) (y 0)) ([PAL_NAME_WIDGET] of Widget (height 60) (is_hidden FALSE) (label "Name") (name ":PAL-NAME") (widget_class_name "edu.stanford.smi.protege.widget.TextFieldWidget") (width 275) (x 0) (y 0)) ([PAL_PROPERTY_LIST] of Property_List (properties [PAL_NAME_WIDGET] [PAL_RANGE_WIDGET] [PAL_DESCRIPTION_WIDGET] [PAL_STATEMENT_WIDGET])) ([PAL_RANGE_WIDGET] of Widget (height 180) (is_hidden FALSE) (label "Range") (name ":PAL-RANGE") (widget_class_name "edu.stanford.smi.protegex.widget.pal.constraint.PalRangeWidget") (width 250) (x 275) (y 180)) ([PAL_STATEMENT_WIDGET] of Widget (height 300) (is_hidden FALSE) (label "Statement") (name ":PAL-STATEMENT") (widget_class_name "edu.stanford.smi.protegex.widget.pal.constraint.PalConstraintWidget") (width 275) (x 0) (y 60))

333

334

Formalsprachliche Darstellungen

([PROJECT] of Project (browser_slot_names [BROWSER_SLOT_NAMES]) (customized_instance_widgets [INSTANCE_ANNOTATION_FORM_WIDGET] [STANDARD_FACET_FORM_WIDGET] [STANDARD_SLOT_FORM_WIDGET] [STANDARD_CLASS_FORM_WIDGET] [PAL_FORM_WIDGET]) (default_cls_metaclass ":STANDARD-CLASS") (default_facet_metaclass ":STANDARD-FACET") (default_instance_widget_class_name "edu.stanford.smi.protege.widget.FormWidget") (default_slot_metaclass ":STANDARD-SLOT") (journaling_enabled FALSE) (next_frame_number 0) (options [option_instance]) (property_map [KB_772086_Class1]) (sources [SOURCES]) (tabs [CLSES_TAB] [SLOTS_TAB] [FORMS_TAB] [INSTANCES_TAB] [QUERIES_TAB] [KB_772086_Class37] [KB_772086_Class81] [KB_772086_Class59] [KB_772086_Class7] [KB_772086_Class31] [KB_772086_Class33] [KB_772086_Class17] [KB_772086_Class73] [KB_772086_Class79] [KB_772086_Class77] [KB_772086_Class23] [KB_772086_Class27] [KB_772086_Class29] [KB_772086_Class55] [KB_772086_Class47] [KB_772086_Class45] [KB_772086_Class21] [KB_772086_Class5] [KB_772086_Class49] [KB_772086_Class61] [KB_772086_Class71] [KB_772086_Class67] [KB_772086_Class25] [KB_772086_Class53] [KB_772086_Class57] [KB_772086_Class3] [KB_772086_Class41] [KB_772086_Class19] [KB_772086_Class85]

Formalsprachliche Darstellungen [KB_772086_Class65] [KB_772086_Class75] [KB_772086_Class87] [KB_772086_Class63] [KB_772086_Class13] [KB_772086_Class35] [KB_772086_Class83] [KB_772086_Class11] [KB_772086_Class69] [KB_772086_Class51] [KB_772086_Class39] [KB_772086_Class15] [KB_772086_Class43] [KB_772086_Class9])) ([QUERIES_TAB] of Widget (is_hidden FALSE) (property_list [KB_772086_Class110]) (widget_class_name "edu.stanford.smi.protegex.queries_tab.QueriesTab")) ([SLOTS_TAB] of Widget (is_hidden FALSE) (widget_class_name "edu.stanford.smi.protege.widget.SlotsTab")) ([SOURCES] of Property_List (properties [KB_772086_Class0] [KB_772086_Class149] [KB_772086_Class150])) ([STANDARD_CLASS_CONSTRAINTS_WIDGET] of Widget (height 120) (label "Constraints") (name ":SLOT-CONSTRAINTS") (property_list [KB_772086_Class89]) (widget_class_name "edu.stanford.smi.protege.widget.ConstraintsWidget") (width 200) (x 400) (y 0)) ([STANDARD_CLASS_DIRECT_INSTANCES_WIDGET] of Widget (name ":DIRECT-INSTANCES")) ([STANDARD_CLASS_DIRECT_SUBCLASSES_WIDGET] of Widget (name ":DIRECT-SUBCLASSES")) ([STANDARD_CLASS_DIRECT_SUPERCLASSES_WIDGET] of Widget

335

336

Formalsprachliche Darstellungen

(name ":DIRECT-SUPERCLASSES")) ([STANDARD_CLASS_DIRECT_TYPE_WIDGET] of Widget (name ":DIRECT-TYPE")) ([STANDARD_CLASS_DOCUMENTATION_WIDGET] of Widget (height 120) (label "Documentation") (name ":DOCUMENTATION") (property_list [KB_772086_Class92]) (widget_class_name "edu.stanford.smi.protege.widget.DocumentationWidget") (width 200) (x 200) (y 0)) ([STANDARD_CLASS_FORM_WIDGET] of Widget (name ":STANDARD-CLASS") (property_list [STANDARD_CLASS_WIDGETS]) (widget_class_name "edu.stanford.smi.protege.widget.FormWidget")) ([STANDARD_CLASS_NAME_WIDGET] of Widget (height 60) (label "Name") (name ":NAME") (property_list [KB_772086_Class93]) (widget_class_name "edu.stanford.smi.protege.widget.InstanceNameWidget") (width 200) (x 0) (y 0)) ([STANDARD_CLASS_ROLE_WIDGET] of Widget (height 60) (label "Role") (name ":ROLE") (property_list [KB_772086_Class97]) (widget_class_name "edu.stanford.smi.protege.widget.RoleWidget") (width 200) (x 0) (y 60)) ([STANDARD_CLASS_TEMPLATE_SLOTS_WIDGET] of Widget (height 150) (label "Template Slots") (name ":DIRECT-TEMPLATE-SLOTS") (property_list [KB_772086_Class94]) (widget_class_name "edu.stanford.smi.protege.widget.TemplateSlotsWidget")

Formalsprachliche Darstellungen (width 600) (x 0) (y 120)) ([STANDARD_CLASS_WIDGETS] of Property_List (name "class widget properties") (properties [STANDARD_CLASS_CONSTRAINTS_WIDGET] [STANDARD_CLASS_DIRECT_INSTANCES_WIDGET] [STANDARD_CLASS_DIRECT_SUBCLASSES_WIDGET] [STANDARD_CLASS_DIRECT_SUPERCLASSES_WIDGET] [STANDARD_CLASS_DOCUMENTATION_WIDGET] [STANDARD_CLASS_NAME_WIDGET] [STANDARD_CLASS_ROLE_WIDGET] [STANDARD_CLASS_DIRECT_TYPE_WIDGET] [STANDARD_CLASS_TEMPLATE_SLOTS_WIDGET] [LAYOUT_PROPERTIES])) ([STANDARD_FACET_ASSOCIATED_SLOT_WIDGET] of Widget (height 60) (label "Associated Slot") (name ":ASSOCIATED-SLOT") (widget_class_name "edu.stanford.smi.protege.widget.InstanceFieldWidget") (width 200) (x 0) (y 60)) ([STANDARD_FACET_DOCUMENTATION_WIDGET] of Widget (height 120) (label "Documentation") (name ":DOCUMENTATION") (widget_class_name "edu.stanford.smi.protege.widget.DocumentationWidget") (width 200) (x 200) (y 0)) ([STANDARD_FACET_FORM_WIDGET] of Widget (name ":STANDARD-FACET") (property_list [STANDARD_FACET_WIDGETS]) (widget_class_name "edu.stanford.smi.protege.widget.FormWidget")) ([STANDARD_FACET_NAME_WIDGET] of Widget (height 60) (label "Name") (name ":NAME") (widget_class_name "edu.stanford.smi.protege.widget.InstanceNameWidget") (width 200) (x 0)

337

338

Formalsprachliche Darstellungen (y 0))

([STANDARD_FACET_WIDGETS] of Property_List (name "facet widget properties") (properties [STANDARD_FACET_NAME_WIDGET] [STANDARD_FACET_DOCUMENTATION_WIDGET] [STANDARD_FACET_ASSOCIATED_SLOT_WIDGET])) ([STANDARD_SLOT_ASSOCIATED_FACET_WIDGET] of Widget (name ":ASSOCIATED-FACET")) ([STANDARD_SLOT_CONSTRAINTS_WIDGET] of Widget (name ":SLOT-CONSTRAINTS")) ([STANDARD_SLOT_DEFAULT_VALUE_WIDGET] of Widget (height 90) (label "Default") (name ":SLOT-DEFAULTS") (property_list [KB_772086_Class101]) (widget_class_name "edu.stanford.smi.protege.widget.DefaultValuesWidget") (width 200) (x 400) (y 90)) ([STANDARD_SLOT_DIRECT_DOMAIN_WIDGET] of Widget (height 95) (label "Domain") (name ":DIRECT-DOMAIN") (property_list [KB_772086_Class99]) (widget_class_name "edu.stanford.smi.protege.widget.DirectDomainWidget") (width 200) (x 400) (y 180)) ([STANDARD_SLOT_DIRECT_TYPE_WIDGET] of Widget (name ":DIRECT-TYPE")) ([STANDARD_SLOT_DOCUMENTATION_WIDGET] of Widget (height 120) (label "Documentation") (name ":DOCUMENTATION") (property_list [KB_772086_Class102]) (widget_class_name "edu.stanford.smi.protege.widget.DocumentationWidget") (width 200) (x 200)

Formalsprachliche Darstellungen (y 0)) ([STANDARD_SLOT_FORM_WIDGET] of Widget (name ":STANDARD-SLOT") (property_list [STANDARD_SLOT_WIDGETS]) (widget_class_name "edu.stanford.smi.protege.widget.FormWidget")) ([STANDARD_SLOT_INVERSE_WIDGET] of Widget (height 60) (label "Inverse Slot") (name ":SLOT-INVERSE") (property_list [KB_772086_Class108]) (widget_class_name "edu.stanford.smi.protege.widget.InverseSlotWidget") (width 200) (x 200) (y 215)) ([STANDARD_SLOT_MAXIMUM_CARDINALITY_WIDGET] of Widget (height 35) (name ":SLOT-MAXIMUM-CARDINALITY") (property_list [KB_772086_Class107]) (widget_class_name "edu.stanford.smi.protege.widget.MaximumCardinalityWidget") (width 200) (x 200) (y 180)) ([STANDARD_SLOT_MAXIMUM_VALUE_WIDGET] of Widget (height 60) (label "Maximum") (name ":SLOT-NUMERIC-MAXIMUM") (property_list [KB_772086_Class103]) (widget_class_name "edu.stanford.smi.protege.widget.NumericMaximumWidget") (width 100) (x 100) (y 215)) ([STANDARD_SLOT_MINIMUM_CARDINALITY_WIDGET] of Widget (height 60) (label "Cardinality") (name ":SLOT-MINIMUM-CARDINALITY") (property_list [KB_772086_Class106]) (widget_class_name "edu.stanford.smi.protege.widget.MinimumCardinalityWidget") (width 200) (x 200) (y 120)) ([STANDARD_SLOT_MINIMUM_VALUE_WIDGET] of Widget

339

340

Formalsprachliche Darstellungen (height 60) (label "Minimum") (name ":SLOT-NUMERIC-MINIMUM") (property_list [KB_772086_Class104]) (widget_class_name "edu.stanford.smi.protege.widget.NumericMinimumWidget") (width 100) (x 0) (y 215))

([STANDARD_SLOT_NAME_WIDGET] of Widget (height 60) (label "Name") (name ":NAME") (property_list [KB_772086_Class105]) (widget_class_name "edu.stanford.smi.protege.widget.InstanceNameWidget") (width 200) (x 0) (y 0)) ([STANDARD_SLOT_SUBSLOTS_WIDGET] of Widget (name ":DIRECT-SUBSLOTS")) ([STANDARD_SLOT_SUPERSLOTS_WIDGET] of Widget (name ":DIRECT-SUPERSLOTS")) ([STANDARD_SLOT_TYPE_WIDGET] of Widget (height 155) (label "Value Type") (name ":SLOT-VALUE-TYPE") (property_list [KB_772086_Class109]) (widget_class_name "edu.stanford.smi.protege.widget.ValueTypeWidget") (width 200) (x 0) (y 60)) ([STANDARD_SLOT_VALUES_WIDGET] of Widget (height 90) (label "Template Values") (name ":SLOT-VALUES") (property_list [KB_772086_Class100]) (widget_class_name "edu.stanford.smi.protege.widget.SlotValuesWidget") (width 200) (x 400) (y 0)) ([STANDARD_SLOT_WIDGETS] of Property_List (name "slot widget properties")

Formalsprachliche Darstellungen

341

(properties [STANDARD_SLOT_MINIMUM_CARDINALITY_WIDGET] [STANDARD_SLOT_MAXIMUM_CARDINALITY_WIDGET] [STANDARD_SLOT_CONSTRAINTS_WIDGET] [STANDARD_SLOT_DIRECT_TYPE_WIDGET] [STANDARD_SLOT_DIRECT_DOMAIN_WIDGET] [STANDARD_SLOT_VALUES_WIDGET] [STANDARD_SLOT_SUPERSLOTS_WIDGET] [STANDARD_SLOT_SUBSLOTS_WIDGET] [STANDARD_SLOT_DEFAULT_VALUE_WIDGET] [STANDARD_SLOT_DOCUMENTATION_WIDGET] [STANDARD_SLOT_MAXIMUM_VALUE_WIDGET] [STANDARD_SLOT_MINIMUM_VALUE_WIDGET] [STANDARD_SLOT_ASSOCIATED_FACET_WIDGET] [STANDARD_SLOT_NAME_WIDGET] [STANDARD_SLOT_INVERSE_WIDGET] [STANDARD_SLOT_TYPE_WIDGET] [KB_772086_Class98])) ([VERTICAL_STRETCHER] of String (name "vertical_stretcher") (string_value ":DIRECT-TEMPLATE-SLOTS"))

Anhang 3.5: Fallbasis im MyCBR-Format Diese Datei beinhaltet die formalsprachliche Darstellung der Fallbasis, deren Fälle durch MyCBR importiert wurden. Implementierung_CBR_CASEBASE.XML: <slotvalue slot="Modell" value="Symbol" allowed_values="Samsung_X20;Dell_Optiplex;VMWare_ESX;Samsung_X50;IBM_iSeries;Dell_PowerEdge; physikalisches_System;virtuelles_System;Samsung_Notebook;Dell_System" /> <slotvalue slot="Typ" value="Symbol" allowed_values="Desktop;Notebook;Tower;Virtuell;Rack" /> <slotvalue slot="Modell" value="Samsung_X20" /> <slotvalue slot="Typ" value="Notebook" /> <slotvalue slot="Modell" value="VMWare_ESX" /> <slotvalue slot="Typ" value="Virtuell" /> <slotvalue slot="Modell" value="Samsung_X50" /> <slotvalue slot="Typ" value="Notebook" />

342

Formalsprachliche Darstellungen

<slotvalue slot="Modell" value="Dell_Optiplex" /> <slotvalue slot="Typ" value="Desktop" /> <slotvalue slot="Betriebssystemname" value="Symbol" allowed_values="Integrity_Linux;Microsoft_Windows_Vista;Red_Hat_Linux_9;Suse_Linux_10;AiX_4.3.3;M icrosoft_Windows_XP;Sun_Solaris_10;Unix;Linux;Microsoft_Windows" /> <slotvalue slot="Familie" value="Symbol" allowed_values="Windows;Unix" /> <slotvalue slot="Betriebssystemname" value="AiX_4.3.3" /> <slotvalue slot="Familie" value="Unix" /> <slotvalue slot="Betriebssystemname" value="Integrity_Linux" /> <slotvalue slot="Familie" value="Unix" /> <slotvalue slot="Betriebssystemname" value="Microsoft_Windows_Vista" /> <slotvalue slot="Familie" value="Windows" /> <slotvalue slot="Betriebssystemname" value="Microsoft_Windows_XP" /> <slotvalue slot="Familie" value="Windows" /> <slotvalue slot="Betriebssystemname" value="Red_Hat_Linux_9" /> <slotvalue slot="Familie" value="Unix" /> <slotvalue slot="Betriebssystemname" value="Sun_Solaris_10" /> <slotvalue slot="Familie" value="Unix" /> <slotvalue slot="Betriebssystemname" value="Suse_Linux_10" /> <slotvalue slot="Familie" value="Unix" /> <slotvalue slot="Modell" value="Symbol" allowed_values="Samsung_X20;Dell_Optiplex;VMWare_ESX;Samsung_X50;IBM_iSeries;Dell_PowerEdge; physikalisches_System;virtuelles_System;Samsung_Notebook;Dell_System" /> <slotvalue slot="Typ" value="Symbol" allowed_values="Desktop;Notebook;Tower;Virtuell;Rack" />

Formalsprachliche Darstellungen

343

<slotvalue slot="Anwendungsname" value="Symbol" allowed_values="Webapplikation;Vertriebsdatenbank;Börsensysteme;Sungard_Global_One;Check_Point_Fire wall;Internet_Explorer;Augeo;WSUS;Iptables" /> <slotvalue slot="Anwendungsbereich" value="Symbol" allowed_values="Handel;Internet;Netzwerk;Projekte" /> <slotvalue slot="Anwendungsname" value="Börsensysteme" /> <slotvalue slot="Anwendungsbereich" value="Handel" /> <slotvalue slot="Anwendungsname" value="Vertriebsdatenbank" /> <slotvalue slot="Anwendungsbereich" value="Handel" /> <slotvalue slot="Anwendungsname" value="Webapplikation" /> <slotvalue slot="Anwendungsbereich" value="Internet" /> <slotvalue slot="Anwendungsname" value="Symbol" allowed_values="Webapplikation;Vertriebsdatenbank;Börsensysteme;Sungard_Global_One;Check_Point_Fire wall;Internet_Explorer;Augeo;WSUS;Iptables" /> <slotvalue slot="Anwendungsbereich" value="Symbol" allowed_values="Handel;Internet;Netzwerk;Projekte" /> <slotvalue slot="Anwendungsname" value="Symbol" allowed_values="Webapplikation;Vertriebsdatenbank;Börsensysteme;Sungard_Global_One;Check_Point_Fire wall;Internet_Explorer;Augeo;WSUS;Iptables" /> <slotvalue slot="Anwendungsbereich" value="Symbol" allowed_values="Handel;Internet;Netzwerk;Projekte" /> <slotvalue slot="Anwendungsname" value="Augeo" /> <slotvalue slot="Anwendungsbereich" value="Projekte" /> <slotvalue slot="Anwendungsname" value="Check_Point_Firewall" /> <slotvalue slot="Anwendungsbereich" value="Netzwerk" /> <slotvalue slot="Anwendungsname" value="Internet_Explorer" /> <slotvalue slot="Anwendungsbereich" value="Internet" /> <slotvalue slot="Anwendungsname" value="Iptables" />

344

Formalsprachliche Darstellungen

<slotvalue slot="Anwendungsbereich" value="Netzwerk" /> <slotvalue slot="Anwendungsname" value="Sungard_Global_One" /> <slotvalue slot="Anwendungsbereich" value="Handel" /> <slotvalue slot="Anwendungsname" value="WSUS" /> <slotvalue slot="Anwendungsbereich" value="Netzwerk" /> <slotvalue slot="Modell" value="Symbol" allowed_values="Samsung_X20;Dell_Optiplex;VMWare_ESX;Samsung_X50;IBM_iSeries;Dell_PowerEdge; physikalisches_System;virtuelles_System;Samsung_Notebook;Dell_System" /> <slotvalue slot="Typ" value="Symbol" allowed_values="Desktop;Notebook;Tower;Virtuell;Rack" /> <slotvalue slot="Modell" value="IBM_iSeries" /> <slotvalue slot="Typ" value="Rack" /> <slotvalue slot="Modell" value="VMWare_ESX" /> <slotvalue slot="Typ" value="Virtuell" /> <slotvalue slot="Modell" value="Dell_PowerEdge" /> <slotvalue slot="Typ" value="Rack" /> <slotvalue slot="Modell" value="Dell_PowerEdge" /> <slotvalue slot="Typ" value="Tower" /> <slotvalue slot="Modell" value="VMWare_ESX" /> <slotvalue slot="Typ" value="Virtuell" /> <slotvalue slot="Modell" value="Dell_PowerEdge" /> <slotvalue slot="Typ" value="Rack" /> <slotvalue slot="Modell" value="Dell_PowerEdge" /> <slotvalue slot="Typ" value="Tower" /> <slotvalue slot="betrifftHardware" value="Instance" allowed_values="Hardware" />

Formalsprachliche Darstellungen

345

<slotvalue slot="betrifftAnwendung" value="Instance" allowed_values="Anwendung" /> <slotvalue slot="Euro" value="Integer" minval="10100" maxval="452000" /> <slotvalue slot="Projekttyp" value="Symbol" allowed_values="Konfiguration;Migration;Installation" /> <slotvalue slot="bestrifftBetriebssystem" value="Instance" allowed_values="Betriebssystem" /> <slotvalue slot="Personentage" value="Integer" minval="12" maxval="504" /> <slotvalue slot="betrifftHardware" value="Server_A2" /> <slotvalue slot="betrifftAnwendung" value="Iptables" /> <slotvalue slot="Euro" value="26000" /> <slotvalue slot="Projekttyp" value="Konfiguration" /> <slotvalue slot="bestrifftBetriebssystem" value="Red_Hat_Linux_9" /> <slotvalue slot="Personentage" value="30" /> <slotvalue slot="betrifftHardware" value="Client_6" /> <slotvalue slot="betrifftAnwendung" value="_undefined_" /> <slotvalue slot="Euro" value="382000" /> <slotvalue slot="Projekttyp" value="Installation" /> <slotvalue slot="bestrifftBetriebssystem" value="Microsoft_Windows_XP" /> <slotvalue slot="Personentage" value="504" /> <slotvalue slot="betrifftHardware" value="_undefined_" /> <slotvalue slot="betrifftAnwendung" value="WSUS" /> <slotvalue slot="Euro" value="420000" /> <slotvalue slot="Projekttyp" value="Installation" /> <slotvalue slot="bestrifftBetriebssystem" value="Microsoft_Windows_XP" /> <slotvalue slot="Personentage" value="300" /> <slotvalue slot="betrifftHardware" value="Server_3" /> <slotvalue slot="betrifftAnwendung" value="Check_Point_Firewall" /> <slotvalue slot="Euro" value="65000" /> <slotvalue slot="Projekttyp" value="Installation" /> <slotvalue slot="bestrifftBetriebssystem" value="Integrity_Linux" /> <slotvalue slot="Personentage" value="77" /> <slotvalue slot="betrifftHardware" value="Server_4" /> <slotvalue slot="betrifftAnwendung" value="Börsensysteme" /> <slotvalue slot="Euro" value="10100" /> <slotvalue slot="Projekttyp" value="Migration" /> <slotvalue slot="bestrifftBetriebssystem" value="Sun_Solaris_10" /> <slotvalue slot="Personentage" value="12" /> <slotvalue slot="betrifftHardware" value="Server_8" /> <slotvalue slot="betrifftAnwendung" value="Webapplikation" /> <slotvalue slot="Euro" value="290000" /> <slotvalue slot="Projekttyp" value="Installation" /> <slotvalue slot="bestrifftBetriebssystem" value="Suse_Linux_10" /> <slotvalue slot="Personentage" value="250" />

346

Formalsprachliche Darstellungen

<slotvalue slot="betrifftHardware" value="Client_9" /> <slotvalue slot="betrifftAnwendung" value="Augeo" /> <slotvalue slot="Euro" value="130000" /> <slotvalue slot="Projekttyp" value="Installation" /> <slotvalue slot="bestrifftBetriebssystem" value="Microsoft_Windows_XP" /> <slotvalue slot="Personentage" value="110" /> <slotvalue slot="betrifftHardware" value="Server_2" /> <slotvalue slot="betrifftAnwendung" value="Sungard_Global_One" /> <slotvalue slot="Euro" value="12200" /> <slotvalue slot="Projekttyp" value="Migration" /> <slotvalue slot="bestrifftBetriebssystem" value="AiX_4.3.3" /> <slotvalue slot="Personentage" value="16" /> <slotvalue slot="betrifftHardware" value="Server_7" /> <slotvalue slot="betrifftAnwendung" value="Vertriebsdatenbank" /> <slotvalue slot="Euro" value="34000" /> <slotvalue slot="Projekttyp" value="Konfiguration" /> <slotvalue slot="bestrifftBetriebssystem" value="Red_Hat_Linux_9" /> <slotvalue slot="Personentage" value="55" /> <slotvalue slot="betrifftHardware" value="Server_1" /> <slotvalue slot="betrifftAnwendung" value="_undefined_" /> <slotvalue slot="Euro" value="452000" /> <slotvalue slot="Projekttyp" value="Konfiguration" /> <slotvalue slot="bestrifftBetriebssystem" value="Red_Hat_Linux_9" /> <slotvalue slot="Personentage" value="320" /> <slotvalue slot="betrifftHardware" value="Client_10" /> <slotvalue slot="betrifftAnwendung" value="_undefined_" /> <slotvalue slot="Euro" value="25000" /> <slotvalue slot="Projekttyp" value="Konfiguration" /> <slotvalue slot="bestrifftBetriebssystem" value="Microsoft_Windows_Vista" /> <slotvalue slot="Personentage" value="28" /> <slotvalue slot="betrifftHardware" value="Client_5" /> <slotvalue slot="betrifftAnwendung" value="Internet_Explorer" /> <slotvalue slot="Euro" value="37500" /> <slotvalue slot="Projekttyp" value="Installation" /> <slotvalue slot="bestrifftBetriebssystem" value="Microsoft_Windows_XP" /> <slotvalue slot="Personentage" value="45" />

Formalsprachliche Darstellungen

347

Anhang 3.6: Erklärungen im MyCBR-Format Da die Definition von Erklärungen innerhalb von MyCBR optional ist und in dieser Arbeit nicht genutzt wird, enthält diese Datei die automatische Standardvorgabe von MyCBR. Implementierung_CBR_EXPLANATIONS.XML: <ExplanationScheme Description="" conceptID="String:THING" /> <ExplanationScheme Description="" conceptID="ModelClsProtege:System" /> <ExplanationScheme Description="" conceptID="DefaultCls:Cls(Hardware)" /> <ExplanationScheme Description="" conceptID="DefaultCls:Cls(Software)" /> <ExplanationScheme Description="" conceptID="ModelClsProtege:Hardware" /> <ExplanationScheme Description="" conceptID="ModelClsProtege:Client" /> <ExplanationScheme Description="" conceptID="ModelSlotProtege:Modell" /> <ExplanationScheme Description="" conceptID="String:Samsung_X20" /> <ExplanationScheme Description="" conceptID="String:Dell_Optiplex" /> <ExplanationScheme Description="" conceptID="String:VMWare_ESX" /> <ExplanationScheme Description="" conceptID="String:Samsung_X50" /> <ExplanationScheme Description="" conceptID="String:IBM_iSeries" /> <ExplanationScheme Description="" conceptID="String:Dell_PowerEdge" /> <ExplanationScheme Description="" conceptID="String:physikalisches_System" /> <ExplanationScheme Description="" conceptID="String:virtuelles_System" /> <ExplanationScheme Description="" conceptID="String:Samsung_Notebook" /> <ExplanationScheme Description="" conceptID="String:Dell_System" /> <ExplanationScheme Description="" conceptID="ModelSlotProtege:Typ" /> <ExplanationScheme Description="" conceptID="String:Desktop" /> <ExplanationScheme Description="" conceptID="String:Notebook" /> <ExplanationScheme Description="" conceptID="String:Tower" /> <ExplanationScheme Description="" conceptID="String:Virtuell" /> <ExplanationScheme Description="" conceptID="String:Rack" /> <ExplanationScheme Description="" conceptID="ModelClsProtege:Server" /> <ExplanationScheme Description="" conceptID="DefaultCls:Cls(Server)" /> <ExplanationScheme Description="" conceptID="DefaultCls:Cls(Client)" /> <ExplanationScheme Description="" conceptID="ModelClsProtege:Software" /> <ExplanationScheme Description="" conceptID="ModelClsProtege:Anwendung" /> <ExplanationScheme Description="" conceptID="ModelClsProtege:Individualanwendung" /> <ExplanationScheme Description="" conceptID="ModelSlotProtege:Anwendungsname" /> <ExplanationScheme Description="" conceptID="String:Webapplikation" /> <ExplanationScheme Description="" conceptID="String:Vertriebsdatenbank" /> <ExplanationScheme Description="" conceptID="String:Börsensysteme" /> <ExplanationScheme Description="" conceptID="String:Sungard_Global_One" /> <ExplanationScheme Description="" conceptID="String:Check_Point_Firewall" /> <ExplanationScheme Description="" conceptID="String:Internet_Explorer" /> <ExplanationScheme Description="" conceptID="String:Augeo" /> <ExplanationScheme Description="" conceptID="String:WSUS" /> <ExplanationScheme Description="" conceptID="String:Iptables" /> <ExplanationScheme Description="" conceptID="ModelSlotProtege:Anwendungsbereich" /> <ExplanationScheme Description="" conceptID="String:Handel" /> <ExplanationScheme Description="" conceptID="String:Internet" /> <ExplanationScheme Description="" conceptID="String:Netzwerk" /> <ExplanationScheme Description="" conceptID="String:Projekte" />

348

Formalsprachliche Darstellungen

<ExplanationScheme Description="" conceptID="DefaultCls:Cls(Standardanwendung)" /> <ExplanationScheme Description="" conceptID="DefaultCls:Cls(Individualanwendung)" /> <ExplanationScheme Description="" conceptID="ModelClsProtege:Standardanwendung" /> <ExplanationScheme Description="" conceptID="DefaultCls:Cls(Anwendung)" /> <ExplanationScheme Description="" conceptID="DefaultCls:Cls(Betriebssystem)" /> <ExplanationScheme Description="" conceptID="ModelClsProtege:Betriebssystem" /> <ExplanationScheme Description="" conceptID="ModelSlotProtege:Betriebssystemname" /> <ExplanationScheme Description="" conceptID="String:Integrity_Linux" /> <ExplanationScheme Description="" conceptID="String:Microsoft_Windows_Vista" /> <ExplanationScheme Description="" conceptID="String:Red_Hat_Linux_9" /> <ExplanationScheme Description="" conceptID="String:Suse_Linux_10" /> <ExplanationScheme Description="" conceptID="String:AiX_4.3.3" /> <ExplanationScheme Description="" conceptID="String:Microsoft_Windows_XP" /> <ExplanationScheme Description="" conceptID="String:Sun_Solaris_10" /> <ExplanationScheme Description="" conceptID="String:Unix" /> <ExplanationScheme Description="" conceptID="String:Linux" /> <ExplanationScheme Description="" conceptID="String:Microsoft_Windows" /> <ExplanationScheme Description="" conceptID="ModelSlotProtege:Familie" /> <ExplanationScheme Description="" conceptID="String:Windows" /> <ExplanationScheme Description="" conceptID="ModelClsProtege:Projekt" /> <ExplanationScheme Description="" conceptID="ModelSlotProtege:betrifftHardware" /> <ExplanationScheme Description="" conceptID="ModelSlotProtege:betrifftAnwendung" /> <ExplanationScheme Description="" conceptID="ModelSlotProtege:Euro" /> <ExplanationScheme Description="" conceptID="ModelSlotProtege:Projekttyp" /> <ExplanationScheme Description="" conceptID="String:Konfiguration" /> <ExplanationScheme Description="" conceptID="String:Migration" /> <ExplanationScheme Description="" conceptID="String:Installation" /> <ExplanationScheme Description="" conceptID="ModelSlotProtege:bestrifftBetriebssystem" /> <ExplanationScheme Description="" conceptID="ModelSlotProtege:Personentage" /> <SMExplanation model_instname="Anwendungsname" smfname="default" type="Symbol" /> <SMExplanation model_instname="Typ" smfname="default" type="Symbol" /> <SMExplanation model_instname="Familie" smfname="default" type="Symbol" /> <SMExplanation model_instname="Anwendungsbereich" smfname="default" type="Symbol" /> <SMExplanation model_instname="Projekttyp" smfname="default" type="Symbol" />

Anhang 3.7: Konfiguration zum Umgang mit unbekannten Attributswerten Durch die Konfiguration zum Umgang mit unbekannten Werten von Attributen und Relationen wird festgelegt, wie diese bei der Berechnung von Ähnlichkeitswerten berücksichtigt werden sollen. Implementierung_CBR_OPTIONS.XML:

Formalsprachliche Darstellungen

349

Anhang 3.8: Ähnlichkeitsmaßstäbe im MyCBR-Format Diese Datei beinhaltet die formalsprachliche Darstellung der lokalen und globalen Ähnlichkeitsmaßstäbe in MyCBR. Implementierung_CBR_SMF.XML: <SpecialValueHandler> <SpecialValue Label="undefined" /> <SMFunction smfname="default" model_instname="Personentage" type="Integer" maxval="504.0" minval="12.0" modeDiffOrQuotient="0" active="true" simMode="Standard"> <SMFunction smfname="default" model_instname="Betriebssystem" type="Class" amalgamation="weighted_sum" active="true" simMode="Standard"> <Slot slotname="Betriebssystemname" enabled="true" weight="1.0" comment="" /> <Slot slotname="Familie" enabled="true" weight="1.0" comment="" /> <SMFunction smfname="default" model_instname="Client" type="Class" amalgamation="weighted_sum" active="true" simMode="Standard"> <Slot slotname="Modell" enabled="true" weight="1.0" comment="" /> <Slot slotname="Typ" enabled="true" weight="1.0" comment="" /> <SMFunction smfname="default" model_instname="Hardware" type="Class" amalgamation="weighted_sum" active="true" simMode="Standard"> <Slot slotname="Modell" enabled="true" weight="1.0" comment="" /> <Slot slotname="Typ" enabled="true" weight="1.0" comment="" /> <SMFunction smfname="default" model_instname="Anwendungsname" type="Symbol" active="true" simMode="Table">

350

Formalsprachliche Darstellungen

<SMFunction smfname="default" model_instname="Euro" type="Integer" maxval="452000.0" minval="10100.0" modeDiffOrQuotient="0" active="true" simMode="Standard"> <SMFunction smfname="default" model_instname="Individualanwendung" type="Class" amalgamation="weighted_sum" active="true" simMode="Standard"> <Slot slotname="Anwendungsbereich" enabled="true" weight="1.0" comment="" /> <Slot slotname="Anwendungsname" enabled="true" weight="1.0" comment="" /> <SMFunction smfname="default" model_instname="System" type="Class" amalgamation="weighted_sum" active="true" simMode="Standard" />

Formalsprachliche Darstellungen

351

<SMFunction smfname="default" model_instname="Anwendung" type="Class" amalgamation="weighted_sum" active="true" simMode="Standard"> <Slot slotname="Anwendungsbereich" enabled="true" weight="1.0" comment="" /> <Slot slotname="Anwendungsname" enabled="true" weight="1.0" comment="" /> <SMFunction smfname="default" model_instname="Modell" type="Symbol" active="true" simMode="Taxonomy"> <SMFunction smfname="default" model_instname="Typ" type="Symbol" active="true" simMode="Table">

352

Formalsprachliche Darstellungen

<SMFunction smfname="default" model_instname="Betriebssystemname" type="Symbol" active="true" simMode="Taxonomy"> <SMFunction smfname="default" model_instname="Familie" type="Symbol" active="true" simMode="Table"> <SMFunction smfname="default" model_instname="Anwendungsbereich" type="Symbol" active="true" simMode="Table">

Formalsprachliche Darstellungen

353

<SMFunction smfname="default" model_instname="Standardanwendung" type="Class" amalgamation="weighted_sum" active="true" simMode="Standard"> <Slot slotname="Anwendungsbereich" enabled="true" weight="1.0" comment="" /> <Slot slotname="Anwendungsname" enabled="true" weight="1.0" comment="" /> <SMFunction smfname="default" model_instname="Software" type="Class" amalgamation="weighted_sum" active="true" simMode="Standard" /> <SMFunction smfname="default" model_instname="Server" type="Class" amalgamation="weighted_sum" active="true" simMode="Standard"> <Slot slotname="Modell" enabled="true" weight="1.0" comment="" /> <Slot slotname="Typ" enabled="true" weight="1.0" comment="" /> <SMFunction smfname="default" model_instname="Projekt" type="Class" amalgamation="weighted_sum" active="true" simMode="Standard"> <Slot slotname="Euro" enabled="true" weight="1.0" comment="" /> <Slot slotname="Personentage" enabled="true" weight="1.0" comment="" /> <Slot slotname="Projekttyp" enabled="true" weight="2.0" comment="" /> <Slot slotname="bestrifftBetriebssystem" enabled="true" weight="1.0" comment="" /> <Slot slotname="betrifftAnwendung" enabled="true" weight="1.0" comment="" /> <Slot slotname="betrifftHardware" enabled="true" weight="1.0" comment="" /> <SMFunction smfname="default" model_instname="Projekttyp" type="Symbol" active="true" simMode="Table">

354

Formalsprachliche Darstellungen