Intelligent Data Interchange (IDI): Interventionsfreier Geschaftsdatenaustausch durch Wissensreprasentation und ontologisches Matching

André Köhler Intelligent Data Interchange (IDI)

VIEWEG+TEUBNER RESEARCH Entwicklung und Management von Informationssystemen und intelligenter Datenauswertung Herausgeber: Prof. Dr. Paul Alpar, Philipps-Universität Marburg Prof. Dr. Ulrich Hasenkamp, Philipps-Universität Marburg

André Köhler

Intelligent Data Interchange (IDI) Interventionsfreier Geschäftsdatenaustausch durch Wissensrepräsentation und ontologisches Matching

Mit einem Geleitwort von Prof. Dr. Ulrich Hasenkamp

VIEWEG+TEUBNER 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 Philipps-Universität Marburg, 2009

1. Auflage 2010 Alle Rechte vorbehalten © Vieweg +Teubner Verlag | Springer Fachmedien Wiesbaden GmbH 2010 Lektorat: Ute Wrasmann | Britta Göhrisch-Radmacher Vieweg+Teubner Verlag ist Teil ist eine Marke von Springer Fachmedien. Springer Fachmedien ist Teil der Fachverlagsgruppe Springer Science+Business Media. www.viewegteubner.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 Druck und buchbinderische Verarbeitung: STRAUSS GMBH, Mörlenbach Gedruckt auf säurefreiem und chlorfrei gebleichtem Papier. Printed in Germany ISBN 978-3-8348-1292-6

Geleitwort Die Arbeit befasst sich mit dem Elektronischen Geschäftsdatenaustausch ("Electronic Data Interchange", EDI), einer Basistechnologie für Electronic Business und Supply-Chain-Management. Der Verfasser entwickelt eine Architektur für intelligenten Geschäftsdatenaustausch ("Intelligent Data Interchange", IDI), die einen interventionsfreien Austausch elektronischer Geschäftsdokumente ermöglicht. Unter dem Begriff "Interventionsfreiheit" versteht der Verfasser, dass Unternehmen vor der Aufnahme einer Kommunikationsbeziehung keine Vereinbarungen über Syntax, Semantik und Pragmatik der auszutauschenden Geschäftsdaten treffen müssen. So genannte IDI-Agenten sollen durch den Einsatz von Ontologien und semantischen Matchingverfahren in die Lage versetzt werden, Syntax-, Semantik- und Pragmatikeigenschaften einer empfangenen Nachricht eigenständig erkennen und die zur Steuerung des Nachrichtenflusses erforderlichen Protokolle vereinbaren zu können. Nachdem in den späten 1980er- und vor allem in den 1990er-Jahren auf dem Gebiet des Elektronischen Geschäftsdatenaustauschs viel Forschung betrieben wurde, ist die Forschungsintensität seitdem deutlich abgeklungen. Dies ist durch zwei Umstände zu erklären. Zum einen war durch die Einführung von UN/EDIFACT und die Entwicklung vieler Subsets dieses weltweiten Datenaustauschstandards ein deutlicher Fortschritt gegenüber den proprietären und bilateral vereinbarten Austauschformaten der Vorzeit erzielt worden, der weitere grundlegende Forschungsbemühungen entbehrlich zu machen schien. Das Gebiet galt als weitgehend ausgereizt. Es blieb zwar eine Unzufriedenheit mit der Existenz der vielen Subsets und des vergleichsweise großen Overheads in den EDIFACT-Formaten. Es fehlten aber offenbar zündende Ideen, um von der Forschung her weitere Fortschritte zu erzielen. Zum anderen führte die explosionsartige Ausbreitung von Electronic Business auf Basis des World Wide Web zu einer Konzentration des Interesses auf Datenaustauschmechanismen, die von dem Betreiber einer

VI

Geleitwort

Website vorgegeben werden, insofern also streng genommen keines Standards bedürfen. Dies ist für B2C-Anwendungen auch nicht problematisch, weil in der Regel Formulare vorgegeben werden, in die der Benutzer Daten geringen Umfangs händisch einträgt. In B2B- und B2GAnwendungen ist dieser Ansatz dagegen unökonomisch, weil die zu übertragenden Daten in der Regel in einem IT-Anwendungssystem vorliegen und automatisch übernommen werden könnten, wenn standardisierte Formate verwendet würden. Eine Brücke von den EDI-Formaten der Zeit vor dem Internet zum Einsatz des World Wide Web stellt das sogenannte Web-EDI dar, das aber lediglich eine Transformation der alten Ideen in eine neue Umgebung, eigentlich nur den Wechsel des Transportkanals, bedeutete. Neue Impulse für den Elektronischen Datenaustausch gingen davon nicht aus. Angesichts der allgemein erlahmten Forschungsbemühungen in einem immer wichtiger gewordenen und nach wie vor unbefriedigend beherrschten Gebiet hoher Praxisrelevanz ist die vorliegende Arbeit sehr zu begrüßen. Die vom Verfasser angestrebte Interventionsfreiheit beim Elektronischen Geschäftsdatenaustausch hat auch den Forschungsbemühungen der 1980er-Jahre schon zugrunde gelegen. Letztlich existieren aber beispielweise in EDIFACT und selbst in dessen branchenorientierten Subsets Freiheitsgrade, die nur durch Vereinbarungen außerhalb des eigentlichen operativen Datenaustauschs soweit reduziert werden können, dass automatische Übertragung zwischen Anwendungssystemen ohne menschlichen Eingriff möglich wird. Der Verfasser belegt dies durch grundlegende Ausführungen und gibt nachvollziehbare Beispiele. Die Kombination von formalen Notationen und gut formulierten, ohne weiteres nachvollziehbaren Erläuterungen ist charakteristisch für die gesamte Arbeit, die dadurch gut lesbar ist. Der Einsatz von Ontologien und semantischen Matchingverfahren erscheint als ein bahnbrechender Ansatz, um den elektronischen Datenaustausch über den aktuellen Stand hinaus weiterzubringen.

Ulrich Hasenkamp

Danksagung Bei meinem Doktorvater, Herrn Prof. Dr. Ulrich Hasenkamp, bedanke ich mich für die Betreuung der Arbeit sowie die Freiheit, die er mir bei der Gestaltung des Forschungsgebiets gelassen hat. Herrn Prof. Dr. Paul Alpar danke ich für die Übernahme des Zweitgutachtens, Frau Prof. Dr. Ingrid Göpfert für die Übernahme des Prüfungsausschuss-Vorsitzes. Den Mitarbeitern des Instituts für Wirtschaftsinformatik bin ich für die zahlreichen fachlichen Diskussionen und Anregungen zu Dank verpflichtet. Besonderen Dank schulde ich meiner Frau Heidrun. Sie hat meine Entscheidung, die Promotion neben der Berufstätigkeit zu betreiben, immer mitgetragen, mich in schwierigen Phasen motiviert und dafür gesorgt, dass auch nach der Geburt unserer drei Söhne noch Zeit zur Fertigstellung der Promotionsschrift vorhanden war. Ohne ihre Unterstützung hätte ich diese Arbeit nicht erfolgreich beenden können. Meinen Eltern möchte ich dafür danken, dass sie durch die Investition in mein Studium den Grundstein für diese Arbeit gelegt haben.

André Köhler

Inhaltsverzeichnis Abkürzungsverzeichnis ........................................................................... XVII Abbildungsverzeichnis .............................................................................. XIX Tabellenverzeichnis ................................................................................. XXIII Axiomenverzeichnis ................................................................................... XXV Verzeichnis der Mengendefinitionen ................................................... XXIX Verzeichnis der Konsistenzbedingungen ............................................. XXXI Formelverzeichnis ..................................................................................XXXIII 1

Einleitung ................................................................................................... 1

2

Von EDI zu IDI – ein Paradigmenwechsel .......................................... 5

2.1 Ausgangssituation und Problemstellung............................................... 5 2.1.1 EDI-Grundlagen .............................................................................. 5 2.1.2 Schwächen des klassischen EDI .................................................... 7 2.1.3 Sich wandelnde Anforderungen an den elektronischen Geschäftsdatenaustausch ............................................................... 9 2.2 Status quo des elektronischen Geschäftsdatenaustausches .............. 12 2.2.1 Electronic Business using XML (ebXML) .................................. 12 2.2.2 Ontologiebasierte Ansätze ........................................................... 14 2.3 Forschungsidee: Intelligent Data Interchange (IDI) ........................... 18 2.4 Einsatzmöglichkeiten für IDI-Agenten ................................................ 23 2.5 Notationshinweise ................................................................................... 27 3

Ontologiearchitektur und -sprache ..................................................... 31

3.1 Forschungsfragen und Kapitelaufbau .................................................. 31 3.2 Grundlagen der ontologischen Wissensrepräsentation ..................... 32 3.2.1 Wissen und Wissensrepräsentation – Begriffsklärung ............ 32 3.2.2 Ontologien als Wissensspeicher.................................................. 34

X

Inhaltsverzeichnis 3.2.2.1 Definitionen und Begriffsklärung ................................. 34 3.2.2.2 Modellierungsprimitiva ................................................. 37

3.3 Ontologiestruktur der IDI-Architektur ................................................ 40 3.3.1 Öffentliche vs. private Ontologien: Evaluation möglicher Architekturvarianten .................................................................... 40 3.3.2 Individuenkategorien ................................................................... 43 3.3.3 GBox ................................................................................................ 44 3.3.4 LBox ................................................................................................ 46 3.3.5 Zusammenfassende Bewertung .................................................. 48 3.4 IDI-Repräsentationssprache ................................................................... 50 3.4.1 Grundlagen logikbasierter Repräsentationssprachen ............. 50 3.4.1.1 Aussagenlogik.................................................................. 50 3.4.1.2 Prädikatenlogik................................................................ 53 3.4.2 Beschreibungslogik + '!&() als IDI-Repräsentationssprache ............................................................................................ 56 3.4.3 Konstruktoren ................................................................................ 62 3.4.3.1 3.4.3.2 3.4.3.3 3.4.3.4

Klassenkonstruktoren ..................................................... 62 Rollenkonstruktoren ....................................................... 64 Quantoren und Kardinalität .......................................... 66 Konkrete Domänen ......................................................... 69

3.4.4 Axiome ............................................................................................ 75 3.4.4.1 Klassenaxiome ................................................................. 75 3.4.4.2 Rollenaxiome.................................................................... 76 3.4.4.3 Individuenaxiome ........................................................... 79 4

Ontologieinhalte und -vokabular........................................................ 81

4.1 Forschungsfragen und Kapitelaufbau .................................................. 81 4.2 Geschäftsdatensyntax ............................................................................. 81 4.2.1 Syntaxwissen – ein informaler Überblick .................................. 82 4.2.2 Formatkategorien .......................................................................... 83 4.2.3 Strukturelementtypen .................................................................. 85 4.2.3.1 Mereologische Struktur .................................................. 85 4.2.3.2 Eigenschaften von Strukturelementen ......................... 90

Inhaltsverzeichnis

XI

4.2.4 Positionsbestimmung von Strukturelementen ......................... 92 4.2.4.1 Informale Spezifikation .................................................. 92 4.2.4.2 Formale Spezifikation ..................................................... 96 4.2.5 Optionalität von Bedeutungseinheiten ...................................... 99 4.2.6 Wiederholungen .......................................................................... 102 4.3 Geschäftsdatensemantik ....................................................................... 103 4.3.1 Semantikwissen – ein informaler Überblick ........................... 103 4.3.2 Ableitung der semantischen Spezifikationsmittel.................. 105 4.3.3 Semantische Spezifikationsmittel ............................................. 107 4.3.3.1 4.3.3.2 4.3.3.3 4.3.3.4

Konzeptklassennamen .................................................. 107 Taxonomische Beziehungen ........................................ 109 Mereologische Beziehungen ........................................ 111 Attributbeziehungen, Werttypen und Maßeinheiten ......................................................................... 113 4.3.3.5 Die Geschäftsdatenstruktur ......................................... 118 4.3.4 Codierung von Geschäftsinhalten ............................................ 119 4.3.5 Konzepte mit einer gemeinsamen semantischen Basis ........ 120 4.4 Geschäftsdatenpragmatik und Interaktionsprotokolle .................... 124 4.4.1 Geschäftsdatenpragmatik .......................................................... 124 4.4.1.1 Die Sprechakttheorie als Grundlage des Pragmatikvokabulars .................................................... 124 4.4.1.2 Ableitung der IDI-Illokutionen ................................... 127 4.4.2 Interaktionsprotokolle ................................................................ 132 4.4.2.1 Elemente und Aufgaben von Interaktionsprotokollen ................................................ 132 4.4.2.2 Agentenklassen .............................................................. 134 4.4.2.3 Sendevorgänge .............................................................. 135 4.4.2.4 Zeitliche und logische Abhängigkeiten ..................... 138 4.4.2.5 Grafische Darstellung von IDI-Protokollen............... 140 4.4.3 Metaprotokolle ............................................................................ 142 4.4.3.1 Aufgaben von Metaprotokollen .................................. 142 4.4.3.2 IDI-Ansatz ...................................................................... 145

XII

Inhaltsverzeichnis 4.4.3.3 Notwendige und hinreichende Bedingungen für Protokollkompatibilität ................................................ 147 4.4.3.4 Verschmelzungsregeln für gemeinsame Sendevorgänge und Protokolle ................................... 155

5

Ontologisches Matching ..................................................................... 161

5.1 Forschungsfragen und Kapitelaufbau ................................................ 161 5.2 Grundlagen des ontologischen Matchings ........................................ 162 5.2.1 Matching und Mapping – Begriffsklärung.............................. 162 5.2.2 Grundlegende Matchingansätze ............................................... 165 5.2.2.1 Kategorisierung von Matchingansätzen .................... 165 5.2.2.2 Schemabasiertes Matching ........................................... 168 5.2.2.3 Individuenbasiertes Matching ..................................... 171 5.3 IDI-Ansatz für das ontologische Matching ........................................ 173 5.3.1 Extensionale vs. intensionale Äquivalenz ............................... 173 5.3.2 Äquivalenzbedingungen und -indikatoren ............................ 175 5.3.3 Methodische Grundlagen .......................................................... 177 5.3.3.1 Dicekoeffizient ............................................................... 177 5.3.3.2 Wahrscheinlichkeitstheoretische Grundlagen und Bayestheorem ......................................................... 178 5.3.4 Primäre vs. sekundäre Äquivalenzindikatoren und Matchingprozess ......................................................................... 181 5.4 Reduktion des Suchraums durch Hypothesenfalsifikation ............ 184 5.4.1 Formale Definition der Hypothesenmengen H0 und H1 ....... 184 5.4.2 Notwendige Äquivalenzbedingungen .................................... 185 5.4.2.1 RA-Kompatibilität sowie Strukturelementtypenund GBox-Übereinstimmung ...................................... 185 5.4.2.2 Maßeinheiten- und Werttypen-Kompatibilität ......... 187 5.5 Äquivalenzindikatoren ......................................................................... 190 5.5.1 Bezeichnerkoeffizient ................................................................. 190 5.5.1.1 Vorüberlegungen........................................................... 190 5.5.1.2 Levensteinmaß ............................................................... 191 5.5.1.3 N-Gramatische Ähnlichkeit ......................................... 193

Inhaltsverzeichnis

XIII

5.5.1.4 Jaromaß ........................................................................... 195 5.5.1.5 Cosinusmaß .................................................................... 198 5.5.1.6 Bewertung der vorgestellten Koeffizienten ............... 200 5.5.2 5.5.3 5.5.4 5.5.5 5.5.6

Attributkoeffizient ...................................................................... 202 Taxonomiekoeffizient ................................................................. 203 Graphenbasierter Äquivalenzindikator ................................... 206 Mereologiekoeffizient ................................................................. 211 RA-Relevanz ................................................................................ 213

5.6 Äquivalenzkoeffizient ........................................................................... 215 5.6.1 Berechnungsmethode ................................................................. 215 5.6.2 Äquivalenz- und Inäquivalenzfunktion .................................. 223 5.7 Heterogenitätsüberwindung................................................................ 225 5.7.1 Heterogenitätsursachen und -effekte ....................................... 225 5.7.2 Heterogenitätsketten .................................................................. 228 5.7.3 Strategien zur Heterogenitätsüberwindung ........................... 233 5.7.3.1 Namensheterogenität.................................................... 234 5.7.3.2 Strukturkonflikte ........................................................... 238 5.7.3.3 Verschmelzungs- und Trennungskonflikte (VTKonflikte) ........................................................................ 241 5.7.3.4 Taxonomieheterogenität............................................... 244 5.7.3.5 Mereologieheterogenität .............................................. 250 5.7.3.6 Attributheterogenität .................................................... 253 5.7.3.7 Attribut-Zuordnungskonflikte .................................... 255 5.7.3.8 Granularitätskonflikte .................................................. 257 5.7.4 Geschäftsdatentransformation .................................................. 260 6

Anwendungsbeispiel ........................................................................... 263

6.1 Beschreibung des Anwendungsbeispiels ........................................... 263 6.2 LBox des Verladers ................................................................................ 264 6.2.1 EDIFACT-Beispielnachricht ...................................................... 264 6.2.1.1 Grundlagen EDIFACT .................................................. 264 6.2.1.2 Beispielnachricht ........................................................... 268 6.2.2 Interaktionsebene: Protokoll "Laderaumsuche" ..................... 270

XIV

Inhaltsverzeichnis 6.2.2.1 Informale Protokollspezifikation ................................ 270 6.2.2.2 Formale Protokollspezifikation ................................... 272 6.2.3 Syntaxebene ................................................................................. 275 6.2.3.1 Informale Darstellung der Repräsentationsinhalte ................................................. 275 6.2.3.2 Mereologische Struktur der Beispielnachricht .......... 275 6.2.3.3 Formale Darstellung der Repräsentationsinhalte ..... 278 6.2.4 Semantikebene ............................................................................. 287 6.2.4.1 6.2.4.2 6.2.4.3 6.2.4.4 6.2.4.5 6.2.4.6

Nachricht "Transportdienstleistung" .......................... 287 Bedeutungseinheit "Transportmittel" ......................... 289 Bedeutungseinheit "Ladedatum" ................................ 291 Bedeutungseinheit "Entladedatum" ........................... 293 Bedeutungseinheiten "Ladeort" und "Entladeort" .... 294 Bedeutungseinheit "Ladung" ....................................... 296

6.3 LBox des Fuhrunternehmers................................................................ 298 6.3.1 XML-Beispielnachricht ............................................................... 298 6.3.1.1 Grundlagen XML .......................................................... 298 6.3.1.2 Beispielnachricht ........................................................... 300 6.3.2 Interaktionsebene: Protokoll "Laderaumnachfrage" .............. 301 6.3.2.1 Informale Protokollspezifikation ................................ 301 6.3.2.2 Formale Protokollspezifikation ................................... 303 6.3.3 Syntaxebene ................................................................................. 304 6.3.3.1 Mereologische Struktur der Beispielnachricht .......... 304 6.3.3.2 Formale Spezifikation ................................................... 306 6.3.4 Semantikebene ............................................................................. 308 6.3.4.1 6.3.4.2 6.3.4.3 6.3.4.4

Nachricht "Transport" ................................................... 308 Bedeutungseinheit "Transportfahrzeug" ................... 311 Bedeutungseinheit "Verpackungseinheit" ................. 312 Bedeutungseinheiten "Ladungsgewicht" und "Stückzahl"...................................................................... 312 6.3.4.5 Bedeutungseinheiten "Verladedatum" und "Abladedatum" .............................................................. 314

Inhaltsverzeichnis

XV

6.3.4.6 Bedeutungseinheiten "Versandadresse" und "Empfangsadresse 1" ..................................................... 316 6.4 Matchingbeispiele .................................................................................. 318 6.4.1 Protokollmatching....................................................................... 318 6.4.2 Hypothesenfalsifikation auf der Semantikebene ................... 325 6.4.3 Ontologisches Matching: Berechnung der Äquivalenzindikatoren .............................................................. 329 6.4.3.1 6.4.3.2 6.4.3.3 6.4.3.4 6.4.3.5

Bezeichnerkoeffizient.................................................... 330 RA-Relevanz .................................................................. 331 Graphenbasierter Äquivalenzindikator ..................... 333 Taxonomiekoeffizient ................................................... 341 Mereologiekoeffizient ................................................... 345

6.4.4 Beispiele zur Heterogenitätsüberwindung ............................. 348 6.4.4.1 Bezeichnerheterogenität ............................................... 348 6.4.4.2 Mereologieheterogenität .............................................. 349 7

Zusammenfassung und Ausblick...................................................... 353

Anhang A: Literaturverzeichnis ................................................................. 357 Anhang B: Verzeichnis der IDI-Illokutionen ......................................... 383 Anhang C: Sachverzeichnis ........................................................................ 393

Abkürzungsverzeichnis ACL

Agent Communication Language

ANSI

American National Standards Institute

AUML

Agent-UML

DIN

Deutsches Institut für Normung

DL

Description Logics

DTD

Document Type Definition

ebXML

Electronic Business using XML

EDI

Electronic Data Interchange

EDIFACT

Electronic Data Interchange For Administration, Commerce and Transport

FIPA

Foundation for Intelligent Physical Agents

IBAN

International Bank Account Number

ISO

International Organization for Standardization

IDI

Intelligent Data Interchange

KQML

Knowledge Query and Manipulation Language

KI

Künstliche Intelligenz

ORL

OWL Rules Language

OWL

Web Ontology Language

OWL-DL

Web Ontology Language for Description Logics

OWL-S

Web Ontology Language for Web Services

RA

Reguläre Ausdrücke

RDF

Resource Description Framework

SF

Similarity Flooding

XVIII

Abkürzungsverzeichnis

SI-System

Système international d'unités

SOAP

Simple Object Access Protocol

SWIFT

Society for Worldwide Interbank Financial Telecommunication

TMWG

Techniques and Methodologies Working Group

UDDI

Universal Description, Discovery and Integration

UML

Unified Modelling Language

UN/CEFACT United Nations Centre for Trade Facilitation and Electronic Business VMI

Vendor Managed Inventory

VT-Konflikte Verschmelzungs- und Trennungskonflikte W3C

World Wide Web Consortium

WSMO

Web Service Modeling Ontology

WSDL

Web Service Description Language

WR

Wissensrepräsentation

XML

Extensible Markup Language

Abbildungsverzeichnis Abbildung 1: Abbildung 2: Abbildung 3: Abbildung 4: Abbildung 5: Abbildung 6: Abbildung 7: Abbildung 8: Abbildung 9: Abbildung 10: Abbildung 11: Abbildung 12: Abbildung 13: Abbildung 14: Abbildung 15: Abbildung 16: Abbildung 17: Abbildung 18: Abbildung 19: Abbildung 20: Abbildung 21: Abbildung 22: Abbildung 23: Abbildung 24: Abbildung 25:

Einfluss von Prozesseigenschaften auf den Einsatz von IDI- oder EDI-Technologie ........................................ 12 Gestaltungsebenen der IDI-Architektur.......................... 18 Architekturkomponenten .................................................. 22 Intension und Extension von Konzeptklassen ............... 38 IDI-Repräsentationsebenen ............................................... 42 Beispiel für eine Geschäftsdateneinheit mit ihrem Transportcontainer ............................................................. 44 Funktionen und Inhalte von GBox und LBox ................ 49 Formatkategorien ............................................................... 85 Mereologische Struktur der Strukturelementtypen ...... 88 Grafische Darstellung von Taxonomien ....................... 110 Grafische Darstellung von Mereologien ....................... 113 Attribut-, Maßeinheiten- und Werttypenbeziehungen ................................................... 117 Beispiel eines IDI-Interaktionsprotokolls...................... 142 Kompatibilitätsbedingungen bei Mischung absoluter und relativer Zeitbezüge ................................ 151 Kategorisierung von Matchingansätzen entsprechend den IDI-Inputkategorien ......................... 166 Abgewandelte Form des semiotischen Dreiecks ......... 173 Ableitung der Konzeptklassenäquivalenz .................... 175 Primäre und sekundäre Äquivalenzindikatoren ......... 182 Matchingprozess ............................................................... 183 Zwei Beispiele für die Berechnung des Jaromaßes...... 197 Beispielgraphen für "Similarity Flooding" .................... 207 Konnektivitäts- und Propagationsgraph ...................... 208 Kategorisierung von Heterogenitätsursachen ............. 226 Heterogenitätspyramide .................................................. 227 Formallogische Darstellung des Schließens in Heterogenitätsketten ........................................................ 230

XX Abbildung 26: Abbildung 27: Abbildung 28: Abbildung 29: Abbildung 30: Abbildung 31: Abbildung 32: Abbildung 33: Abbildung 34: Abbildung 35: Abbildung 36: Abbildung 37: Abbildung 38: Abbildung 39: Abbildung 40: Abbildung 41: Abbildung 42: Abbildung 43: Abbildung 44: Abbildung 45: Abbildung 46: Abbildung 47:

Abbildungsverzeichnis Überwindung von Namensheterogenität ..................... 238 Überwindung von Strukturkonflikten .......................... 240 Verschmelzungs- und Trennungskonflikte .................. 241 Fehlende taxonomische Beziehungen als Heterogenitätsursache ..................................................... 245 Diagnose und Überwindung fehlender taxonomischer Beziehungen ........................................... 247 Taxonomische Lücken als Ursachen taxonomischer Heterogenität..................................................................... 248 Fehlende mereologische Beziehungen als Heterogenitätsursachen ................................................... 251 Diagnose und Überwindung fehlender mereologischer Beziehungen .......................................... 253 Fehlende Attributbeziehung als Heterogenitätsursache ..................................................... 254 Diagnose und Überwindung fehlender Attributbeziehungen ........................................................ 255 Attribut-Zuordnungskonflikte ....................................... 256 Granularitätskonflikte als Heterogenitätsursachen..... 258 EDIFACT-Beispielnachricht "Laderaumgesuch" ......... 268 Protokoll "Laderaumsuche" aus der Senderperspektive ............................................................ 271 Mereologische Syntaxstruktur der EDIFACTNachricht............................................................................ 277 Mereologischer Kontext der Konzeptklasse "Transportdienstleistung"................................................ 288 Taxonomischer Kontext der Konzeptklasse "Transportdienstleistung"................................................ 288 Taxonomischer Kontext der Konzeptklasse "Transportmittel" .............................................................. 290 Taxonomischer Kontext der Konzeptklasse "Ladung" ............................................................................ 297 Taxonomischer Kontext der Konzeptklasse "Packmittel" ....................................................................... 298 Protokoll "Laderaumnachfrage" aus der Fuhrunternehmer-Perspektive ....................................... 302 Mereologische Syntaxstruktur der XML-Nachricht .... 306

Abbildungsverzeichnis

XXI

Abbildung 48: Mereologischer Kontext der Nachricht "Transport" .... 309 Abbildung 49: Taxonomischer Kontext der Nachricht "Transport" .... 310 Abbildung 50: Taxonomischer Kontext der Konzeptklasse "Transportfahrzeug" ......................................................... 311 Abbildung 51: Beispiel für die Kompatibilitätsbedingung "Gleichheit der inhaltlichen Bezüge" ............................. 320 Abbildung 52: Kandidaten für kompatible Sendevorgangspaare ....... 321 Abbildung 53: Konnektivitätsgraph für die Konzeptklassen "Transportfahrzeug" und "Transportmittel" ................. 334 Abbildung 54: Propagationsgraph für die Konzeptklassen "Transportfahrzeug" und "Transportmittel" ................. 335 Abbildung 55: Propagationsgraph für die Konzeptklassen "Transportfahrzeug" und "Ladung" ............................... 339 Abbildung 56: Ermittlung des Übereinstimmungsgrads des taxonomischen Kontextes im Fallbeispiel ..................... 343 Abbildung 57: Ermittlung des Übereinstimmungsgrads des mereologischen Kontextes im ersten MereologieAnwendungsbeispiel ....................................................... 346 Abbildung 58: Ermittlung des Übereinstimmungsgrades des mereologischen Kontextes im zweiten MereologieAnwendungsbeispiel ....................................................... 347 Abbildung 59: Mereologische Struktur der Konzeptklassen "Packmittel" und "Verpackungseinheit"........................ 352

Tabellenverzeichnis Tabelle 1: Tabelle 2: Tabelle 3: Tabelle 4:

Junktoren in der Aussagenlogik ....................................... 52 Interpretationen von Junktoren ........................................ 53 Beispiele für den Einsatz des Existenz- und Allquantors .......................................................................... 55 Konstruktoren von + '!&() ........................................ 58

Tabelle 5:

Axiomkategorien zur Spezifikation von Fakten in + '!&() ........................................................................... 59

Tabelle 6:

Informale Semantik von Rollen zur Positionsbestimmung ......................................................................... 95 Illokutionen der EDIFACT-Nachrichtentypen............. 129 Illokution "Assertive" ....................................................... 131 Konsistente Kombinationsmöglichkeiten logischer Rollen .................................................................................. 152 Beispiel für die Ableitung logischer Relationen zwischen verschmolzenen Sendevorgängen ................ 158 Ursprungsrollen und abgeleitete Rolle zweier gemeinsamer Sendevorgänge ......................................... 159 Kompatibilitätsmatrix zur Darstellung von Werttypenkompatibilität ................................................. 189 Erstellung von String-Vektoren ...................................... 199 Ähnlichkeitsmaße zur Berechnung des Übereinstimmungsgrades zweier Zeichenketten ........ 202 Graphenbasierter Äquivalenzindikator: eine beispielhafte Iterationstabelle ......................................... 211 Trainingsmenge zur Kalkulation des Äquivalenzkoeffizienten ................................................. 217 Matrix positiver Vorhersagewerte ................................. 220 Matrix negativer Vorhersagewerte ................................ 222 Überzeugungen eines IDI-Agenten hinsichtlich Konzeptklassenäquivalenz oder -inäquivalenz ........... 224

Tabelle 7: Tabelle 8: Tabelle 9: Tabelle 10: Tabelle 11: Tabelle 12: Tabelle 13: Tabelle 14: Tabelle 15: Tabelle 16: Tabelle 17: Tabelle 18: Tabelle 19:

XXIV Tabelle 20: Tabelle 21: Tabelle 22: Tabelle 23 : Tabelle 24: Tabelle 25: Tabelle 26: Tabelle 27: Tabelle 28: Tabelle 29: Tabelle 30: Tabelle 31:

Tabellenverzeichnis Definition von Koeffizienten- und Indikatorheterogenität ..................................................... 228 Heterogenitätsketten ........................................................ 232 Grafische Darstellung von Prozessen zur Heterogenitätsüberwindung........................................... 234 Formen der Synonymie ................................................... 237 EDIFACT Trennzeichen................................................... 267 Elemente des EDIFACT-Directories D.05B und ihre Darstellung im Internet ................................................... 268 Sender- und Empfängeragenten von Sendevorgängen ............................................................... 323 Hypothesenmenge H1 des Anwendungsbeispiels ...... 329 Ergebnisse des Bezeichnerkoeffizienten ....................... 331 Iterationstabelle zur beispielhaften Berechnung des graphenbasierten Äquivalenzindikators....................... 338 Iterationstabelle Beispiel 2 ............................................... 340 Heterogenitätsketten, die Mereologieheterogenität auslösen können ............................................................... 350

Axiomenverzeichnis Axiom 1: Axiom 2: Axiom 3: Axiom 4: Axiom 5: Axiom 6: Axiom 7: Axiom 8: Axiom 9: Axiom 10: Axiom 11: Axiom 12: Axiom 13: Axiom 14: Axiom 15: Axiom 16: Axiom 17: Axiom 18: Axiom 19: Axiom 20: Axiom 21: Axiom 22: Axiom 23: Axiom 24:

Konzeptklasse "SETyp" ...................................................... 88 Domänen- und Bildbereich der Rolle "hatSE" ................ 89 Klassendefinitionen der StrukturelementtypenKlassen ................................................................................. 90 Definitionen der Konzeptklassen zur eindeutigen Kennzeichnung von Strukturelementen ......................... 92 Definition der Strukturelementtypen .............................. 92 Domänen- und Bildbereich der Rolle "hatBE"................ 92 Konzeptklasse "SETyp" ...................................................... 97 Domänen- und Bildbereich der Rolle "endeGleichStart" ................................................................ 97 Domänen- und Bildbereich der Rollen "seGleichStart" und " seGleichEnde"................................ 99 Domänen- und Bildbereich der Rolle "optional" ......... 100 Domänen- und Bildbereich der Rolle "terminierbarDurch" ......................................................... 101 Domänen- und Bildbereich der Rolle "wdhDurch" ..... 102 Domänen- und Bildbereich der Rolle "hatBez" ............ 108 Domänen- und Bildbereich der Rolle "synVon" .......... 108 Domänen- und Bildbereich der Rolle "hatSynonym".................................................................... 109 Domänen- und Bildbereich der Rolle "hyperVon" ...... 110 Domänen- und Bildbereich der Rolle "hatKomp" ....... 112 Domänen- und Bildbereich der Rolle "attribut" ........... 115 Domänen- und Bildbereich der Rolle "werttyp" .......... 115 Konzeptklasse "Werttyp" ................................................. 115 Domänen- und Bildbereich der Rolle "hatMaßeinheit" ................................................................ 117 Domänen- und Bildbereich der Rolle "reg" .................. 119 Domänen- und Bildbereich der Rolle "hatKlartext" .... 120 Konzeptklasse "Datum" ................................................... 121

XXVI Axiom 25: Axiom 26: Axiom 27: Axiom 28: Axiom 29: Axiom 30: Axiom 31: Axiom 32: Axiom 33: Axiom 34: Axiom 35: Axiom 36: Axiom 37: Axiom 38: Axiom 39: Axiom 40: Axiom 41: Axiom 42: Axiom 43: Axiom 44: Axiom 45: Axiom 46: Axiom 47: Axiom 48: Axiom 49 Axiom 50:

Axiom 51: Axiom 52: Axiom 53: Axiom 54:

Axiomenverzeichnis Konzeptklassen "Tag", "Monat" und "Jahr" .................. 121 Konzeptklasse "Adresse" ................................................. 121 Konzeptklasse "Name"..................................................... 122 Konzeptklasse "Straße" .................................................... 122 Konzeptklasse "Hausnummer" ....................................... 123 Konzeptklasse "Stadt" ...................................................... 123 Konzeptklasse "PLZ" ........................................................ 123 Domänen- und Bildbereiche der Rollen "hatSender" und "hatEmpfänger"......................................................... 135 Komplementarität der Rollen "hatSender" und "hatEmpfänger" ................................................................. 135 Domänen- und Bildbereich der Rolle "hatSV" ............. 136 Domänen- und Bildbereich der Rolle "hatNach" ......... 136 Domänen- und Bildbereich der Rolle "hatIllo"............. 136 Konzeptklasse "Illokution" .............................................. 136 Ausweitung des Domänenbereichs der Rolle "optional" auf Sendevorgänge ........................................ 137 Domänen- und Bildbereich der Rolle "bezugZu" ........ 137 Domänen- und Bildbereich der Rolle "frühest"............ 138 Domänen- und Bildbereich der Rolle "vorher" ............ 139 Asymmetrie der Rolle "vorher" ...................................... 139 Domänen- und Bildbereich der Rolle "kompRA" ........ 186 Domänen- und Bildbereich der Rolle "kompSE" ......... 187 Domänen- und Bildbereich der Rolle "kompGB" ........ 187 Domänen- und Bildbereich der Rolle "kompME"........ 188 Domänen- und Bildbereich der Rolle "kompWT" ....... 189 Protokoll "Laderaumsuche" (VER-Ontologie) .............. 273 Sendevorgänge zur Protokollvereinbarung (VEROntologie) .......................................................................... 273 Buchungsanfrage des Verladers und Reaktionsmöglichkeit des Fuhrunternehmens (VEROntologie) .......................................................................... 274 Reaktionsmöglichkeit des Verladers auf das Transportangebot (VER-Ontologie) ............................... 274 Kopfteil 01 (VER-Ontologie) ........................................... 278 Datenfeld 01 (VER-Ontologie) ........................................ 279 Datenfeld 02 (VER-Ontologie) ........................................ 279

Axiomenverzeichnis Axiom 55: Axiom 56: Axiom 57: Axiom 58: Axiom 59: Axiom 60: Axiom 61: Axiom 62: Axiom 63: Axiom 64: Axiom 65: Axiom 66: Axiom 67: Axiom 68: Axiom 69: Axiom 70: Axiom 71: Axiom 72: Axiom 73: Axiom 74: Axiom 75: Axiom 76 Axiom 77: Axiom 78:

XXVII

Datenfelder 03 bis 05 (VER-Ontologie) ......................... 279 Datenfeld 06 (VER-Ontologie) ........................................ 280 Datenfeld 07 (VER-Ontologie) ........................................ 280 Datenfeldgruppe 02 mit Datenfeldern (VEROntologie) .......................................................................... 281 Datenfeldgruppe 03 mit zugehörigen Datenfeldern (VER-Ontologie) ............................................................... 282 Datenfeldgruppe 04 mit zugehörigen Datenfeldern (VER-Ontologie) ............................................................... 283 Datenfeldgruppe 05 mit zugehörigen Datenfeldern (VER-Ontologie) ............................................................... 284 Datenfeldgruppe 06 mit zugehörigen Datenfeldern (VER-Ontologie) ............................................................... 285 Datenfeldgruppe 07 mit zugehörigen Datenfeldern (VER-Ontologie) ............................................................... 286 Kopfteil 02 und zugeordnete Datenfelder (VEROntologie) .......................................................................... 286 Konzeptklasse "Transportdienstleistung" (VEROntologie) .......................................................................... 289 Konzeptklasse "Transportmittel" (VER-Ontologie) ..... 291 Konzeptklasse "Ladedatum" (VER-Ontologie) ............ 292 Konzeptklassen "Ladetag", "Lademonat", "Ladejahr" (VER-Ontologie) ............................................ 292 Konzeptklasse "Entladedatum" (VER-Ontologie) ....... 293 Konzeptklassen "Entladetag", "Entlademonat" und "Entladejahr" (VER-Ontologie) ....................................... 294 Konzeptklasse "Ladeort" (VER-Ontologie) ................... 295 Konzeptklassen "Ladename", "Ladestraße", "LadePLZ" und "Ladestadt" (VER-Ontologie) ............. 295 Konzeptklasse "Entladeort" (VER-Ontologie) .............. 296 Konzeptklassen "Entladename", "Entladestraße", "EntladePLZ" und "Entladestadt" (VER-Ontologie) .... 296 Konzeptklasse "Ladung" (VER-Ontologie) ................... 297 Konzeptklasse "Anzahl" (VER-Ontologie) .................... 297 Konzeptklasse "Packmittel" (VER-Ontologie) .............. 298 Protokoll "Laderaumnachfrage" (FUH-Ontologie)...... 303

XXVIII Axiom 79: Axiom 80:

Axiom 81: Axiom 82: Axiom 83: Axiom 84: Axiom 85: Axiom 86: Axiom 87: Axiom 88: Axiom 89: Axiom 90: Axiom 91: Axiom 92: Axiom 93: Axiom 94: Axiom 95: Axiom 96:

Axiomenverzeichnis Sendevorgänge zur Protokollvereinbarung (FUHOntologie) .......................................................................... 303 Laderaumgesuch eines Verladers mit Reaktionsmöglichkeiten des FUH-Agenten (FUHOntologie) .......................................................................... 304 Reaktionsmöglichkeiten des Verladers auf ein Transportangebot (FUH-Ontologie) .............................. 304 Datenfelder 01 bis 04 (FUH-Ontologie) ......................... 307 Datenfeldgruppe 01 mit Datenfeldern (FUHOntologie) .......................................................................... 307 Datenfeldgruppe 03 mit Datenfeldern (FUHOntologie) .......................................................................... 308 Konzeptklasse "Transport" (FUH-Ontologie)............... 310 Konzeptklasse "Transportfahrzeug" (FUHOntologie) .......................................................................... 312 Konzeptklasse "Verpackungseinheit" (FUHOntologie) .......................................................................... 312 Konzeptklasse "Ladungsgewicht" (FUH-Ontologie)... 313 Konzeptklasse "Stückzahl" (FUH-Ontologie) ............... 313 Konzeptklasse "Verladedatum" (FUH-Ontologie)....... 314 Konzeptklassen "Verladetag", "Verlademonat" und "Verladejahr" (FUH-Ontologie) ...................................... 315 Konzeptklasse "Abladedatum" (FUH-Ontologie)........ 315 Konzeptklassen "Abladetag", "Ablademonat" und "Abladejahr" (FUH-Ontologie) ....................................... 316 Konzeptklasse "Versandadresse" (FUH-Ontologie) .... 317 Meronyme der Bedeutungseinheit "Versandadresse" (FUH-Ontologie) ............................... 317 Konzeptklasse "Empfangsadresse1" und Meronyme (FUH-Ontologie) .......................................... 318

Verzeichnis der Mengendefinitionen Definition 1: Definition 2: Definition 3: Definition 4: Definition 5: Definition 6: Definition 7: Definition 8: Definition 9: Definition 10: Definition 11: Definition 12:

Zähler des Dicekoeffizienten .......................................... 178 Hypothesenmenge der Stufe 0........................................ 184 Hypothesenmenge der Stufe 1........................................ 185 Schnittmenge für den Zähler des Attributkoeffizienten........................................................ 203 Der hyperonyme und hyponyme Kontext einer Konzeptklasse ................................................................... 205 Schnittmengen zweier Hyponymen- oder Hyperonymen-Mengen ................................................... 205 Meronyme und holonyme Kontexte einer Konzeptklasse ................................................................... 212 Schnittmengen zweier Homonymie- und Meronymie-Mengen ......................................................... 213 Hypothesenmenge nach der Heterogenitätsüberwindung........................................... 233 Gemeinsame Sendevorgänge des VER- und FUHProtokolls, Sendevorgänge 1-4 ....................................... 324 Gemeinsame Sendevorgänge des VER- und FUHProtokolls, Sendevorgänge 5-8 ....................................... 325 Taxonomie-Schnittmengen des Fallbeispiels ............... 342

Verzeichnis der Konsistenzbedingungen Bedingung 1: Bedingung 2: Bedingung 3: Bedingung 4: Bedingung 5: Bedingung 6: Bedingung 7: Bedingung 8: Bedingung 9: Bedingung 10: Bedingung 11: Bedingung 12:

Bedingung 13: Bedingung 14: Bedingung 15: Bedingung 16:

Konsistente Verwendung der Rolle "endeGleichStart" ................................................................ 98 Konsistente Verwendung der Rollen "seGleichStart" und "seGleichEnde"................................. 99 Konsistente Verwendung der Rolle "terminierbarDurch" ......................................................... 102 Konsistente Verwendung der Rollen "hatSynonym" und "synVon" ................................................................... 109 Asymmetrie der Rolle "bezugZu" .................................. 137 Zulässige Kombinationen relativer und absoluter Zeitbezüge ......................................................................... 139 Protokollkompatibilität.................................................... 148 Gleiche Illokutionen bei SendevorgangsKompatibilität ................................................................... 148 Äquivalente Nachrichten bei SendevorgangsKompatibilität ................................................................... 149 Konsistente Verwendung zweier "genau"-Rollen bei Sendevorgangs-Kompatibilität ................................ 149 Konsistente Kombination einer "spätest"- und einer "frühest"-Rolle bei Sendevorgangs-Kompatibilität ..... 149 Konsistente Kombination einer "frühest"- und "genau"- sowie einer "spätest"- und "genau"- Rolle bei Sendevorgangs-Kompatibilität ................................ 150 Gleiche Ausrichtung relativer Zeitbezüge bei Sendevorgangs-Kompatibilität ....................................... 150 Mischung relativer und absoluter Zeitbezüge bei Sendevorgangs-Kompatibilität ....................................... 151 Kompatibilität logischer Verknüpfungen ..................... 153 Gleiche Ausrichtung inhaltlicher Bezüge bei Sendevorgangs-Kompatibilität ....................................... 154

XXXII

Verzeichnis der Konsistenzbedingungen

Bedingung 17: Sich überschneidende Sender- und Empfängerkonzepte bei SendevorgangsKompatibilität ................................................................... 154 Bedingung 18: Optionalität gemeinsamer Sendevorgänge .................. 156 Bedingung 19: Absolute Zeitbezüge bei gemeinsamen Sendevorgängen ............................................................... 156 Bedingung 20: Sendezeiten gemeinsamer Sendevorgänge bei Mischungen absoluter und relativer Zeitbezüge ......... 157 Bedingung 21: Ableitung der logischen Rolle für einen gemeinsamen Sendevorgang (Beispiel) ........................ 159 Bedingung 22: Hinreichende und notwendige Bedingungen für Synonymie ......................................................................... 235 Bedingung 23: Hinreichende und notwendige Bedingungen für Homonymie ....................................................................... 237 Bedingung 24: Hinreichende und notwendige Bedingungen für Strukturrelevanz ............................................................... 239 Bedingung 25: Hinreichende und notwendige Bedingungen für Strukturirrelevanz ............................................................ 240 Bedingung 26: Hinreichende und notwendige Bedingungen für Verschmelzungskonflikte ................................................ 243 Bedingung 27: Hinreichende und notwendige Bedingungen für Trennungskonflikte .......................................................... 244 Bedingung 28: Hinreichende und notwendige Bedingungen für fehlende taxonomische Beziehungen als Heterogenitätsursachen ................................................... 246 Bedingung 29: Hinreichende und notwendige Bedingungen für taxonomische Lücken als Heterogenitätsursachen ..... 249 Bedingung 30: Hinreichende und notwendige Bedingungen für fehlende mereologische Beziehungen als Heterogenitätsursachen ................................................... 252 Bedingung 31: Hinreichende und notwendige Bedingungen für fehlende Attributbeziehungen als Heterogenitätsursachen ................................................... 255 Bedingung 32: Hinreichende und notwendige Bedingungen für Attribut-Zuordnungskonflikte ....................................... 257 Bedingung 33: Hinreichende und notwendige Bedingungen für Granularitätskonflikte ...................................................... 259

Formelverzeichnis Formel 1: Formel 2: Formel 3: Formel 4: Formel 5: Formel 6: Formel 7 Formel 8: Formel 9: Formel 10: Formel 11: Formel 12: Formel 13: Formel 14: Formel 15: Formel 16: Formel 17: Formel 18:

Formale Semantik für die allgemeinste und die speziellste Klasse ................................................................ 62 Formale Semantik für abgeschlossene Klassen .............. 62 Formale Semantik für Klassenkonjunktion, -disjunktion und -negation................................................ 64 Formale Semantik für Rollenkonjunktion, -disjunktion, -kontravalenz und -negation ..................... 65 Formale Semantik für Rolleninversion............................ 66 Formale Semantik für universelle und existenzielle Werterestriktionen .............................................................. 68 Formale Semantik für einfache Kardinalitätseinschränkungen ......................................... 68 Formale Semantik für qualifizierende Kardinalitätseinschränkungen ......................................... 69 Formale Semantik für universelle und existenzielle Datentypdeklarationen ...................................................... 71 Formale Semantik für universelle und existenzielle Deklarationen von Datentypgruppen ............................. 73 Formale Semantik für Klassendefinitionen und inklusionen .......................................................................... 76 Formale Semantik für Rollendefinitionen und inklusionen .......................................................................... 77 Formale Semantik für Domänen- und Bildbereichsaxiome ............................................................ 78 Formale Semantik für Rollensymmetrie ......................... 78 Formale Semantik für Rollentransitivität........................ 78 Formale Darstellung funktionaler Rollen ....................... 79 Formale Semantik für Klassenaussagen .......................... 79 Formale Semantik für Aussagen mit Abstrakten Rollen .................................................................................... 80

XXXIV Formel 19: Formel 20: Formel 21: Formel 22: Formel 23: Formel 24: Formel 25: Formel 26: Formel 27: Formel 28: Formel 29: Formel 30: Formel 31: Formel 32: Formel 33: Formel 34: Formel 35: Formel 36: Formel 37: Formel 38: Formel 39: Formel 40: Formel 41: Formel 42:

Formelverzeichnis Formale Semantik für Aussagen mit Konkreten Rollen .................................................................................... 80 Formale Semantik für Gleichheit und Ungleichheit von Individuen.................................................................... 80 Dicekoeffizient .................................................................. 178 Berechnung der Konzeptklassenäquivalenz mithilfe der Bayes'schen Regel ....................................... 180 Ableitung der Normalisierungskonstante zur Berechnung der Bayes-Formel ........................................ 181 Levensteinmaß .................................................................. 192 Modifiziertes Levensteinmaß ......................................... 193 N-Gramatische Ähnlichkeit ............................................ 194 Jaromaß .............................................................................. 196 Cosinusmaß ....................................................................... 200 Cosinusmaß in Mengendarstellung ............................... 200 Mittlere quadratische Abweichung ............................... 201 Bezeichnerkoeffizient ....................................................... 202 Attributkoeffizient ............................................................ 203 Hyponymie- und Hyperonymiekoeffizient.................. 205 Taxonomiekoeffizient ...................................................... 206 Graphenbasierte Konzeptähnlichkeit: Berechnung des n-ten Iterationsschritts .............................................. 209 Graphenbasierter Äquivalenzindikator ........................ 211 Homonymie- und Meronymiekoeffizient ..................... 212 Mereologiekoeffizient ...................................................... 213 RA-Relevanz ...................................................................... 214 Äquivalenzkoeffizient...................................................... 218 Berechnung der Normalisierungskonstante ................. 218 Formale Definition von Äquivalenz und Inäquivalenz ...................................................................... 224

1 Einleitung Die Zielsetzung der vorliegenden Arbeit besteht in der Entwicklung einer Architektur für intelligenten Geschäftsdatenaustausch ("Intelligent Data Interchange", IDI). Diese IDI-Architektur soll einen interventionsfreien Austausch elektronischer Geschäftsdokumente ermöglichen. Interventionsfreiheit bedeutet, dass Unternehmen vor der Aufnahme einer Kommunikationsbeziehung keine Vereinbarungen über Syntax, Semantik und Pragmatik der auszutauschenden Geschäftsnachrichten treffen müssen. Zentrale Bestandteile der IDI-Architektur sind die sog. IDI-Agenten. Sie fungieren, ähnlich wie bereits heute verfügbare EDI1-Systeme, als Schnittstellen zwischen den lokalen Anwendungssystemen und den EDI-Systemen der Kommunikationspartner. Im Gegensatz zu bestehenden EDI-Systemen sollen sie allerdings in der Lage sein, Syntax-, Semantik- und Pragmatikeigenschaften einer empfangenen elektronischen Geschäftsnachricht eigenständig erkennen und die zur Steuerung des Nachrichtenflusses erforderlichen Protokolle vereinbaren zu können. Somit können Absprachen zwischen den kommunizierenden Unternehmen über die semiotischen Eigenschaften auszutauschender Geschäftsnachrichten entfallen. Unternehmen werden in die Lage versetzt, Geschäftsdaten auch ad hoc und mit unbekannten Partnern elektronisch austauschen zu können. Die Forschungsidee dieser Arbeit besteht darin, das Wissen über die Syntax, Semantik und Pragmatik der zu versendenden und empfangenden Geschäftsnachrichten sowie die erforderlichen Interaktionsprotokolle in lokalen Ontologien zu speichern. IDI-Agenten ergänzen jede zu versen-

1

Die Abkürzung "EDI" steht für "Electronic Data Interchange". Vgl. Abschnitt 2.1.1.

A. Köhler, Intelligent Data Interchange (IDI), DOI 10.1007/978-3-8348-9767-1_1, © Vieweg+Teubner Verlag |Springer Fachmedien Wiesbaden GmbH 2010

2

1 Einleitung

dende elektronische Geschäftsnachricht um Metadaten, die den für diese Nachricht relevanten Ausschnitt ihrer Ontologie beinhalten. Die begleitenden Metadaten enthalten also das gesamte Wissen, das der empfangende IDI-Agent zur Syntax-, Semantik- und Pragmatik-Interpretation benötigt. Ontologische Matchingverfahren ermöglichen den empfangenden IDI-Agenten die Interpretation dieser Metadaten. Um eine möglichst breite Interoperabilitätsbasis zu schaffen, wird eine zweigliedrige Ontologiearchitektur vorgeschlagen. Dieser Architekturvorschlag sieht vor, das lokal gespeicherte Domänenwissen mithilfe eines global gültigen Vokabulars zu formulieren. Die folgenden Architekturbestandteile sind Gegenstand dieser Forschungsarbeit: ƒ Protokolle und Methoden zur Protokollvereinbarung, ƒ ein Ontologievokabular zur Spezifikation der Geschäftsdatensyntax, ƒ ein Ontologievokabular zur Spezifikation der Geschäftsdatensemantik und ontologische Matchingverfahren zur Interpretation von Geschäftsinhalten sowie ƒ ein Ontologievokabular zur Spezifikation der Geschäftsdatenpragmatik. Aufgrund der bei einer dezentralen Ontologieentwicklung zu erwartenden ontologischen Heterogenität kann nicht davon ausgegangen werden, dass die IDI-Agenten in der Lage sein werden, alle ontologischen Mappings identifizieren zu können. Daher sind auf den Anwendungsfall "Intelligent Data Interchange" zugeschnittene Methoden zur Identifizierung von Heterogenitätsursachen und Strategien zur Heterogenitätsüberwindung ebenfalls Forschungsgegenstand. Methodisch basiert die vorliegende Arbeit auf den beiden Forschungsansätzen der konzeptionellen Systementwicklung und wissenschaftlichen Konstruktion2. Dabei werden zunächst – basierend auf einer theoreti-

2

Zur wissenschaftlichen Konstruktion als Methode wissenschaftlicher Erkenntnisgewinnung vgl. Haefner 2000, S. 70.

1 Einleitung

3

schen Analyse der Anwendungsdomäne – logisch abgeleitete Gestaltungsempfehlungen erarbeitet, die das gewünschte Verhalten einer IDIArchitektur spezifizieren.3 Gesucht ist dann, so das Sachziel der wissenschaftlichen Konstruktion, "[...] eine Struktur des Systems, die zu dem geforderten Verhalten führt."4 Die Arbeit besteht aus insgesamt sieben Kapiteln. Das zweite Kapitel beschreibt die Motivation für das Forschungsvorhaben und gibt einen thematischen Einstieg. Zunächst erfolgt eine kritische Analyse bestehender EDI-Systeme. Aus den gewonnenen Erkenntnissen über die Schwächen dieser EDI-Systeme sowie die sich wandelnden Anforderungen an den zwischenbetrieblichen Geschäftsdatenaustausch wird die Notwendigkeit für einen "intelligenten" Geschäftsdatenaustausch abgeleitet. Die Relevanz der Forschungsidee "IDI" wird anhand einiger möglicher Einsatzszenarien für IDI-Agenten aufgezeigt. Gegenstand des dritten Kapitels ist die Evaluation geeigneter Ontologiearchitekturen und -sprachen. Zunächst werden die Grundlagen ontologischer Wissensrepräsentation erläutert. Darauf folgt eine Darstellung der IDI-Ontologiestruktur. Hieran schließt sich die Vorstellung der zur Wissensrepräsentation verwendeten formalen Sprache + '!&() an. Das vierte Kapitel besitzt zwei inhaltliche Schwerpunkte. Zum einen werden die benötigten Repräsentationsinhalte identifiziert und informal dargestellt. Zum anderen wird ein formales Vokabular auf Basis der Repräsentationssprache + '!&() vorgestellt, das zur Entwicklung der lokalen Ontologien verwendet werden muss. Die Gliederung des dritten Kapitels folgt den Repräsentationsebenen "Syntax", "Semantik", "Pragmatik" und "Interaktionsprotokolle". Das fünfte Kapitel beinhaltet den IDI-Ansatz für das ontologische Matching. Das Kapitel beginnt mit einem Überblick über bestehende Ansätze zum Ontologie-Matching. Das IDI-Matching besteht aus drei Teilprozessen: der Falsifikation von Mappinghypothesen, der Kalkulation von

3 4

Vgl. Ferstl 1979, S. 44; Habermann 2001, S. 5. Ferstl 1979, S. 3; Sinz 1999.

4

1 Einleitung

Äquivalenzindikatoren und der Äquivalenzwahrscheinlichkeit sowie der Identifizierung und Überwindung von Heterogenität. Das sechste Kapitel zeigt den Einsatz der vorgestellten Verfahren zur Wissensrepräsentation und zum ontologischen Matching anhand eines Anwendungsbeispiels. Im abschließenden siebten Kapitel erfolgt eine zusammenfassende Bewertung der erarbeiteten Forschungsergebnisse. Das Kapitel endet mit einer Betrachtung des weiteren Forschungsbedarfs.

2 Von EDI zu IDI – ein Paradigmenwechsel 2.1 Ausgangssituation und Problemstellung 2.1.1 EDI-Grundlagen Der elektronische Austausch strukturierter Geschäftsdaten, auch als "Electronic Data Interchange (EDI)" bezeichnet, ist in vielen Unternehmen ein wichtiges Instrument zur Steuerung zwischenbetrieblicher Wertschöpfungsketten geworden. Der Einsatz von EDI-Technologie ermöglicht es, ohne Medienbrüche Geschäftsdaten zwischen den Anwendungen unterschiedlicher Unternehmen auszutauschen. "Electronic data interchange (EDI) is the term used to refer to the exchange of structured business documents – such as purchase orders, invoices, and delivery schedules – that have been processed into binary digits. These machine-readable messages are sent between computing devices and may or may not be read by human operators."5 Dieser Geschäftsdatenaustausch erfolgt meistens in Dateiform. Dabei erzeugt die Sender-Anwendung eine Geschäftsdatendatei, die an den Empfänger übermittelt wird. Alternativ hierzu können Kommunikationspartner auch die Nutzung eines standardisierten Zwischenformats wie bspw. EDIFACT vereinbaren. In diesem Fall muss die Geschäftsdatendatei zunächst in die EDIFACT-Syntax konvertiert werden.

5

o.V. 1993, S. 1.

A. Köhler, Intelligent Data Interchange (IDI), DOI 10.1007/978-3-8348-9767-1_2, © Vieweg+Teubner Verlag |Springer Fachmedien Wiesbaden GmbH 2010

6

2 Von EDI zu IDI – ein Paradigmenwechsel

Zur Steuerung und Abwicklung des elektronischen Geschäftsdatenaustausches kommen in der Regel spezielle EDI-Systeme6 zum Einsatz. Ihre Aufgaben bestehen u.a. aus ƒ der Bereitstellung von Schnittstellen zu den unternehmensinternen Anwendungen, ƒ der Bereitstellung von Mappingwerkzeugen, die eine syntaktische und semantische Zuordnung zwischen den Elementen unterschiedlicher EDI-Formate ermöglichen, ƒ der Konvertierung zwischen unterschiedlichen EDI-Formaten7 sowie ƒ der Bereitstellung von Schnittstellen zu Kommunikationsdiensten. Zur vertraglichen Absicherung des Geschäftsdatenaustausches werden zwischen den beteiligten Kommunikationspartnern meistens sog. Implementierungsvereinbarungen getroffen. Sie enthalten Abmachungen der beteiligten Partner über die Syntax, Semantik und Pragmatik der auszutauschenden Geschäftsdaten. Es wird bspw. festgelegt, welche Bedeutung einzelne Datenfelder haben, nach welchen Regeln das Mapping zwischen Quell- und Zielformat vorgenommen werden muss oder wie der Geschäftspartner bei einer erfolgreichen oder fehlerhaften Übertragung zu reagieren hat. Diese Vereinbarungen müssen getroffen werden, bevor Geschäftsdaten zwischen den beteiligten Partnern elektronisch ausgetauscht werden können. Unternehmen versprechen sich von der EDI-Nutzung unter anderem ƒ eine höhere Datenqualität, da elektronisch empfangene Geschäftsdaten nicht noch einmal erfasst werden müssen und somit Erfassungsfehler reduziert werden können, ƒ Wettbewerbsvorteile durch eine schnellere Verarbeitung und Bereitstellung von Informationen,

6

7

Vgl. Deutsch 1995, S. 136. Für eine detaillierte Schilderung der Komponenten von EDI-Anwendungen vgl. Lamprecht 1998, S. 24. Für eine detaillierte Darstellung des Mappings und der Konvertierung von EDINachrichten vgl. Deutsch 1995, S. 147-148.

2.1 Ausgangssituation und Problemstellung

7

ƒ eine höhere Bindung von Lieferanten und Kunden an das Unternehmen.8 Darüber hinaus schafft erst der elektronische Geschäftsdatenaustausch die Voraussetzung für zahlreiche Ansätze zur unternehmensübergreifenden Geschäftsprozessoptimierung. Als Beispiele seien Just-in-TimeLieferketten sowie die lieferantengesteuerte Bestandsführung (Vendor Managed Inventory, VMI) genannt.9 Der Erfolg derartiger Ansätze hängt wesentlich von der zeitnahen Bereitstellung der benötigten Geschäftsdaten ab. In den 90er Jahren des letzten Jahrhunderts sorgten EDI-Standards wie EDIFACT in Deutschland oder ANSI X12 in den USA für eine zunehmende Ausbreitung des elektronischen Geschäftsdatenaustausches. Im Jahr 1999 setzte gut die Hälfte aller an einer empirischen Studie teilnehmenden deutschen Unternehmen EDI-Technologie ein, amerikanische Firmen erreichten einen Durchdringungsgrad von 75 Prozent.10

2.1.2 Schwächen des klassischen EDI Die oben beschriebenen und im weiteren Verlauf der Arbeit auch als "klassisches EDI" bezeichneten Verfahren weisen einige Schwächen auf. So ist die Implementierung einer solchen EDI-Beziehung mit erheblichem Aufwand verbunden, da sie auf allen semiotischen Ebenen11 (Syntax, Semantik, Pragmatik) eine vorherige Absprache zwischen den Kommunikationspartnern erfordert. Für jeden Transaktionstyp12, der mit einem bestimmten Geschäftspartner ausgetauscht wird, sind vorab die Geschäftsdatensyntax, die Bedeutung der Geschäftsinhalte sowie die

8 9 10 11

12

Vgl. Stahlknecht, Hasenkamp 2002, S. 386; Müller-Berg 1995, S. 19-21. Vgl. Scheckenbach, Zeier 2003, S. 130; Westarp et al. 1999, S. 23. Vgl. Westarp et al. 1999, S. 25-27. Zielsetzung der Semiotik ist "[…] die wissenschaftliche Erforschung der Gegenstände und der Funktionsweisen von Kommunikationsvorgängen". Picot et al. 2003, S. 89. Transaktionstypen sind Rechnungen, Bestellungen etc.

8

2 Von EDI zu IDI – ein Paradigmenwechsel

rechtlichen und organisatorischen Rahmenbedingungen des Geschäftsdatenaustausches zu vereinbaren. EDI-Standards wie EDIFACT wurden ursprünglich entwickelt, um den Implementierungs- und Pflegeaufwand des EDI-Einsatzes zu senken. Dieses Ziel sollte durch die Definition eines möglichst umfassenden Standards erreicht werden, der für alle denkbaren Transaktionstypen geeignete Nachrichtentypen bereitstellte und durch eine semantische Spezifikation der in den Standardnachrichten enthaltenen Elemente für semantische Interoperabilität sorgte. Dieses Ziel konnte jedoch – nicht zuletzt aufgrund des Anspruchs, die Anforderungen möglichst vieler Branchen abdecken zu können – nicht erreicht werden. Insbesondere bei den Codelisten und Qualifiern ist eine teilweise eklatante Mehrdeutigkeit zu beklagen13; andererseits wiederum sind für bestimmte Anwendungszwecke keine Codes verfügbar.14 Die semantische Mehrdeutigkeit, die auch andere EDIFACT-Strukturebenen wie Segmente, Datenfelder und letztlich auch die Nachrichtentypen betrifft, führt dazu, dass die Bedeutung dieser Strukturelemente trotz aller Standardisierungsbemühungen vor der Aufnahme einer EDI-Beziehung vereinbart werden muss. Ein anderes, generelles Problem klassischer EDI-Standards besteht in ihrer mangelnden Fähigkeit, semantische Beziehungen zwischen einzelnen Entitäten ausdrücken zu können. Dies sei am Beispiel des EDIFACTSegments "DTM" verdeutlicht. Ein Segment, das durch diese drei Buchstaben gekennzeichnet wird, enthält immer eine Datums- oder Zeitangabe. Die weitere Segmentspezifikation erfolgt durch die Codeliste 2005. Code Nr. 36 bspw. lautet "Expiry date", also "Verfallsdatum". Mit einem solchen Code ist zwar eine zusätzliche semantische Spezifikation der Datumsangabe verbunden. Allerdings ist innerhalb des DTM-Segments kein expliziter Hinweis darauf vorgesehen, auf welches Objekt bzw. auf welche andere Entität innerhalb der EDIFACT-Nachricht sich ein solches Verfallsdatum beziehen soll. Derartige inhaltliche Bezüge müssen in heu-

13 14

Eine Einführung zu EDIFACT ist in Abschnitt 6.2.1.1 zu finden. Vgl. Deutsch 1995, S. 152.

2.1 Ausgangssituation und Problemstellung

9

tigen EDI-Architekturen stets explizit vereinbart werden, bevor die erste Nachricht ausgetauscht werden kann. Die mangelnde Fähigkeit zur Spezifikation von Beziehungen zwischen den Entitäten eines EDI-Standards führt auch an anderer Stelle zu semantischen Mehrdeutigkeiten. So lässt sich zwar die Bedeutung von Segmenten oder Datenfeldern bei EDIFACT durch Codes definieren. Die semantischen Beziehungen zwischen diesen Codes werden jedoch nirgendwo abgebildet. So lässt sich in EDIFACT bspw. nicht darstellen, dass der eine Code eine Spezialisierung eines anderen Codes repräsentiert. Dies hat erhebliche Bedeutungsüberschneidungen zur Folge. Die Notwendigkeit zur Vereinbarung von Syntax und Semantik für alle Bestandteile einer Geschäftsnachricht verursacht nicht nur einen erheblichen Aufwand. Sie grenzt auch die Flexibilität von Unternehmen bei der Aufnahme neuer Kommunikationsbeziehungen erheblich ein. Ad-hocKommunikation ist auf diese Weise nicht möglich. Abschließend sei darauf hingewiesen, dass die Semantik heutiger EDIStandards informal definiert wird. Somit ist kein maschineller Zugriff auf diese Semantikspezifikationen möglich. Zudem schaffen informale Bedeutungsspezifikationen eher Interpretationsspielräume als formale. Die eindeutige Interpretierbarkeit von EDI-Inhalten wird also eher durch formale Bedeutungsspezifikationen gewährleistet.15

2.1.3 Sich wandelnde Anforderungen an den elektronischen Geschäftsdatenaustausch Unabhängig von den o.g. Schwächen hat sich der Einsatz klassischer EDI-Systeme in Geschäftsprozessen mit bestimmten, charakteristischen Merkmalen etabliert. Dieser Abschnitt zeigt zunächst auf, welche Merkmale als Voraussetzungen für den Einsatz klassischer EDI-Architekturen betrachtet werden können. Anschließend werden Merkmale von Prozesskategorien beschrieben, in denen zukünftig Geschäftsdaten durch IDI-Agenten ausgetauscht werden könnten.

15

Vgl. Moore 2000, S. 6.

10

2 Von EDI zu IDI – ein Paradigmenwechsel

Klassisches EDI wird fast ausschließlich in sog. "Routineprozessen"16 genutzt. Charakteristische Merkmale dieser Prozesskategorie sind ƒ eine niedrige Komplexität und Variabilität der unternehmensübergreifenden Interaktionsstruktur, ƒ stabile Geschäftsbeziehungen zu Kommunikationspartnern, ƒ die hohe Strukturiertheit sowie ƒ ein großes Belegvolumen und hohe Performanceanforderungen.17 Die oben beschriebenen Merkmale von Routineprozessen sind als Voraussetzungen für den Einsatz klassischer EDI-Technologie zu betrachten.18 Nur sie erlauben eine wirtschaftliche Nutzung klassischer EDIVerfahren. Interventionsfreiheit beim Einsatz von EDI in Routineprozessen ist insofern gegeben, als dass eine EDI-Beziehung, ist sie erst einmal implementiert, in Geschäftsprozessen dieses Typs kaum noch einer weiteren Änderung unterworfen ist. Es ist jedoch, wie auch die Anwendungsbeispiele für IDI-Agenten in Abschnitt 2.4 veranschaulichen, von sich wandelnden Anforderungen an den elektronischen Geschäftsdatenaustausch auszugehen. "[...] there is a need for optimization of business processes and cost reduction resulting in establishing EDI on a more flexible or ad-hoc basis."19 Unternehmen werden zunehmend auch in sog. Regelprozessen die Vorteile eines automatisierten elektronischen Geschäftsdatenaustausches nutzen wollen. Regelprozesse sind Prozesse mit ƒ einer mittleren Komplexität und Variabilität,

16 17

18 19

Zum Begriff "Routineprozess" vgl. Picot, Rohrbach 1995, S. 31. Vgl. Rebstock et al. 2008, S. 14; Schmoll, Nommensen 1996, S. 14; Scheckenbach 1997, S. 7. Vgl. Quantz, Wichmann 2003, S. 31-40; Scheckenbach 1997, S. 47. Wombacher, Mahlecko 2002, S. 339.

2.1 Ausgangssituation und Problemstellung

11

ƒ wechselnden Kommunikationspartnern, mit denen u.U. nur wenige Nachrichten ausgetauscht werden, ƒ einer im Vergleich zu Routineprozessen geringeren Wiederholungshäufigkeit, ƒ der Anforderung zur Ad-hoc-Kommunikation, ƒ eingeschränkt determinierbaren Abläufe und Strukturen sowie ƒ einer im Vergleich zu Routineprozessen höheren Interprozessverflechtung.20 In Geschäftsprozessen mit den o.g. Eigenschaften ist der Einsatz von klassischem EDI nicht oder nur unter unwirtschaftlichen Bedingungen möglich.21 Gegenstand des vorliegenden Forschungsvorhabens ist daher die Entwicklung einer IDI-Architektur, die einen interventionsfreien elektronischen Geschäftsdatenaustausch auch in sog. Regelprozessen erlaubt. Wie die folgende Abbildung verdeutlichen soll, führt der Einsatz von IDI-Technologie weniger zu einer Substitution, sondern eher zu einer Ergänzung von EDI-Systemen. In Abhängigkeit von bestimmten Prozesseigenschaften kann sowohl der Einsatz von IDI- als auch der Einsatz von EDI-Technologie sinnvoll sein. Gleichwohl ist zu postulieren, dass die Verwendung von IDI-Technologie auch in Routineprozessen zu einer Reduktion des Implementierungs- und Pflegeaufwands führen dürfte.

20

21

Vgl. Rebstock et al. 2008, S. 15; Schwarz et al. 2001, S. 3-4; Picot, Rohrbach 1995, S. 31. Vgl. Scheckenbach 1997, S. 46.

Routineprozesse

Anzahl der Schnittstellen Prozessvariabilität Spontanität des Informationsbedarfs Variabilität des Informationsbedarfs

EDI

eher hoch

2 Von EDI zu IDI – ein Paradigmenwechsel eher niedrig

12

Regelprozesse

IDI

Abbildung 1: Einfluss von Prozesseigenschaften auf den Einsatz von IDI- oder EDITechnologie

2.2 Status quo des elektronischen Geschäftsdatenaustausches 2.2.1 Electronic Business using XML (ebXML) Nicht zuletzt vor dem Hintergrund der skizzierten Schwächen klassischer EDI-Systeme wurden ab etwa Mitte der 90er Jahre des letzten Jahrhunderts zahlreiche neue Ansätze für den elektronischen Geschäftsdatenaustausch entwickelt. Als die beiden umfassendsten Initiativen sind RosettaNet und ebXML zu betrachten. Sie definieren nicht nur Nachrichten, sondern auch den Nachrichtentransport sowie ganze Geschäftsprozesse.22 Da ebXML, im Gegensatz zu RosettaNet, einen branchenübergreifenden Ansatz verfolgt und darüber hinaus auch als Basis für weitergehende, ontologiebasierte Ansätze dient, seien nun die Grundzüge der für diesen Forschungsbeitrag relevanten ebXML-Architekturmerkmale dargestellt. EbXML geht auf eine gemeinsame Initiative von OASIS und UN/CEFACT zurück. Zielsetzung ist der Entwurf eines weltweit gültigen

22

Vgl. Feßenbecker 2002.

2.2 Status quo des elektronischen Geschäftsdatenaustausches

13

und einheitlichen Rahmenwerks für den Austausch von Geschäftsdaten mittels XML.23 "The goal is to provide an XML-based open technical framework to enable XML to be utilized in a consistent and uniform manner for the exchange of electronic business (eb) data in application to application, application to human, and human to application environments – thus creating a single global electronic market." Für die vorliegende Arbeit ist vor allem die Spezifikation der ebXMLKernkomponenten von Interesse. Kernkomponenten repräsentieren die Semantik von Bausteinen, aus denen Geschäftsdokumente zusammengesetzt werden können. "Core components are semantic building blocks that can be used for all aspects of data and information modelling and exchange. Core components are the linchpin for creating interoperable business process models and business documents."24 Ein wesentliches Merkmal der ebXML-Kernkomponentenarchitektur besteht in der Festlegung unterschiedlicher Abstraktionsstufen. Während Kernkomponenten die grundlegende Semantik beschreiben, repräsentieren sog. "Geschäftsinformationsentitäten" ("Business Information Entities") Spezialisierungen dieser Kernkomponenten. Geschäftsinformationsentitäten sorgen also für eine Anpassung des Kernkomponentenmodells an bestimmte Umgebungsbedingungen.25 Bspw. könnte eine Kernkomponente das Realweltphänomen "Person" und eine Geschäftsinformationsentität das Realweltphänomen "Person mit deutschem Wohnsitz" repräsentieren. Eine wichtige Rolle in der ebXML-Architektur spielen sog. Kollaborationsprofile ("Collaboration-Protocol Profiles"). Kollaborationsprofile beinhalten Informationen über die von einem Geschäftspartner unterstütz-

23 24 25

Vgl. Weitzel et al. 2001, S. 116. UN/CEFACT 2007, S. 17. Vgl. UN/CEFACT 2007, S. 22.

14

2 Von EDI zu IDI – ein Paradigmenwechsel

ten Geschäftsprozesse und Geschäftsnachrichten.26 Hierbei handelt es sich um XML-Dokumente, die in Registrierungsdiensten gespeichert und dort von potenziellen Geschäftspartnern gefunden werden können. Die Vereinbarung einer Kommunikationsbeziehung und der sich hieraus ergebende Geschäftsdatenaustausch kann in sog. Kollaborationsvereinbarungen ("Collaboration-Protocol Agreements") hinterlegt werden. Diese Vereinbarungen werden ebenfalls in XML-Dokumenten festgehalten und sind mit den aus klassischen EDI-Ansätzen bekannten Handelspartnervereinbarungen vergleichbar.27 Zwar können durch die ebXML-Architektur einige Schwächen klassischer EDI-Ansätze überwunden werden. So lassen sich etwa durch die Berücksichtigung unterschiedlicher Abstraktionsstufen Redundanzen und semantische Mehrdeutigkeiten vermeiden. Weiterhin erlaubt die Spezifikation und Veröffentlichung der Kollaborationsprofile eine Reduktion des Implementierungsaufwands, da zumindest ein Teil der Schnittstellenbeschreibung nicht mehr mit jedem Partner separat erstellt werden muss. Allerdings sind auch die im Rahmen von ebXML entwickelten Standards noch nicht geeignet, einen automatisierten und interventionsfreien Geschäftsdatenaustausch in Regelprozessen zu gewährleisten. Bislang existiert kein Ansatz für das automatische Aushandeln einer Kollaborationsvereinbarung. Ein solcher Ansatz ließe sich mit der aktuell verfügbaren ebXML-Architektur auch nicht realisieren, weil die Semantikspezifikation von Kernkomponenten nicht formal erfolgt und somit auch kein maschineller Zugriff hierauf möglich ist. Es existiert kein Vokabular zur formalen Spezifikation der Semantik von Kernkomponenten.

2.2.2 Ontologiebasierte Ansätze In den letzten Jahren ist eine starke Zunahme des Einsatzes von Ontologien und hierauf aufsetzenden Diensten im betriebswirtschaftlichen Um-

26 27

Vgl. OASIS 2002, S. 11. Vgl. OASIS 2002, S. 11-12.

2.2 Status quo des elektronischen Geschäftsdatenaustausches

15

feld zu beobachten. Es seien nun zwei ontologiebasierte Ansätze vorgestellt, mit deren Hilfe die Leistungsfähigkeit von EDI-Systemen verbessert werden soll. Eine detaillierte Definition des Ontologiebegriffs erfolgt in Kapitel 3.2.2. Zunächst wird ein Ansatz von Foxvog und Bussler dargestellt.28 Die Zielsetzung der beiden Forscher besteht in der Entwicklung einer zentralen Ontologie zur Repräsentation von Syntax und Semantik von ANSI X12. Dabei soll allerdings lediglich das vorhandene Regelwerk formalisiert werden. Auf Syntaxebene ist vorgesehen, alle Syntax-Strukturelemente wie Datenfelder, Datenfeldgruppen etc. formal zu beschreiben. Diese Syntaxspezifikation bildet die Grundlage für die ontologische Semantikdefinition. Foxvog und Bussler schlagen vor, sämtliche Elemente des ANSI X12Standards semantisch zu spezifizieren. Hierzu gehören u.a. über 36.000 Datenelement-Codes, über 1.400 einfache Datenelemente sowie über 1.000 Segmente.29 Abgesehen von der Komplexität und dem Aufwand eines solchen Vorhabens ist anzumerken, dass der Ansatz von Foxvog und Bussler keine maschinelle Identifizierung der Bedeutung von ANSI X12-Elementen erlaubt, da lediglich die Struktur dieser Elemente ontologisch nachgebildet wird. Eine Semantikspezifikation im Sinne von Abschnitt 4.3 dieser Arbeit stellt die von Foxvog und Bussler vorgeschlagene Ontologie nicht dar. Somit ist auch keine Ad-hoc-Kommunikation möglich. Hinsichtlich des vorgestellten Syntaxvokabulars ist zu kritisieren, dass die Autoren lediglich die Spezifikation der Syntax von ANSI X12 vorsehen. Es handelt sich also bei diesem Vokabular um keine generische Sprache zur Beschreibung beliebiger Formatstandards. Auch an diesem Punkt scheitert die Fähigkeit zur Ad-hoc-Kommunikation.

28 29

Vgl. Foxvog, Bussler 2005. Vgl. Foxvog, Bussler 2005, S. 53.

16

2 Von EDI zu IDI – ein Paradigmenwechsel

Ein anderer Ansatz von Hofreiter und Huemer sieht die Erweiterung des ebXML-Standards um eine sog. "Dokumentenontologie" vor.30 Zielsetzung dieser Dokumentenontologie soll es sein, das Matching zwischen unterschiedlichen E-Business-Vokabularen zu unterstützen. Hofreiter und Huemer verstehen unter einem E-Business-Vokabular ein Dokument zur Strukturbeschreibung von XML-Dokumenten.31 Derartige Strukturbeschreibungen lassen sich mittels XML-Schemata32 oder DTDs33 erstellen. Der Prozess zum Aufbau einer ebXML-Dokumentenontologie wird von Hofreiter und Huemer in vier Stufen unterteilt. In einem ersten Schritt wird die Struktur der ebXML-Kernkomponenten in einer RDF34Bibliothek abgebildet. Dabei spiegelt das Vokabular dieser RDFBibliothek das den Kernkomponenten zugrunde liegende Metamodell wider. Zielsetzung ist also nicht die semantische Spezifikation der Kernkomponenten. Dies sei an einem Beispiel verdeutlicht. Im ebXMLMetamodell stellen sog. "Grundlegende Kernkomponenten" ("Basis Core Components")35 Spezialisierungen der allgemeinen Kernkomponenten dar. Dieser Zusammenhang wird in der RDF-Bibliothek durch eine subClassOf-Beziehung repräsentiert.36 In einem zweiten Schritt werden den in der RDF-Bibliothek angelegten Kernkomponenten Syntaxbeschreibungen zugeordnet. Diese Syntaxbeschreibungen beinhalten XML-spezifische Merkmale zur Darstellung der

30 31 32

33

34

35 36

Vgl. Hofreiter, Huemer 2002. Vgl. Hofreiter, Huemer 2002, S. 339 und S. 341. XML Schemata sind XML-Dokumente, die die Struktur anderer XML-Dokumente beschreiben. Für einen Überblick der Leistungsmerkmale von XML Schemata vgl. Jakobs 2007, S. 3. DTD steht für "Document Type Definition" und dient ebenfalls der Definition von Elementen für XML-Dokumente. Im Gegensatz zu XML Schemata sind DTDs jedoch nicht in XML notiert. Vgl. Ray 2004, S. 122-123. RDF steht für "Ressource Description Framework". RDF ist eine Ontologiesprache, die ursprünglich entwickelt wurde, um Informationen über Ressourcen im Internet zu repräsentieren. Vgl. Manola, Miller 2004. Für eine Erläuterung der Basic Core Components vgl. UN/CEFACT 2007, S. 20. Vgl. Hofreiter, Huemer 2002, S. 343-344.

2.2 Status quo des elektronischen Geschäftsdatenaustausches

17

zu den einzelnen Kernkomponenten gehörenden Geschäftsdaten. Ergebnis dieses zweiten Schritts sind E-Business-Vokabulare in Form von XML-Schemata oder DTDs. Die Beziehungen zwischen den Schemaelementen und den Kernkomponenten werden durch explizite Mappings festgelegt.37 Ein dritter Schritt sieht die Bildung kontextspezifischer Sichten auf die Kernkomponenten vor. Dabei werden die aus den Kernkomponenten abgeleiteten Geschäftsinformationsentitäten ebenfalls in die RDFBibliothek überführt. Die hier gebildeten sog. kontextspezifischen Sichten spiegeln die inhaltlichen Anforderungen an einzelne Geschäftsdokumente wider.38 Schließlich lassen sich in einem vierten Schritt Implementierungsrichtlinien für Geschäftsdokumente erstellen. Diese Implementierungsrichtlinien umfassen jedoch ausschließlich die Syntaxstruktur der auszutauschenden Geschäftsnachrichten. Dies ist der einzige Schritt, der automatisiert erfolgen kann.39 Der Ansatz von Hofreiter und Huemer sieht eine Zuordnung von syntaxbeschreibenden Elementen zu einzelnen Kernkomponenten vor. Dieser Ansatz weist hinsichtlich der in Abschnitt 2.1.3 genannten Anforderungen einige Schwächen auf. ƒ Der Ansatz von Hofreiter und Huemer sieht keine explizite Spezifikation einer Geschäftsdatensyntax vor. Es werden lediglich Kernkomponenten einzelnen XML-Strukturelementen zugeordnet. ƒ Derartige Zuordnungen sind somit auch nur für Nutzer der ebXMLKernkomponentenbibliotheken zu verwenden. ƒ Es lässt sich nur die Syntax von XML-Dokumenten spezifizieren. Es wird keine allgemeine Sprache zur Syntaxspezifikation beliebiger Geschäftsdokumente bereitgestellt.

37 38 39

Vgl. Hofreiter, Huemer 2002, S. 346-347. Vgl. Hofreiter, Huemer 2002, S. 347. Vgl. Hofreiter, Huemer 2002, S. 348.

18

2 Von EDI zu IDI – ein Paradigmenwechsel

ƒ Eine formale, semantische Spezifikation von Geschäftsinformationsentitäten ist nicht vorgesehen. Somit erfordert auch der Ansatz von Hofreiter und Huemer eine explizite Vereinbarung der Feldbedeutung. Aus den o.g. Gründen ist der Ansatz von Hofreiter und Huemer, ebenso wie der von Foxvog und Bussler, für den automatisierten Geschäftsdatenaustausch in Regelprozessen nicht geeignet.

2.3 Forschungsidee: Intelligent Data Interchange (IDI) Es sei nun die dieser Arbeit zugrunde liegende Forschungsidee skizziert. Intelligent Data Interchange (IDI) basiert auf sog. IDI-Agenten, die den interventionsfreien Austausch von Geschäftsdaten zwischen Unternehmen auch in sog. "Regelprozessen" erlauben. IDI-Agenten sind in der Lage, Syntax, Semantik und Pragmatik der auszutauschenden Geschäftsdaten ohne menschlichen Eingriff zu erkennen und die empfangenen Geschäftsdaten ihrer vorgesehenen Verwendung zuzuführen. Außerdem müssen IDI-Agenten Protokolle, also Sequenzen aufeinanderfolgender und fachlich zusammengehörender Nachrichten, vereinbaren können. Eine solche IDI-Architektur basiert auf drei wesentlichen Anforderungen: Repräsentationsfähigkeit, Interpretationsfähigkeit und Fähigkeit zur Heterogenitätsüberwindung.

Syntax

Semantik

Pragmatik

Protokolle Fähigkeit zur

Repräsentationsfähigkeit

Interpretationsfähigkeit

HeterogenitätsÜberwindung

Abbildung 2: Gestaltungsebenen der IDI-Architektur

2.3 Forschungsidee: Intelligent Data Interchange (IDI)

19

a) Repräsentationsfähigkeit und Metadatenversand Eine wichtige Eigenschaft von Regelprozessen ist ihre Veränderlichkeit, insbesondere hinsichtlich der Kommunikationspartner sowie der Inhalte von Geschäftsdokumenten. Aufgrund dieser Veränderlichkeit können Syntax, Semantik und Pragmatik von Geschäftsdokumenten nicht vor der Aufnahme einer Kommunikationsbeziehung durch menschliche Aufgabenträger vereinbart werden. Trotzdem muss zwischen den Kommunikationspartnern Interoperabilität auf den genannten semiotischen Ebenen hergestellt werden. Zur Lösung des Problems wird vorgeschlagen, ein Vokabular zur Beschreibung der Geschäftsdatensyntax, -semantik und -pragmatik sowie zur Protokollspezifikation zu entwickeln und zentral vorzugeben. Mithilfe eines solchen Vokabulars können Unternehmen die Eigenschaften von Nachrichten definieren und als Domänenwissen in ihren privaten Ontologien speichern. Dabei müsste ein Kommunikationspartner alle Nachrichten ontologisch spezifizieren, die von ihm gesendet oder empfangen werden sollen. Die semiotischen Eigenschaften einer Nachricht müssen dieser Nachricht in Form von Metadaten mitgegeben werden. b) Interpretationsfähigkeit Die Interpretationsfähigkeit ermöglicht den IDI-Agenten, Metadaten auf den vier genannten Ebenen interpretieren zu können. ƒ Interpretationsfähigkeit auf der Syntaxebene versetzt IDI-Agenten in die Lage, Geschäftsdaten syntaktisch lokalisieren, extrahieren und ggf. in ein Zielformat transformieren zu können. ƒ Interpretationsfähigkeit auf der Semantikebene ermöglicht IDIAgenten, die Bedeutung der Geschäftsdaten bestimmen zu können. ƒ Interpretationsfähigkeit auf der Pragmatikebene erlaubt den IDIAgenten, die Handlungsabsichten von Nachrichten erkennen und Geschäftsdaten ihrer vorbestimmten Verwendung zuführen zu können. ƒ Interpretationsfähigkeit auf der Protokollebene schließlich verleiht IDI-Agenten die Fähigkeit, Protokolle interpretieren und vereinbaren zu können.

20

2 Von EDI zu IDI – ein Paradigmenwechsel

Um die erhaltenen Metadaten interpretieren zu können, muss der empfangende IDI-Agent über eine lokale Ontologie verfügen, welche Wissen über die semiotischen Eigenschaften von Nachrichten enthält, die er empfangen können möchte. c) Fähigkeit, Heterogenität zu überwinden Das Wissen über die zu sendenden und zu empfangenden Nachrichten soll in privaten Ontologien gespeichert werden. Trotz der Verwendung eines gemeinsamen Vokabulars kann nicht von der Interoperabilität dieser Ontologien ausgegangen werden. Ein wichtiger Schwerpunkt dieser Forschungsarbeit muss somit bei der Analyse möglicher Heterogenitätsursachen liegen. Hierzu gehört auch die Entwicklung von Strategien zur Heterogenitätsüberwindung. Vor dem Hintergrund der oben beschriebenen Anforderungen an eine IDI-Architektur seien nun vier Forschungshypothesen formuliert. Hypothese 1: Syntaxwissen Die Eigenschaftskategorien zur Syntaxspezifikation beliebiger elektronischer Geschäftsnachrichten lassen sich vollständig durch ein zu definierendes Syntaxvokabular abbilden. Das mithilfe dieses Vokabulars formulierte Syntaxwissen ermöglicht die Extraktion von Geschäftsinhalten aus ihrer syntaktischen Hülle ohne vorherige manuelle Vereinbarung. Hypothese 2: Semantikwissen und ontologisches Matching Die Bedeutung der Inhalte von EDI-Nachrichten lässt sich durch ontologische Merkmale beschreiben. Ontologisches Matching ermöglicht die maschinelle Interpretation von Geschäftsnachrichten und ihren Bestandteilen.

2.3 Forschungsidee: Intelligent Data Interchange (IDI)

21

Hypothese 3: Pragmatikwissen Die Pragmatikeigenschaften beliebiger elektronischer Geschäftsnachrichten lassen sich durch ein zu definierendes Pragmatikvokabular vollständig formal beschreiben. Durch die Bereitstellung eines ontologischen Pragmatikvokabulars wird der maschinelle Zugriff auf die mit einer Geschäftsnachricht verbundene Handlungsabsicht ermöglicht. Hypothese 4: Protokollwissen und Protokollmatching Eigenschaften und Randbedingungen von Nachrichtensequenzen lassen sich durch definierte Protokollvokabulare vollständig beschreiben. Protokolle können durch vorgegebene Metaprotokolle ohne menschlichen Eingriff zwischen zwei IDI-Agenten vereinbart werden. Die beschriebene Forschungsidee impliziert einen Paradigmenwechsel. So modellieren Unternehmen nicht mehr eine zwischenbetriebliche Perspektive in Form eines auszutauschenden Zwischenformats, das bspw. auf einem Standard wie EDIFACT basiert. Stattdessen definieren sie die Struktur und die Bedeutung der von ihren Anwendungssystemen verarbeitbaren und erzeugbaren Geschäftsdaten in Form von ontologischen Merkmalen. Dabei greifen sie auf ein zentral vorgegebenes Vokabular zurück. Es sei nun ein Überblick über die wesentlichen Elemente der IDIArchitektur gegeben.

22

2 Von EDI zu IDI – ein Paradigmenwechsel IDI-Agent Ontologie

Matchingkomponente

IDI Datenaustausch

Vokabular

Interpretation

Metadaten

bestimmt Struktur und Inhalt

Generierung

spezifizieren Geschäftsnachricht

Domänenwissen

TransformationsKomponente steuert

Konvertierung

AnwendungsSysteme

Wissen über Syntax, Semantik, Pragmatik und Interaktionsprotokolle Abbildung 3: Architekturkomponenten

Es wird eine zweigeteilte ontologische Struktur vorgeschlagen. ƒ Eine öffentliche Ontologie stellt das für alle IDI-Agenten verbindlich zu verwendende Vokabular zur Spezifikation des erforderlichen Domänenwissens bereit. ƒ Jeder IDI-Agent greift lokal auf eine eigene Ontologie zurück. Hier sind Syntax, Semantik und Pragmatik der durch ihn zu empfangenden und versendenden Nachrichten gespeichert. Zur Spezifikation dieser privaten Ontologien wird das in der öffentlichen Ontologie bereitgestellte Vokabular verwendet. IDI-Agenten haben drei Aufgaben zu erfüllen: ƒ Generierung begleitender Metadaten bei zu versendenden Nachrichten, ƒ Interpretation begleitender Metadaten bei empfangenen Nachrichten,

2.4 Einsatzmöglichkeiten für IDI-Agenten

23

ƒ Transformation von Geschäftsdaten. Zur Erfüllung dieser Aufgaben greifen IDI-Agenten auf das lokal definierte Domänenwissen zurück. Geschäftsnachrichten werden in Architekturen intelligenter IDI-Agenten um eine Metadatenebene ergänzt. Die begleitenden Metadaten spezifizieren Syntax, Semantik und Pragmatik der jeweiligen Nachrichten.

2.4 Einsatzmöglichkeiten für IDI-Agenten Zur Darlegung der Relevanz des bearbeiteten Forschungsthemas seien nun mögliche Einsatzszenarien für IDI-Agenten skizziert. Als erstes Beispiel soll die Ausschreibung und Vergabe von Baudienstleistungen betrachtet werden. Solche Ausschreibungsprozesse sind durch eine hohe Anzahl an Kommunikationsbeziehungen zwischen dem Auftraggeber und einer u.U. hohen Zahl von z.T. unbekannten potenziellen Auftragnehmern gekennzeichnet. Im Rahmen des Vergabeprozesses erstellt der Auftraggeber in der Regel zunächst ein Leistungsverzeichnis, das er einer möglichsten großen Anzahl geeigneter Auftragnehmer bekannt machen möchte. Die Suche nach ausgeschriebenen Waren und Dienstleistungen erfolgt heute noch weitgehend manuell; dies stellt für Auftragnehmer einen erheblichen Aufwand dar.40 Diese müssen teilweise noch Angebote von Subunternehmern einholen, ehe alle Angebotsbestandteile aggregiert und dem Auftraggeber zur Prüfung übersendet werden können. Der Dokumentenversand zwischen den Ausschreibungsparteien erfolgt noch weitgehend papierbasiert. Jeder Teilnehmer erfasst die für ihn relevanten Daten erneut und sendet sie z.B. an Subunternehmer weiter. Somit entstehen zahlreiche Medienbrüche, die mit der Gefahr der fehlerhaften Datenerfassung verbunden sind. Zur Automatisierung dieser im Rahmen von Ausschreibungen erforderlichen Interaktionsstrukturen

40

Vgl. Geibig 2007, S. 40.

24

2 Von EDI zu IDI – ein Paradigmenwechsel

zwischen Unternehmen erscheinen bestehende EDI-Ansätze wenig geeignet, da es sich bei den beschriebenen Prozessen eher um Regel- als Routineprozesse handelt. Als zweites Beispiel sei die Zusammenführung von Waren- und Informationsströmen in Logistikketten genannt. Bislang wurden Warenund Informationsströme in Transportketten weitgehend entkoppelt, um die begleitenden Geschäftsdaten den Waren voraussenden zu können.41 So werden Ladungsdaten heute in den meisten Fällen per Post oder elektronisch versendet. Der zunehmende Einsatz der RFID-Technologie bewirkt jedoch einen Veränderungsprozess. Er eröffnet die Möglichkeit, Ladungsdaten direkt an das zu versendende Gut zu koppeln. So könnten etwa auf einem am Produkt befestigten RFID-Chip Daten über Material, Herstellungsort, Produktionscharge, Umweltdaten, Produkteigenschaften, Versandadressen, Lagerplätze usw. gespeichert sein. Die Zusammenführung von Waren- und Informationsströmen eröffnet Chancen, Geschäftsprozesse in Logistikketten schlanker gestalten bzw. den Servicegrad erhöhen zu können. Dies sei beispielhaft anhand eines von Schoch und Strassner beschriebenen "smarten Lagers" gezeigt: "Ein smartes Lager könnte beispielsweise automatisch erkennen, welche Güter es enthält und könnte bei Bedarf, evtl. nach Absprache mit dem Produktionssystem, eine Bestellung aufgeben. Das smarte Lager wäre nicht nur in der Lage den Bestand zu kontrollieren, sondern würde auch darauf achten, dass Güter an der richtigen Stelle eingelagert, explosionsgefährdete oder verderbliche Güter ordnungsgemäß aufbewahrt und Güter nicht gestohlen werden."42 Der Trend zur oben beschriebenen Kopplung von Waren- und Informationsströmen wird in der Literatur allgemein unter dem Stichwort "Ubiquitous Computing" diskutiert. Hierunter ist die Allgegenwärtigkeit von Datenverarbeitung zu verstehen. Die Vision eines solchen, alle Unternehmensbereiche durchdringenden, IT-Einsatzes besteht aus einer "um-

41 42

Vgl. o.V. 2004, S. 4. Schoch, Strassner 2003, S. 3.

2.4 Einsatzmöglichkeiten für IDI-Agenten

25

fassenden Informatisierung und Vernetzung fast aller Dinge."43 Wichtigster Baustein des Ubiquitous Computing sind sog. "smarte Dinge"; hierzu gehören auch die oben beschriebenen RFID-Chips. "Smarte Dinge sind hybride Produkte. Sie setzen sich aus einer physischen (Atome) und einer datenverarbeitenden (Bits) Komponente zusammen. Der datenverarbeitende Anteil eines smarten Dings verbirgt sich im Hintergrund, d.h. er wird vom Nutzer oftmals nicht offensichtlich wahrgenommen."44 Es erscheint offensichtlich, dass Ubiquitous Computing zu einem starken Anwachsen der Maschine-zu-Maschine-Kommunikation führen wird.45 Dies gilt nicht nur für Kommunikationsprozesse innerhalb von Unternehmen, sondern auch für zwischenbetriebliche Kommunikationsprozesse. Wenn RFID-Chips Geschäftsdaten für einzelne Produkte beinhalten, dann wird entlang der gesamten Logistikkette von der Produktion bis zum Endkunden an zahlreichen Stellen die Notwendigkeit zum Auslesen und korrekten Interpretieren dieser Geschäftsdaten bestehen. Die Zusammenführung von Waren- und Informationsströmen ist also aus der Perspektive des zwischenbetrieblichen Geschäftsdatenaustausches durch einen starken Zuwachs der Ad-hoc-Kommunikation mit unbekannten Partnern gekennzeichnet. Für dieses Anwendungsumfeld sind bestehende EDI-Techniken nicht geeignet. Das dritte Beispiel betrachtet Dienstleistungen, die online erbracht werden. Als eher technikorientierter Begriff für derartige Dienstleistungen hat sich die Bezeichnung "Web Services" etabliert. "Web-Services sind unabhängige Software-Objekte, die eine bestimmte Funktionalität oder einen Geschäftsprozess realisieren. Sie kommunizieren mit Hilfe von standardisierten, XML46-basierten Protokollen und nutzen dabei die üblichen Internettechnologien zum Datenaustausch. [...]

43 44 45 46

Mattern 2003, S. 1. Fleisch et al. 2003, S. 13. Vgl. Mattern 2003, S. 2-3. XML steht für " Extensible Markup Language".

26

2 Von EDI zu IDI – ein Paradigmenwechsel Über Web-Services können heterogene Softwaresysteme innerhalb und außerhalb der Unternehmen miteinander kommunizieren."47

Die Nutzung von Web Services erfordert in vielen Fällen den Austausch von Geschäftsdaten. Zwar existieren bereits einige Standards, die eine grundlegende Infrastruktur für Web Services bereitstellen. Zu nennen sind hier insb. ƒ das "Simple Object Access Protocol" (SOAP) für den Versand entfernter Prozeduraufrufe48, ƒ die "Web Service Description Language" (WSDL) zur Beschreibung der angebotenen Web Services49 sowie ƒ die "Universal Description, Discovery and Integration" (UDDI) als Verzeichnisdienst für Web Services.50 Allerdings lässt sich mit der bestehenden Infrastruktur die ursprüngliche Vision einer völlig automatisierten Identifizierung, Kombination und Ausführung von Web Services nicht umsetzen.51 Während zwar mit OWL-S (Web Ontology Language for Web Services) und WSMO (Web Service Modelling Ontology)52 bereits an Standards für die semantische Beschreibung der technischen Infrastruktur von Web Services gearbeitet wird, ist bislang nicht ersichtlich, mit welchem Ansatz sich Heterogenität auf Ebene der zu transportierenden Geschäftsdaten überwinden lassen könnte.53 Die Verwendung klassischer EDI-Technologie erscheint aufgrund der mit Web Services verbundenen Automatisierungsvision nicht sinnvoll.

47 48 49 50 51 52 53

Küster 2003, S. 5-6. Vgl. Gudgin et al. 2007. Vgl. Chinnici et al. 2007. Vgl. Clement et al. 2004. Vgl. Stollberg 2007. Vgl. Roman et al. 2005. Vgl. Bijlsma 2002, S. 15.

2.5 Notationshinweise

27

2.5 Notationshinweise Es seien nun an dieser Stelle einige Notationshinweise für den formalen Teil der Arbeit gegeben. Inhaltliche Erläuterungen sind nicht Gegenstand dieses Abschnitts. Alle formalen Ausdrücke werden in Kursivschrift notiert. Dabei werden vier Kategorien von formalen Ausdrücken unterschieden: Formeln, Axiome, Randbedingungen und Definitionen. Für jede dieser Kategorien wurde ein eigenes Verzeichnis angelegt. ƒ Unter einer Formel wird in dieser Arbeit ein Ausdruck zur Darstellung mathematischer oder logischer Zusammenhänge verstanden. Kennzeichnend für Formelausdrücke ist die Verwendung des Gleichheitszeichens ( ). ƒ Unter einem Axiom wird ein unbewiesener Ausdruck verstanden, der wahr oder falsch sein kann. Axiome enthalten in dieser Arbeit das Axiomen-Definitionszeichen (  ), das Äquivalenzzeichen ( { ), das Inäquivalenzzeichen ( { ) oder das Inklusionszeichen ( ‹ ).54 ƒ Konsistenzbedingungen stellen wahrheitsfunktionale Ausdrücke dar, die zur Sicherstellung der ontologischen Konsistenz erfüllt sein müssen. Alle Konsistenzbedingungen in IDI-Ontologien sind Quantorenausdrücke und enthalten mindestens einen Existenzquantor (  ) oder Allquantor (  ). ƒ Schließlich seien noch Mengendefinitionen genannt. Als MengenDefinitionszeichen wird in dieser Arbeit die Zeichenkette " : " eingesetzt. Für die Bildung ontologischer Ausdrücke sind drei Konstruktoren von Bedeutung: Rollen55, Konzeptklassen56 und Individuen57. Die abstraktes-

54 55

56

Vgl. Abschnitt 3.4.4. Synonym zum Begriff "Rolle" wird im weiteren Verlauf der Arbeit auch der Begriff "Beziehung" verwendet. Synonym zum Begriff "Konzeptklasse" werden im weiteren Verlauf der Arbeit auch die Begriffe "Klasse" und "Konzept" verwendet.

28

2 Von EDI zu IDI – ein Paradigmenwechsel

te, nicht mehr weiter zu verallgemeinernde Rolle wird in der Literatur zu Beschreibungslogiken meistens mit " R " angegeben, die abstrakteste Konzeptklasse mit " C ". Individuen stellen Instanzen von Konzeptklassen dar. Sie werden, beginnend mit einem Großbuchstaben, in geschweiften Klammern notiert (z.B. ^Lutz Lustig GmbH` ). Spezialisierungen der Rolle R sollen mit einem Kleinbuchstaben beginnen und mit einem tiefgestellten Index enden. Dabei werden drei Rollenkategorien unterschieden: ƒ Attributrollen erhalten den Index "A"; Beispiel: farbeA .58 ƒ Konkrete Rollen erhalten den Index "T"; Beispiel: ladegewichtT .59 ƒ Sonstige Rollen erhalten den Index "R"; Beispiel: hatKompR Spezialisierungen der Konzeptklasse C sollen mit einem Großbuchstaben beginnen. Hierbei lassen sich zwei Kategorien unterscheiden: ƒ Konzeptklassen, die für die öffentliche Ontologie, d.h. die sog. "GBox", definiert wurden, erhalten den Hochindex "IDI"; Beispiel: Datenfeld IDI . ƒ Alle anderen Konzeptklassen erhalten als Hochindex das Kürzel der privaten Ontologie, in der sie definiert wurden. Das dieser Arbeit zugrunde liegende Anwendungsumfeld ist durch die Dualität von Sender und Empfänger von Nachrichten gekennzeichnet. Diese Dualität offenbart sich auch in der ontologischen Struktur: Gegenstand des ontologischen Matchings sind Ontologien bzw. Ontologieausschnitte des Senders und des Empfängers. Senderontologien werden in dieser Arbeit durch die drei Großbuchstaben KME, Empfängerontologien durch die Großbuchstaben KLO bezeichnet. Konzeptklassen, die Bestandteil einer der beiden Ontologien sind, werden durch die gleichen

57

58 59

Synonym zum Begriff "Individuum" wird im weiteren Verlauf der Arbeit auch der Begriff "Instanz" verwendet. Vgl. Abschnitt 4.3.3.4. Konkrete Rollen werden in sog. "Konkreten Domänen" eingesetzt. Vgl. Abschnitt 3.4.3.4.

2.5 Notationshinweise

29

drei Buchstaben gekennzeichnet, allerdings wird lediglich der erste Buchstabe großgeschrieben. Konzeptklassen können in formalen Darstellungen außerdem noch über einen Index verfügen. Als Beispiele seien die Konzeptklassen Klo , Klo1 , Kme oder Kme15 genannt. Die Mächtigkeit von Mengen wird durch das Zeichen # angegeben. Die Mächtigkeit einer Menge M bspw. wird also durch den Term # M notiert.

3 Ontologiearchitektur und -sprache 3.1 Forschungsfragen und Kapitelaufbau Zielsetzung dieses Kapitels ist in einem ersten Schritt die Identifikation und Evaluation potenzieller Ontologiearchitekturen und -sprachen. In einem zweiten Schritt sollen die Repräsentationsinhalte dargestellt werden, die die IDI-Agenten zur Erfüllung ihrer Aufgaben benötigen. Schließlich wird in einem letzten Schritt auf Basis der gewählten Ontologiesprache ein Vokabular definiert, das zur Spezifikation des erforderlichen Syntax-, Semantik-, Pragmatik- und Protokollwissens verwendet werden muss. Abschnitt 3.2 enthält eine Einführung zum Thema "ontologische Wissensrepräsentation". Dabei werden auch grundlegende konzeptionelle Strukturelemente von Ontologien und mögliche Architekturvarianten vorgestellt. In Abschnitt 3.3 wird die Forschungsfrage nach der geeigneten ontologischen Architektur für IDI-Agenten beantwortet. Abschnitt 3.4 geht der Forschungsfrage nach, welche formale Repräsentationssprache für die IDI-Architektur geeignet ist. Es werden zunächst die Grundlagen logikbasierter Repräsentationssprachen erläutert. Darauf folgt eine Beschreibung der Konstruktoren und Axiome der zur Realisierung dieses Forschungsvorhabens ausgewählten Repräsentationssprache + '!&().

A. Köhler, Intelligent Data Interchange (IDI), DOI 10.1007/978-3-8348-9767-1_3, © Vieweg+Teubner Verlag |Springer Fachmedien Wiesbaden GmbH 2010

32

3 Ontologiearchitektur und -sprache

3.2 Grundlagen der ontologischen Wissensrepräsentation 3.2.1 Wissen und Wissensrepräsentation – Begriffsklärung Das Forschungsgebiet "Wissensrepräsentation" (WR) befasst sich mit Fragen der formalen Darstellung, Pflege und Manipulation von Wissen in einem Problemlösungsprozess.60 Eine wichtige Aufgabe von repräsentiertem Wissen besteht darin, als Basis zur Ableitung neuen Wissens zu dienen. Die Notwendigkeit zur Wissensrepräsentation ergibt sich aus dem metaphysischen Postulat der Künstlichen Intelligenz (KI), wonach ein intelligentes System eine Repräsentation der Welt besitzen muss.61 Davis bezeichnet repräsentiertes Wissen als Surrogat für die eigentlichen Objekte der Realität.62 Der Surrogat-Charakter entsteht, da Elemente einer WR korrespondierende materielle oder immaterielle Elemente der Realität symbolisieren.63 Operationen werden somit auf den Symbolen vollzogen, nicht auf den Objekten der Realität. Eine WR lässt sich daher auch als abstraktes Modell einer relevanten Domäne betrachten. Die mit der WR einhergehende Symbolisierung und Formalisierung von Wissen ist eine Voraussetzung für seine maschinelle Verarbeitbarkeit. Das Analyse- und Manipulationsobjekt der Wissensrepräsentation stellt das sog. "Wissen" dar. Wissen entsteht "durch Vernetzung von Informationen mit dem Kontext".64 Dabei liefert Wissen die "[...] Menge an Informationen [...], die ein Mensch (oder eine Maschine) benötigt und die so organisiert ist, dass sie zur Bearbeitung komplexer Aufgaben verwendet werden kann."65

60 61 62 63 64 65

Vgl. Lakemeyer, Nebel 1994, S. 1. Vgl. Schefe 1986, S. 12. Vgl. Davis et al. 1993, S. 17. Vgl. Brachman, Levesque 2004, S. 3-4; Schefe 1986, S. 157. Hasenkamp, Roßbach 1998, S. 957. Ferber 2001, S. 256.

3.2 Grundlagen der ontologischen Wissensrepräsentation

33

Vom Wissensbegriff abzugrenzen sind die Begriffe "Daten" und "Informationen". Daten bestehen aus Zeichen oder Zeichenfolgen. Dabei spielt es keine Rolle, welches Medium zur Speicherung oder Übermittlung der Daten verwendet wird.66 Kennzeichnend für die Datenebene ist, dass hier keine Aussage über die Bedeutung eines Zeichens oder einer Zeichenfolge gemacht werden kann. Hennings versteht unter Daten "alles das, was sich auf einer DV-Anlage geeignet kodiert erfassen, speichern, bearbeiten, übertragen und wieder ausgeben lässt."67 Informationen ergänzen Daten um einen Kontext, einen Bedeutungszusammenhang: "Daten werden zu Informationen, indem sie in einen Problemzusammenhang gestellt und zum Erreichen eines Ziels verwendet werden."68 Wissen lässt sich in explizites und implizites Wissen unterteilen. Unter explizitem Wissen wird Wissen verstanden, das speicherbar und für Dritte zugänglich ist. Implizites Wissen hingegen ist an seinen Wissensträger gebunden und nur durch diesen nutzbar.69 Die Speicherung von formalisiertem Wissen ermöglicht den maschinellen Zugang zu diesem Wissen. Formalisierung bedeutet, Wissen in der Syntax einer bestimmten Repräsentationssprache darzustellen. Repräsentationssprachen verfügen meistens über eine vordefinierte Semantik ihrer Konstruktoren. Gegenstand der Wissensrepräsentation in der IDI-Architektur ist die Repräsentation desjenigen Wissens, das zur Interpretation von Syntax, Semantik und Pragmatik von Geschäftsdaten sowie Protokollen erforderlich ist. Dieses Wissen wird heute bereits in Form sog. "EDIImplementierungsvereinbarungen" informal spezifiziert. Implementierungsvereinbarungen werden vertraglich zwischen den beteiligten

66 67 68 69

Vgl. Alpar et al. 2008, S. 8. Hennings 1991, S. 5. Bullinger et al. 1997, S. 7. Vgl. Hasenkamp, Rossbach 1998, S. 957.

34

3 Ontologiearchitektur und -sprache

Kommunikationspartnern vereinbart und regeln technische, fachliche und rechtliche Details des Geschäftsdatenaustausches.

3.2.2 Ontologien als Wissensspeicher 3.2.2.1 Definitionen und Begriffsklärung Ontologien beinhalten konzeptionelle Modelle von Ausschnitten der realen Welt. Modellierungsprimitiva von Ontologien sind Konzepte bzw. Konzeptklassen, Konzeptbeziehungen, Individuen und Axiome.70 Zielsetzung von Ontologien ist es, die für eine bestimmte Anwendungssituation relevanten Konzepte und Eigenschaften explizit und formalsprachlich darzustellen.71 Insbesondere für die Kommunikation zwischen intelligenten Agenten sind Ontologien von Bedeutung, da sie Wissen über den für die Aufgabenerfüllung des Agenten relevanten Weltausschnitt bereitstellen können.72 Ontologien können somit zu einem gemeinsamen Verständnis eines Anwendungsbereiches beitragen73. Ontologien sind von sog. Wissensbasen zu unterscheiden; eine Ontologie kann als Spezialfall einer Wissensbasis betrachtet werden. Der allgemeinere Begriff "Wissensbasis" bezeichnet eine Menge von Aussagen zu einem bestimmten Ausschnitt der Realität sowie eine Menge von Inferenzmethoden, mit deren Hilfe aus den vorhandenen Aussagen zusätzliches Wissen abgeleitet werden kann.74 Im Unterschied zu Wissensbasen speichern Ontologien Wissen in kategorialer Form. Kategoriales Wissen enthält Merkmale von Erfahrungsklassen.75 Ontologien verfügen also (auch) über zustandsunabhängiges

70

71 72 73 74 75

Vgl. Hesse 2002, S. 477; Rebstock et al. 2008, S. 98. Eine detaillierte Beschreibung der genannten Modellierungsprimitiva findet sich im folgenden Absatz. Vgl. Uschold, Gruninger 1996, S. 5-6; Zelewski et al. 2001, S. 187. Vgl. Stuckenschmidt, Timm 2002, S. 6. Vgl. Horrocks et al. 2000. Vgl. Shapiro 1998, S. 1. Vgl. Anderson 2001, S. 153.

3.2 Grundlagen der ontologischen Wissensrepräsentation

35

Wissen, während allgemeine Wissensbasen ausschließlich zustandsabhängiges Wissen speichern.76 Der Unterschied zwischen zustandsabhängigem und zustandsunabhängigem Wissen sei an zwei Beispielen verdeutlicht. Als erstes Beispiel dient das Objekt "Fuhrunternehmen". Dieses Objekt repräsentiert eine Menge von Realweltgegenständen (nämlich die Menge der Fuhrunternehmen) und ihre gemeinsamen Eigenschaften. Das zweite Beispiel besteht aus dem Individuum "Lutz Lustig GmbH" und seinen Eigenschaften. Das erste Beispiel repräsentiert zustandsunabhängiges Wissen, weil Fuhrunternehmen immer eine definierte Menge gemeinsamer Eigenschaften besitzen. Das zweite Beispiel hingegen beinhaltet zustandsabhängiges Wissen, weil Eigenschaften der Lutz Lustig GmbH nur im Kontext dieser Firma gültig sind. Gruber betont bei seiner Definition des Ontologiebegriffs die Aspekte der Explikation und Konzeptualisierung: "An ontology is an explicit specification of a conceptualization."77 Explikation bedeutet, Wissen für beliebige menschliche oder maschinelle Aufgabenträger sichtbar und verarbeitbar zu machen. Konzeptualisierungen sind erforderlich, um die Komplexität der Realität auf das für den jeweiligen Erkenntnis- bzw. Einsatzzwecke sinnvolle Maß zu reduzieren. Konzeptualisierungen stellen also Abstraktionen der realen Welt dar. Guarino definiert: "An ontology is a logical theory accounting for the intended meaning of a formal vocabulary, i.e. its ontological commitment to a particular conceptualization of the world. The intended models of a logical language using such a vocabulary are constrained by its ontological commitment."78

76 77 78

Vgl. Guarino 1998, S. 8. Gruber 1993, S. 1. Guarino 1998, S. 5.

36

3 Ontologiearchitektur und -sprache

Ein anderes Ontologieverständnis formulieren van Heijst et al. Danach beschreiben Ontologien die Struktur und das Vokabular von statischem Domänenwissen. Das Domänenwissen seinerseits umfasst eine Menge von Aussagen über die Domäne.79 Ontologien selbst wären also nach diesem Verständnis kein Repräsentationsbestandteil. Sie stellten eher eine Metaebene von Wissensrepräsentationen dar.80 Nach diesem Ontologieverständnis ähnelt der Zweck von Ontologien dem von Metamodellen. Sie definieren ein für die Modellbildung erforderliches Begriffssystem (Vokabular) und legen die erforderlichen Modellbestandteile sowie deren Beziehungen untereinander fest.81 Allerdings erfolgt die Spezifikation der Repräsentationsinhalte bei Ontologien ausschließlich formalsprachlich, während Metamodelle auch eine natürlichsprachliche Spezifikation zulassen.82 Ein weiterer Unterschied betrifft die nutzbaren Spezifikationsmittel. Metamodelle sind auf die Spezifikation des Termvorrats sowie der Syntax beschränkt, während Ontologien auch semantische Spezifikationsmittel verwenden.83 Dabei handelt es sich allerdings um eine ausschließlich repräsentationale Semantik, während beispielsweise Referenzmodelle eine normative Semantik besitzen.84 Ontologien lassen sich in unterschiedliche Kategorien einteilen. Eine Möglichkeit der Kategorisierung besteht in der Unterscheidung verschiedener Einsatzzwecke. Während bspw. sog. Domäne-Ontologien Wissen über einen definierten, abgegrenzten Anwendungsbereich repräsentieren, definieren Meta-Ontologien Begriffssysteme (Vokabulare) und Strukturen zur Spezifikation von Domäne-Ontologien. Generische Ontologien fokussieren auf die Definition von allgemeinem Basiswissen wie Raum, Zeit, Ereignisse etc. Aufgabenontologien stellen Begriffe für

79 80 81 82 83 84

Vgl. van Heijst et al. 1997, S. 186. Vgl. van Heijst et al. 1997, S. 191. Vgl. Schulze 2001, S. 1; Sinz 1996, S. 126. Vgl. Zelewski et al. 2001, S. 191. Vgl. Zelewski et al. 2001, S. 191. Vgl. Zelewski et al. 2001, S. 194.

3.2 Grundlagen der ontologischen Wissensrepräsentation

37

spezifische Aufgaben bereit. Methodenontologien definieren Problemlösungsmethoden.85 Eine weitere, für diese Arbeit bedeutsame Typisierung von Ontologien betrifft die Unterscheidung von privaten und öffentlichen Ontologien.86 Öffentliche Ontologien stehen einem unbeschränkten, private Ontologien nur einem eingeschränkten Nutzerkreis zur Verfügung. Stuckenschmidt und Timm vertreten die Ansicht, dass die Nutzung einer gemeinsamen Ontologie Grundlage für jegliche sinnvolle Kollaboration zwischen Agenten darstellt.87 Dieser Arbeit liegt ein weit gefasstes Ontologieverständnis zugrunde. Danach enthalten Ontologien sowohl ein Begriffssystem bzw. ein Vokabular als auch das mit diesem Begriffssystem formulierte Domänenwissen. Begrifflich werden beide Ebenen durch die Zeichenketten „GBox“ und „LBox“ unterschieden. Eine detaillierte Beschreibung hierzu ist in Kapitel 3.3 zu finden. 3.2.2.2 Modellierungsprimitiva In der vorangegangenen Definition des Ontologiebegriffs wurden bereits die in Ontologien zur Verwendung kommenden Modellierungsprimitiva aufgezählt. Dieser Abschnitt definiert die einzelnen Primitiva und erläutert, welche Rolle sie in Ontologien spielen können. Als Konzept soll in dieser Arbeit ein abstraktes, eindeutig abgrenzbares und durch seine Eigenschaften beschreibbares Phänomen der Realität bezeichnet werden. Phänomene der Realität können stoffliche Objekte, aber auch gedankliche Konstrukte darstellen. Auf der Konzeptebene werden nicht Objekte der Realität betrachtet, sondern Klassen von Ob-

85

86 87

Für einen Überblick über Typisierungen und Einsatzzwecke von Ontologien vgl. Ahlemann et al. 2006, S.7-8; Guarino 1998, S. 7-8; Fensel 2000, S. 8-9; Puppe et al. 2000, S. 622-623; van Heijst et al. 1997, S. 192-193. Vgl. Uschold 2000, S. 2. Vgl. Stuckenschmidt, Timm 2002, S. 6-7.

38

3 Ontologiearchitektur und -sprache

jekten. Daher werden Konzepte im weiteren Verlauf der Arbeit auch als Konzeptklassen oder Klassen bezeichnet. 88 Konzepte können sowohl intensional wie auch extensional definiert werden. Die Extension bezeichnet die Menge aller Individuen, die zu der Konzeptklasse gehören. Die Intension umfasst die Menge aller Eigenschaften, über die ein Individuum verfügen muss, um zu der Konzeptklasse zu gehören.89 Extensionale Konzeptdefinitionen beruhen somit auf einer Aufzählung der Konzeptindividuen, intensionale Definitionen auf einer Aufzählung der Konzepteigenschaften.

Konzeptklasse

Intension

Extension

Menge aller Eigenschaften einer Konzeptklasse

Menge aller Individuen einer Konzeptklasse

Abbildung 4: Intension und Extension von Konzeptklassen

Rollen repräsentieren semantische Beziehung zwischen zwei Konzepten. Semantische Beziehungen gelten somit für alle Individuen der verbundenen Konzepte. Im Gegensatz zu Konzepten stellen Individuen konkrete physische oder gedankliche Objekte der realen Welt dar. Zwar können auch zwischen Individuen Beziehungen bestehen und in einer Ontologie dargestellt werden. Allerdings berühren diese Beziehungen ausschließlich die verbundenen Individuen, während Beziehungen zwischen Konzepten für alle Individuen gelten, die zu den durch die Beziehungen verbundenen Konzepten gehören.

88 89

Vgl. Reimer 1991, S. 18. Vgl. Wolff 1993, S. 3; Reimer 1991, S. 16-17.

3.2 Grundlagen der ontologischen Wissensrepräsentation

39

Axiome sind Sätze, die aufgrund ihrer Evidenz oder ihrer Glaubwürdigkeit nicht begründet werden müssen. Dabei kann innerhalb eines Axiomensystems kein Axiom aus einem anderen logisch hergeleitet werden. Außerdem darf kein Axiom einem anderen widersprechen. Axiome können auch Definitionen repräsentieren. So werden bspw. in Axiomensystemen, die auf Beschreibungslogiken basieren, Rollen oder Konzepte durch andere Rollen und Konzepte definiert. Bei der Interpretation eines Axiomensystems werden allen Sätzen Wahrheitswerte zugewiesen.90 IDI-Ontologien basieren auf einem axiomatischen Modellverständnis. In axiomatischen Modellen werden Fakten und Zusammenhänge der betreffenden Anwendungsdomäne in einem Axiomensystem formuliert. Axiomensysteme bestehen aus einer Menge von Axiomen und ggf. Schlussfolgerungsregeln.91 In IDI-Ontologien dienen Axiome der formalen Definition von Fakten über die durch einen IDI-Agenten zu versendenden oder zu empfangenden Geschäftsnachrichten. Bei der Modellbildung werden diese Axiome in Bezug auf einen bestimmten Realweltausschnitt bzw. eine bestimmte Anwendungsdomäne interpretiert. Bei dieser Interpretation wird jedem Axiom ein Wahrheitswert zugewiesen. Ein Axiomensystem stellt dann ein axiomatisches Modell dar, wenn alle seine Axiome für den betrachteten Realweltausschnitt wahr sind.92 Ein Vorteil der Axiomatisierung besteht darin, Axiomensysteme für das automatisierte Schließen nutzen zu können. Denn Axiome "[...] bieten die grundlegende faktische Information, aus der sinnvolle Schlüsse gezogen werden können."93 Zudem eignen sich Axiomensysteme zur Formulierung von Konsistenzbedingungen. Realweltkonstellationen können nur dann Modelle eines bestimmten Axiomensystems sein, wenn sie die axiomatisch definierten Konsistenzbedingungen erfüllen.

90 91 92 93

Vgl. Schulze 2001, S. 16-18. Vgl. Spies 2004, S. 64. Vgl. Thomas 2005, S. 11-12; Becker, Pfeiffer 2006, S. 1552. Russel, Norvig 2004, S. 320.

40

3 Ontologiearchitektur und -sprache

Eine detaillierte Beschreibung der zur Formulierung des IDI-Vokabulars verwendeten formalen Sprache im Allgemeinen sowie der Konstruktoren und Axiome im Speziellen ist in Kapitel 3.4 zu finden.

3.3 Ontologiestruktur der IDI-Architektur 3.3.1 Öffentliche vs. private Ontologien: Evaluation möglicher Architekturvarianten Fraglich ist, ob IDI-Agenten auf öffentliche oder private Ontologien zugreifen sollen. Denkbar wäre auch eine Hybridarchitektur, die eine Mischung von öffentlichen und privaten Ontologien vorsieht. Würden IDI-Agenten ausschließlich eine öffentliche Ontologie nutzen, so müsste diese öffentliche Ontologie sowohl über das Vokabular wie auch das erforderliche Domänenwissen verfügen. Das Domänenwissen müsste sämtliche Konzepte beinhalten, die von der Gesamtheit aller IDIAgenten zur Spezifikation von Syntax, Semantik, Pragmatik und Interaktionsprotokollen benötigt würde. So könnte bspw. ein bestimmtes Syntaxformat nur dann genutzt werden, wenn ein entsprechendes Konzept in der öffentlichen Ontologie vorhanden wäre. Zwar weist die soeben beschriebene Architekturvariante den höchsten Interoperabilitätsgrad auf. Durch die Nutzung einer gemeinsamen, öffentlichen Ontologie könnten potenzielle Heterogenitätskonflikte faktisch eliminiert werden. Der so gewonnene Vorteil wird jedoch durch einige schwerwiegende Nachteile erkauft. ƒ Die Pflege und Weiterentwicklung einer solchen zentralen Ontologie wäre mit einem erheblichen Aufwand verbunden. ƒ Der Prozess der Weiterentwicklung einer öffentlichen Ontologie dürfte sich aufgrund der Vielzahl von Abstimmungs- und Interessenpartnern entsprechend langwierig gestalten. Hierdurch würde die Fähigkeit der Marktakteure reduziert, flexibel auf neue Anforderungen reagieren zu können. Diese Erfahrung wurde bereits bei bestehenden EDI-Standards gemacht. Private Ontologien sind in der Lage, exakt die Anforderungen der jeweiligen Anwender abzudecken. Sie erlauben eine unmittelbare Anpassung

3.3 Ontologiestruktur der IDI-Architektur

41

an sich ändernde Markterfordernisse, da sowohl das Vokabular wie auch das Domänenwissen lokal definiert werden. Allerdings wird diese Flexibilität mit einer mangelnden Interoperabilität zwischen den einzelnen privaten Ontologien erkauft.94 Würde jeder IDI-Agent ein proprietäres Vokabular nutzen, wäre eine Kommunikation zwischen IDI-Agenten nur mithilfe aufwendiger, manuell durchzuführender Mappings möglich. Beide Ansätze sind nicht in der Lage, die einleitend formulierten Anforderungen an eine IDI-Architektur zu erfüllen. Somit kommt nur eine Hybridarchitektur infrage. Die Idee einer solchen Hybridlösung besteht darin, ein für alle IDI-Agenten gültiges Vokabular in einer öffentlichen Ontologie bereitzustellen. Die Formulierung des jeweiligen Domänenwissens erfolgt hingegen auf lokaler Ebene in privaten Ontologien, auf die im Regelfall nur ein IDI-Agent Zugriff besitzt.95 Zwar erfordert auch diese Architekturvariante ein Matching zwischen den einzelnen Domänenontologien. Es wird jedoch angenommen, dass aufgrund des gemeinsam genutzten Vokabulars dieses Matching – anders bei der ausschließlichen Verwendung privater Ontologien – automatisiert erfolgen kann. Der Nachweis für diese Annahme ist im weiteren Verlauf der Arbeit zu erbringen. Die IDI-Hybridarchitektur besteht aus einer öffentlichen (GBox) und einer Vielzahl an privaten Ontologien (LBoxen). Die öffentliche Ontologie stellt das Vokabular zur Verfügung, das zur Spezifikation der lokalen Ontologien verwendet werden muss. In privaten Ontologien wird mithilfe dieses Vokabulars Wissen über die Syntax, Semantik und Pragmatik unternehmensspezifischer Geschäftsnachrichten sowie über Interaktionsprotokolle formuliert.

94 95

Vgl. Wache et al. 2001, S. 2. Vgl. Wache et al. 2001, S. 3. Einen ähnlichen Ansatz verfolgen Stuckenschmidt und Timm (Stuckenschmidt, Timm 2002). Sie schlagen vor, Kernbereiche der Anwendungsdomäne in einer standardisierten, gemeinsam genutzten Ontologie bereitzustellen.

42

3 Ontologiearchitektur und -sprache

GBox (Vokabular)

LBox 1

LBox 2

LBox n

Domänenwissen Abbildung 5: IDI-Repräsentationsebenen

Die Begriffe "GBox" und "LBox" lehnen sich an die Terminologie der Literatur zu der in dieser Arbeit genutzten Beschreibungslogik + '!&() an. Dort werden meistens die beiden Bezeichnungen "TBox" und "ABox" verwendet.96 Die TBox entspricht dem Teil einer Ontologie, der zustandsunabhängiges Wissen speichert. Die ABox hingegen repräsentiert zustandsabhängiges Wissen. Zustandsabhängiges Wissen enthält Aussagen über Eigenschaften von Individuen (Rollenaussagen) oder Aussagen über die Zugehörigkeit von Individuen zu Klassen (Klassenaussagen).97 Der wesentliche Unterschied der IDI-Architektur zu anderen Ontologiearchitekturen besteht in der Aufspaltung des zustandsunabhängigen Wissens der TBox in einen global gültigen Vokabularteil (GBox, öffentliche Ontologie) und einen lokal gültigen Teil zur Spezifikation der unternehmensspezifischen Nachrichten (LBox, private Ontologie). ABoxen spielen in der IDI-Architektur keine Rolle.

96 97

Vgl. z.B. Nardi, Brachman 2002, S. 17-20. Vgl. z.B. Nardi, Brachman 2002, S. 19.

3.3 Ontologiestruktur der IDI-Architektur

43

3.3.2 Individuenkategorien Zur konzeptionellen Strukturierung der ontologischen Architektur bietet sich der Rückgriff auf die in Kapitel 2.3 identifizierten Gestaltungsebenen an: Syntax, Semantik, Pragmatik und Protokolle. Jede dieser Gestaltungsebene repräsentiert eine charakteristische Kategorie von Individuen. In IDI-Ontologien werden die folgenden Begriffe für die Individuenkategorien der einzelnen Gestaltungsebenen verwendet: ƒ Transportcontainer (Syntax), ƒ Geschäftsdateneinheiten (Semantik), ƒ Sendevorgänge (Pragmatik) und ƒ Protokolle. Transportcontainer wie z.B. Datenfelder fungieren als syntaktische Hüllen für Geschäftsdaten. Sie verfügen über bestimmte Syntaxeigenschaften und ermöglichen somit die Identifizierung und Extraktion der enthaltenen Geschäftsdaten. Allerdings besitzen Transportcontainer keine eigene Bedeutung. Geschäftsdateneinheiten stellen die eigentliche Nutzlast einer Nachricht dar. Sie repräsentieren die kleinsten, Bedeutung tragenden Teile eines Geschäftsdatenstroms. Einzelne Geschäftsdateneinheiten werden in Datenfeldern transportiert. Die unten stehende Abbildung zeigt den Unterschied zwischen einem Transportcontainer und einer Geschäftsdateneinheit. In der Abbildung ist das Beispiel eines XML-basierten Datenfelds zu sehen. Die Start- und Endemarkierungen ("Tags") repräsentieren den Transportcontainer. Die Zeichenkette zwischen den beiden Markierungen stellt die Geschäftsdateneinheit dar.

44

3 Ontologiearchitektur und -sprache

Geschäftsdateneinheit 12.08.2009

Transportcontainer Abbildung 6: Beispiel für eine Geschäftsdateneinheit mit ihrem Transportcontainer

Die Trennung zwischen Transportcontainer und Geschäftsdateneinheiten erscheint sinnvoll, da bestimmte Geschäftsinhalte in unterschiedlichen Transportcontainern mit verschiedenartigen Eigenschaften transportiert werden und Transportcontainer unterschiedliche Geschäftsinhalte transportieren können. Sendevorgänge repräsentieren die mit einer Nachricht verknüpfte Handlungsabsicht. Protokolle dienen der Spezifikation von Abfolgen fachlich zusammengehörender Geschäftsnachrichten. Protokolle sollen es zudem ermöglichen, Regeln bzw. Randbedingungen für die Gültigkeit von Nachrichtensequenzen festzulegen. Für jede Individuenkategorie soll in der öffentlichen Ontologie eine nicht verallgemeinerbare Referenzkonzeptklasse definiert werden. Spezialisierungen dieser Referenzkonzeptklassen sollen in den einzelnen LBoxen als Anknüpfungspunkte zur Formulierung von Syntax-, Semantik-, Pragmatik- sowie Protokolleigenschaften dienen.

3.3.3 GBox Die GBox stellt eine für die IDI-Architektur entwickelte Ontologieebene dar und entspricht der bereits beschriebenen öffentlichen Ontologie. Hier werden die konzeptionelle Struktur sowie das Vokabular für die privaten Ontologien festgelegt. Die Spezifikation des Vokabulars orien-

3.3 Ontologiestruktur der IDI-Architektur

45

tiert sich an den in Kapitel 2.3 identifizierten Gestaltungsebenen. Benötigt wird also ƒ ein Vokabular zur Spezifikation von Syntaxeigenschaften, ƒ ein Vokabular zur Bedeutungsdefinition von Geschäftsinhalten, ƒ ein Vokabular zur Spezifikation von Handlungsabsichten sowie ƒ ein Vokabular zur Spezifikation von Interaktionsprotokollen. Die genannten Vokabulare werden in der GBox axiomatisch definiert. Axiome der GBox sind allgemeiner bzw. kategorialer Art, ihre Wahrheitswerte lassen sich unabhängig von einem bestimmten Kontext festlegen.98 Das Vokabular der GBox ist zur Formulierung des privaten LBoxWissens99 zwingend zu verwenden. In der GBox sollen zwei Arten von Axiomen unterschieden werden: Definitionen zur Spezifikation von Konzepten und Rollen sowie Randbedingungen für die konsistente Verwendung dieser Konzepte und Rollen. Die in der GBox spezifizierten Konsistenz- bzw. Randbedingungen dürfen in keiner LBox verletzt werden. Als Randbedingung könnte bspw. festgelegt werden, dass eine bestimmte Beziehung nur zwischen den Individuenmengen zweier bestimmter Konzeptklassen definiert werden darf. Der Spezifikation eines Syntaxvokabulars liegt die Annahme zugrunde, dass es möglich ist, ein Vokabular zu definieren, mit dem sich die Syntax beliebiger Geschäftsdatenformate beschreiben lässt.100 Die Konzepte und Rollen dieses Syntaxvokabulars sollen in der GBox spezifiziert werden und stehen dann allen Unternehmen zur Beschreibung ihrer spezifischen Syntaxformate zur Verfügung. Anders hingegen bei der Spezifikation des Semantikvokabulars: hier können in der GBox keine Konzepte vordefiniert werden. Eine solche Vorgabe würde voraussetzen, dass die spezifizierende Institution Kenn-

98 99 100

Vgl. Russel, Norvig 2004, S. 400. Die Beschreibung der LBox erfolgt im nächsten Unterkapitel. Die Spezifikation dieses Syntaxvokabulars erfolgt in Abschnitt 4.2.

46

3 Ontologiearchitektur und -sprache

nis über alle global benötigten Inhalte von Geschäftsnachrichten besäße. Allerdings ist eine solche Annahme nicht als realistisch zu betrachten. Darüber hinaus wäre die Erstellung und Pflege einer derartigen zentralen Ontologie mit einem erheblichen Aufwand verbunden. Hingegen erscheint es sinnvoll, die Bedeutung wiederkehrender Konzepte (Beispiel: Konzept "Datum") in der GBox festzulegen. Somit muss bspw. auf privater Ebene lediglich eine Spezialisierung des öffentlichen Konzepts "Datum" vorgenommen werden. Es wird vorgeschlagen, die Konzeptbedeutung durch die Definition semantischer Beziehungen zu anderen Konzepten zu spezifizieren. Somit besteht das Semantikvokabular vor allem aus Rollen.101 Das Pragmatikvokabular dient der Spezifikation der mit einer Nachricht verbundenen Handlungsabsicht. Die für den elektronischen Geschäftsdatenaustausch relevanten Handlungsabsichten werden in der GBox definiert.102 Das Protokollvokabular soll es ermöglichen, Sequenzen von Geschäftsnachrichten zu definieren. Für diese Sequenzen sollen auch Randbedingungen formuliert werden können.103 Einen bedeutsamen Einfluss auf die Entwicklung des Protokollvokabulars hat die Frage, wie der Prozess zur Protokollvereinbarung zwischen IDI-Agenten gestaltet sein soll.104

3.3.4 LBox LBoxen sind private Ontologien, die nur jeweils einem IDI-Agenten zugänglich sind. Sie enthalten das Wissen über die für einzelne IDIAgenten relevanten Protokolle, Sendevorgänge, Geschäftsdateneinheiten

101 102 103 104

Zur Darstellung des Semantikvokabulars vgl. Abschnitt 4.3. Zur Darstellung des Pragmatikvokabulars vgl. Abschnitt 4.4.1. Zur Darstellung des Protokollvokabulars vgl. Abschnitt 4.4.2. Zur Darstellung des Metaprotokolls zur Protokollvereinbarung vgl. Abschnitt 4.4.3.

3.3 Ontologiestruktur der IDI-Architektur

47

und Transportcontainer. Wie die GBox ist auch die LBox eine IDIspezifische Ontologieebene. Jedes Individuum der im vorangegangenen Abschnitt genannten Individuenkategorien soll in der LBox durch genau eine Konzeptklasse spezifiziert werden. Um die Repräsentationsebene begrifflich von der Ebene der Individuen trennen zu können, erhalten die in den einzelnen LBoxen zu spezifizierenden Referenzkonzepte eine zur Individuenebene abweichende Bezeichnung: ƒ Spezialisierungen der Referenzkonzeptklasse "Strukturelement" repräsentieren einzelne Transportcontainer und ihre Eigenschaften; ƒ Spezialisierungen der Referenzkonzeptklasse "Bedeutungseinheit" repräsentieren einzelne Geschäftsdateneinheiten und ihre Eigenschaften; ƒ Spezialisierungen der Referenzkonzeptklasse "Sendung" repräsentieren einzelne Sendevorgänge und ihre Eigenschaften; ƒ Spezialisierungen der Referenzkonzeptklasse "Sequenz" repräsentieren einzelne Protokolle und ihre Eigenschaften.105 Die Spezialisierungen der jeweiligen Referenzkonzeptklassen erfolgen unter Verwendung des in der GBox definierten Vokabulars. Dabei erbt jede spezialisierte Konzeptklasse die in der GBox formulierten Eigenschaften ihrer Referenzkonzeptklasse. Bei den Bedeutungseinheiten sind atomare und zusammengesetzte Bedeutungseinheiten zu unterscheiden. Atomare Bedeutungseinheiten lassen sich nicht in kleinere, Bedeutung tragende Einheiten unterteilen. Zusammengesetzte Bedeutungseinheiten hingegen können aus atomaren oder anderen zusammengesetzten Bedeutungseinheiten bestehen. Ein Beispiel für eine atomare Bedeutungseinheit ist das Realweltphänomen "Bestellnummer", eine zusammengesetzte Bedeutungseinheit könnte das Realweltphänomen "Bestellung" darstellen. Jede Bedeutungseinheit wird in der LBox durch genau eine Konzeptklasse repräsentiert.

105

Einen Überblick verschafft Abbildung 7.

48

3 Ontologiearchitektur und -sprache

Die Spezifikation der Geschäftsdatenbedeutung beruht auf einer intensionalen Semantik. Die Bedeutung ergibt sich also aus den Eigenschaften, die einzelnen Bedeutungseinheiten über die in der GBox definierten Rollen zugewiesen werden. Da sich die oben dargestellte Schachtelbarkeit von Bedeutungseinheiten auch auf der Syntaxseite widerspiegeln muss, lassen sich unterschiedliche Strukturelementtypen unterscheiden. Beispiele für Strukturelementtypen sind etwa „Datenfeld“ oder „Datenfeldgruppe“. Auch wenn das Wissen der LBox lokal definiert wird, so handelt es sich trotzdem um generisches Wissen, das sich nicht auf ein bestimmtes Individuum, sondern eine Gruppe gleichartiger Individuen bezieht. Konzeptklassen von LBoxen repräsentieren also kategoriales Wissen.106 Dies sei anhand der oben beispielhaft genannten Bedeutungseinheiten erläutert. Enthält die LBox eine Konzeptklasse "Bestellnummer", so repräsentiert diese Konzeptklasse kein bestimmtes Individuum der Realität, also eine bestimmte Bestellnummer. Vielmehr repräsentiert diese Konzeptklasse eine Kategorie von Realweltphänomenen, die alle über die gleichen Eigenschaften verfügen. Gleiches gilt auch auf der Syntaxebene. Hier wird nicht ein bestimmter Transportcontainer beschrieben. Vielmehr spezifiziert jedes Strukturelement eine Gruppe von Transportcontainern, die alle über die gleichen Eigenschaften verfügen. Bei jedem Sendevorgang wird einer dieser Transportcontainer verwendet. Allerdings besitzen alle Transportcontainer eines Strukturelements das gleiche Aussehen. Im Gegensatz hierzu können unterschiedliche Geschäftsdateneinheiten ein unterschiedliches Aussehen besitzen, auch wenn sie Individuen der gleichen Bedeutungseinheit sind.

3.3.5 Zusammenfassende Bewertung Funktion und Inhalt der beiden Ontologieebenen "GBox" und "LBox" seien in dem folgenden Schaubild zusammengefasst.

106

Vgl. Russel, Norvig 2004, S. 400.

3.3 Ontologiestruktur der IDI-Architektur

GBox

LBox

49

Syntaxvokabular

Semantikvokabular

Pragmatikvokabular

Protokollvokabular

spezifiziert

spezifiziert

spezifiziert

spezifiziert

Strukturelemente

Bedeutungseinheiten

Sendungen

Sequenzen

repräsentieren

repräsentieren

repräsentieren

repräsentieren

Transportcontainer

transportieren

Geschäftsdateneinheiten

Sendevorgänge Protokolle

Individuen Abbildung 7: Funktionen und Inhalte von GBox und LBox

Der wesentliche Vorteil der vorgeschlagenen Architektur besteht darin, dass durch die Verwendung eines global gültigen Vokabulars verbindliche Repräsentationsprimitiva zur Beschreibung der Syntax- und Pragmatikeigenschaften von Geschäftsnachrichten sowie Protokolle zur Steuerung von Nachrichtensequenzen zur Verfügung stehen. Durch diese globale Gültigkeit des Vokabulars besitzen IDI-Agenten eine gemeinsame Interoperabilitätsbasis. Das Semantikvokabular besteht im Wesentlichen aus Rollen zur Spezifikation beliebiger Konzeptklassen. Darüber hinaus sollen auf der Semantikebene Referenzkonzepte sowie Rollen zur Spezialisierung dieser Referenzkonzepte vorgegeben werden. Welche Konzeptklassen in den privaten Ontologien spezifiziert werden, um unter Verwendung der vorgegebenen Rollen die einzelnen Bedeutungseinheiten semantisch zu definieren, obliegt den lokalen Ontologieentwicklern. Dies sei an einem Beispiel verdeutlicht.

50

3 Ontologiearchitektur und -sprache

Angenommen, in der GBox ist eine Rolle hatKompR definiert und diese Rolle sagt aus, dass ein bestimmtes Konzept ein anderes Konzept als Komponente besitzt. Die Rolle hatKompR könnte also verwendet werden, um das Konzept "Auto" semantisch zu spezifizieren, indem typische Komponenten eines Autos dargestellt werden. Welche Komponenten zum Einsatz kommen, legen die lokalen Ontologieentwickler fest. Diese Architekturentscheidung ermöglicht auf der einen Seite ein höchstmögliches Maß an Flexibilität. Auf der anderen Seite jedoch lässt sich das Heterogenitätsrisiko trotz der vorhandenen Interoperabilitätsbasis nicht völlig ausschalten. Betrachtet bspw. der eine Ontologieentwickler die Räder als wesentliche Komponenten eines Autos, ein anderer jedoch definiert die Komponenten "Motor" und "Karosserie", dann weisen diese Spezifikationen keine Übereinstimmung auf, obwohl semantisch äquivalente Konzepte spezifiziert wurden. Um einen möglichst hohen Automatisierungsgrad erreichen zu können, müssen von vorneherein Verfahren zur Identifizierung und Überwindung von Heterogenität vorgesehen werden. Die Definition grundlegender, häufig verwendeter Referenzkonzepte in der GBox vermeidet Redundanzen. Der Unterschied zu Architekturansätzen wie ebXML besteht darin, dass die Spezialisierung dieser grundlegenden Konzepte ausschließlich auf lokaler Ebene erfolgt. Hieraus resultiert eine hohe Flexibilität für die einzelnen Nutzer, da die privaten Ontologien beliebig erweitert werden können. Die Verwendung neuer Inhalte oder Prozesse ist damit nicht mehr abhängig von einer u.U. schwerfälligen, zentralen Standardisierungsinstitution.

3.4 IDI-Repräsentationssprache 3.4.1 Grundlagen logikbasierter Repräsentationssprachen 3.4.1.1 Aussagenlogik Überall dort, wo durch Schlussfolgerungsmechanismen aus vorhandenem Wissen neues Wissen generiert werden soll, wo der Wahrheitsgehalt von Zuständen oder Aussagen von Interesse ist oder wo die Konsistenz

3.4 IDI-Repräsentationssprache

51

einer Wissensbasis ermittelt werden muss, spielt der Einsatz von Logik als grundlegendem Repräsentationsprinzip eine bedeutende Rolle.107 Die als IDI-Repräsentationssprache gewählte Beschreibungslogik basiert, wie alle Logiksprachen, auf der Aussagen- und Prädikatenlogik. Daher sollen die grundlegenden Elemente dieser beiden Repräsentationssprachen vorgestellt werden. Alle formalen Sprachen bauen auf einem definierten Alphabet auf, das aus einer Menge unterschiedlicher Symbole besteht. Das Alphabet der Aussagenlogik umfasst ƒ einen Symbolvorrat für atomare Aussagen, ƒ eine Menge aussagenlogischer Verknüpfungen sowie ƒ die öffnende und schließende Klammer.108 Atomare Aussagensymbole repräsentieren elementare Aussagen über die reale Welt und werden in der Literatur meistens durch Großbuchstaben dargestellt. ƒ Beispiel: F " Es regnet." Atomare Aussagen können durch aussagenlogische Verknüpfungen, auch "Junktoren" genannt, zu komplexen Aussagen verbunden werden. Die folgende Tabelle listet die in dieser Arbeit genutzten Junktoren auf.109

107

108 109

Zu den grundlegenden Anwendungsszenarien logikbasierter Repräsentationssysteme vgl. Kelly 2003, S. 17; Haun 2000, S. 44-45; Helbig 1996, S. 53. Vgl. Spies 2004, S. 14. Vgl. Schmid, Kindsmüller 1996, S. 47; Heinsohn, Socher-Ambrosius 1999, S. 76.

52

3 Ontologiearchitektur und -sprache Konjunktion

F šG

Disjunktion

F ›G

Implikation

F ŸG

Äquivalenz

F œG

Kontravalenz F R G Negation Tabelle 1:

™F

Junktoren in der Aussagenlogik

Negierte oder nicht negierte atomare Aussagen werden "Literale" genannt.110 Als positive Literale werden in dieser Arbeit alle nicht negierten, als negative Literale alle negierten Atome bezeichnet. Die Semantik der Aussagenlogik beruht darauf, jeder Elementaraussage einen Wahrheitswert zuzuweisen. Es sei die Interpretation " ‚ " eine surjektive Funktion, die jedem Element einer Menge aussagenlogischer Atome " ¦ " einen Wahrheitswert aus der Menge Boole ^wahr ,falsch` zuordnet.111 Somit sei " ‚ " formal definiert als ‚ : ¦ o ^wahr ,falsch` .

ƒ Beispiel: F " Es regnet." ; wenn es regnet, dann gilt: ‚  F wahr . Bei komplexen aussagenlogischen Termen ergibt sich der Wahrheitswert des Terms aus den Wahrheitswerten der Atome seiner Signatur112 sowie den verbindenden Junktoren. Die Interpretation der mithilfe der o.g. Junktoren gebildeten Terme sei nun anhand einer Wahrheitstafel erläutert. Die ersten beiden Zeilen zeigen alle möglichen Kombinationen der Wahrheitswerte "wahr" (w) und "falsch" (f) für die beiden Aussagen " F " und " G ". Die sich hieraus ergebende Interpretation der einzelnen Terme ist in den Folgezeilen zu finden.

110 111 112

Vgl. Baumgarten 1996, S. 31. Vgl. Kastens, Kleine Büning 2005, S. 85; Heinsohn, Socher-Ambrosius 1999, S. 76. Als Signatur wird in der Aussagenlogik die Menge der in einer Formel enthaltenen Atome bezeichnet.

3.4 IDI-Repräsentationssprache

Tabelle 2:

53

‚F

w

w

f

f

‚ G

w

f

w

f

‚  ™F

f

f

w

w

‚ F š G

w

f

f

f

‚ F › G

w

w

w

f

‚F Ÿ G

w

f

w

w

‚F œ G

w

f

f

w

‚ F R G

f

w

w

f

Interpretationen von Junktoren

Die Menge aller Interpretationen mit dem Wahrheitswert „wahr“ wird auch als Modell des Terms bezeichnet. Alle Terme, die mindestens ein Modell besitzen, heißen "erfüllbar".113 3.4.1.2 Prädikatenlogik Die Aussagenlogik ermöglicht keinen Zugriff auf einzelne Komponenten einer Aussage, da ihre Literale nicht weiter zerlegt werden können. Folglich lassen sich beispielsweise keine Variablen oder Konstanten bei der Definition von Aussagen verwenden. Diese Nachteile überwindet die Prädikatenlogik. Ihre Syntax besteht aus den folgenden Elementen: ƒ Individuenkonstanten, ƒ Individuenvariablen, ƒ Funktionszeichen, ƒ Prädikatenzeichen und ƒ Quantorenzeichen. Prädikate sind die Kernelemente prädikatenlogischer Formeln. Sie repräsentieren "Aussagen von etwas über etwas."114 Prädikatenlogische

113 114

Vgl. Heinsohn, Socher-Ambrosius 1999, S. 78. Spies 2004, S. 86.

54

3 Ontologiearchitektur und -sprache

Ausdrücke besitzen zwei Bestandteile: das als Präfix notierte Prädikat sowie einen Klammerausdruck mit den Argumenten des Prädikats. Prädikate können mit Verbalphrasen natürlichsprachlicher Sätze verglichen werden. Sie repräsentieren Aussagen über Eigenschaften von oder Beziehungen zwischen Objekten. Der Klammerausdruck entspricht der Nominalphrase natürlichsprachlicher Sätze. Hier sind die Objekte als Argumente enthalten, deren Eigenschaften durch das Prädikat spezifiziert werden. Argumente prädikatenlogischer Terme können aus Individuenkonstanten, Individuenvariablen oder Funktionsausdrücken bestehen. Individuenkonstanten repräsentieren ein bestimmtes Objekt der Realität. Das Konstantensymbol besteht daher oftmals aus dem Eigennamen oder der Bezeichnung des Individuums. Individuen können bspw. bestimmte Städte, Namen, aber auch Realweltobjekte wie eine Rechnung oder ein Datenfeld einer elektronischen Nachricht sein. Individuenkonstanten beginnen mit einem Großbuchstaben. Individuenvariablen stehen stellvertretend für Objektmengen. So könnte etwa die Variable "x" die Objektmenge "Bestellnummer" repräsentieren. Individuenvariablen beginnen mit einem Kleinbuchstaben. Funktionen als Argumente in prädikatenlogischen Termen geben – in Abhängigkeit der Belegung ihrer Funktionsargumente – ein konkretes Individuum zurück.115 Prädikatenlogische Aussagen weisen somit die folgende Struktur auf: Prädikat Term1 ,Term2 ,…,Termn .

Der folgende Beispielausdruck repräsentiert die Aussage, dass das Individuum "Kunde AG" ein anderes Individuum "Staubsauger1" bestellt hat.

115

Zu Individuenvariablen und -ausdrücken sowie Funktionsausdrücken vgl. Spies 2004, S. 92-93.

3.4 IDI-Repräsentationssprache

55

hatBestellt  Kunde AG,Staubsauger 1

Mit der Einführung von Individuenvariablen ist es möglich, prädikatenlogische Ausdrücke zu quantifizieren. Ist eine Variable durch einen Allquantor gebunden (Notation: "  "), so muss der prädikatenlogische Ausdruck für alle Belegungen dieser Variable gültig sein. Beim Einsatz des Existenzquantors (Notation: "  ") genügt hingegen schon eine gültige Variablenbelegung.116 Um die Einsatzmöglichkeiten des Existenzquantors zu erweitern, soll die Anzahl der Elemente, für die eine Aussage gültig ist, angegeben werden können. Die Notation " n " sagt aus, dass der prädikatenlogische Ausdruck für mindestens n Ausprägungen gültig sein muss. Die folgende Tabelle listet beispielhaft zwei Terme mit Existenzquantor und Allquantor sowie der zugehörigen Interpretation auf. Term

Bedeutung

x : ª¬ AKunde  x Ÿ Rabatt  30%, x º¼

1x : ª¬ AKunde  x º¼ Tabelle 3:

Für alle x gilt: ist x ein A-Kunde, so erhält x 30% Rabatt. Es existiert genau ein A-Kunde.

Beispiele für den Einsatz des Existenz- und Allquantors

Prädikatenlogische Ausdrücke stellen eine Folge von Symbolen dar. Die Semantik der Prädikatenlogik erschließt sich, indem einzelnen Symbolen Objekte der Realität zugeordnet werden. Die Interpretation logikbasierter Ausdrücke wird ausführlich am Beispiel der Beschreibungslogik + '!&() dargestellt. Auf eine vertiefende Darstellung wird daher an dieser Stelle verzichtet.

116

Vgl. Schmid, Kindsmüller 1996, S. 55.

56

3 Ontologiearchitektur und -sprache

3.4.2 Beschreibungslogik + '!&() als IDI-Repräsentationssprache Hinter dem Begriff "Beschreibungslogik" verbirgt sich eine ganze Familie von Repräsentationssprachen. Beschreibungslogiken sind Fragmente der oben beschriebenen Prädikatenlogik und nehmen eine dominierende Rolle als Repräsentationssprachen von Ontologien ein.117 Ihren Namen verdanken die Beschreibungslogiken der Tatsache, dass die Konzepte einer Domäne durch sog. Konzeptbeschreibungen spezifiziert werden: "The name desciption logics is motivated by the fact that, on the one hand, the important notions of the domain are described by concept descriptions, i.e. expressions that are built from atomic concepts (unary predicates) and atomic roles (binary predicates) using the concept and role constructors provided by particular DL."118 Beschreibungslogiken stammen von den sog. "semantischen Netzen" ab. Im Gegensatz zu diesen besitzen sie jedoch eine formale Semantik. Die Beschreibungslogik + '!&() umfasst die folgenden grundlegenden Sprachelemente:119 ƒ Atomare Klassen werden in + '!&() als Mengen von Individuen interpretiert. Sie entsprechen den einstelligen Prädikaten der Prädikatenlogik. ƒ Atomare Rollen repräsentieren binäre Relationen zwischen Individuenmengen. Sie entsprechen zweistelligen Prädikaten der Prädikatenlogik. ƒ Individuen repräsentieren Objekte der realen Welt. In der Prädikatenlogik werden Individuen durch Konstantensymbole repräsentiert. Bei der Benennung von Beschreibungslogiken hat jeder Buchstabe eine bestimmte Bedeutung bzw. steht für einen bestimmten Sprachbestand-

117 118 119

Vgl. Wache 2001, S. 3. Baader et al. 2004, S. 5. Die Abkürzung "DL" steht für " Description Logics". Vgl. Hitzler et al. 2008, S. 164-167.

3.4 IDI-Repräsentationssprache

57

teil. Die Beschreibungslogik + '!&() setzt sich aus den folgenden Bestandteilen zusammen:120 ƒ + steht für $ plus Rollentransitivität. ƒ

steht für die Unterrollenbeziehung.

ƒ ' steht für abgeschlossene Klassen. ƒ ! steht für inverse Rollen. ƒ & steht für Zahlenrestriktionen. ƒ  steht für Datentypen. Es folgt ein tabellarischer Überblick über die in dieser Arbeit verwendeten Konstruktoren von + '!&().121 Die hier aufgelisteten Konstruktoren werden in Abschnitt 3.4.3 näher erläutert. Konstruktor/ Quantor

Bezeichnung

?

leere Klasse

F

allgemeinste Klasse

CŠD

Klassenkonjunktion

C‰D

Klassendisjunktion

™C

Klassennegation

RŠP

Rollenkonjunktion

R‰P

Rollendisjunktion

R ’P

Rollenkontravalenz

™R

Rollennegation

120

121

Die Auflistung der Bestandteile ist ohne Änderung entnommen aus Hitzler et al. 2008, S. 172. Einen Überblick über + '!&()-Konstruktoren liefern Horrocks, PatelSchneider 2003, S. 22; Baader et al. 2004, S. 14.

58

3 Ontologiearchitektur und -sprache

Konstruktor/ Quantor

Bezeichnung

R.C

universelle Wertedeklaration

R.C

existenzielle Wertedeklaration

t nR , d nR ,

nR

t nR.C , d nR.C ,

einfache Kardinalitätsrestriktionen qualifizierende Kardinalitätsrestriktionen

nR.C

^a1 ,! ,an `

abgeschlossene Klassen

R.^a1 ,! ,an `

Füllermenge

T .d

existenzielle Datentypdeklaration

T .d

universelle Datentypdeklaration

T1 ,! ,Tn .Pn

existenzielle Deklaration von Datentypgruppen

T1 ,! ,Tn .Pn

universelle Deklaration von Datentypgruppen

R

Rolleninversion

Tabelle 4:

Konstruktoren von + '!&()

Durch Konstruktoren und Quantoren alleine können keine Fakten über Domänen ausgedrückt werden. Zu diesem Zweck werden in + '!&() Axiomensysteme spezifiziert. Ein Axiomensystem ist "[...] eine Menge von Sätzen, die ohne Ableitung als wahr angenommen werden [...] "122 Axiomensysteme in + '!&() bestehen im Wesentlichen aus Konzeptund Rollendefinitionen sowie aus Konzept- und Rolleninklusionen. Hinzu kommen Aussagen über Individuen. Die folgende Tabelle zeigt eine Übersicht der + '!&()-Axiome.123 Die einzelnen Axiome werden in Abschnitt 3.4.4 näher erläutert.

122 123

Spies 2004, S. 64. Vgl. Baader et al. 2004, S. 15.

3.4 IDI-Repräsentationssprache Axiom

Bezeichnung

C‹D

Klasseninklusion

C {D

Klassenäquivalenz

C {D

Klasseninäquivalenz

C  Comp

Klassendefinition

R‹P

Rolleninklusion

R P

Rollendefinition

R  R

Rollensymmetrie

R ‹ R

Rollentransitivität

F‹ R.C

Bildbereich (Range)

R. F ‹ C

Domänenbereich (Domain)

C a

Klassenzugehörigkeit von Individuen

R  a,b

Aussagen Abstrakter Rollen

a

b, a z b

T  a,x Tabelle 5:

59

Gleichheit und Ungleichheit von Individuen Aussagen Konkreter Rollen

Axiomkategorien zur Spezifikation von Fakten in + '!&()

Es sei nun zunächst die formale Semantik von + '!&() für Individuen, atomare Klassen, Abstrakte Rollen sowie Konkrete Rollen definiert. Aufbauend auf dieser formalen Semantik lassen sich dann in den folgenden Abschnitten die Interpretationsfunktionen für die oben tabellarisch dargestellten Konstruktoren und Axiome ableiten. Beschreibungslogiken können als extensionale Sprachen aufgefasst werden. Danach spezifizieren Konzeptklassen Mengen von Individuen, Rollen spezifizieren Beziehungen zwischen zwei Individuenmengen.124 Es

124

Vgl. Spies 2004, S. 94.

60

3 Ontologiearchitektur und -sprache

erscheint daher naheliegend, auch die formale Semantik extensional zu definieren.125 Ausgangspunkt für die Bildung einer Interpretationsfunktion sind die folgenden disjunkten Bezeichnermengen:126 ƒ die Menge " I " als Menge aller Individuenbezeichner, ƒ die Menge " C " als Menge aller Bezeichner atomarer Klassen, ƒ die Menge " R " als Menge aller Bezeichner Abstrakter Rollen, ƒ die Menge " T " als Menge aller Bezeichner Konkreter Rollen. Abstrakte und Konkrete Rollen unterscheiden sich hinsichtlich ihres Wertebereichs. Der Wertebereich Abstrakter Rollen ist eine Menge von Individuen. Der Wertebereich Konkreter Rollen ist eine Konkrete Domäne.127 Es sei ! eine Interpretationsdomäne, bestehend aus Individuen der realen Welt. Es sei ferner  die Menge der Datentypen einer Konkreten Domäne mit ! ˆ ‡ . Dann wird über die Interpretationsfunktion ƒ ! I jedem Individuenbezeichner aus I ein Domänenelement aus I ! ! ,

ƒ !C jedem Bezeichner einer atomaren Klasse aus C eine Menge C ! Ž! ,

125

126 127

Alternativ zur extensionalen Semantik ließe sich die Bedeutung von + '!&() z.B. auch mithilfe der Prädikatenlogik spezifizieren (vgl. Hitzler et al. 2008, S. 163-172). Nach der Ansicht von Hitzler et al. lassen sich extensionale Semantiken jedoch intuitiver erfassen, "[...]vor allem für Personen, die mit Prädikatenlogik weniger oder gar nicht vertraut sind." Hitzler et al. 2008, S. 172. Vgl. Hitzler et al. 2008, S. 173. Vgl. Horrocks, Sattler 2001, S. 200. Das Thema "Konkrete Domänen" wird in Abschnitt 3.4.3.4 behandelt. Als dritte Rollenkategorie werden in der IDIArchitektur noch Attributrollen betrachtet. Vgl. hierzu Abschnitt 4.3.3.4.

3.4 IDI-Repräsentationssprache

61

ƒ !R jedem Bezeichner einer Abstrakten Rolle aus R eine binäre Relati-





on R ! Ž ! u! sowie ƒ !T jedem Bezeichner einer Konkreten Rolle aus T eine binäre Relati-





on T ! Ž ! u zugeordnet.128 Eine Konkretisierung der allgemeinen Interpretationsfunktionen für Konstruktoren und Axiome ist den folgenden Abschnitten 3.4.3 und 3.4.4 zu entnehmen. Zum Abschluss dieser allgemeinen Einführung von + '!&() soll hinterfragt werden, warum gerade diese Beschreibungslogik als Repräsentationssprache für die IDI-Architektur ausgewählt wurde. Ein wesentlicher Grund besteht darin, dass + '!&() mit OWL DL129 über eine XMLbasierte Syntax verfügt, die im Jahr 2004 vom W3C als Ontologiesprache für das "Semantic Web" standardisiert wurde.130 Eine solche XMLbasierte Ontologiesprache wird auch für die IDI-Architektur benötigt, da Ausschnitte der privaten LBoxen zwischen den IDI-Agenten ausgetauscht werden müssen. Aber auch die Sprache selbst weist einige Vorzüge auf. So besteht etwa die Möglichkeit, Definitions- und Wertebereiche für Rollen zu definieren oder Füllermengen zu spezifizieren. Alle Konstruktoren und Axiome von + '!&() verfügen über eine formale Semantik. Bei der Nutzung einer formalen Sprache, die über weniger reichhaltige Ausdrucksmittel verfügt oder keine formale Semantik besitzt (z.B. die Prädikatenlogik), hätten die Konstruktoren und Axiome erst noch syntaktisch und semantisch definiert werden müssen.

128 129 130

Vgl. Hitzler et al. 2008, S. 173. OWL DL steht für " Web Ontology Language for Description Logics". Für einen OWL-Überblick vgl. Smith et al. 2004; Antoniou, van Harmelen 2004.

62

3 Ontologiearchitektur und -sprache

3.4.3 Konstruktoren 3.4.3.1 Klassenkonstruktoren Konstruktoren dienen der Erstellung komplexer Rollen oder Klassen aus atomaren Rollen oder Klassen. Jede Beschreibungslogik verfügt über eine charakteristische Menge an Konstruktoren. In wenigen Fällen gehören die in dieser Arbeit dargestellten Konstruktoren und Axiome nicht zum Sprachumfang von + '!&(). Darauf wird dann an der entsprechenden Stelle hingewiesen. Es seien nun zunächst die allgemeinste (Notation " F ") und die speziellste Konzeptklasse (Notation " ? ") vorgestellt.131 Die allgemeinste Konzeptklasse umfasst sämtliche Objekte der Domäne. Das speziellste Konzept entspricht der leeren Menge und enthält keine Objekte.132 F! ! ; ?! ‡ Formel 1: Formale Semantik für die allgemeinste und die speziellste Klasse

Abgeschlossene Klassen sehen vor, Konzepte durch die Aufzählung ihrer Individuen zu definieren. Wie die unten stehende Interpretationsfunktion zeigt, muss jedes Element einer abgeschlossenen Klasse ^a1 ,! ,an ` ein Objekt der Interpretationsdomäne sein.133

^a1 ,! ,an `!

^a1! ! ` ‰ ! ‰ ^an! ! `

Formel 2: Formale Semantik für abgeschlossene Klassen

Das folgende Beispiel für eine abgeschlossene Klasse verwendet das in Abschnitt 3.4.4.1 vorgestellte Definitionszeichen ("  "). ƒ Beispiel: Verkäufer  ^Meyer ,Müller ,Schulz` ; ƒ Interpretation: Die Objekte

^Meyer ,Müller ,Schulz` stellen eine voll-

ständige extensionale Definition der Konzeptklasse "Verkäufer" dar.

131 132 133

Vgl. Calvanese et al. 1998, S. 232. Vgl. Baader, Nutt 2002, S. 52. Vgl. Hitzler et al. 2008, S. 174.

3.4 IDI-Repräsentationssprache

63

Konjunktionen von Konzeptklassen werden durch das Konjunktionszeichen " Š " gebildet. Es seien C und D Konzeptklassen, dann ist C Š D ein Konjunktionsklasse. Die Konjunktionsklasse C Š D bezeichnet alle Individuen, die sowohl zu C wie auch zu D gehören. C Š D kann daher auch als Schnittmenge der Individuen von C und D interpretiert werden.134 ƒ Beispiel: Handelsunternehmen Š Produktionsunternehmen ; ƒ Interpretation: Die Klasse Handelsunternehmen Š Produktionsunternehmen umfasst alle Individuen, die sowohl ein Handels- wie auch ein Produktionsunternehmen sind. Es seien C und D Klassen, dann ist C ‰ D ein Disjunktionsklasse. Die Disjunktionsklasse C ‰ D bezeichnet alle Individuen, die zu mindestens einer der Klassen C oder D gehören. C ‰ D lässt sich daher auch als Vereinigungsmenge der Individuen von C und D interpretieren.135 ƒ Beispiel: Handelsunternehmen ‰ Produktionsunternehmen ; ƒ Interpretation: Die Klasse Handelsunternehmen ‰ Produktionsunternehmen umfasst alle Individuen, die ein Handels- oder ein Produktionsunternehmen (oder beides) sind. Die Negation von Konzeptklassen wird analog zur Aussagen- oder Prädikatenlogik notiert. Es sei C eine Klasse, dann ist ™C eine Negationsklasse. Die Klasse ™C umfasst alle Individuen, die nicht zu C gehören. ƒ Beispiel: ™Handelsunternehmen ; ƒ Interpretation: Die Klasse ™Handelsunternehmen enthält alle Unternehmen, die kein Handelsunternehmen sind. Konjunktion, Disjunktion und Negation seien nun auch formal definiert.136

134 135 136

Vgl. Hitzler et al. 2008, S. 174. Vgl. Hitzler et al. 2008, S. 174. Vgl. Baader, Nutt 2002, S. 52.

64

3 Ontologiearchitektur und -sprache

C Š D !

C ! ˆ D ! ; C ‰ D

!

C ! ‰ D ! ;  ™C

!

! \C !

Formel 3: Formale Semantik für Klassenkonjunktion, -disjunktion und -negation

3.4.3.2 Rollenkonstruktoren Als eine Besonderheit von Beschreibungslogiken können auch Rollen durch Konjunktionen, Disjunktionen und Negationen zu komplexen Rollen zusammengesetzt werden. Es seien P und R Rollen, dann ist R Š P ein Konjunktionsrolle. Die Konjunktionsrolle R Š P bezeichnet alle Individuenpaare, die sowohl durch die Rolle P wie auch die Rolle R verbunden werden. ƒ Beispiel: hatKundeR ŠhatTochterunternehmenR ƒ Interpretation: Die Rolle hatKundeR ŠhatTochterunternehmenR umfasst alle Individuenpaare, die sowohl durch die Rolle hatKundeR wie auch die Rolle hatTochterunternehmenR verbunden sind. Es seien P und R Rollen, dann ist R ‰ P eine Disjunktionsrolle. Die Disjunktionsrolle R ‰ P bezeichnet alle Individuenpaare, die durch die Rolle P oder die Rolle R oder durch beide verbunden werden. ƒ Beispiel: hatKundeR ‰ hatTochterunternehmenR ƒ Interpretation: Die Rolle hatKundeR ‰ hatTochterunternehmenR umfasst alle Individuenpaare, die entweder durch die Rolle hatKundeR oder die Rolle hatTochterunternehmenR oder durch beide Rollen verbunden sind. Es sei R eine Rolle, dann ist ™ R eine Negationsrolle. Die Rolle ™ R umfasst alle Individuenpaare, die nicht durch die Rolle R verbunden werden. ƒ Beispiel: ™hatKundeR ƒ Interpretation: Die Rolle ™hatKundeR enthält alle Individuenpaare, die keine Kundenbeziehung unterhalten. Es seien P und R Rollen, dann ist R’P eine Kontravalenzrolle. Die Kontravalenzrolle R’P bezeichnet alle Individuenpaare, die entweder durch die Rolle P oder die Rolle R verbunden werden, nicht jedoch durch beide. Die Kontravalenzrolle ist eine abgeleitete Rolle, die bei der

3.4 IDI-Repräsentationssprache

65

Formulierung der IDI-GBox benötigt wird. Sie lässt sich unter Verwendung der originären + '!&()-Rollen definieren: R ’P  ª¬ R ‰ P Š ™  R Š P º¼ .

ƒ Beispiel: hatKundeR’hatTochterunternehmenR ƒ Interpretation: Die Rolle hatKundeR’hatTochterunternehmenR umfasst alle Individuenpaare, die entweder durch die Rolle hatKundeR oder die Rolle hatTochterunternehmenR verbunden sind, nicht jedoch durch beide. Es sei nun die formale Semantik für Rollenkonjunktion, -disjunktion, -kontravalenz und -negation wie folgt definiert.137

R Š P !

 R’P !



R ! ˆ P ! ; R ‰ P





!

R! ‰ P ! ;

ª R ! \ P ! ‰ P ! \ R ! º ;  ™R ! ¬ ¼

! u! \ R !

Formel 4: Formale Semantik für Rollenkonjunktion, -disjunktion, -kontravalenz und -negation

Rolleninversionen werden in Beschreibungslogiken durch ein hochgestelltes Minuszeichen angezeigt. Eine Rolle R  ist invers zu einer Rolle R , wenn der Domänenbereich138 von R  der Bildbereich139 von R und der Bildbereich von R  der Domänenbereich von R ist. ƒ Beispiel: hatKindR  hatElternteilR ƒ Interpretation: Die Rolle " hatKindR " ist die Umkehrrolle zu " hatElternteilR ". Damit ist die Umkehrrolle von " hatElternteilR " semantisch äquivalent zur Rolle " hatKindR ". Auch die formale Semantik von Rolleninversionen lässt sich extensional definieren.

137 138 139

Vgl. Baader, Nutt 2002, S. 95. Für eine Erläuterung des Begriffs "Domänenbereich" siehe Abschnitt 3.4.3.3. Für eine Erläuterung des Begriffs "Bildbereich" siehe Abschnitt 3.4.3.3.

66

3 Ontologiearchitektur und -sprache

R  ^a,b |  b,a  R ! ` !

Formel 5: Formale Semantik für Rolleninversion

3.4.3.3 Quantoren und Kardinalität Quantoren werden in Beschreibungslogiken in Verbindung mit Rollen definiert und deklarieren die zulässige Individuenmenge für den sog. "Rollenfüller". Es sei R  a,b eine Rollenaussage über die Individuen a und b , dann stellt das Individuum b den sog. "Rollenfüller" ("role filler") dar.140 Um die funktionalen Unterschiede der Individuen in Rollenbeziehungen sprachlich abbilden zu können, wird im weiteren Verlauf der Arbeit jedes Individuum an erster Position einer Rolle Rollenerster, jedes Individuum an zweiter Position Rollenzweiter genannt. Rollenfüller entsprechen also den Rollenzweiten. Außerdem wird im weiteren Verlauf der Arbeit die Menge aller gültigen Rollenersten einer Rolle als Domänenbereich, die Menge aller gültigen Rollenzweiten als Bildbereich einer Rolle bezeichnet. Durch Quantoren erzeugte Terme stellen komplexe Klassen dar; wenn also R eine Rolle und C eine Klasse ist, dann sind R.C und R.C komplexe Klassen.141 Zu berücksichtigen ist, dass die zu quantifizierende Variable – im Gegensatz etwa zur Prädikatenlogik – nicht angezeigt wird.142 Die universelle Werterestriktion R.C repräsentiert die Klasse aller Individuen, die als Rollenerste über die Rolle R mit einer Menge von Rollenzweiten verbunden sind, wobei die Rollenzweiten immer Individuen der Klasse C sein müssen. Der Allquantor – ebenso wie der Existenzquantor – schränkt also die Bildbereiche der Rollen ein. ƒ Beispiel: hatKundeR .Handelsunternehmen

140 141 142

Vgl. Nardi, Brachman 2002, S. 12. Vgl. Hitzler et al. 2008, S. 165. Vgl. Nardi, Brachman 2002, S. 12.

3.4 IDI-Repräsentationssprache

67

ƒ Interpretation: Die Klasse hatKundeR .Handelsunternehmen umfasst alle Individuen, die über Kunden verfügen und deren Kunden ausschließlich Handelsunternehmen sind. Die existentielle Werterestriktion R.C repräsentiert die Klasse aller Individuen, die als Rollenerste über die Rolle R mit einer Menge von Rollenzweiten verbunden sind, wobei mindestens ein Rollenzweiter ein Individuum der Konzeptklasse C sein muss. ƒ Beispiel: hatKundeR .Handelsunternehmen ƒ Interpretation: Die Klasse hatKundeR .Handelsunternehmen umfasst alle Individuen, die über Kunden verfügen und in deren Kundenkreis sich mindestens ein Handelsunternehmen befindet. Quantifizierungen sind auch mit Individuen möglich. ƒ Beispiel: hatKundeR .^Firma Meyer GmbH` ƒ Interpretation: Die Klasse hatKundeR .^Firma Meyer GmbH` umfasst alle Individuen, die über Kunden verfügen. Einer dieser Kunden muss die Firma Meyer GmbH sein. Soll ausgesagt werden, dass eine Individuenmenge ausschließlich über die Firma Meyer GmbH als Kunde verfügt, so lässt sich dieser Sachverhalt mit einer qualifizierenden Kardinalitätseinschränkung formulieren:143 ƒ

1 hatKundeR .^Firma Meyer GmbH `

Es sei nun die formale Semantik für universelle und existentielle Werterestriktionen angegeben.144

143

144

Eine Definition qualifizierender Kardinalitätseinschränkungen erfolgt im gleichen Kapitel weiter unten. Vgl. Baader, Nutt 2002, S. 52-53.

68

3 Ontologiearchitektur und -sprache

 R.C !  R.C !

^a  | b : ª¬a,b  R Ÿ  b  C º¼` ^a  |  b : ª¬a,b  R š b  C º¼` !

!

!

!

!

!

Formel 6: Formale Semantik für universelle und existenzielle Werterestriktionen

Die Kardinalität schränkt die Anzahl der möglichen Rollenzweiten ein. Einfache Kardinalitätseinschränkungen begrenzen die Anzahl möglicher Rollenfüller, ohne deren Klassenzugehörigkeit zu reglementieren. n R Notationen für KardinalitätsbeEs seien t n R , d n R und schränkungen. Um die Lesbarkeit zu verbessern, werden Kardinalitätsangaben in eckigen Klammern (" ") vor der Rollenbezeichnung notiert. Es sei nun die Semantik für einfache Kardinalitätseinschränkungen formal definiert.145

 t nR !  d nR !  Formel 7

nR

!

^a  | # ^b  | a,b  R ` t n` ^a  | # ^b  | a,b  R ` d n` ^a  | # ^b  |  a,b  R ` n` !

!

!

!

!

!

!

!

!

Formale Semantik für einfache Kardinalitätseinschränkungen

ƒ Beispiel: t 3 hatKundeR ƒ Interpretation: Die Klasse t 3 hatKundeR umfasst alle Individuen, die über mindestens drei Kunden verfügen. Rollen mit einer Kardinalität

1 werden auch funktionale Rollen ge-

nannt, da sie jedem Rollenersten genau einen Rollenzweiten zuordnen. Beschreibungslogiken kennen auch qualifizierende Kardinalitätseinschränkungen. Hier wird zusätzlich zur Anzahl der möglichen Rollenfüller auch deren Klassenzugehörigkeit eingeschränkt. Es seien t n R.C ,

145

Vgl. Baader, Nutt 2002, S. 53.

3.4 IDI-Repräsentationssprache d n R.C und

69

n R.C Notationen für qualifizierende Qualitätsein-

schränkungen. Es folgt eine formale Definition qualifizierender Kardinalitätseinschränkungen.146

 t nR.C !  d nR.C

!



!

nR.C

^a  | # ^b  | a,b  R ^a  | # ^b  | a,b  R ^a  | # ^b  | a,b  R !

!

!

!

!

!

` ` ! š b  C ! ` d n` ! š b  C ! ` n` !

š b C ! t n

Formel 8: Formale Semantik für qualifizierende Kardinalitätseinschränkungen

ƒ Beispiel: t 3 hatKundeR .Handelsunternehmen ƒ Interpretation: Die Klasse

t 3 hatKundeR .Handelsunternehmen um-

fasst alle Individuen, die über Kundenbeziehungen verfügen. Mindestens drei dieser Kunden müssen Handelsunternehmen sein. Es sei darauf hingewiesen, dass nur einfache, nicht jedoch qualifizierende Kardinalitätseinschränkungen zum originären Sprachumfang von + '!&() gehören. 3.4.3.4 Konkrete Domänen Ontologische Definitionen erfordern bisweilen den Einsatz von Individuen. Eine Möglichkeit zur Einbeziehung von Individuen in Inklusionsoder Definitionsaxiome stellen die bereits beschriebenen abgeschlossenen Klassen dar. Diese Variante lässt sich jedoch nur für diskrete Individuenmengen mit einer überschaubaren Anzahl an Elementen sinnvoll einsetzen. In der Realität existiert jedoch eine Vielzahl von Konzepten, deren Individuen sich nicht durch abgeschlossene Klassen abbilden lassen. Beispiele sind Entfernungsangaben, Maße, Geldbeträge oder Zeitangaben. Die

146

Vgl. Calvanese et al 1998, S. 233.

70

3 Ontologiearchitektur und -sprache

Repräsentation derartiger Phänomene erfolgt in Beschreibungslogiken durch sog. "Konkrete Domänen".147 Konkrete Domänen können, im Gegensatz zu den bislang betrachteten Abstrakten Domänen, aus den folgenden Elementen bestehen :148 ƒ Datentypen deklarieren Kategorien von Daten. Mögliche Datentypen könnten bspw. "String", "Boolean" oder "Integer" sein. Der Datentyp determiniert die möglichen Operationen, die mit den Daten durchgeführt werden dürfen. ƒ Datentypeigenschaften repräsentieren Eigenschaften wie "Größe", "Geschwindigkeit" oder "Betrag". Datentypeigenschaften werden in Beschreibungslogiken durch sog. "Konkrete Rollen" repräsentiert. Im Gegensatz zu Abstrakten Rollen besteht der Bildbereich Konkreter Rollen nicht aus Individuen, sondern aus Elementen eines bestimmten Datentyps. Eine Datentypeigenschaft könnte bspw. durch die Konkrete Rolle hatGewichtT repräsentiert werden; diese Rolle könnte einem Individuum einen bestimmten, durch einen Datentyp determinierten, Zahlenwert zuweisen. ƒ Datentypprädikate spezifizieren Randbedingungen über eine Liste von Datentypeigenschaften. Die Stelligkeit dieser Prädikate entspricht der Anzahl der Datentypeigenschaften. Bspw. könnte ein Prädikat " ! " Gewichtsunterschiede zwischen Individuen spezifizieren, die über eine Konkrete Rolle hatGewichtT verfügen. In der IDI-Architektur werden zwei Kategorien Konkreter Domänen verwendet: Typensysteme und Datentypengruppen. Zwar stellen Typensysteme eine Spezialisierung von Datentypengruppen dar. Zur besseren Veranschaulichung werden jedoch beide Ansätze separat voneinander vorgestellt. Es sollen zunächst Typensysteme beschrieben werden.149

147 148 149

Vgl. Baader et al. 2002, S. 227-228. Vgl. Pan, Horrocks 2002, S. 1069. Zum Thema „Typensysteme“ bzw. „Konkrete Datentypen“ vgl. Horrocks, Sattler 2001; eine gute Beschreibung findet sich auch in Pan, Horrocks 2003.

3.4 IDI-Repräsentationssprache

71

Es sei %D die Domäne aller Datentypen und T eine Konkrete Rolle. Der Wertebereich Konkreter Rollen sei durch %D angegeben. Ferner sei d ein Datentyp. Jedem Datentyp ist eine Wertemenge d D Ž %D zugeordnet. Mit der Notation T .d bzw. T .d sind universelle bzw. existenzielle Datentypdeklarationen möglich. Die komplexe Klasse T .d umfasst alle Individuen, die Rollenerste der Konkreten Rolle T sind. Dabei entspricht die Menge der zulässigen Rollenzweiten der Wertemenge d D Ž %D . Die komplexe Klasse T .d umfasst ebenfalls alle Individuen, die Rollenerste der Konkreten Rolle T sind. Hier muss allerdings nur in einem Fall der Rollenzweite ein Element der Wertemenge d D Ž %D sein. Diese informale Definition sei nun auch formal dargestellt.150

 T .d !  T .d !

^a  | y : ª¬a,y T Ÿ  y  d º¼` ^a  | y : ª¬a,y T š  y  d º¼` !

!

!

!





Formel 9: Formale Semantik für universelle und existenzielle Datentypdeklarationen

Die Datentypdeklaration sei an einem Beispiel veranschaulicht. ƒ Beispiel: maxLadegewichtT .decimal ƒ Interpretation: Die Konzeptklasse maxLadegewichtT .decimal umfasst alle Individuen, die über die Eigenschaft "maximales Ladegewicht" verfügen. Das maximale Ladegewicht wird immer durch eine Dezimalzahl angegeben, entspricht also dem Datentyp decimal . Mithilfe der soeben beschriebenen Typendeklarationen ist es zwar möglich, den Bildbereich einer Konkreten Rolle auf einen bestimmten Datentyp zu beschränken. Allerdings lassen sich keine Randbedingungen über eine Liste Konkreter Rollen formulieren. Hierzu werden in Beschreibungslogiken Datentypengruppen genutzt.151

150 151

Vgl. Pan, Horrocks 2004, S. 4. Vgl. Pan, Horrocks 2002; Pan, Horrocks 2003.

72

3 Ontologiearchitektur und -sprache

Datentypengruppen basieren auf Mengen von Datentypen ( d1 ,! ,dm ). Analog zu einzelnen Datentypen sind auch die Elemente von Datentypengruppen Teilmengen der Konkreten Domäne:





i : d iD Ž %D .

Bei der Spezifikation von Datentypengruppen werden Datentypprädikate ( P1 ,! ,Pr ) zur Formulierung von Constraints über Listen von Datentypeneigenschaften verwendet. Für jedes Datentypprädikat Pj muss eine Stelligkeit n j definiert sein. Außerdem ist jedem Datentypprädikat Pj eine Wertemenge PjD zugeordnet, die eine Teilmenge des kartesischen Produkts der betrachteten Datentyp-Wertemengen darstellt:152





nj º j : ª 1 d j d r š PjD Ž d Dj 1 u ! u d D jn j Ž %% » . ¬« ¼

Es sei T1 ,! ,Tn eine Liste von Datentypeigenschaften bzw. Konkreten Rollen. Dann lassen sich universelle und existentielle Datentypgruppen nach der folgenden Syntax deklarieren: T1 ,! ,Tn .Pn T1 ,! ,Tn .Pn

.

Es sei nun zunächst die Bedeutung dieser Deklarationen formal spezifiziert.153

152 153

Vgl. Pan, Horrocks 2002, S. 1070. Vgl. Pan, Horrocks 2002, S. 1073.

3.4 IDI-Repräsentationssprache

 T1 ,! ,Tn .Pn  T1 ,! ,Tn .Pn

!

!

73

­a ! |  y 1 ,! ,y n : ° ®ª ! ! ° ¬  a,y 1  T1 š ! š  a,y n  Tn Ÿ ¯



­a ! |  y 1 ,! ,y n : ° ®ª ! ! ° ¬  a,y 1  T1 š ! š  a,y n  Tn ¯



½ ° D º¾  y1 ,! ,y n  Pn ¼ °¿ ½ ° D º¾ š  y 1 ,! ,y n  Pn ° ¼¿









Formel 10: Formale Semantik für universelle und existenzielle Deklarationen von Datentypgruppen

Die Verwendung von Datentypgruppen sei nun an zwei Beispielen veranschaulicht. Es sei der Datentyp d=Natürliche Zahlen mit der Wertemenge d D ` definiert. Es seien ferner die unären Prädikate dn , tn , n , !n mit n  ` definiert. Schließlich repräsentiere ladegewichtT eine Konkrete Rolle. ƒ Beispiel 1:   ladegewichtT . t10 Š ladegewichtT . d 35 ƒ Interpretation: Die Konzeptklasse   ladegewichtT . t10 Š ladegewichtT . d35 repräsentiert die Menge aller Individuen, deren Ladegewicht zwischen den Werten 10 und 35 liegt. Die Menge der Prädikate sei nun um die binären Prädikate " d , t , ! ,  " erweitert. Es seien hatEigenkapitalT und hatFremdkapitalT zwei Konkrete Rollen. ƒ Beispiel 2:   hatEigenkapitalT ,hatFremdkapitalT .  ƒ Interpretation: Die Konzeptklasse   hatEigenkapitalT ,hatFremdkapitalT .  umfasst sämtliche Individuen, die über mehr Fremd- als Eigenkapital verfügen. Statt n-stellige Prädikate zu definieren, können auch sog. O -Ausdrücke verwendet werden.154 Der Lambda-Operator ändert die Art eines Aus-

154

Ein Beispiel für die Verwendung von O -Ausdrücken statt n-stelliger Prädikate liefern Pan, Horrocks 2002, S. 1072.

74

3 Ontologiearchitektur und -sprache

drucks, indem er z.B. einen Satz in ein Prädikat oder eine Individuenvariable umwandelt.155 Es wird die folgende Syntax für O -Ausdrücke in der GBox verwendet: O  x1 ,! , xn  Formel

Hinter dem O -Operator werden zunächst die benötigten Variablen aufgelistet. Dabei richtet sich die Anzahl der Variablen nach der Stelligkeit des Prädikats, das der O -Ausdruck repräsentiert. Es schließt sich die Formel an, in der die Variablen durch arithmetische oder andere Operationen aufeinander bezogen werden. Die Verwendung von O -Ausdrücken sei nun an einem Beispiel verdeutlicht. § 1 hatEigenkapitalT Š · ¨ ¸ ¨ 1 hatFremdkapitalT Š ¸ ¨ ¸ ƒ Beispiel: ¨ 1 hatEkQuoteT . ! 0, 5 Š ¸ ¨ ª  hatEigenkapital ,hatFremdkapital ,hatEkQuote .º ¸ T T T ¨« »¸ ¨ «O ª x,y ,z  z x /  x  y º »¼ ¸¹ ¼ ©¬ ¬

Die oben aufgeführte Konzeptklasse repräsentiert alle Individuen, die über eine Eigenkapitalquote größer 0,5 verfügen. Die erste Zeile des Beispiels legt fest, dass die Individuen der definierten Individuenmenge Rollenerste der Konkreten Rollen hatEigenkapitalT , hatFremdkapitalT sowie hatEkQuoteT sein müssen und dass der Bildbereich der Rolle hatEkQuoteT ausschließlich aus Werten größer 0,5 bestehen darf. In der zweiten Beispielzeile wird spezifiziert, nach welcher Formel sich die Eigenkapitalquote berechnen lässt. Zu beachten ist, dass die Reihenfolge der Variablendeklaration im O Ausdruck der Reihenfolge der zugehörigen Argumente in dem Prädikatsausdruck entsprechen muss.

155

Vgl. Schwarz, Chur 2004, S. 152.

3.4 IDI-Repräsentationssprache

75

3.4.4 Axiome Der Zweck von Axiomen besteht in Beschreibungslogiken darin, Fakten über eine Anwendungsdomäne zu definieren. Die folgenden Unterkapitel zu 3.4.4 geben einen Überblick über die durch + '!&() bereitgestellten Axiomenkategorien. 3.4.4.1 Klassenaxiome Klassenaxiome werden in der IDI-Architektur in vier Kategorien unterteilt: Klassendefinitionen, Klassenäquivalenzen, Klasseninäquivalenzen und Klasseninklusionen. Es sei C eine atomare und Comp eine komplexe Klasse, dann ist C  Comp eine Klassendefinition. Hierbei befindet sich das Definiendum (die Klasse C ) auf der linken Seite des Definitionssymbols, das Definiens (die komplexe Klasse Comp ) auf der rechten Seite. Definienden werden auch als Namenssymbole bezeichnet, ein Synonym für Definiens ist "Basissymbol".156 Klassendefinitionen liefern Definitionen notwendiger und hinreichender Bedingungen für die Zugehörigkeit von Individuen des Definiens zum Definiendum. Sie unterliegen in Beschreibungslogiken zwei wichtigen Einschränkungen: ƒ Konzeptklassen dürfen nur einmal definiert werden;157 ƒ Definitionen müssen azyklisch sein, d.h. eine Klasse darf weder durch sich selbst noch durch Referenzen auf sich selbst definiert werden.158 Von der Klassendefinition wird in der IDI-Architektur die sog. Klassenäquivalenz unterschieden. Es seien C und D Konzeptklassen, dann repräsentiert der Ausdruck C { D eine Äquivalenzaussage.

156 157

158

Vgl. Baader, Nutt 2002, S. 56. Wenn Konzeptklassen in der vorliegenden Arbeit an mehreren Stellen definiert werden, dann erfolgt dies aufgrund der inhaltlichen Gliederung dieser Forschungsarbeit. Es handelt sich also in diesen Fällen um unterschiedliche Teile einer Definition, die im Anwendungsfall zusammengeführt werden würden. Vgl. Nardi, Brachman 2002, S. 17.

76

3 Ontologiearchitektur und -sprache

Zielsetzung der Unterscheidung von Klassendefinition und -äquialenz ist es, definierende Axiome von solchen Axiomen zu trennen, die lediglich eine Aussage über das semantische Verhältnis zweier Konzeptklassen machen. Klasseninäquivalenz soll durch den Term C {D ausgedrückt werden. Eine weitere Axiomenkategorie stellen Konzeptinklusionen dar. Es seien C und D Konzeptlassen, dann ist C ‹ D eine Konzeptklasseninklusion. Inklusionen drücken Spezialisierungsbeziehungen zwischen Konzepten aus. Sie repräsentieren notwendige, nicht jedoch hinreichende Bedingungen für die Konzeptzugehörigkeit von Individuen. Bei der Notation einer formalen Semantik für Axiome ist – im Gegensatz zur formalen Semantik von Konstruktoren – eine Besonderheit zu beachten. Interpretationsergebnis von Klassen sind Individuenmengen und von Rollen Mengen von Individuenpaaren. Demgegenüber stellen Interpretationsergebnisse von Axiomen Wahrheitswerte dar. Um trotzdem Axiome durch Mengendefinitionen semantisch spezifizieren zu können, muss einer der beiden Wahrheitswerte ("wahr" oder "falsch") angenommen werden. Folglich wird bspw. nicht das Axiom C  D semantisch spezifiziert, ! sondern der Term ªC  D

¬

wahr º . ¼

Es sei nun die Semantik für Klassendefinitionen und -inklusionen formal spezifiziert.



ªC  Comp ! wahr º œ C ! Comp ! ¬ ¼ ! ªC { D wahr º œ C ! D ! ¬ ¼ ! ªC ‹ D wahr º œ C ! Ž D ! ¬ ¼ ªC A D ! wahr º œ C ! z D ! ¬ ¼

  





Formel 11: Formale Semantik für Klassendefinitionen und -inklusionen

3.4.4.2 Rollenaxiome Analog zu den Konzeptklassen lassen sich auch für Rollen Inklusionen und Definitionen spezifizieren. Es seien R und P Rollen, dann ist R  P

3.4 IDI-Repräsentationssprache

77

eine Rollendefinition. Diese Rollendefinition sagt aus, dass alle Individuenpaare, die durch R verbunden sind, auch durch P verbunden sein müssen und umgekehrt. Rollendefinitionen beschreiben notwendige und hinreichende Eigenschaften für die Rollenzugehörigkeit von Individuenpaaren. Auf der linken Seite der Rollendefinition findet sich der Rollenbezeichner, auf der rechten Seite werden die notwendigen und hinreichenden Bedingungen für die Zugehörigkeit von Individuenpaaren zu der durch den Bezeichner bezeichneten Rolle definiert. Wie auch bei Konzeptklassen können Rollen in der GBox nur einmal definiert werden. Rolleninklusionen drücken Spezialisierungsbeziehungen zwischen Rollen aus. Sie beschreiben notwendige Bedingungen für die Rollenzugehörigkeit von Individuenpaaren. Die Rolleninklusion R ‹ P sagt aus, dass alle Individuenpaare, die durch R verbunden sind, auch durch P verbunden sein müssen. Umgekehrt jedoch müssen nicht alle durch P verbundenen Individuenpaare auch durch R verbunden sein. R stellt also die allgemeinere und P die spezifischere Rolle dar. Rollendefinitionen und -inklusionen seien nun formal spezifiziert.159 ª R  P ! ¬ ª R ‹ P ! ¬

 

wahr º œ R ! P ! ¼ wahr º œ R ! Ž P ! ¼



Formel 12: Formale Semantik für Rollendefinitionen und -inklusionen

Bisweilen ist es erforderlich, den Domänen- oder Bildbereich von Rollen global einzuschränken. Die zugehörigen Axiome sollen als Domänenoder Bildbereichsaxiome bezeichnet werden. Das Axiom F‹ R.C sagt aus, dass der Bildbereich von R stets aus Individuen der Konzeptklasse C bestehen muss. Wenn die Konzeptklasse F eine Spezialisierung der Konzeptklasse R.C darstellt, dann ist R.C nicht verallgemeinerbar. Alle Rollenzweiten von R müssen also immer Individuen der Klasse C sein.

159

Vgl. Hitzler et al. 2008, S. 175.

78

3 Ontologiearchitektur und -sprache

Der Domänenbereich von R lässt sich durch die inverse Rolle R  ausdrücken. Demnach definiert das Axiom F‹ R  .C den Bildbereich der Rolle R  , der gleichzeitig der Domänenbereich von R ist. Die Semantik der beiden beschriebenen Axiomenkategorien sei nun auch formal dargestellt.160 ª F‹ R.C ! ¬



ª  « F‹ R .C ¬



wahr º œ  a, b : ª a,b  R ! Ÿ b  C ! º ¬ ¼ ¼



ª§  a,b  R  º wahr » œ  a, b : ««¨ ¨ ! ¼ «¬¨©  b,a  R

!

!

º · œ¸ !» Ÿ a C » ¸ ¸ »¼ ¹

Formel 13: Formale Semantik für Domänen- und Bildbereichsaxiome

Rollensymmetrie ist ein Rollenaxiom, das aussagt, dass der Domänenund Bildbereich einer Rolle identisch zum Domänen- und Bildbereich ihrer Rollenumkehr (inversen Rolle) ist. Die Syntax der Symmetrieaussage lautet R  R  .161



ª  «R R ¬



!

º wahr » œ ¼

ª ! «R ¬

R 

!

º » ¼

Formel 14: Formale Semantik für Rollensymmetrie

Rollensymmetrie setzt die Gleichheit von Bild- und Domänenbereich einer Rolle voraus. Allerdings ist die Gleichheit von Bild- und Domänenbereich keine hinreichende Bedingung für Rollensymmetrie. Rollentransitivität sei durch die unten stehende Formel definiert.





! ª º  wahr » œ « R‹ R ¬ ¼ ª a, b, c : º « » ! ! ! « ª ª a,b  R š  b,c  R º Ÿ  a,c  R º » ¼ ¼¼ ¬¬¬

Formel 15: Formale Semantik für Rollentransitivität

160 161

Vgl. Hitzler et al. 2008, S. 166. Vgl. Hitzler et al. 2008, S. 170.

3.4 IDI-Repräsentationssprache

79

Wird eine Konzeptklasse durch eine funktionale Rolle spezifiziert, so soll hierfür, abweichend von der + '!&()-Notation, auch eine funktionale Darstellung möglich sein. Es wird vorgeschlagen, zur Notation funktionaler Zusammenhänge die Doppelklammer ( a b ) zu verwenden. Es sei C eine Konzeptklasse, der durch die funktionale Rolle rolleR ein Individuum ^Ind` zugeordnet wird. Dann lässt sich die Formeldarstellung wie folgt aus einer Klasseninklusion ableiten:

C ‹ rolleR .^Ind ` œ ^Ind `

rolleR a C b

Formel 16: Formale Darstellung funktionaler Rollen

Durch diese extraktive Darstellung einzelner Individuen wird die Möglichkeit eröffnet, in Randbedingungen oder Axiomen Individuenwerte, die unterschiedlichen Konzeptklassen oder durch unterschiedliche Rollen zugewiesen wurden, zu vergleichen oder funktional aufeinander zu beziehen. Diese Darstellungsmöglichkeit ist in + '!&() nicht vorgesehen,162 erleichtert jedoch die Definition von Randbedingungen in der GBox. 3.4.4.3 Individuenaxiome Individuenaxiome ordnen einzelne Individuen bestimmten Klassen oder Individuenpaare bestimmten Rollen zu. Außerdem lässt sich Gleichheit und Ungleichheit zwischen Individuen ausdrücken. Es sei C eine Klasse und a ein Individuum. Dann ist die Klassenaussage C  a genau dann wahr, wenn a ein Individuum der Klasse C ist.163 ª C  a ! ¬«



wahr º œ a !  C ! ¼»



Formel 17: Formale Semantik für Klassenaussagen

162

163

Die Notation der in Abschnitt 3.4.3.4 vorgestellten Konkreten Domänen erlaubt es lediglich, Individuen innerhalb einer Klassendefinition miteinander zu vergleichen oder funktional aufeinander zu beziehen. Vgl. Nardi, Brachman 2002, S. 19.

80

3 Ontologiearchitektur und -sprache

Bei Rollenaussagen ist zwischen Abstrakten und Konkreten Rollen zu unterscheiden. Abstrakte Rollen verbinden Individuen mit Individuen, Konkrete Rollen Individuen mit Datenwerten.164 Die Rollenaussage der Abstrakten Rolle R  a,b gibt an, dass die Individuen a und b durch die Rolle R miteinander verbunden sind.165 ª R a,b ! «¬ 





wahr º œ ª a ! ,b !  R ! º »¼ ¬ ¼

Formel 18: Formale Semantik für Aussagen mit Abstrakten Rollen

Eine Konkrete Rolle T  a,x verbindet das Individuum a mit dem Datenwert x einer Konkreten Domäne. ªT  a, x ! ¬«





wahr º œ ª a ! , x !  T ! º ¬ ¼ ¼»

Formel 19: Formale Semantik für Aussagen mit Konkreten Rollen

Abschließend seien Aussagen über die Gleichheit und Ungleichheit von Individuen betrachtet. Zwei Individuen sind gleich ( a b ), wenn die jeweiligen Individuenbezeichner demselben Individuum zugeordnet sind. Analog sind zwei Individuen ungleich ( a z b ), wenn ihre Bezeichner unterschiedlichen Individuen zugeordnet sind.166 ª a b ! ¬ ª a z b ! ¬

 

wahr º œ a ! b ! ¼ wahr º œ a ! z b ! ¼



Formel 20: Formale Semantik für Gleichheit und Ungleichheit von Individuen

Die Gleichheit oder Ungleichheit von Individuen kann auch durch funktionale Rollen ausgedrückt werden. ƒ Beispiel: rolleR a C b

164 165 166

rolleR a D b .

Vgl. Hitzler et al. 2008, S. 130. Vgl. Nardi, Brachman 2002, S. 19. Vgl. Hitzler et al. 2008, S. 175.

4 Ontologieinhalte und -vokabular 4.1 Forschungsfragen und Kapitelaufbau Das nun folgende Kapitel besitzt zwei inhaltliche Schwerpunkte. Zum einen sollen die erforderlichen Repräsentationsinhalte identifiziert und informal dargestellt werden. Zum anderen soll auf der Basis der identifizierten Repräsentationsinhalte das benötigte Repräsentationsvokabular abgeleitet werden. Im Repräsentationsvokabular manifestiert sich die konzeptionelle Struktur der IDI-Ontologie. Die Bearbeitung der soeben skizzierten Forschungsfragen erfolgt getrennt nach den Ebenen "Syntax" (4.2), "Semantik" (4.3) sowie "Geschäftsdatenpragmatik und Interaktionsprotokolle" (4.4).

4.2 Geschäftsdatensyntax Das in der LBox gespeicherte Syntaxwissen soll einen IDI-Agenten in die Lage versetzen, Geschäftsdaten aus ihrer Syntaxstruktur herauszulösen. In Kapitel 4.2 werden zwei Forschungsziele verfolgt. Erstens sollen mögliche Syntaxmerkmale identifiziert und beschrieben werden. Zweitens soll ein GBox-Vokabular für die identifizierten Syntaxmerkmale definiert werden. Dieses Syntaxvokabular besteht aus Konzeptklassen und Rollen, die dann in einzelnen LBoxen zur syntaktischen Spezifikation von Geschäftsnachrichten verwendet werden können. Das in dieser Arbeit spezifizierte Syntaxvokabular muss für die Syntaxbeschreibung beliebiger Geschäftsnachrichten geeignet sein. Beispielhaft wird dies an einer EDIFACT- und einer XML-Nachricht in Kapitel 6 gezeigt.

A. Köhler, Intelligent Data Interchange (IDI), DOI 10.1007/978-3-8348-9767-1_4, © Vieweg+Teubner Verlag |Springer Fachmedien Wiesbaden GmbH 2010

82

4 Ontologieinhalte und -vokabular

4.2.1 Syntaxwissen – ein informaler Überblick Nach der Definition von Carnap umfasst die Syntax einer Sprache "[...] Regeln [...], [...] nach denen die sprachlichen Gebilde [...] aus Elementen [...] zusammengesetzt sind."167 Dabei wird "[...] auf die Bedeutung der Zeichen [...] und auf den Sinn der Ausdrücke [...] nicht Bezug genommen [...], sondern nur auf Art und Reihenfolge der Zeichen, aus denen die Ausdrücke aufgebaut sind."168 In der IDI-Architektur ist die Syntax von Geschäftsdaten zu beschreiben. Syntaxwissen in IDI-Ontologien umfasst maschinell verarbeitbares Wissen über die syntaktische Identifizierbarkeit von Geschäftsdaten. Syntaktische Identifikationsmerkmale stellen definierte Zeichen, Zeichenketten oder feste Positionsangaben dar, die es erlauben, Geschäftsdateneinheiten zu identifizieren und zu extrahieren. Die Aufgabe von Syntaxwissen besteht darin, die Extraktion der Geschäftsdateneinheiten zu steuern. Dabei werden Geschäftsdaten entsprechend den Eigenschaften der jeweiligen Transportcontainer aus ihrer syntaktischen Hülle herausgelöst und der jeweiligen Anwendungsschnittstelle übergeben. Eine solche Zerlegung und Analyse eines Zeichenstroms wird auch "Parsen" genannt. 169 Geschäftsdatenformate lassen sich durch eine generische Struktur beschreiben. Diese generische Struktur besteht aus Strukturelementen, die unabhängig von bestimmten Syntaxformaten anzutreffen sind. Hierzu gehören Datenfelder, Datenfeldgruppen, Kopfteile, Positionsteile sowie Nachrichten. Datenfelder repräsentieren atomare Transportcontainer und sind daher in allen Geschäftsnachrichten zu finden. Alle anderen Strukturelementtypen müssen nicht zwingend zur syntaktischen Strukturierung einer Geschäftsnachricht verwendet werden.

167 168 169

Carnap 1968, S. 1. Carnap 1968, S. 1. Vgl. Ray 2004, S. 43.

4.2 Geschäftsdatensyntax

83

Die Unterscheidung von Strukturelementen ist von Bedeutung, da jedes Strukturelement eine eigene syntaktische Markierung besitzen kann. Mit einer detaillierten Analyse der Strukturelementtypen befasst sich Kapitel 4.2.3. Geschäftsnachrichten können mehrere Transaktionen (z.B. mehrere Bestellungen) und mehrere Transaktionstypen (z.B. Rechnungen, Bestellungen etc.) enthalten. Aus Vereinfachungsgründen wird angenommen, dass eine Geschäftsnachricht nur aus einer Transaktion besteht. Die Berücksichtigung mehrerer Transaktionen und Transaktionstypen würde zu keinem zusätzlichen Erkenntnisgewinn führen. Die bei Transaktionen und Transaktionstypen zu verwendenden Mechanismen der Syntaxspezifikation entsprechen denen der bereits oben aufgeführten Strukturelementtypen. Der syntaktische Aufbau einer Nachricht und ihrer Strukturelemente soll in den begleitenden Metadaten beschrieben werden. Die Zielsetzung der Speicherung und Übermittlung von syntaxbezogenen Metadaten besteht allerdings nicht darin, das gesamte Regelwerk eines Formatstandards wie beispielsweise EDIFACT zu erfassen und zu formalisieren. Vielmehr spezifizieren Metadaten ausschließlich die Syntaxmerkmale der begleiteten Nachricht.

4.2.2 Formatkategorien Bei der Betrachtung unterschiedlicher Formatstandards lassen sich charakteristische Arten der Syntaxspezifikation erkennen. Diese unterschiedlichen Arten werden in IDI-Ontologien zu den folgenden Formatkategorien zusammengefasst: ƒ Festsatzformate (z.B. MT940)170, ƒ Formate mit Trennzeichen und flexibler Satzlänge (z.B. DTAUS)171,

170

171

Der MT940 ist ein SWIFT-Format für Kontoauszugsdaten. SWIFT steht für "Society for Worldwide Interbank Financial Telecommunication". DTAUS ist ein in Deutschland genutztes Format für die Übermittlung von Zahlungsaufträgen. Vgl. ZKA 2008.

84

4 Ontologieinhalte und -vokabular

ƒ bezeichnergesteuerte Formate (z.B. alle XML-Formate) sowie ƒ Hybridformate (z.B. EDIFACT). Festsatzformate besitzen Transportcontainer mit fester Satzlänge und fester Position. Zur Identifikation der Transportcontainer müssen Syntaxinformationen über Feldlängen und absolute Feldpositionen vorhanden sein. Können einzelne Transportcontainer nicht oder nicht vollständig gefüllt werden, werden die verbleibenden Positionen mit Leerzeichen oder anderen definierten Zeichen aufgefüllt. Trennzeichenformate besitzen flexible Feldlängen. Einzelne Transportcontainer werden durch definierte Trennzeichen voneinander abgetrennt. Leere oder nicht vollständig gefüllte Transportcontainer müssen nicht zwangsläufig gefüllt werden, da das Ende eines Strukturelements durch das entsprechende Trennzeichen angezeigt wird. Bei diesem Formattyp benötigen IDI-Agenten Informationen über die Feldreihenfolge sowie die verwendeten Trennzeichen. Bezeichnerformate begrenzen einzelne Transportcontainer durch definierte Zeichenketten, die ähnlich wie Trennzeichen von einem Parser identifiziert werden können. Im Gegensatz zu den Trennzeichenformaten lassen sich Transportcontainer bei Bezeichnerformaten eindeutig anhand ihres Bezeichners identifizieren. Die Feldreihenfolge spielt daher bei diesem Formattyp nur dann eine Rolle, wenn gleiche Bezeichner für mehrere Transportcontainer verwendet wurden. Das bekannteste Bezeichnerformat ist XML. Eine Einführung zu XML ist in Abschnitt 6.3.1.1 zu finden. Hybridformate sind durch eine Mischung der drei beschriebenen Kategorien gekennzeichnet. Prominentes Beispiel für ein solches Hybridformat ist EDIFACT. EDIFACT trennt einerseits Datenfelder und Datenfeldgruppen durch spezifische Trennzeichen. Andererseits verwendet EDIFACT Bezeichner zur Identifikation und Abtrennung einzelner Segmente.172 Da EDIFACT zudem unterschiedliche Trennzeichen für normale Datenelemente und Gruppendatenelemente einsetzt, werden Informa-

172

Für einen Überblick über EDIFACT vgl. Kapitel 6.2.1.1.

4.2 Geschäftsdatensyntax

85

tionen bzgl. der Segmentreihenfolge sowie der Reihenfolge der in einem Segment verfügbaren Datenelemente und Gruppendatenelemente benötigt. Weiterhin benötigt der Parser Informationen darüber, ob einzelne Segmente, Datenelemente sowie Datenelementgruppen gefüllt werden oder nicht. Die folgende Abbildung vermittelt einen zusammenfassenden Überblick über die identifizierten Formattypen und das benötigte Syntaxwissen zur Identifikation der Transportcontainer. Formattyp

Festsatzformate

- Feldposition - Feldlängen

Trennzeichenformate

- Feldtrennzeichen - Feldreihenfolge

Bezeichnerformate

- Bezeichner - ggf. BezeichnerReihenfolge

Hybridformate (Trennzeichen und Bezeichner)

- Feldtrennzeichen - Feldreihenfolge - Bezeichner - ggf. BezeichnerReihenfolge

Syntaxwissen zur Identifikation von Transportcontainern Abbildung 8: Formatkategorien

4.2.3 Strukturelementtypen 4.2.3.1 Mereologische Struktur Mereologien sind semantische Netze, deren Kanten Teil-GanzesBeziehungen repräsentieren. Weitere Erläuterungen zu Mereologien finden sich in Abschnitt 4.3.3.3. Die meisten EDI-Formatstandards sind durch eine generische Mereologiestruktur gekennzeichnet. Diese Struktur entsteht durch den Einsatz allgemeingültiger Elemente, die in der IDI-Architektur "Strukturelemente" genannt werden. Diese Strukturelemente sollen die Syntaxeigenschaf-

86

4 Ontologieinhalte und -vokabular

ten von Transportcontainern repräsentieren. Jedem Transportcontainer steht in einer LBox genau ein Strukturelement gegenüber. Es lassen sich die folgenden Typen von Strukturelementen unterscheiden: ƒ Nachrichten, ƒ Kopfteile, ƒ Positionsteile, ƒ Datenfeldgruppen, ƒ Datenfelder. Jede dieser Kategorien wird in der GBox durch einen Strukturelementtyp repräsentiert. Alle Strukturelemente, die in LBoxen spezifiziert werden, müssen Spezialisierungen eines GBox-Strukturelementtyps darstellen. Es sei nun die Bedeutung der aufgezählten Strukturelementtypen dargestellt. Übertragungsdateien können aus mehreren Nachrichten bestehen. Jede Nachricht kann einen Kopfteil sowie einen Positionsteil oder mehrere Positionsteile enthalten. Nachrichtentypen wie Rechnungen und Bestellungen verfügen in der Regel über mehrere Positionsteile. Die in den Kopfteilen enthaltenen Geschäftsdaten gelten für alle Positionen einer Nachricht. Beispielsweise gilt eine Bestellnummer für alle Positionen einer Bestellung. Allerdings ist die Trennung von Positionsund Kopfteilen, insbesondere bei Nachrichten mit nur einem Positionsteil, nicht zwingend erforderlich. Es kann die Besonderheit auftreten, dass die zu einem Kopfteil gehörenden Datenfelder keine physische Einheit bilden, da bspw. ein Teil der Kopfteil-Datenfelder am Anfang, ein anderer jedoch am Ende einer Nachricht steht. In diesen Fällen kann aus technischen Gründen die Repräsentation mehrerer Kopfteile erforderlich sein. Positionsteile umfassen diejenigen Transportcontainer, die nur einer bestimmten Position, z.B. einer bestimmten Bestellposition, zugeordnet sind. Bspw. gilt in Rechnungen ein bestimmter Warenpreis nur für diejenigen Positionen, in denen diese Ware enthalten ist.

4.2 Geschäftsdatensyntax

87

Datenfeldgruppen bündeln mehrere, inhaltlich zusammengehörende Datenfelder zu einer strukturellen Einheit. Sie können Bestandteil eines Kopfteils, eines Positionsteils oder einer Nachricht sein. Datenfelder sind die elementarsten Strukturelementtypen einer Geschäftsdatendatei. Sie transportieren Geschäftsdateneinheiten, also die kleinsten interpretierbaren Teile eines Geschäftsdatenstroms. Alle Strukturelemente können mit einer Bedeutungseinheit verbunden sein. Während das Strukturelement die Syntaxeigenschaften eines Transportcontainers spezifiziert, legt die Bedeutungseinheit die Semantik des in diesem Transportcontainer enthaltenen Geschäftsdatenstroms fest. Vor ihrer formalen Definition sei nun zunächst eine allgemeingültige mereologische Struktur173 der Strukturelementtypen dargestellt.

173

Mereologische Beziehungen werden im Kontext der Semantikspezifikation erläutert. Vgl. Abschnitt 4.3.3.3.

88

4 Ontologieinhalte und -vokabular

Übertragungsdatei

Nachricht

Kopfteil

Positionsteil

DF-Gruppe

*

Datenfeld

Abbildung 9: Mereologische Struktur der Strukturelementtypen

Es sein nun zunächst die Konzeptklasse SETypIDI als Oberklasse sämtlicher Strukturelementtypen definiert. § Nachricht IDI ‰ Kopfteil IDI ‰ Positionsteil IDI · ¸ SETypIDI  ¨ ¨ ‰ DF-GruppeIDI ‰ Datenfeld IDI ¸ © ¹ Axiom 1: Konzeptklasse "SETyp"

Strukturelemente können andere Strukturelemente als Komponenten besitzen oder selbst Komponenten anderer Strukturelemente sein. Diese Beziehung soll durch die Rolle hatSER ausgedrückt werden.

4.2 Geschäftsdatensyntax

89

Die Rolle hatSER entspricht der auf der Semantikebene verwendeten Rolle hatKompR .174 Der Unterschied zwischen beiden Rollen besteht darin, dass hatSER mereologische Beziehungen zwischen Strukturelementen definiert, hatKompR hingegen zwischen Bedeutungseinheiten. Es sei nun der Domänen- und Bildbereich der Rolle hatSER definiert. § Positionsteil IDI ‰ Kopfteil IDI ‰ · ¸ F‹ hatSER . ¨ ¨ DF-GruppeIDI ‰ Datenfeld IDI ¸ © ¹ F‹

§ Nachricht IDI ‰ Positionsteil IDI ‰ · ¸ 1 hatSER . ¨ ¨ Kopfteil IDI ‰ DF-GruppeIDI ¸ © ¹

Axiom 2: Domänen- und Bildbereich der Rolle "hatSE"

Der Domänenbereich der Rolle hatSER umfasst alle Strukturelemente, die einem anderen Strukturelement als Holonym zugeordnet sein können. Strukturelemente des Typs "Datenfeld" gehören nicht in diese Aufzählung, weil Datenfelder atomare, nicht weiter teilbare Strukturelemente darstellen. Der Domänenbereich besitzt eine Kardinalität von "1", da Strukturelemente nur einem Holonym zugeordnet sein dürfen. Der Bildbereich enthält alle Strukturelemente, die einem anderen Strukturelement als Meronym175 zugeordnet werden können. Strukturelemente des Typs "Nachricht" gehören nicht in diese Aufzählung, da sich Nachrichten nicht als Meronyme einem anderen Strukturelement zuordnen lassen. Mithilfe der hatSER -Rolle lassen sich nun die einzelnen Strukturelementtypen definieren. Diese Definition spiegelt die in Abbildung 9 dargestellte generische Struktur von Geschäftsdatendateien wider.

174 175

Vgl. Abschnitt 4.3.3.3. Eine Definition des Begriffs "Meronym" findet sich in Kapitel 4.3.3.3.

90

4 Ontologieinhalte und -vokabular

ª § Kopfteil IDI ‰ Positionsteil IDI ‰ · º ¸» Nachricht IDI ‹ «hatSER . ¨ ¨ DF-GruppeIDI ‰ Datenfeld IDI ¸ » «¬ © ¹¼





ªhatSE . DF-GruppeIDI ‰ Datenfeld IDI Šº R » Positionsteil IDI ‹ « « »  IDI 1 hatSE .Nachricht R ¬ ¼





ªhatSE . DF-GruppeIDI ‰ Datenfeld IDI Šº R » Kopfteil IDI ‹ « « »  IDI hatSE .Nachricht 1 R ¬ ¼ ªhatSER .Datenfeld IDI Š DF-GruppeIDI ‹ « « 1 hatSER . Nachricht IDI ‰ Kopfteil IDI ‰ Positionsteil IDI ¬ ª § Nachricht IDI ‰ Kopfteil IDI ‰ ·º ¸» Datenfeld IDI ‹ « 1 hatSER . ¨ ¨ Positionsteil IDI ‰ DF-GruppeIDI ¸ » «¬ © ¹¼





º » » ¼

Axiom 3: Klassendefinitionen der Strukturelementtypen-Klassen

Wie die oben dargestellten Axiome zeigen, kann ein Strukturelement über mehrere Meronyme verfügen, allerdings nur über ein Holonym176. 4.2.3.2 Eigenschaften von Strukturelementen

Ein wichtiges Merkmal zur syntaktischen Identifizierung von Geschäftsinhalten stellt die Reihenfolge von Strukturelementen in einer Nachricht dar. Um diese Reihenfolge feststellen zu können, soll jedes Strukturelement eine Kennzeichnung in Form einer eindeutigen Nummer erhalten. Dabei besitzt jeder Strukturelementtyp einen eigenen Nummernkreis. Die Nummerierung der Strukturelemente erfolgt aufgrund der Reihenfolge ihres Auftretens in einer Nachricht. Es wird vorgeschlagen, die laufenden Nummern von Strukturelementen als Konkrete Domäne zu repräsentieren. Diese Konkrete Domäne verfügt über die folgenden Bestandteile:

176

Zur Definition des Begriffs "Holonym" vgl. Kapitel 4.3.3.3.

4.2 Geschäftsdatensyntax

91

ƒ Die Individuen der Klasse LfdNr IDI , die eine Teilmenge der natürlichen Zahlen darstellen, repräsentieren die Wertemenge der Konkreten Domäne. ƒ Als Datentypeigenschaft sei die Konkrete Rolle hatLfdNrT festgelegt. Diese Rolle weist jedem Strukturelement eine laufende Nummer zu. Dabei müssen die laufenden Nummern innerhalb eines Strukturelementtyps eindeutig vergeben werden. ƒ Außerdem seien noch die binären Prädikate "  ", " ! " und " " hinzugefügt.

Es wird vorgeschlagen, die Konzeptklasse LfdNr IDI in weitere Subklassen zu unterteilen, sodass jede Subklasse den Nummernkreis eines Strukturelementtyps repräsentiert. Nachrichten erhalten keinen eigenen Nummernkreis, da aus Vereinfachungsgründen angenommen wurde, dass eine Geschäftsdatei nur aus einer Nachricht besteht. In der GBox sind die folgenden Konzeptklassen mit jeweils einem eigenen Nummernkreis zur Identifizierung von Strukturelementen vorgesehen: ƒ LfdNr_DF IDI zur eindeutigen Kennzeichnung von Datenfeldern, ƒ LfdNr_DFG IDI zur eindeutigen Kennzeichnung von Datenfeldgruppen, ƒ LfdNr_KT IDI zur eindeutigen Kennzeichnung von Kopfteilen177, ƒ LfdNr_PT IDI zur eindeutigen Kennzeichnung von Positionsteilen.

Die o.g. Konzeptklassen können nun durch eine Inversion der Rolle hatLfdNrT vollständig definiert werden. So ist bspw. die Konzeptklasse LfdNr_DF IDI vollständig definiert als die Menge der Individuen einer

Konkreten Domäne, die genau einem Datenfeld über die hatLfdNrT -Rolle zugeordnet sind.

177

Aus technischen Gründen kann die Repräsentation mehrerer Kopfteile erforderlich sein.

92

4 Ontologieinhalte und -vokabular 1 hatLfdNrT .Datenfeld IDI

LfdNr_DF IDI 

1 hatLfdNrT .DF_GruppeIDI

LfdNr_DFGIDI  LfdNr_KT IDI 

1 hatLfdNrT .Kopfteil IDI

LfdNr_PT IDI 

1 hatLfdNrT .Positionsteil IDI

Axiom 4: Definitionen der Konzeptklassen zur eindeutigen Kennzeichnung von Strukturelementen

Um die Eindeutigkeit der vergebenen Nummern gewährleisten zu können, muss sichergestellt sein, dass jedem Strukturelement genau eine Nummer zugewiesen wird. Diese Einschränkung lässt sich durch eine Definition der betreffenden Strukturelementtypen formulieren. Datenfeld IDI 

1 hatLfdNrT .LfdNr_DF IDI

DF-GruppeIDI  Kopfteil IDI 

1 hatLfdNrT .LfdNr_DFGIDI

1 hatLfdNrT .LfdNr_KT IDI

Positionsteil IDI 

1 hatLfdNrT .LfdNr_PT IDI

Axiom 5: Definition der Strukturelementtypen

Es sei abschließend die Rolle hatBER vorgestellt. Durch diese Rolle werden einzelnen Strukturelementen Bedeutungseinheiten zugeordnet. Der Domänenbereich besteht also aus Strukturelementen, der Bildbereich aus Bedeutungseinheiten. F‹ hatBER .SETypIDI F‹ hatBER .BE IDI Axiom 6: Domänen- und Bildbereich der Rolle "hatBE"

4.2.4 Positionsbestimmung von Strukturelementen 4.2.4.1 Informale Spezifikation

Transportcontainer besitzen Syntaxmerkmale, die zur Identifikation und Extraktion einer bestimmten Geschäftsdateneinheit benötigt werden. Jeder Transportcontainer wird in einer LBox durch genau ein Strukturelement repräsentiert.

4.2 Geschäftsdatensyntax

93

Bei der syntaktischen Markierung von Geschäftsdateneinheiten lassen sich zwei Verfahren unterscheiden. Die direkte Positionsbestimmung sieht die Extraktion der zu einer Bedeutungseinheit gehörenden Geschäftsdateneinheit anhand der Syntaxmerkmale des zugeordneten Strukturelements vor. Bei der indirekten Positionsbestimmung hingegen wird die Position einer Geschäftsdateneinheit bestimmt, indem Start- oder Endemarkierung des zugeordneten Transportcontainers durch die Syntaxmerkmale anderer Transportcontainer beschrieben werden. Diese indirekte Positionsbestimmung ist bspw. dann erforderlich, wenn eine Datenfeldgruppe mit einem bestimmten Datenfeld beginnt und mit einem anderen Datenfeld endet, die Datenfeldgruppe selbst jedoch keine eigene Syntaxmarkierung besitzt. Trotzdem kann diese Datenfeldgruppe über syntaxrelevante Eigenschaften wie bspw. die Wiederholbarkeit verfügen. Somit müssen auch Transportcontainer ohne eigene Syntaxmarkierungen durch Strukturelemente repräsentiert werden. Bei der indirekten Positionsbestimmung sind zwei Eigenschaften zu spezifizieren: ƒ der Transportcontainer, auf den sich die relative Positionsangabe bezieht, ƒ die Entfernung zu diesem Transportcontainer.

Bei einer indirekten Positionsbestimmung könnte bspw. festgelegt werden, dass ein bestimmtes Datenfeld drei Zeichen hinter der Endemarkierung eines anderen Datenfelds beginnt. Vor der formalen Definition des Syntax-Vokabulars soll zunächst dargestellt werden, wie in IDI-Ontologien die syntaktischen Besonderheiten der bereits in Kapitel 4.2.2 identifizierten Formatkategorien berücksichtigt werden sollen. Elektronische Geschäftsnachrichten mit Festsatzformaten können als eine zweidimensionale Matrix betrachtet werden. Dabei sind Beginn und Ende einzelner Transportcontainer durch Schnittpunkte aus Spalten und Zeilen definiert. Um die einzelnen Geschäftsdateneinheiten extrahieren zu können, müssen für die Strukturelemente daher die folgenden Begrenzungspunkte spezifiziert sein:

94

4 Ontologieinhalte und -vokabular

ƒ Zeilenbeginn, Spaltenbeginn, Zeilenende, Spaltenende.

Diese festen Zeilen- und Spaltennummern der Begrenzungspunkte werden in IDI-Ontologien in Relation zum ersten Zeichen der Nachricht angegeben. Trennzeichen- und Bezeichnerformate sollen in IDI-Ontologien nicht getrennt betrachtet werden. Beide Formatkategorien verwenden eine Zeichenkette zur Positionsmarkierung. Bei Trennzeichenformaten besteht diese Zeichenkette nur aus einem Zeichen.

Grundsätzlich gilt, dass jede Begrenzung von Transportcontainern nur durch eines der oben beschriebenen Verfahren markiert werden darf. Die Spezifikation von Begrenzungsmarkierungen soll durch Konkrete Rollen erfolgen. Die unten stehende Tabelle listet die benötigten Rollen auf. Die ersten vier Rollen dienen der Spezifikation von Festsatzformaten. Die Rollen fünf und sechs ermöglichen die Definition von Zeichenketten zur Positionsmarkierung. Die letzten vier Rollen werden zur Spezifikation relativer Positionsmarken benötigt. Die formale Spezifikation erfolgt im nächsten Unterkapitel.

Nr.

Rolle

Bedeutung

1

feZeileStartT

Spezifiziert die Zeilennummer, mit der ein Transportcontainer startet.

2

feZeileEndeT

Spezifiziert die Zeilennummer, mit der ein Transportcontainer endet.

3

feSpalteStartT

Spezifiziert die Spaltennummer, mit der ein Transportcontainer startet.

4

feSpalteEndeT

Spezifiziert die Spaltennummer, mit der ein Transportcontainer endet.

5

zkStartT

Spezifiziert die Zeichenkette, die den Anfang eines Transportcontainers markiert.

6

zkEndeT

Spezifiziert die Zeichenkette, die das Ende eines Transportcontainers markiert.

4.2 Geschäftsdatensyntax Nr.

Rolle

7

startBeiStartT .O  K  x

8

startBeiEndeT .O  K  x

9

endeBeiStartT .O  K  x

10

endeBeiEndeT .O  K  x

Tabelle 6:

95 Bedeutung Spezifiziert die Startmarkierung eines Transportcontainers relativ zur Startmarkierung eines anderen Transportcontainers K . Der Transportcontainer beginnt x Zeichen hinter der Startmarkierung von K. Spezifiziert die Startmarkierung eines Transportcontainers relativ zur Endemarkierung eines anderen Transportcontainers K . Der Transportcontainer beginnt x Zeichen vor der Endemarkierung von K . Spezifiziert die Endemarkierung eines Transportcontainers relativ zur Startmarkierung eines anderen Transportcontainers K . Der Transportcontainer endet x Zeichen hinter der Startmarkierung von K. Spezifiziert die Endemarkierung eines Transportcontainers relativ zur Endemarkierung eines anderen Transportcontainers K . Der Transportcontainer endet x Zeichen vor der Endemarkierung von K.

Informale Semantik von Rollen zur Positionsbestimmung

Bei der Verwendung von Trennzeichen kann der Fall eintreten, dass die Endemarkierung des einen Strukturelements eine Einheit mit der Startmarkierung des folgenden Strukturelements bildet. Eine solche Situation, für die der Begriff "horizontale Trennzeichenteilung" vorgeschlagen wird, muss dem empfangenden IDI-Agenten mitgeteilt werden, da dieser andernfalls keine Startmarkierung für das folgende Strukturelement findet.

96

4 Ontologieinhalte und -vokabular

Entsprechend lässt sich auch die bereits oben angesprochene "vertikale Trennzeichenteilung" spezifizieren. Hierbei tritt eine Identität zwischen ƒ der Startmarkierung eines Strukturelements sowie der Startmarkierung eines seiner Holonyme oder Meronyme oder ƒ der Endemarkierung eines Strukturelements sowie der Endemarkierung eines seiner Holonyme oder Meronyme auf.

Um eine einheitliche Syntaxrepräsentation zu gewährleisten, sollen alle Strukturelemente über eine definierte Start- und Endeposition verfügen, auch wenn sie sich diese Positionsmarkierung horizontal oder vertikal teilen. Die horizontale bzw. vertikale Trennzeichenteilung muss somit über eine jeweils eigene Rolle angezeigt werden können. 4.2.4.2 Formale Spezifikation

Tabelle 6 enthält eine Übersicht aller Rollen, die zur Definition von Start und Ende eines Transportcontainers verwendet werden können. Der Domänenbereich dieser Konkreten Rollen besteht aus der Menge sämtlicher Strukturelemente. Der Bildbereich der Rollen zur Spezifikation fester Positionsmarken (Nr. 1-4) umfasst alle natürlichen Zahlen, die Start oder Ende einer Zeile oder Spalte markieren. Der Bildbereich aller Rollen mit Zeichenketten als Positionsmarke (Nr. 5-6) besteht aus der Menge aller Zeichenketten, die Start oder Ende eines Strukturelements markieren. Bei den Rollen zur Spezifikation relativer Positionsmarken (Nr. 7-10) werden Ώ-Ausdrücke zur Spezifikation von Entfernungsangaben verwendet. Die beiden Lambda-Ausdrücke O  K  x und O  K  x beinhalten die beiden Variablen K und x . K stellt ein beliebiges Strukturelement dar, x eine positive natürliche Zahl. Die beiden Ausdrücke legen fest, dass sich die gesuchte Positionsmarke ƒ x Zeichen rechts von K (Notation:  K  x ) oder ƒ x Zeichen links von K (Notation:  K  x )

befinden soll. Die Konzeptklasse SETypIDI soll in der GBox als oberstes Strukturelement definiert werden. Die folgende Definition spezifiziert also die Eigenschaft sämtlicher Strukturelemente.

4.2 Geschäftsdatensyntax

SETypIDI

ª§ ª «¨ « «¨ «¬ «¨ «¨©   « « § ª «¨ « «¨ «¬ «¨ «¬¨© 

1 feZeileStartT Š 1 zkStartT 1 startBeiStartT ‰ 1 feZeileEndeT Š 1 zkEndeT 1 endeBeiStartT ‰

97 1 feSpalteStartT ’ º · º »’¸ » »¼ ¸ Š» ¸ » ¸ » 1 startBeiEndeT . ¹ » 1 feSpalteEndeT ’ º · » »’¸ » »¼ ¸ » ¸ » ¸ » 1 endeBeiEndeT . ¹ ¼

Axiom 7: Konzeptklasse "SETyp"

Die ersten drei Zeilen der Definition legen fest, durch welche Rollen die Startmarkierungen von Strukturelementen spezifiziert werden können. Die ersten beiden Zeilen sagen aus, dass die Startmarkierung eines Strukturelements entweder durch eine feste Positionsangabe oder durch eine Zeichenkette angegeben werden kann. Im Anschluss wird das Ergebnis dieser ersten Kontravalenz in eine weitere Kontravalenz geschachtelt, die festlegt, dass die Startmarkierung als relative Positionsangabe definiert ist. Die Spezifikation von Endemarkierungen erfolgt analog. Es wird nun die Rolle zur horizontalen Trennzeichenteilung definiert. Um auszudrücken, dass die Endemarkierung des einen identisch zur Startmarkierung des anderen Strukturelements ist, soll die Rolle endeGleichStartR verwendet werden. Der Domänenbereich der Rolle endeGleichStartR soll alle Strukturelemente umfassen, denen über die Rolle zkEndeT eine Zeichenkette als Endemarkierung zugewiesen ist. Entsprechend besteht der Bildbereich aus allen Strukturelementen, denen über die Rolle zkStartT eine Zeichenkette als Startmarkierung zugewiesen ist. F‹ endeGleichStartR .

1 zkEndeT

F‹ endeGleichStartR .

1 zkStartT

Axiom 8: Domänen- und Bildbereich der Rolle "endeGleichStart"

Damit zwei Strukturelemente durch die Rolle endeGleichStartR verbunden werden können, müssen zwei Bedingungen erfüllt sein:

98

4 Ontologieinhalte und -vokabular

ƒ Die Transportcontainer der betreffenden Strukturelemente müssen sich physisch nebeneinander befinden, d.h. die laufende Nummer des Strukturelements aus dem Bildbereich muss um den Wert "1" höher sein wie die Nummer des Strukturelements aus dem Domänenbereich. ƒ Die Zeichenkette zur Endemarkierung des Domänenbereich-Strukturelements muss der Zeichenkette zur Startmarkierung des BildbereichStrukturelements entsprechen.

Beide Zusammenhänge seien nun in einer Randbedingung definiert. Es seien C1 und C2 Konzeptklassen. C1 , C2 :

ªC1 ‹ 1 endeGleichStartT .C2 Ÿ º « » « ª ¬ªhatLfdNrT a C2 b hatLfdNrT a C1 b  1¼º š º » »» «« »¼ » « «¬ ª¬ zkStartT a C2 b zkEndeT a C1 b º¼ ¬ ¼

Bedingung 1: Konsistente Verwendung der Rolle "endeGleichStart"

Es sei nun der Fall der vertikalen Trennzeichenteilung betrachtet. Hier teilen sich zwei Strukturelemente eine Start- oder Endemarkierung, die in einem Meronym-Holonym-Verhältnis zueinander stehen. Damit eine einheitliche Darstellung gewährleistet ist, sollen alle Strukturelemente eine eigene Positionsmarkierung erhalten. Dies gilt auch, wenn sich zwei mereologisch verbundene Konzeptklassen eine Positionsmarkierung teilen. Daher muss dieser Fall der Positionszeichenidentität explizit dargestellt werden. Hierzu sollen die Rollen seGleichStartR und seGleichEndeR verwendet werden. Bild- und Domänenbereiche beider Rollen sind identisch zu denen der Rolle endeGleichStartR . Allerdings stellen seGleichStartR und seGleichEndeR symmetrische Rollen dar, da es für die Rollenbedeutung in diesem Fall keinen Unterschied macht, ob ein Individuum Rollenerster oder -zweiter ist.

4.2 Geschäftsdatensyntax F‹ seGleichStartR .

99 1 zkStartT

seGleichStartR  seGleichStartR F‹ seGleichEndeR .

1 zkEndeT

seGleichEndeR  seGleichEndeR Axiom 9: Domänen- und Bildbereich der Rollen "seGleichStart" und "seGleichEnde"

Die Verwendung beider Rollen setzt zwei Bedingungen voraus: ƒ Bei Verwendung der Rolle seGleichStartR müssen die Startmarkierungen des Rollenersten und Rollenzweiten übereinstimmen. ƒ Bei Verwendung der Rolle seGleichEndeR müssen die Endemarkierungen des Rollenersten und Rollenzweiten übereinstimmen.

Diese notwendigen Bedingungen seien wiederum als Randbedingungen definiert. C1 , C2 :

ªC1 ‹ 1 seGleichStartR .C2 Ÿ º « »š «¬ zkStartT a C1 b zkStartT a C2 b »¼ ªC1 ‹ 1 seGleichEndeR .C2 Ÿ º « » «¬ zkEndeT a C1 b zkEndeT a C2 b »¼

Bedingung 2: Konsistente Verwendung der Rollen "seGleichStart" und "seGleichEnde"

4.2.5 Optionalität von Bedeutungseinheiten Optionalität ist eine häufig genutzte Eigenschaft bei EDI-Formatstandards. Optionalität legt fest, ob bestimmte Elemente von EDI-Nachrichten Nutzdaten enthalten müssen oder nicht. Diese Eigenschaft muss auch in der IDI-Architektur abgebildet werden können. Entsprechend lassen sich Bedeutungseinheiten in zwei Kategorien unterteilen: obligatorische und optionale Bedeutungseinheiten.

100

4 Ontologieinhalte und -vokabular

Wurde in einer Empfangsnachricht178 eine Bedeutungseinheit als obligatorisch gekennzeichnet, so können nur solche Nachrichten empfangen werden, die über eine semantisch äquivalente Bedeutungseinheit verfügen. Zudem muss dieser semantisch äquivalenten Bedeutungseinheit ein gefüllter Transportcontainer zugeordnet sein. Obligatorische Bedeutungseinheiten in Sendenachrichten179 informieren den Empfänger darüber, dass der Sender den zugehörigen Transportcontainer immer mit einer Geschäftsdateneinheit füllen wird. Optionale Bedeutungseinheiten in Empfangsnachrichten ermöglichen es den jeweiligen IDI-Agenten, eine Nachricht auch dann zu akzeptieren, wenn diese über keine äquivalente Bedeutungseinheit verfügt oder der zugeordnete Transportcontainer leer ist. Optionale Bedeutungseinheiten in Sendenachrichten signalisieren, dass der zugeordnete Transportcontainer nicht immer eine Geschäftsdateneinheit enthalten wird.

Es erscheint sinnvoll, die Eigenschaft der Optionalität als Eigenschaft eines Transportcontainers zu repräsentieren, da die Optionalität einer Bedeutungseinheit auch die Syntaxeigenschaften des zugeordneten Strukturelements beeinflussen kann. Optionalität soll in der IDI-Architektur durch die Boole'sche Rolle optionalR repräsentiert werden. Der Domänenbereich dieser Rolle besteht aus Strukturelementen, die durch die Rolle hatBER einer Bedeutungseinheit zugewiesen wurden. F‹

1 optionalR .^wahr ,falsch`



F‹ optional R . SETypIDI Š hatBER



Axiom 10: Domänen- und Bildbereich der Rolle "optional"

178

179

Alle Nachrichten, die von einem IDI-Agenten empfangen werden sollen, werden "Empfangsnachrichten" genannt. Alle Nachrichten, die ein IDI-Agent versenden kann, werden "Sendenachrichten" genannt.

4.2 Geschäftsdatensyntax

101

Der Rolle optionalR kommt vor allem bei der Spezifikation von Empfangsnachrichten eine große Bedeutung zu. Der Nachrichtenempfänger kann durch diese Rolle Anforderungen der Importschnittstellen seiner Anwendungssysteme abbilden. Setzen einzelne Anwendungsschnittstellen bestimme Nachrichteninhalte für den Import zwingend voraus, so muss das Strukturelement, dessen Transportcontainer diesen Nachrichteninhalt transportiert, als obligatorisch gekennzeichnet sein. Aus Syntaxsicht entsteht bei der Optionalität von Strukturelementen dann ein zusätzlicher Repräsentationsbedarf, wenn die Nichtbefüllung von Transportcontainern durch die vorzeitige Terminierung holonymer Transportcontainer angezeigt wird. Vorzeitige Terminierung von Transportcontainern bedeutet, dass optional zu füllende Meronyme dieser Transportcontainer nicht gefüllt wurden. Derartige Terminierungsmechanismen werden bei Formatstandards wie z.B. EDIFACT eingesetzt. Hier signalisiert bspw. das Hochkomma (') das Ende eines Segments. Damit IDI-Agenten derartige Konstellationen erkennen können, ist in den lokalen LBoxen zu hinterlegen, welche Strukturelemente durch welche Holonyme terminiert werden können. Zu diesem Zweck sei die Rolle terminierbarDurchR definiert. Der Domänenbereich dieser Rolle soll aus allen Strukturelementen bestehen, deren Transportcontainer vorzeitig durch ein Holonym terminiert werden können. Hierzu gehören keine Nachrichten, da Nachrichten keine Holonyme besitzen können. Der Bildbereich soll alle Transportcontainer umfassen, die terminieren können. Da Datenfelder über keine Meronyme verfügen, ist dieser Strukturelementtyp nicht Element des Bildbereichs. § § Kopfteil IDI ‰ Positionsteil IDI ‰ · · ¨¨ ¸ Š¸ ‰ Datenfeld IDI ¸¹ ¸ ¨ ¸ ¨ optional .^wahr ` ¸ R © ¹

F‹ terminierbarDurchR . ¨ ¨© DF-GruppeIDI

§ Nachricht IDI ‰ Kopfteil IDI ‰ · ¸ F‹ terminierbarDurchR . ¨ ¨ Positionsteil IDI ‰ DF-GruppeIDI ¸ © ¹ Axiom 11: Domänen- und Bildbereich der Rolle "terminierbarDurch"

102

4 Ontologieinhalte und -vokabular

Als Randbedingung ist zu formulieren, dass das terminierende Strukturelement Holonym des terminierten Strukturelements sein muss. C1 , C2 : ªC1 ‹ terminierbarDurchR .C2 Ÿ º « » « C1 ‹ hatSER .C2 » ¬ ¼





Bedingung 3: Konsistente Verwendung der Rolle "terminierbarDurch"

4.2.6 Wiederholungen Unter einer Wiederholung soll im IDI-Kontext eine Bedeutungseinheit verstanden werden, die innerhalb einer Nachricht über mehrere Geschäftsdateneinheiten verfügen kann. Bspw. könnte die Übertragung mehrerer Telefonnummern vorgesehen sein. Semantisch werden diese Telefonnummern durch dieselbe Bedeutungseinheit spezifiziert. Es erscheint sinnvoll, Wiederholbarkeit auf der Syntaxebene zu repräsentieren, weil Wiederholungen durch bestimmte Syntaxmerkmale gekennzeichnet sein müssen. Zur Kennzeichnung wiederholbarer Strukturelemente ist die Rolle wdhDurchR vorgesehen. Der Domänenbereich der Rolle besteht aus wiederholbaren Strukturelementen, der Bildbereich umfasst Strukturelemente, die die Syntaxeigenschaften von Wiederholungen spezifizieren. Falls die Syntaxeigenschaften der Wiederholung die gleichen sind wie die des Originals, bestehen der Rollenerste und Rollenzweite aus dem gleichen Strukturelement. Strukturelemente, die als Rollenerste der Rolle wdhDurchR zugeordnet sind, werden durch diese Zuordnung als wiederholbar gekennzeichnet. Die Menge der Rollenzweiten umfasst alle Strukturelemente, die die syntaktischen Eigenschaften von Wiederholungen spezifizieren. F‹

1 wdhDurchR .SETypIDI

F‹wdhDurchR .SETypIDI Axiom 12: Domänen- und Bildbereich der Rolle "wdhDurch"

4.3 Geschäftsdatensemantik

103

Jedem wiederholbaren Strukturelement ist genau ein WiederholungsStrukturelement zugeordnet. Wiederholungs-Strukturelemente hingegen können unterschiedlichen Strukturelementen zugeordnet sein.

4.3 Geschäftsdatensemantik 4.3.1 Semantikwissen – ein informaler Überblick Semantikwissen enthält Wissen über die Bedeutung von Geschäftsdateneinheiten. Aufgabe des Semantikwissens ist es, das ontologische Matching, also die automatisierte Identifizierung semantisch äquivalenter Konzeptklassen, zu steuern.180 Im Idealfall kann durch das ontologische Matching jeder empfangenen Bedeutungseinheit ein semantisches Äquivalent in der LBox des Empfängers zugeordnet werden. Semantik bezeichnet die Lehre von der Bedeutung sprachlicher Ausdrücke bzw. von der Bedeutung beliebiger Zeichen.181 Bedeutung entsteht, wenn die Zeichenfolgen bestimmten Objekten und Phänomenen der Realität zugeordnet werden. Zeichenketten mit einer bestimmten Bedeutung verweisen also immer auf Gegenstände, Zustände oder Ereignisse.182 Die Anreicherung von Symbolfolgen mit einer formalen Semantik ist eine Voraussetzung, um sinnvoll maschinelle Operationen auf diesen Symbolfolgen durchführen zu können. Eine für die IDI-Architektur bedeutsame maschinelle Operation besteht in der Identifikation semantisch äquivalenter Konzeptklassen. Semantische Anreicherung im Kontext der IDI-Architektur bedeutet also, eine Konzeptklasse mit der Menge und Art an Informationen auszustatten, dass ein maschineller Aufgabenträger inhaltsgleiche von inhaltsverschiedenen Konzeptklassen unterscheiden kann. Dabei nimmt der semantische Gehalt in dem Maße zu, wie mögliche Interpretationen ausgeschlossen werden können.

180 181 182

Das Thema "ontologisches Matching" ist Gegenstand von Kapitel 5. Vgl. Lorenz 2004b, S. 768. Vgl. Picot et al. 2003, S. 90.

104

4 Ontologieinhalte und -vokabular "Je mehr Semantik eine Symbolfolge aufweist, desto besser sind tendenziell die Möglichkeiten einer automatisierten Auswertung."183

Fraglich ist, mittels welcher semantischen Spezifikationsmittel ein möglichst hoher Grad an semantischer Eindeutigkeit erreicht werden kann. Angenommen, auf Geschäftsdatenebene wird eine Geschäftsdateneinheit mit der Bezeichnung "Bank" übertragen. Ohne weitere Angaben ist der semantische Gehalt dieser Zeichenfolge offensichtlich sehr gering. Es kann sich etwa um ein Kreditinstitut oder eine Sitzgelegenheit handeln. Wird die Annahme aufgegeben, dass Objekte der Realität mit den in der deutschen Sprache dafür vorgesehenen Zeichenfolgen symbolisiert werden, könnte die Zeichenfolge "Bank" sogar jedes beliebige Phänomen der Realität symbolisieren. Wird nun die semantische Spezifikation der Zeichenfolge "Bank" um die Eigenschaft „Breite“ und einen Eigenschaftswert "2,50m" erweitert, wird dem menschlichen Betrachter klar, dass die Interpretation "Kreditinstitut" sehr unwahrscheinlich ist. Für den maschinellen Aufgabenträger jedoch ist eine solche Schlussfolgerung nur dann möglich, wenn Wissen darüber repräsentiert ist, wie breit ein Kreditinstitut üblicherweise zu sein hat bzw. dass Breite kein sinnvolles Attribut für ein Kreditinstitut ist. Angenommen, die semantische Spezifikation enthielte eine weitere Information, dass es sich bei der Zeichenfolge „Bank“ um eine Sitzgelegenheit handelt. Möglicherweise ist der maschinelle Aufgabenträger nun in der Lage, die Zeichenfolge „Bank“ eindeutig nicht als Kreditinstitut zu interpretieren, da sich in seiner Ontologie die Interpretation „Kreditinstitut“ und die Information „ist eine Sitzgelegenheit“ eindeutig ausschließen. Es lässt sich somit festhalten, dass der semantische Gehalt dann am größten ist, wenn ein maschineller Aufgabenträger als Empfänger und Interpretant einer Nachricht aufgrund der semantischen Spezifikation die Anzahl divergierender Interpretationen auf Null reduzieren kann, sodass nur noch die vom Sender intendierte Interpretation verbleibt.

183

Frank, Schauer 2001, S. 170.

4.3 Geschäftsdatensemantik

105

4.3.2 Ableitung der semantischen Spezifikationsmittel Zur Semantikspezifikation sind in der IDI-Architektur fünf Merkmale vorgesehen: ƒ der Konzeptklassenname, ƒ der taxonomische Kontext, ƒ der mereologische Kontext, ƒ der Attributkontext sowie ƒ die Geschäftsdatenstruktur.

Es ist nun zu klären, aus welchen Gründen die genannten Merkmale zur Semantikrepräsentation verwendet werden sollen. Das Matching von Konzeptnamen weist mehrere Vorteile auf. ƒ Sofern Konzeptklassennamen Worte einer natürlichen Sprache sind, verweisen diese Namen im Idealfall auf genau ein Ding bzw. eine Kategorie von Dingen der Realität.184 Somit sind Konzeptklassennamen dazu geeignet, die Zahl der denkbaren Interpretationsmöglichkeiten einer Konzeptklasse erheblich einzuschränken. ƒ Ontologisches Matching auf Basis von Konzeptklassenbezeichnern ist geeignet, Mappings mit einer Kardinalität >1 zu finden.185 Bspw. könnte anhand von Konzeptnamen erkannt werden, dass eine Konzeptklasse "Straße und Hausnummer" semantisch äquivalent zu zwei anderen Konzeptklassen "Straße" und "Hausnummer" ist. ƒ Das Matching von Konzeptklassennamen erfordert keinen Rückgriff auf andere, vorangegangene Matchingergebnisse, sofern durchgehend Konzeptbezeichner vergeben wurden.

Es sei darauf hingewiesen, dass Ehrig und Staab in einer Untersuchung mehrerer Matchingverfahren dem Matching von Konzeptklassenbezeichnern eine herausragende Bedeutung zuschreiben:

184 185

Vgl. Magnini et al. 2002, S. 3. Vgl. Rahm, Bernstein 2001a, S. 340.

106

4 Ontologieinhalte und -vokabular "Labels are very important for mapping, if not the most important feature of all, and alone return very satisfying results."186

Viele Dinge der Realität lassen sich in sog. Taxonomien einordnen. Taxonomien sind Begriffshierarchien, deren Elemente in einem Generalisierungs-/ Spezialisierungsverhältnis stehen.187 Zudem gilt in Taxonomien das Vererbungsprinzip. Somit vererben Konzeptklassen ihre Eigenschaften an spezialisierte Nachkommen.188 Es wird deutlich, dass taxonomische Beziehungen eine hohe semantische Aussagekraft für die verbundenen Konzepte besitzen. Durch die Einordnung in einen taxonomischen Kontext kann die Anzahl der für eine Konzeptklasse infrage kommenden Interpretationsalternativen erheblich eingeschränkt werden. Die Nutzung mereologischer Beziehungen als semantische Spezifikationsmittel bietet sich in der IDI-Architektur besonders an. So sind mereologische Strukturen für viele EDI-Formatstandards charakteristisch. Bspw. besitzen EDIFACT-Nachrichtentypen eine hierarchische Struktur, in der u.a. Datenfelder als Elemente von Datenfeldgruppen oder Datenfeldgruppen als Elemente von Kopfteilen oder Positionsteilen definiert werden. Aber auch properietäre Formate verfügen oftmals über eine vergleichbare Strukturierung. So ist etwa die hierarchische Gliederung und Verschachtelung von Markups eine inhärente Eigenschaft von XMLDokumenten. Diese Strukturierung und Gliederung erfolgt auch nach inhaltlichen Kriterien. So sieht etwa der EDIFACT-Standard eine Zusammenfassung inhaltlich zusammengehörender Datenfelder zu Datenfeldgruppen oder Segmenten vor. Es erscheint sinnvoll, eine solche, auch an Inhalten ausgerichtete, mereologische Strukturierung zur Semantikrepräsentation zu nutzen.

186 187 188

Ehrig, Staab 2004, S. 13. Vgl. Brachman, Levesque 2004, S. 172. Vgl. Brachman, Levesque 2004, S. 176.

4.3 Geschäftsdatensemantik

107

Attributbeziehungen ermöglichen es, Eigenschaften zu spezifizieren, die für die Interpretation von Konzepten hilfreich sein können.

Die Geschäftsdatenstruktur schließlich stellt kein Konzeptklassenmerkmal im ontologischen Sinne dar. Vielmehr wird durch dieses semantische Spezifikationsmittel versucht, einen kausalen Zusammenhang zwischen den strukturellen Eigenschaften eines Geschäftsdatenstroms und seiner Bedeutung herzustellen. Bspw. werden Datumsangaben häufig in der Struktur "TT.MM.JJJJ"189 angegeben. Immer dann, wenn Geschäftsdaten über eine solche oder eine ähnliche Struktur verfügen, kann somit inhaltlich von einer Datumsangabe ausgegangen werden. Es wird deutlich, dass unterschiedliche Merkmalskategorien zur Semantikspezifikation herangezogen werden können. Dies macht eine Kombination unterschiedlicher Matchingansätze erforderlich, weil nicht bei allen semantischen Merkmalen das gleiche Matchingverfahren genutzt werden kann. Zudem haben Untersuchungen gezeigt, dass von einer Kombination mehrerer Matchingansätze qualitativ bessere Mappingresultate zu erwarten sind als von Einzelansätzen.190 Dies ist insb. dann der Fall, wenn bestimmte Merkmale oder Eigenschaften nicht immer verfügbar sind. Ist bspw. kein taxonomischer Kontext für eine Konzeptklasse definiert, dann kann diese Konzeptklasse nicht in den Matchingprozess einbezogen werden, wenn semantische Äquivalenz ausschließlich auf Basis des taxonomischen Kontextes bestimmt würde. Die folgenden Abschnitte befassen sich mit der formalen Spezifikation der semantischen Merkmale.

4.3.3 Semantische Spezifikationsmittel 4.3.3.1 Konzeptklassennamen

Als Repräsentationsvokabular für Konzeptklassennamen werden zwei Elemente benötigt: eine Konzeptklasse für die Konzeptklassennamen

189 190

TT = Tag; MM = Monat; JJJJ = Jahr. Vgl. Tang et al. 2005, S. 3; Ehrig, Sure 2004, S. 77; Rahm, Bernstein 2001a, S. 343.; Do, Rahm 2002, S. 12.

108

4 Ontologieinhalte und -vokabular

und eine Rolle, mit der diese Namen einer Konzeptklasse zugewiesen werden können. Die Konzeptklasse Bezeichner IDI repräsentiert Namen für Bedeutungseinheiten. Diese Namen werden den einzelnen Bedeutungseinheiten über die Rolle hatBezR zugewiesen. Dabei darf jeder Name nur einmal vergeben werden. Gleichzeitig kann eine Bedeutungseinheit nur über genau einen Namen verfügen. Es sei nun der Domänen- und Bildbereich der Rolle hatBezR definiert. F‹ hatBezR .Bezeichner IDI F‹ hatBezR .BE IDI Axiom 13: Domänen- und Bildbereich der Rolle "hatBez"

Zur Überwindung der noch zu betrachtenden Bezeichnerheterogenität kann es für einen IDI-Agenten vorteilhaft sein, über eine Liste synonymer Konzeptnamen zu verfügen. Synonyme Konzeptnamen stellen Zeichenketten dar, die als Symbole für gleiche Realweltphänomene verwendet werden. Bspw. werden die Zeichenketten "Bank" und "Kreditinstitut" oft synonym für den gleichen Sachverhalt genutzt. Die explizite Definition von Synonymen trägt zur semantischen Spezifikation einer Konzeptklasse bei. Durch die Angabe einer Menge synonymer Zeichenketten wird die Zahl möglicher Interpretationen eingeschränkt. Zur Repräsentation von Bezeichner-Synonymen wird in der IDI-Architektur die symmetrische Rolle synVonR verwendet. Diese Rolle verbindet zwei Konzeptklassen mit synonymen Konzeptklassenbezeichnern. Sowohl der Domänen- wie auch der Bildbereich dieser Rolle bestehen aus Bedeutungseinheiten. Alle Bedeutungseinheiten sind Spezialisierungen der GBox-Konzeptklasse BE IDI . F‹ synVonR .BE IDI F‹ synVonR .BE IDI Axiom 14: Domänen- und Bildbereich der Rolle "synVon"

Zusätzlich sei auch eine Konzeptklasse hatSynonymR definiert. Im Gegensatz zu der Rolle synVonR ist hatSynonymR asymmetrisch. Sie weist

4.3 Geschäftsdatensemantik

109

einer Bedeutungseinheit einen synonymen Bezeichner zu. Der Domänenbereich besteht somit aus Bedeutungseinheiten, der Bildbereich aus Individuen der Konzeptklasse Bezeichner IDI . F‹ hatSynonymR .Bezeichner IDI F‹ hatSynonymR .BE IDI Axiom 15: Domänen- und Bildbereich der Rolle "hatSynonym"

Der Zusammenhang zwischen den Rolle synVonR und hatSynonymR sei durch die folgende Randbedingung ausgedrückt. C1 , C2 : ªC1 ‹ synVonR .C2 œ « « ª ª hatBezR .C1 ‹ hatSynonymR .C2 ««¬ ««ª   «¬ «¬ ¬ hatBezR .C2 ‹ hatSynonymR .C1

 

 



º » º ›º» ¼ »» » º »» ¼ ¼ »¼

Bedingung 4: Konsistente Verwendung der Rollen "hatSynonym" und "synVon"

Die oben formulierte Randbedingung sagt aus, dass im Fall der Synonymie zwischen zwei Konzeptklassen C1 und C2 entweder der Bezeichner von C1 eine Teilmenge der Synonyme von C2 oder der Bezeichner von C2 eine Teilmenge der Synonyme von C1 sein muss. 4.3.3.2 Taxonomische Beziehungen

Taxonomien bestehen aus Ober- und Unterklassenbeziehungen zwischen Konzepten. Diese Beziehungen drücken Generalisierungs- und Spezialisierungsrelationen zwischen den betrachteten Konzeptklassen aus. Kennzeichnend für Unterklassen ist, dass sie alle Merkmale und Relationen ihrer Oberklassen erben.191 Unterklassen einer Konzeptklasse werden als Hyponyme, Oberklassen als Hyperonyme bezeichnet.192 Die folgende Abbildung illustriert die grafische Darstellung von Taxonomien in dieser Arbeit. 191 192

Vgl. Russel, Norvig 2004, S. 400. Vgl. Löbner 2003, S. 133.

Hyperonym

Hyponym1

Hyponym2

Hyponym3

Generalisierung

4 Ontologieinhalte und -vokabular Spezialisierung

110

Abbildung 10: Grafische Darstellung von Taxonomien

Bei der visuellen Darstellung von Taxonomienetzen werden Konzeptklassen in dieser Arbeit als Rechtecke und Beziehungen als Kanten zwischen den Knoten (Rechtecken) dargestellt. Die Pfeilspitzen zeigen immer auf ein Hyperonym. Taxonomische Netze sollen in der LBox durch die Rolle hyperVonR abgebildet werden. Diese Rolle verbindet zwei Bedeutungseinheiten, wobei der Rollenerste das Hyperonym und der Rollenzweite das Hyponym darstellt. Zwar werden sowohl Domänen- wie auch Bildbereich dieser Rolle aus Bedeutungseinheiten gebildet. Allerdings handelt es sich bei hyperVonR nicht um eine symmetrische Rolle. F‹ hyperVonR .BE IDI F‹ hyperVonR .BE IDI hyperVonR Š hyperVonR

‡

Axiom 16: Domänen- und Bildbereich der Rolle "hyperVon"

Die Bedeutung taxonomischer Beziehungen für die Identifikation semantisch äquivalenter Konzeptklassen beruht auf der Annahme, dass semantisch äquivalente Konzeptklassen über einen gleichen oder zumindest ähnlichen taxonomischen Kontext verfügen. Unter einem taxonomischen Kontext wird die Menge aller Konzeptklassen verstanden, die in einer Taxonomie in einem direkten Verwandtschaftsverhältnis zu der betrachteten Konzeptklasse stehen. Auf der Seite der Nachkommen sind dies Kinder, Enkel, Urenkel etc. Auf Seiten der Vorfahren sind Eltern, Großeltern etc. zu berücksichtigen. Zu klären ist, bis zu welchem Verwandtschaftsgrad Konzeptklassen bei der Bestimmung der taxonomischen Ähnlichkeit berücksichtigt werden

4.3 Geschäftsdatensemantik

111

sollen. Es ist zu postulieren, dass mit abnehmendem Verwandtschaftsgrad die semantische Aussagekraft einer taxonomischen Beziehung abnimmt. Reimer stellt einen Zusammenhang zwischen der semantischen Nähe und der Entfernung zwischen zwei Knoten in einem semantischen Netz her: "Es ergibt sich somit (zumindest tendenziell) eine umso längere Kantenfolge zwischen zwei Konzepten, je geringer ihre semantische Nähe ist, denn sind zwei Konzepte inhaltlich weit voneinander entfernt, muß ihr Bezug zueinander über eine Reihe von Zwischenknoten hergestellt werden."193

Zwar wird erst in Kapitel 5 geklärt, bis zu welchem Verwandtschaftsgrad Konzeptklassen im taxonomischen Kontext berücksichtigt werden. Allerdings sei an dieser Stelle die Funktion : C1 ,C2 vorgestellt. Diese Funktion gibt den direkten taxonomischen Abstand zwischen den Konzeptklassen C1 und C2 zurück. Daher nimmt : C1 ,C2 umso größere Werte an, je mehr Knoten (Konzeptklassen) sich zwischen C1 und C2 befinden. Der kleinste Wert beträgt "1". In diesem Fall wäre C1 ein direkter Nachkomme von C2 oder umgekehrt. 4.3.3.3 Mereologische Beziehungen

Als eine wichtige semantische Beziehung wird die Beziehung zwischen den Teilen einer Sache und einem Ganzen betrachtet.194 Solche Beziehungen werden in sog. Mereologien repräsentiert. Mereologien sind Begriffshierarchien, die im Gegensatz zu Taxonomien aus Teil-GanzesBeziehungen aufgebaut sind. Konzeptklassen in Mereologien lassen sich in zwei Kategorien aufteilen: Meronyme sind Konzepte, die als Teile zu einem Ganzen gehören. Holonyme sind Konzepte, die aus mehreren Teilen bestehen.

193 194

Reimer 1991, S. 145. Vgl. Winston et al. 1987, S. 417.

112

4 Ontologieinhalte und -vokabular "A ist genau dann ein Meronym von B, und B ein/ das Holonym von A, wenn ein potenzieller Referent von A durch die Bedeutung von A als konstitutiver Teil eines potenziellen Referenten von B konzipiert ist."Konstitutive Teile" sind dabei zu verstehen als wesentliche Teile, die das Ganze zu dem machen, was es ist."195

Für die IDI-Architektur wird festgelegt, dass mereologische ebenso wie taxonomische Beziehungen über die Eigenschaft der Transitivität verfügen. Somit gilt: ist B ein Meronym von A und C ein Meronym von B, dann ist auch C ein Meronym von A. Zur Repräsentation mereologischer Beziehungen sei die Rolle hatKompR vorgeschlagen. Der Domänenbereich dieser Rolle besteht aus Homonymen, der Bildbereich umfasst die zugehörigen Meronyme. Sowohl Meronyme wie auch Holonyme sind Bedeutungseinheiten. Da sich der mereologische Kontext einer Bedeutungseinheit aus dem mereologischen Kontext der zugeordneten Strukturelemente ergibt, kann der Domänenund Bildbereich dieser Rolle nur aus Bedeutungseinheiten bestehen, die einem Strukturelement zugeordnet sind. Die Rolle hatKompR ist asymmetrisch.

 F‹ hatKompR .  BE IDI Š hatBER F‹ hatKompR . BE IDI Š hatBER

hatKompR Š hatKompR

‡

Axiom 17: Domänen- und Bildbereich der Rolle "hatKomp"

Bei einer grafischen Darstellung von Mereologien werden Beziehungen als Kanten und Konzeptklassen als Knoten dargestellt. Die Rauten verweisen auf die übergeordneten Holonyme.

195

Löbner 2003, S. 135.

4.3 Geschäftsdatensemantik

113 Holonym

Meronym 1

Meronym 2

Meronym 3

Abbildung 11: Grafische Darstellung von Mereologien

Mereologien zur Semantikspezifikation sollen in der IDI-Architektur aus der mereologischen Struktur der Strukturelemente abgeleitet werden. Die in Abbildung 9 dargestellte Struktur wird also auf die Semantikebene übertragen. Dabei werden alle Strukturelemente berücksichtigt, denen eine Bedeutungseinheit zugeordnet ist. Analog zur taxonomischen Distanz lässt sich auch eine mereologische Distanz angeben. Die in dieser Arbeit als mereologische Distanz bezeichnete Funktion < C1 ,C2 gibt den direkten vertikalen Knotenabstand zwischen den Konzeptklassen C1 und C2 an. Eine Einschränkung des maximal zu berücksichtigenden Verwandtschaftsgrads ist in Mereologien nicht erforderlich. Der Verwandtschaftsgrad wird durch den Umfang der Strukturelemente-Mereologie begrenzt. 4.3.3.4 Attributbeziehungen, Werttypen und Maßeinheiten Attribute stellen atomare Merkmale einer Konzeptklasse dar und können über Attributwerte verfügen. Bspw. könnte ein Attribut "Farbe" den Attributwert "blau" besitzen. Da Attribute ausschließlich der semantischen Spezifikation dienen, sollen nur Bedeutungseinheiten mit Attributen versehen werden können.

Fraglich ist, wie Attribute strukturell repräsentiert werden sollen. Einerseits könnte für jedes Attribut eine eigene Rolle definiert werden. Ande-

114

4 Ontologieinhalte und -vokabular

rerseits wäre es denkbar, Attribute als Konzeptklassen zu repräsentieren und über eine vordefinierte Rolle zuzuweisen.196 Für die IDI-Architektur wird vorgeschlagen, beide Strategien miteinander zu kombinieren und sowohl eine Attributrolle wie auch eine Attributkonzeptklasse, jeweils mit gleicher Bezeichnung, zu definieren. Diese Strategie erscheint aus mehreren Gründen vorteilhaft: ƒ Durch den Einsatz von Attributrollen lässt sich der Domänen- und Bildbereich dieser Attributrolle festlegen. Es kann also bspw. festgelegt werden, welche Konzepte über ein bestimmtes Attribut verfügen dürfen und welche Attributwerte durch ein bestimmtes Attribut zugeordnet werden können. ƒ Zudem besteht die Möglichkeit, den Wertebereich der Attributrollen durch Quantifizierungen und Kardinalitätsangaben einzugrenzen. ƒ Werden Attribute zudem in Form von Konzeptklassen repräsentiert, so können alle beschriebenen Klassenkonstruktoren zur Attributdefinition verwendet werden.

Um Attributrollen von den bislang definierten Rollen besser unterscheiden zu können, werden alle Attributrollen-Bezeichner mit dem Index " A " versehen. Alle Attributrollen müssen eine Spezialisierungen der Rolle attribut A darstellen. Der Domänenbereich dieser Rolle besteht aus Bedeutungseinheiten. Der Bildbereich umfasst die Individuen der Konzeptklasse Attribut IDI . Diese Individuen repräsentieren die Attributwerte. Es erscheint wenig sinnvoll, die Kaskadierung von Attributen zuzulassen. Bei einer solchen Kaskadierung würde das eine Attribut durch ein anderes semantisch spezifiziert. Folglich dürfen Attribute nicht zum Domänenbereich der Rolle attribut A gehören.

196

Vgl. hierzu die Diskussion in Noy 2005.

4.3 Geschäftsdatensemantik

115

F‹ attribut A .Attribut IDI



F‹ attribut A . BE IDI Š ™Attribut IDI



Axiom 18: Domänen- und Bildbereich der Rolle "attribut"

Zur allgemeinen Typisierung der Individuenmengen von Bedeutungseinheiten wird die Rolle werttypR vorgeschlagen. Werttypen repräsentieren einfache strukturelle Merkmalskategorien. Für komplexere strukturelle Merkmale von Individuenmengen ist die Spezifikation Regulärer Ausdrücke vorgesehen.197 Der Domänenbereich der Rolle werttypR umfasst zwei Individuenmengen: ƒ Bedeutungseinheiten, die einem Strukturelement zugeordnet sind und somit Geschäftsdateneinheiten semantisch spezifizieren, ƒ Attribute.

Der Bildbereich besteht aus den Individuen der Konzeptklasse WerttypIDI . F‹ werttypR .WerttypIDI F‹ werttypR . ªhatBER ‰ Attribut IDI º ¬ ¼ Axiom 19: Domänen- und Bildbereich der Rolle "werttyp"

Die Individuenmenge der Konzeptklasse WerttypIDI besteht aus Datentypen.198 Die im nachfolgenden Axiom definierte Liste von Datentypen lässt sich im Bedarfsfall erweitern. WerttypIDI  ^Integer ,Decimal ,String,Boole,Time,Date` Axiom 20: Konzeptklasse "Werttyp"

197 198

Vgl. Abschnitt 4.3.3.5 Die Konzeptklasse "Werttyp" umfasst die wichtigsten primitiven Datentypen von XML Schema. Vgl. Biron, Malhotra 2004.

116

4 Ontologieinhalte und -vokabular

Es sei festgelegt, dass nur solchen Konzeptklassen die Werttypen ^Integer ` und ^Decimal ` zugeordnet werden dürfen, die Zahlzeichen (Ziffern) repräsentieren, denen eine Maßeinheit zugeordnet werden kann. Als Beispiele für Zahlzeichen, die über keine Maßeinheiten verfügen, seien Postleitzahlen und Hausnummern genannt. Konzeptklassen, die solche Zahlzeichen repräsentieren, soll der Werttyp ^String` zugeordnet werden. Der Unterschied zwischen den Werttypen und den in Kapitel 3.4.3.4 beschriebenen Datentypen besteht darin, dass Werttypen die Individuenmengen von Konzeptklassen typisieren. Datentypen hingegen typisieren Bildbereiche Konkreter Rollen. In beiden Fällen lassen sich die gleichen Typen verwenden. Neben der Spezifikation von Werttypen besteht auch die Möglichkeit, eine konkrete Wertemenge vorzugeben. Solche Wertemengen lassen sich als abgeschlossene Klassen von Bedeutungseinheiten abbilden. Die Übereinstimmung eines empfangenen Geschäftsdatenstroms oder Attributwertes zu einem der in der Wertemenge einer lokalen Konzeptklasse spezifizierten Werte stellt eine notwendige Bedingung für die semantische Äquivalenz der betrachteten Konzeptklassen dar. Als eine weitere Form der semantischen Spezifikation sei die Rolle hatMaßeinheitR eingeführt. Attributwerte in numerischer Form beruhen oft auf einer Maßeinheit. Aber auch in Geschäftsnachrichten lassen sich viele Datenfeldinhalte durch Maßeinheiten semantisch spezifizieren. Die Spezifikation von Maßeinheiten ermöglicht es, mit geringem Aufwand ein hohes Maß an semantischer Ausdruckskraft zu erreichen. Als Beispiele für Normierungen von Maßeinheiten seien das von der ISO herausgegebene Verzeichnis für Währungsabkürzungen (ISO 4217199) sowie das internationale Einheitensystem für physikalische Einheiten (SI-System, "Système international d'unités") genannt. Die SI-Einheiten

199

Internet-Adresse: http://www.iso.org/iso/en/prods-services/popstds/currencycodeslist.html.

4.3 Geschäftsdatensemantik

117

werden in Deutschland und anderen Ländern als gesetzliche Einheiten für den amtlichen und geschäftlichen Verkehr genutzt.200 Der Bildbereich der Rolle hatMaßeinheitR wird durch die Konzeptklasse Maßeinheit IDI repräsentiert. Diese Konzeptklasse besteht aus der Menge

aller Maßeinheitenzeichen.201 Der Domänenbereich der Rolle hatMaßeinheitR umfasst alle Konzeptklassen, die auch als Domänenbereich der Rolle werttypR fungieren202 und denen entweder der Werttyp ^Dezimal ` oder ^Integer ` zugeordnet ist. F‹

1 hatMaßeinheitR .Maßeinheit IDI

F‹ hatMaßeinheitR . ª¬werttypR . ^Integer ` ‰ ^Dezimal ` º¼ Axiom 21: Domänen- und Bildbereich der Rolle "hatMaßeinheit"

Konzeptklassen können nur über eine Maßeinheit verfügen. Allerdings kann jede Maßeinheit beliebig vielen Konzeptklassen zugeordnet sein. Die folgende Abbildung stellt den strukturellen Zusammenhang zwischen Attribut-, Maßeinheiten- und Werttypen-Beziehungen grafisch dar.

BEIDI

attributR

werttypR

WerttypIDI

hatMaßeinheitR

MaßeinheitIDI

AttributIDI

Abbildung 12: Attribut-, Maßeinheiten- und Werttypenbeziehungen

Ergänzend sei angemerkt, dass Werttypen und Maßeinheiten auch für Bedeutungseinheiten definiert werden können, die einem Strukturelement zugeordnet sind.

200 201 202

Vgl. PTB 2004. Vgl. PTB 2004. Vgl. Axiom 19.

118

4 Ontologieinhalte und -vokabular

4.3.3.5 Die Geschäftsdatenstruktur

Strukturspezifikationen für Geschäftsdaten nehmen in der IDI-Architektur zwei Funktionen wahr: ƒ Sie erlauben es, aus der fehlenden Kompatibilität einer empfangenen Geschäftsdateneinheit mit der Strukturspezifikation einer lokalen Konzeptklasse auf die semantische Inäquivalenz der betrachteten Konzeptklassen zu schließen. ƒ Somit ermöglichen Strukturspezifikationen eine deutliche Reduktion des Suchraums nach semantisch äquivalenten Konzeptklassenpaaren.

Mächtige Instrumente zur Darstellung struktureller Anforderungen an Geschäftsdaten stellen sog. Reguläre Ausdrücke (RA) dar. In der Automatentheorie werden RA zur Definition Regulärer Sprachen verwendet.203 In der IDI-Architektur sollen RA genutzt werden, um die zulässige Struktur aller zu einer Bedeutungseinheit gehörenden Geschäftsdateneinheiten zu beschreiben. Die Kompatibilität einer Geschäftsdateneinheit zum Regulären Ausdruck einer Konzeptklasse ist eine notwendige Bedingung dafür, dass die betrachtete Geschäftsdateneinheit ein gültiges Individuum der betrachteten Konzeptklasse ist. In vielen bestehenden EDI-Systemen wird der Inhalt von Transportcontainern durch Datentypen wie bspw. Integer, Boolean oder Float eingeschränkt. Merkmal zahlreicher EDI-Standards ist auch die Möglichkeit, minimale oder maximale Feldlängen zu spezifizieren. Die Verwendung Regulärer Ausdrücke ermöglicht es, darüber hinausgehende, noch detailliertere Beschreibungen der strukturellen Eigenschaften von Geschäftsinhalten zu hinterlegen. Für eine vertiefende Darstellung der Syntax und Semantik Regulärer Ausdrücke sei auf die entsprechende Literatur verwiesen.204

203 204

Hopcroft et al. 2002, S. 96. Vgl. z.B. Socher 2003, S. 42-50; Hopcroft et al. 2002, S. 93-99. Für eine Darstellung von Regulären Ausdrücken in XML Schema vgl. Skulschus, Wiederstein 2004, S. 122-130.

4.3 Geschäftsdatensemantik

119

Der Verwendung Regulärer Ausdrücke als semantisches Spezifikationsmittel liegt die Annahme zugrunde, dass die zu semantisch äquivalenten Konzeptklassen gehörenden Geschäftsdaten oft über ein kleinstes gemeinsames Grundmuster verfügen. Ein solches Grundmuster findet sich bspw. bei Straßenangaben. Sie enthalten meistens eine Zeichenkette, gefolgt von einer Zahl und gegebenenfalls einem an die Zahl angehängten Buchstaben. Die Zeichenkette endet meistens mit den Zeichen "str." oder "straße". Alternativ können auch zwei Zeichenketten und eine Zahl angegeben sein, wobei die zweite Zeichenkette oft "Weg" oder "Allee" lautet. Der folgende Reguläre Ausdruck sei als ein Beispiel für die Struktur typischer amerikanischer Straßennamen angeführt.205 [0-9]+[A-Z]? [A-Z][a-z]*( [A-Z][a-z]*)* (Street|ST\.|Avenue|Ave\.|Road|Rd\.)

Zur Repräsentation Regulärer Ausdrücke soll die Rolle hatRegR eingesetzt werden. Der Domänenbereich dieser Rolle bleibt auf alle Bedeutungseinheiten beschränkt, die einem Datenfeld zugeordnet sind. Der Bildbereich besteht aus der Menge Regulärer Ausdrücke, die durch die Konzeptklasse RAIDI repräsentiert werden. Jedem Datenfeld kann nur ein Regulärer Ausdruck zugeordnet werden.



F‹ hatReg R . hatBER .Datenfeld IDI F‹



1 hatReg R .RAIDI

Axiom 22: Domänen- und Bildbereich der Rolle "reg"

4.3.4 Codierung von Geschäftsinhalten Im Normalfall werden die in einzelnen Transportcontainern übermittelten Geschäftsdaten nach dem Nachrichtenempfang extrahiert und an die entsprechenden Anwendungssysteme des Empfängers übergeben. Dies ist in den Fällen nicht möglich, in denen Geschäftsinhalte codiert von

205

Entnommen aus: Hopcroft et al. 2002, S. 123.

120

4 Ontologieinhalte und -vokabular

den Anwendungsschnittstellen bereitgestellt werden. Da nicht sichergestellt werden kann, dass Sender und Empfänger die gleichen Codelisten verwenden, sind die Codes in eine Klartextdarstellung zu transformieren. Als Beispiel sei das EDIFACT-Datenfeld 7065 (Package type description code) genannt. Die zugehörige Codeliste206 umfasst alle Codes, die in diesem Feld transportiert werden können. Bspw. steht der Code "PX" für "Palette", "GB" für "Gasflasche" etc. Zur Verknüpfung von Bedeutungseinheiten, die über codierte Geschäftsdateneinheiten verfügen, mit einer Klartextbezeichnung ist die Rolle hatKlartextR vorgesehen. Der Domänenbereich der Rolle besteht aus Bedeutungseinheiten, die einem Datenfeld zugeordnet wurden. Der Bildbereich umfasst die Konzeptklasse Klartext IDI , die sämtliche Individuen repräsentiert, die als Klartext für einen codierten Geschäftsdatenstrom gesendet werden können.



F‹ hatKlartextR . BE IDI Š hatBER .Datenfeld IDI F‹

1 hatKlartextR .Klartext



IDI

Axiom 23: Domänen- und Bildbereich der Rolle "hatKlartext"

4.3.5 Konzepte mit einer gemeinsamen semantischen Basis Zahlreiche Geschäftsnachrichten verfügen über Bedeutungseinheiten mit identischer semantischer Basis. Beispielhaft seien Datumsangaben genannt. Alle Datumsangaben besitzen eine semantische Gemeinsamkeit: sie bezeichnen einen kalendarischen Zeitpunkt hinsichtlich Tag, Monat und Jahr. Die in Geschäftsnachrichten verwendeten Datumsangaben stellen Spezialisierungen dieses allgemeinen Konzepts dar. Als Beispiele für solche Spezialisierungen seien etwa ein Zahlungsdatum oder ein Bestelldatum genannt. Es erscheint sinnvoll, zur Vermeidung von Heterogeni-

206

Vgl. UN/ECE 2008.

4.3 Geschäftsdatensemantik

121

tätseffekten die gemeinsame semantische Basis in Form von GBoxKonzeptklassen vorzudefinieren. Es sei nun die Konzeptklasse DatumIDI vollständig durch ihre mereologische Beziehung zu den drei Konzeptklassen Tag IDI , Monat IDI und Jahr IDI definiert. § DatumIDI  ¨ ¨ ©

1 hatKompR .Tag IDI Š 1 hatKompR .Jahr IDI

1 hatKompR .Monat IDI Š · ¸ ¸ ¹

Axiom 24: Konzeptklasse "Datum"

Tag, Mona und Jahr wiederum lassen sich am einfachsten durch die Aufzählung ihrer Individuen definieren. Tag IDI  ^01,02,03,! , 30 , 31` Monat IDI  ^01,02,! ,11,12` Jahr IDI  ^1900 ,1901,!` Axiom 25: Konzeptklassen "Tag", "Monat" und "Jahr"

Auch Adressangaben sind häufig in Geschäftsnachrichten zu finden. Es sei vereinfachend angenommen, dass die Konzeptklasse AdresseIDI über die Bestandteile NameIDI , StraßeIDI , Hausnummer IDI , PLZ IDI und Ort IDI verfügen kann. ª § NameIDI ‰ StraßeIDI ‰ Hausnummer IDI ‰ · º ¸» AdresseIDI ‹ «hatKompR . ¨ ¨ PLZ IDI ‰ Ort IDI ¸» «¬ © ¹¼ Axiom 26: Konzeptklasse "Adresse"

Bei der Definition des Adressnamens sei angenommen, dass ausschließlich Firmennamen gesendet werden. Firmennamen verfügen stets über einen Zusatz, der über ihren Gesellschaftstyp Auskunft gibt. Somit lässt

122

4 Ontologieinhalte und -vokabular

sich durch einen Regulären Ausdruck festlegen, dass alle Adressnamen über die Endung "GmbH", "AG" oder "GbR" verfügen müssen.207 NameIDI ‹ hatReg R .^[.]+(GmbH|AG|GbR)` Axiom 27: Konzeptklasse "Name"

Reguläre Ausdrücke werden formal als Individuen betrachtet und somit in geschwungenen Klammern notiert. Der Punkt zwischen den eckigen Klammern steht für ein beliebiges Zeichen. Das "+" hinter der eckigen Klammer legt fest, dass dieses beliebige Zeichen beliebig oft wiederholt werden darf. Die sich anschließende runde Klammer beinhaltet eine Auswahl von drei Zeichenketten, die am Ende des zu analysierenden Zeichenstroms stehen müssen. Das Pipe-Symbol ("|") repräsentiert alternativ gültige Zeichenketten. Die Struktur von Straßennamen mit Hausnummern ist dadurch gekennzeichnet, dass die betreffenden Zeichenketten über ein charakteristisches Ende wie "...straße", "...str." oder " Weg" verfügen. StraßeIDI ‹ hatRegR .^[.]+(straße|str.|Weg)` Axiom 28: Konzeptklasse "Straße"

Der oben dargestellte Reguläre Ausdruck beginnt wie der für die Konzeptklasse NameIDI . Mit der Zeichenkette [.]+ wird angezeigt, dass ein beliebiges Zeichen beliebig oft wiederholt werden darf. Die sich anschließende Auswahlliste legt die Zeichenketten fest, mit denen die zu analysierende Zeichenfolge enden darf. Hausnummern setzen sich aus den Zahlen 0 bis 9 zusammen und besitzen mindestens eine, maximal jedoch vier Stellen. Der eigentlichen Hausnummer darf noch ein Buchstabenzusatz folgen.

207

Aus Vereinfachungsgründen bleibt die Betrachtung auf diese drei Gesellschaftstypen beschränkt, auch wenn zahlreiche weitere Typen – insb. auf der internationalen Ebene – existieren.

4.3 Geschäftsdatensemantik

123

Hausnummer IDI ‹ hatRegR .^[0-9]{1,4}[A-Za-z]?` Axiom 29: Konzeptklasse "Hausnummer"

Die Zeichenkette [0-9]{1,4} zeigt an, dass Hausnummern aus mindestens einer, maximal jedoch vier Ziffern bestehen und aus den Zeichen 0 bis 9 gebildet werden. Die Zeichenfolge [A-Za-z]? verdeutlicht, dass der Hausnummer ein beliebiger Buchstabe in Groß- oder Kleinschrift folgen darf. Das Fragezeichen ist ein Quantor, der angibt, dass der vorgenannte Buchstabe vorkommen kann, aber nicht muss. Städtenamen bestehen ausschließlich aus Buchstaben. Bei der Formulierung eines Regulären Ausdrucks für die entsprechende Konzeptklasse kann daher auf die bereits oben verwendete Zeichenkette [A-Za-z] zurückgegriffen werden, die sämtliche Buchstaben in Groß- und Kleinschrift enthält. Da die Länge des Städtenamens nicht beschränkt werden soll, wird als Quantor das Pluszeichen angehängt. Stadt IDI ‹ hatRegR .^[A-Za-z]+` Axiom 30: Konzeptklasse "Stadt"

Auch die Postleitzahl besitzt eine einfach zu definierende Struktur. Sie besteht immer aus fünf Ziffern. PLZ IDI ‹ hatRegR .^[0-9] ^5`` Axiom 31: Konzeptklasse "PLZ"

124

4 Ontologieinhalte und -vokabular

4.4 Geschäftsdatenpragmatik und Interaktionsprotokolle 4.4.1 Geschäftsdatenpragmatik 4.4.1.1 Die Sprechakttheorie als Grundlage des Pragmatikvokabulars

Die Pragmatik ist ein aus der Philosophie heraus entstandenes Forschungsgebiet, das sich mit handlungstheoretischen Untersuchungen befasst. Einen wesentlichen Schwerpunkt bildet hierbei die sog. "Sprechakttheorie".208 Levinson stellt "[...] die Erforschung der Sprache aus funktionaler Perspektive [...]"209 als eine der Aufgaben der Pragmatikforschung heraus. Eine bedeutende Rolle spielt die Sprechakttheorie in der Agentenforschung; die meisten Kommunikationssprachen für intelligente Softwareagenten basieren auf der Sprechakttheorie.210 Als wichtigste Vertreter sog. Agentensprachen seien die "Knowledge Query and Manipulation Language"211 (KQML) und FIPA-ACL212 (Agent Communication Language) genannt. Für die IDI-Architektur sollen die Pragmatikforschung im Allgemeinen und die Sprechakttheorie im Speziellen einen Analyse- und Klassifizierungsrahmen liefern, der es erlaubt, die in Geschäftsnachrichten implizit oder explizit vorhandenen Handlungsabsichten zu identifizieren, zu kategorisieren und in ein entsprechendes Repräsentationsvokabular zu überführen. Als Beispiele für Handlungsabsichten seien die Abgabe einer bindenden Willenserklärung oder einer Aufforderung gegenüber dem Kommunikationspartner genannt.

208 209 210 211 212

Vgl. Apel, Habermas 2004, S. 323. Levinson 1994, S. 7. Vgl. Berges et al. 2008, S. 8. Vgl. Finin et al. 1993. Vgl. FIPA 2002.

4.4 Geschäftsdatenpragmatik und Interaktionsprotokolle

125

Zielsetzung des nun folgenden Abschnitts ist es, aus der Sprechakttheorie Erkenntnisse für die Repräsentation von Pragmatikwissen und Interaktionsprotokollen abzuleiten. Die Sprechakttheorie beschäftigt sich mit der Rolle von Sprache als Handlung.213 Dem zugrunde liegt die Hypothese, dass Kommunizieren bzw. Sprache sprechen immer auch das Ausführen von Sprechakten bedeutet.214 Durch die Äußerung von Worten und Sätzen wird der Zustand der Welt verändert, der Äußernde hat mit seiner Äußerung somit eine sprachliche Handlung vollzogen. „Sprechakte [...] sind die grundlegenden oder kleinsten Einheiten der sprachlichen Kommunikation.“215

Die Sprechakttheorie ist Bestandteil der Pragmatikforschung bzw. der Semiotik.216 Nach Searle setzen sich ein Sprechakt aus drei Teilakten zusammen: dem lokutionären, dem propositionalen und dem illokutionären Akt.217 Der Äußerungsakt bzw. der lokutionäre Akt umfasst die Lautäußerung an sich. Bei IDI-Agenten ist der Äußerungsakt gleichbedeutend mit dem Versenden, also dem "Äußern" einer Nachricht. Der Äußerungsakt spielt für die Wissensrepräsentation in IDI-Ontologien keine Rolle. Der propositionale Akt besteht aus einer Referenz und der Prädikation. Allgemein wird über die Referenz der Bezug zu einem Objekt hergestellt, das als Gegenstand des Sprechakts betrachtet werden kann. Searle verknüpft mit der Referenz den Begriff des "hinweisenden Ausdrucks".218 Für einen hinweisenden Ausdruck ist charakteristisch, "[...] daß seine Äußerung dazu dient, ein 'Objekt' oder eine 'Entität' oder ein Einzelding, in Bezug auf daß der Sprecher dann etwas sagt

213 214 215 216 217 218

Vgl. Singh 1993, S. 50. Vgl. Searle 1983, S. 30. Searle 1983, S. 30. Vgl. Meibauer 2001, S. 84. Vgl. Searle 1983, S. 40. Searle 1983, S. 43.

126

4 Ontologieinhalte und -vokabular oder eine Frage stellt usw., als abgesondert von anderen Objekten herauszugreifen und zu identifizieren. Jeden Ausdruck, der dazu dient, ein Ding, einen Prozeß, ein Ereignis, eine Handlung oder sonstige Arten von 'Individuen' oder 'partikularen Objekten' zu identifizieren, nenne ich einen hinweisenden Ausdruck."219

Die Sprechakttheorie interpretiert eine Prädikation als die Zuweisung von Eigenschaften zu den referenzierten Objekten. Diese Eigenschaftszuweisung erfolgt meistens in Form eines Verbs.220 Der illokutionäre Akt spezifiziert die Wirkung eines Sprechakts auf den Kommunikationspartner. Die Illokution ist ein "[...] Akt, den man vollzieht, indem man etwas sagt, im Unterschied zu dem Akt, dass man etwas sagt".221 Beispiele für Illokutionen sind "auffordern", "fragen" oder "sich verpflichten". Analyseobjekt der Sprechakttheorie ist die natürliche Sprache. Im Vergleich zur Struktur der natürlichen Sprache weisen Interaktionsbeziehungen zum Austausch elektronischer Geschäftsdokumente eine wesentlich geringere Komplexität auf. Allerdings sind die oben identifizierten Grundbausteine auch in IDI-Interaktionsbeziehungen vorzufinden. Als Referenz können die betroffenen Unternehmen bzw. die sie vertretenden IDI-Agenten betrachtet werden. Als Prädikation ist die Nachricht bzw. die Nachrichtenbedeutung anzusehen. Illokutionen legen die Wirkung einer Nachricht fest und bestimmen, welchen Veränderungen die reale Welt durch den Vollzug des illokutionären Akts unterworfen ist. Fraglich ist nun, welche Schlussfolgerungen sich hieraus für die Wissensrepräsentation in IDI-Ontologien ergeben. Referenzen werden in Form von Agentenklassen und ihren Individuen repräsentiert.222 Die Spezifikation der Nachrichtenbedeutung ist Gegenstand der Semantikebene.

219 220 221 222

Searle 1983, S. 44. Vgl. Meibauer 2001, S. 87. Austin 1979, S. 117. Vgl. Abschnitt 4.4.2.

4.4 Geschäftsdatenpragmatik und Interaktionsprotokolle

127

Illokutionen sollen in IDI-Ontologien bestimmen, was mit einer Nachricht als Ganzes geschehen soll. Sie spezifizieren nicht die Bedeutung der Nachricht selbst, sondern die mit einer Nachricht verbundene Handlungsabsicht. Daher sind Illokutionen Repräsentationsgegenstand der Pragmatikebene. Welche vordefinierten Illokutionen in der IDI-Ontologien zur Verfügung gestellt werden, ist dem folgenden Abschnitt zu entnehmen. 4.4.1.2 Ableitung der IDI-Illokutionen

Die illokutionäre Kraft einer elektronischen Geschäftsnachricht wird in bestehenden EDI-Architekturen nicht explizit dargestellt. Trotzdem ist zu postulieren, dass jeder Nachrichtentyp klassischer EDI-Standards wie etwa EDIFACT über eine eindeutig zu bestimmende illokutionäre Kraft verfügt. Den Nachweis hierzu hat Moore in einer Studie erbracht. Zielsetzung der Studie war es u.a., 125 EDIFACT- und 41 SWIFT-Nachrichtentypen mindestens einer Illokution zuzuordnen.223 Für den Standard EDIFACT ist das Ergebnis der Studie in der folgenden Tabelle zusammengefasst. Die Spalte 1 enthält pro Zeile eine der von Moore identifizierten Illokutionen. Spalte 2 zeigt, mit welcher Häufigkeit die einzelnen Illokutionen bei den 125 Nachrichtentypen entdeckt wurden. Spalte 3 liefert eine kurze Beschreibung der Illokution. Spalte 4 schließlich zeigt die illokutionäre Kraft am Beispiel eines EDIFACT-Nachrichtentyps.

223

Vgl. Moore 1998.

128 Illokution

4 Ontologieinhalte und -vokabular Anz.

Beschreibung

Bsp. für EDIFACT-Nachrichtentyp und Beschreibung

confirmative 6

Bestätigung einer bereits gesendeten Nachricht.

ORDRSP; kann von einem Verkäufer dazu genutzt werden, eine Bestellung des Käufers zu bestätigen.

descriptive

36

Beschreibende bzw. PRICAT; dient dem Austausch von Katalogdaten erläuternde zwischen Handelspartnern. Nachricht.

disputative

1

Anfechtende Nach- RECADV; fungiert als Melricht. dung über die erfolgte physische Warenlieferung und kann zur Mitteilung über Lieferabweichungen genutzt werden.

informative

24

Mitteilende Nachricht.

IFTDGN; Information über Gefahrengüter einer Gütersendung.

predictive

20

Vorankündigung von Ereignissen oder Handlungen.

DEBADV; zeigt eine noch zu erfolgende Kontobelastung an.

retrodictive

28

Anzeige vergange- DEBADV; zeigt eine erfolgte ner Ereignisse bzw. Kontobelastung an. erfolgter Handlungen.

permissive

3

Autorisierende Nachricht.

COREOR; gestattet die Abholung von Containern.

4.4 Geschäftsdatenpragmatik und Interaktionsprotokolle

129

Illokution

Anz.

Beschreibung

Bsp. für EDIFACT-Nachrichtentyp und Beschreibung

requestive

22

Abfragende bzw. anfordernde Nachricht.

ORDCHG; Anfrage zur Änderung eines Kaufauftrags.

requirement 12

Anfordernde bzw. COREOR; Aufforderung zur auffordernde Nach- Containerfreigabe. richt.

offer

5

Anbietende Nachricht.

JOBAPP; Bewerberangebote für Arbeitgeber von einer Arbeitsagentur.

promise

7

Versprechende bzw. verpflichtende Nachricht.

IFTMIN; Benachrichtigung eines Versenders durch einen Frachtführer über aktuelle Details oder Konditionen des durchzuführenden Versands.

effective

17

Bewirkt Veränderungen hinsichtlich des institutionellen Status von Personen, Organisationen oder Dingen.

INVOIC; Rechnung.

verdictive

1

Rechtlich bindende Erklärungen einer Behörde oder Institution.

SANCRT; beinhaltet Zertifikate für den Warenimport und -export.

Tabelle 7:

Illokutionen der EDIFACT-Nachrichtentypen (Quelle: in Anlehnung an Moore 1998, S. 225)

Die zitierte Studie erlaubt es, eine Liste der für die IDI-Architektur relevanten Illokutionen abzuleiten. Die meisten der durch Moore identifizierten Illokutionen wurden in diese IDI-Liste übernommen; an einigen Stellen wurde die Moore-Liste erweitert. Bspw. erscheint es sinnvoll, mit

130

4 Ontologieinhalte und -vokabular

"Rejective" über eine Illokution zu verfügen, die als explizite Ablehnung auf die Illokutionen "Requestive" und "Offer" gesendet werden kann. Fraglich ist, wie sich eine konsistente Verwendung der Illokutionen sicherstellen lässt. Es wird vorgeschlagen, Rahmenbedingungen zu formulieren, die bei der Verwendung bestimmter Illokutionen einzuhalten sind. Eine formale Spezifikation dieser Rahmenbedingungen scheint nicht erforderlich zu sein, da hierauf kein maschineller Zugriff erfolgen muss. Es wird die Spezifikation der folgenden Rahmenbedingungen vorgeschlagen: ƒ Vorbedingungen, die zur Verwendung einer Illokution erfüllt sein müssen; ƒ Rechte und Pflichten, die sich durch den Einsatz der Illokution für den Sender (S) oder den Empfänger (E) ergeben; ƒ Bedeutung der Geschäftsdaten; ƒ Das von S intendierte Ergebnis.

Auf Basis der Moore-Klassifikation wurde eine für die IDI-Architektur gültige Liste von Illokutionen erarbeitet. Diese Liste besteht aus den folgenden Illokutionen: Assertive, Offer, Acceptance, Authorization Request, Permissive, Requirement, Confirmative, Requestive, Rejective, Feedback, Informative, Predictive, Retrodictive, Verdictive, Declarative, Service, ProtOffer, ProtAccept, ProtReject.

Eine tabellarische Erläuterung der o.a. Illokutionen unter Berücksichtigung der oben formulierten Rahmenbedingungen ist in Anhang B zu finden. Für jede IDI-Illokution werden Bedeutung, Vorbedingungen und Ergebnis informal definiert. Hierzu gehört auch eine kurze inhaltliche Beschreibung des Nachrichteninhalts, den die Illokution spezifiziert. Die Beispiele zeigen jeweils auf, in welchen Anwendungssituationen die einzelnen IDI-Illokutionen verwendet werden sollen. Um einen Bogen zur klassischen EDI-Welt zu schlagen, wird beispielhaft ein EDIFACT-Nachrichtentyp erwähnt, der in der genannten Anwendungssituation verwendet werden könnte.

4.4 Geschäftsdatenpragmatik und Interaktionsprotokolle

131

An dieser Stelle sei stellvertretend für alle im Anhang dargestellten Illokutionen die Illokution "Assertive" dargestellt. Die unten stehende und auch im Anhang vorhandene Tabelle spezifiziert die Rahmenbedingungen, die zur Nutzung der Illokution erfüllt sein müssen.

IDI-Illokution

Assertive

Bedeutung

Der Sender (S) verpflichtet sich auf die Wahrheit der in der Nachricht (N) übermittelten Inhalte, geht jedoch darüber hinaus keine Verpflichtung ein. Es handelt sich also um eine Information und keine Willenserklärung, aus der heraus sich weitere Pflichten für S ergäben.

Nachrichteninhalt

Informationen, die S dem Empfänger (E) mitteilen möchte.

Vorbedingung S möchte, dass E von den Inhalten der Nachricht (N) Kenntnis erlangt. Ergebnis

E hat Kenntnis über N erlangt.

Beispiel

Katalog- und Preisinformationen (EDIFACT: PRICAT)

Tabelle 8:

Illokution "Assertive"

Die letzten vier IDI-Illokutionen der oben gezeigten Liste dienen dem Austausch von Service- bzw. Protokollnachrichten. Servicenachrichten enthalten keine Geschäftsdaten, sondern kommunizieren einen fachlichen Status. Sie können bspw. dazu dienen, den Empfang oder die erfolgreiche bzw. fehlgeschlagene Interpretation der Geschäftsdaten zu kommunizieren. Aufgrund ihrer untergeordneten Bedeutung für das Thema dieser Arbeit werden Servicenachrichten nicht weiter betrachtet. Protokollnachrichten dienen der Vereinbarung und fachlichen Steuerung von Nachrichtensequenzen. Eine detaillierte Darstellung ist in Abschnitt 4.4.2 zu finden. Abschließend sei angemerkt, dass Illokutionen als Eigenschaften sog. Sendevorgängen zugeordnet werden. Die formale Definition der zugehörigen Konzeptklassen und Rollen wird daher in Abschnitt 4.4.2.3 beschrieben.

132

4 Ontologieinhalte und -vokabular

4.4.2 Interaktionsprotokolle 4.4.2.1 Elemente und Aufgaben von Interaktionsprotokollen

Die Definitionen von Agenten- bzw. Interaktionsprotokollen224 in der Literatur weisen oft nur geringe Unterschiede auf. Odell etwa definiert die Bedeutung von Agentenprotokollen wie folgt: "An agent interaction protocol (AIP) describes a communication pattern as an allowed sequence of messages between agents and the constraints on the content of those messages."225

Ähnliche Definitionen sind auch bei Paurobally und Cunningham226, Walton und Robertson227 sowie Nowostawski et al.228 zu finden. Interaktionsprotokolle haben in der IDI-Architektur die Aufgabe, kausale, logische und zeitliche Abhängigkeiten zwischen Geschäftsnachrichten zu definieren. Ohne ein gemeinsames Verständnis über diese Abhängigkeiten können Kommunikationspartner keine Nachrichten austauschen. Die Zielsetzung dieses Kapitels (4.4.2) und seiner Unterkapitel besteht darin, eine konzeptionelle Protokollarchitektur zu entwerfen, die es ermöglicht, Protokolle zur Laufzeit zu vereinbaren. Diese Architektur soll aus drei grundlegenden Bausteinen bestehen: Sendevorgängen, Agentenklassen und Randbedingungen zur Spezifikation zeitlicher oder kausaler Abhängigkeiten zwischen Sendevorgängen. Sendevorgänge stellen die Hauptbestandteile von IDI-Interaktionsprotokollen dar. Sie sollen die Handlungsabsicht der zugehörigen Geschäftsnachricht spezifizieren, die es dem empfangenden IDI-Agenten ermöglicht, die Geschäftsnachricht der Senderintention entsprechend zu verwenden. Darüber hinaus stellen Sendevorgänge Anknüpfungspunkte zur Spezifikation protokollspezifischer Eigenschaften und Randbedin-

224 225 226 227 228

Beide Begriffe sollen in dieser Arbeit synonym verwendet werden. Odell et al. 2001, S. 125. Vgl. Paurobally, Cunningham 2002, S. 1. Vgl. Walton, Robertson 2002, S. 2. Vgl. Nowostawski et al. 2001, S. 4.

4.4 Geschäftsdatenpragmatik und Interaktionsprotokolle

133

gungen dar. Eine detaillierte Betrachtung und formale Spezifikation der Eigenschaftskategorien von Sendevorgängen erfolgt in Abschnitt 4.4.2.3. Agentenklassen sollen Mengen von Agentenindividuen repräsentieren, die jeweils über gemeinsame Eigenschaften, Schnittstellen oder Dienste verfügen.229 In der IDI-Architektur sollen Agentenklassen vor allem genutzt werden, um die Sender und Empfänger von Sendevorgängen festzulegen. Zur formalen Spezifikation von Agentenklassen siehe Abschnitt 4.4.2.2. Randbedingungen dienen der Formulierung notwendiger Konsistenzbedingungen. Hierzu gehören auch kausale und zeitliche Abhängigkeiten zwischen Sendevorgängen.

Kausale und zeitliche Abhängigkeiten ergeben sich oftmals aus den Anforderungen der Anwendungsschnittstellen. Bspw. könnte ein Besteller auf seine Bestellung innerhalb von 24 Stunden eine Bestellbestätigung verlangen. Die Herausforderung in der IDI-Architektur besteht darin, dass Protokolle dynamisch, d.h. zur Laufzeit, vereinbart werden müssen. Diese Anforderung lässt sich mit zwei alternativen Strategien erfüllen. Zum einen könnten alle relevanten Protokolle ex ante definiert und mit einer formalen oder informalen Semantik versehen werden. Der Nachteil dieser Strategie besteht in der mangelnden Flexibilität, da bei einer zentralen Spezifikation von Interaktionsprotokollen nicht alle denkbaren Anwendungssituationen bekannt sind. Ad-hoc-Kommunikation wäre in diesem Szenario nur bei Nutzung der vorhandenen Konversationsprotokolle möglich. Zum anderen ließe sich ein standardisiertes Vokabular bereitstellen, das alle zur Beschreibung eines Konversationsprotokolls erforderlichen Konzepte und Rollen enthielte. Damit wären die Anwender in der Lage, auf ihre jeweilige Anwendungssituation zugeschnittene Protokolle zu spezifizieren. Allerdings würde bei dieser Strategie ein Metaprotokoll benötigt, das den Prozess der Protokollvereinbarung regelt ("Semantic Hand-

229

Vgl. Bauer et al. 2001, S. 97.

134

4 Ontologieinhalte und -vokabular

shake Protocol"230). Diese Strategie wird in der vorliegenden Forschungsarbeit verfolgt. Für eine detaillierte Darstellung des Metaprotokolls sei auf Abschnitt 4.4.3 verwiesen. In den drei Folgeabschnitten werden die drei identifizierten Bestandteile von IDI-Protokollen detailliert beschrieben. 4.4.2.2 Agentenklassen

Agentenklassen repräsentieren Mengen von Agentenindividuen, die innerhalb eines Protokolls die Rolle eines Senders oder Empfängers einnehmen können. Agentenklassen stellen Spezialisierungen der Konzeptklasse Agent IDI dar. Zwar besitzen Agentenklassen Namen, die die Funktionen der in den Agentenklassen enthaltenen Individuen widerspiegeln sollen. So könnten Agentenklassen bspw. die Bezeichnungen "Besteller" oder "Fuhrunternehmer" tragen. Allerdings sind diese Bezeichnungen nicht Gegenstand eines ontologischen Matchingprozesses. Vielmehr ergibt sich die Bedeutung der einzelnen Agentenklassen implizit aus den Sendevorgängen, die sie innerhalb eines Protokolls empfangen oder senden müssen. Da Interaktionsprotokolle erst zur Laufzeit vereinbart werden können, steht u.U. auch erst zur Laufzeit fest, welche Agentenindividuen den einzelnen Agentenklassen zugeordnet sind. Im einfachsten Fall besteht ein Interaktionsprotokoll aus zwei Agentenklassen mit jeweils einem IDI-Agenten. Die Rollen hatSenderR sowie hatEmpfängerR legen fest, welche Agentenklassen als Sender bzw. Empfänger der einzelnen Sendevorgänge fungieren. Somit umfasst der Domänenbereich beider Rollen die Menge aller Sendevorgänge; der Bildbereich besteht aus der Konzeptklasse Agent IDI . Während ein Agent beliebig viele Sendevorgänge senden und empfangen und ein Sendevorgang durch beliebig viele Agenten empfangen werden kann, können Sendevorgänge nur durch einen Agenten gesendet werden.

230

Euzenat et al. 2004, S. 6.

4.4 Geschäftsdatenpragmatik und Interaktionsprotokolle

135

Alle Sendevorgänge sind Spezialisierungen der GBox-Konzeptklasse Sendung IDI . F‹

1 hatSenderR .Agent IDI

F‹ hatSenderR .Sendung IDI F‹ hatEmpfängerR .Agent IDI F‹ hatEmpfängerR .Sendung IDI Axiom 32: Domänen- und Bildbereiche der Rollen "hatSender" und "hatEmpfänger"

Als Randbedingung ist zu formulieren, dass Sender und Empfänger eines Sendevorgangs aus unterschiedlichen Individuenmengen bestehen müssen. Mit anderen Worten darf die Konjunktionsrolle hatSenderR Š hatEmpfängerR

keine Individuenpaare beinhalten, sondern muss leer sein. hatSenderR Š hatEmpfängerR ‹ ‡ Axiom 33: Komplementarität der Rollen "hatSender" und "hatEmpfänger"

4.4.2.3 Sendevorgänge

Sendevorgänge sollen Pragmatik- und Interaktionseigenschaften von Geschäftsnachrichten beschreiben. Sie beinhalten aus der Perspektive einzelner IDI-Agenten zwei Arten von Nachrichten: Eingangs- und Ausgangsnachrichten. Eingangsnachrichten sollen IDI-Agenten empfangen, Ausgangsnachrichten senden können. Da jeder Sendevorgang über einen Sender und (mindestens) einen Empfänger verfügt, wird dieselbe Nachricht in der einen Ontologie als Ausgangs-, in der anderen als Eingangsnachricht repräsentiert. Zunächst sei die Rolle hatSVR vorgestellt. Mit ihr können Sendevorgänge einem Protokoll zugeordnet werden. Entsprechend besteht der Bildbereich aus Sendevorgängen, der Domänenbereich umfasst alle Individuen, die Protokolle darstellen Alle

Protokolle SequenzIDI .

sind

Spezialisierungen

der

GBox-Konzeptklasse

136

4 Ontologieinhalte und -vokabular F‹ hatSVR .Sendung IDI F‹ hatSVR .SequenzIDI

Axiom 34: Domänen- und Bildbereich der Rolle "hatSV"

Die Zuordnung von Nachrichten zu Sendevorgängen erfolgt durch die Rolle hatNachR . Allerdings ist nicht jedem Sendevorgang eine Nachricht zugeordnet. Manche Sendevorgänge kommen ohne Nachricht aus, weil sie sich auf eine bereits in einem anderen Sendevorgang gesendete Nachricht beziehen. Jeder Sendevorgang kann höchstens über eine Nachricht verfügen. Allerdings können Nachrichten mehreren Sendevorgängen zugeordnet sein. F‹ d 1 hatNachR .Nachricht IDI F‹ hatNachR .Sendung IDI Axiom 35: Domänen- und Bildbereich der Rolle "hatNach"

Die Rolle hatIlloR dient der Zuweisung von Illokutionen zu Sendevorgängen. Jeder Sendevorgang muss über genau eine Illokution verfügen. Allerdings kann eine Illokution beliebig vielen Sendevorgängen zugeordnet sein. F‹

1 hatIlloR .IllokutionIDI

F‹ hatIlloR .Sendung IDI Axiom 36: Domänen- und Bildbereich der Rolle "hatIllo"

Die Konzeptklasse IllokutionIDI lässt sich als abgeschlossene Klasse definieren. Die benötigten Individuen werden im unten stehenden Axiom aufgezählt.

IllokutionIDI

­ Assertive,Offer,Acceptance,Authorization Request,½ °Permissive,Requirement,Confirmative,Requestive, ° °° °°  ®Rejective,Feedback,Informative,Predictive, ¾ °Retrodictive,Verdictive,Declarative,Service, ° ° ° ¯°ProtOffer,ProtAccept,ProtReject ¿°

Axiom 37: Konzeptklasse "Illokution"

4.4 Geschäftsdatenpragmatik und Interaktionsprotokolle

137

In Abschnitt 4.2.5 wurde bereits die Boole'sche Rolle optionalR eingeführt, um anzuzeigen, welche Strukturelemente Geschäftsdaten enthalten müssen und welche nicht. Der Domänenbereich dieser Rolle soll nun auf Sendevorgänge ausgeweitet werden. Alle Sendevorgänge, die als obligatorisch gekennzeichnet sind, müssen gesendet werden. F‹

1 optionalR .^wahr ,falsch`

F‹ optionalR .Sendung IDI Axiom 38: Ausweitung des Domänenbereichs der Rolle "optional" auf Sendevorgänge

Fraglich ist, wie die Optionalität von Sendevorgängen zu interpretieren ist. Ob Sendevorgänge optional zu senden sind oder nicht, legt der protokollvorschlagende Agent (im Folgenden "VER-Agent" genannt) fest. Bezüge ermöglichen es, inhaltliche Referenzen zwischen Sendevorgängen abzubilden. Bspw. muss die Annahme eines Angebots immer einen Bezug zum Angebot herstellen. Diese Bezüge sollen in IDI-Ontologien durch die Rolle bezugZuR hergestellt werden. Sowohl der Bild- wie auch der Domänenbereich der Rolle bezugZuR bestehen aus Sendevorgängen. Es sei festgelegt, dass die Menge der Rollenersten von bezugZuR die Menge der referenzierenden, die Menge der Rollenzweiten die Menge der referenzierten Sendevorgänge darstellt. Dabei ist zu berücksichtigen, dass ein Sendevorgang genau einen Sendevorgang referenzieren, aber von beliebig vielen anderen Sendevorgängen referenziert werden kann. F‹

1 bezugZuR .Sendung IDI

F‹ bezugZuR .Sendung IDI Axiom 39: Domänen- und Bildbereich der Rolle "bezugZu"

Zwar besteht sowohl der Domänen- wie auch der Bildbereich von bezugZuR aus Sendevorgängen. Jedoch handelt es sich bei bezugZuR um eine asymmetrische Rolle. bezugZuR Š bezugZuR Bedingung 5: Asymmetrie der Rolle "bezugZu"

‡

138

4 Ontologieinhalte und -vokabular

4.4.2.4 Zeitliche und logische Abhängigkeiten

Die Repräsentation von zeitlichen Abhängigkeiten zwischen Sendevorgängen lässt sich durch Datentypengruppen repräsentieren. Es sei = als Konkrete Domäne zur Spezifikation von Zeitangaben definiert. Diese Konkrete Domäne bestehe aus ƒ der Konzeptklasse Zeitpunkt IDI , welche die Wertemenge der Konkreten Domäne repräsentiert; es repräsentiere ^z` ein Individuum der

Konzeptklasse Zeitpunkt IDI ; ƒ der Konkreten Rolle hatSendezeitT , die einzelnen Sendevorgängen einen Sendezeitpunkt ^z` zuordnet; ƒ den unären Prädikaten d^z` , t^z` , ^z` , !^z` , ^z` ; ƒ den binären Prädikaten d, t, !, , .

In einem ersten Schritt seien sog. absolute Zeitbezüge betrachtet. Absolute zeitliche Bezüge repräsentieren Restriktionen hinsichtlich des Sendezeitpunkts eines Sendevorgangs. Sie sind unabhängig von den gewollten oder tatsächlichen Sendezeitpunkten anderer Sendevorgänge. Durch einen absoluten zeitlichen Bezug lässt sich festlegen, zu welchem Zeitpunkt ein Sendevorgang frühestens gesendet werden darf bzw. genau oder spätestens gesendet werden muss. Diese absoluten zeitlichen Bezüge sollen durch die Rollen frühestT , spätestT sowie genauT repräsentiert werden. Bei allen drei genannten Rollen handelt es sich jeweils um eine Spezialisierung der Rolle hatSendezeitT . Es seien nun der Bild- und Domänenbereich der Rolle frühestT formal definiert. Die Bild- und Domänenbereiche der Rollen spätestT und genauT sind hierzu identisch; auf eine separate Darstellung wird daher verzichtet. F‹

1 frühestT .Zeitpunkt IDI

F‹ frühestT .Sendung IDI Axiom 40: Domänen- und Bildbereich der Rolle "frühest"

Relative Zeitbezüge knüpfen den Sendezeitpunkt des einen Sendevorgangs an den Sendezeitpunkt eines anderen. Somit lässt sich eine ge-

4.4 Geschäftsdatenpragmatik und Interaktionsprotokolle

139

wünschte Reihenfolge der Sendevorgänge innerhalb eines Protokolls generieren. Zu diesem Zweck sei die Rolle vorherR definiert. Werden zwei Sendevorgänge durch diese Rolle verbunden, so darf der Rollenzweite erst nach dem Rollenersten gesendet werden. F‹ vorherR .Sendung IDI F‹ vorherR .Sendung IDI Axiom 41: Domänen- und Bildbereich der Rolle "vorher"

Analog zur Rolle bezugZuR muss auch die Rolle vorherR asymmetrisch sein. vorherR Š vorherR

‡

Axiom 42: Asymmetrie der Rolle "vorher"

Verfügen beide Sendevorgänge sowohl über feste wie auch relative Zeitbezüge, so sind diese Zeitbezüge nur unter Einhaltung der unten definierten Randbedingungen zulässig. Es seien SV1 und SV2 Sendevorgänge. SV1 , SV2 : ª ª SV1 ‹ vorherT .SV2 š º º «« » » « « SV1 ‹ 1  frühestT ‰ genauT ‰ spätT .^Z1` š » Ÿ ^Z1`  ^Z2 ` » «« » » «¬ ¬« SV2 ‹ 1  frühestT ‰ genauT ‰ spätT .^Z 2 ` ¼» »¼ Bedingung 6: Zulässige Kombinationen relativer und absoluter Zeitbezüge

Wird durch die Rolle vorherT festgelegt, dass ein beliebiger Sendevorgang SV1 vor einem anderen Sendevorgang SV2 gesendet werden muss, dann sind feste Zeitbezüge nur zulässig, wenn der früheste, genaue oder späteste Sendezeitpunkt von SV1 vor dem frühesten, genauen oder spätesten Sendezeitpunkt von SV2 liegt. Schließlich wird vorgeschlagen, Rollen zur Repräsentation logischer Beziehungen zwischen Sendevorgängen vorzusehen. Die Aufgabe dieser Rollen besteht darin, logische Abhängigkeiten zwischen dem Versand einzelner Sendevorgänge festlegen zu können.

140

4 Ontologieinhalte und -vokabular

Es werden die folgenden Rollen zur Repräsentation logischer Beziehungen zwischen Sendevorgängen vorgeschlagen: ƒ Die Rolle oderR verbindet zwei Sendevorgänge, sodass entweder der eine oder der andere Sendevorgang oder beide gesendet werden können. Es muss aber mindestens ein Sendevorgang gesendet werden. ƒ Die Rolle noderR bewirkt, dass von den verbundenen Sendevorgängen keiner gesendet werden darf. Diese Rolle ist bei der Spezifikation von Interaktionsprotokollen nicht sinnvoll einsetzbar. Allerdings wird diese Rolle mit ihrer spezifischen Kombination von Wahrheitswerten bei der Spezifikation der Eigenschaften gemeinsamer Sendevorgänge benötigt.231 ƒ Die Rolle xoderR wirkt als ausschließliches Oder, d.h. es muss entweder der eine oder der andere Sendevorgang gesendet werden, es dürfen jedoch nicht beide gesendet werden. ƒ Die Rolle nxoderR wirkt als Bikonditional, d.h. es können entweder nur beide Sendevorgänge gesendet werden oder es wird keiner der Sendevorgänge gesendet. ƒ Die Rolle undR verbindet zwei Sendevorgänge, sodass der gemeinsame Versand beider Sendevorgänge verpflichtend ist. ƒ Die Rolle nundR bewirkt, dass jede Konstellation gestattet ist, außer dem gemeinsamen Versand beider Sendevorgänge.

Sämtliche der oben aufgezählten logischen Rollen sind symmetrisch. 4.4.2.5 Grafische Darstellung von IDI-Protokollen

Die in dieser Arbeit verwendete Notation zur grafischen Darstellung von Agentenprotokollen beruht auf Agent-UML (AUML), einer Erweiterung von UML zur Darstellung von Interaktionssequenzen zwischen Agenten.232 Dabei wird eine vereinfachte Form der AUML-Protokolldiagramme verwendet. So sind bspw. nur asynchrone Nachrichten vorgese-

231 232

Vgl. hierzu Abschnitt 4.4.3.4. Vgl. Odell et al. 2001.

4.4 Geschäftsdatenpragmatik und Interaktionsprotokolle

141

hen. Auch auf die Verwendung eingebetteter Protokolle wurde verzichtet. Dafür wurde AUML um Symbole zur Darstellung der oben beschriebenen Merkmale von Sendevorgängen erweitert. Es seien nun die grafischen Darstellungsmittel definiert. Lebenslinien repräsentieren die Zeitspanne, in der ein IDI-Agent existiert. Sie werden als gestrichelte, vertikale Linien dargestellt. In einem Rechteck am Kopf jeder Lebenslinie ist die Agentenklasse angegeben. Die Bezeichnung der Agentenklasse kennzeichnet die Funktion, die ein Agent mit einer bestimmten Lebenslinie wahrnimmt. Lebenslinien repräsentieren also – wie auch in AUML – keine individuellen Agenten, sondern alle Agenten, die Individuen der jeweiligen Agentenklasse sind. Aus Vereinfachungsgründen sei vereinbart, dass IDI-Agenten innerhalb eines Protokolls nur eine Rolle einnehmen können. Aktivitäten von Agenten werden durch Aktivitätsbalken dargestellt. Aktivitäten sind Handlungen, die ein Agent nach dem Empfang einer Nachricht oder zur Vorbereitung des Nachrichtenversands ausführt. Der Aktivitätsbalken repräsentiert eine Phase, in der der Agent bestimmte Aufgaben wahrnimmt, also "aktiv" ist. Der Aktivitätsbalken wird als längliches Rechteck auf der Lebenslinie abgebildet. Sendevorgänge stellen die zentralen Protokollbestandteile dar. Sie werden durch Rechtecke zwischen den Lebenslinien dargestellt. Im linken Teil des Rechtecks ist der Name der Nachricht abgebildet, die der Sendevorgang beinhaltet. Immer dann, wenn der Sendevorgang keine Nachricht enthält, bleibt dieser Teil leer. Der rechte Bereich des Sendevorgangs-Kästchens enthält die Illokution, über die jeder Sendevorgang verfügen muss. Die Senderichtung ergibt sich aus den horizontalen Pfeilen, die an die einzelnen Sendevorgänge gezeichnet sind.

Auch die zwischen einzelnen Sendevorgängen definierbaren logischen Beziehungen sollen dargestellt werden. Die sich aus einer logischen Beziehung ergebende Aufteilung der Lebenslinie wird durch einen Kreis angezeigt. Dieser Kreis enthält die ersten beiden Buchstaben der am Ende des letzten Abschnitts formulierten Logikrollen. Inhaltliche Bezüge zwischen Sendevorgängen sollen durch vertikale Pfeile dargestellt werden. Die Pfeilspitze zeigt auf den Sendevorgang, auf den Bezug genommen wird. Der Punkt hängt an dem bezugneh-

142

4 Ontologieinhalte und -vokabular

menden Sendevorgang. Zeitliche Bezüge hingegen werden durch geschwungene Linien repräsentiert. Die Pfeilrichtung repräsentiert die einzuhaltende Sendereihenfolge. Absolute Zeitvorgaben werden durch einen Beschriftungskasten dargestellt. Abschließend seien die wichtigsten Elemente zur grafischen Darstellung der IDI-Protokolle an einem Beispiel demonstriert.

SV01:



SV02:



SV03:



xo

Abbildung 13: Beispiel eines IDI-Interaktionsprotokolls

4.4.3 Metaprotokolle 4.4.3.1 Aufgaben von Metaprotokollen

Unter einem Metaprotokoll wird in dieser Arbeit ein Verfahren zur automatisierten Vereinbarung von Interaktionsprotokollen verstanden. Interaktionsprotokolle beschreiben die Eigenschaften von Sequenzen inhaltlich aufeinander Bezug nehmender Sendevorgänge. Technische Fragestellungen wie z.B. Nachrichtenadressierung, Routing, Fehlerbehandlung, Verschlüsselung etc. bleiben ausgeklammert.233 Da eine der zentralen IDI-Anforderungen die Fähigkeit zur Kommunikation mit unbekannten Partnern verlangt, können Protokolle zur Steuerung von Nachrichtensequenzen nicht vorab vereinbart werden. Es muss also ein Metaprotokoll entwickelt werden, das den IDI-Agenten das Aushandeln oder Vereinbaren von Protokollen zur Laufzeit erlaubt. 233

Vgl. Chaib-Draa, Dignum 2002, S. 90.

4.4 Geschäftsdatenpragmatik und Interaktionsprotokolle

143

Eine zentrale Standardisierung und Vorgabe von Agentenprotokollen erscheint aus verschiedenen Gründen nicht sinnvoll. Da eine zentrale Standardisierungsinstanz nicht alle Geschäftsanforderungen abdecken kann, ist die Nutzung eines solchen Standards mit der entsprechenden Inflexibilität verbunden. Zwar gleichen sich viele Geschäftsprozesse auf einer hohen Abstraktionsebene. Im Detail allerdings können zahlreiche Unterschiede vorhanden sein. Die zentralisierte Perspektive zwingt Anwender, sich einem Standard anzupassen, statt Systeme zu nutzen, welche die eigenen Anforderungen abbilden können. Zudem ergibt sich aus der Anforderung der Offenheit bzw. der Fähigkeit zur Ad-hoc-Kommunikation, dass jederzeit neue IDI-Agenten sowie neue Geschäftsprozesse hinzutreten können. Zumindest letzteres ist mit einem Agentenstandard, der auf zentral vorgegebenen Protokollen basiert, nur schwer möglich.234 Es seien nun zunächst bestehende Forschungsansätze zur laufzeitgebundenen Protokollvereinbarung betrachtet. Walton und Robertson schlagen vor, Agentenprotokolle dynamisch während der Laufzeit zu bilden.235 Das von den Autoren so genannte „flexible protocol“ beruht auf einer Explikation der perlokutionären Handlung, also der Handlung, deren Durchführung von einem Gesprächspartner als Reaktion auf einen erfolgreichen Sprechakt erwartet wird. Beispielsweise wird nach dem Satz „Wie spät ist es?“ vom Gesprächspartner implizit die Nennung der Uhrzeit erwartet. Das übergeordnete "flexible protocol" entsteht aus einer Aneinanderreihung atomarer Agentenprotokolle, die jeweils aus einem Sprechakt mit den zugehörigen Inhalten sowie einer Spezifikation der vom Partner erwarteten Antwort bestehen. Zu Beginn einer Interaktionssequenz steht somit noch nicht fest, welchen Verlauf die Kommunikation nehmen wird. Hierin ist allerdings auch die entscheidende Schwäche des Ansatzes zu sehen: es ist nicht möglich, einen Agenten zu Beginn einer Kommunikation auf eine feste Abfolge von Nachrichten und Nachrichteninhalten zu verpflichten. Der Sender hat keine Möglichkeit, seine vorhandenen An-

234 235

Vgl. Tamma et al. 2002, S. 62. Vgl. Walton, Robertson 2002.

144

4 Ontologieinhalte und -vokabular

forderungen an eine Interaktionssequenz mitzuteilen. Der Empfänger kann nicht beurteilen, ob er alle Anforderungen des Senders erfüllen kann oder will. Ahn et al. schlagen einen Mechanismus vor, der es Agenten ermöglicht, zur Laufzeit neue Protokolle auszutauschen und zu vereinbaren.236 Basis ist ein Metaprotokoll, das vor der Aufnahme von Kommunikationsbeziehungen als Standard für eine Agentengesellschaft vereinbart wird. Das Metaprotokoll sieht vor, dass ein Agent A, der mit einem Agenten B in einem bestimmten Kontext kommunizieren möchte, von Agent B das entsprechende Protokoll anfordert. Nach erfolgreicher Interpretation des Protokolls kann A mit der eigentlichen Konversation beginnen. Agent A überprüft nach Empfang des Protokollvorschlags von Agent B, ob die hierin festgelegten Vorbedingungen mit seinem eigenen mentalen Zustand (Ziele, Überzeugungen, Absichten etc.) vereinbar sind. Falls dies zutrifft, tritt A in die Konversation mit B ein. Der Nachteil dieses Ansatzes ist in der erforderlichen umfangreichen semantischen Spezifikation der mentalen Zustände sowie des zugehörigen Schlussfolgerungsapparats zu sehen. Reed et al. präferieren einen hybriden Ansatz, der als eine Mischung aus Agentenstandard und dynamischer Protokollgenerierung zu betrachten ist.237 Dabei greifen Agenten auf einen vordefinierten, multidimensionalen Rahmen („semantic space“) zurück, der eine semantische Spezifikation der verwendbaren Kommunikationsprimitiva enthält. Auf Basis dieses Rahmens können die Agenten zur Laufzeit die exakte Semantik der von Ihnen benötigten Kommunikationsprimitiva aushandeln („semantic fixing“). Hintergrund des Ansatzes ist die Überlegung, dass Kommunikationsprimitiva nie absolut definiert werden können, sondern immer nur relativ zu einem bestimmten Kontext.238 Die vorgestellte Arbeit basiert, ebenso wie die von Ahn et al., auf dem mentalistischen Ansatz, der eine Repräsentation innerer, kognitiver Zustände vorsieht.

236 237 238

Vgl. Ahn et al. 2002. Vgl. Reed et al. 2002. Vgl. Reed et al. 2002, S. 229-230.

4.4 Geschäftsdatenpragmatik und Interaktionsprotokolle

145

4.4.3.2 IDI-Ansatz

Es erscheint nicht notwendig zu sein, IDI-Agenten mit einer Repräsentation mentaler Zustände auszustatten. Die Verwendung des sog. mentalistischen Ansatzes ist vor allem dann gerechtfertigt, wenn komplexe Interaktionsstrukturen repräsentiert werden müssen. Als Beispiele für eine komplexe Interaktionsstruktur seien die autarke Koordination von Aufgaben sowie Verhandlungen zwischen Agenten genannt. Derartige Interaktionsstrukturen treten in der IDI-Architektur jedoch nicht auf. Das IDI-Metaprotokoll sieht vor, dass der kommunikationsinitiierende IDI-Agent einen Protokollvorschlag an den oder die potenziellen Empfänger sendet. Kommunikation findet nur statt, wenn der Empfänger über ein kompatibles Protokoll in seiner LBox verfügt. Besitzt der Empfänger ein kompatibles Protokoll, so werden die kompatiblen Protokolle zu einem gemeinsamen Protokoll verschmolzen, das dann den folgenden Nachrichtenaustausch steuert. Das so entstandene neue Protokoll repräsentiert das gemeinsame Verständnis der beteiligten IDI-Agenten über die fachlichen Rahmenbedingungen einer definierten Nachrichtensequenz. Ohne dieses gemeinsame Protokoll, das als Schnittmenge aus den Elementen zweier Protokollspezifikationen entsteht, kann keine Kommunikation zwischen IDI-Agenten stattfinden. Wesentliche Aufgabe des Metaprotokolls ist es, unter Berücksichtigung der in den einzelnen Protokollen spezifizierten Eigenschaften Randbedingungen für die Verschmelzung der Protokolle und ihrer Sendevorgänge zu definieren sowie die Eigenschaften und Randbedingungen des neuen Protokolls und seiner Sendevorgänge festzulegen. Eine Interpretation von Protokollen im semantischen Sinn ist nicht erforderlich, da alle Protokolle mithilfe des global gültigen Vokabulars formuliert werden müssen. Die Bedeutung dieses in der GBox repräsentierten Vokabulars ist somit festgelegt. Das IDI-Metaprotokoll sieht vor, dass der Initiator einer Nachrichtensequenz einen Protokollvorschlag an den oder die potenziellen Empfänger sendet. Der empfangende Agent stellt dann fest, ob er alle Anforderungen des Initiators und ob der Initiator alle Anforderungen des Empfängers erfüllen kann. Ist dies der Fall, teilt er dem Sender sein Einverständ-

146

4 Ontologieinhalte und -vokabular

nis mit. Das Protokoll ist damit vereinbart. Kann der empfangende Agent nicht alle Anforderungen des Senders bzw. der Sender nicht alle Anforderungen des Empfängers erfüllen, wird die Protokollzustimmung verweigert. Die Idee des IDI-Metaprotokolls beruht darauf, dass alle beteiligten IDIAgenten in ihren jeweiligen Ontologien über Protokolle verfügen, die sämtliche Interaktionsszenarien spezifizieren, an denen der betreffende IDI-Agent teilnehmen können soll. Möchte der Empfänger eines Protokollvorschlags mit dessen Sender Geschäftsdaten austauschen, so muss in der Ontologie des Empfängers ein zum Vorschlag des Senders kompatibles Protokoll vorhanden sein. Die Protokollkompatibilität ist an eine Reihe von Kompatibilitätsbedingungen geknüpft. Mit der detaillierten Darstellung und formalen Definition dieser Kompatibilitätsbedingungen befasst sich Abschnitt 4.4.3.3. Eine wichtige Rolle bei der Protokollvereinbarung spielt die Kennzeichnung von fakultativen und obligatorischen Sendevorgängen. ƒ Ist ein Sendevorgang des Initiator-Protokolls als obligatorisch gekennzeichnet, so kann das Protokoll nur vereinbart werden, wenn der Empfänger die zugeordnete Nachricht verarbeiten kann. Kann der Empfänger eine obligatorische Nachricht nicht verarbeiten, so kann das Protokoll nicht vereinbart werden. ƒ Ist ein Sendevorgang des Initiator-Protokolls als fakultativ gekennzeichnet, so kann das Protokoll auch dann vereinbart werden, wenn der Empfänger die zugeordnete Nachricht nicht verarbeiten kann. ƒ Ist ein Sendevorgang des Empfänger-Protokolls als obligatorisch gekennzeichnet, so kann das Protokoll nur vereinbart werden, wenn der Sender die zugehörige Nachricht senden kann. ƒ Ist ein Sendevorgang des Empfänger-Protokolls als fakultativ gekennzeichnet, so kann das Protokoll auch dann vereinbart werden, wenn der Sender die zugehörige Nachricht nicht senden kann.

Die soeben beschriebene Art der Protokollvereinbarung impliziert die Verfügbarkeit einer Minimal- und einer Maximalversion für jedes Interaktionsprotokoll der Kommunikationspartner. Die Minimalversion enthält die Prozessbestandteile, die aus der jeweiligen Perspektive min-

4.4 Geschäftsdatenpragmatik und Interaktionsprotokolle

147

destens vorhanden sind oder sein müssen. Die Maximalversion spezifiziert zusätzliche Bestandteile, die die Partner liefern oder verarbeiten können. Nur wenn die jeweiligen obligatorischen Bestandteile bei der Gegenpartei wenigstens als fakultative Elemente vorgesehen sind, kann das Protokoll vereinbart werden. Es wird vorgeschlagen, bei der Spezifikation von Protokollen das Prinzip der minimalen Granularität zu verfolgen. Dabei dürfen nur diejenigen Nachrichten bzw. Sendevorgänge in einem Protokoll enthalten sein, die sich unmittelbar gegenseitig bedingen. Nachrichten bedingen sich gegenseitig, wenn Nachricht A nicht ohne eine andere Nachricht B gesendet wird oder gesendet worden wäre. Andernfalls bestünde die Gefahr, dass kein Protokoll vereinbart würde, obwohl beide Partner auch mit dem Versand einzelner Sequenzteile einverstanden gewesen wären. Als ein weiteres Prinzip bei der Protokollvereinbarung soll das Prinzip des maximalen Kommunikationsumfangs verfolgt werden. Zielsetzung dabei ist es, alle übereinstimmenden Protokollbestandteile auch dann im Protokoll zu vereinbaren, wenn diese bei mindestens einer Partei als fakultativ deklariert wurden. 4.4.3.3 Notwendige und hinreichende Bedingungen für Protokollkompatibilität

Übermittelt Agent A einem anderen Agenten B einen Protokollvorschlag und stimmt B diesem Protokollvorschlag zu, so wird aus beiden Protokollen ein gemeinsames Protokoll gebildet. Bedingung für die Bildung gemeinsamer Protokolle ist die Erfüllung der notwendigen Bedingungen für die Protokollkompatibilität. Das nun folgende Unterkapitel widmet sich der formalen Explikation dieser Bedingungen. Es seien nun zunächst einige benötigte Rollen, Konzepte und Individuen definiert. ƒ Es seien A und B zwei Ontologien. ƒ Es seien SequenzA und SequenzB Protokolle der Ontologien A und B. ƒ Es seien SVA1 und SVA2 Sendevorgänge des Protokolls SequenzA .

148

4 Ontologieinhalte und -vokabular

ƒ Es seien SVB1 und SVB 2 Sendevorgänge des Protokolls SequenzB . ƒ Die Rolle kompSVR zeigt die Kompatibilität zwischen zwei Sendevorgängen an. Bild- und Domänenbereich bestehen also aus Sendevorgängen. Die Rolle ist außerdem symmetrisch. ƒ Die Rolle kompPRR zeigt die Kompatibilität zwischen zwei Protokollen an. Bild- und Domänenbereich bestehen also aus Protokollen. Auch diese Rolle ist symmetrisch. ƒ Die beiden Individuen ^Illokution1` und ^Illokution2 ` sind Instanzen der

Konzeptklasse Illokution IDI . Die notwendige Kompatibilitätsbedingung für zwei Protokolle lautet, dass alle obligatorischen Sendevorgänge beider Protokolle über genau einen kompatiblen Sendevorgang im Partnerprotokoll verfügen müssen.

SequenzA ‹ kompPRR .SequenzB Ÿ ª§ SVA1 , SVB1 : «¨ «¨© SVA1 ‹ 1 optionalR .^falsch` Ÿ  SVA1 ‹ « «§ SVB1 , SVA1 : «¨¨ ¬© SVB1 ‹ 1 optionalR .^falsch` Ÿ  SVB1 ‹

· º ¸¸ š » 1 kompSVR .SVB1 ¹ » » · » ¸ 1 kompSVR .SVA1 ¹¸ ¼»

Bedingung 7: Protokollkompatibilität

Im verbleibenden Teil des Unterkapitels werden nun die Kompatibilitätsbedingungen für Sendevorgänge definiert. Gemäß der ersten Kompatibilitätsbedingung müssen kompatible Sendevorgänge die gleichen Illokutionen besitzen. Andernfalls wären diese Sendevorgänge mit unterschiedlichen Handlungsabsichten verknüpft. Sendevorgänge mit unterschiedlichen Handlungsabsichten können allerdings nicht kompatibel sein. SVA1 , SVB1 : ª SVA1 ‹ kompSVR .SVB1 Ÿ º « » ¬« hatIlloR a SVA1 b hatIlloR a SVB1 b ¼» Bedingung 8: Gleiche Illokutionen bei Sendevorgangs-Kompatibilität

4.4 Geschäftsdatenpragmatik und Interaktionsprotokolle

149

In einer zweiten Kompatibilitätsbedingung ist zu fordern, dass die Nachrichten, die zwei kompatiblen Sendevorgängen zugeordnet sind, semantisch äquivalent sein müssen. SVA1 , SVB1 : ª SVA1 ‹ kompSVR .SVB1 Ÿ « « 1 hatNachR .SVA1 { 1 hatNachR .SVB1 ¬





º » » ¼

Bedingung 9: Äquivalente Nachrichten bei Sendevorgangs-Kompatibilität

Auch absolute Zeitbezüge spielen zur Feststellung der Kompatibilität von Sendevorgängen eine Rolle. Besitzen zwei Sendevorgänge einen durch die Rolle genauT festgelegten Sendezeitpunkt, dann setzt ihre Kompatibilität die Gleichheit der jeweiligen Sendezeitpunkte voraus. SVA1 , SVB 1 : ª ª SVA1 ‹ kompSVR .SVB1 š º «« » « « SVA1 ‹ 1 genauT .^Z A1` š » Ÿ ^Z A1` «« » «¬ «¬ SVB 1 ‹ 1 genauT .^ZB1` »¼

º » ^ZB1` » » »¼

Bedingung 10: Konsistente Verwendung zweier "genau"-Rollen bei SendevorgangsKompatibilität

Verfügen beide Sendevorgänge über die Rollen frühestT und spätestT , so darf der durch spätestT definierte Zeitpunkt nicht vor dem durch frühestT definierten Zeitpunkt liegen. SVA1 , SVB1 : ª ª SVA1 ‹ kompSVR .SVB1 š º º «« » » « « SVA1 ‹ 1 frühestT .^Z A1` š » Ÿ ^Z A1` d ^ZB1` » «« » » «¬ ¬« SVB1 ‹ 1 spätestT .^ZB1` ¼» »¼ Bedingung 11: Konsistente Kombination einer "spätest"- und einer "frühest"-Rolle bei Sendevorgangs-Kompatibilität

Bei einer Kombination der Rollen frühestT und genauT sowie spätestT und genauT ist Sendevorgangskompatibilität nur dann gegeben, wenn der durch genauT angegebene Zeitpunkt innerhalb der durch spätestT und frühestT festgelegten Intervalle liegt.

150

4 Ontologieinhalte und -vokabular SVA1 , SVB1 :

SVA1 ‹ kompSVR .SVB1 š ª ª ª SVA1 ‹ ««« « « « SVB1 ‹ «¬¬ « ª ª SV ‹ A1 ««« « « « SV ‹ B1 ¬¬¬

º º 1 genauT .^Z A1` š º » Ÿ ^Z A1` d ^ZB1` » š » » » 1 spätestT .^ZB1` »¼ ¼ » º » º 1 genauT .^Z A1` š » Ÿ ^Z A1` t ^ZB1` » » » » 1 frühestT .^ZB1` »¼ ¼ ¼

Bedingung 12: Konsistente Kombination einer "frühest"- und "genau"- sowie einer "spätest"- und "genau"- Rolle bei Sendevorgangs-Kompatibilität

Wird ein Sendevorgang in seiner Ontologie durch die Rolle vorherR mit einem anderen Sendevorgang verbunden, so dürfen die Verschmelzungskandidaten einer anderen Ontologie nicht durch die inverse Rolle vorherR verbunden sein. Wenn relative Zeitbezüge in beiden Ontologien vorhanden sind, dann müssen diese gleichgerichtet sein. SVA1 , SVA2 , SVB1 , SVB 2 : ª ª SVA1 ‹ kompSVR .SVB1 š º º «« » » « « SVA 2 ‹ kompSVR .SVB 2 š » Ÿ  SVB 2 ‹ vorherR .SVB1 » «« » » ¼ ¬ ¬ SVA1 ‹ vorherR .SVA 2 ¼ Bedingung 13: Gleiche Ausrichtung relativer Zeitbezüge bei SendevorgangsKompatibilität

Schließlich ist noch der Fall zu betrachten, dass absolute und relative Zeitbezüge gemischt werden. Dabei sind zwei Sendevorgänge der einen Ontologie durch die Rolle vorherR verbunden, die Verschmelzungskandidaten der anderen Ontologie verfügen beide über eine feste Zeitvorgabe.

4.4 Geschäftsdatenpragmatik und Interaktionsprotokolle

151

SVA1 , SVA 2 , SVB1 , SVB 2 : ª ª SV ‹ kompSV .SV š º º A1 R B1 «« » » « « SVA 2 ‹ kompSVR .SVB 2 š » » «« » » « « SVA1 ‹ vorherR .SVA 2 š » Ÿ ^ZB 1`  ^ZB 2 ` » «« » » « « SVB 1 ‹ 1 hatSendezeitT .^ZB 1` š » » «« » » ¬« ¬ SVB 2 ‹ 1 hatSendezeitT .^ZB 2 ` ¼ ¼» Bedingung 14: Mischung relativer und absoluter Zeitbezüge bei SendevorgangsKompatibilität

Die Kompatibilität der beiden Sendevorgangspaare ist nur dann sichergestellt, wenn die Sendezeiten der beiden Sendevorgänge aus OntologieB den relativen Zeitbezug aus OntologieA nachvollziehen, d.h. der Sendezeitpunkt von Sendevorgang SVB1 muss vor dem Sendezeitpunkt von Sendevorgang SVB 2 liegen. Des besseren Verständnisses wegen sei diese Kompatibilitätsbedingung anhand des folgenden Schaubilds illustriert. Ontologie A

SVA1

Ontologie B kompSVR

SVB1

hatSendezeitT

^ZB1`

Ÿ ^ZB1 `  ^ZB 2 `

vorherR

^ZB 2 ` SVA 2

kompSVR

SVB 2

Prämisse

hatSendezeitT

Folgerung (notwendige Komp.-Bedingung)

Abbildung 14: Kompatibilitätsbedingungen bei Mischung absoluter und relativer Zeitbezüge

In Abschnitt 4.4.2.4 wurden sechs Rollen zur logikbasierten Verknüpfung von Sendevorgängen vorgestellt. Zu klären verbleibt, welche Kombinationen logikbasierter Verknüpfungen zur Inkompatibilität der betrachte-

152

4 Ontologieinhalte und -vokabular

ten Sendevorgänge und damit auch zur Protokollinkompatibilität führen. Angenommen, zwei fakultative Sendevorgänge eines Protokolls ( SVA1 und SVA2 ) sind durch eine logische Verknüpfung miteinander verbunden, ebenso wie zwei fakultative Sendevorgänge eines anderen Protokolls ( SVB1 und SVB 2 ). Es ist zu klären, durch welche logischen Verknüpfungen SVA1 und SVA2 sowie SVB1 und SVB 2 verbunden sein dürfen, ohne die Kompatibilität zwischen SVA1 und SVB1 sowie SVA2 und SVB 2 zu gefährden. Logische Verknüpfungen, die die Sendevorgangskompatibilität nicht stören, sollen als kompatible logische Verknüpfungen bezeichnet werden. Kompatibilität logischer Verknüpfungen ist dann gegeben, wenn beide logischen Rollen über einen gemeinsamen Wahrheitsbereich verfügen. Der Begriff des gemeinsamen Wahrheitsbereichs sei anhand der folgenden Tabelle erläutert.

Tabelle 9:

SV1 gesendet

w

w

f

f

SV2 gesendet

w

f

w

f

oder

w

w

w

f

noder

f

f

f

w

xoder

f

w

w

f

nxoder

w

f

f

w

und

w

f

f

f

nund

f

w

w

w

Konsistente Kombinationsmöglichkeiten logischer Rollen

Die ersten beiden Zeilen zeigen die Kombinationsmöglichkeiten des Sendens (w) und Nichtsendens (f) bei zwei Sendevorgängen SV1 und SV2 . Die folgenden Zeilen geben Auskunft, ob die jeweilige logische Verknüpfung in Abhängigkeit vom Ergebnis der ersten beiden Zeilen zulässig (w) oder unzulässig (f) ist. Wären also bspw. die beiden Sendevorgänge SV1 und SV2 durch die Rolle oderR verknüpft, dann wäre es zulässig, beide Sendevorgänge oder nur einen von beiden zu senden. Un-

4.4 Geschäftsdatenpragmatik und Interaktionsprotokolle

153

zulässig (= "f") hingegen wäre es, wenn keiner der beiden Sendevorgänge gesendet würde. Durch einen Vergleich der jeweiligen Zeilen der einzelnen logischen Rollen lässt sich ermitteln, welche dieser Rollen kompatibel sind. Kompatibilität logischer Rollen ist dann gegeben, wenn es mindestens eine Kombination des Sendens und Nichtsendens der betrachteten Sendevorgangspaare gibt, die für beide Rollen zulässig ist. Bspw. sind die Rollen oderR und xoderR kompatibel, weil es bei beiden Rollen zulässig ist, jeweils nur einen Sendevorgang zu senden. Inkompatibel hingegen sind bspw. die Rollen xoderR und nxoderR . Hier existiert keine Kombinationsmöglichkeit des Sendens oder Nichtsendens, die für beide logischen Rollen gültig wäre. Wie sich aus der oben stehenden Tabelle ergibt, führen die Kombinationen der folgenden Rollen zu Inkompatibilität: ƒ oderR und noderR , ƒ xoderR und nxoderR , ƒ xoderR und undR , ƒ undR und nundR .

Dieser Sachverhalt sei nun auch formal in einer Randbedingung dargelegt. SVA1 , SVA 2 , SVB1 , SVB 2 : ª ª¬ SVA1 ‹ kompSVR .SVB1 š  SVA 2 ‹ kompSVR .SVB 2 º¼ Ÿ º « » º» « ª  SVA1 ‹ oderR .SVA 2 Ÿ  SVB1 ‹ noderR .SVB 2 š »» «« « «§ §  SVB1 ‹ nxoderR .SVB 2 š · · » » « «¨  SVA1 ‹ xoderR .SVA 2 Ÿ ¨ ¸ ¸ š» » ¨  SV ‹ und .SV ¸ ¸ »» « «¨© B1 R B2 © ¹¹ »» «« ‹ ‹ SV und .SV SV nund .SV  Ÿ   B1 «¬ ¬«  A1 B2 R A2 R ¼» »¼ Bedingung 15: Kompatibilität logischer Verknüpfungen

Eine weitere notwendige Bedingung für Protokollkompatibilität fordert die gleiche Ausrichtung inhaltlicher Bezüge. Angenommen, für zwei Sendevorgangspaare ist die Sendevorgangskompatibilität zu prüfen. Besteht zwischen den Sendevorgängen der gleichen Ontologie ein inhaltli-

154

4 Ontologieinhalte und -vokabular

cher Bezug, so müssen die Sendevorgänge der Partnerontologie einen gleichgerichteten inhaltlichen Bezug besitzen. SVA1 , SVA 2 , SVB1 , SVB 2 : ª ª SVA1 ‹ kompSVR .SVB 1 š º «« » « « SVA 2 ‹ kompSVR .SVB 2 š » Ÿ  SVB1 ‹ «« » «¬ ¬« SVA1 ‹ 1 bezugZuR .SVA 2 ¼»

º » 1 bezugZuR .SVB 2 » » »¼

Bedingung 16: Gleiche Ausrichtung inhaltlicher Bezüge bei SendevorgangsKompatibilität

Als letzte notwendige Bedingung für Sendevorgangskompatibilität sei die Übereinstimmung der jeweiligen Sender- und Empfängerrollen betrachtet. Die Rollen hatSenderR und hatEmpfängerR ordnen jedem Sendevorgang eine Konzeptklasse oder ein Individuum als Sender bzw. Empfänger zu. Damit zwei Sendevorgänge kompatibel sein können, müssen ihre Sender- und Empfängerspezifikationen über jeweils mindestens ein gemeinsames Individuum verfügen. Ist also bspw. für den Sendevorgang SVA1 ein Agentenindividuum ^ Agent A ` und für den Sendevorgang SVB1 ein Agentenindividuum ^ AgentB ` als Sender definiert,

dann können SVA1 und SVB1 nur dann kompatibel sein, wenn es sich bei ^Agent A` und ^AgentB ` um das gleiche Agentenindividuum handelt. Dieser Zusammenhang sei nun auch formal als Randbedingung definiert. SVA1 , SVB1 : ª SVA1 ‹ kompSVR .SVB1 Ÿ º « » º» « ª ª hatSenderR .SVA1 ‹ hatSenderR .SVB1 › º »» »š ««« »» » «««   »» « « ¬« hatSenderR .SVB1 ‹ hatSenderR .SVA1 ¼» »» «« « « ª hatEmpfängerR .SVA1 ‹ hatEmpfängerR .SVB1 › º » » »»» ««« »»» « « « hatEmpfänger  .SV ‹ hatEmpfänger  .SV R B1 R A1 ¼» ¼» ¼» ¬« ¬« «¬

   





Bedingung 17: Sich überschneidende Sender- und Empfängerkonzepte bei Sendevorgangs-Kompatibilität

4.4 Geschäftsdatenpragmatik und Interaktionsprotokolle

155

4.4.3.4 Verschmelzungsregeln für gemeinsame Sendevorgänge und Protokolle

Im vorangegangenen Abschnitt wurden die Randbedingungen für die Kompatibilität zwischen Protokollen und den in ihnen enthaltenen Sendevorgängen herausgearbeitet. Die Einigung auf ein gemeinsames Protokoll ist nur möglich, wenn beide Protokolle und somit sämtliche enthaltenen Sendevorgänge kompatibel zueinander sind. Kompatibilität bedeutet allerdings nicht, dass sämtliche Eigenschaften zweier Sendevorgänge völlig übereinstimmen. In einem Folgeschritt sind daher nun Regeln zu erarbeiten, nach denen Sendevorgänge mit unterschiedlichen Eigenschaften zu einem gemeinsamen Sendevorgang verschmolzen werden können. Diese Regeln müssen festlegen, wie sich aus den Merkmalen der ursprünglichen Sendevorgänge die Merkmale der verschmolzenen Sendevorgänge ableiten lassen. Formal werden diese Regeln als Konsistenzbedingungen formuliert, die nur bei einer zulässigen Kombination aus alten und neuen Merkmalen den Wahrheitswert "wahr" zurückgeben. Die Notation von verschmolzenen Sendevorgängen orientiert sich an der Notation der Einzelvorgänge; es wird lediglich die Zeichenkette "GEM" als Hochindex hinzugefügt. Der untere Index besteht aus den laufenden Nummern der beiden ursprünglichen Sendevorgänge, verbunden durch ein kaufmännisches "Und" (&). Der aus den Sendevorgängen SVA1 und SVB1 neu gebildete, gemeinsame Sendevorgang würde dann bspw. als SVAGEM 1&B 1 notiert.

Zur Spezifikation der Randbedingungen in diesem Kapitel wird die Rolle gemSVR benötigt. Diese symmetrische Rolle zeigt an, welche Sendevorgänge aufgrund ihrer Kompatibilität zu einem gemeinsamen Sendevorgang verschmolzen werden sollen. Der Bild- und Domänenbereich dieser Rolle besteht somit aus Sendevorgängen; Rollenerste und Rollenzweite von gemSVR müssen kompatibel zueinander sein. Es sei nun zunächst die Rolle optionalR betrachtet. Ist der Versand einer der beiden zu verschmelzenden Sendevorgänge obligatorisch, so muss auch der Versand des gemeinsamen Sendevorgangs obligatorisch sein.

156

4 Ontologieinhalte und -vokabular SVA1 , SVB 1 : ª ª SVA1 ‹ gemSVR .SVB1 š ºº «« »» « « ªSVA1 ‹ 1 optionalR .^falsch` › º » » »»» ««« « «¬ ¬«SVB 1 ‹ 1 optional R .^falsch` ¼» »¼ » « » «Ÿ SVAGEM ‹ 1 optional R .^falsch` » 1 &B 1 ¬ ¼





Bedingung 18: Optionalität gemeinsamer Sendevorgänge

Besitzen beide Sendevorgänge unterschiedliche absolute Zeitbezüge, so muss der gemeinsame Sendevorgang über den restriktiveren Zeitbezug verfügen. SVA1 , SVB1 : ª ª ª SV ‹ gemSV .SV š º º º A1 R B1 ««« » » » « « « SVA1 ‹ 1 spätestT .^Z A1` š » Ÿ SVAGEM 1 genauT .^ZB1` » š » 1&B1 ‹ ««« » » » « « «¬ SVB1 ‹ 1 genauT .^ZB1` »¼ »¼ » ¬ « » «ª » ª§ SV GEM ‹ ºº · A1&B1 « « ª SV ‹ gemSV .SV š » » º « » R ¨ ¸ A1 R B1 ««« » » «©¨ 1 spätestT .^Z A1` ¹¸ »» « « « SVA1 ‹ 1 spätestT .^Z A1` š » Ÿ « » »» š ««« » · » » «§ SVAGEM » ‹ 1&B 1 « « «¬ SVB1 ‹ 1 frühestT .^ZB1` »¼ » ¸ » «¨¨ » « «¬ » «¬© 1 frühestT .^ZB1` ¸¹ »¼ »¼ « » « ª ª SV ‹ gemSV .SV š » º º A1 R B1 ««« » » » « « « SVA1 ‹ 1 frühestT .^Z A1` š » Ÿ SVAGEM 1 genauT .^ZB1` » » 1&B 1 ‹ ««« » » » « « ¬« SVB1 ‹ 1 genauT .^ZB1` ¼» »¼ » ¬¬ ¼









Bedingung 19: Absolute Zeitbezüge bei gemeinsamen Sendevorgängen

Auch bei Mischungen absoluter und relativer Zeitbezüge ist zu klären, welche Eigenschaft dem verschmolzenen Sendevorgang zugewiesen werden muss.

4.4 Geschäftsdatenpragmatik und Interaktionsprotokolle

157

SVA1 , SVA 2 , SVB1 , SVB 2 : ª ª SVA1 ‹ gemSVR .SVB1 š º º ª§ SV GEM ‹ · º» «« » A1&B1 «¨ ¸ š» » « « SVA 2 ‹ gemSVR .SVB 2 š » «¨© hatSendezeitT .^Z A1` ¸¹ » » «« » »» « « SVA1 ‹ 1 hatSendezeitT .^Z A1` š » Ÿ « · »» «§ SVAGEM «« » 2&B 2 ‹ ¸ «¨¨ « « SVA 2 ‹ 1 hatSendezeitT .^Z A2 ` š » ¸ »» «© hatSendezeitT .^Z A 2 ` ¹ ¼» » «« » ¬ ¼ ¬ ¬ SVB1 ‹ vorherR .SVB 2 ¼ Bedingung 20: Sendezeiten gemeinsamer Sendevorgänge bei Mischungen absoluter und relativer Zeitbezüge

Es sei nun abschließend betrachtet, nach welchen Regeln logische Beziehungen zwischen verschmolzenen Sendevorgängen zu bilden sind. Werden zwei Sendevorgänge des einen Protokolls mit jeweils zwei Sendevorgängen eines anderen Protokolls verschmolzen und sind die Sendevorgänge in einem Protokoll durch eine logische Beziehung miteinander verknüpft, so sind auch die verschmolzenen Sendevorgänge durch diese Beziehung verknüpft. Es seien im Folgenden die Fälle betrachtet, in denen die jeweiligen Sendevorgangspaare über unterschiedliche logische Relationen verfügen. Für die logische Relation zwischen zwei verschmolzenen Sendevorgängen ist der gemeinsame Wahrheitsraum zwischen den logischen Relationen der ursprünglichen Sendevorgänge verantwortlich. Dies sei an einem Beispiel verdeutlicht. Es seien zwei Sendevorgänge SVA1 und SVA2 durch die logische Rolle oderR sowie zwei Sendevorgänge SVB1 und SVB 2 durch die logische Rolle nundR verbunden. Nun sollen SVA1 und SVB1 sowie SVA2 und SVB 2 zu gemeinsamen Sendevorgängen verschmolzen werden. Fraglich ist, welche logische Rolle zwischen den beiden gemeinsamen SendevorgänGEM gen SVAGEM 1&B 1 und SVA 2&B 2 definiert werden muss. Bei der Klärung dieser Frage unterstützt die folgende Tabelle.

158

4 Ontologieinhalte und -vokabular SVA1 SVA2 oder

gemeinsame

nund SVB1 SVB2

Wahrheitswerte w

w

w

f

f

w

w

w

f

w

w

w

w

f

f

w

w

w

w

f

w

f

f

f

f

w

f

f

–

xoder Tabelle 10: Beispiel für die Ableitung logischer Relationen zwischen verschmolzenen Sendevorgängen

Für die Definition logischer Relationen zwischen gemeinsamen Sendevorgängen sind die logischen Relationen zwischen den ursprünglichen Sendevorgängen relevant. In der oben gezeigten Tabelle sind die Wahrheitssignaturen der beiden logischen Rollen oderR und nundR dargestellt. Diese beiden Rollen verfügen an den mittleren Positionen über gemeinsame w-Werte. Somit ergibt sich die mittig in der Tabelle dargestellte Wahrheitssignatur der zwischen den gemeinsamen Sendevorgängen zu definierenden logischen Rolle. Diese Wahrheitssignatur entspricht der Rolle xoderR . Also ist zwischen den Sendevorgängen GEM SVAGEM 1&B 1 und SVA 2&B 2 die logische Rolle xoderR zu definieren.

Die folgende Tabelle gibt einen Überblick über alle gültigen Kombinationen aus zwei Ursprungsrollen und der hieraus abzuleitenden logischen Rolle zwischen zwei gemeinsamen Sendevorgängen.

4.4 Geschäftsdatenpragmatik und Interaktionsprotokolle Ursprungs- Ursprungsrolle 1 rolle 2

159

Rolle des gemeinsamen Sendevorgangs

oderR

xoderR

xoderR

oderR

undR

undR

oderR

nundR

xoderR

oderR

nxoderR

undR

noderR

nxoderR

undR

noderR

nundR

noderR

xoderR

nundR

xoderR

nxoderR

undR

undR

nxoderR

nundR

noderR

Tabelle 11: Ursprungsrollen und abgeleitete Rolle zweier gemeinsamer Sendevorgänge

Der Zusammenhang zwischen den beiden Ursprungsrollen und der Rolle der gemeinsamen Sendevorgänge sei nun auch formal dargestellt. Allerdings bleibt die formale Darstellung auf den ersten Fall, also die erste Zeile der o.a. Tabelle, beschränkt. Alle anderen Fälle können nach dem gleichen Muster definiert werden. SVA1 , SVA 2 , SVB1 , SVB 2 : ª ª SVA1 ‹ gemSVR .SVB 1 š º «« » « « SVA 2 ‹ gemSVR .SVB 2 š » GEM GEM «« » Ÿ SVA1&B1 ‹ xoderR .SVA 2&B 2  š SV oder .SV ‹  A1 R A2 «« » « « SV ‹ xoder .SV » B1 R B2 ¼ ¬¬





º » » » » » ¼

Bedingung 21: Ableitung der logischen Rolle für einen gemeinsamen Sendevorgang (Beispiel)

5 Ontologisches Matching 5.1 Forschungsfragen und Kapitelaufbau Das fünfte Kapitel widmet sich der Forschungsfrage, mithilfe welcher Verfahren semantische Äquivalenzbeziehungen zwischen den Bedeutungseinheiten zweier IDI-Ontologien maschinell identifiziert werden können. Der Input für den ontologischen Matchingprozess besteht in der IDI-Architektur aus zwei Ontologien: einer Empfängerontologie (bezeichnet mit den drei Buchstaben KLO ) und einer Senderontologie (bezeichnet mit KME ). Während in Abschnitt 5.2.1 zunächst die Begriffe "Matching" und "Mapping" allgemein sowie im Kontext der IDI-Architektur definiert werden, befasst sich Abschnitt 5.2.2 mit der Darstellung grundlegender Matchingansätze. Hier soll der Forschungsfrage nachgegangen werden, welche grundlegenden Matchingverfahren bei IDI-Ontologien zum Einsatz kommen könnten und welche Gestaltungsempfehlungen aus bestehenden Matchingsystemen ableitbar sind. Abschnitt 5.3 gibt einen detaillierten Überblick über das in der IDIArchitektur eingesetzte ontologische Matchingverfahren. Dabei werden auch grundlegende arithmetische Verfahren zur Kalkulation von Äquivalenzindikatoren erläutert, die im weiteren Verlauf des Kapitels zum Einsatz kommen. Abschnitt 5.4 beschreibt mit der Hypothesenfalsifikation den ersten Arbeitsschritt des IDI-Matchingprozesses. Zielsetzung der Falsifikation ist es, Konzeptklassenpaare zu identifizieren, für die die Äquivalenzhypothese aufgrund verletzter Äquivalenzbedingungen zu verwerfen ist. Hierdurch wird die Menge der für das Matching infrage kommenden Konzeptklassenpaare reduziert. Der überwiegende Teil des Kapitels enthält Beschreibungen der Falsifikationskriterien. A. Köhler, Intelligent Data Interchange (IDI), DOI 10.1007/978-3-8348-9767-1_5, © Vieweg+Teubner Verlag |Springer Fachmedien Wiesbaden GmbH 2010

162

5 Ontologisches Matching

Abschnitt 5.5 beinhaltet die formale und informale Spezifikation der Äquivalenzindikatoren. Diese Äquivalenzindikatoren stellen Maße für den Übereinstimmungsgrad der jeweiligen ontologischen Eigenschaften zweier Konzeptklassen dar. Abschnitt 5.6 beschreibt den Äquivalenzkoeffizienten, der aus einer aggregierten Betrachtung sämtlicher Äquivalenzindikatoren die Wahrscheinlichkeit für die semantische Äquivalenz zweier Konzeptklassen ableitet. Abschnitt 5.7 schließlich untersucht, mithilfe welcher Techniken auftretende Heterogenitätseffekte überwunden werden können.

5.2 Grundlagen des ontologischen Matchings 5.2.1 Matching und Mapping – Begriffsklärung Der Zweck des ontologischen Matchings besteht darin, semantische Mappings zwischen ontologischen Entitäten zu identifizieren. "We define ontology matching as a process that takes two ontologies as input and returns the mappings that identify corresponding concepts in the two ontologies, namely the concepts with the same or the closest intended meaning."239

Die Begriffe "Matching" und "Mapping" werden in der Literatur meistens bedeutungsverschieden genutzt. Der Begriff "Matching" bezieht sich in der Regel auf den Prozess der Identifizierung semantischer Beziehungen zwischen Konzeptklassen unterschiedlicher Schemata bzw. Ontologien. "Schema matching on the other hand is the operation which takes as input two schemata and produces a mapping between elements of these schemata that correspond semantically to each other."240

Ontologische Mappings hingegen stellen das Ergebnis des Matchingprozesses dar. Ein ontologisches Mapping lässt sich bspw. definieren als

239 240

Castano et al. 2006, S. 29. Kalfoglou et al. 2005, S. 6.

5.2 Grundlagen des ontologischen Matchings

163

ƒ "[...] a correspondence between a concept of the first ontology and one or more concepts of the second ontology [...]";241 ƒ "[...] a (declarative) specification of the semantic overlap between two ontologies [...]";242 ƒ "[...] a formal expression that states the semantic relation between two entities belonging to different ontologies [...]".243

Während prinzipiell jede Art semantischer Beziehung Ergebnis eines Matchingprozesses sein kann, sind für die IDI-Architektur ausschließlich Äquivalenzbeziehungen zwischen den Konzepten unterschiedlicher Ontologien relevant.244 Synonym zum Begriff "Matching" wird in dieser Arbeit der Begriff "Abgleich" verwendet. Ontologisches Matching wird i.a. als ein ontologieübergreifender Prozess gesehen. Die abzugleichenden Objekte befinden sich also in unterschiedlichen Ontologien. Ontologisches Matching stellt eine von mehreren Strategien zur ontologischen Integration dar. In der Literatur werden weitere Ansätze zur Ontologie-Integration diskutiert.245 Eine besondere Rolle dabei spielt die Verschmelzung von Ontologien ("Ontology Merging"). Zielsetzung der Verschmelzung ist es, Entitäten unterschiedlicher Ontologien in eine neue, gemeinsame Ontologie zu überführen.246 Die neue Ontologie enthält sämtliche Strukturen und Konzepte der Ursprungsontologien. Zur Verschmelzung von Ontologien werden die gleichen oder ähnliche Methoden genutzt wie für ontologische Matchings. Sollen Methoden und Verfahren zur Integration von Ontologien hinsichtlich ihres Einsat-

241 242 243 244 245 246

Castano et al. 2006, S. 29. Predoiu et al. 2005, S. 6. Bouquet et al. 2005, S. 4. Euzenat, Shvaiko 2007, S. 2. Vgl. Hakimpour, Geppert 2002; Stuckenschmidt 2002. Vgl. Bouquet et al. 2005, S. 5.

164

5 Ontologisches Matching

zes in der IDI-Architektur evaluiert werden, so können also auch Ansätze zur Ontologieverschmelzung einbezogen werden. Forschungsanstrengungen zur ontologischen Integration haben ihren Ursprung im Forschungsgebiet "Schemaintegration" der 80er Jahre des 20. Jahrhunderts.247 Die Voraussetzungen zur Automatisierung des Matchingprozesses sind jedoch erst durch die Einführung von Ontologien geschaffen worden. Sie verfügen gegenüber einfachen Datenbankschemata über einen wichtigen Vorteil: sie enthalten eine explizite und formalisierte Darstellung der Konzeptsemantik.248 Während bei schemabasierten Integrationsansätzen lediglich charakteristische Merkmale der Instanzdaten sowie Einschränkungen einzelner Datentypen als Ansatzpunkte zur Identifizierung semantischer Äquivalenzbeziehungen ausgewertet werden können, verfügen Ontologien über eine explizite Beschreibung der Bedeutung einzelner Konzeptklassen. Darüber hinaus besitzen Ontologien eine größere Anzahl an Primitiva und Konstruktoren.249 Diese Ausdrucksstärke schafft zahlreiche Ansatzpunkte für eine semantische Differenzierung von Konzepten. Bei den in der IDI-Architektur durchzuführenden ontologischen Matchings sind immer eine Sender- und eine Empfängerontologie Matchinggegenstand. Als Senderontologie soll der Teil der Ontologie eines Senders bezeichnet werden, der die Syntax-, Semantik- und Pragmatikeigenschaften einer bestimmten Geschäftsnachricht beschreibt. Die Senderontologie wird zusammen mit der Geschäftsnachricht übertragen. Empfängerontologien repräsentieren diejenigen Ontologieausschnitte, die zur Spezifikation der zu empfangenden Geschäftsnachrichten dienen. Der empfangende IDI-Agent versucht nach dem Empfang einer Geschäftsnachricht, semantische Äquialenzbeziehungen zwischen den Be-

247

248 249

Vgl. Doan 2002, S. 1. Zum Thema "Schemaintegration bei Datenbanken" vgl. u.a.: Sheth, Kashyap 1992; Rahm, Bernstein 2001b; Milo, Zohar 1998; Berlin, Motro 2001. Vgl. Shvaiko, Euzenat 2004, S. 5. Vgl. Shvaiko 2004, S. 5.

5.2 Grundlagen des ontologischen Matchings

165

deutungseinheiten der empfangenen und denen der eigenen Ontologie zu identifizieren. Dabei besteht die Zielsetzung des Matchings für den empfangenden IDI-Agenten nicht darin, Äquivalenzbeziehungen zwischen sämtlichen Bedeutungseinheiten der beteiligten Ontologien aufzudecken. Vielmehr müssen Agenten lediglich für diejenigen Teile ihrer Ontologien Mappings finden, die die jeweilige Empfangsnachricht und ihre Bestandteile semantisch spezifizieren.250 Die Beschreibung des ontologischen Matchings in der IDI-Architektur ist Gegenstand dieses Kapitels. Eine weitere, für die IDI-Architektur relevante, Form des Matchings stellt das Protokollmatching dar. Das Protokollmatching übernimmt derjenige IDI-Agenten, der einen Protokollvorschlag empfängt. Die Zielsetzung des Protokollmatchings besteht darin, ein zum empfangenen Protokollvorschlag kompatibles Protokoll in der Empfängerontologie zu identifizieren. Die Rahmenbedingungen des Protokollmatchings sind in dem in Abschnitt 4.4.3 beschriebenen Metaprotokoll festgelegt.

5.2.2 Grundlegende Matchingansätze 5.2.2.1 Kategorisierung von Matchingansätzen

In Kapitel 4.3.3 wurde durch die Definition des Semantikvokabulars bereits festgelegt, welchen Input geeignete Matchingansätze verarbeiten können müssen. Fraglich ist nun, mithilfe welcher grundlegenden Methoden aus diesem Input Aussagen über die Äquivalenzwahrscheinlichkeit von Konzeptklassen abgeleitet werden können. Zielsetzung dieses Abschnitts und der beiden folgenden Abschnitte ist es, grundlegende ontologische Matchingverfahren zu identifizieren und zu beschreiben. Dabei soll auch analysiert werden, welche Gestaltungsempfehlungen aus bestehenden Matchingsystemen für die IDI-Architektur abgeleitet werden können.

250

Vgl. Besana, Robertson 2005, S. 1.

166

5 Ontologisches Matching

Als systematisierender Rahmen wird die in der folgenden Abbildung dargestellte, an den IDI-Inputkategorien angelehnte, hierarchische Gliederung von Matchingansätzen vorgeschlagen. IDIMatchingkategorien

Individuenbasiert

Schemabasiert

Beziehungsebene

Konzeptebene

Linguistisch

Constraintbasiert

Abbildung 15: Kategorisierung von Matchingansätzen entsprechend den IDIInputkategorien (Quelle: in Anlehnung an Rahm, Bernstein 2001a, S. 338).

Schemabasierte Ansätze nutzen die konzeptionelle Struktur von Ontologien als Input. Unter einer konzeptionellen Struktur sei hier die Summe aller Konzeptklassen und Beziehungen einer Ontologie verstanden.

Matchingansätze der Konzeptebene lassen den Beziehungskontext unberücksichtigt, auf der Beziehungsebene hingegen wird der Beziehungskontext gezielt in den Matchingprozess eingebunden.251 Der Beziehungskontext besteht in IDI-Ontologien aus den taxonomischen und mereologischen Beziehungen einer Konzeptklasse sowie aus ihren Attributen. Constraintbasierte Ansätze spielen in der IDI-Architektur vor allem bei der Reduktion des Suchraums durch Hypothesenfalsifikation eine Rolle. 251

Vgl. Euzenat, Shvaiko 2007, S. 64.

5.2 Grundlagen des ontologischen Matchings

167

Linguistische Ansätze verwenden den Namen von Konzeptklassen für das ontologische Matching. Individuenbasierte Ansätze betrachten die Eigenschaften von Individuen, um semantische Äquivalenz diagnostizieren zu können. Matchingobjekte in der IDI-Architektur sind Geschäftsdateneinheiten.

Bei den individuenbasierten Ansätzen können einerseits linguistische Verfahren zum Einsatz kommen, wie sie bspw. auch auf dem Gebiet des Information Retrieval Verwendung finden. Eine andere Option besteht darin, die Bedeutung von Instanzdaten anhand charakteristischer Zeichen bzw. Zeichenketten zu erkennen.252 Zwar existieren in der Literatur mittlerweile einige Systeme und Architekturen für das ontologische Matching.253 Die Liste der Matchingansätze, aus denen sich Gestaltungsempfehlungen ableiten lassen, ist jedoch aufgrund der IDI-Anforderungen stark eingeschränkt. ƒ Zielsetzung der IDI-Architektur ist eine Automatisierung des ontologischen Matchings; zahlreiche Matchingansätze sind jedoch auf einen halbautomatischen Betrieb ausgelegt, der lediglich eine Unterstützung für menschliche Aufgabenträger bieten soll. ƒ Zahlreiche Matchingansätze produzieren nicht den gewünschten Output, nämlich semantische Äquivalenzbeziehungen zwischen Konzeptklassen. ƒ Viele Ansätze verwenden Input, der nicht dem in IDI-Ontologien verfügbaren Input entspricht. ƒ Da fast jede Inputkategorien eine individuelle Matchingmethode benötigt, besteht die zentrale Herausforderung in der anschließenden Aggregation der Einzelergebnisse zu einer gesamten Äquivalenzaus-

252 253

Vgl. Rahm, Bernstein 2001a, S. 342. Einen Überblick über Matching-Systeme liefern: Euzenat, Shvaiko 2007, S. 153192; Kalfoglou, Schorlemmer 2003; Noy, Musen 2002; Shvaiko 2004; Rahm, Bernstein 2001b, S. 7-18; Do et al. 2002.

168

5 Ontologisches Matching

sage.254 Bislang existieren jedoch kaum Ansätze für das sog. MetaMatching. ƒ Als zentrale Problematik einer Architektur, die aus einer öffentlichen und vielen privaten Ontologien besteht, ist die potenzielle Heterogenität zwischen den privaten Ontologien zu betrachten. Eine umfassende, auf die Besonderheiten der IDI-Architektur zugeschnittene Analyse der Ursachen und Effekte von Heterogenität ist nicht Gegenstand bestehender Forschungsansätzen. Gleiches gilt für die Entwicklung von Strategien zur Heterogenitätsüberwindung. ƒ Aufgrund der großen Anzahl benötigter Mappings könnte es für die IDI-Architektur von großem Vorteil sein, über Verfahren zur Reduktion des Suchraums zu verfügen. Derartige, auf die Bedürfnisse der IDI-Architektur, zugeschnittene Verfahren sind zurzeit noch nicht verfügbar.

Es werden in den nächsten beiden Abschnitten nur solche Matchingansätze betrachtet, die unter Berücksichtigung der o.g. Anforderungen Gestaltungshinweise für das IDI-Matching liefern können. 5.2.2.2 Schemabasiertes Matching

Eine wichtige Rolle bei den konzeptbasierten Matchingansätzen spielt in der IDI-Architektur das sog. linguistische Matching. Hier wird die semantische Äquivalenz zweier Konzeptklassen aus dem Übereinstimmungsgrad ihrer Namen abgeleitet.255 Einem solchen Ansatz liegt die Annahme zugrunde, dass von einem Konzeptnamen auf die Konzeptbedeutung geschlossen werden kann. Die Funktionsfähigkeit eines solchen Ansatzes ist allerdings nur dann gewährleistet, wenn die Namen von Konzeptklassen Bestandteile einer natürlichen Sprache sind.256 Zum linguistischen Matching kann auch das sog. lexikalische Matching gezählt werden. Lexikalisches Matching verwendet z.B. Thesauri, die für

254

255 256

Die Problematik der Aggregation von einzelnen Mappings zu einem Gesamtmapping wird in Abschnitt 5.6 thematisiert. Vgl. Rahm, Bernstein 2001a, S. 339-340. Vgl. Magnini et al. 2002, S. 3.

5.2 Grundlagen des ontologischen Matchings

169

einzelne Worte Synonymlisten enthalten. Schlägt der Abgleich für zwei Matchingkandidaten fehl, so lässt sich anhand eines Thesaurus ermitteln, ob ein Synonymiekonflikt Ursache für den fehlgeschlagenen Abgleich gewesen sein könnte. Zur Ermittlung der Ähnlichkeit von Zeichenketten existieren zahlreiche Berechnungsmethoden, die in Abschnitt 5.5.1 vorgestellt und evaluiert werden. Constraintbasierte Verfahren, die ebenfalls zu den konzeptbasierten Matchingansätzen zählen, nutzen als Input die für einzelne Klassen definierten Beschränkungen oder Randbedingungen.257 Hierzu können bspw. Datentypen, Wertebereiche oder die Optionalität von Konzeptklassen gehören.258

Constraints stellen nur schwache Äquivalenzindizien dar, da die in Constraints formulierten Randbedingungen nur einen groben Klassifizierungsansatz liefern und somit von zahlreichen Individuen erfüllt werden können.259 Es erscheint wenig sinnvoll, solche Randbedingungen zur Äquivalenzberechnung in der IDI-Architektur zu nutzen. Constraints werden hier stattdessen als notwendige Äquivalenzbedingungen interpretiert und zur Falsifikation von Äquivalenzhypothesen verwendet. Bspw. ist eine Äquivalenzhypothese falsifiziert, wenn zwei Konzeptklassen über inkompatible Maßeinheiten verfügen. Das Verfahren zur Reduktion des Suchraums durch Hypothesenfalsifikation wird in Kapitel 5.4 vorgestellt. Ebenfalls einen wichtigen Anknüpfungspunkt für das ontologische Matching liefert der Beziehungskontext einer Konzeptklasse. Beziehungskontexte in IDI-Ontologien bestehen aus taxonomischen und mereologischen Beziehungen sowie aus Attributbeziehungen.

257

258 259

Ein Beispiel für ein constraintbasiertes Matchingverfahren findet sich in der Arbeit von Chen et al. Vgl. Chen et al. 2005. Vgl. Rahm, Bernstein 2001a, S. 341. Vgl. Rahm, Bernstein 2001a, S. 341.

170

5 Ontologisches Matching

Kennzeichnend für die meisten Matchingansätze auf der Beziehungsebene ist, dass sie als Input auf die Ergebnisse eines vorgelagerten Matchingprozesses zurückgreifen müssen. Dieser vorgelagerte Prozess basiert meistens auf linguistischen Matchingverfahren. Äquivalenzindikatoren, die auf die Ergebnisse eines anderen Matchingverfahrens als Input angewiesen sind, werden in der IDI-Architektur als sekundäre Äquivalenzindikatoren bezeichnet. Dementsprechend werden Matchingverfahren, die auch ohne vorhandene Mappings ein Ergebnis liefern, primäre Äquivalenzindikatoren genannt. Als ein typisches Beispiel für beziehungsbasiertes Matching sei der CUPID-Ansatz vorgestellt.260 In einem ersten Schritt sehen Madhavan et al. die Ermittlung eines linguistischen Ähnlichkeitswerts für die abzugleichenden Konzeptklassenpaare vor. In einem zweiten Schritt soll die strukturelle Ähnlichkeit der abzugleichenden Konzeptklassenpaare ermittelt werden. Voraussetzung für diesen Abgleich ist, dass die Konzeptklassen in einer hierarchischen Struktur wie einer Taxonomie vorliegen. Bei der Ermittlung eines semantischen Ähnlichkeitswertes unterscheiden Madhavan et al. zwischen Blättern und Knoten der Hierarchie. ƒ Blattkonzepte sind ähnlich, wenn sie linguistisch ähnlich sind und über ähnliche Geschwister und Vorfahren verfügen. ƒ Knotenkonzepte sind ähnlich, wenn sie linguistisch ähnlich sind und über ähnliche Teilbäume verfügen.

Als weitere Beispiele, die im Wesentlichen auf einer ähnlichen Matchingstrategie beruhen, seien noch der ASCO-Algorithmus sowie der HMatch-Ansatz261 genannt. Die Idee, die semantische Äquivalenz zwischen zwei Konzeptklassen von der Ähnlichkeit des jeweiligen semantischen Kontextes abhängig zu machen, wird auch in der IDI-Architektur aufgegriffen. Hier werden die Übereinstimmungsgrade des mereologischen, taxonomischen sowie des

260 261

Vgl. Madhavan et al. 2001. Vgl. Castano et al. 2006.

5.2 Grundlagen des ontologischen Matchings

171

Attributkontextes in die Kalkulation einer Äquivalenzwahrscheinlichkeit einbezogen. Als einer der wenigen beziehungsbasierten Ansätze, der ohne einen Rückgriff auf vorangegangene Matchings auskommt, ist das Verfahren "Similarity Flooding" zu nennen. Da es als sinnvoll erscheint, eine möglichst breite Basis an primären Äquivalenzindikatoren zu schaffen, wurde dieses Verfahren in den IDI-Ansatz integriert. Eine detaillierte Erläuterung ist in Abschnitt 5.5.4 zu finden. 5.2.2.3 Individuenbasiertes Matching

Individuenbasiertes Matching beruht auf der Annahme, dass sich aus den Eigenschaften eines Individuums Aussagen über seine Bedeutung ableiten lassen. Individuenbasierte Matchingmethoden verwenden oft maschinelle Lernverfahren. Maschinelle Lernverfahren greifen auf Trainingsmengen zurück, in denen jeder Konzeptklasse eine bestimmte Individuenmenge zugeordnet ist. Es wird angenommen, dass Individuen, die Instanzen einer bestimmten Konzeptklasse sind, über ein charakteristisches Eigenschaftsprofil verfügen. Agenten können somit maschinelle Lernverfahren nutzen, um aus der retrospektiven Analyse des Eigenschaftsprofils aller zu einer Konzeptklasse C1 gehörenden Individuen einen Wahrscheinlichkeitswert dafür zu errechnen, dass das Individuum einer Konzeptklasse C2 aufgrund seiner Eigenschaften ebenfalls ein Individuum der Konzeptklasse C1 ist und somit die Konzeptklassen C1 und C2 semantisch äquivalent sind. Als Beispiel für individuenbasiertes Matching sei die GLUE-Architektur vorgestellt.262 GLUE untersucht den Zusammenhang zwischen der Eigenschaftsmenge eines Individuums und der Konzeptklassenbedeutung. Es sei mit d ^w1 ,! ,w k ` die Eigenschaftsmenge einer Konzeptklasse  d mit den Eigenschaften ^w1 ,! ,w k ` bezeichnet. Gesucht ist die bedingte

Wahrscheinlichkeit dafür, dass ein Individuum zu einer bestimmten

262

Vgl. Doan et al. 2002.

172

5 Ontologisches Matching

Konzeptklasse gehört, wenn deren Eigenschaftsmenge d bekannt ist. Diese bedingte Wahrscheinlichkeit sei mit P  A | d bezeichnet und lässt sich mithilfe des Bayes-Verfahrens berechnen:263 P  A | d D P d | A P  A .

Als individuenbasierte Eigenschaften in der IDI-Architektur können alle Eigenschaften betrachtet werden, die sich unmittelbar aus dem Geschäftsdatenstrom ergeben. Als Beispiele für solche Eigenschaften seien die Zeichen, die Länge oder die Häufigkeit des Vorkommens einer Geschäftsdateneinheit genannt. Die oben genannte Formel ist nur dann anwendbar, wenn jeweils eine einzelne Eigenschaft betrachtet wird. Sollen mehrere Eigenschaften berücksichtigt werden, dann lässt sich die bedingte Wahrscheinlichkeit P  A | d unter der Annahme der statistischen Unabhängigkeit264 des Auftretens einzelner Eigenschaften durch die sog. Naive Bayes-Formel265 berechnen: P A | d

n

D P  A – P w k | A . k 1

Hierbei gibt P w k | A die relative Wahrscheinlichkeit des Auftretens einer Eigenschaft wk an, wenn bekannt ist, dass das Individuum zur Konzeptklasse A gehört. Die Variable n steht für die Anzahl der betrachteten Eigenschaften. Die Idee des individuenbasierten Matchings wird in der IDI-Architektur bei der Berechnung der RA-Relevanz aufgegriffen. Die RA-Relevanz ist einer der IDI-Äquivalenzindikatoren und wird mithilfe der BayesFormel berechnet. Eine detaillierte Erläuterung zur Verwendung der Bayes-Formel ist Abschnitt 5.3.3.2 zu entnehmen.

263 264

265

Das Bayes-Verfahren wird in Abschnitt 5.3.3.2 vorgestellt. Zur statistischen Unabhängigkeit zweier Ereignisse vgl. Bamberg, Baur 2002, S. 88. Vgl. Lewis 1998; Pearle 1988, S. 40.

5.3 IDI-Ansatz für das ontologische Matching

173

Als Input verwendet der Äquivalenzindikator "RA-Relevanz" die Struktur der Geschäftsdateneinheiten. Für weitere Details sei auf Kapitel 5.5.6 verwiesen.

5.3 IDI-Ansatz für das ontologische Matching 5.3.1 Extensionale vs. intensionale Äquivalenz Die Zielsetzung des ontologischen Matchings in der IDI-Architektur besteht in der Identifikation semantisch äquivalenter Konzeptklassen zwischen den abzugleichenden Ontologien. Gegenstand dieses Abschnitts ist es, den Begriff der semantischen Äquivalenz zu konkretisieren und zu operationalisieren. In der IDI-Architektur soll zwischen extensionaler und intensionaler Äquivalenz unterschieden werden. Die Bedeutung beider Äquivalenzkategorien sei anhand einer abgewandelten Form des semiotischen Dreiecks veranschaulicht.266 le na z o n i ns le te iva n i qu en Ä i er z i if ez sp

Konzeptklasse

Konzeptmerkmale

repräsentiert

de te

rm

in i er t

Individuum

extensionale Äquivalenz

Abbildung 16: Abgewandelte Form des semiotischen Dreiecks

266

Für eine sprachwissenschaftliche Definition des semiotischen Dreiecks vgl. Lorenz 2004a, S. 781.

174

5 Ontologisches Matching

Zwei Konzeptklassen sollen als extensional äquivalent bezeichnet werden, wenn sie die gleichen Individuen repräsentieren. Extensionale Äquivalenz manifestiert sich also durch die Übereinstimmung der Extensionen zweier Konzeptklassen. Allerdings lässt sich diese Übereinstimmung in der IDI-Architektur nicht prüfen, da für die anzugleichenden Konzeptklassen keine Individuenmengen verfügbar sind. Die Strategie in der IDI-Architektur besteht somit in der Ermittlung der intensionalen Äquivalenz. Intensionale Äquivalenz tritt auf, wenn zwei Konzeptklassen die gleichen Merkmale besitzen. Die fett gedruckten Doppelpfeile in der oben dargestellten Abbildung zeigen auf die jeweiligen Bezugsobjekte, auf die sich die Aussagen über die semantische Äquivalenz zweier Konzeptklassen beziehen. In der IDI-Architektur wird von der intensionalen auf die extensionale Äquivalenz geschlossen. Es wird also angenommen, dass zwei Konzeptklassen, die identische Merkmale besitzen, auch über die gleichen Individuenmengen verfügen. Die hinter dem Begriff der intensionalen Äquivalenz stehende Annahme der Ableitbarkeit semantischer Äquivalenzbeziehungen aus dem Übereinstimmungsgrad ontologischer Merkmale zweier Konzeptklassen sei durch das folgende Schaubild verdeutlicht.

5.3 IDI-Ansatz für das ontologische Matching

ier

en

Ontologische Eigenschaften

t ie r

Ontologie 1

zi fiz

mi ni e rt

Ontologie 2

Konzeptklassenäquivalenz ?

Konzept 2

Individuenmenge 1

repräsentiert

Konzept 1 sp e

175

m ter de

in

Übereinstimmungsgrad Ontologiz ifi ez p s

en sche Eigenier

schaften

de ter

repräsentiert

Individuenmenge 2

Abbildung 17: Ableitung der Konzeptklassenäquivalenz

5.3.2 Äquivalenzbedingungen und -indikatoren Bei der Ableitung semantischer Äquivalenz ist zwischen notwendigen und hinreichenden Äquivalenzbedingungen sowie Äquivalenzindikatoren zu unterscheiden. Notwendige Äquivalenzbedingungen sind solche Eigenschaften, die erfüllt sein müssen, damit Konzeptklassen semantisch äquivalent sein können. Jedoch kann aus der Erfüllung einer notwendigen Äquivalenzbedingung nicht automatisch auf Äquivalenz geschlossen werden. Allerdings stellt die Verletzung einer notwendigen Äquivalenzbedingung eine hinreichende Bedingung für semantische Inäquivalenz dar. Not-

176

5 Ontologisches Matching

wendige Äquivalenzbedingungen werden daher in IDI-Ontologien zur Falsifikation von Äquivalenzhypothesen genutzt.267 Als Beispiel für eine notwendige Äquivalenzbedingung sei die Kompatibilität von Maßeinheiten genannt. Konzeptklassen mit den Maßeinheiten "Meter" und "Kilometer" können äquivalent sein, nicht hingegen Konzeptklassen mit den Maßeinheiten "Meter" und "Gramm". Aus hinreichenden Äquivalenzbedingungen könnte direkt die semantische Äquivalenz der betrachteten Konzeptklassen gefolgert werden. Faktisch sind solche Bedingungen jedoch im IDI-Anwendungsumfeld nicht vorhanden. Selbst bei einer völligen Übereinstimmung der ontologischen Eigenschaften lässt sich die semantische Äquivalenz der betrachteten Konzeptklassen nicht garantieren. In einem automatisierten Matchingprozess lassen sich lediglich Wahrscheinlichkeitswerte für die semantische Äquivalenz zweier Konzeptklassen errechnen und angeben. Solche Maßzahlen werden in der IDIArchitektur Äquivalenzindikatoren genannt. Formal betrachtet stellt ein Äquivalenzindikator simE C1 ,C2 eine Funk-

tion dar, die für die zu mappenden Konzeptklassen C1 ,C2 einen auf die Eigenschaft E bezogenen Ähnlichkeitswert zwischen 0 und 1 zurückgibt. Ein Äquivalenzindikator simE C1 ,C2 1 zeigt die völlige Übereinstimmung der Konzeptklassen C1 ,C2 bezogen auf die Eigenschaft E an. Ein

Äquivalenzindikator simE C1 ,C2 0 signalisiert, dass keine Überein-

stimmung der Konzeptklassen C1 ,C2 bezogen auf die Eigenschaft E festzustellen ist.

Die Äquivalenzindikatoren werden je Konzeptklassenpaar zu einer Maßzahl, dem Äquivalenzkoeffizienten, zusammengefasst. Der Äquivalenzkoeffizient stellt ein Maß für die Äquivalenzwahrscheinlichkeit der betrachteten Konzeptklassenpaare dar. In der IDI-Architektur werden sechs Äquivalenzindikatoren als Input zur Berechnung des Äquivalenzkoeffizienten ermittelt:

267

Vgl. Abschnitt 5.4.

5.3 IDI-Ansatz für das ontologische Matching

177

ƒ simBEZ gibt den Übereinstimmungsgrad der Bezeichner an. ƒ simTAX gibt den Übereinstimmungsgrad des taxonomischen Kontextes an. ƒ simMER gibt den Übereinstimmungsgrad des mereologischen Kontextes an. ƒ simGRA gibt den Übereinstimmungsgrad der Graphenstruktur an, in die die betrachteten Konzeptklassen eingebettet sind. ƒ simRAW gibt die bedingte Äquivalenzwahrscheinlichkeit an, wenn bekannt ist, dass die betrachteten Geschäftsdaten mit einem Regulären Ausdruck übereinstimmen. ƒ simATT gibt den Übereinstimmungsgrad der Attribute an.

Eine Beschreibung der in der IDI-Architektur verwendeten Äquivalenzindikatoren ist in Kapitel 5.5 zu finden. Die Aggregation der einzelnen Indikatoren zu einem Äquivalenzkoeffizienten wird in Abschnitt 5.6 beschrieben.

5.3.3 Methodische Grundlagen 5.3.3.1 Dicekoeffizient

Drei der sechs Äquivalenzindikatoren berechnen den Übereinstimmungsgrad eines semantischen Kontextes. Hierzu gehören ƒ der Attributkoeffizient, ƒ der Taxonomiekoeffizient sowie ƒ der Mereologiekoeffizient.

Zur Berechnung dieser Indikatoren muss jeweils in den einzelnen Kontexten die Menge der semantisch äquivalenten Konzeptklassenpaare zur Menge aller Konzeptklassenpaare ins Verhältnis gesetzt werden. Derartige Ähnlichkeitsmaße lassen sich mithilfe des aus dem Information Retrieval bekannten Jaccard- oder Dicekoeffizienten errechnen.268 268

Vgl. Mohammad, Hirst 2005, S. 9.

178

5 Ontologisches Matching

Beide Koeffizienten führen zu den gleichen Klassifikationsergebnissen.269 Zur weiteren Verwendung wurde der Dicekoeffizient ausgewählt, der auf die Bedürfnisse der IDI-Architektur angepasst wird. Es bezeichne KAT  Klo die Menge der Konzeptklassen, die durch die Merkmalskategorie KAT mit der Konzeptklasse Klo verbunden sind. Weiterhin sei KAT  Kme definiert als die Menge der Konzeptklassen, die durch die Merkmalskategorie KAT mit der Konzeptklasse Kme verbunden sind. Für das Dicemaß in der IDI-Architektur ( DMKAT ) sei nun die unten stehende Formel definiert. DMKAT  Klo,Kme

2 ˜ # KATˆ  Klo,Kme # KAT  Klo  # KAT  Kme

Formel 21: Dicekoeffizient

Die Menge KATˆ  Klo,Kme bedarf einer gesonderten Definition. Hierbei handelt es sich um die Teilmenge des kartesischen Produkts ª¬KAT  Klo u KAT  Kme º¼ , deren geordneten Paare semantisch äquivalent

sind. Dabei muss gelten, dass für jedes Klo  KAT  Klo genau ein semantisches Äquivalent aus KAT  Kme existieren muss und umgekehrt. Entsprechend sei nun die Menge KATˆ  Klo,Kme definiert. ­ ½ C1  KAT  Klo š C2  KAT  Kme š ° ° ° ° KATˆ  Klo,Kme : ®C1 ,C2 ªC1 , 1C2 : C1 { C2 º š ¾ ¬ ¼ ° ° ªC2 , 1C1 : C1 { C2 º ° ° ¬ ¼ ¯ ¿ Definition 1: Zähler des Dicekoeffizienten

5.3.3.2 Wahrscheinlichkeitstheoretische Grundlagen und Bayestheorem

Einer der IDI-Äquivalenzindikatoren (die RA-Relevanz) sowie der Äquivalenzkoeffizient basieren auf der sog. Bayes-Formel. Daher sollen an

269

Vgl. Finch 2005, S. 91.

5.3 IDI-Ansatz für das ontologische Matching

179

dieser Stelle die Grundlagen zur Berechnung von Wahrscheinlichkeitswerten mithilfe der Bayes-Formel dargestellt werden. Die Wahrscheinlichkeit P  A eines Ereignisses A ist definiert als "[...] das Verhältnis der Anzahl an günstigen Ereignissen nA zur Gesamtzahl der unvereinbaren, gleichmöglichen Ereignisse, d.h. P  A

n A 270 ." n

In der Agentenforschung wird die Wahrscheinlichkeit P  A auch als Glaubensgrad eines Agenten hinsichtlich des Ereignisses A interpretiert.271 Bei einem Glaubensgrad von "0" geht der Agent davon aus, dass das betrachtete Ereignis nicht eintritt. Ein Glaubensgrad von "1" signalisiert das sichere Eintreten des Ereignisses. Insb. bei der Modellierung unsicheren Wissens spielt der Begriff der bedingten Wahrscheinlichkeit eine große Rolle.272 Die bedingte Wahrscheinlichkeit repräsentiert "[...] die Wahrscheinlichkeit dafür, daß eine Aussage A zutrifft, unter der Voraussetzung, daß eine andere Aussage B gilt. Durch das Gelten der Aussage B verändert sich im allgemeinen die Wahrscheinlichkeit der Aussage A."273

Die bedingte Wahrscheinlichkeit, formal notiert als P  A | B , wird auch als A-posteriori-Wahrscheinlichkeit bezeichnet, die unbedingte Wahrscheinlichkeit als A-priori-Wahrscheinlichkeit.274 Bedingte Wahrscheinlichkeiten lassen sich z.B. für die sog. diagnostische Inferenz verwendet. Hierbei wird, ausgehend von der Wahrscheinlichkeit eines Evidenzfaktors, die Wahrscheinlichkeit einer bestimmten Diagnose errechnet.275 Die Grundlagen der Kalkulation diagnostischer

270 271 272 273 274 275

Borgelt et al. 2000, S. 296. Vgl. Russel, Norvig 2004, S. 571-572. Vgl. Spies 1993, S. 36. Spies 1993, S. 36. Vgl. Russel, Norvig 2004, S. 577-578. Vgl. Spies 1993, S. 36.

180

5 Ontologisches Matching

Wahrscheinlichkeiten seiŽ— nun auf die Anwendungsdomäne der IDIArchitektur übertragen. Die Äquivalenz zwischen zwei Konzeptklassen ( C1 { C2 ) kann als Ereignis interpretiert werden. Dann repräsentiert der Wert P C1 { C2 die Apriori-Wahrscheinlichkeit für die semantische Äquivalenz der beiden Konzeptklassen. Soll die Äquivalenzwahrscheinlichkeit auf einen bestimmten Evidenzfaktor ( e ) bezogen werden, so ist die bedingte Äquivalenzwahrscheinlichkeit P C1 { C2 | e zu berechnen. Die bedingte Äquivalenzwahrscheinlichkeit P C1 { C2 | e gibt die Wahrscheinlichkeit für die Äquiva-

lenz der beiden Konzeptklassen C1 und C2 an, wenn bekannt ist, dass der Evidenzfaktor e vorliegt. Diese bedingte Äquivalenzwahrscheinlichkeit lässt sich mithilfe der sog. Bayes-Formel berechnen.276 P  e | C1 { C2 < P C1 { C2 P e

P C1 { C2 | e

D ˜ P  e | C1 { C2 ˜ P C1 { C2 Formel 22: Berechnung der Konzeptklassenäquivalenz mithilfe der Bayes'schen Regel

In vielen Fällen lässt sich die A-priori-Wahrscheinlichkeit für den Evidenzfaktor ( P  e ) nicht ermitteln. In diesem Fall kann z.B. zusätzlich zu P C1 { C2 | e auch die Wahrscheinlichkeit P C1 { C2 | e sowie der Nor-

malisierungsfaktor D errechnet werden. Die Normalisierungskonstante sorgt dafür, dass die Addition aus P C1 { C2 | e und P C1 { C2 | e den Wert "1" ergibt.

276

Vgl. Russel, Norvig 2004, S. 590.

5.3 IDI-Ansatz für das ontologische Matching

181

D ª¬P C1 { C2 | e  P C1 { C2 | e º¼ 1 œ

D

1 ¬ªP C1 { C2 | e  P C1 { C2 | e ¼º

Formel 23: Ableitung der Normalisierungskonstante zur Berechnung der BayesFormel

Die bedingte Wahrscheinlichkeit P  e | C1 { C2 stellt die sog. kausale Wahrscheinlichkeit dar. Sie repräsentiert in dem hier dargestellten Anwendungsfall die Wahrscheinlichkeit für das Auftreten des Evidenzereignisses, wenn die betrachteten Konzeptklassen semantisch äquivalent sind.

5.3.4 Primäre vs. sekundäre Äquivalenzindikatoren und Matchingprozess In der IDI-Architektur ist die Nutzung von Äquivalenzindikatoren vorgesehen, die auf die Ergebnisse anderer, bereits ermittelter Äquivalenzindikatoren zurückgreifen müssen. Diese Unterscheidung zwischen den sog. primären und sekundären Äquivalenzindikatoren beeinflusst den Matchingprozess und wird daher an dieser Stelle thematisiert. Die folgende Abbildung veranschaulicht die Zuordnung der in der IDIArchitektur vorgesehenen Indikatoren zu den beiden genannten Kategorien.

182

Semantische Eigenschaften

5 Ontologisches Matching Konzeptklassenbezeichner

simBEZ

Struktureigenschaft der Instanz

simRAW

Beziehungskontext der Konzeptklasse

simGRA

Mereologischer Kontext

simMER

Attribute der Konzeptklassen

simATT

Taxonomischer Kontext

simTAX

Primäre Äquivalenzindikatoren

Sekundäre Äquivalenzindikatoren

Abbildung 18: Primäre und sekundäre Äquivalenzindikatoren

Primäre Äquivalenzindikatoren werden nur zu Beginn des Matchingprozesses einmal berechnet. Ihre Werte hängen nicht von den Werten anderer Äquivalenzindikatoren ab. Anders hingegen die sekundären Äquivalenzindikatoren: diese sind ggf. in einem iterativen Prozess neu zu berechnen, weil sich durch jede Iteration ihr Input ändert.

Ausgangspunkt für den Matchingprozess ist eine Äquivalenz- bzw. Hypothesenmenge H0 . Diese Menge beinhaltet alle Bedeutungseinheitenpaare, die sich aus den beiden Mengen der Bedeutungseinheiten zweier Ontologien bilden lassen. Mathematisch betrachtet entspricht die Hypothesenmenge H0 also dem kartesischen Produkt der Bedeutungseinheiten zweier Ontologien. In jeder Berechnungsstufe, die auf H0 folgt, werden die Äquivalenzindikatoren sowie der Äquivalenzkoeffizient für die in der jeweiligen Hypothesenmenge enthaltenen Konzeptklassenpaare berechnet. Wurden Konzeptklassenpaare als heterogen identifiziert, so wird versucht, diese Heterogenität mittels der in Kapitel 5.7 dargestellten Verfahren zu überwinden. Alle Paare, die als eindeutig inäquivalent identifiziert werden konnten, werden aus der Hypothesenmenge entfernt. Im Idealfall besteht die Hy-

5.3 IDI-Ansatz für das ontologische Matching

183

pothesenmenge zum Ende des Kalkulationsprozesses nur noch aus äquivalenten Konzeptklassenpaaren. Der Matchingprozess sei nun auch grafisch dargestellt.

Input

Output

Hypothesenmenge H0

HypothesenFalsifikation (n = 1)

Hypothesenmenge Hn

Hypothesenmenge Hn

Berechnung primäre Äquivalenzindikatoren

Primäre Äquivalenzindikatoren für Hn

Primäre Äquivalenzindikatoren für Hn

Berechnung sekundäre Äquivalenzindikatoren

Sekundäre Äquivalenzindikatoren für Hn

Sekundäre Äquivalenzindikatoren für Hn

Berechnung Äquivalenzkoeffizient

Äquivalenzkoeffizient für Hn

Äquivalenzkoeffizient für Hn

Heterogenitätsüberwindung (n = n + 1)

Hypothesenmenge Hn

Iteration

Nein

Hn = Hn-1?

Ja

Ende

Abbildung 19: Matchingprozess

Der Iterationsprozess soll dann stoppen, wenn durch die Verfahren zur Heterogenitätsüberwindung keine Verbesserung des Mappingergebnisses mehr erzielt werden kann oder wenn eine vorab festgelegte Anzahl an Iterationen erreicht wurde. Das Mapping war erfolgreich, wenn alle obligatorischen Konzeptklassen der betrachteten Ontologien einen semantisch äquivalenten Partner ge-

184

5 Ontologisches Matching

funden haben. War das Mapping nicht erfolgreich, so können die Kommunikationspartner nicht automatisiert Geschäftsdaten austauschen. Die Klassifizierungsgüte einzelner Äquivalenzindikatoren oder des Äquivalenzkoeffizienten kann durch die sog. Korrektklassifikationsrate (4 ) angegeben werden. Diese ermittelt für eine bestimmte Hypothesenmenge den relativen Anteil der korrekt ermittelten Äquivalenz- und Inäquivalenzaussagen.

5.4 Reduktion des Suchraums durch Hypothesenfalsifikation 5.4.1 Formale Definition der Hypothesenmengen H0 und H1 Der IDI-Matchingprozess startet mit der Hypothesenfalsifikation. Die Zielsetzung besteht darin, für jede denkbare Kombination aus Konzeptklassen zu prüfen, ob die notwendigen Äquivalenzbedingungen erfüllt sind oder nicht. Eine Kalkulation von Äquivalenzwahrscheinlichkeiten ist nicht Gegenstand der Hypothesenfalsifikation. Vielmehr wird geprüft, welche Konzeptklassenpaare inäquivalent sind. Der Vorteil der Falsifikation als ein dem eigentlichen Matching vorgeschalteter Arbeitsschritt besteht in der starken Reduzierung des Suchraums und somit einer entsprechenden Einsparung von Rechenkapazität. Der Input für die Hypothesenfalsifikation besteht aus der Hypothesenmenge H0 . Es sei die Menge der Bedeutungseinheiten einer Senderontologie mit KMEBE sowie die Menge der Bedeutungseinheiten einer Empfängerontologie mit KLOBE definiert. Dann lässt sich die Hypothesenmenge H0 als das kartesische Produkt aus KLOBE und KMEBE definieren. H0 :

^ Klo,Kme |  Klo,Kme  KLOBE u KMEBE `

Definition 2: Hypothesenmenge der Stufe 0

Als Output produziert der Falsifikationsprozess die Hypothesenmenge H1 . Bestandteil dieser Hypothesenmenge sind alle Elemente von H0 , die

5.4 Reduktion des Suchraums durch Hypothesenfalsifikation

185

nicht die in den folgenden Abschnitten definierten notwendigen Äquivalenzbedingungen verletzen. Die Erfüllung einer Äquivalenzbedingung wird durch die folgenden Rollen angezeigt: ƒ kompRAR , ƒ kompSER , ƒ kompGBR , ƒ kompMER sowie ƒ kompWTR .

Alle diese Rollen sind asymmetrisch, da der Rollenerste immer ein Element der lokalen Ontologie sein muss, der Rollenzweite ein Element der erhaltenen Ontologie. Jede Rolle repräsentiert eine Äquivalenzbedingung. Die weitere formale und informale Spezifikation dieser Rollen ist Gegenstand der beiden folgenden Abschnitte 5.4.2 und 5.4.2.2. Es sei nun die Hypothesenmenge H1 formal definiert. ­ ° ° ° ° H1 : ® Klo,Kme ° ° ° ° ¯

½  Klo,Kme  H0 š °  Klo ‹ kompRAR .Kme š °  Klo ‹ kompGBR .Kme š °° ¾  Klo ‹ kompSER .Kme š °  Klo ‹ kompMER .Kme š °°  Klo ‹ kompWTR .Kme °¿

Definition 3: Hypothesenmenge der Stufe 1

5.4.2 Notwendige Äquivalenzbedingungen 5.4.2.1 RA-Kompatibilität sowie Strukturelementtypen- und GBoxÜbereinstimmung RA-Kompatibilität als notwendige Äquivalenzbedingung setzt die Vereinbarkeit zweier Konzeptklassen hinsichtlich der Geschäftsdateneinheit der einen und des Regulären Ausdrucks der anderen Konzeptklasse vor-

186

5 Ontologisches Matching

aus. RA-Kompatibilität zwischen einer erhaltenen Konzeptklasse Kme und einer lokalen Konzeptklasse Klo liegt in drei Fällen vor: ƒ Der zu Kme gehörende Geschäftsdatenstrom ist kompatibel zum Regulären Ausdruck von Klo . ƒ Für Klo ist kein Regulärer Ausdruck definiert; da somit keine RAInkompatibilität auftreten kann, wird das betreffende Konzeptklassenpaar als RA-kompatibel betrachtet. ƒ Für Klo ist eine abgeschlossene Klasse definiert und der zu Kme gehörende Geschäftsdatenstrom stimmt mit einem Element der abgeschlossenen Klasse von Klo überein.

Alle Konzeptklassenpaare, bestehend aus einer erhaltenen Konzeptklasse Kme und einer lokalen Konzeptklasse Klo , können nur dann semantisch äquivalent sein, wenn sie mindestens eine der drei o.a. Bedingungen erfüllen. Die RA-Kompatibilität zwischen zwei Bedeutungseinheiten sei durch die Rolle kompRAR ausgedrückt. RA-Kompatibilität spielt nur auf Ebene derjenigen Bedeutungseinheiten eine Rolle, denen ein Datenfeld zugeordnet ist. Der Bild- und Domänenbereich ist entsprechend zu definieren.

   hatBER .Datenfeld

F‹ kompRAR . hatBER .Datenfeld F‹

kompRAR .

Axiom 43: Domänen- und Bildbereich der Rolle "kompRA"

Strukturelementtypen-Übereinstimmung als notwendige Äquivalenzbedingung sagt aus, dass Bedeutungseinheiten nur dann semantisch äquivalent sein können, wenn ihnen der gleiche Strukturelementtyp zugeordnet ist. Es erscheint z.B. offensichtlich, dass die Bedeutungseinheit, die eine Nachricht repräsentiert, nicht zu einer Bedeutungseinheit semantisch äquivalent sein kann, die ein Datenfeldinhalt repräsentiert.

Die Übereinstimmung der Strukturelemente zweier Konzeptklassen soll durch die Rolle kompSER ausgedrückt werden. Der Domänen- und Bildbereich dieser Rolle besteht aus Bedeutungseinheiten, denen ein Strukturelement zugeordnet ist.

5.4 Reduktion des Suchraums durch Hypothesenfalsifikation

187

 F‹ kompSER .  hatBER F‹ kompSER . hatBER

Axiom 44: Domänen- und Bildbereich der Rolle "kompSE"

Die notwendige Äquivalenzbedingung "GBox-Übereinstimmung" besagt, dass zwei Bedeutungseinheiten Spezialisierungen der gleichen GBox-Konzeptklasse sein müssen, um semantisch äquivalent sein zu können. GBox-Übereinstimmung ist in zwei Fällen gegeben: ƒ Sind beide Konzeptklassen Spezialisierungen einer GBox-Konzeptklasse, so muss es sich in beiden Fällen um die gleiche GBox-Konzeptklasse handeln. Bspw. kann eine Konzeptklasse, die eine Spezialisierung der Konzeptklasse Tag IDI repräsentiert, nicht semantisch äquivalent zu einer Konzeptklasse sein, die eine Spezialisierung der Konzeptklasse StraßeIDI darstellt. ƒ Außerdem ist GBox-Übereinstimmung gegeben, wenn beide Konzeptklassen nicht von einer GBox-Konzeptklasse abstammen.

Entsprechend ist semantische Äquivalenz bei allen Konzeptklassenpaaren ausgeschlossen, bei denen nur eine der beiden Konzeptklassen eine Spezialisierung einer GBox-Konzeptklasse repräsentiert. GBox-Übereinstimmung wird durch die Rolle kompGBR ausgedrückt. Der Domänen- und Bildbereich der Rolle besteht aus Bedeutungseinheiten. F‹ kompGBR .BE F‹ kompGBR .BE Axiom 45: Domänen- und Bildbereich der Rolle "kompGB"

5.4.2.2 Maßeinheiten- und Werttypen-Kompatibilität

Besitzen zwei Bedeutungseinheiten jeweils eine Maßeinheit, so können diese Bedeutungseinheiten nur dann kompatibel sein, wenn ihre Maßeinheiten kompatibel sind. Die Kompatibilität zweier Maßeinheiten ME1 und ME2 setzt voraus, dass ein Umrechnungsfaktor E existiert, mit dem sich ME1 durch ME2 ausdrücken lässt und umgekehrt:

188

5 Ontologisches Matching ME1

E ˜ ME2

bzw.

ME2

1

E

ME1 .

Die Umwandlung von Maßeinheiten stellt eine Aufgabe der Geschäftsdatentransformation dar. Geschäftsdatentransformation bedeutet in diesem Fall, die Geschäftsdaten in eine vom Empfänger verarbeitbare Maßeinheit umzurechnen. Die Kompatibilität zwischen den Maßeinheiten zweier Konzeptklassen wird durch die Rolle kompMER ausgedrückt. Der Domänen- und Bildbereich dieser Rolle bleibt auf Bedeutungseinheiten beschränkt, die über eine Maßeinheit verfügen. F‹ kompMER .  hatMaßeinheitR F‹ kompME R .  hatMaßeinheitR Axiom 46: Domänen- und Bildbereich der Rolle "kompME"

Maßeinheiten-Kompatibilität soll in zwei Fällen gelten. ƒ Die Maßeinheiten einer erhaltenen Konzeptklasse Kme und einer lokalen Konzeptklasse Klo sind kompatibel. ƒ Beide Konzeptklassen verfügen über keine Maßeinheiten; somit kann bei diesen Konzeptklassen keine Maßeinheiten-Inkompatibilität auftreten.

Da Konzeptklassen mit Maßeinheiten nur zu solchen Konzeptklassen semantisch äquivalent sein können, die ebenfalls über eine Maßeinheit verfügen, werden alle Konzeptklassenpaare, bei denen nur eine der beiden Konzeptklassen über eine Maßeinheit verfügt, an dieser Stelle ausgefiltert. Auch die Kompatibilität von Werttypen stellt eine notwendige Äquivalenzbedingung dar. Allerdings ist bei dieser Kompatibilitätskategorie die Transformationsrichtung zu beachten. Angenommen, ein IDI-Agent empfängt ein Attribut mit dem Werttyp "Decimal". Lokal definierte Attribute mit Werttypen "Integer" sind inkompatibel, da die Menge der Natürlichen Zahlen lediglich eine Teilmenge der Gleitkommazahlen darstellt. Umgekehrt jedoch wäre Kompatibilität gegeben.

5.4 Reduktion des Suchraums durch Hypothesenfalsifikation

189

Die Werttypenkompatibilität unter Berücksichtigung der Transformationsrichtung lässt sich durch eine Kompatibilitätsmatrix darstellen. Die Zeilen geben den Werttyp der lokalen, die Spalten den Werttyp der erhaltenen Konzeptklassen an. Ein "X" markiert die Kompatibilität einzelner Kombinationen..

Klo

String

Boolean

Time

Date

Decimal Lokale Konzept- String klasse Boolean

Decimal

Integer

Integer

Erhaltene Konzeptklasse Kme

X

X

X

X

X

X

X

X

X

X

X

X

X

Time

X

Date

X

X X

Tabelle 12: Kompatibilitätsmatrix zur Darstellung von Werttypenkompatibilität

Es wurde angenommen, dass der Werttyp "String" als universeller Werttyp alle Zeichen der anderen Werttypen enthalten kann. Werttypenkompatibilität sei durch die Rolle kompWTR bezeichnet. Domänen- und Bildbereich der Rolle kompWTR entsprechen dem Domänenbereich der Rolle werttypR . F‹ kompWTR .  werttypR F‹ kompWT R .  werttypR Axiom 47: Domänen- und Bildbereich der Rolle "kompWT"

Da Werttypen nicht zwingen spezifiziert werden müssen, können aus der Hypothesenmenge nur solche Konzeptklassenpaare ausgeschlossen werden, die beide über einen zueinander inkompatiblen Werttyp verfügen. Werttypenkompatibilität tritt in zwei Fällen auf.

190

5 Ontologisches Matching

ƒ Besitzen beide Konzeptklassen einen Werttyp, so müssen die Werttypen entsprechend Tabelle 12 kompatibel sein. ƒ Werttypenkompatibilität ist außerdem gegeben, wenn nur eine Konzeptklasse oder keine der beiden Konzeptklassen einen Werttyp besitzt.

5.5 Äquivalenzindikatoren 5.5.1 Bezeichnerkoeffizient 5.5.1.1 Vorüberlegungen

Bezeichnerkoeffizienten sind primäre Äquivalenzindikatoren. Sie liefern ein Maß für die Ähnlichkeit der zur Bezeichnung einzelner Konzeptklassen verwendeten Zeichenketten. Dabei nehmen sie eine besondere Stellung ein. So ist der Bezeichnerkoeffizient erstens das einzige Ähnlichkeitsmaß, das in jedem Fall berechnet werden kann, da jede Konzeptklasse über einen Namen verfügen muss. Dies ist von besonderer Bedeutung, da alle sekundären Äquivalenzindikatoren das Ergebnis von mindestens einem primären Äquivalenzindikator als Input benötigen. Zweitens liefern Konzeptnamen auch für einen menschlichen Aufgabenträger intuitiv erkennbare Indizien für eine mögliche semantische Äquivalenz. Der Einsatz eines Bezeichnerkoeffizienten simBEZ setzt voraus, dass die verwendeten Bezeichnungen Worte einer natürlichen Sprache sind. Da Phänomene der Realität oft schon durch ein einzelnes Wort eindeutig bezeichnet werden können, stellt ein hoher Übereinstimmungsgrad der Bezeichner ein starkes Indiz für die Äquivalenz der betrachteten Konzeptklassen dar.277 Würde allerdings bspw. ein Kreditinstitut statt mit "Bank" mit "AL149UFF" bezeichnet, könnten Bezeichnerkoeffizienten keine sinnvollen Ergebnisse liefern. Würde statt "Bank" die Zeichenkette

277

Vgl. Ehrig, Sure 2004, S. 80.

5.5 Äquivalenzindikatoren

191

"Kreditinstitut" verwendet, könnte eine mögliche Äquivalenzbeziehung immerhin noch aus einer Synonymdatenbank abgeleitet werden.278 Formal wird der Bezeichnerkoeffizient für zwei Konzeptklassen Klo und Kme mit simBEZ  Klo,Kme angegeben. simBEZ ist ein Maß für die Ähnlichkeit der Konzeptnamen. Dabei werden ausschließlich Zeichenketten miteinander verglichen. Die Werte des Bezeichnerkoeffizienten liegen in einem Intervall zwischen "0" und "1". Ein Wert simBEZ 1 signalisiert die völlige Übereinstimmung der betrachteten Zeichenketten; ein Wert simBEZ 0 bedeutet, dass die verglichenen Zeichenketten keinerlei Übereinstimmung besitzen. Zur Bestimmung der Ähnlichkeit zweier Zeichenketten stehen zahlreiche Methoden zur Verfügung. In den folgenden Abschnitten werden zunächst die wichtigsten Methoden erläutert. Im Anschluss wird anhand einiger beispielhafter Zeichenketten analysiert, welche der getesteten Verfahren Gleichheit und Ungleichheit von Konzeptklassennamen am zuverlässigsten erkennen. 5.5.1.2 Levensteinmaß

Das Levensteinmaß ( LM ) ist ein Verfahren zur Bestimmung der syntaktischen Ähnlichkeit zweier Zeichenketten. Das Levensteinmaß basiert auf der sog. Levensteindistanz. Die Levensteindistanz gibt an, wie viele Schritte erforderlich sind, um durch das Einfügen, Löschen, Verschieben oder Ersetzen einzelner Zeichen aus einer Zeichenkette t eine andere, gesuchte Zeichenkette s zu formen. Dabei sind die aufgezählten Verfahren (Löschen, Substituieren, Verschieben und Einfügen) so zu wählen, dass die Anzahl an Manipulationsschritten minimal ist.279 Dies sei an den folgenden Beispielen verdeutlicht:

278

279

Synonymie und Homonymie sind Ursachen für Namens-Heterogenität. Vgl. Kapitel 5.7.3.1. Zur Ermittlung der Levensteindistanz vgl. Bilenko et al. 2003, S. 16-17; Levenstein 1966.

192

5 Ontologisches Matching

ƒ Beispiel 1: Es ist genau eine Substitution erforderlich, um aus "WANNE" die Zeichenkette "KANNE" zu erhalten. ƒ Beispiel 2: Eine Verschiebung verwandelt "WNANNE" in die Zeichenkette "WANNEN".

die

Zeichenkette

ƒ Beispiel 3: Drei Löschungen verwandeln die Zeichenkette "RECH.NR." in die Zeichenkette "RECHNR".

Die Levensteindistanz bedarf einer Normalisierung, um eine Aussage über den Übereinstimmungsgrad zweier Zeichenketten treffen zu können. Übereinstimmungsgrade nehmen Werte zwischen "0" und "1" an, wobei "0" keine und "1" völlige Übereinstimmung signalisiert. Die normalisierte Levensteindistanz soll als "Levensteinmaß" bezeichnet werden. Bei der Ermittlung des Levensteinmaßes für zwei Zeichenketten gebe m die Zeichenzahl der kürzeren und n die Zeichenzahl der längeren Zeichenkette an. Wenn die zu vergleichenden Zeichenketten keine gemeinsamen Zeichen besitzen, dann sind genau m Substitutionen sowie ( n  m ) Einfügeoperationen erforderlich. Die maximale Gesamtzahl der Operationsschritte kann nicht größer sein als die Zeichenzahl der längeren Zeichenkette ( n ). Das normalisierte Levensteinmaß lässt sich nach der unten stehenden Formel berechnen. Die Variable d gibt die Anzahl der notwendigen Manipulationsschritte an.280 LM

1

d n

Formel 24: Levensteinmaß

In Beispiel 1 muss ein Zeichen substituiert werden, Beispiel 3 erfordert drei Löschungen. Somit lassen sich für beide Beispiele die folgenden Levensteinmaße ermitteln: ƒ LM1

280

1 5

0, 2 ;

Vgl. Yancey 2004, S. 6.

5.5 Äquivalenzindikatoren ƒ LM 3

193

3 | 0 , 33 . 9

Als eine Schwäche des Levensteinmaßes ist die mangelnde Berücksichtigung übereinstimmender Subsequenzen ("longest common subsequence") zu betrachten. So ergibt das Levensteinmaß für die beiden Zeichenketten "WANNE" und "BADEWANNE" lediglich einen Wert von 0 , 556 , obwohl "WANNE" völlig mit dem hinteren Teil von "BADEWANNE" übereinstimmt. Solche Aspekte spielen besonders bei Wortzusammensetzungen eine Rolle, wie sie auch im EDI-Umfeld häufig anzutreffen sind. Als Beispiele seien die Wortpaare "Summe" und "Rechnungssumme", "Betrag" und "Gesamtbetrag" sowie "Datum" und "Lieferdatum" genannt. Angenommen, die Variable lcs repräsentiert die Zeichenzahl der längsten gemeinsamen Subsequenz. Dann wird das modifizierte Levensteinmaß ( LM ' ) nach der unten stehenden Formel berechnet:281 LM  LM '

lcs m

2

d · lcs § ¨1  ¸  n¹ m © 2

Formel 25: Modifiziertes Levensteinmaß

Das modifizierte Levensteinmaß errechnet für die beiden Zeichenketten "WANNE" und "BADEWANNE" einen Wert von 0,778 . 5.5.1.3 N-Gramatische Ähnlichkeit

Bei der N-Gramatischen Ähnlichkeit wird für jede zu analysierende Zeichenkette eine Menge ihrer N-Grame ( N-Gram ) gebildet. Ein N-Gram stellt ein Teilstück der zu untersuchenden Zeichenkette dar, wobei N die Anzahl der Zeichen angibt, aus denen dieses Teilstück besteht.282 So enthält bspw. die Menge der 3-Grame einer Zeichenkette alle Teilzeichenketten, die aus der betrachteten Zeichenkette gewonnen werden

281 282

Vgl. Yancey 2004, S. 6. Vgl. Cavnar, Trenkle 1994, S. 2.

194

5 Ontologisches Matching

können und drei Zeichen lang sind. Bspw. lässt sich für die Zeichenkette "KANNE" die folgende 2-Gram-Menge bilden: ƒ 2-GramKANNE

^KA, AN,NN,NE` .

Es seien s und t zwei zu vergleichende Zeichenketten. Ferner sei N  s die Menge der N-Grame von s und N  t die Menge der N-Grame von t . Nun kann die N-Gramatische Ähnlichkeit mithilfe des bereits vorgestellten Dicemaßes berechnet werden: simN-GRAM  s,t

2 ˜ # N s ˆ N t # N s  # N t

Formel 26: N-Gramatische Ähnlichkeit

Die Länge der zu vergleichenden N-Grame kann entweder ex ante festgelegt oder von weiteren Faktoren wie der Länge von s und t abhängig gemacht werden. Wird N zu hoch angesetzt, können kleinere Zeichenketten u.U. selbst bei nur geringfügigen Unterschieden nicht als ähnlich identifiziert werden. Wird N zu niedrig angesetzt, wächst bei längeren Zeichenketten die Gefahr, dass diese zwar über gleiche Subsequenzen verfügen, die Subsequenzen jedoch jeweils zu anderen Zeichenketten zusammengesetzt wurden. Daher liegt es nahe, N den Längen von s und t anzupassen. Es sei k die Länge der kürzeren Zeichenreihe. Ferner sei ABR0 eine Funktion, die einen ganzzahlig abgerundeten Wert des Funktionsterms zurückgibt. Es wird die folgende Methode zur Ermittlung der Länge N vorgeschlagen: N

§k · ABR0 ¨  1 ¸ , wobei 2 d N d 5 . ©2 ¹

Für N gilt also die untere Schranke von 2 und eine obere Schranke von 5. Die Berechnung von N sei am Beispiel der Zeichenketten "WANNE" und "KANNE" verdeutlicht:

5.5 Äquivalenzindikatoren N WANNE,KANNE

195 §5 · ABR0 ¨  1 ¸ ©2 ¹

2 wegen 2 d N d 5 .

Nun sei auch die 2-Gram-Menge für die Zeichenkette "WANNE" ermittelt: 2-GramWANNE :

^WA, AN,NN,NE`

Die N-Gramatische Ähnlichkeit der beiden Beispielzeichenketten lässt sich nach der unten stehenden Formel berechnen: sim2-GRAM WANNE,KANNE

2 ˜ #  2-GramKANNE ˆ 2-GramWANNE . #  2-GramKANNE  #  2-GramWANNE

Die Schnittmenge der beiden N-Gram-Mengen besitzt drei Elemente:

^WA, AN,NN,NE` ˆ ^KA, AN,NN,NE` ^AN,NN,NE` Somit ergibt sich ein Ähnlichkeitswert von sim2-GRAM WANNE,KANNE

2˜3 44

0,75 .

5.5.1.4 Jaromaß

Das Jaromaß (JM) misst die Anzahl gleicher Zeichen zweier Zeichenketten unter Berücksichtigung eines bestimmten Suchbereichs. Es sei die Zeichenkette s ein n-Tupel, das die Zeichen der Zeichenkette in ihrer Reihenfolge angibt: s  s1 ,s2 ,! ,sn . Analog beinhaltet das m-Tupel t

 t1 ,t2 ,! ,tm die Zeichen einer anderen Zeichenkette t . Dabei muss

t

die längere Zeichenkette sein, sodass gilt: n d m . Zur Ermittlung des Jaromaßes wird zunächst der Wert für einen Suchbereich benötigt, der sich an der Länge der Zeichenketten orientiert. In der Literatur wird als Suchbereich ( d ) die halbe Länge der kürzeren Zeichenkette vorgeschlagen:283

283

Vgl. Cohen et al. 2003, S. 2; Yancey 2004, S. 3; Bilenko et al. 2003, S. 17.

196

5 Ontologisches Matching d

n . 2

Zur Kalkulation des Jaromaßes seien zusätzlich die folgenden Variablen definiert: ƒ Es sei c definiert als die Anzahl der übereinstimmenden Zeichen innerhalb des Suchbereichs. Jedes Zeichen darf nur einmal gewählt werden. ƒ Ferner sei mit q die Anzahl der erforderlichen Transpositionen bezeichnet.

Transpositionen sind Zeichen, die zwar in beiden Ketten vorkommen, jedoch in unterschiedlicher Reihenfolge. Die Ermittlung des Jaromaßes muss transpositionsoptimal erfolgen, d.h. bei gleich bleibender Zahl übereinstimmender Buchstabenpaare muss eine Variante gewählt werden, die die Anzahl an Transpositionen minimiert. Das Jaromaß ( JM ) kann anhand der folgenden Formel berechnet werden:284 JM

1§ c c c q· ¨   ¸ c ¹ 3©m n

Formel 27: Jaromaß

Bei identischen Zeichenketten ist m ein Wert JM 1 .

n

c sowie t

0 . Damit ergibt sich

Die folgende Abbildung verdeutlicht die Berechnung des Jaromaßes an zwei Beispielen. Zur Orientierung enthalten die Tabellen Positionsnummern. Auf der vertikalen Achse befinden sich die y-, auf der horizontalen Achse die x-Koordinaten.

284

Vgl. Yancey 2004, S. 4; Bilenko et al. 2003, S. 17.

5.5 Äquivalenzindikatoren

197

Beispiel 1

Beispiel 2

1 2 3 4 5 6 W A N N E N 1 2 3 4 5 6

R Ä N D E R

1 2 3 4 5 6

X X X

1 2 3 4 5 6 W A N N E N W X N X A X N X N X E X

Abbildung 20: Zwei Beispiele für die Berechnung des Jaromaßes

In Beispiel 1 werden die beiden Zeichenketten t WANNEN und s RÄNDER miteinander verglichen. Beide Strings sind jeweils sechs Zeichen lang, sodass sich ein Suchraum von d

6 2

3

ergibt. Der Suchraum wird in der Matrix grau schattiert dargestellt. Es werden nun beide Zeichenketten jeweils über den Suchraum von drei Stellen miteinander verglichen und die in diesem Suchraum gefundenen übereinstimmenden Zeichenpaare gezählt. Anschließend wird der Suchbereich beider Zeichenketten um jeweils eine Stelle nach rechts und nach unten verschoben. So werden in Bsp. 1 zunächst die Positionen 1 bis 3 der beiden Zeichenketten miteinander verglichen, das sind die beiden Substrings "WAN" und "RÄN"; hier stimmt das Zeichen "N" überein. Anschließend rückt der Suchbereich eine Stelle weiter, sodass die Positionen 2 bis 4 ("ANN" und "ÄND") miteinander verglichen werden. Hier stimmt zwar auch der Buchstabe "N" überein. Allerdings wurde dieses Zeichen bereits zugeordnet und darf somit nicht erneut gezählt werden. Daher gelten für Beispiel 1 die Werte c 2 und q 0 . Im Gegensatz zum ersten treten im zweiten Beispiel Transpositionen auf: hier sind die Positionen  x 3; y 2 und  x 2; y 3 sowie  x 6 ; y 5 und  x

5; y

6 transponiert. Somit sind hier die Werte c

festzustellen. Es seien nun die Jaromaße für beide Beispiele kalkuliert:

6 und q

2

198

5 Ontologisches Matching JM1

1§ 2 2 2 0 · ¨   ¸ 3©6 6 6 ¹

0, 33

JM2

1§6 6 6 2· ¨   ¸ 3©6 6 6 ¹

0 , 89

.

Das Jaromaß weist somit für die Zeichenketten aus Beispiel 2 einen hohen Übereinstimmungsgrad auf, während die Zeichenketten aus Beispiel 1 einen niedrigen Übereinstimmungsgrad besitzen. 5.5.1.5 Cosinusmaß

Das Cosinusmaß gehört zu den aus dem Fachgebiet "Information Retrieval" bekannten vektorbasierten Ähnlichkeitsmaßen.285 Hierbei werden die zu vergleichenden Zeichenketten als Binärvektoren dargestellt. Jedes Zeichen der betrachteten Zeichenketten repräsentiert eine eigene Vektordimension. Jede Vektordimension kennt zwei Zustände: "Zeichen vorhanden" oder "Zeichen nicht vorhanden". Die Ähnlichkeit der beiden Zeichenketten ergibt sich aus dem Winkel zwischen den beiden Binärvektoren.286 Auch die Berechnung des Cosinusmaßes sei an einem Beispiel demonstriert. Es seien s und t zwei zu vergleichende Zeichenketten. Es sei M die Vereinigungsmenge aller in s und t verwendeten Zeichen, Mt die Menge aller in t verwendeten Zeichen und Ms die Menge aller in s verwendeten Zeichen. Mehrfach innerhalb eines Dokuments vorkommende Zeichen werden als eigene Zeichen gewertet. Die Variable mit bezeichnet die i-te Merkmalsausprägung der Zeichenkette t , mis analog die i-te Merkmalsausprägung von s . Es seien v t und vs String-Vektoren mit dem folgenden Aufbau: ƒ vt

 m1t ,m2t ,! ,mit ;

ƒ vs

 m1s ,m2 s ,! ,mis .

285

286

Für eine Einführung in das Vektorraummodell vgl. Baeza-Yates, Ribeiro-Neto 1999, S. 27-30. Vgl. Ferber 2003, S. 61-65; Priebe et al. 2005, S. 1317.

5.5 Äquivalenzindikatoren

199

Die folgende Tabelle zeigt die Erstellung der String-Vektoren an den Beispielen t = KANNE sowie s = WANNE. Die jeweiligen String-Vektoren verfügen über das Merkmal "0", wenn das Zeichen der Mittelspalte in der Zeichenkette nicht vorhanden ist. Ist das Zeichen vorhanden, besitzt der String-Vektor an der entsprechenden Position den Wert "1".

i

t= KANNE mi,t

M

Mt W

s= WANNE Ms

mi,s

W

1

1

0

2

1

K

K

3

1

A

A

A

1

4

1

N

N

N

1

5

1

N

N

N

1

6

1

E

E

E

1

0

Tabelle 13: Erstellung von String-Vektoren

Somit ergeben sich aus diesen beiden Beispielen die String-Vektoren v t  0, 1,1,1, 1,1 und v s  1, 0 , 1, 1, 1, 1 . Das Cosinusmaß berechnet den Winkel zwischen diesen beiden Vektoren. Mit wachsenden Unterschieden zwischen den zu vergleichenden Zeichenketten wächst auch der Winkel zwischen den String-Vektoren, der Cosinus als Maß für die Ähnlichkeit zwischen beiden Zeichenketten wird kleiner.287 Ist D der zwischen beiden Vektoren eingespannte Winkel, dann lässt sich das Cosinusmaß nach der unten stehenden Formel berechnen.288

287 288

Vgl. Mohammad, Hirst 2005, S. 7. Vgl. König et al. 1999, S. 345.

200

5 Ontologisches Matching cos D

JJG JJG JJG JJG vt u vs

vt u vs

m1s m1t  m2s m2t  !  mis mit m12s

 m22s  !  mis2 m12t  m22t  !  mit2

Formel 28: Cosinusmaß

Die maximale Winkeldistanz zweier Binärvektoren beträgt 90°. In diesem Fall existiert keinerlei Korrelation zwischen den betrachteten Vektoren, der Cosinus besitzt den Wert "0". Da die Binärvektoren die Mengeneigenschaften der zugrunde liegenden Zeichenketten repräsentieren, kann das Cosinusmaß ( CM ) auch als Ergebnis einer Mengenoperation dargestellt werden. CM

#  M t ˆ Ms

#  Mt u Ms

Formel 29: Cosinusmaß in Mengendarstellung

Für die beiden oben dargestellten Beispielvektoren ergibt sich ein Cosinusmaß von 0,8: CM

4 5˜5

0, 8 .

5.5.1.6 Bewertung der vorgestellten Koeffizienten

An den in der IDI-Architektur zu nutzenden Bezeichnerkoeffizienten besteht eine Anforderung: er soll sehr ähnliche und sehr unterschiedliche Zeichenketten möglichst eindeutig erkennen können. Um die Leistungsfähigkeit der vorgestellten Ähnlichkeitsmaße besser einschätzen zu können, wurden einige Zeichenkettenpaare mit einer hohen und einige Zeichenkettenpaare mit einer niedrigen Ähnlichkeit vorgegeben. Dabei wurden Zeichenketten ausgewählt, die als typische Bezeichner für Konzeptklassen im EDI-Umfeld gelten können. Die hier präsentierte Evaluierung verfolgt nicht das Ziel, statistisch abgesicherte Erkenntnisse über die Güte einzelner Koeffizienten zu erhalten. Vielmehr soll die grundsätzliche Eignung der Koeffizienten anhand weniger Beispiele überprüft werden. Für den Einsatz in der IDI-Architektur soll derjenige Koeffizient mit der geringsten Abweichung vom Erwartungswert ausgewählt werden. Der

5.5 Äquivalenzindikatoren

201

Erwartungswert beträgt "0", wenn die Zeichenketten als nicht übereinstimmend, und "1", wenn diese als übereinstimmend klassifiziert werden sollen. Als Maß für die Abweichung vom Erwartungswert soll die mittlere quadratische Abweichung berechnet werden. Es sei Ei der Erwartungswert des i-ten Zeichenkettenpaars und simi der ermittelte Übereinstimmungsgrad für das i-te Zeichenkettenpaar. Ferner sei n die Anzahl aller zu berücksichtigenden Zeichenkettenpaare. Dann lässt sich die mittlere quadratische Abweichung ( MQA ) nach der folgenden Formel berechnen.289 n

¦  simi  Ei MQA

2

i 1

n

Formel 30: Mittlere quadratische Abweichung

Die folgende Tabelle zeigt die Werte der Ähnlichkeitsmaße für die acht ausgewählten Zeichenkettenpaare sowie die zu den einzelnen Zeichenkettenpaaren gehörenden Erwartungswerte. Die letzte Zeile beinhaltet die mittlere quadratische Abweichung für jede Berechnungsmethode.

289

Zur Berechnung der mittleren quatratischen Abweichung vgl. Bamberg, Baur 2002, S. 21.

202

5 Ontologisches Matching

Nr.

Jaro

COS

1. straße

String 1

adresse

String 2

0,286

0,226

0,000

0,540

0,617

0

2. bestell-nr.

lieferdatum

0,091

0,091

0,000

0,455

0,455

0

3. rechnung

anfechtung

0,600

0,488

0,286

0,811

0,783

0

4. container

transportbehälter

0,176

0,199

0,000

0,483

0,485

0

5. rechnr

rechnungs-nummer

0,375

0,604

0,400

0,715

0,612

1

6. trafo

transformator

0,385

0,492

0,375

0,795

0,620

1

7. straße

strase

0,833

0,750

0,600

0,889

0,833

1

8. lieferant

leiferant

0,778

0,722

0,571

0,963

1,000

1

0,166

0,111

0,147

0,191

0,220

Mittlere quatratische Abweichung

LM

LM'

nGram

E

Tabelle 14: Ähnlichkeitsmaße zur Berechnung des Übereinstimmungsgrades zweier Zeichenketten

Das Levensteinmaß LM ' ist der einzige Koeffizient, der durchweg brauchbare Schätzungen liefert. Das modifizierte Levensteinmaß LM ' profitiert gegenüber dem Standard-Levensteinmaß von seinem Korrekturfaktor, der übereinstimmende Teilzeichenketten in die Kalkulation einbezieht. Der N-Gram-Koeffizient neigt zu pessimistischen Schätzungen. Jaround Cosinusmaß wiederum schätzen nicht übereinstimmende Zeichenketten deutlich zu optimistisch ein. Aufgrund des oben dargestellten Ergebnisses wird das modifizierte Levensteinmaß zur Berechnung der Bezeichner-Ähnlichkeit in der IDIArchitektur ausgewählt. Der Bezeichnerkoeffizient für die IDI-Architektur wird somit nach der folgenden Formel berechnet: LM  simBEZ

lcs n

2

Formel 31: Bezeichnerkoeffizient

5.5.2 Attributkoeffizient Der Attributkoeffizient trifft Aussagen über die Ähnlichkeit der Attributmengen der betrachteten Konzeptklassen. Attribute sind Konzeptklassen, die einer anderen Konzeptklasse über die Rolle attribut A zugeordnet sind.

5.5 Äquivalenzindikatoren

203

Wie bereits angemerkt ist der Attributkoeffizient einer der drei Äquivalenzindikatoren, die mithilfe des Dicekoeffizienten berechnet werden. Es seien nun mit ATT  Klo und ATT  Kme die Attributmengen der beiden Konzeptklassen Klo und Kme definiert. Weiterhin ist, um den Attributkoeffizienten berechnen zu können, noch die Schnittmenge des Dicemaßzählers festzulegen. ­ ½ C1  ATT  Klo š C2  ATT  Kme š ° ° ° ° ATTˆ  Klo,Kme : ®C1 ,C2 ªC1 , 1C2 : C1 { C2 º š ¾ ¬ ¼ ° ° ªC2 , 1C1 : C1 { C2 º ° ° ¬ ¼ ¯ ¿ Definition 4: Schnittmenge für den Zähler des Attributkoeffizienten

Der Attributkoeffizient simATT lässt sich nun mithilfe des in Formel 21 dargestellten Dicemaßes berechnen. simATT  Klo,Kme

2 ˜ # ª¬ ATTˆ  Klo,Kme º¼

# ª¬ ATT  Klo º¼  # ª¬ ATT  Kme º¼

Formel 32: Attributkoeffizient

Die Berechnung des Attributkoeffizienten setzt voraus, dass zumindest für die Konzeptklassenpaare der Attributmengen bereits eine primäre Äquivalenzaussage berechnet wurde und somit semantisch äquivalente Konzeptklassenpaare identifiziert werden konnten. Der Attributkoeffizient zählt daher zu den sog. sekundären Ähnlichkeitsmaßen.

5.5.3 Taxonomiekoeffizient Der Taxonomiekoeffizient berechnet den Übereinstimmungsgrad des taxonomischen Kontextes zweier Konzeptklassen. Der taxonomische Kontext besteht aus der Summe aller Konzeptklassen, die in vertikaler Linie über die Rollen hyperVonR und hyperVonR mit der betrachteten Konzeptklasse verbunden sind. Vertikale Verwandte sind bspw. Eltern und Großeltern bzw. Kinder und Enkel, nicht jedoch Geschwister. Vor der Ermittlung des Taxonomiekoeffizienten ist zu klären, welche Tiefe des taxonomischen Kontextes in die Berechnung einbezogen werden

204

5 Ontologisches Matching

soll.290 Die taxonomische Tiefe gibt die Anzahl zu berücksichtigender Sub- und Superklassenstufen an. Mit zunehmender taxonomischer Distanz ist zu postulieren, dass immer weniger von dem taxonomischen Kontext auf die Bedeutung der betrachteten Konzeptklasse geschlossen werden kann. Da Taxonomien lokal erstellt werden und ggf. unterschiedliche Zwecke erfüllen sollen, ist die Wahrscheinlichkeit groß, dass mit wachsender taxonomischer Entfernung zweier Konzeptklassen unterschiedliche Blickwinkel oder sonstige Erfordernisse zu unterschiedlichen taxonomischen Strukturen führen. Somit kann bei großen taxonomischen Entfernungen aus einem nur schwach übereinstimmenden taxonomischen Kontext nicht auf mangelnde semantische Äquivalenz geschlossen werden. Es wird daher vorgeschlagen, den zu berücksichtigenden Verwandtschaftsgrad bei der Berechnung des Taxonomiekoeffizienten auf einen Wert von :max 2 zu begrenzen. Es werden somit nur Vorfahren und Nachkommen bis zum zweiten Verwandtschaftsgrad berücksichtigt. Es wird weiterhin vorgeschlagen, innerhalb des taxonomischen Kontextes die Menge der Hyponyme und Hyperonyme gleichzugewichten. Diese Gleichgewichtung erscheint sinnvoll, da insb. in Klassifizierungssystemen die Menge der Hyponyme in der Regel über eine wesentlich geringere Anzahl an Elementen verfügt als die Menge der Hyperonyme. So besteht bspw. die Menge der Homonyme einer Konzeptklasse "Singvögel" lediglich aus der Konzeptklasse "Vögel". Gleichzeitig verfügt die Gattung der Singvögel über zahlreiche Hyperonyme. Somit hätten Heterogenitätskonflikte im hyponymen Kontext einer Konzeptklasse wesentlich größere Auswirkungen als im hyperonymen Kontext. Um diese Verzerrung zu vermeiden, müssen beide Kontexte gleichgewichtet werden. Auch der Taxonomiekoeffizient lässt sich mithilfe des Dicemaßes berechnen. Es sei Hypo  Klo die Menge der Hyponyme einer Empfängerkonzeptklasse Klo , wobei nur Verwandte bis zum zweiten Grad berücksichtigt werden. Analog hierzu umfasst Hyper  Klo die Hyperonyme bis

290

Vgl. Rodriguez, Egenhofer 2003, S. 450.

5.5 Äquivalenzindikatoren

205

zum zweiten Grad. Schließlich lassen sich die entsprechenden Mengen Hypo  Kme und Hyper  Kme auch für die Senderkonzeptklasse Kme festlegen. Die Mengen der Hyponyme und Hyperonyme seien nun beispielhaft für die Konzeptklasse Klo definiert. Hypo  Klo : Hyper  Klo :

^C | C ‹ hyperVon

 R .Klo

š ¬ª: Klo,C d 2¼º`

^C | C ‹ hyperVonR .Klo š ¬ª: Klo,C d 2 ¼º`

Definition 5: Der hyperonyme und hyponyme Kontext einer Konzeptklasse

Der Taxonomiekoeffizient setzt sich aus dem Hyponymie- und Hyperonymiekoeffizienten zusammen. Beide Koeffizienten seien nun definiert. simHyper  Klo,Kme simHypo  Klo,Kme

2 ˜ # ª¬Hyperˆ  Klo,Kme º¼

# ª¬Hyper  Klo º¼  # ª¬Hyper  Kme º¼ 2 ˜ # ª¬Hypoˆ  Klo,Kme º¼

# ª¬Hypo  Klo º¼  # ª¬Hypo  Kme º¼

Formel 33: Hyponymie- und Hyperonymiekoeffizient

Zwei Hyponyme oder Hyperonyme im taxonomischen Kontext zweier Konzeptklassen sind dann Bestandteil der unten definierten Schnittmengen, wenn sie semantisch äquivalent sind. Dabei stützt sich die Feststellung der semantischen Äquivalenz an dieser Stelle ausschließlich auf die Äquivalenzaussagen der primären Äquivalenzindikatoren. ­ ½ C1  Hyper  Klo š C2  Hyper  Kme š ° ° ° ° Hyperˆ  Klo,Kme : ®C1 ,C2 ªC1 , 1C2 : C1 { C2 º š ¾ ¬ ¼ ° ° ªC2 , 1C1 : C1 { C2 º ° ° ¬ ¼ ¯ ¿ ­ ½ C1  Hypo  Klo š C2  Hypo  Kme š ° ° ° ° Hypoˆ  Klo,Kme : ®C1 ,C2 ªC1 , 1C2 : C1 { C2 º š ¾ ¬ ¼ ° ° ªC2 , 1C1 : C1 { C2 º ° ° ¬ ¼ ¯ ¿ Definition 6: Schnittmengen zweier Hyponymen- oder Hyperonymen-Mengen

206

5 Ontologisches Matching

Der Taxonomiekoeffizient wird als Mittelwert der beiden oben definierten Koeffizienten berechnet. simTAX  Klo,Kme

simHyper  Klo,Kme  simHypo  Klo,Kme

2

Formel 34: Taxonomiekoeffizient

Es sei abschließend darauf hingewiesen, dass auch der Taxonomiekoeffizient ein sekundäres Ähnlichkeitsmaß darstellt. Er kann also nur dann berechnet werden, wenn für die Hyponyme und Hyperonyme im taxonomischen Kontext der betrachteten Konzeptklassen wenigstens ein primärer Äquivalenzindikator vorliegt.

5.5.4 Graphenbasierter Äquivalenzindikator Der graphenbasierte Äquivalenzindikator simGRA misst den Übereinstimmungsgrad des Beziehungskontextes, in den die betrachteten Konzeptklassen eingebunden sind. Die Bedeutung der Konzeptklassen spielt bei diesem Ähnlichkeitsmaß keine Rolle. simGRA ist daher ein primärer Äquivalenzindikator; er lässt sich ohne Rückgriff auf andere Indikatoren ermitteln. Der Koeffizient simGRA basiert auf der Methode "Similarity Flooding" (SF), die von Melnik et al.291 entwickelt wurde. Es seien die Konzeptklassen Knoten und es seien Beziehungen gerichtete Kanten zwischen den Knoten. Knoten und Kanten werden zu einem gerichteten Graphen zusammengefügt. Graphenbasierte Verfahren zur Berechnung der Konzeptähnlichkeit beruhen auf der Annahme, dass sich die Bedeutung eines Knotens durch seine Position in einem solchen Graphen bestimmen lässt. Folglich setzt eine große Ähnlichkeit zweier Konzeptklassen einen hohen Übereinstimmungsgrad ihres Beziehungskontextes voraus. Dabei bleibt die Bedeutung anderer Knoten in diesem Kontext unberücksichtigt. Der hier vorgestellte Algorithmus verwendet als Input zwei Graphen unterschiedlicher Ontologien. Jeder Beziehungstyp wird durch einen Kan-

291

Vgl. Melnik et al. 2002.

5.5 Äquivalenzindikatoren

207

tentyp repräsentiert. Jeder Kantentyp ist eindeutig durch einen Bezeichner E x gekennzeichnet. In IDI-Ontologien kommen drei Beziehungstypen zum Einsatz: ƒ E1 (mereologische Beziehungen), ƒ E 2 (Taxonomiebeziehungen), ƒ E 3 (Attributbeziehungen).

Die Funktionsweise des Algorithmus sei anhand der beiden folgenden Beispielgraphen erläutert: 292 Klo1

E1

Klo2

Kme1

E1

E2

Klo3

E1 Kme2

E2

E2

Kme3

Abbildung 21: Beispielgraphen für "Similarity Flooding" (Quelle: in Anlehnung an Melnik et al. 2002, S. 120)

Aus den beiden oben dargestellten Inputgraphen wird zunächst ein sog. Konnektivitätsgraph erstellt. Die Knoten dieses Graphen bestehen aus je einer Konzeptklasse der beiden Konzeptmengen KLO und KME . Dabei werden diejenigen Konzeptklassen zu Paaren zusammengeführt, die entweder Quelle oder Ziel semantisch äquivalenter Kanten sind. Abbildung 22 enthält im linken Teil den Konnektivitätsgraphen, der aus den beiden in Abbildung 21 dargestellten Beispielgraphen abgeleitet wurde. Hier sind bspw. die beiden Konzepte Klo1 und Kme1 in ihren jeweiligen Ontologien Quelle des Beziehungstyps E1 und werden somit zu einem Konnektivitätsknoten zusammengefügt. E1 zielt in KLO auf zwei Konzeptklassen: Klo2 und Klo3 . In KME hingegen ist lediglich die Konzeptklasse Kme2 Ziel der Kante E1 . Somit kommt sowohl für Klo2 wie auch für Klo3 die Konzeptklasse Kme2 als potenziell übereinstimmender

292

Vgl. Melnik et al. 2002, S. 120.

208

5 Ontologisches Matching

Kandidat infrage. Es werden zwei entsprechende Konnektivitätsknoten gebildet. Auf die gleiche Weise lassen sich auch alle Quell- und Zielknotenpaare für den Kantentyp E 2 ermitteln.

E1 Klo2 Kme2

Klo1 Kme1

Klo2 Kme1

E1 Klo3 Kme2

E2

0,5

Klo3 Kme3

Klo2 Kme2

Klo1 Kme1 1,0

0,5

1,0

1,0 Klo3 Kme2 1,0

E2

1,0

Klo3 Kme3

1,0

Klo2 Kme3

Klo2 Kme3 Konnektivitätsgraph

Klo2 Kme1

Propagationsgraph

Abbildung 22: Konnektivitäts- und Propagationsgraph

Schließlich wird der Konnektivitätsgraph in einem weiteren Schritt in einen Propagationsgraphen überführt. Dabei wird jede Kante um eine entgegengesetzt gerichtete Kante ergänzt. Alle Kanten werden anschließend gewichtet, sodass die Summe aller von einem Konzeptknoten abgehenden Kanten den Wert "1" ergibt. Ist ein Knoten Quelle mehrerer Kanten, so erhält jede Kante das gleiche Gewicht. Das oben dargestellte Beispiel enthält nur einen Propagationsknoten, aus dem mehr als eine Kante entspringt: ( Klo1 , Kme1 ). Da zwei Kanten von diesem Knoten abgehen, sind beide Kanten jeweils mit 0,5 gewichtet. Alle anderen Knoten sind Quelle lediglich einer Kante, die somit jeweils mit dem Wert 1 gewichtet wird. Die Gesamtheit aller an einen Propagationsknoten grenzenden Kantengewichtungen ist ein Gradmesser für die Ähnlichkeit der semantischen Netze, in die die Konzeptklassen einzelner Propagationsknoten eingebettet sind. In der IDI-Architektur wird für jedes zu matchende Konzeptklassenpaar jeweils ein Konnektivitäts- und ein Propagationsgraph erstellt, denn jede Konzeptklasse besitzt einen individuellen Beziehungskontext.

5.5 Äquivalenzindikatoren

209

Melnik et al. schlagen zur Ermittlung der Konzeptähnlichkeit einen iterativen Prozess vor. Dabei werden Initialwerte für jeden Propagationsknoten benötigt; diese können jedoch frei gewählt werden. Es sei nun die Berechnung des graphenbasierten Äquivalenzindikators demonstriert. Es sei V n  Kloi ,Kme j ein Maß für die Ähnlichkeit der Knoten Kloi und Kme j nach dem n-ten Iterationsschritt. Es gebe P die Anzahl der auf einen Knoten zielenden Kanten und Y m  Klo x ,Kmey die

Gewichtung der m-ten, von  Klo x ,Kmey auf  Kloi ,Kme j zielenden Kan-

n 1 te an. Schließlich sei V m  Klox ,Kmey ein Wert für die nach dem (n-1)-

ten Iterationsschritt ermittelte Konzeptähnlichkeit des Konzeptpaars  Klox ,Kmey , das über die m-te Kante auf  Kloi ,Kme j zeigt. Dann lässt sich V n  Kloi ,Kme j nach der folgenden Formel berechnen:293 V n  Kloi ,Kme j V n 1  Kloi ,Kme j 

P

¦ Zm Klox ,Kmey ˜ V mn 1  Klox ,Kmey

m 1

Formel 35: Graphenbasierte Konzeptähnlichkeit: Berechnung des n-ten Iterationsschritts

Die Berechnung sei an den folgenden Beispielen erläutert. Zur Ermittlung der Beispielwerte wurde ein Initialwert von 1 für alle Propagationspaare gewählt. V 1  Klo1 ,Kme1 V 0  Klo1 ,Kme1  1 ˜ V 0  Klo2 ,Kme2  1 ˜ V 0  Klo3 ,Kme2 1  1˜1  1˜1

V

1

3

 Klo2 ,Kme2 V  Klo2 ,Kme2  0, 5 ˜  Klo1 ,Kme1 0

1  0 , 5 ˜ 1 1, 5

Nach jedem Iterationsschritt werden die Ergebnisse normiert. Dabei erfolgt eine Division der Einzelwerte durch den höchsten Ähnlichkeitswert; im obigen Beispiel ist dies der Wert "3". Die normierten Werte für das obige Beispiel lauten also:

293

Vgl. Melnik et al. 2002, S. 120-121.

210

5 Ontologisches Matching V 1  Klo1 ,Kme1 3 / 3 1 V 1  Klo2 ,Kme2 1, 5 / 3 0, 5

Die folgende Tabelle listet zur Veranschaulichung die Ähnlichkeitswerte der Konzeptpaare für 30 Iterationsschritte auf. Klo1/ n Kme1

Klo2/ Kme2

Klo3/ Kme2

Klo2/ Kme3

Klo2/ Kme1

Klo3/ Kme3

0

1,00000 1,00000 1,00000 1,00000 1,00000 1,00000

1

1,00000 0,50000 0,83333 0,66667 0,66667 0,66667

2

1,00000 0,42857 0,85714 0,64286 0,57143 0,57143

3

1,00000 0,40625 0,87500 0,65625 0,50000 0,50000

4

1,00000 0,39726 0,89041 0,67123 0,43836 0,43836

5

1,00000 0,39222 0,90120 0,68263 0,38323 0,38323

6

1,00000 0,38903 0,90862 0,69060 0,33420 0,33420

7

1,00000 0,38693 0,91364 0,69602 0,29091 0,29091

8

1,00000 0,38553 0,91702 0,69968 0,25290 0,25290

9

1,00000 0,38459 0,91929 0,70213 0,21967 0,21967

10 1,00000 0,38396 0,92081 0,70378 0,19070 0,19070 11 1,00000 0,38353 0,92182 0,70488 0,16548 0,16548 12 1,00000 0,38325 0,92251 0,70562 0,14356 0,14356 13 1,00000 0,38306 0,92296 0,70611 0,12453 0,12453 14 1,00000 0,38294 0,92327 0,70644 0,10800 0,10800 15 1,00000 0,38285 0,92347 0,70666 0,09366 0,09366 16 1,00000 0,38280 0,92361 0,70681 0,08122 0,08122 17 1,00000 0,38276 0,92370 0,70691 0,07043 0,07043 18 1,00000 0,38273 0,92376 0,70697 0,06107 0,06107 19 1,00000 0,38272 0,92380 0,70702 0,05296 0,05296 20 1,00000 0,38271 0,92382 0,70705 0,04592 0,04592

5.5 Äquivalenzindikatoren Klo1/ n Kme1

Klo2/ Kme2

211 Klo3/ Kme2

Klo2/ Kme3

Klo2/ Kme1

Klo3/ Kme3

21 1,00000 0,38270 0,92384 0,70707 0,03982 0,03982 22 1,00000 0,38269 0,92386 0,70708 0,03453 0,03453 23 1,00000 0,38269 0,92386 0,70709 0,02994 0,02994 24 1,00000 0,38269 0,92387 0,70709 0,02596 0,02596 25 1,00000 0,38269 0,92387 0,70710 0,02251 0,02251 26 1,00000 0,38269 0,92387 0,70710 0,01952 0,01952 27 1,00000 0,38268 0,92388 0,70710 0,01692 0,01692 28 1,00000 0,38268 0,92388 0,70710 0,01467 0,01467 29 1,00000 0,38268 0,92388 0,70711 0,01272 0,01272 30 1,00000 0,38268 0,92388 0,70711 0,01103 0,01103 Tabelle 15: Graphenbasierter Äquivalenzindikator: eine beispielhafte Iterationstabelle

Für die Paare  Klo1 ,Kme1 sowie  Klo3 ,Kme2 ist ein hoher Ähnlichkeits-

grad zu konstatieren. Bei  Klo1 ,Kme1 ist dieses Ergebnis darauf zurückzuführen, dass ausschließlich dieser Knoten Ausgangspunkt einer Beziehung E1 ist. Die Konzeptklassen  Klo3 ,Kme2 sind die einzigen, auf die sowohl E1 wie auch E 2 zielen. Alle anderen Paare weisen deutlich geringere strukturelle Übereinstimmungen auf. Es sei nun abschließend die Formel für den graphenbasierten Äquivalenzindikator dargestellt. simGRA  Klo,Kme V n  Klo,Kme Formel 36: Graphenbasierter Äquivalenzindikator

5.5.5 Mereologiekoeffizient Der Mereologiekoeffizient simMER ist ein Maß für die Ähnlichkeit des mereologischen Kontextes zweier Konzeptklassen. Ebenso wie der Attribut- und der Taxonomiekoeffizient gehört auch dieser Koeffizient zu den

212

5 Ontologisches Matching

sekundären Ähnlichkeitsmaßen und wird mithilfe des Dicekoeffizienten berechnet. Um bei der Berechnung des Taxonomiekoeffizienten die Gleichgewichtung des hyponymen und hyperonymen Kontextes sicherzustellen, wurde die getrennte Berechnung eines hyponymen und eines hyperonymen Koeffizienten vorgeschlagen. Auch bei der Berechnung des Mereologiekoeffizienten ist eine solche Gleichgewichtung notwendig. Es sei nun mit Homo  Klo die Menge der Konzeptklassen im homonymen Kontext von Klo und mit Mero  Klo die Menge der Konzeptklassen im meronymen Kontext von Klo definiert. Homo  Klo : Mero  Klo :

^C | C ‹ hatKompR .Klo `

^C | C ‹ hatKomp

 R .Klo

`

Definition 7: Meronyme und holonyme Kontexte einer Konzeptklasse

Somit lassen sich jetzt nach der bereits bekannten Formel die Meronymie- und Homonymiekoeffizienten bestimmen. simHomo  Klo,Kme

2 ˜ # ª¬Homoˆ  Klo,Kme ¼º # ª¬Homo  Klo º¼  # ª¬Homo  Kme º¼

simMero  Klo,Kme

2 ˜ # ª¬Meroˆ  Klo,Kme º¼ # ª¬Mero  Klo º¼  # ª¬Mero  Kme º¼

Formel 37: Homonymie- und Meronymiekoeffizient

Auch die Ähnlichkeit des mereologischen Kontextes soll sich nach der Anzahl äquivalenter Konzeptklassen bemessen.

5.5 Äquivalenzindikatoren

213

­ ½ C1  Homo  Klo š C2  Homo  Kme š ° ° ° ° Homoˆ  Klo,Kme : ®C1 ,C2 ªC1 , 1C2 : C1 { C2 º š ¾ ¬ ¼ ° ° ªC2 , 1C1 : C1 { C2 º ° ° ¬ ¼ ¯ ¿ ­ ½ C1  Mero  Klo š C2  Mero  Kme š ° ° ° ° Meroˆ  Klo,Kme : ®C1 ,C2 ªC1 , 1C2 : C1 { C2 º š ¾ ¬ ¼ ° ° ªC2 , 1C1 : C1 { C2 º ° ° ¬ ¼ ¯ ¿ Definition 8: Schnittmengen zweier Homonymie- und Meronymie-Mengen

Der Mereologiekoeffizient wird als Mittelwerte der beiden Teilkoeffizienten berechnet. simMER  Klo,Kme

simHomo  Klo,Kme  simMero  Klo,Kme 2

Formel 38: Mereologiekoeffizient

5.5.6 RA-Relevanz Der Äquivalenzindikator simRAW berechnet die Äquivalenzwahrscheinlichkeit einer KLO- und einer KME-Konzeptklasse. Diese Äquivalenzwahrscheinlichkeit hängt von der Präzision ab, mit der ein Regulärer Ausdruck der KLO-Ontologie die Geschäftsdateneinheit einer KMEBedeutungseinheit beschreibt. Je mehr Geschäftsdateneinheiten zum Regulären Ausdruck einer KLO-Konzeptklasse kompatibel sind, umso geringer ist die Wahrscheinlichkeit der jeweiligen Konzeptklassenpaare, semantisch äquivalent zu sein. Die Äquivalenzwahrscheinlichkeit wird bei diesem Koeffizienten mithilfe des bereits beschrieben Bayes'schen Theorems ermittelt. Hierzu seien zunächst die vier benötigten Wahrscheinlichkeitswerte definiert. Es sei kompRA  Klo,Kme eine Bool'sche Funktion, die angibt, ob der Geschäftsdatenstrom der Konzeptklasse Kme zum Regulären Ausdruck von Klo kompatibel ist

 kompRA  Klo,Kme

Wahr

214

5 Ontologisches Matching

oder nicht

 kompRA  Klo,Kme

Falsch .

Der Term kompRA  Klo,Kme wird in dieser Arbeit als Kurzform für den Term kompRA  Klo,Kme Wahr genutzt. ƒ P  Klo { Kme bezeichnet die A-priori-Wahrscheinlichkeit für die

Äquivalenz der beiden Konzeptklassen Klo und Kme . ƒ P ¬ªkompRA  Klo,Kme ¼º bezeichnet die A-priori-Wahrscheinlichkeit da-

für, dass der Geschäftsdatenstrom der Konzeptklasse Kme zum Regulären Ausdruck von Klo kompatibel ist. ƒ P ¬ªkompRA  Klo,Kme |  Klo { Kme ¼º ist die Wahrscheinlichkeit für die

Kompatibilität des Geschäftsdatenstroms von Kme mit dem Regulären Ausdruck von Klo , wenn bekannt ist, dass Klo und Kme semantisch äquivalent sind. ƒ P ª¬ Klo { Kme | kompRA  Klo,Kme º¼ ist die Wahrscheinlichkeit für die Äquivalenz der beiden Konzeptklassen Klo und Kme , wenn bekannt ist, dass der Geschäftsdatenstrom von Kme zum Regulären Ausdruck von Klo kompatibel ist. Dies ist die gesuchte Größe.

Nachdem alle benötigten Wahrscheinlichkeitswerte definiert wurden, kann nun die Formel zur Berechnung von simRAW aufgestellt werden. simRAW  Klo,Kme P ª¬ Klo { Kme | kompRA  Klo,Kme º¼ ª P ¬ªkompRA  Klo,Kme |  Klo { Kme ¼º ˜ P  Klo { Kme º « » P ª¬kompRA  Klo,Kme º¼ ¬« ¼» Formel 39: RA-Relevanz

Die Berechnung der RA-Relevanz sei an einem Beispiel erläutert. Eine empfangene Nachricht verfüge über 100 Konzeptklassen. Ohne weitere Informationen beträgt die A-priori-Wahrscheinlichkeit für die Äquivalenz einer der 100 Konzeptklassen zu einer bestimmten lokalen Konzeptklasse Klo 1:100, d.h. P  Klo { Kme 0, 01 . Wenn die Geschäftsdaten von vier Konzeptklassen zum Regulären Ausdruck von Klo kompatibel sind, dann ist P ª¬kompRA  Klo,Kme º¼ 0 , 04 . Die Wahrscheinlichkeit

5.6 Äquivalenzkoeffizient

215

P ¬ª kompRA  Klo,Kme |  Klo { Kme ¼º beträgt immer 100%, denn die RA-

Kompatibilität ist notwendige Bedingung für semantische Äquivalenz. Somit lässt sich der folgende Wert für die RA-Relevanz ausrechnen: simRAW  Klo,Kme

1 * 0 ,01 0,04

0, 25 .

Der Wert für simRAW sinkt also, je mehr Konzeptklassen aus KME über einen RA-kompatiblen Geschäftsdatenstrom verfügen. Um technisch feststellen zu können, ob ein Geschäftsdatenstrom mit den strukturellen Anforderungen eines Regulären Ausdrucks übereinstimmt, lassen sich bspw. die aus der Informatik bekannten Deterministischen Endlichen Automaten (DEA)294 einsetzen. Automaten sind abstrakte Modelle einer Maschine. Sie sind in der Lage, eine Zeichenkette sequenziell zu prüfen und festzustellen, ob die geprüfte Zeichenkette eine gültige Reguläre Sprache im Sinne des definierten Regulären Ausdrucks darstellt. Es sei an dieser Stelle auf die entsprechende Literatur verwiesen.295

5.6 Äquivalenzkoeffizient 5.6.1 Berechnungsmethode Die beschriebenen Äquivalenzindikatoren lassen sich nicht ohne weitere Bearbeitung zu einem globalen Äquivalenzkoeffizienten aggregieren. Hierfür sind zwei Gründe verantwortlich: ƒ Methodische Divergenz: die einzelnen Indikatoren wurden durch unterschiedliche Berechnungsmethoden gewonnen. So berechnet etwa der Taxonomiekoeffizient einen Übereinstimmungsgrad zweier Mengen, die RA-Relevanz hingegen stellt einen Wahrscheinlichkeitswert dar.

294 295

Für eine vertiefende Betrachtung der Automatentheorie vgl. Hopcroft et al. 2002. Vgl. Hopcroft et al. 2002, S. 93-133; Socher 2003, S. 42-50; Clark, Cormack 1997; Karttunen et al. 1996.

216

5 Ontologisches Matching

ƒ Fehlende Interpretationsfunktion: es lässt sich kein Zusammenhang zwischen der absoluten Höhe eines bestimmten Äquivalenzindikators und der Äquivalenzwahrscheinlichkeit herstellen. Bspw. könnte ein Taxonomiekoeffizient von 0,3 bei einer bestimmten Konzeptklasse bereits eine sichere Äquivalenz vorhersagen, während bei einer anderen Konzeptklasse ein Taxonomiekoeffizient mit diesem Wert für sichere Inäquivalenz stünde.

Eine Interpretationsfunktion, die sowohl die methodische Divergenz überwinden als auch kausale Zusammenhänge zwischen der Höhe einzelner Äquivalenzindikatoren und der Höhe der globalen Äquivalenzwahrscheinlichkeit ableiten kann, lässt sich im IDI-Anwendungskontext auf zwei Arten gewinnen. Entweder wird sie von Experten geschätzt und vorgegeben, oder sie wird aus einer Trainingsmenge induktiv abgeleitet. Da in der IDI-Architektur ein möglichst hoher Automatisierungsgrad angestrebt wird, kommt die erste Variante nicht infrage. Das Forschungsziel besteht somit in der Entwicklung eines Äquivalenzkoeffizienten, der sich induktiv aus einer Trainingsmenge ableiten lässt. Die Grundidee der induktiven Inferenz besteht darin, aus Beispielen für Ein- und Ausgabewerte eine Funktion abzuleiten, die einem Eingabewert einen passenden Ausgabewert zuordnet.296 Als Trainingsmenge werden also Beispiele benötigt, die aus einer Reihe von Eingabewerten und den dazu gehörenden Ausgabewerten bestehen. Es sei mit f der funktionale Zusammenhang zwischen Ein- und Ausgabewerten einer Trainingsmenge bezeichnet. Gesucht ist die Funktion h , die eine möglichst gute Annäherung an f sein soll. Die Funktion h wird auch als Hypothese über f bezeichnet.297 Als Eingabewerte dienen in der IDI-Architektur die einzelnen Äquivalenzindikatoren. Als Ausgabewerte müssen in der Trainingsmenge In-

296 297

Vgl. Russel, Norvig 2004, S. 794. Vgl. Russel, Norvig 2004, S. 796.

5.6 Äquivalenzkoeffizient

217

formationen darüber verfügbar sein, ob die betrachteten Konzeptklassen semantisch äquivalent sind oder nicht. Die folgende Tabelle zeigt eine hypothetische Trainingsmenge für die Konzeptklasse Klo einer lokalen Ontologie. Die Trainingsmenge besteht aus sechs Konzeptklassen  Kme1 ,! ,Kme6 . Für jedes Konzeptklassen-

paar  Klo,Kmey sind die Werte der einzelnen Äquivalenzindikatoren

angegeben, z.B. simTAX  Klo,Kme1 0, 28 . Die letzten beiden Zeilen enthalten die Information darüber, ob das jeweilige Konzeptklassenpaar  Klo,Kmey semantisch äquivalent ist oder nicht. Mithilfe dieser Trainingsmenge soll nun beispielhaft die Berechnung des Äquivalenzkoeffizienten für eine neu hinzugekommene Konzeptklasse Kme7 gezeigt werden. Die letzte Spalte der Tabelle enthält die für Kme7 zugrunde gelegten Äquivalenzindikatoren, die als Input für die Kalkulation des Äquivalenzkoeffizienten benötigt werden. Kme1 Kme2 Kme3 Kme4 Kme5 Kme6 e1 (TAX)

0,28

0,33

0,26

0,23

0,35

Kme7

0,35

0,34

e2 (MER)

0,50

0,58

0,38

0,22

0,67

0,87

0,62

e3 (GRA)

0,73

0,46

0,24

0,90

0,55

0,62

0,73

e4 (ATT)

0,25

0,37

0,30

0,74

0,49

0,49

0,50

e5 (BEZ)

0,88

0,61

0,47

0,33

0,97

0,68

0,70

e6 (RAW)

0,50

1,00

0,75

0,25

1,00

1,00

0,50

KlowKmey

1

1

1

0

0

1

¬(KlowKmey)

0

0

0

1

1

0

?

Tabelle 16: Trainingsmenge zur Kalkulation des Äquivalenzkoeffizienten

Es sei nun zunächst die Berechnung des globalen Äquivalenzkoeffizienten für ein beliebiges Konzeptklassenpaar  Klo,Kme demonstriert. Der globale Äquivalenzkoeffizient wird interpretiert und berechnet als die bedingte Äquivalenzwahrscheinlichkeit ( Klo { Kme ), gegeben die Evidenzereignisse  e1 ,! ,e6 . Jedes Evidenzereignis ist einem Äquivalenzindikator zugeordnet. Eine solche bedingte Wahrscheinlichkeit bei multipler Evidenz lässt sich mithilfe der sog. naiven Bayes-Formel berechnen.

218

5 Ontologisches Matching

Es sei nun der Äquivalenzkoeffizient ECO  Klo,Kme wie folgt angegeben:298 ECO  Klo,Kme ª 6 º P  Klo { Kme | e1 ,! ,e6 D P  Klo { Kme « P  ei | Klo { Kme » «¬ i 1 »¼

–

Formel 40: Äquivalenzkoeffizient

Bei dem Faktor D handelt es sich um eine Normalisierungskonstante, die dafür sorgt, dass die beiden Wahrscheinlichkeitswerte P  Klo { Kme | e1 ,! ,e6 und P  Klo { Kme | e1 ,! ,e6

zusammen den Wert "1" ergeben.299 Somit ist der Faktor D nach der unten stehenden Formel zu berechnen. D

1 ª ª 6 º º «P  Klo { Kme « P  ei | Klo { Kme »  » « ¬« i 1 ¼» » « » 6 ª º» « «P  Klo { Kme « P  ei | Klo { Kme » » «¬ i 1 »¼ »¼ «¬

–

–

Formel 41: Berechnung der Normalisierungskonstante

Die Berechnung des Äquivalenzkoeffizienten sei nun am Beispiel des Konzeptklassenpaars  Klo,Kme7 demonstriert. Der Term P  Klo { Kme7 gibt die A-priori-Wahrscheinlichkeit für die semantische Äquivalenz der Senderkonzeptklasse Kme7 und der Empfängerkonzeptklasse Klo an. Die Trainingsmenge in Tabelle 16 enthält insgesamt sechs TrainingsKonzeptklassen. Davon sind vier Konzeptklassen semantisch äquivalent

298 299

Vgl. Pearl 1988, S. 40; Lewis 1998. Vgl. Pearl 1988, S. 40.

5.6 Äquivalenzkoeffizient

219

zu Klo . Somit ergibt sich für die A-priori-Wahrscheinlichkeit der semantischen Äquivalenz zwischen Kme7 und Klo ein Wert von P  Klo { Kme7

4 6

0 , 67 .

Gesucht sind nun die Werte für die Terme P  ei | Klo { Kme7 mit i

1 bis 6 . P  ei | Klo { Kme7 ist als die Wahrscheinlichkeit für das Auf-

treten des Evidenzereignisses ei zu interpretieren, wenn bekannt ist, dass die Konzeptklassen äquivalent sind. Das Evidenzereignis ei sei definiert als





simi  Klo,Kme7 ! simi Klo,Kmey .

d.h. es werden alle Fälle gezählt, in denen der Ähnlichkeitswert simi  Klo,Kme7 größer ist als einer der in der Trainingsmenge vorhande-

nen Ähnlichkeitswerte simi  Klo,Kmey .

Die letzte Spalte in Tabelle 16 zeigt die Werte der einzelnen Äquivalenzindikatoren für das Konzeptklassenpaar  Klo,Kme7 . Hier ist bspw. ersichtlich, dass der ermittelte Wert des Taxonomiekoeffizienten simTAX  Klo,Kme7

0 , 34

in vier Fällen größer ist als die Werte der in der Trainingsmenge vorhandenen Taxonomiekoeffizienten. Dies ist in der ersten Tabellenzeile zu sehen, die die Trainingswerte für den Taxonomiekoeffizienten beinhaltet. Zusätzlich ist einem Folgeschritt zu prüfen, ob sowohl das Evidenzereignis ei wie auch das bedingte Evidenzereignis  ei | Klo { Kme eingetreten ist. Das bedingte Evidenzereignis  ei | Klo { Kme sei definiert als





ªsimi  Klo,Kme7 ! simi Klo,Kmey º š ªKlo { Kmey º . ¼ ¬ ¼ ¬

Das bedingte Evidenzereignis tritt also immer dann ein, wenn zusätzlich zu dem Evidenzereignis ei auch die betreffenden Konzeptklassenpaare der Trainingsmenge äquivalent sind. Dies ist bei dem Evidenzereignis in drei Fällen zu beobachten.

220

5 Ontologisches Matching

Die folgende Tabelle enthält eine Evidenzmatrix, die für jede Kombination  ei | Kmey angibt, ob das bedingte Evidenzereignis eingetreten ist (Wert = "1") oder nicht (Wert = "0"). Kme1 Kme2 Kme3 Kme4 Kme5 Kme6 P(ei|KlowKmey) e1 (TAX)

1

1

1

0

0

0

0,75

e2 (MER)

1

1

1

0

0

0

0,75

e3 (GRA)

0

1

1

0

0

1

0,75

e4 (ATT)

1

1

1

0

0

1

1,00

e5 (BEZ)

0

1

1

0

0

1

0,75

e6 (RAW)

1

0

0

0

0

0

0,25

KlowKmey

1

1

1

0

0

1

Tabelle 17: Matrix positiver Vorhersagewerte

Die Ermittlung und Interpretation der Werte für die oben dargestellte Evidenzmatrix sei an zwei Beispielen verdeutlicht. Wie in Tabelle 16 dargestellt verfügt das Konzeptklassenpaar  Klo,Kme1 über einen Taxono-

miekoeffizienten mit dem Wert simTAX  Klo,Kme1 0, 28 . Das betrachtete Konzeptklassenpaar wurde als semantisch äquivalent klassifiziert. Es wird nun angenommen, dass alle Konzeptklassenpaare, bestehend aus einer KME-Konzeptklasse und Klo , die mindestens einen Taxonomiekoeffizienten von 0,28 erreichen, ebenfalls semantisch äquivalent sein müssen. Der Wert des Taxonomiekoeffizienten für  Klo,Kme7 beträgt simTAX  Klo,Kme7 =0,34 .

Da dieser Wert größer als 0,28 ist, wird aus der Perspektive des Taxonomiekoeffizienten geschlossen, dass dieses Konzeptklassenpaar ebenfalls semantisch äquivalent sein muss. Die entsprechende Zelle der Evidenzmatrix besitzt daher den Wert "1". Der Wert des Taxonomiekoeffizienten für das Konzeptklassenpaar  Klo,Kme4 lautet simTAX  Klo,Kme4 =0,23 .

Zwar liegt auch dieser Wert unter 0,34. Allerdings wurde das Konzeptklassenpaar  Klo,Kme4 als inäquivalent klassifiziert. Somit kann nicht

5.6 Äquivalenzkoeffizient

221

auf die semantische Äquivalenz des Konzeptklassenpaars  Klo,Kme4 geschlossen werden. Die entsprechende Matrixzelle besitzt also den Wert "0". Die letzte Tabellenspalte der Matrix positiver Vorhersagewerte enthält die bedingten Wahrscheinlichkeitswerte P  ei | Klo { Kmey . Die bedingte Wahrscheinlichkeit P  ei | Klo { Kmey lässt sich berechnen durch



P ei | Klo { Kmey







P ªei š Klo { Kmey º ¬ ¼ .300 P Klo { Kmey





Die Berechnung der bedingten Wahrscheinlichkeit sei wiederum am Beispiel des Evidenzereignisses e1 gezeigt. Der Wert P  Klo { Kme 0,67 wurde bereits oben ermittelt. Der Wert für P ª¬ei š  Klo { Kmey º¼ gibt die Verbundwahrscheinlichkeit dafür an, dass das Evidenzereignis e1 eingetreten ist und gleichzeitig die betrachteten Konzeptklassen semantisch äquivalent sind. Am Beispiel des Evidenzereignisses e1 lässt sich anhand von Tabelle 17 zeigen, dass diese Situation in der Trainingsmenge in drei von sechs Fällen eingetreten ist. Die Verbundwahrscheinlichkeit für das Evidenzereignis e1 lässt sich also berechnen durch





P ªe1 š Klo { Kmey º ¬ ¼

3 6

0, 5 .

Nur bei den ersten drei Trainingskonzeptklassen Kme1 bis Kme3 tritt die Situation auf, dass der Wert für simTAX  Klo,Kme7 größer ist als die jeweiligen Trainingswerte und gleichzeitig die Konzeptklassenpaare der Trainingsmenge semantisch äquivalent sind. Die semantische Äquivalenz lässt sich in der letzten Zeile von Tabelle 17 ablesen.

300

Zur Berechnung einer bedingten Wahrscheinlichkeit vgl. Bamberg, Baur 2002, S. 86.

222

5 Ontologisches Matching

Es lässt sich nun für P  e1 | Klo { Kmey der folgende Wert ermitteln:



P e1 | Klo { Kmey

0, 5 0,67



0,75 .

Um den Faktor D berechnen zu können, müssen auch die Wahrscheinlichkeitswerte







P Klo { Kmey und P ei |Klo { Kmey



bekannt sein. Hierzu wird eine Evidenzmatrix für negative Vorhersagewerte benötigt, deren Werte sich nach dem gleichen Schema bestimmen lassen. Kme1 Kme2 Kme3 Kme4 Kme5 Kme6 P(ei|¬(KlowKmey)) e1 (TAX)

0

0

0

1

0

0

0,50

e2 (MER)

0

0

0

1

0

0

0,50

e3 (GRA)

0

0

0

0

1

0

0,50

e4 (ATT)

0

0

0

0

1

0

0,50

e5 (BEZ)

0

0

0

1

0

0

0,50

e6 (RAW)

0

0

0

1

0

0

0,50

¬(KlowKmey)

0

0

0

1

1

0

Tabelle 18: Matrix negativer Vorhersagewerte

Die Berechnung der in der rechten Spalte dargestellten Werte P  ei | Klo { Kmey verläuft analog zur Berechnung der Werte





P ei | Klo { Kmey .

Es sind nun alle Werte verfügbar, um den bedingten Wahrscheinlichkeitswert P  Klo { Kme7 | e1 ,! ,e6

berechnen zu können. Für P  Klo { Kme7 wurde bereits oben ein Wert von 0,67 ermittelt. Entsprechend beträgt der Wert P  Klo { Kme7 0 , 33 . Die restlichen Faktoren können Tabelle 17 und Tabelle 18 entnommen werden.

5.6 Äquivalenzkoeffizient

223

ª 6 º P  Klo { Kme7 « P  ei | Klo { Kme7 » ¬« i 1 ¼»

–

ª 6 º P  Klo { Kme7 « P  ei | Klo { Kme7 » «¬ i 1 »¼

–

P  Klo { Kme7 | e1 ,! ,e6

§ 0 ,67 ˜ 0 ,75 ˜ 0 ,75 ˜ · ¨ 0 ,75 1 0,75 0 , 25 ¸ ˜ ˜ ˜ © ¹ 0, 33 ˜ 0, 56

0, 0527 0, 0527  0, 0052

0, 0527

0, 0052

0, 91

Somit liegt die Äquivalenzwahrscheinlichkeit für die beiden Konzeptklassen Klo und Kme7 unter Berücksichtigung der Evidenzereignisse bei 91%. Die oben beschriebene, evidenzbasierte Methode zur Berechnung der bedingten Äquivalenzwahrscheinlichkeit weist zwei Vorteile auf: ƒ Die methodische Divergenz und die hieraus resultierende fehlende gemeinsame Interpretationsbasis werden überwunden, da sich sämtliche Äquivalenzindikatoren zu einer Maßzahl zusammenfassen lassen. ƒ Die skizzierte Methode lässt sich als Basis zur sukzessiven Verbesserung der Prognosewerte während der Laufzeit nutzen ("Maschinelles Lernen").

5.6.2 Äquivalenz- und Inäquivalenzfunktion Um eine Äquivalenzaussage treffen zu können, sind Schwellenwerte zur Feststellung der Äquivalenz ( G Equ  ) von Konzeptklassen zu definieren. Solche Schwellenwerte lassen sich bspw. aus Trainingsmengen generieren. Sie können aber auch durch Experten festgelegt werden. Konzeptklassenpaare, deren Äquivalenzkoeffizienten Werte unterhalb von G Equ  angenommen haben, aber nicht durch die Prozesse der Hypothesenfalsifikation oder Heterogenitätsüberwindung als endgültig inäquivalent klassifiziert wurden, werden als heterogen eingestuft. Hier lässt sich eine Äquivalenzaussage u.U. erst nach einigen Iterationsschritten treffen. Liegt der Äquivalenzkoeffizient auch nach einer festgelegten Anzahl von Iterationsschritten noch unterhalb des Schwellenwerts, so ist für die be-

224

5 Ontologisches Matching

trachteten Konzeptklassen keine automatisierte Äquivalenzaussage zu treffen. Es seien nun Equn und Equn als Äquivalenz- und Inäquivalenzfunktion für die Iterationsstufe n definiert. Equn C1 ,C2 Equn C1 ,C2

­ ½ ° ^wahr ` | ª¬C1 ,C2  Hn º¼ š ª¬ECO C1 ,C2 t G Equ  º¼ ° ® ¾ ª º ¯°^falsch` | ¬ªC1 ,C2  Hn ¼º š ¬ECO C1 ,C2  G Equ  ¼ ¿° ­°^wahr ` | C1 ,C2  Hn ½° ® ¾ ¯°^falsch` | C1 ,C2  Hn ¿°

Formel 42: Formale Definition von Äquivalenz und Inäquivalenz

Sowohl Equn wie auch Equn stellen Boole'sche Funktionen dar. Sie repräsentieren die (aktuelle) Überzeugung eines IDI-Agenten zur semantischen Äquivalenz zweier Konzeptklassen. Die folgende Tabelle erläutert die vier möglichen Fälle. Bool'sche Funktion

Überzeugung des IDI-Agenten

Equ  C1 ,C2

wahr

Die Konzeptklassen sind äquivalent.

Equ  C1 ,C2

falsch Die Konzeptklassen sind nicht äquivalent, aber

deshalb nicht zwangsläufig inäquivalent. Equ  C1 ,C2

wahr

Equ  C1 ,C2

falsch Die Konzeptklassen sind nicht inäquivalent, aber

Die Konzeptklassen sind inäquivalent. deshalb nicht zwangsläufig äquivalent.

Tabelle 19: Überzeugungen eines IDI-Agenten hinsichtlich Konzeptklassenäquivalenz oder -inäquivalenz

Der Äquivalenzkoeffizient wird für alle Konzeptklassenpaare einer Input-Hypothesenmenge errechnet. Im Anschluss kann für alle Elemente dieser Hypothesenmenge eine der oben beschriebenen Äquivalenzaussagen getroffen werden. In Abhängigkeit von den Ergebnissen dieser Äquivalenzaussagen werden für einzelne Konzeptklassenpaare die im folgenden Kapitel beschriebenen Verfahren zur Heterogenitätsüberwindung angewendet.

5.7 Heterogenitätsüberwindung

225

5.7 Heterogenitätsüberwindung Da die Entwicklung einzelner LBoxen nach den Prämissen dieser Arbeit dezentral erfolgt, besteht die Gefahr semantischer Heterogenität. Um die Anforderung der Fähigkeit zur Ad-hoc-Kommunikation erfüllen zu können, müssen Verfahren gefunden werden, die eine automatisierte Überwindung von Heterogenität erlauben. Aufgrund der besonderen Bedeutung dieses Themas widmet sich der verbleibende Teil von Kapitel 5 mit der Analyse von Heterogenitätsursachen und Methoden zur Heterogenitätsüberwindung.

5.7.1 Heterogenitätsursachen und -effekte Bei der Analyse von Heterogenität erscheint die Trennung zwischen Heterogenitätsursachen und -effekten sinnvoll. Unter einem Heterogenitätseffekt wird in der IDI-Architektur die Sichtbarwerdung von Heterogenität verstanden. Heterogenitätseffekte ermöglichen die Identifizierung und Messung von Heterogenität. Hiervon zu unterscheiden sind die Heterogenitätsursachen. Sie sind für die Entstehung von Heterogenität und damit auch die Sichtbarwerdung von Heterogenitätseffekten verantwortlich. Die folgende Abbildung präsentiert einen Vorschlag für die Kategorisierung von Heterogenitätsursachen in der IDI-Architektur. Dabei bleibt die Abbildung auf die Darstellung derjenigen Heterogenitätsursachen beschränkt, die in der IDI-Architektur Heterogenitätseffekte auslösen können.301

301

Einen allgemeinen Überblick über mögliche Heterogenitätskonflikte bei der ontologischen Integration geben z.B. Klein 2001, S. 4; Visser et al. 1997; Sheth, Kashyap 1992; Predoiu et al. 2005, S. 9-12; Bornhövd 2001, S. 111-163.

226

5 Ontologisches Matching Heterogenitätsursachen

NamensHeterogenität Synonymie

Mereologische Lücken

VerschmelzungsKonflikte

Strukturkonflikte

Homonymie

Fehlende mereolog. Beziehung.

MereologieHeterogenität

TaxonomieHeterogenität

VT*Konflikte

AttributHeterogenität

Trennungskonflikte Granularitätskonflikte

AttributZuordnungs -Konflikte

Strukturrelevanz

Strukturirrelevanz

Fehlende taxonom. Beziehung.

Taxonomische Lücken

Fehlende AttributBeziehung.

Fehlende Attribute

* Verschmelzungs- und Trennungskonflikte

Abbildung 23: Kategorisierung von Heterogenitätsursachen

Die dargestellte Kategorisierung bildet den Gliederungsrahmen für die Abschnitte 5.7.3.1 bis 5.7.3.8. Heterogenität wird oft durch Unvollständigkeit des in den jeweiligen Ontologien gespeicherten Wissens verursacht. Unvollständigkeit des Wissens bedeutet, dass Phänomene der Realität in einer Ontologie repräsentiert werden, in einer anderen jedoch nicht. Je nach Ausmaß der Unvollständigkeit sinkt oder wächst die Unsicherheit über die Äquivalenz der betrachteten Konzeptklassen. Das Ausmaß an Unsicherheit manifestiert sich also in der ermittelten Äquivalenzwahrscheinlichkeit. Die Überwindung von Heterogenität erfordert eine Reduzierung von Unsicherheit. Zur Systematisierung der Heterogenitätsanalyse seien die Begriffe "Koeffizientenheterogenität" und "Indikatorheterogenität" eingeführt. Koeffizientenheterogenität signalisiert, dass überhaupt ein Heterogenitätsproblem besteht. Koeffizientenheterogenität ist dadurch gekenn-

5.7 Heterogenitätsüberwindung

227

zeichnet, dass die Äquivalenzfunktion Equn für ein bestimmtes Konzeptklassenpaar den Wert ^falsch` zurückgibt. Indikatorheterogenität lässt Rückschlüsse darauf zu, welcher Äquivalenzindikator Heterogenität verursacht hat.

Sowohl Koeffizienten- wie auch Indikatorheterogenität werden als Heterogenitätseffekte betrachtet, da beide Begriffe Zustände beschreiben, durch die Heterogenität sichtbar und messbar wird. Jeder Heterogenitätseffekt lässt sich auf mindestens eine Heterogenitätsursache zurückführen. Die soeben beschriebenen Analyseebenen sind in der folgenden Abbildung in Form einer Heterogenitätspyramide dargestellt.

Koeffizientenheterogenität Indikatorheterogenität

Heterogenitätsursachen

Abbildung 24: Heterogenitätspyramide

Der grundsätzliche Unterschied zwischen Heterogenitätsursachen und -effekten sei an einem Beispiel verdeutlicht. Angenommen, bei zwei Konzeptklassen wird Taxonomieheterogenität festgestellt. Taxonomieheterogenität bedeutet, dass der Taxonomiekoeffizient einen Wert kleiner als G Equ  angenommen hat.

228

5 Ontologisches Matching

Für Taxonomieheterogenität können unterschiedliche Ursachen wie etwa fehlende Konzeptklassen oder fehlende Beziehungsdefinitionen im taxonomischen Kontext einzelner Konzeptklassen verantwortlich sein. Heterogenitätseffekte auf den einzelnen Stufen werden unterschiedlich notiert. ƒ Het  Klo,Kme bezeichnet Koeffizientenheterogenität. ƒ HetKAT  Klo,Kme bezeichnet Indikatorheterogenität.

Die Buchstabenkombination KAT repräsentiert eine der ontologischen Eigenschaftskategorien wie bspw. den taxonomischen Kontext (TAX ) oder den mereologischen Kontext ( MER ). Um Heterogenitätseffekte eindeutig identifizieren zu können, müssen notwendige und hinreichende Bedingungen definiert werden, aus denen auf Koeffizienten- oder Indikatorheterogenität geschlossen werden kann. Ebene

Notwendige und hinreichende Heterogenitätsbedingungen

Koeffizienten- Het  Klo,Kme œ ªEqu   Klo,Kme falsch º ¬ ¼ heterogenität Indikatorheterogenität

ªHet  Klo,Kme š HetKAT  Klo,Kme œ « «¬ simKAT  Klo,Kme  G Equ 





º » »¼

Tabelle 20: Definition von Koeffizienten- und Indikatorheterogenität

Koeffizientenheterogenität tritt dann auf, wenn ein Konzeptklassenpaar weder als eindeutig äquivalent noch als eindeutig inäquivalent klassifiziert werden konnte. Indikatorheterogenität sei als der Zustand definiert, bei dem der Wert des betrachteten Äquivalenzindikators unterhalb des Schwellenwertes für Äquivalenz liegt und für das betrachtete Konzeptklassenpaar Koeffizientenheterogenität festgestellt wurde.

5.7.2 Heterogenitätsketten Die Unterscheidung zwischen Ursachen und Effekten von Heterogenität ist wichtig, weil einzelne Ursachen mehrere Heterogenitätseffekte auslösen und einzelne Heterogenitätseffekte durch unterschiedliche Ursachen

5.7 Heterogenitätsüberwindung

229

hervorgerufen werden können. Nur durch die Analyse dieser UrsacheWirkungsketten lässt sich Heterogenität überwinden. Gegenstand der weiteren Untersuchung sind daher sogenannte Heterogenitätsketten. Unter dem Begriff Heterogenitätskette wird in der vorliegenden Arbeit die Aneinanderreihung einer Heterogenitätsursache und eines durch diese Ursache hervorgerufenen Heterogenitätseffekts verstanden. Zur Kategorisierung derartiger Heterogenitätsketten sei eine Klassifikation nach den folgenden vier Kategorien vorgeschlagen: ƒ Ursache-Wirkungs-eindeutige (UWE), ƒ Wirkungs-eindeutige (WE), ƒ Ursache-eindeutige (UE) und ƒ Ursache-Wirkungs-mehrdeutige (UWM) Heterogenitätsketten.

Erzeugt eine Heterogenitätsursache genau einen Heterogenitätseffekt und wird dieser Heterogenitätseffekt ausschließlich durch diese eine Heterogenitätsursache hervorgerufen, so handelt es sich um eine UWEKette. Hier kann von der Ursache auf den Effekt und umgekehrt geschlossen werden. Der Vorteil von UWE-Ketten besteht darin, dass keine Suche nach der Heterogenitätsursache erforderlich ist. Diese steht mit der Identifizierung des entsprechenden Heterogenitätseffekts fest. Heterogenitätsketten, bei denen zwar die betrachtete Ursache mehrere Heterogenitätseffekte hervorrufen kann, der betrachtete Heterogenitätseffekt jedoch ausschließlich durch die betrachtete Ursache hervorgerufen wird, werden in dieser Arbeit als WE-Ketten bezeichnet. Hier ist nur der Schluss von dem Effekt auf die Ursache zulässig. Auch bei WE-Ketten muss nicht nach der Heterogenitätsursache gesucht werden. Weiterhin sind Heterogenitätsketten zu unterscheiden, bei denen die betrachtete Ursache nur einen Heterogenitätseffekt erzeugt, dieser jedoch durch unterschiedliche Ursachen hervorgerufen werden kann. Diese Heterogenitätsketten werden in der IDI-Architektur UE-Ketten genannt. Sie erlauben nur das Schließen von der Ursache auf den hervorgerufenen Effekt. Somit wird eine genaue Analyse erforderlich, welche Ursache den beobachteten Heterogenitätseffekt hervorgerufen hat.

230

5 Ontologisches Matching

Schließlich ist noch der Fall zu erwähnen, dass eine Ursache mehrere Heterogenitätseffekte erzeugen und der betrachtete Effekt von mehreren Ursachen hervorgerufen werden kann. Derartige Heterogenitätsketten werden als UWM-Ketten bezeichnet. Hier ist weder der Schluss von der Ursache auf die Wirkung noch von der Wirkung auf die Ursache zulässig. Bei der Heterogenitätsüberwindung muss auch hier zunächst die verantwortliche Heterogenitätsursache ermittelt werden. Die oben beschriebenen Kategorien sowie die hiermit verbundenen zulässigen Formen des logischen Schließens zwischen Heterogenitätsursache (U) und Heterogenitätseffekt (E) seien nun in der folgenden Abbildung zusammengefasst.

Heterogenitätseffekt (E) kann hervorgerufen werden von

Heterogenitätsursache (U) verursacht

einer Ursache

einen Effekt

mehrere Effekte

U œE

U E

(UWE-Kette)

(UE-Kette)

mehreren U Ÿ E Ursachen (WE-Kette)

U Ÿ E 1 › ! › E n (UWM-Kette)

Abbildung 25: Formallogische Darstellung des Schließens in Heterogenitätsketten

Äquivalente Konzepte mit völlig disjunkten Eigenschaftsmengen sowie inäquivalente Konzepte mit übereinstimmenden Eigenschaftsmengen können maschinell nicht als heterogen erkannt werden. Beispielhaft für eine Situation völlig disjunkter Eigenschaftsmengen bei gleichzeitiger Konzeptäquivalenz seien sog. Äquipollenzen erwähnt.302 Hierbei werden identische Realweltobjekte aus unterschiedlichen Perspektiven betrachtet, z.B. "Einwohner" vs. "Konsument".

302

Vgl. Lehmann, Ortner 1997, S. 67.

5.7 Heterogenitätsüberwindung

231

Die folgende Tabelle gibt einen antizipativen Überblick über die im verbleibenden Teil des Kapitels analysierten Heterogenitätsketten. Die erste Spalte nennt die Heterogenitätsursache sowie in Klammern den formalen Bezeichner für diese Heterogenitätsursache. Alle formalen Bezeichner für Heterogenitätsursachen beginnen mit dem griechischen Buchstaben Ypsilon (b ). In der zweiten Spalte sind die durch die Heterogenitätsursache erzeugbaren Heterogenitätseffekte dargestellt. Die dritte Spalte stellt den logischen Zusammenhang zwischen Ursache und Effekt dar. Die vierte Spalte gibt Auskunft, ob die dargestellte Heterogenitätskette maschinell überwunden werden kann. Ein Kreuz in der fünften Spalte informiert, ob die dargestellte Heterogenitätskette eine Transformation von Geschäftsdaten erfordern kann. In der sechsten und letzten Spalte ist das Unterkapitel angegeben, in dem die Heterogenitätskette detailliert dargestellt wird. UrsacheEffektZusammenhang

Synonymie (b SYNON )

HetBEZ

U ŸE

X

5.7.3.1

Homonymie (b HOMON )

HetBEZ

U ŸE

X

5.7.3.1

Strukturrelevanz (b SRELE )

HetRAW

U ŸE

Strukturirrelevanz (b SIRRE )

HetRAW

U ŸE

Verschmelzungskonflikt (bVKONF )

HetBEZ

UŸ

Het ATT

 E1 › ! › En

GD-Transform. erforderlich?

Effekt(e)

Maschinell überwindbar?

Ursache

Kapitel

5.7.3.2

X

5.7.3.2

X

5.7.3.3 X

X

HetMER

Trennungskonflikt (b TKONF )

HetBEZ Het ATT HetMER

UŸ

 E1 › ! › En

5.7.3.3 X

X

Ursache

Effekt(e)

UrsacheEffektZusammenhang

Fehlende taxonomische Beziehungen (b FBTAX )

HetTAX

UŸ

HetGRA

 E1 › ! › En

Taxonomische Lücken (b LÜTAX )

HetTAX

UŸ

HetGRA

 E1 › ! › En

Fehlende mereologische Beziehungen (b FBMER )

HetMER HetGRA

UŸ

Mereologische Lücken (b LÜMER )

HetMER HetGRA

UŸ

Fehlende Attributbeziehungen (b FBATT )

Het ATT

UŸ

HetGRA

 E1 › ! › En

Fehlende Attribute (b FKATT )

Het ATT

UŸ

HetGRA

Attributzuordnungskonf- Het ATT likte (b ATTZO ) Granularitätskonflikte (b GKONF )

HetMER HetTAX HetGRA

Tabelle 21: Heterogenitätsketten

 E1 › ! › En

X 5.7.3.4

5.7.3.5 X 5.7.3.5

5.7.3.6 X 5.7.3.6

 E1 › ! › En X

UŸ

 E1 › ! › En

Kapitel

5.7.3.4

 E1 › ! › En

U ŸE

GD-Transform. erforderlich?

5 Ontologisches Matching Maschinell überwindbar?

232

5.7.3.6 5.7.3.8

X

5.7 Heterogenitätsüberwindung

233

5.7.3 Strategien zur Heterogenitätsüberwindung Die Zielsetzung der Heterogenitätsüberwindung besteht in der Ableitung einer neuen Hypothesenmenge Hn . Diese neue Hypothesenmenge enthält alle Konzeptklassenpaare, die nach der Heterogenitätsüberwindung als äquivalent oder heterogen klassifiziert werden. ­ ° Hn : ® Klo,Kme ° ¯

Equn Klo,Kme Equn Klo,Kme



wahr R ½ ° ¾ für  n ! 1 falsch ° ¿

Definition 9: Hypothesenmenge nach der Heterogenitätsüberwindung

Zur besseren Veranschaulichung werden in den folgenden Unterkapiteln einzelne Teilprozesse der Heterogenitätsüberwindung grafisch in einer auf den sog. "Programmablaufplänen" basierenden Notation dargestellt. Die Bedeutung der in dieser Arbeit verwendeten Symbole ist der folgenden Tabelle zu entnehmen.303 Symbol

Bedeutung Startsymbol; benennt den festgestellten Heterogenitätseffekt. Verzweigung; beinhaltet stets einen wahrheitsfunktionalen Term, dessen Wahrheitsgehalt bestimmt, in welchen Teil des Ablaufplans verzweigt wird.

303

Zur allgemeinen Bedeutung der in Programmablaufplänen vorkommenden Symbole vgl. Stahlknecht, Hasenkamp 2002, S. 271-272.

234 Symbol

5 Ontologisches Matching Bedeutung Mehrfachverzweigung; wird genutzt, wenn mehr als zwei Verzweigungsalternativen vorgesehen sind. Es müssen also mindestens drei Mehrfachverzweigungen parallel geschaltet sein. Jede Mehrfachverzweigung beinhaltet einen wahrheitsfunktionalen Ausdruck; sie wird durchlaufen, wenn dieser Ausdruck wahr ist. Aktionen; hier werden Aktionen vollzogen, die der Heterogenitätsüberwindung dienen.

Ende

Terminatoren; jeder Ablauf endet mit einem solchen Symbol.

Tabelle 22: Grafische Darstellung von Prozessen zur Heterogenitätsüberwindung

5.7.3.1 Namensheterogenität

Namensheterogenität kann auf zwei Heterogenitätsursachen zurückgeführt werden: Synonymie, formal durch das Symbol b SYNON bezeichnet, und Homonymie, formal durch das Symbol b HOMON bezeichnet. Sowohl die durch Synonymie wie auch die durch Homonymie hervorgerufenen Heterogenitätsketten sind Wirkungs-, nicht aber Ursache-eindeutig. Somit wird eine formale Definition der notwendigen und hinreichenden Bedingungen für Synonymie und Homonymie erforderlich. Eine solche Definition ermöglicht es einem IDI-Agenten, den Heterogenitätseffekt zu identifizieren und Maßnahmen zur Heterogenitätsüberwindung einzuleiten. Es seien nun die notwendigen und hinreichenden Bedingungen für Synonymie formal spezifiziert.

5.7 Heterogenitätsüberwindung

235

Klo, Kme : ªHetBEZ  Klo,Kme š º « » § Klo ‹ synVonR .Klo1 š · º» «ª ¸¸ › » » « «Klo1 : ¨¨ sim b SYNON  Klo,Kme œ « « BEZ  Klo1 ,Kme t G Equ  ¹ » » © » «« Kme ‹ synVon.Kme1 š · » » « «Kme : §¨ » ¸ 1 ¨ simBEZ  Klo,Kme1 t G Equ  ¸ » » «« © ¹ ¼¼ ¬¬ Bedingung 22: Hinreichende und notwendige Bedingungen für Synonymie

Synonymie wird als ein Zustand gekennzeichnet, in dem die Bezeichner zweier Konzeptklassen den Heterogenitätseffekt HetBEZ  Klo,Kme verursachen und ein weiterer, als synonym gekennzeichneter Konzeptklassenname existiert, bei dem dieser Heterogenitätseffekt nicht auftritt. Die folgende Tabelle beinhaltet eine Kategorisierung von Ursachen für Synonymie aus sprachwissenschaftlicher Sicht.

236

5 Ontologisches Matching

Bezeichnung

Erläuterung

Flexionen

Flexionen entstehen, indem lexikalische Worte durch sog. "Flexive" erweitert oder verändert werden.304 Typische Beispiele sind Singular-Plural-Versionen: Haus – Häuser.

Wortbildungen

Wortbildungen bringen lexikalische Worte hervor, im Gegensatz zu den oben genannten flexivischen Worten.305 Beispiele für Wortbildungen sind zusammengesetzte Worte wie "Rechnungssumme" oder "Ampelanlage".

Heterogenität kann einerseits dann entstehen, wenn ein Partner das zusammengesetzte Wort als Name verwendet, der andere jedoch nur einen Teil verwendet, z.B. nur "Summe" statt "Rechnungssumme". Darüber hinaus kann Heterogenität durch unterschiedliche Arten der syntaktischen Verknüpfung der Teilworte entstehen. Einzelne Teilworte können zusammenŽschrieben, getrenntgeschrieben sowie durch einenȱ’—ŽȬ ȱȱȱȱȱȱȱȱȱȱȱȱȱȱȱȱȱȱȱȱȱȱȱȱȱȱȱȱstrich oder sonstiges Trennzeichen separiert  Ž›Ž—ǯ

304 305

Vgl. Vater 1999, S. 77. Vgl. Vater 1999, S. 79.

5.7 Heterogenitätsüberwindung Bezeichnung

237

Erläuterung

Abkürzungen Abkürzungen stellen syntaktische Variationen des gleichen Bezeichners dar.306 Zu Abkürzungen gehören:307 ƒ Initialwörter mit Buchstabenaussprache: SPD, HSV ƒ Initialwörter mit silbischer Aussprache: UNO, NATO ƒ Zusammensetzung von Silbenteilen: Trafo, Kripo ƒ Kopfwörter: Auto, Akku ƒ Schwanzwörter: Bus ƒ Initiale und Vollwort: U-Bahn ƒ Sonstige, freie Abkürzungen, die individuell von den Nutzern vorgenommen werden können; z.B. "R.Sum" für "Rechnungssumme". Tabelle 23 : Formen der Synonymie

Es seien nun die notwendigen und hinreichenden Bedingungen für Homonymie (b HOMON ) formal definiert. Klo, Kme : ªHetBEZ  Klo,Kme š º « » º» §  hatBezR a Klo1 b hatBezR a Klo b š · «ª ¸ › »» « «Klo1 : ¨ ¨ Equ   Klo ,Kme ¸ »» b HOMON  Klo,Kme œ « « 1 © ¹ »» «« §  hatBezR a Kme1 b hatBezR a Kme b š · » » «« ¸»» « «Kme1 : ¨ ¨ Equ   Klo,Kme ¸»» « «¬ 1 © ¹¼¼ ¬ Bedingung 23: Hinreichende und notwendige Bedingungen für Homonymie

306 307

Vgl. Bouquet et al. 2005, S. 7. Liste entnommen aus Vater 1999, S. 97.

238

5 Ontologisches Matching

Homonymie sei dann gegeben, wenn die Bezeichner zweier Konzeptklassen den lokalen Heterogenitätseffekt HetBEZ  Klo,Kme verursachen und in einer der Ontologien eine weitere Konzeptklasse mit gleichem Bezeichner existiert, die als semantisch äquivalent klassifiziert wurde. Das folgende Schaubild zeigt die Überwindung von Namensheterogenität vor dem Hintergrund der oben definierten Heterogenitätsursachen. Het BEZ  Klo,Kme

Homonymie

Synonymie

simBEZ  Klo,Kme

1

simBEZ  Klo,Kme

Sonstiges

0

Keine maschinelle Heterogenitätsüberwindung möglich

Ende

Abbildung 26: Überwindung von Namensheterogenität

Im Fall von Synonymie wird der Bezeichnerkoeffizient auf den Wert "1" gesetzt; Homonymie führt zu einem Wert "0". Eine Transformation der Geschäftsdaten ist bei Namensheterogenität nicht erforderlich. 5.7.3.2 Strukturkonflikte

Strukturkonflikte lassen sich an den Werten der RA-Relevanz erkennen. Hier können zwei Heterogenitätsursachen auftreten, die als "Strukturrelevanz" und "Strukturirrelevanz" bezeichnet werden sollen. Beide Strukturkonflikte sind Wirkungs-eindeutig, d.h. von einem sublokalen Heterogenitätseffekt kann nicht direkt auf die Heterogenitätsursache geschlossen werden, der umgekehrte Weg ist allerdings möglich. Somit er-

5.7 Heterogenitätsüberwindung

239

fordern die beiden genannten Ursachen für Strukturkonflikte eine formale Definition. Mit Strukturrelevanz (b SRELE )wird eine Situation bezeichnet, in der der Heterogenitätseffekt HetRAW  Klo,Kme auftritt und alle Konzeptklassen der Ontologie KME , deren Geschäftsdaten ebenfalls zum Regulären Ausdruck von Klo kompatibel sind, als semantisch inäquivalent zu Klo klassifiziert werden. In diesem Fall ist die Struktur der Geschäftsdateneinheit von Kme relevant zur Heterogenitätsüberwindung, weil aufgrund dieser Geschäftsdatenstruktur ausschließlich Kme semantisch äquivalent zu Klo sein kann. Klo, Kme : ªHetRAW  Klo,Kme š º « » º» « ªKme1 : b SRELE  Klo,Kme œ « « » º » »» ·  « « «ª§  Kme1 { Kme š Ÿ Equ  Klo,Kme1 » » « « ¨¨ kompRA  Klo,Kme ¸¸ »¼ ¼» ¼» 1 ¹ ¬ ¬« «¬© Bedingung 24: Hinreichende und notwendige Bedingungen für Strukturrelevanz

Strukturirrelevanz (b SIRRE ) beschreibt eine Situation, in der der lokale Heterogenitätseffekt HetRAW  Klo,Kme auftritt und unter den anderen

Konzeptklassen der Ontologie KME , deren Geschäftsdaten ebenfalls zum Regulären Ausdruck von Klo kompatibel sind, eine Konzeptklasse existiert, die semantisch äquivalent zu Klo ist. Hieraus lässt sich folgern, dass aus der Kompatibilität der Geschäftsdaten von Kme zum Regulären Ausdruck von Klo in diesem konkreten Fall nicht auf die Äquivalenz der beiden Konzeptklassen geschlossen werden kann. Die Geschäftsdatenstruktur ist also irrelevant für die Äquivalenz der betrachteten Konzeptklassen.

240

5 Ontologisches Matching Klo, Kme : ªHetRAW  Klo,Kme š º « » º» « ªKme1 : » «« · » »» b SIRRE  Klo,Kme œ « «§  Kme1 { Kme š ¨ ¸ « «¨ kompRA Klo,Kme š ¸ » »  1 » « «¨ ¸» » « «¨ Equ   Klo,Kme ¸ » 1 ¹ »¼ ¼ ¬ «¬©

Bedingung 25: Hinreichende und notwendige Bedingungen für Strukturirrelevanz

Die folgende Abbildung skizziert die Szenarien zur Überwindung von Strukturkonflikten. HetRAW  Klo,Kme

Strukturirrelevanz

Strukturrelevanz

simRAW  Klo,Kme

1

simRAW  Klo,Kme

Sonstiges

0

Keine maschinelle Heterogenitätsüberwindung möglich

Ende

Abbildung 27: Überwindung von Strukturkonflikten

Für den Fall der Strukturrelevanz wird angenommen, dass nur das betrachtete Konzeptklassenpaar  Klo,Kme semantisch äquivalent sein kann. Der Wert für die RA-Relevanz wird daher auf "1" gesetzt. Analog ist im Fall der Strukturirrelevanz davon auszugehen, dass das betrachtete Konzeptklassenpaar  Klo,Kme aus der Perspektive der RARelevanz nicht semantisch äquivalent sein kann. Diese Annahme resultiert in einem Wert für die RA-Relevanz von "0".

5.7 Heterogenitätsüberwindung

241

Eine Transformation der Geschäftsdaten ist bei struktureller Heterogenität nicht erforderlich. 5.7.3.3 Verschmelzungs- und Trennungskonflikte (VT-Konflikte)

Verschmelzungs- und Trennungskonflikte (VT-Konflikte) treten aufgrund unterschiedlicher Granularität der betrachteten Ontologien auf. Granularitätsunterschiede sind dadurch gekennzeichnet, dass Realweltphänomene in der einen Ontologie durch eine einzelne Konzeptklasse, in der anderen Ontologie jedoch durch mehrere Konzeptklassen repräsentiert werden. Hierbei ist also die Abbildungsgranularität in der einen Ontologie grober, in der anderen feiner. Dadurch lassen sich für die Bereiche unterschiedlicher Granularität keine semantisch äquivalenten Pendants in der jeweiligen Partnerontologie identifizieren. Die betrachteten Konzeptklassen werden nicht als semantisch äquivalent identifiziert. Verschmelzungskonflikte sind dadurch gekennzeichnet, dass nach dem Empfang einer Nachricht mindestens zwei KME-Konzeptklassen zu einer KLO-Konzeptklasse verschmolzen werden müssen. Trennungskonflikte erfordern die Aufteilung einer empfangenen Konzeptklasse auf mindestens zwei KLO-Konzeptklassen. Äquivalenzgruppe Kme Kme1

Kme2 Klo1

Klo2

Klo Äquivalenzgruppe Verschmelzungskonflikt

Trennungskonflikt

Abbildung 28: Verschmelzungs- und Trennungskonflikte

VT-Konflikte unterscheiden sich durch zwei Merkmale von den in Kapitel 5.7.3.8 vorgestellten Granularitätskonflikten. ƒ Granularitätskonflikte lassen sich nicht durch eine Verschmelzung von Konzeptklassen überwinden.

242

5 Ontologisches Matching

ƒ Die Ursache für Granularitätskonflikte ist das Fehlen mindestens einer Konzeptklasse. VT-Konflikte sind hingegen nicht durch fehlende Konzeptklassen gekennzeichnet. ƒ VT-Konflikte lassen sich auch als horizontale Granularitätskonflikte interpretieren.

Alle durch VT-Konflikte verursachten Heterogenitätsketten sind Ursache-Wirkungs-mehrdeutig. Die durch VT-Konflikte verursachten Heterogenitätseffekte können damit einerseits auch das Ergebnis einer anderen Heterogenitätsursache sein. Andererseits können VT-Konflikte Heterogenitätseffekte bei mehreren Äquivalenzindikatoren hervorrufen. Es lässt sich also weder aus dem beobachteten Effekt auf eine bestimmte Heterogenitätsursache schließen, noch kann alleine aus dem Auftreten der betrachteten Heterogenitätsursache das Auftreten eines bestimmten Heterogenitätseffekts vorhergesagt werden. Somit ist eine formale Definition von VT-Konflikte erforderlich, um eine maschinelle Identifizierbarkeit dieser Heterogenitätsursache zu ermöglichen. Als Basis für eine formale Analyse von Verschmelzungs- oder Trennungskonflikten wird nun das Konstrukt der "Äquivalenzgruppen" (ÄG) vorgestellt. Als Äquivalenzgruppe wird die Menge der zu verschmelzenden oder die Menge der getrennten KLO-Konzeptklassen bezeichnet, denen eine äquivalente Konzeptklasse in der Partnerontologie gegenübersteht. Jede Äquivalenzgruppe verfügt über die Summe aller Eigenschaften der in ihr enthaltenen Konzeptklassen. Formal sollen Äquivalenzgruppen durch das Präfix "ÄG" notiert werden. Der Term ÄGKME  Klo1 ,Klo2 bezeichnet also eine Äquivalenzgruppe, die aus den beiden Konzeptklassen Klo1 und Klo2 besteht und sich auf die Ontologie KME bezieht. Mit KME werden in dieser Arbeit stets Senderontologien bezeichnet. Somit impliziert die Äquivalenzgruppe ÄGKME  Klo1 ,Klo2 , dass eine Konzeptklasse in KME existiert, die auf die beiden Konzeptklassen Klo1 und Klo2 aufgeteilt werden muss (Trennungskonflikt). Äquivalenzgruppen können nur innerhalb einer Ontologie gebildet werden.

5.7 Heterogenitätsüberwindung

243

Zunächst soll der Prozess der Identifizierung und Überwindung von Verschmelzungskonflikten betrachtet werden. Verschmelzungskonflikte können durch die folgenden Heterogenitätseffekte sichtbar werden: HetBEZ , Het ATT und HetMER . Da alle drei Heterogenitätseffekte nicht Ursache-eindeutig interpretiert werden können, stellen sie lediglich Hinweise für mögliche VT-Konflikte dar. Die Diagnose von VT-Konflikten ist somit eine mögliche Option, wenn mindestens einer der drei Heterogenitätseffekte festgestellt wird. Ein Verschmelzungskonflikt liegt vor, wenn eine Äquivalenzgruppe, bestehend aus zwei Konzeptklassen Kme1 und Kme2 , gefunden werden kann, die zu einer betrachteten Konzeptklasse Klo semantisch äquivalent ist. Bei Verschmelzungskonflikten werden stets zwei Konzeptklassen einer empfangenen Ontologie zu einer Konzeptklasse der KLO-Ontologie verschmolzen. Klo, Kme1 :

b VKONF  Klo,Kme1 œ ª « «Kme2 « « ¬

§ Het  Klo,Kme š ·º 1 ¨ ¸» ¸» : ¨ Het  Klo,Kme2 š ¨ ¸»  ¨ Equ  Klo, ÄG  Kme1 ,Kme2 ¸ » © ¹¼

Bedingung 26: Hinreichende und notwendige Bedingungen für Verschmelzungskonflikte

Zu klären ist, wie sich die Berechnung einzelner Äquivalenzindikatoren ändert, wenn diese für eine Konzeptklasse und eine Äquivalenzgruppe statt für zwei Konzeptklassen berechnet werden müssen. Zur Kalkulation des Bezeichnerkoeffizienten simBEZ werden die Namen der zu verschmelzenden Konzeptklassen zu einer Zeichenkette zusammengefügt. Die Attributmengen der zu verschmelzenden Konzeptklassen werden vereinigt, ggf. vorhandene Doppeleinträge müssen entfernt werden. Weiterhin enthält die verschmolzene Gruppe alle mereologischen und taxonomischen Beziehungen der Einzelkonzepte. Falls es sich bei den zu verschmelzenden KME-Konzeptklassen um Bedeutungseinheiten handelt, denen ein Datenfeld-Strukturelement zugeordnet ist und sofern die KLO-Konzeptklasse über einen Regulären

244

5 Ontologisches Matching

Ausdruck verfügt, dann müssen die Geschäftsdaten der beiden KMEKonzeptklassen derart verknüpft werden, dass sie zum Regulären Ausdruck der KLO-Konzeptklasse kompatibel sind. Bei Trennungskonflikten kann die zu trennende KME-Konzeptklasse einem Datenfeld zugeordnet sein. In diesem Fall ist auch die in diesem Datenfeld transportierte Geschäftsdateneinheit aufzuteilen. Diese Aufteilung kann nur dann automatisiert erfolgen, wenn für die beiden KLOKonzeptklassen ein Regulärer Ausdruck definiert ist. In diesem Fall lässt sich bspw. durch Ausprobieren herausfinden, welcher Teil des Geschäftsdatenstroms zu welcher KLO-Konzeptklasse gehört. Trennungskonflikte sind dadurch gekennzeichnet, dass die Äquivalenzgruppe Bestandteil der KLO-Ontologie ist. Entsprechend sind die notwendigen und hinreichenden Bedingungen für Trennungskonflikte anzupassen. Klo1 , Kme :

b TKONF  Klo1 ,Kme œ ª « «Klo2 « « ¬

§ Het  Klo ,Kme š ·º 1 ¨ ¸» ¸» : ¨ Het  Klo2 ,Kme š ¨ ¸» ¨ Equ   ÄG  Klo1 ,Klo2 ,Kme ¸ » © ¹¼

Bedingung 27: Hinreichende und notwendige Bedingungen für Trennungskonflikte

Die Überwindung von Trennungskonflikten erfolgt analog zur der für Verschmelzungskonflikte beschriebenen Methode. 5.7.3.4 Taxonomieheterogenität

Unter dem Sammelbegriff "Taxonomieheterogenität" werden zwei Heterogenitätsursachen zusammengefasst: fehlende Konzepte im taxonomischen Kontext und fehlende taxonomische Beziehungen. Beide Heterogenitätsursachen können zwei Heterogenitätseffekte hervorrufen: HetTAX und HetGRA . Treten HetTAX und HetGRA gemeinsam auf, so erscheint es ratsam, die Ursachenanalyse auf den Heterogenitätseffekt HetTAX zu konzentrieren. Im Gegensatz zu HetGRA ist HetTAX indikatorspezifisch, da dieser Heterogenitätseffekt ausschließlich im taxonomischen Kontext der betrachte-

5.7 Heterogenitätsüberwindung

245

ten Konzeptklassen hervorgerufen werden kann. HetGRA hingegen kann auch im mereologischen Kontext seinen Ursprung besitzen. Die durch fehlende taxonomische Beziehungen (b FBTAX ) verursachten Heterogenitätsketten sind Ursache-Wirkungs-mehrdeutig, da die infrage kommenden Ursachen mehrere Heterogenitätseffekte auslösen können. Gleichzeitig ist von den genannten Heterogenitätseffekten kein Rückschluss auf fehlende taxonomische Beziehungen als Heterogenitätsursache möglich, da beide Heterogenitätseffekte auch durch fehlende Konzeptklassen ausgelöst werden können. Der Zustand taxonomischer Heterogenität aufgrund fehlender taxonomischer Beziehungen sei in dem unten stehenden Schaubild dargestellt:

Kme1

HetTAX  Klo1 ,Kme1

Klo1

Kme2

HetTAX  Klo2 ,Kme2

Klo2

Abbildung 29: Fehlende taxonomische Beziehungen als Heterogenitätsursache

In der obigen Abbildung sind zwar die Konzeptklassen Klo1 und Klo2 taxonomisch miteinander verbunden. Allerdings fehlt eine analoge Beziehung in der KME -Ontologie. Somit tritt zwischen den Paarungen beider Ontologien taxonomische Heterogenität auf. Die notwendigen und hinreichenden Bedingungen für fehlende taxonomische Beziehungen als Heterogenitätsursache seien nun auch formal definiert.

246

5 Ontologisches Matching Klo1 , Kme1 :

b FBTAX  Klo1 ,Kme1 œ ªHetTAX  Klo1 ,Kme1 š º « » º» « ªKme2 , Klo2 : »» ««ª ª ª Klo ‹ hyperVon  .Klo š º º º » » ««« R 2 1 «« » ›»»»» ««« «« » »»  ««« Kme2 ‹ hyperVonR .Kme1 » » » » » « « « »» ¬ ¼ « « « »»»» ««« « ª Klo2 ‹ hyperVonR .Klo1 š º » » » » ««« » ›»»» «« ««« «¬ Kme2 ‹ hyperVonR .Kme1 »¼ » » » » « « « «HetTAX  Klo2 ,Kme2 š » « »» ««« ª Klo ‹ hyperVon  .Klo š º » » » » « R 2 1 «« » › »»»» «« »» « « «« « »  « Kme2 ‹ hyperVonR .Kme1 »»»» ««« « » ¬ ¼ « »»»» ««« « ª Klo ‹ hyperVon .Klo š º » » » » ««« 2 R 1 «« » » »» » » « «« « »  Kme ‹ hyperVon .Kme «  « » «¬ ¬ ¬ 2 R 1 ¼ ¼ ¼ »¼ » ¬¬ ¼

 



 







Bedingung 28: Hinreichende und notwendige Bedingungen für fehlende taxonomische Beziehungen als Heterogenitätsursachen

Die hier dargestellte Heterogenitätsursache lässt sich überwinden, indem die fehlende taxonomische Beziehung in der entsprechenden Ontologie nachträglich eingefügt wird. Der Ablauf hierzu ist der nachfolgenden Abbildung zu entnehmen.

5.7 Heterogenitätsüberwindung

247

Klo ‹ hyperVon .Klo š Kme ‹ hyperVon .Kme  R

2

1

 R

2

Kme2 ‹ hyperVonR .Kme1

1

 Klo2 ‹ hyperVonR .Klo1 š

 Kme2 ‹ hyperVonR .Kme1

Kme2 ‹ hyperVonR .Kme1

b FBTAX  Klo1 ,Kme1

Ende

 Klo ‹ hyperVon .Klo š  Kme ‹ hyperVon .Kme  R

2

2

 R

1

 Klo2 ‹ hyperVonR .Klo1 š  Kme2 ‹ hyperVonR .Kme1

Sonst

Klo2 ‹ hyperVonR .Klo1

1

Klo2 ‹ hyperVonR .Klo1

Ende

Abbildung 30: Diagnose und Überwindung fehlender taxonomischer Beziehungen

Die Art der hinzuzufügenden Beziehung sowie die Konzeptklassen, zwischen denen die Beziehung hinzuzufügen ist, werden aus den bereits in Bedingung 28 ("Hinreichende und notwendige Bedingungen für fehlende taxonomische Beziehungen als Heterogenitätsursache") dargestellten vier Szenarien abgeleitet. Eine weitere Ursache von Taxonomieheterogenität stellt die sog. taxonomische Lücke (b LÜTAX ) dar. Das folgende Schaubild veranschaulicht den Zustand taxonomischer Lücken anhand eines Beispiels.

248

5 Ontologisches Matching Kme

HetTAX  Klo,Kme

Klo

?

Klo1

? ?

Abbildung 31: Taxonomische Lücken als Ursachen taxonomischer Heterogenität

In der oben dargestellten Abbildung weisen die Konzeptklassen Klo und Kme taxonomische Heterogenität auf. Für diese Heterogenität ist eine fehlende Konzeptklasse in der KME -Ontologie verantwortlich. Der Unterschied zwischen taxonomischen Lücken und den in Abschnitt 5.7.3.8 dargestellten Granularitätskonflikten besteht darin, dass taxonomische Lücken nicht aufgrund unterschiedlicher Abstraktionsgrade auftreten. Die bei taxonomischen Lücken fehlenden Konzeptklassen stellen keine Knoten, sondern Blätter innerhalb des taxonomischen Netzes dar. Blätter verfügen nur über eine taxonomische Beziehung, Knotenkonzepte besitzen mindestens zwei taxonomische Beziehungen. Um festzustellen, ob eine taxonomische Lücke Heterogenitätsursache ist, muss der taxonomische Kontext des als taxonomisch heterogen eingestuften Konzeptklassenpaars analysiert werden. Die Heterogenitätsursache "Taxonomische Lücke", formal dargestellt durch das Symbol b LÜTAX , sei nun formal definiert.

5.7 Heterogenitätsüberwindung

249

Klo, Kme :

b LÜTAX  Klo,Kme œ ªHetTAX  Klo,Kme š º « » º» ª ª Klo1 ‹ hyperVonR .Klo š º º «ªª º »» «« ««« »R» » »» ««¬ Klo2 :  Klo2 ‹ hyperVonR .Klo1 »¼ » » ««« »» » š» « « «Klo : « 1 « ª Klo ‹ hyperVon  .Klo š º »» » » ««« 1 R » »» «« » »› ««« »» « « Klo : Klo ‹ hyperVon  .Klo » » » ««« 2 2 1 »¼ R »» ««« ¬« «¬ ¼» » »» » ««« ª Kme { Kme1 Ÿ º »» » ««« » »» » « « «Kme1 : «  «¬Equ  Klo1 , Kme1 »¼ »» « « ¬« ¼» »» «« ª ª Kme1 ‹ hyperVonR .Kme š º º»» º ««ª «« » R » »»» ««« ««¬ Kme2 :  Kme2 ‹ hyperVonR .Kme1 »¼ » »»» ««« » š» » » « « «Kme1 : « ª º « Kme1 ‹ hyperVonR .Kme š » »»» ««« « » « « » »»» « « « « Kme : Kme ‹ hyperVon  .Kme » » »»» ««« R 2 2 1 ¼» «¬ ¬« »¼ » » » ««« »»» ««« ª Klo { Klo1 Ÿ º »»» « « «Klo1 : « » »»»  « « «« «¬Equ  Klo1 ,Kme1 »¼ »¼ ¼ ¼ ¬¬¬

















Bedingung 29: Hinreichende und notwendige Bedingungen für taxonomische Lücken als Heterogenitätsursachen

Im ersten Teil der obigen Randbedingung führt eine fehlende Konzeptklasse in der KME -Ontologie zum Heterogenitätseffekt HetTAX  Klo,Kme .

Im zweiten Teil ist eine fehlende Konzeptklasse in der KLO -Ontologie verantwortlich. Es sei nun der erste Teil der oben dargestellte Randbedingung erläutert. Die Terme

 Klo1 ‹ hyperVonR .Klo und

Klo1 ‹ hyperVonR- .Klo

250

5 Ontologisches Matching

definieren eine weitere Konzeptklasse Klo1 der KLO-Ontologie, die ein Hyperonym (erste Zeile) oder ein Hyponym (zweite Zeile) von Klo darstellt. Die Terme Klo2 :  Klo2 ‹ hyperVonR .Klo1 und



Klo2 : Klo2 ‹ hyperVonR- .Klo1



legen fest, dass die Konzeptklasse Klo1 ein Blattkonzept ist. Schließlich bedeutet der Term ª Kme { Kme1 Ÿ º Kme1 : « »  «¬Equ  Klo1 ,Kme1 »¼ ,

dass alle Konzeptklassen der KME-Ontologie, die nicht zu Kme semantisch äquivalent sind, auch nicht zu Klo1 äquivalent sein dürfen. Taxonomische Lücken lassen sich nicht überwinden, da sich nicht feststellen lässt, ob die fehlende Konzeptklasse bewusst oder unbewusst weggelassen wurde. Daher dient die formale Definition dieser Heterogenitätsursache lediglich dazu, andere Heterogenitätsursachen ausschließen zu können. 5.7.3.5 Mereologieheterogenität

Auch Mereologieheterogenität umfasst zwei Heterogenitätsursachen: fehlende mereologische Beziehungen und fehlende Konzeptklassen im mereologischen Kontext. Die Analyse und Überwindung von Mereologieheterogenität gleicht den bei Taxonomieheterogenität angewendeten Verfahren. Es erfolgt daher eine kompaktere Darstellung als im vorangegangenen Abschnitt. Wie auch bei taxonomischer Heterogenität sind die durch fehlende mereologische Beziehungen (b FBMER ) verursachten Heterogenitätsketten Ursache-Wirkungs-mehrdeutig. Diese Heterogenitätsursache kann die beiden Heterogenitätseffekte HetMER und HetGRA auslösen. Analog zur taxonomischen Heterogenität ist der Heterogenitätseffekt HetMER indikatorspezifisch und somit für die Ursachenanalyse im mereologischen Kontext relevant.

5.7 Heterogenitätsüberwindung

251

Die Konstellation einer fehlenden mereologischen Beziehung als Heterogenitätsursache sei nun beispielhaft im unten stehenden Schaubild grafisch dargestellt.

Kme1

HetMER  Klo1 ,Kme1

Klo1

Kme2

HetMER  Klo2 ,Kme2

Klo2

Abbildung 32: Fehlende mereologische Beziehungen als Heterogenitätsursachen

Hier ist die fehlende mereologische Beziehung zwischen Kme1 und Kme2 für den Heterogenitätseffekt verantwortlich. Es folgt nun wie schon bei der Taxonomieheterogenität eine formale Darstellung der hinreichenden und notwendigen Bedingungen für fehlende mereologische Beziehungen als Heterogenitätsursache.

252

5 Ontologisches Matching Klo1 , Kme1 : ªHetMER  Klo1 ,Kme1 š º « » º» « ªKme2 , Klo2 : » «« º » »» « « «ªHetMER  Klo2 ,Kme2 š »» «« ªª  º º » « « «« « « Klo2 ‹ hatKompR .Klo1 š » » »» » » › » «« «« » » » « « «« « « Kme2 ‹ hatKompR .Kme1 » » »» » » ¼ »» ««««¬ « « ª Klo ‹ hatKomp .Klo š º »» » » » « b FKMER  Klo1 ,Kme1 œ « « R 2 1 » « «« » ›» »» « « «« « «¬ Kme2 ‹ hatKompR .Kme1 »¼ » »» » » «««« » »» « « « « ª Klo2 ‹ hatKompR .Klo1 š º » »» » » » › » »» ««««« » »»»» «««««  « « « « ¬« Kme2 ‹ hatKompR .Kme1 ¼» » »» » » ««« « » »» « « « « ª  Klo2 ‹ hatKompR .Klo1 š º » »» » » « « « « « Kme ‹ hatKomp .Kme » » » » »  2 R 1 ¼» ¼ ¼ ¼» » ¬« ¬« ¬ ¬ ¬« ¼

 



 







Bedingung 30: Hinreichende und notwendige Bedingungen für fehlende mereologische Beziehungen als Heterogenitätsursachen

Auch in Mereologien kann diese Heterogenitätsursache durch das nachträgliche Einfügen der fehlenden Beziehung überwunden werden.

5.7 Heterogenitätsüberwindung

253

 Klo ‹ hatKomp .Klo š  Kme ‹ hatKomp .Kme  R

2

1

 R

2

1

 Klo2 ‹ hatKompR .Klo1 š

 Kme2 ‹ hatKompR .Kme1

Kme2 ‹ hatKompR .Kme1

Kme2 ‹ hatKompR .Kme1

b FBMER  Klo1 ,Kme1

Ende

Klo ‹ hatKomp .Klo š Kme ‹ hatKomp .Kme  R

2

2

 R

1

 Klo2 ‹ hatKompR .Klo1 š  Kme2 ‹ hatKompR .Kme1

Sonst

Klo2 ‹ hatKompR .Klo1

1

Klo2 ‹ hatKompR .Klo1

Ende

Abbildung 33: Diagnose und Überwindung fehlender mereologischer Beziehungen

Auch in Mereologien lassen sich mereologische Lücken als Heterogenitätsursache feststellen. Da die Analyse und Überwindung mereologischer Lücken analog zu der Analyse und Überwindung taxonomischer Lücken verläuft, wird auf eine redundante Darstellung verzichtet. Es sei diesbezüglich auf das vorangegangene Unterkapitel verwiesen. 5.7.3.6 Attributheterogenität

Attributheterogenität entspricht hinsichtlich der Heterogenitätsursachen, der Heterogenitätsanalyse und der Heterogenitätsüberwindung weitgehend den beiden vorangegangenen Unterkapiteln, in denen Taxonomieund Mereologieheterogenität besprochen wurde. So kennt auch Attributheterogenität zwei Heterogenitätsursachen: fehlende Attributbeziehungen und fehlende Konzeptklassen (Attribute) im Attributkontext.

254

5 Ontologisches Matching

Der Unterschied zwischen Attribut- und Taxonomieheterogenität wird bei Betrachtung der jeweiligen Kontexte deutlich. Der taxonomische Kontext einer Konzeptklasse ist zweigeteilt und besteht aus einem hyperonymen und einem hyponymen Bereich. Da allerdings Attribute nicht durch andere Attribute spezifiziert werden sollen, ist eine solche Zweiteilung in Attributkontexten nicht zu finden. Die folgende Abbildung zeigt eine fehlende Attributbeziehung als Heterogenitätsursache (b FBATT ). Es gelte Alo ‹ Attribut IDI sowie Ame ‹ Attribut IDI . Alo ist ein Attribut der KLO-, Ame ein Attribut der KME-Ontologie.

Ame

Equ   Alo, Ame

?

Kme

Alo

aloA

Het ATT  Klo,Kme

Klo

Abbildung 34: Fehlende Attributbeziehung als Heterogenitätsursache

Es seien nun die Bedingungen für fehlende Attributbeziehungen als Heterogenitätsursache formal definiert.

5.7 Heterogenitätsüberwindung

255

Klo, Kme :

b FBATT  Klo,Kme œ ªHet ATT  Klo,Kme š º « » º» « ªAme, Alo : »» ««ª ª ª Klo ‹ attribut A .Alo š º ºº»» ««« «« » R »» «««  Kme ‹ attribut A .Ame »¼ » » »» »» « « «Equ   Alo, Ame š « «¬ « »»»» ««« ª Klo ‹ attribut A .Alo š º « »»»» « « « « » « »»»» « « « ¬ «¬ Kme ‹ attribut A .Ame »¼ ¼ ¼» ¼ ¼ ¬¬¬ Bedingung 31: Hinreichende und notwendige Bedingungen für fehlende Attributbeziehungen als Heterogenitätsursachen

Das folgende Schaubild veranschaulicht die Diagnose und Überwindung fehlender Attributbeziehungen.  Klo ‹ attribut A .Alo š

 Kme ‹ attribut A .Ame

Kme ‹ attribut A .Ame

Het ATT  Klo,Kme š

Ende

Equ   Alo,Ame

 Klo ‹ attribut A .Alo š  Kme ‹ attribut A .Ame

Sonst

Klo ‹ attribut A .Alo

Ende

Abbildung 35: Diagnose und Überwindung fehlender Attributbeziehungen

Fehlende Attribute als Heterogenitätsursache können nicht überwunden werden. Auf eine formale Definition und grafische Darstellung wird daher verzichtet. 5.7.3.7 Attribut-Zuordnungskonflikte

Neben fehlenden Konzeptklassen sowie fehlenden Attributbeziehungen treten als Besonderheit in Attributkontexten sog. Attribut-Zuordnungskonflikte auf (b ATTZO ). Attribut-Zuordnungskonflikte entstehen immer dann, wenn semantisch äquivalente Attribute auf unterschiedlichen ta-

256

5 Ontologisches Matching

xonomischen Ebenen zugewiesen werden. Angenommen, Fahrzeuge sollen durch das Attribut "Farbe" spezifiziert werden und "Fahrzeuge" ist Superklasse der beiden Konzeptklassen "LKW" und "PKW". Die Eigenschaft "Farbe" kann entweder der Superklasse "Fahrzeuge" oder den beiden Subklassen zugeordnet werden. Ist nun die Eigenschaft in der einen Ontologie der Super-, in der anderen jedoch den Subklassen zugeordnet, so führt dies zu einem Attribut-Zuordnungskonflikt. Kme1

Het ATT  Kme1 ,Klo1

Klo1

Equ   Alo, Ame

Alo

ameA

Ame V Kme2

aloA

Equ   Klo2 ,Kme2

Klo2

Abbildung 36: Attribut-Zuordnungskonflikte

Die beiden Attribute Ame und Alo stellen semantisch äquivalente Konzeptklassen dar. Diese Attribute sind in ihren jeweiligen Ontologien jedoch auf unterschiedlichen taxonomischen Ebenen zugeordnet. So ist Ame Attribut von Kme1 , Alo ist der Konzeptklasse Klo2 als Attribut zugeordnet. Infolgedessen entsteht zwischen Kme1 und Klo1 der Heterogenitätseffekt Het ATT  Kme1 ,Klo1 . Zwischen Kme2 und Klo2 besteht keine Heterogenität, da Kme2 als Hyponym von Kme1 dessen Eigenschaften erbt. Diese Vererbungsbeziehung wird im Schaubild durch den Kreis mit einem "V" repräsentiert. Die durch Attribut-Zuordnungskonflikte hervorgerufenen Heterogenitätsketten sind Wirkungs-eindeutig, da Attribut-Zuordnungskonflikte ausschließlich den Attributkoeffizienten beeinflussen. Um einen Attribut-Zuordnungskonflikt diagnostizieren zu können, muss dieser zunächst formal definiert werden.

5.7 Heterogenitätsüberwindung

257

Kme1 , Klo1 :

b ATTZO  Klo1 ,Kme1 œ ªHet ATT  Klo1 ,Kme1 š « « « « « « «Kme , Klo , Alo, Ame : 2 2 « « « « « ¬«

º » ªEqu  Alo, Ame š Equ  Klo2 ,Kme2 š º » « »» « Kme1 ‹ hyperVonR .Kme2 š »» « »» « Klo1 ‹ hyperVonR .Klo2 š »» « »» ª º « ª Kme1 ‹ attribut A .Ame š º › »» » » « « « Klo ‹ attribut .Alo »» 2 A ¼» » « « ¬« »» « » « ª Kme ‹ attribut .Ame š º »» 2 A » « «« »» » » «¬ ¬« ¬« Klo1 ‹ attribut A .Alo »¼ » ¼» ¼ ¼ 



Bedingung 32: Hinreichende und notwendige Bedingungen für AttributZuordnungskonflikte

Die Strategie zur Überwindung von Attribut-Zuordnungskonflikten besteht darin, Attribute neu zuzuordnen. Diese Neuzuordnung erfolgt immer in der Ontologie, in der das betrachtete Attribut der spezielleren Konzeptklasse zugeordnet ist. In dieser Ontologie wird das Attribut der allgemeineren Konzeptklasse zugeordnet. Am Beispiel aus Abbildung 36 würde dies bedeuten, dass das Attribut Alo statt der Konzeptklasse Klo2 der Konzeptklasse Klo1 zugeordnet werden müsste. 5.7.3.8 Granularitätskonflikte

Granularitätskonflikte können in allen Kontexten auftreten, die durch transitive Beziehungen gebildet werden. In IDI-Ontologien gehören hierzu taxonomische und mereologische Beziehungen. Granularitätskonflikte können drei Heterogenitätseffekte verursachen: HetTAX , HetMER und HetGRA . Die durch Granularitätskonflikte ausgelösten Heterogenitätsketten sind Ursache-Wirkungs-mehrdeutig. Granularitätskonflikte treten auf, wenn in zwei Ontologien Teile des taxonomischen oder mereologischen Kontextes auf unterschiedlichen Abstraktionsstufen abgebildet wurden. Unterschiedliche Abstraktionsstufen sind dadurch gekennzeichnet, dass gleiche semantische Abstände durch eine unterschiedliche Anzahl an Konzeptklassen ausgefüllt wer-

258

5 Ontologisches Matching

den. Dieser Zusammenhang sei anhand der unten stehenden Grafik erläutert.

Kme2

HetMER  Klo1 ,Kme2

Kme1

?

Kme

HetMER  Klo,Kme

Klo1

Klo

Abbildung 37: Granularitätskonflikte als Heterogenitätsursachen

Die KLO -Ontologie wurde, zumindest in dem betrachteten Ausschnitt, auf einem höheren Abstraktionsniveau modelliert. So besteht der mereologische Kontext der Konzeptklasse Kme aus den Konzeptklassen Kme1 und Kme2 , während der mereologische Kontext von Klo lediglich aus der Konzeptklasse Klo1 besteht. Treten in dieser Konstellation die Heterogenitätseffekte HetMER  Klo,Kme sowie HetMER  Klo1 ,Kme2

auf und sind alle Konzeptklassen der KLO-Ontologie zu der Konzeptklasse Kme1 inäquivalent, so wird dieser Zustand in der IDI-Architektur als Granularitätskonflikt bezeichnet. Dieser Granularitätskonflikt ist dadurch gekennzeichnet, dass das zu Kme1 äquivalente Pendant in der KLO-Ontologie fehlt. Es bestehen die folgenden Unterschiede zu VT-Konflikten. ƒ Die Überwindung eines Granularitätskonflikts kann nicht durch die Verschmelzung von Konzeptklassen erfolgen, da einer solchen verschmolzenen Konzeptklasse kein semantisch äquivalentes Pendant in der Partnerontologie gegenübersteht.

5.7 Heterogenitätsüberwindung

259

ƒ Granularitätskonflikte werden durch fehlende Konzeptklassen verursacht. ƒ Im Gegensatz zu VT-Konflikten können die in diesem Abschnitt beschriebenen Granularitätskonflikten auch als vertikale Granularitätskonflikte interpretiert werden.

Es besteht der folgende Unterschied zu taxonomischen oder mereologischen Lücken: ƒ Die bei taxonomischen oder mereologischen Lücken fehlenden Konzeptklassen stellen Blattkonzepte dar; fehlende Konzeptklassen in Granularitätskonflikten hingegen repräsentieren Knotenkonzepte.

Es seien nun die notwendigen und hinreichenden Bedingungen eines Granularitätskonflikts für die Rolle hatKompR formal definiert. Die gleiche Bedingungsdefinition gilt analog auch für die Rollen hatKompR sowie hyperVonR und hyperVonR . Klo, Kme :

b GKONF  Klo,Kme œ ªHetMER  Klo,Kme š « « « « « «Klo1 , Kme1 , Kme2 « « « «¬

º » ª º» « Klo1 ‹ hatKompR .Klo š »» « Kme ‹ hatKomp .Kme š »» R 1 « »» »» : « Kme2 ‹ hatKompR .Kme1 š « »» «HetMER  Klo1 ,Kme2 š »» « »»  «¬C : ¬ªC  KLO Ÿ Equ C,Kme1 ¼º »¼ » ¼

Bedingung 33: Hinreichende und notwendige Bedingungen für Granularitätskonflikte

Die o.a. Bedingung beschreibt eine fehlende Knotenkonzeptklasse in der KLO-Ontologie. Analog hierzu kann allerdings auch in der KME-Ontologie eine fehlende Knotenkonzeptklasse zu Granularitätskonflikten führen. Auf eine separate Darstellung wird verzichtet. Die Strategie zur Überwindung von Granularitätskonflikten besteht darin, die Konzeptklasse ohne semantisch äquivalentes Pendant bei der Ermittlung des Taxonomie- oder Mereologiekoeffizienten unberücksichtigt zu lassen. Bezogen auf die Darstellung in Abbildung 37 dürfte also die

260

5 Ontologisches Matching

Konzeptklasse Kme1 bei der Kalkulation des Mereologiekoeffizienten keine Berücksichtigung finden.

5.7.4 Geschäftsdatentransformation Die Geschäftsdatentransformation stellt den letzten Schritt im Prozess der Heterogenitätsüberwindung dar. Zielsetzung der Transformation ist es, die Syntax empfangener Geschäftsdaten so zu verändern, dass sie von den Anwendungsschnittstellen des Empfängers verarbeitet werden können. Die Bedeutung der Geschäftsdaten bleibt unverändert. Eine Notwendigkeit zur Geschäftsdatentransformation kann sich bei VTKonflikten ergeben. Dieser Punkt wurde bereits in Abschnitt 5.7.3.3 bearbeitet und findet somit an dieser Stelle keine Beachtung mehr. Eine weitere Transformationsnotwendigkeit ergibt sich bei der Kompatibilität von Maßeinheiten. Geschäftsdaten mit kompatiblen Maßeinheiten besitzen zwar die gleiche Bedeutung. Allerdings müssen die empfangenen Geschäftsdaten erst umgerechnet werden, bevor sie von den lokalen Anwendungsschnittstellen verarbeitet werden können. Die zur Umrechnung erforderlichen Umrechnungsfaktoren können bspw. in einer Umrechnungsmatrix gespeichert oder als Umrechnungsfunktion repräsentiert werden. Es sei umrechnen  ME1

faktor * ME2

eine Funktion, die angibt, mit welchem Umrechnungsfaktor faktor ein in der Maßeinheit ME2 notierter Zahlenwert zu multiplizieren ist, damit dieser Zahlenwert der Maßeinheit ME1 entspricht. Die Umkehrfunktion der o.g. Umrechnungsfunktion lautet umrechnen  ME 2

ME1 . faktor

Die Umrechnung von Zahlen sei am Beispiel der Maßeinheiten "Seemeile" (Sm) und "Kilometer" (Km) erläutert. Eine Seemeile entspricht 1,852 Kilometern.

5.7 Heterogenitätsüberwindung umrechnen  Km

261 1, 852 * Sm

Transformationen sind häufig bei sog. strukturierten Datenfeldern erforderlich. Als typisches Beispiel für ein strukturiertes Datenfeld sei das Datumsfeld genannt. Tag, Monat und Jahr in Datumsfeldern können in unterschiedlicher Reihenfolge und mit unterschiedlichen Trennzeichen notiert sein. Oft sind Anwendungssysteme nur in der Lage, Datumsfelder mit einer bestimmten Syntaxstruktur zu verarbeiten. Nutzt der Sender eine andere Strukturierung, so wird eine Transformation der Geschäftsdaten erforderlich. Auch im Finanzbereich lassen sich Beispiele für strukturierte Datenfelder finden. So besteht bspw. die sog. IBAN (International Bank Account Number) aus zwei Bestandteilen: einer nationalen Identifikationsnummer der Bank und der Kontonummer. Ist eine Anwendung nur in der Lage, Bankleitzahl und Kontonummer zu verarbeiten, dann ist eine Aufspaltung dieses IBAN-Datenfelds erforderlich.

6 Anwendungsbeispiel 6.1 Beschreibung des Anwendungsbeispiels Ausgangspunkt für das fiktive Anwendungsbeispiel ist die Produktionsfirma "Produktion GmbH", die Laderaumkapazitäten nach Bedarf am Markt einkaufen möchte. Die Firma "Produktion GmbH" nimmt also die Rolle eines sog. "Verladers" ein, der logistische Transportdienstleistungen nachfragt.308 Das Unternehmen möchte Laderaumgesuche unter Nutzung vorhandener Schnittstellen durch das bestehende Anwendungssystem erzeugen und dann versenden. Dabei sieht sich die Produktion GmbH einer großen Anzahl möglicher Dienstleister gegenüber, mit denen keine Vereinbarungen über den Austausch elektronischer Geschäftsdaten bestehen. Der IDI-Agent der Firma Produktion GmbH, auch "VER-Agent" genannt, hat die Aufgabe, die aus den Anwendungssystemen generierten Laderaumgesuche an eine elektronische Clearingstelle (z.B. eine Laderaumbörse) zu senden. Die Clearingstelle interpretiert die Nachricht auf Pragmatikebene und leitet das Laderaumgesuch an die IDI-Agenten von Fuhrunternehmen weiter. Die Funktionalität dieser Clearingstelle ist für diese Forschungsarbeit nicht weiter von Interesse. Um als Datendrehscheibe im oben beschriebenen Sinne fungieren zu können, muss sie zwar ebenfalls die Nachricht bzw. die zugehörigen Metadaten mindestens auf Pragmatikebene interpretieren. Die umfassendere Interpretation (Syntax, Semantik, Pragmatik und Protokolle) findet jedoch in jedem Fall dezentral bei den IDI-Agenten der Fuhrunternehmen statt. Der IDIAgent des Fuhrunternehmens wird im Folgenden auch "FUH-Agent" genannt.

308

Vgl. Pfohl 1996, S. 281.

A. Köhler, Intelligent Data Interchange (IDI), DOI 10.1007/978-3-8348-9767-1_6, © Vieweg+Teubner Verlag |Springer Fachmedien Wiesbaden GmbH 2010

264

6 Anwendungsbeispiel

Zielsetzung des Anwendungsbeispiels ist es, die grundlegende Arbeitsweise sowie die Funktionsfähigkeit einer IDI-Architektur anhand eines Beispielszenarios darzustellen. Das Anwendungsbeispiel umfasst die folgenden Bestandteile: ƒ eine informale Darstellung eines durch VER-Agent zu versendenden Laderaumgesuchs (Abschnitt 6.2.1), ƒ die informale und formale Darstellung der VER-Ontologie bzw. des Ausschnitts aus der VER-Ontologie, der das Laderaumgesuch als Sendenachricht spezifiziert (Abschnitte 6.2.2 bis 6.2.4), ƒ eine informale Darstellung des durch FUH-Agent zu empfangenden Laderaumgesuchs (6.3.1), ƒ die informale und formale Darstellung der FUH-Ontologie bzw. des Ausschnitts aus der FUH-Ontologie, der das Laderaumgesuch als Empfangsnachricht spezifiziert (Abschnitt 6.3.2 bis 6.3.4), ƒ die Darstellung von Ausschnitten des ontologischen Matchingprozesses (Abschnitt 6.4).

Die Kalkulation des Äquivalenzkoeffizienten ist nicht Gegenstand des Anwendungsbeispiels. Zu diesem Kalkulationsprozess wurde bereits in Abschnitt 5.6.1 ein Rechenbeispiel vorgestellt. Die beiden LBox-Spezifikationen starten jeweils mit der Interaktionsebene, da hier Konzeptklassen spezifiziert werden, die bei der folgenden Syntaxspezifikation benötigt werden. Die Semantikspezifikation erfolgt zum Schluss.

6.2 LBox des Verladers 6.2.1 EDIFACT-Beispielnachricht 6.2.1.1 Grundlagen EDIFACT

Um den Implementierungsaufwand für IDI-Agenten möglichst gering halten zu können, soll die bestehende EDI-Infrastruktur umfassend weiter- und mitgenutzt werden. Da der EDIFACT-Standard heute weit verbreitet ist, sei angenommen, dass das zu versendende Laderaumgesuch als EDIFACT-Nachricht vorliegt. Es werden daher in diesem Abschnitt

6.2 LBox des Verladers

265

die wichtigsten Grundlagen des EDIFACT-Standards dargestellt. Für eine vertiefende Darstellung wird auf die entsprechende Literatur verwiesen.309 EDIFACT steht für "Electronic Data Interchange For Administration, Commerce and Transport". EDIFACT ist ein weltweit anerkannter und branchenneutraler Standard für die syntaktische und semantische Spezifikation elektronisch zu versendender Geschäftsdaten. EDIFACT ist sowohl ISO- wie auch DIN-Norm. Die EDIFACT-Syntax wird international unter ISO 9735, national unter DIN 16556 beschrieben. EDIFACT spezifiziert auf syntaktischer Ebene den zulässigen Zeichensatz, zulässige Datenelemente sowie den strukturellen Aufbau einer Geschäftsdatendatei.310 Datenelemente bilden den Grundbaustein einer EDIFACT-Datei. Beispiele sind "Bestellmenge" oder "Bestellnummer". Datenelemente können zu Gruppen zusammengefasst werden und heißen dann Gruppendatenelemente. Segmente beinhalten logisch zusammengehörige Datenelemente oder Datenelementgruppen. Beispiele für Segmente sind: ƒ NAD – Name und Adresse; ƒ PAT – Zahlungsbedingungen; ƒ LIN – Positionsdaten.

Wie die Beispiele zeigen, werden einzelne Segmente durch einen Segmentbezeichner identifiziert; NAD steht für Name und Adresse, PAT für Zahlungsbedingungen usw. Es werden zwei Arten von Segmenten unterschieden: ƒ Nutzdaten-Segmente beinhalten die eigentlichen betriebswirtschaftlichen Daten.

309 310

Vgl. DIN 1998; Deutsch 1995, S. 39-57. Die Beschreibung des syntaktischen EDIFACT-Aufbaus ist im Wesentlichen entnommen aus DIN 1998, S.12-17; Schmoll, Nommensen 1996, S. 57-74; Hermes 1991.

266

6 Anwendungsbeispiel

ƒ Service-Segmente dienen der Identifizierung und Strukturierung einer Übertragungsdatei. So ist beispielsweise UNG das Kopfsegment einer Nachrichten-Gruppe, UNH ist einzelnen Nachrichten vorangestellt. Während UNT das Ende einer Nachricht anzeigt, bestimmt UNE das Ende einer Nachrichtengruppe.

Strukturell besteht eine EDIFACT-Übertragungsdatei aus mehreren Nachrichtengruppen oder Nachrichten. Eine Nachricht sei definiert als eine "Zusammenfassung aller Segmente, die zur Darstellung eines Geschäftsvorgangs (z.B. Bestellung, Rechnung) erforderlich sind."311 Segmente beinhalten sowohl einfache Datenelemente wie auch Datenelement-Gruppen. Sie werden durch einen Bezeichner gekennzeichnet. Die Reihenfolge einzelner Datenelemente in Segmenten oder Datenelement-Gruppen ist festgelegt. Gleiches gilt für die Abfolge von Segmenten in einzelnen EDIFACT-Nachrichtentypen wie ORDERS oder INVOIC. Allerdings können einzelne Datenelemente, Datenelementgruppen sowie Segmente auch weggelassen werden, sofern dies laut EDIFACT-Standard zulässig ist. EDIFACT stellt ein Hybridformat dar, das neben Bezeichnern auch unterschiedliche Trennzeichen verwendet. Die folgende Tabelle listet die verfügbaren EDIFACT-Trennzeichen auf und beschreibt, welche Elemente durch das jeweilige Trennzeichen separiert werden.

311

Hermes 1991, S. 9.

6.2 LBox des Verladers Trennzeichen

267

Beschreibung

+

Trennt den Segmentbezeichner von den folgenden Datenelementen und einzelne Datenelemente voneinander.

:

Gruppendatenelement-Trennzeichen. Trennt die Datenelemente einer Datenelement-Gruppe.

'

Segment-Endezeichen; beendet das Segment.

Tabelle 24: EDIFACT Trennzeichen

Die semantische Spezifikation einzelner Geschäftsinhalte in EDIFACTNachrichten erfolgt vor allem durch den Einsatz von Segmentbezeichnern und sog. "Qualifiern". Segmentbezeichner grenzen die Interpretationsmöglichkeiten der Geschäftsdaten eines Segments ein, können jedoch die Segmentsemantik nicht exakt festlegen. So bestimmt der Segmentbezeichner "DTM" zwar, dass die nachfolgenden Geschäftsdaten Informationen über ein Datum oder eine Zeitangabe enthalten. Es wird jedoch nicht festgelegt, ob es sich um ein Lieferdatum, ein Zahldatum oder ein sonstiges Datum handelt. Diese weitere semantische Einschränkung erfolgt über Qualifier. So legt beispielsweise der Qualifier "137" fest, dass es sich bei dem betreffenden Datum um ein Rechnungsdatum handelt. Die in der folgenden Beispielnachricht verwendeten Segmente, Datenfelder, Datenfeldgruppen und Codes entsprechen dem EDIFACTDirectory D.05B. Es wurden die jeweiligen Batch-Verzeichnisse verwendet. Der Nachrichtentyp lautet IFTMBP. Die folgende Tabelle listet Internetadressen auf, die Beschreibungen zu den einzelnen Elementen der IFTMBP-Nachricht enthalten. Alle Elemente der Beispielnachricht wurden diesen Verzeichnissen entnommen. EDIFACTEbene

URL

Nachricht

http://www.unece.org/trade/untdid/d05b/trmd/ iftmbp_c.htm

268

6 Anwendungsbeispiel

EDIFACTEbene

URL

Segmente

http://www.unece.org/trade/untdid/d05b/trsd/ trsdi1.htm

Datenfeldgruppen

http://www.unece.org/trade/untdid/d05b/trcd/ trcdi1.htm

Datenfelder und Codes

http://www.unece.org/trade/untdid/d05b/tred/tredi1.htm

Tabelle 25: Elemente des EDIFACT-Directories D.05B und ihre Darstellung im Internet

6.2.1.2 Beispielnachricht

Es sei nun zunächst die EDIFACT-Beispielnachricht dargestellt, die der VER-Agent versendet. Im Anschluss wird die Bedeutung dieser Beispielnachricht erläutert. UNH+NUMMER01+IFTMBP:D:05:B:UN' BGM+335' TDT+1++3' DTM+189:181108:2' DTM+233:201108:2' NAD+CZ+++Produktion GmbH+Senderstr. 12+Sendestadt++12345' NAD+CN+++Vertrieb1 GmbH+Empfängerstr. 28+Empfangstadt++67899' NAD+CN+++Vertrieb2 GmbH+Empfängerstr. 45+Empfangstadt++67899' GID++5:PX' UNT+9+NUMMER01' Abbildung 38: EDIFACT-Beispielnachricht "Laderaumgesuch"

UNH-Segment

Das UNH-Segment fungiert als Nachrichtenkopf und besitzt keine fachliche Funktion. Inhaltliche Bestandteile des UNH-Segments sind ƒ die eindeutige Nachrichtenreferenz (hier "NUMMER01"),

6.2 LBox des Verladers

269

ƒ der Nachrichtentyp (hier: IFTMBP = "Provisional Booking Message" (Buchungsanfrage))312, ƒ Informationen zur Versions- und Releasenummer der Nachricht und zur standardisierenden Organisation. BGM-Segment (Beginning of Message)

Das Segment spezifiziert in diesem Beispiel die Nachrichtenbedeutung. Bei der Ziffernfolge "335" handelt es sich um einen Code, der für "Booking Request" steht.313 TDT-Segment (Transport information)

Dieses Segment definiert die Transporteigenschaften. Dabei kommen wieder zwei Codes zum Einsatz. Code "1" steht für einen Inlandstransport (Datenfeld 8051), Code "3" legt fest, dass der Transport über die Straße erfolgen soll (Datenfeld 8067).314 DTM-Segment (Date/time/period)

Auch im Segment zur Spezifikation von Zeitpunktangaben werden zahlreiche Codes genutzt. ƒ Code "189" (Datenfeld 2005) steht für "Transport means departure date/time, scheduled"315, also die geplante Abfahrt. ƒ Code "233" (Datenfeld 2005) steht für "Transport means arrival date/time, ultimate"316, also die späteste Ankunft. ƒ Code "2" (Datenfeld 2379) spezifiziert das Datumsformat: DDMMYY (Y=Year; M=Month; D=Day).

312

313 314 315 316

"A message from a party requesting space and/or giving brief details of a planned consignment for forwarding and/or transport services to the party providing those services. In this message, the conditions under which the planned transport should take place can be given." (UN/EDIFACT 2006). Code 335 ist ein Element von Datenfeld 1001. Vgl. UN/EDIFACT 2005. Vgl. UN/CEFACT 2001. UN/EDIFACT 2005. UN/EDIFACT 2005.

270

6 Anwendungsbeispiel

NAD-Segment (Name and address)

Das NAD-Segment gehört zur Segmentgruppe 8, welche die beteiligten Parteien definiert. Es sollen in der vorliegenden Nachricht drei Parteien spezifiziert werden, somit muss das NAD-Segment dreimal wiederholt werden. Die inhaltliche Festlegung der Partei erfolgt durch das Datenfeld 3035 (Party function code qualifier). "CZ" steht für Versender, "CN" für Empfänger. Alle anderen Angaben in diesen drei Segmenten stellen Adressangaben dar. GID-Segment (Goods Item Details)

Dieses Segment spezifiziert die Ladungseigenschaften. Die Zahl "5" gibt die Anzahl der zu transportierenden Paletten an. "PX" ist ein Code von Datenfeld 7065 und steht für "Palette".317 UNT-Segment

Das UNT-Segment ist ein Servicesegment ohne fachliche Bedeutung. Hier wird die Anzahl der Segmente angegeben und eine eindeutige Nachrichtenreferenz genannt.

6.2.2 Interaktionsebene: Protokoll "Laderaumsuche" 6.2.2.1 Informale Protokollspezifikation

Der Verlader fungiert in dem hier vorgestellten Szenario als Initiator eines Kommunikationsprozesses. Diese Initiatorrolle sieht vor, dass er einen Protokollvorschlag an einen oder mehrere infrage kommende FUHAgenten sendet. Ob diese Kommunikationsbeziehung durch eine direkte Ansprache, einen elektronischen Marktplatz oder eine sonstige Institution zustande kommt, ist für die vorliegende Arbeit ohne Bedeutung. Die Zielsetzung des Verladers besteht darin, ein Transportangebot für einen bestimmten Transportbedarf zu erhalten. Das in diesem Unterkapitel informal dargestellte Protokoll "Transportnachfrage" spezifiziert eine vom Verlader definierte Interaktionsstruktur, die aus fachlicher Sicht ge-

317

Vgl. UN/ECE 2008.

6.2 LBox des Verladers

271

eignet ist, das Ziel des Verladers zu erreichen. Die Protokollspezifikation ist Bestandteil der Verlader-Ontologie VER . Alle Elemente der Ontologie erhalten bei der formalen Spezifikation als oberen Index die Zeichenkette "VER". Fuhrunternehmen

Verlader

VER SV01



ProtOffer

VER SV02



ProtReject

xo VER SV03



ProtAccept

VER SV04

Transportdienstl.

Requestive

VER SV05



Rejective

xo VER SV06

Transportdienstl.

Offer

VER SV07



Rejective

VER SV08



Acceptance

xo

Abbildung 39: Protokoll "Laderaumsuche" aus der Senderperspektive

Die oben gezeigte Grafik visualisiert das Protokoll LaderaumsucheVER aus der Perspektive des Verladers. Zielsetzung des Verladers ist es, auf seine Buchungsanfrage hin ein Transportangebot zu erhalten. Vorab muss der IDI-Agent des Verladers zunächst eine Protokollanfrage an den IDI-Agenten des Fuhrunternehmens senden. Dieses Protokollangebot kann entweder angenommen oder abgelehnt werden.

272

6 Anwendungsbeispiel

Der Protokollvorschlag muss mindestens den Ausschnitt aus der Ontologie des Verladers umfassen, der das vorliegende Protokoll formal spezifiziert. Hierzu gehört insb. die Spezifikation der Sendevorgänge. Die ersten drei Sendevorgänge bilden den Prozess der Protokollvereinbarung ab. Diese Sendevorgänge verfügen über keine Geschäftsdaten, somit ist auch kein Nachrichtenbezeichner vorhanden. Protokollannahme und -ablehnung sind durch eine xoderR -Rolle verbunden. Lehnt der IDI-Agent des Fuhrunternehmers den Protokollvorschlag ab, so endet die Kommunikationsbeziehung. Auf der Lebenslinie des Verlader-Agenten ist ein Aktivitätsbalken zur Annahme und Interpretation der Protokollablehnung vorgesehen. Allerdings geht von diesem Aktivitätsbalken keine weitere Aktivität aus. Nimmt der FUH-Agent den Protokollvorschlag an, so generiert der VERAgent infolgedessen eine Buchungsanfrage. Diese Buchungsanfrage stellt den eigentlichen inhaltlichen Kern der innerhalb des Protokolls ausgetauschten Sendevorgänge dar. Hier sind alle für den Verlader relevanten betriebswirtschaftlichen Daten der nachgefragten Dienstleistung enthalten. Neben dem Sendevorgang mit der Nummer "06" ist dies der einzige Sendevorgang, der eine Nachricht und somit Geschäftsdaten enthält. Das Protokoll sieht für den FUH-Agenten zwei mögliche Reaktionen vor: er kann ein Angebot abgeben oder die Angebotsabgabe verweigern. Beide Sendevorgänge weisen einen inhaltlichen Bezug zur Buchungsanfrage, also zum Sendevorgang Nr. 04, auf. Dieser Bezug verhindert das redundante Versenden von Geschäftsdaten. Das Transportangebot aus Sendevorgang Nr. 07 muss allerdings einen Preis für die angebotene Dienstleistung enthalten. Sowohl Sendevorgänge mit der Illokution "Requestive" wie auch Sendevorgänge mit der Illokution "Offer" werden im Ablehnungsfall mit der Illokution "Rejective" beantwortet. Der inhaltliche Bezug der Ablehnung wird wiederum durch die Rolle bezugZuR hergestellt. 6.2.2.2 Formale Protokollspezifikation

Es sei nun das Interaktionsprotokoll formal dargestellt. In einem ersten Schritt werden die Sendevorgänge dem Protokoll zugeordnet.

6.2 LBox des Verladers

LaderaumsucheVER

273 VER ªSequenzIDI Š hatSVR .SV01 º Š « » VER VER » « hatSVR .SV02 Š hatSVR .SV03 Š « » VER VER  « hatSVR .SV04 Š hatSVR .SV05 Š» « VER VER » « hatSVR .SV06 Š hatSVR .SV07 Š» « » VER «¬ hatSVR .SV08 »¼

Axiom 48: Protokoll "Laderaumsuche" (VER-Ontologie)

Der Rest des Kapitels beinhaltet die formale Darstellung der einzelnen Sendevorgänge. Ein wesentliches Merkmal von Sendevorgängen betrifft die Sender- und Empfängerrollen. Der protokollvorschlagende IDI-Agent besitzt zunächst nur Informationen darüber, welche Sendevorgänge er selbst senden oder empfangen wird. Diesen Sendevorgängen weist er daher jeweils mit der Sender- oder Empfängerrolle die abgeschlossene Klasse ^VER-Agent` zu. Das Individuum ^VER-Agent` repräsentiert den IDIAgenten des Verladers. Da vor der Protokollvereinbarung die Identität des Kommunikationspartners nicht bekannt ist, wird der Bildbereich der entsprechenden Rollen durch die allgemeine Klasse Agent IDI angegeben. ª VER ‹« SV01 «¬

VER SV02

VER SV03

ª « « ‹« « « ¬« ª « « ‹« « « ¬«

1 hatSenderR .^VER-Agent ` Š 1 1 1 1 1

1 hatEmpfängerR .Agent IDI Š º » hatIlloR .^ProtOffer ` »¼ º hatSenderR .Agent IDI Š » hatEmpfängerR .^VER-Agent ` Š » » VER hatIlloR .^ProtReject ` Š 1 bezugZuR .SV01 Š » » VER xoderR .SV03 ¼»

1 hatSenderR .Agent IDI Š 1 hatEmpfängerR .^VER-Agent ` Š 1 hatIlloR .^ProtAccept` Š VER 1 xoderR .SV02

VER 1 bezugZuR .SV01

º » » » Š» » ¼»

Axiom 49 Sendevorgänge zur Protokollvereinbarung (VER-Ontologie)

274

6 Anwendungsbeispiel

Die Sendevorgänge 04 bis 06 beinhalten die Buchungsanfrage des Verladers und die Reaktionsmöglichkeiten des Fuhrunternehmers hierauf. Bei diesen Sendevorgängen sind auch Anforderungen an die Sendereihenfolge zu spezifizieren. Die Beschränkung der Reihenfolge wird für diejenigen Sendevorgänge definiert, die erst nach einem anderen Sendevorgang gesendet werden dürfen.

VER SV04

VER SV05

VER SV06

ª « ‹« « « ¬ ª « ‹« « « ¬ ª « « ‹« « « «¬

1 hatSenderR .^VER-Agent ` Š 1 1 1 1 1 1 1 1 1

1 hatEmpfängerR .Agent IDI Šº » VER » hatIlloR .^Requestive` Š 1 vorherR .SV03 Š » » hatNachR .TransportdienstleistungVER ¼ IDI hatSenderR .Agent Š 1 hatEmpfängerR .^VER-Agent ` Šº » VER » Š hatIlloR .^Rejective` Š 1 bezugZuR .SV04 » VER VER » Š 1 vorherR .SV04 xoderR .SV06 ¼ IDI hatSenderR .Agent Š 1 hatEmpfängerR .^VER-Agent ` Š º » VER » Š hatIlloR .^Offer ` Š 1 bezugZuR .SV04 » VER » Š xoderR .SV05 »  VER VER » vorherR .SV04 Š 1 hatNachR .Transportdienstleistung ¼

Axiom 50: Buchungsanfrage des Verladers und Reaktionsmöglichkeit des Fuhrunternehmens (VER-Ontologie)

Abschließend erfolgt die Spezifikation der Reaktionsmöglichkeiten des Verladers auf das Transportangebot des Fuhrunternehmens. 1 hatSenderR .^VER-Agent ` Š

VER SV07

ª « ‹« « « ¬

1 hatSenderR .^VER-Agent ` Š

VER SV08

ª « ‹« « « ¬

1 hatEmpfängerR .Agent IDI Šº » VER » Š 1 hatIlloR .^Rejective` Š 1 vorherR .SV06 » VER VER » Š 1 bezugZuR .SV06 1 xoderR .SV08 ¼ 1 hatEmpfängerR .Agent IDI Šº » VER » 1 hatIlloR .^ Acceptance` Š 1 vorherR .SV06 Š » VER VER » 1 xoderR .SV07 Š 1 bezugZuR .SV06 ¼

Axiom 51: Reaktionsmöglichkeit des Verladers auf das Transportangebot (VEROntologie)

6.2 LBox des Verladers

275

6.2.3 Syntaxebene 6.2.3.1 Informale Darstellung der Repräsentationsinhalte

Wie die Abbildung 39 gezeigt hat, sieht das Protokoll "Laderaumgesuch" im vierten Sendevorgang den Versand einer Nachricht vor. Zielsetzung dieses Unterkapitels ist es, das in der VER-Ontologie des Verladers gespeicherte Syntaxwissen über die in Sendevorgang 04 zu versendende EDIFACT-Nachricht formal und informal darzustellen. Die in den folgenden Unterkapiteln verwendete Notation für SyntaxKonzeptklassen umfasst drei Bestandteile: ƒ Sie beinhaltet einen Bezeichner, wobei jeder Bezeichner einen Strukturelementtyp repräsentiert ("Nach" steht für Nachricht, "Kopf" für Kopfteil, "Pos" für Positionsteil, "DFG" für Datenfeldgruppe und "DF" für Datenfeld). ƒ Sie beinhaltet einen Hochindex "VER", um zu kennzeichnen, dass die bezeichnete Konzeptklasse zur Ontologie des Verladers gehört. ƒ Schließlich verfügt jeder Bezeichner noch über einen Tiefindex, der dem bezeichneten Strukturelement eine eindeutige Nummer zuweist. Jeder Strukturelementtyp besitzt einen eigenen Nummernkreis. Für die Reihenfolge der Indexnummern ist ausschließlich die Reihenfolge des Auftretens in der Nachricht relevant.

Als Beispiel für die Bezeichnung einer Syntax-Konzeptklasse sei das VER Konzept DF12 genannt. 6.2.3.2 Mereologische Struktur der Beispielnachricht

EDIFACT-Nachrichten besitzen charakteristische mereologische Strukturen, die bei der syntaktischen Identifizierung von Geschäftsdateneinheiten zu berücksichtigen sind. Die in Abbildung 38 gezeigte Beispielnachricht verfügt über die folgenden, zu spezifizierenden Strukturelemente: eine Nachricht, zwei Kopfteile, ein Positionsteil, sieben Datenfeldgruppen und 29 Datenfelder. Kopfteile enthalten Datenfelder, die für alle Positionen einer Nachricht gelten. Bei der vorliegenden Beispielnachricht tritt eine Besonderheit auf: der Kopfteil ist physisch in die Segmente UNH und UNT getrennt. Da-

276

6 Anwendungsbeispiel

her sind formal bei der Syntaxrepräsentation zwei Kopfteile zu repräsentieren. Alternativ könnte der zweite Teil des Kopfteils (das Segment UNT) auch als Fußteil interpretiert werden. Positionsteile enthalten Datenfelder, die nur für einzelne Positionen Gültigkeit besitzen. Bspw. sind Artikelpreise nur für einzelne Positionen gültig. Datenfeldgruppen beinhalten inhaltlich zusammengehörende Datenfelder. Datenfeldgruppen werden in IDI-Ontologien aus zwei Gründen als eigene Objekte repräsentiert: ƒ Datenfeldgruppen können Geschäftsdateneinheiten mit einer eigenen Bedeutung besitzen. ƒ Datenfeldgruppen können über eine eigene syntaktische Kennzeichnung verfügen.

Es folgt nun eine grafische Darstellung der mereologischen Syntaxstruktur der in Abbildung 38 dargestellten EDIFACT-Nachricht. Die dort verwendeten grafischen Elemente besitzen die folgenden Bedeutungen: ƒ Die grau gefärbte Raute an der Mereologie-Wurzel repräsentiert die Nachricht. ƒ Alle anderen, untergeordneten Rauten repräsentieren Kopfteile und Positionsteile. ƒ Rechtecke stellen Datenfeldgruppen und Datenfelder mit ihren jeweiligen laufenden Nummern dar. ƒ Abgerundete Rechtecke bei Datenfeldgruppen beinhalten die Segmentbezeichner der Datenfeldgruppe. ƒ Abgerundete Rechtecke bei Datenfeldern enthalten die transportierten Geschäftsdateneinheiten.

6.2 LBox des Verladers

277 NachVER

VER Kopf02

VER Kopf01

PosVER

NUMMER01

VER DF01

IFTMBP

VER DF02

D

VER DF03

05

VER DF04

B

VER DF05

UN

VER DF06

9

VER DF28

20

VER DF13

NUMMER01

VER DF29

11 08

BGM

335

TDT

DTM+189

VER DFG03

VER DFG06

NAD+CN

18

VER DF10

VER DF20

Vertrieb1 GmbH

11

VER DF11

VER DF21

Empfängerstr. 28

08

VER DF12

VER DF22

Empfangstadt

VER DF23

67899

DTM+233

VER DFG04

VER DFG07

GID

VER DF14

VER DF24

5

VER DF15

VER DF25

PX

VER DFG01

VER DF07

VER DFG02

NAD+CZ

VER DFG05

Produktion GmbH

VER DF16

Senderstr. 12

VER DF17

1

VER DF08

Sendestadt

VER DF18

3

VER DF09

12345

VER DF19

Abbildung 40: Mereologische Syntaxstruktur der EDIFACT-Nachricht

Die obige Abbildung stellt zum einen sämtliche mereologischen Beziehungen zwischen den Strukturelementen dar. Zum anderen zeigt die Abbildung für jedes Strukturelement den zugehörigen eindeutigen Index. Zur besseren Orientierung sind außerdem auch die Geschäftsinhalte sowie – auf Ebene der Segmente – die Segmentbezeichner enthalten.

278

6 Anwendungsbeispiel

6.2.3.3 Formale Darstellung der Repräsentationsinhalte

Dieser Abschnitt beinhaltet eine formale Darstellung des erforderlichen Syntaxwissens. Da alle EDIFACT-Segmente über eigene syntaktische Kennzeichnungen verfügen, wird jedes dieser Segmente als Datenfeldgruppe repräsentiert. Die Spezifikation der Datenfelder erfolgt nach der Reihenfolge ihrer laufenden Nummern. VER Als erstes Strukturelement soll der durch die Konzeptklasse Kopf01 repräsentierte Kopfteil spezifiziert werden. Dieser Kopfteil entspricht dem EDIFACT-Segment UNH und enthält sechs Datenfelder. Der Kopfteil verfügt über eine eigene Startmarkierung ("UNH") sowie eine Endemarkierung ('). Diese Endemarkierung ist gleichzeitig auch Endemarkierung des letzten Datenfelds.

VER Kopf01

VER VER VER ªhatSER .DF01 º Š hatSER .DF02 Š hatSER .DF03 Š « » VER VER VER «hatSER .DF04 » Š hatSER .DF05 Š hatSER .DF06 Š  « » « 1 hatLfdNrR .^01` Š 1 zkStartT .^UNH ` Š 1 zkEndeT .^' ` Š » « » VER «¬ 1 seGleichEndeR .DF06 Š 1 optionalR .^falsch` »¼

Axiom 52: Kopfteil 01 (VER-Ontologie)

In den ersten beiden Zeilen werden die Meronyme des Kopfteils definiert. In der dritten Zeile wird zunächst die laufende Nummer zugewiesen. Es folgt die Spezifikation der Zeichenketten, die Start und Ende des Kopfteils markieren. Da sich der Kopfteil seine Endemarkierung mit VER dem Datenfeld DF06 teilt, ist ein entsprechender Hinweis in der letzten Zeile eingebaut. Schließlich wird durch den letzten Eintrag festgelegt, dass der Kopfteil verbindlich gefüllt wird. Bei der Spezifikation des ersten Datenfelds ist zu beachten, dass die Endemarkierung ("+") gleichzeitig Startmarkierung des folgenden Datenfelds 02 ist. Bei der Repräsentation von Datenfeld 02 müsste diese Information nicht erneut explizit spezifiziert werden. Der besseren Übersichtlichkeit wegen wird jedoch an dieser Stelle eine redundante Darstellung vorgezogen. Somit enthalten die Definitionen von Strukturelementen jeweils eine vollzählige Liste aller syntaktisch relevanten Eigenschaften.

6.2 LBox des Verladers ª VER DF01  « «¬

279

1 hatLfdNrR .^01` Š

1 zkStartT .^` Š

VER 1 endeGleichStartR .DF02 Š

1 zkEndeT .^` Š º » 1 optional R .^falsch` »¼

Axiom 53: Datenfeld 01 (VER-Ontologie)

Weil mit Datenfeld 02 in der EDIFACT-Syntax eine Datenelementgruppe beginnt, werden die folgenden Datenfelder durch das EDIFACTTrennzeichen für Gruppendatenelemente (":") voneinander separiert. In der IDI-Ontologie ist die Repräsentation dieser Gruppe nicht erforderlich, da sie über keine eigene syntaktische Kennzeichnung und keine eigene Bedeutung verfügt. VER DF02

ª «  « « «¬

1 hatLfdNrR .^02` Š

1 zkStartT .^` Š

1 optionalR .^falsch` Š VER 1 endeGleichStartR .DF01 Š

1 zkEndeT .^:` Š º » » » VER 1 endeGleichStartR .DF03 »¼

Axiom 54: Datenfeld 02 (VER-Ontologie)

Die Syntax-Repräsentationen der Datenfelder 03 bis 05 weisen keine Besonderheiten auf. VER DF03

VER DF04

VER DF05

ª «  « « «¬

1 hatLfdNrR .^03` Š

ª «  « « ¬«

1 hatLfdNrR .^04` Š

ª «  « « ¬«

1 hatLfdNrR .^05` Š

1 zkStartT .^:` Š

1 optionalR .^falsch` Š VER 1 endeGleichStartR .DF02 Š

º » » » VER 1 endeGleichStartR .DF04 »¼

1 zkStartT .^:` Š

1 optional R .^falsch` Š VER 1 endeGleichStartR .DF03 Š

VER 1 endeGleichStart R .DF04 Š

1 zkEndeT .^:` Š

º » » » VER 1 endeGleichStartR .DF05 ¼»

1 zkStartT .^:` Š

1 optional R .^falsch` Š

1 zkEndeT .^:` Š

1 zkEndeT .^:` Š

º » » » VER 1 endeGleichStartR .DF06 ¼»

Axiom 55: Datenfelder 03 bis 05 (VER-Ontologie)

Die Endemarkierung von Datenfeld 06 markiert gleichzeitig auch das Ende von Kopfteil 01. Dieser Zusammenhang wurde bei der Spezifikation des Kopfteils durch die Rolle seGleichEndeR ausgedrückt. Soll der

280

6 Anwendungsbeispiel

gleiche Sachverhalt aus der Perspektive des Datenfelds 06 formuliert werden, so ist die inverse Rolle seGleichEndeR zu verwenden.

VER DF06

ª «  « « ¬«

1 hatLfdNrR .^06` Š

1 zkStartT .^:` Š

1 optionalR .^falsch` Š VER 1 endeGleichStartR .DF05 Š

1 zkEndeT .^` ' Š

º » » » VER 1 seGleichEndeR .Kopf01 ¼»

Axiom 56: Datenfeld 06 (VER-Ontologie)

Mit dem nun folgenden EDIFACT-Segment BGM beginnt der Positionsteil. Da der Positionsteil jedoch weder über eine eigene syntaktische Kennzeichnung verfügt, noch eine eigene Bedeutung besitzt, noch wiederholt werden soll, ist eine eigenständige Repräsentation dieses Strukturelements nicht erforderlich. Gleiches gilt für das Segment BGM, das nur aus einem Datenfeld besteht. Um die Extrahierbarkeit der zugehörigen Geschäftsdateneinheit sicherzustellen, reicht es, die syntaktischen Eigenschaften von Datenfeld 07 und des zugehörigen Segments durch eine Konzeptklasse, nämlich Datenfeld 07, zu repräsentieren. Im Gegensatz zu den bislang definierten Datenfeldern wird als Startmarkierung also zusätzlich die Startmarkierung des EDIFACT-Segmentbezeichners angegeben. ª VER « DF07 ¬«

1 hatLfdNrR .^07` Š 1 zkEndeT .^` ' Š

1 zkStartT .^BGM ` Šº » 1 optionalR .^falsch` ¼»

Axiom 57: Datenfeld 07 (VER-Ontologie)

Das Segment TDT spezifiziert die Transportdetails und besteht aus den beiden Datenfeldern 08 und 09. Es wird zunächst die Datenfeldgruppe 02 syntaktisch definiert, dann die beiden genannten Datenfelder.

6.2 LBox des Verladers

VER DFG02 

ª VER DF08  « ¬« VER DF09

ª «  « « «¬

281

ªhatSE .DF VER Š hatSE .DF VER Š º R R 08 09 « » « 1 hatLfdNrR .^02` Š 1 zkStartT .^DTD` Š 1 zkEndeT .^' ` Š » « » VER «¬ 1 seGleichEndeR .DF09 Š 1 optionalR .^falsch` »¼ 1 hatLfdNrR .^08` Š 1 zkStartT .^` Š 1 zkEndeT .^` Šº » VER 1 endeGleichStartR .DF09 Š 1 optionalR .^falsch` ¼» 1 hatLfdNrR .^09` Š

1 zkStartT .^` Š

1 optionalR .^falsch` Š VER Š 1 endeGleichStartR .DF08

' Š º 1 zkEndeT .^` » » » VER 1 seGleichEndeR .DFG02 »¼

Axiom 58: Datenfeldgruppe 02 mit Datenfeldern (VER-Ontologie)

Bei den folgenden beiden EDIFACT-Segmenten tritt eine Besonderheit auf: der Segmentbezeichner lautet in beiden Fällen "DTM". Dieses Segment wird also wiederholt, wobei die Wiederholung eine andere Bedeutung besitzt. Es handelt sich daher um keine Wiederholung im Sinne der IDI-Architektur. Die zugehörigen Strukturelemente sind unterschiedlichen Bedeutungseinheiten zugeordnet. Um eine eindeutige Zuordnung der in den jeweiligen DTM-Segmenten enthaltenen Geschäftsdaten sicherstellen zu können, müssen sich die Segmente immer in der gleichen Reihenfolge befinden. Zwar ändert sich die Segmentreihenfolge bei EDIFACT-Nachrichten nicht. Bei den betrachteten DTM-Segmenten bietet es sich allerdings zusätzlich an, die im ersten Datenfeld übertragenen Codes als weiteres Identifikationsmerkmal zu nutzen. Die Startmarkierungen der Datenfeldgruppen lauten dann "DTM+189" und "DTM+233". Da es sich hierbei um eindeutig zu identifizierende Zeichenketten handelt, ist die eindeutige Identifizierbarkeit der Transportcontainer unabhängig von der Reihenfolge ihres Auftretens sichergestellt. Das Segment enthält einen weiteren Code am Ende, den EDIFACT-Code Nr. 2379 ("Date or time or period format code"). Dieser Code mit dem vorliegenden Wert "2" bestimmt lediglich die Struktur der Datumsangabe und wird nicht als Bestandteil des Geschäftsdatenstroms interpretiert. Eine Explikation der Datumsstruktur wird nicht benötigt, da die Da-

282

6 Anwendungsbeispiel

tumsangabe ohnehin durch drei separate Strukturelemente repräsentiert wird. Es sei nun zunächst die Datenfeldgruppe 03 mit ihren jeweiligen Datenfeldern definiert. Im Anschluss erfolgt die Syntaxrepräsentation der drei Datumsbestandteile. VER VER ªhatSER .DF10 º Š hatSER .DF11 Š « » VER «hatSER .DF12 Š 1 hatLfdNrR .^03` Š » VER DFG03  « » « 1 zkStartT .^DTM  189` Š » « » ¬ 1 zkEndeT .^' ` Š 1 optionalR .^falsch`¼ ª 1 hatLfdNrR .^10` Š 1 zkStartT .^:` Š º VER »  « DF10 VER « 1 endeBeiStartT .O DF10  2 Š 1 optional R .^falsch`» ¬ ¼ VER ª 1 hatLfdNr .^11` Š 1 startBeiStart .O DF º 3 10 R T VER »  « DF11 « » VER 1 endeBeiStartT .O DF10  4 Š 1 optionalR .^falsch`» ¬« ¼

 

ª VER  « DF12 « ¬

1 hatLfdNrR .^12` Š 1 zkEndeT .^: 2` Š













VER  5 Šº 1 startBeiStartT .O DF10 » » 1 optionalR .^falsch` ¼

Axiom 59: Datenfeldgruppe 03 mit zugehörigen Datenfeldern (VER-Ontologie)

Alle Positionsangaben von einschließlich der Endemarkierung von Datenfeld 10 bis zur Startmarkierung von Datenfeld 12 sind relative Positionsangaben. Sie wurden relativ zur Startmarkierung von Datenfeld 10 festgelegt. Hier wurden also Transportcontainer unterhalb der Ebene der EDIFACT-Datenfelder definiert. Die Struktur der Datenfeldgruppe 04 entspricht exakt der Struktur der Datenfeldgruppe 03. Lediglich die Bedeutung beider Gruppen unterscheidet sich. Datenfeldgruppe 03 enthält das Versanddatum, Datenfeldgruppe 04 das Empfangsdatum.

6.2 LBox des Verladers

283

VER VER ªhatSER .DF13 º Š hatSER .DF14 Š « » VER «hatSER .DF15 » Š 1 hatLfdNrR .^04` Š VER DFG04  « » « 1 zkStartT .^DTM  233` Š 1 zkEndeT .^' ` Š » « » ¬ 1 optionalR .^falsch` ¼ ª 1 hatLfdNrR .^13` Š 1 zkStart A .^:` Š º VER »  « DF13 VER « 1 endeBeiStartT .O DF13  2 Š 1 optionalR .^falsch`» ¬ ¼ VER ª 1 hatLfdNr .^14` Š 1 startBeiStart .O DF º 3 R T 13 VER » DF14  «« » VER «¬ 1 endeBeiStartT .O DF13  4 Š 1 optional R .^falsch`»¼

 

ª VER DF15  « « ¬

1 hatLfdNrR .^15` Š 1 zkEndeT .^: 2` Š













VER  5 Šº 1 startBeiStartT .O DF13 » » 1 optionalR .^falsch` ¼

Axiom 60: Datenfeldgruppe 04 mit zugehörigen Datenfeldern (VER-Ontologie)

Es folgen in der Beispielnachricht drei EDIFACT-Segmente mit den Bezeichnern "NAD". Dieser Bezeichner kennzeichnet Segmente, die einen Namen und eine Adresse beinhalten. In dem vorliegenden Fall beinhaltet das erste NAD-Segment eine Ladeadresse, die folgenden beiden NAD-Segmente jeweils eine Entladeadresse. Wie auch in den beiden vorangegangenen DTM-Segmenten folgt hier direkt auf den Segmentkennzeichner ein Codefeld, das die Art der Adresse spezifiziert. Dieses Codefeld bzw. die zugehörigen Codes sollen – wie bereits oben bei dem DTM-Segment praktiziert – der eindeutigen Kennzeichnung der NAD-Segmente dienen. Das erste NAD-Segment mit der Ladeadresse verfügt über eine Besonderheit: das Datenfeld, das den Stadtnamen beinhaltet (Datenfeld 18), wird nicht immer gefüllt, da das Anwendungssystem des Senders teilweise nur über die Postleitzahl verfügt. Der Sender muss den Empfänger hierüber informieren. Weitere Informationen sind nicht erforderlich, da bei fehlenden Geschäftsinhalten die Startmarkierung direkt auf die Endemarkierung trifft. Es sei nun zunächst das erste NAD-Segment syntaktisch spezifiziert.

284

6 Anwendungsbeispiel

VER DFG05

VER VER ªhatSER .DF16 º Š hatSER .DF17 Š « » VER VER «hatSER .DF18 » Š hatSER .DF19 Š « »  « 1 hatLfdNrR .^05` Š 1 zkStartT .^NAD  CZ` Š » « » ' Š « 1 zkEndeT .^` » « 1 seGleichEnde .DF VER Š 1 optional . falsch » ^ ` R R 19 ¬ ¼

ª VER DF16  « «¬

1 hatLfdNrR .^16` Š 1

VER endeGleichStartR .DF17

ª «  « « «¬ ª  « ¬«

1 hatLfdNrR .^17` Š

ª VER DF19  « «¬

1 hatLfdNrR .^19` Š

VER DF17

VER DF18

1 1 1 1

1 zkStart A .^  ` Š Š

1 zkEndeA .^` Šº » 1 optional R .^falsch` »¼

1 zkEndeT .^` Šº » VER endeGleichStartR .DF16 Š » » VER endeGleichStartR .DF18 Š 1 optional R .^falsch` »¼ hatLfdNrR .^18` Š 1 zkStartT .^` Š 1 zkEndeT .^` Šº » VER Š 1 optional R .^wahr ` endeGleichStartR .DF17 ¼»

1 optional R .^falsch` Š

1 zkStartT .^` Š

1 zkStartT .^` Š 1

1 zkEndeT .^' ` Šº » »¼

VER seGleichEndeR .DFG05

Axiom 61: Datenfeldgruppe 05 mit zugehörigen Datenfeldern (VER-Ontologie)

Zwischen den Datenfeldern 18 und 19 sind zwei Pluszeichen notiert. Die EDIFACT-Regeln sehen vor, dass ein nicht genutztes, im Standard aber definiertes Datenfeld durch ein Datenfeld-Trennzeichen angezeigt wird. Für die syntaktische Extrahierbarkeit ist dieser Zusammenhang ohne Belang. Um eine möglichst geringe Anzahl an Eigenschaften spezifizieren zu müssen, wurde das erste Pluszeichen als Endemarkierung von Datenfeld 18 und das zweite Pluszeichen als Startmarkierung von Datenfeld 19 definiert. Es folgt nun die Spezifikation von Datenfeldgruppe 06. Strukturell unterscheidet sich dieses NAD-Segment kaum von dem vorangegangenen. Allerdings ist das Strukturelement, das den Stadtnamen enthält, wieder als obligatorisch gekennzeichnet. Darüber hinaus kann das Segment wiederholt werden. Zu definieren ist also zum einen die Eigenschaft der Wiederholbarkeit. Zum anderen müssen die Syntaxeigenschaften des Wiederholungssegments festgelegt werden.

6.2 LBox des Verladers

285

Da Wiederholungen über die gleichen Syntaxeigenschaften wie das ursprüngliche NAD-Segment verfügen, ist die Spezifikation eines eigenen Wiederholungs-Strukturelements nicht erforderlich. Es ist lediglich durch die Rolle wdhDurchR festzulegen, dass die Syntaxeigenschaften VER VER der Wiederholung von DFG06 denen von DFG06 entsprechen.

VER  DFG06

ª VER  « DF20 ¬« VER DF21

VER DF22

ª «  « « «¬ ª  « ¬«

ª VER DF23  « «¬

ªhatSE .DF VER Š hatSE .DFVER Š º 20 21 R R « » VER VER «hatSER .DF22 » Š hatSER .DF23 Š « » « 1 hatLfdNrR .^06` Š 1 zkStartT .^NAD  CN` Š » » « VER « 1 zkEndeT .^' ` Š 1 seGleichEndeR .DF23 Š » « VER » «¬ 1 optionalR .^falsch` Š 1 wdhDurchR .DFG06 »¼ 1 hatLfdNrR .^20` Š 1 zkStart A .^  ` Š 1 zkEndeA .^` Šº » VER 1 endeGleichStartR .DF21 Š 1 optional R .^falsch` Š ¼» 1 hatLfdNrR .^21` Š 1 1 1 1

1 zkStartT .^` Š

1 zkEndeT .^` Šº » Š » » VER Š 1 optionalR .^falsch` endeGleichStartR .DF22 »¼ hatLfdNrR .^22` Š 1 zkStartT .^` Š 1 zkEndeT .^` Šº » VER Š 1 optional R .^falsch` endeGleichStartR .DF21 ¼» VER endeGleichStartR .DF20

1 hatLfdNrR .^23` Š 1 optionalR .^falsch` Š

1 zkStartT .^` Š 1

1 zkEndeT .^' ` Šº » »¼

VER seGleichEndeR .DFG06

Axiom 62: Datenfeldgruppe 06 mit zugehörigen Datenfeldern (VER-Ontologie)

Datenfeldgruppe 07 (Segment GID) weist keine Besonderheiten auf. Dieses Segment enthält Details der zu transportierenden Ware.

286

6 Anwendungsbeispiel

VER  DFG07

ª VER  « DF24 ¬« VER DF25

ª «  « « ¬«

VER VER ªhatSER .DF24 º Š hatSER .DF25 Š « » « 1 hatLfdNrR .^07` Š 1 zkStartT .^GID ` Š » « » zkEnde . ' Š 1 T ^` « » « » VER ¬ 1 seGleichEndeR .DF25 Š 1 optionalR .^falsch`¼ 1 hatLfdNrR .^24` Š 1 zkStartT .^` Š 1 zkEndeT .^:` Š º » VER Š 1 optionalR .^falsch` 1 endeGleichStartR .DF25 ¼»

1 hatLfdNrR .^25` Š

1 zkStartT .^:` Š

1 optionalR .^falsch` Š VER 1 endeGleichStartR .DF24 Š

1 zkEndeT .^` ' Š

º » » »  VER 1 seGleichEndeR .DFG07 ¼»

Axiom 63: Datenfeldgruppe 07 mit zugehörigen Datenfeldern (VER-Ontologie)

Abschließend soll noch das Segment UNT syntaktisch spezifiziert werden. Das Segment UNT gehört zum Kopfteil. Da sich der Kopfteil physisch an zwei unterschiedlichen Stellen befindet, ist für jedes dieser Stücke aus Syntaxsicht die Definition einer eigenen Datenfeldgruppe erforderlich. Alternativ wäre auch denkbar, neben dem Kopfteil die Spezifikation von Fußteilen o.ä. vorzusehen.

VER Kopf02 

ª VER DF28  « «¬ VER DF29

ª «  « « «¬

VER VER ª hatSER .DF28 º Š hatSER .DF29 Š « » « 1 hatLfdNrR .^02` Š 1 zkStartT .^UNT ` Š » « » « 1 zkEndeT .^' ` Š » « » VER seGleichEnde .DF optional . falsch Š 1 1 ^ ` R R 29 ¬ ¼ 1 hatLfdNrR .^28` Š 1 zkStartT .^` Š 1 zkEndeT .^` Šº » VER 1 endeGleichStartR .DF29 Š 1 optionalR .^falsch` »¼

1 hatLfdNrR .^29` Š

1 zkStartT .^` Š

1 optional R .^falsch` Š VER 1 endeGleichStartR .DF28 Š

1 zkEndeT .^' ` Š º » » »  VER 1 seGleichEndeR .Kopf02 »¼

Axiom 64: Kopfteil 02 und zugeordnete Datenfelder (VER-Ontologie)

6.2 LBox des Verladers

287

6.2.4 Semantikebene 6.2.4.1 Nachricht "Transportdienstleistung"

Es soll nun zunächst die Nachrichtenbedeutung spezifiziert werden. Der Konzeptklassenname der Bedeutungseinheit, die die in Abbildung 38 dargestellte EDIFACT-Nachricht repräsentiert, lautet "Transportdienstleistung". Eine Nachricht bildet die inhaltliche Klammer um alle Bedeutungseinheiten, die Datenfeldern oder Datenfeldgruppen zugeordnet sind. Nachrichtenköpfe und Positionsteile besitzen keine eigene Bedeutung, folglich werden den zugehörigen Transportcontainern keine Bedeutungseinheiten zugeordnet. Eine Besonderheit ist bei der Datenfeldgruppe 01 zu berücksichtigen. Der hier notierte Code "335" weist zwar auf die Nachrichtenbedeutung hin. Diese wird jedoch in IDI-Ontologien als Merkmal der Nachricht spezifiziert. Somit enthält diese Datenfeldgruppe keine semantikrelevanten Repräsentationsinhalte. Generell ist zu berücksichtigen, dass für Bedeutungseinheiten von Sendenachrichten keine Geschäftsdatenstrukturen im Sinne von Abschnitt 4.3.3.5 definiert werden müssen. Die Spezifikation Regulärer Ausdrücke macht nur bei Empfangsnachrichten Sinn. Die unten dargestellte mereologische Struktur der Nachrichteninhalte wurde aus der EDIFACT-Syntaxstruktur abgeleitet. Diese mereologische Struktur spezifiziert implizit die Bedeutung der enthaltenen Konzeptklassen und trägt somit auch zur Semantikspezifikation der Nachricht "Transportdienstleistung" bei.

288

6 Anwendungsbeispiel Transportdienstleistung

Entladedatum

Ladedatum

Ladeort

Entladeort

Entladetag

Ladetag

Ladename

Entladename

Entlademonat

Lademonat

Ladestraße

Entladestraße

Entladejahr

Ladejahr

LadePLZ

EntladePLZ

Ladestadt

Entladestadt

Transportmittel

Ladung

Anzahl Packmittel

Abbildung 41: Mereologischer Kontext der Konzeptklasse "Transportdienstleistung"

Bei der Spezifikation des taxonomischen Kontextes kann nicht auf eine vorgegebene Struktur zurückgegriffen werden, wie dies beim mereologischen Kontext der Fall ist. Die Bestimmung des taxonomischen Kontextes unterliegt also der persönlichen Kreativität und den persönlichen Vorstellungen der Ontologie-Entwickler. Es sei beispielhaft ein taxonomischer Kontext für die Konzeptklasse TransportdienstleistungVER dargestellt. Transaktion

Dienstleistung

Transportdienstleistung

Ladungsverkehr

Stückgutverkehr

Schüttgutverkehr

Abbildung 42: Taxonomischer Kontext der Konzeptklasse "Transportdienstleistung"

6.2 LBox des Verladers

289

Bei der formalen Spezifikation mereologischer und taxonomischer Kontexte ist zu beachten, dass für jede Konzeptklasse ausschließlich deren direkte Vorfahren und Nachkommen berücksichtigt werden. So ist zwar im taxonomischen Kontext der Konzeptklasse TransportdienstleistungVER die Konzeptklasse DienstleistungVER zu finden, nicht jedoch die Konzeptklasse TransaktionVER . Diese wird im taxonomischen Kontext der Konzeptklasse DienstleistungVER spezifiziert. TransportdienstleistungVER  ªhatBER .NachVER Š º « » VER VER «hatKompR .Ladedatum » Š hatKompR .Entladedatum Š « » «hatKompR .LadeortVER Š hatKompR .EntladeortVER Š » « » VER VER Š hatKompR .Transportmittel Š «hatKompR .Ladung » « VER VER » Š hyperVonR .Stückgutverkehr Š» «hyperVonR .Ladungsverkehr « VER VER »  Š 1 hyperVonR .Dienstleistung ¬hyperVonR .Schüttgutverkehr ¼ Axiom 65: Konzeptklasse "Transportdienstleistung" (VER-Ontologie)

Die erste Zeile des Definiens ordnet die Bedeutungseinheit dem Strukturelement NachVER zu. Die folgenden beiden Zeilen spezifizieren den mereologischen, die letzten beiden Zeilen den taxonomischen Kontext. 6.2.4.2 Bedeutungseinheit "Transportmittel"

Die Bedeutungseinheit "Transportmittel" repräsentiert die Semantik der auf Syntaxebene präsentierten Datenfeldgruppe 02. Die in der Datenfeldgruppe 02 enthaltenen Codes sagen aus, dass es sich bei dem nachgefragten Transport um einen inländischen Straßentransport handelt. Zumindest die Eigenschaft des Inlandstransports erfordert allerdings keine explizite Repräsentation; dieser Sachverhalt ergibt sich implizit aus dem Lade- und Entladeort. Die Anforderung an das Transportmittel – im konkreten Fall wird durch den Code in Datenfeld 09 ein LKW verlangt – lässt sich nicht implizit ableiten und muss daher als Konzeptklasse explizit repräsentiert werden. Allerdings transportiert das betreffende Feld lediglich einen Code, der eine Eigenschaft der begleitenden Geschäftsdaten spezifiziert.

290

6 Anwendungsbeispiel

Somit ist es erforderlich, die Konzeptklasse TransportmittelVER als codiert zu markieren und die Zeichenkette "LKW" als Klartext zu deklarieren. Hierzu wird die Rolle hatKlartextR benötigt. Ist für eine Bedeutungseinheit, die mit einem Strukturelement verbunden ist, ein Klartext definiert, so wird bei der Transformation der Geschäftsdaten in die Empfängersyntax der Code durch den Klartext substituiert. Eine solche Ersetzung ist erforderlich, da nicht sicherzustellen ist, dass der Empfänger den Code eindeutig interpretieren kann. Die Konzeptklasse TransportmittelVER weist eine mereologische Beziehung auf: sie ist Meronym der Konzeptklasse TransportdienstleistungVER . Es sei nun der taxonomische Kontext der Konzeptklasse "Transportmittel" zunächst grafisch dargestellt. Fahrzeug

motorisiertes Fahrzeug

Transportmittel

LKW

Zug

Schiff

Abbildung 43: Taxonomischer Kontext der Konzeptklasse "Transportmittel"

Schließlich sei die Konzeptklasse "Transportmittel" auch formal spezifiziert.

6.2 LBox des Verladers

TransportmittelVER

291

VER ª 1 hatBER .DF09 Š 1 codiertR .^wahr ` Š º « » « 1 hatKlartextR .^LKW ` Š » « »  VER Š » « 1 hatKompR .Transportdienstleistung  « » VER Š hyperVonR .ZugVER Š» «hyperVonR .LKW « » VER Š «hyperVonR .Schiff » « »  VER ¬ 1 hyperVonR .motorisiertes Fahrzeug ¼

Axiom 66: Konzeptklasse "Transportmittel" (VER-Ontologie)

6.2.4.3 Bedeutungseinheit "Ladedatum"

Die

wichtigste

semantische

Eigenschaft

der

Konzeptklasse

LadedatumVER besteht darin, eine Spezialisierung der Konzeptklasse DatumIDI zu sein. Durch diese semantische Eigenschaft wird der Kreis

möglicher Mapping-Kandidaten bereits deutlich eingeschränkt. Die der Bedeutungseinheit "Ladedatum" zugeordnete Datenfeldgruppe VER transportiert – neben den Angaben zu Tag, Monat und Jahr – DFG03 zwei Codes: Code "189" gibt an, dass hier ein Ladedatum enthalten ist; Code "2" informiert über das Format der Datumsangabe. Das Format der Datumsangabe hat keinen semantischen Bezug. Entsprechend besteht hierzu kein semantischer Repräsentationsbedarf. Der Code "189" wird in EDIFACT zur semantischen Spezifikation der Datumsangabe eingesetzt. Eine Klartextangabe wie bei der Konzeptklasse TransportmittelVER ist nicht möglich, da der Code im vorliegenden Fall nicht einen Teil des Geschäftsdatenstroms substituiert, sondern die Bedeutung der gesamten Datenfeldgruppe verschlüsselt darstellt. Die Bedeutung der Datenfeldgruppe wird durch die Konzeptklasse LadedatumVER repräsentiert. Aus der Semantikperspektive ergibt sich daher für das den Code 189 transportierende Datenfeld kein weiterer Repräsentationsbedarf. Eine Taxonomiespezifikation erscheint für die Bedeutungseinheit LadedatumVER wenig sinnvoll, da sich das Realweltphänomen "Ladedatum" kaum sinnvoll generalisieren oder spezialisieren lässt.

292

6 Anwendungsbeispiel

Es wird vorgeschlagen, die semantische Definition des Konzepts "Ladedatum" auf eine umfassende Definition möglicher Synonyme zu stützen. Als Synonyme seien genannt: ƒ Verladedatum, Bunkerdatum, Beladedatum, Aufladedatum.

Es sei nun die Konzeptklasse LadedatumVER formal definiert.

LadedatumVER

VER ªDatumIDI Š 1 hatBER .DFG03 Š « VER « hatKompR .Ladejahr Š «  « 1 hatKompR .TransportdienstleistungVER Š  «« hatKomp .LadetagVER Š R « VER  hatKomp Š « R .Lademonat « «hatSynonym . ­®Verladedatum, Bunkerdatum, R «¬ ¯Beladedatum, Aufladedatum

º » » » » » » » » » ½» ¾» ¿¼

Axiom 67: Konzeptklasse "Ladedatum" (VER-Ontologie)

Die semantische Spezifikation der Konzeptklassen LadetagVER , Lademonat VER und Ladejahr VER

kann auf die Definition von jeweils zwei Beziehungen beschränkt bleiben. Ihre Bedeutung ergibt sich zum einen daraus, dass sie Spezialisierungen der Konzeptklassen Tag IDI , Monat IDI und Jahr IDI sind. Zum anderen wird ihre Bedeutung durch die Semantikspezifikation ihres Holonyms, also der Konzeptklasse "Ladedatum", determiniert. § Tag IDI Š 1 hatKompR .LadedatumVER Š · ¸ LadetagVER  ¨ ¨ 1 hatBE  .DF VER ¸ R 10 © ¹ § Monat IDI Š 1 hatKompR .LadedatumVER Š · ¸ Lademonat VER  ¨ ¨ 1 hatBE  .DF VER ¸ R 11 © ¹ § Jahr IDI Š 1 hatKompR .LadedatumVER Š · ¸ Ladejahr VER  ¨ ¨ 1 hatBE  .DF VER ¸ R 12 © ¹ Axiom 68: Konzeptklassen "Ladetag", "Lademonat", "Ladejahr" (VER-Ontologie)

6.2 LBox des Verladers

293

6.2.4.4 Bedeutungseinheit "Entladedatum"

Die ontologische Spezifikation der Konzeptklasse EntladedatumVER unterscheidet sich nur geringfügig von der der Konzeptklasse VER zugeordnet, die LadedatumVER . Sie ist der Datenfeldgruppe DFG04 ebenfalls über einen Code verfügt. Die Zeichenkette "233" gibt an, dass es sich bei der Konzeptklasse um ein Entladedatum handelt. Auch hier besteht die Funktion des Codes darin, die Semantik der Datenfeldgruppe zu verschlüsseln. Die semantische Definition der Konzeptklasse EntladedatumVER stützt sich – neben einer Spezifikation des mereologischen Kontextes – auf eine umfassende Definition der möglichen Synonyme. Mögliche Synonyme sind die Zeichenketten "Entladedatum", "Abladedatum", "Ausladedatum" und "Löschdatum".

EntladedatumVER

VER ªDatumIDI Š 1 hatBER .DFG04 Š « VER «hatKompR .Entladejahr Š « « 1 hatKompR .TransportdienstleistungVER Š  ««hatKomp .EntladetagVER Š R « VER hatKomp  Š « R .Entlademonat « «hatSynonym . ­® Abladedatum, Ausladedatum, R «¬ ¯Löschdatum

º » » » » » » » » » ½» ¾» ¿¼

Axiom 69: Konzeptklasse "Entladedatum" (VER-Ontologie)

Auch die Meronyme des Entladedatums bedürfen einer Semantikdefinition.

294

6 Anwendungsbeispiel §Tag IDI Š 1 hatKompR .EntladedatumVER Š · ¸ EntladetagVER  ¨ ¨ 1 hatBE  .DF VER ¸ R 13 © ¹ § Monat IDI Š 1 hatKompR .EntladedatumVER Š · ¸ Entlademonat VER  ¨ ¨ 1 hatBE  .DF VER ¸ R 14 © ¹ § Jahr IDI Š 1 hatKompR .EntladedatumVER Š · ¸ Entladejahr VER  ¨ ¨ 1 hatBE  .DF VER ¸ R 15 © ¹

Axiom 70: Konzeptklassen "Entladetag", "Entlademonat" und "Entladejahr" (VER-Ontologie)

6.2.4.5 Bedeutungseinheiten "Ladeort" und "Entladeort"

Die beide Bedeutungseinheiten LadeortVER und EntladeortVER stellen Spezialisierungen der Konzeptklasse AdresseIDI dar. Somit steht die grundlegende Bedeutung beider Konzeptklassen fest, lediglich ihre inhaltliche Spezialisierung ist festzulegen. Die zu beiden Bedeutungseinheiten gehörenden Geschäftsdatenströme werden in den Datenfeldgruppen 05 und 06 transportiert. Die Datenfeldgruppe 05 verfügt über ein Feld, das einen Code ("CZ") transportiert. Dieser Code wird in EDIFACT zur semantischen Spezifikation der Geschäftsdaten eingesetzt. Da die Semantikrepräsentation in IDI-Ontologien nicht durch Codes, sondern ontologische Eigenschaften erfolgt, ist dem betreffenden Strukturelement keine Bedeutungseinheit zuzuordnen. Wie Abbildung 41 zeigt, besitzen die Konzeptklassen LadeortVER und EntladeortVER jeweils vier Meronyme. Die Bedeutung der einzelnen Meronyme ergibt sich zum einen daraus, dass sie Spezialisierungen der Konzeptklassen NameIDI , StraßeIDI , Hausnummer IDI , PLZ IDI und Ort IDI sind. Zum anderen soll die Art der Spezialisierung auf der Ebene ihrer Homonyme, also der Konzeptklassen LadeortVER und EntladeortVER , definiert werden. Analog zu den oben spezifizierten Datumsangaben wird vorgeschlagen, die semantische Spezifikation dieser Konzeptklasse auf die Definition möglicher Synonyme zu beschränken. Die Synonyme sind den nun folgenden formalen Definitionen zu entnehmen.

6.2 LBox des Verladers

295

LadeortVER  ª§ AdresseIDI Š 1 hatBE  .DFGVER Š · º R 05 «¨ ¸ » «¨ 1 hatKompR .TransportdienstleistungVER Š ¸ » «¨ ¸ Š» «¨ hatKompR .LadenameVER Š hatKompR .LadestraßeVER Š ¸ » «¨ ¸ » ¸ » «¨© hatKompR .LadePLZVER Š hatKompR .LadeStadtVER ¹ « » ­Ladestelle, Ladeplatz, Ladestandort, ½ « » °Ladestadt, ° « » ° ° « » °Beladeort, Beladestelle, Beladeplatz, ° « » ¾ «hatSynonymR . ® » °Beladestandort, Beladestadt, ° « » °Ladeadresse, Beladeadresse, ° « » ° ° « » ¯Versandadresse ¿ ¬ ¼ Axiom 71: Konzeptklasse "Ladeort" (VER-Ontologie)

In der Ontologie des Verladers sind Ladestraße und Hausnummer zu einer Konzeptklasse LadestraßeVER zusammengefasst. 1 hatKompR .LadeadresseVER  LadestraßeVER   StraßeIDI Š 1 hatKompR .LadeadresseVER LadePLZVER   PLZ IDI Š 1 hatKompR .LadeadresseVER LadeStadtVER   Stadt IDI Š 1 hatKompR .LadeadresseVER LadenameVER  NameIDI Š

Axiom 72: Konzeptklassen "Ladename", "Ladestraße", "LadePLZ" und "Ladestadt" (VER-Ontologie)

Die Konzeptklasse EntladeortVER verfügt über die gleiche Struktur wie die Konzeptklasse Ladeort IDI .

296

6 Anwendungsbeispiel EntladeortVER  ª§ AdresseIDI Š 1 hatBE  .DFGVER Š · º R 06 «¨ ¸ » «¨ 1 hatKompR .TransportdienstleistungVER Š ¸ » «¨ ¸ Š» «¨ hatKompR .EntladenameVER Š hatKompR .EntladestraßeVER Š ¸ » «¨ ¸ » ¸ » «¨© hatKompR .EntladePLZVER Š hatKompR .EntladeStadtVER ¹ « » ­Entladestelle, Entladeplatz, Entladestandort, ½ « » °Entladestadt, Abladestelle, Abladeplatz, ° « » ° ° « » ° Abladestandort, Abladestadt, Ausladestelle, ° « » «hatSynonymR . ® Ausladeplatz, Ausladestandort, Ausladestadt ¾ » ° ° « » ° Abladeadresse, Empfangsadresse, ° « » ° ° « » ¯Empfängeradresse ¿ ¬ ¼

Axiom 73: Konzeptklasse "Entladeort" (VER-Ontologie)

Auch im meronymen Kontext der Konzeptklasse EntladeortVER sind Straße und Hausnummer zu einer Konzeptklasse zusammengefasst und werden gemeinsam durch die Konzeptklasse EntladestraßeVER repräsentiert. 1 hatKompR .EntladeadresseVER  EntladestraßeVER   StraßeIDI Š 1 hatKompR .EntladeadresseVER EntladePLZVER   PLZ IDI Š 1 hatKompR .EntladeadresseVER EntladeStadtVER   Stadt IDI Š 1 hatKompR .EntladeadresseVER EntladenameVER  NameIDI Š

Axiom 74: Konzeptklassen "Entladename", "Entladestraße", "EntladePLZ" und "Entladestadt" (VER-Ontologie)

6.2.4.6 Bedeutungseinheit "Ladung"

Die Bedeutungseinheit "Ladung" als Semantik-Pendant der Datenfeldgruppe 07 enthält ladungsrelevante Angaben, nämlich das Packmittel und die Anzahl der Packungseinheiten. Sie besitzt als Meronyme die Konzeptklassen "Anzahl" und "Packmittel". Es sei nun zunächst der taxonomische Kontext grafisch dargestellt.

6.2 LBox des Verladers

297 Artefakt

Ware

Ladung

Abbildung 44: Taxonomischer Kontext der Konzeptklasse "Ladung"

Die formale Semantikspezifikation der Konzeptklasse LadungVER stützt sich auf den taxonomischen und mereologischen Kontext sowie eine Synonymenliste. LadungVER  VER ª 1 hatBER .DFG07 Š 1 hatKompR .TransportdienstleistungVER Šº « » «hatKompR .Anzahl IDI Š hatKompR .Packmittel IDI Š » « »  VER « 1 hyperVonR .Ware » Š « » ­Ladungsangaben, Ladungsdetails, ½ « » °Ladungsinformationen, ° « » ° ° «hatSynonymR . ® » ¾ « » °Frachtangaben, Frachtdetails, ° « » ° ° Frachtinformationen ¯ ¿ ¬ ¼

Axiom 75: Konzeptklasse "Ladung" (VER-Ontologie)

Die Konzeptklasse Anzahl VER wird semantisch maßgeblich durch die ihr zugeordnete Maßeinheit ^Stück ` spezifiziert. Darüber hinaus erleichtert eine Liste möglicher Synonyme die Interpretation dieser Konzeptklasse. AnzahlVER

VER ª 1 hatBER .DF24 º Š 1 hatKompR .LadungVER Š « »  « 1 hatMaßeinheitR .^Stück ` Š » « » hatSynonymR .^Zahl, Stückzahl, Menge, Mengenangabe`» ¬« ¼

Axiom 76 Konzeptklasse "Anzahl" (VER-Ontologie)

Die Individuen der Konzeptklasse PackmittelVER geben an, auf welche Verpackungseinheit sich die oben spezifizierte Stückzahl bezieht. Es sei

298

6 Anwendungsbeispiel

zunächst der taxonomische Kontext der Konzeptklasse Packmittel VER grafisch dargestellt. Mittel

Aggregationsmittel

Packmittel

Abbildung 45: Taxonomischer Kontext der Konzeptklasse "Packmittel"

Die Synonyme der Konzeptklasse sind der formalen Definition zu entnehmen.

PackmittelVER

VER ª 1 hatBER .DF25 º Š « »  VER « 1 hatKompR .Ladung » Š « »  « 1 hyperVon  .AggregationsmittelVER Š » R « » ­Verpackungseinheit , ½» «  hatSynonym . ¾» R ® « ¯Packstück ,Versandverpackung ¿ ¼ ¬

Axiom 77: Konzeptklasse "Packmittel" (VER-Ontologie)

6.3 LBox des Fuhrunternehmers 6.3.1 XML-Beispielnachricht 6.3.1.1 Grundlagen XML

Die Zielsetzung dieses Abschnitts besteht darin, diejenigen Merkmale von XML darzustellen, die für das Verständnis der unten gezeigten Bei-

6.3 LBox des Fuhrunternehmers

299

spielnachricht erforderlich sind. Eine weitergehende Einführung zu XML ist in der entsprechenden Literatur zu finden.318 XML-Dokumente besitzen eine baumartige Struktur, ihre Elemente sind also hierarchisch in Form von Wurzelelementen, Blättern und Zweigen angeordnet. Hierdurch entsteht die logische Struktur eines XMLDokuments.319 Elektronische Geschäftsnachrichten im XML-Format bestehen aus Bezeichnern und den eigentlichen Geschäftsinhalten. Bezeichner in XMLDateien werden auch "Markups" genannt. Sie werden durch das Kleinerals- ("") begrenzt.320 Sie können als Etikett oder Überschrift für die markierte Zeichenkette interpretiert werden. In der Regel wird jede Geschäftsdateneinheit von einem Start- und einem Ende-Markup eingeschlossen. Da Markups auch schachtelbar sind, wird das Ende-Markup eindeutig durch einen Slash ("/") nach dem Kleiner-als-Zeichen markiert. Eine beispielhafte Geschäftsdateneinheit und ihr Transportcontainer könnten also in XML das folgende Aussehen besitzen: 18.12.2009

In dem oben angegebenen Beispiel markiert die Zeichenkette das Start-Markup, das Ende-Markup. Zwischen den Markups befindet sich in diesem Fall eine Geschäftsdateneinheit. Durch die Schachtelbarkeit von XML-Markups entsteht die für XMLDokumente typische Baumstruktur. XML ist "[...] ein Werkzeugkasten für das Schaffen, Gestalten und Verwenden von Markup-Sprachen [...]."321 Gegenstand einer solchen Sprache wäre bspw. die Definition der zulässigen Markups.

318 319 320 321

Vgl. z.B. Ray 2004; Goldfarb, Prescod 1999. Vgl. Goldfarb, Prescod 1999, S. 57. Vgl. Goldfarb, Prescod 1999, S.62. Ray 2004, S. XI.

300

6 Anwendungsbeispiel

Als Vorteil von XML in Bezug auf den elektronischen Geschäftsdatenaustausch ist vor allem die intuitive Erfassbarkeit der Bedeutung einzelner Elemente zu nennen, die sich aus der Verwendung aussagekräftiger Markup-Bezeichner ergeben kann. 6.3.1.2 Beispielnachricht

Die im Folgenden präsentierte Beispielnachricht zeigt die in Abbildung 38 dargestellte EDIFACT-Nachricht aus der Empfängerperspektive, nachdem sie durch den FUH-Agenten transformiert wurde. Die Anwendungssysteme des Empfängers benötigen eine XML-basierte Syntax als Input. Die von VER-Agent gesendete und von FUH-Agent empfangene Laderaumnachfrage muss also von FUH-Agent in die unten gezeigte Syntax transformiert werden, bevor eine Weiterverarbeitung durch die lokalen Anwendungen möglich ist. Inhaltlich weist die Nachrichtenstruktur des Fuhrunternehmens zu der des Verladers zwei Abweichungen auf. Zum einen ist hier ein Feld für das Ladungsgewicht vorgesehen. Da der Verlader eine solche Information nicht liefert, kann Kommunikation nur stattfinden, wenn dieses Feld in der Ontologie des Fuhrunternehmens als fakultativ markiert ist. Fehlt die Information über das Ladegewicht in einer empfangenen Nachricht, so bleibt das entsprechende Feld in der XML-Datei leer. Zum anderen sieht die Empfangsnachricht des Fuhrunternehmens keine beliebige Wiederholbarkeit der Empfangsadressen vor. Hier sind genau drei mögliche Empfangsadressen vorgesehen, wobei nur die erste Empfangsadresse obligatorisch zu füllen ist. Es sei nun die Empfangsnachricht dargestellt. LKW Palette <Stückzahl>5 18 11 2008 20 11

6.3 LBox des Fuhrunternehmers

301

2008 Produktion GmbH Senderstr. 12 12345 Sendestadt <Empfangsadresse 1> <Empfangsname1>Vertrieb1 GmbH <Empfangsstraße1>Empfängerstr. <Empfangshausnummer1>28 <EmpfangsPLZ1>67899 <Empfangsort1>Empfangstadt <Empfangsadresse 2> <Empfangsname2>Vertrieb2 GmbH <Empfangsstraße2>Empfängerstr. <Empfangshausnummer2>45 <EmpfangsPLZ2>67899 <Empfangsort2>Empfangstadt <Empfangsadresse 3> <Empfangsname3> <Empfangsstraße3> <Empfangshausnummer3> <EmpfangsPLZ3> <Empfangsort3>

6.3.2 Interaktionsebene: Protokoll "Laderaumnachfrage" 6.3.2.1 Informale Protokollspezifikation

Das nun zu spezifizierende Protokoll wird aus der Sicht eines Fuhrunternehmens definiert, das Nachfragen nach Transportkapazitäten empfangen möchte. Das Fuhrunternehmen fungiert dabei nicht als Initiator des Kommunikationsprozesses, sondern wartet auf Protokollangebote von Verladern. Das unten dargestellte Protokoll ist Bestandteil der FuhrunternehmerOntologie FUH . Somit verfügen alle Konzeptklassen dieser LBox über den Hochindex "FUH".

302

6 Anwendungsbeispiel Fuhrunternehmen

Verlader

SV01FUH



ProtOffer

SV02FUH



ProtReject

xo SV03FUH



ProtAccept frühestens 20.12.2008

SV04FUH

Transport

Requestive

SV05FUH



Rejective

nu SV06FUH

Transport

Offer

SV07FUH



Rejective spätestens 28.12.2008

nu SV08FUH



Acceptance

Abbildung 46: Protokoll "Laderaumnachfrage" aus der FuhrunternehmerPerspektive

Bei der Protokollspezifikation des vorliegenden Anwendungsbeispiels wurde implizit angenommen, dass die Initiative zur Kommunikation von dem produzierenden Verladerunternehmen ausgeht. Ebenso hätte jedoch auch ein Protokoll definiert werden können, in dem der FUHAgent die Kommunikationsbeziehung initiiert. Das oben dargestellte Protokoll ist zu dem in Abbildung 39 gezeigten Protokoll des Verladers kompatibel. Allerdings bestehen einige Unterschiede, auf die bei der Verschmelzung beider Protokolle zu achten ist. So verfügt das Fuhrunternehmer-Protokoll über keine relativen, sondern ausschließlich über absolute Zeitbezüge. Zudem werden z.T andere logische Bezüge zwischen den Sendevorgängen verwendet.

6.3 LBox des Fuhrunternehmers

303

6.3.2.2 Formale Protokollspezifikation

Das oben grafisch gezeigte Interaktionsprotokoll sei nun auch formal dargestellt. Zunächst wird das Protokoll durch Zuordnung der enthaltenen Sendevorgänge definiert.

LaderaumnachfrageFUH

FUH ªhatSVR .SV01 « FUH «hatSVR .SV03 « FUH  «hatSVR .SV05 « FUH «hatSVR .SV07 « IDI «¬Sequenz

FUH º Š hatSVR .SV02 Š » FUH » Š hatSVR .SV04 Š » FUH Š hatSVR .SV06 Š» FUH » Š hatSVR .SV08 Š» » »¼

Axiom 78: Protokoll "Laderaumnachfrage" (FUH-Ontologie)

Bei den Sendevorgängen, die durch den FUH-Agenten gesendet oder empfangen werden sollen, ist als Bildmenge der Rollen "hatSender" bzw. "hatEmpfänger" das Individuum ^FUH-Agent ` vorgesehen. Alle anderen, ex ante unbekannten, Sender und Empfänger werden durch die allgemeine Konzeptklasse Agent IDI repräsentiert. Es besteht die Möglichkeit, die Liste der gewünschten oder akzeptierten Kommunikationspartner durch die Formulierung einer abgeschlossenen Klasse einzugrenzen. ª FUH SV01 ‹« «¬ ª « FUH SV02 ‹« « « ¬ ª « FUH SV03 ‹« « « ¬

1 hatEmpfängerR .^FUH-Agent ` Šº » hatIlloR .^ProtOffer ` »¼ hatSenderR .^FUH-Agent ` Š 1 hatEmpfängerR .Agent IDI Šº » FUH » hatIlloR .^ProtReject ` Š 1 bezugZuR .SV01 Š » FUH » xoderR .SV03 ¼ IDI º hatSenderR .^FUH-Agent ` Š 1 hatEmpfängerR .Agent Š » FUH » hatIlloR .^ProtAccept ` Š 1 bezugZuR .SV01 Š » FUH » xoderR .SV02 ¼

1 hatSenderR .Agent IDI Š 1 1 1 1 1 1 1

Axiom 79: Sendevorgänge zur Protokollvereinbarung (FUH-Ontologie)

Auch in der FUH-Ontologie repräsentieren die Sendevorgänge 04 bis 06 die Buchungsanfrage des Verladers. Teilweise verfügen die Sendevorgänge der FUH-Ontologie jedoch über abweichende Eigenschaften.

304

FUH SV04

FUH SV05

FUH SV06

6 Anwendungsbeispiel 1 hatEmpfängerR .^FUH-Agent ` Šº » 1 frühestT .^20.12.2008` Š » » »¼

ª «  « « «¬

1 hatSenderR .Agent IDI Š

ª «  « « « ¬ ª «  « « « ¬

1 hatSenderR .^FUH-Agent ` Š

1 hatIlloR .^Requestive` Š 1 hatNachR .Transpor t FUH

1 1 1 1 1

1 hatEmpfängerR .Agent IDI Šº » FUH » hatIlloR .^Rejective` Š 1 bezugZuR .SV04 Š » FUH » nundR .SV06 ¼ IDI º hatSenderR .^FUH-Agent ` Š 1 hatEmpfängerR .Agent Š » FUH » hatIlloR .^Offer ` Š 1 bezugZuR .SV04 Š » FUH » nundR .SV05 Š 1 hatNachR .Transport FUH ¼

Axiom 80: Laderaumgesuch eines Verladers mit Reaktionsmöglichkeiten des FUHAgenten (FUH-Ontologie)

In der FUH-Ontologie sind, ebenso wie in der VER-Ontologie, zwei alternative Reaktionen des Verladers auf das Transportangebot vorgesehen. 1 hatEmpfängerR .^FUH-Agent ` Šº » FUH » 1 hatIlloR .^Rejective` Š 1 nundR .SV08 Š » FUH » 1 bezugZuR .SV06 Š 1 spätestT .^28.12.2008` ¼ 1 hatSenderR .Agent IDI Š

FUH SV07

ª «  « « « ¬

FUH SV08

ª «  « « « ¬

1 hatEmpfängerR .^FUH-Agent ` Šº » FUH » 1 hatIlloR .^Acceptance` Š 1 nundR .SV07 Š » FUH » 1 bezugZuR .SV06 Š 1 spätestT .^28.12.2008` ¼ 1 hatSenderR .Agent IDI Š

Axiom 81: Reaktionsmöglichkeiten des Verladers auf ein Transportangebot (FUHOntologie)

6.3.3 Syntaxebene 6.3.3.1 Mereologische Struktur der Beispielnachricht

Auch die dargestellte XML-Nachricht besitzt eine mereologische Struktur. Allerdings ist diese im Vergleich zu der in Abbildung 40 dargestell-

6.3 LBox des Fuhrunternehmers

305

ten Struktur flacher, es fehlen die Kopf- und Positionsteile. Weiterhin werden in dieser XML-Nachricht keine Felder zur Spezifikation eines bestimmten Formatstandards benötigt, wie dies bei EDIFACT-Nachrichten der Fall ist. Da die in der folgenden Abbildung dargestellten Konzeptklassen zur FUH-Ontologie gehören, besitzen sie den Hochindex "FUH". Es gelten die gleichen Vereinbarungen zur grafischen Darstellung der mereologischen Struktur, wie sie in Abschnitt 6.2.3.2 beschrieben wurden. Die mereologische Struktur der XML-Nachricht sieht drei Datenfeldgruppen zur Spezifikation von Empfangsadressen vor. Da die von VERAgent gesendete Nachricht nur über zwei Empfangsadressen verfügt, bleibt der Transportcontainer der dritten Empfangsadresse leer.

306

6 Anwendungsbeispiel NachFUH

LKW

DF01FUH

Palette

DF02FUH



DF03FUH

5

DF04FUH

Verladedatum

FUH DFG01

18

DF05FUH

11

DF06FUH

2008

DF07FUH

Versandadresse

FUH DFG03

FUH DFG05

Empfangsadresse 2

Produktion GmbH

DF11FUH

FUH DF21

Vertrieb2 GmbH

Senderstr.

DF12FUH

FUH DF22

Empfängerstr.

12

DF13FUH

FUH DF23

45

12345

DF14FUH

FUH DF24

67899

Sendestadt

DF15FUH

FUH DF25

Empfangstadt

FUH DFG06

Empfangsadresse 3

Empfangsadresse 1

FUH DFG04

Vertrieb1 GmbH

DF16FUH

FUH DF26



Empfängerstr.

DF17FUH

FUH DF27



20

DF08FUH

28

DF18FUH

FUH DF28



11

DF09FUH

67899

DF19FUH

FUH DF29



DF10FUH

Empfangstadt

FUH DF20

FUH DF30



Abladedatum

2008

FUH DFG02

Abbildung 47: Mereologische Syntaxstruktur der XML-Nachricht

6.3.3.2 Formale Spezifikation

Die ontologische Definition der Syntax von XML-Nachrichten gestaltet sich deutlich einfacher als die von EDIFACT-Nachrichten. Anfang und Ende aller Strukturelemente sind durch eine eindeutige Zeichenkette markiert. Es seien nun zunächst die ersten vier Datenfelder syntaktisch spezifiziert. Diese Datenfelder entsprechen inhaltlich den Datenfeldern 07, 24 und 25 der VER-Ontologie.

6.3 LBox des Fuhrunternehmers ª FUH DF01  « ¬«

1 hatLfdNrR .^01` Š

ª FUH DF02  « ¬«

1 hatLfdNrR .^02` Š

ª FUH DF03  « «¬

1 hatLfdNrR .^03` Š

ª FUH DF04  « «¬

307 1 zkStartT .^` Š

1 zkEndeT .^` Š

º » 1 optional R .^falsch`¼»

1 zkStartT .^` Š º » 1 zkEndeT .^` Š 1 optionalR .^falsch`¼» 1 zkStartT .^` Š º » 1 zkEndeT .^` Š 1 optional R .^wahr `»¼ 1 hatLfdNrR .^04` Š 1 zkStartT .^<Stückzahl>` Š º » 1 zkEndeT .^` Š 1 optional R .^falsch`»¼

Axiom 82: Datenfelder 01 bis 04 (FUH-Ontologie)

Mit Ausnahme des dritten Datenfelds sind alle anderen Felder obligatorisch zu füllen. Verlade- und Abladedatum bestehen aus jeweils einer Datenfeldgruppe. Auch hier erfolgt eine getrennte Syntaxrepräsentation für Tag, Monat und Jahr. Es sei nun die erste Datenfeldgruppe formal dargestellt. Die formale Repräsentation des Abladedatums erfolgt analog. Auf eine separate Darstellung wird daher verzichtet. FUH DFG01

FUH FUH FUH ªhatSER .DF05 Š hatSER .DF06 Š hatSER .DF07 Š «  « 1 hatLfdNrR .^01` Š 1 zkStartT .^` Š « «¬ 1 zkEndeT .^` Š 1 optional R .^falsch`

ª FUH DF05  « «¬ ª FUH  « DF06 ¬«

1 hatLfdNrR .^05` Š

ª FUH  « DF07 ¬«

1 hatLfdNrR .^07` Š

º » » » »¼

1 zkStartT .^ Tag !` Š º » 1 zkEndeT .^` Š 1 optional R .^falsch`»¼ 1 hatLfdNrR .^06` Š 1 zkStartT .^<Monat>` Š º » 1 zkEndeT .^` Š 1 optional R .^falsch`¼» 1 zkStartT .^<Jahr>` Š º » 1 zkEndeT .^` Š 1 optional R .^falsch`¼»

Axiom 83: Datenfeldgruppe 01 mit Datenfeldern (FUH-Ontologie)

Es werden nun die Datenfeldgruppen betrachtet, die Adressen beinhalten. Da die Repräsentationsstruktur bei allen vier Gruppen gleich ist, bleibt die formale Darstellung auf die erste Datenfeldgruppe beschränkt.

308

6 Anwendungsbeispiel

Zu beachten ist allerdings, dass die Datenfeldgruppen 05 und 06 optional zu füllen sind.

FUH DFG03

FUH FUH FUH ªhatSER .DF11 Š hatSER .DF12 Š hatSER .DF13 Š º « » FUH FUH « hatSER .DF14 Š hatSER .DF15 Š 1 hatLfdNrR .^03` Š »  « » « 1 zkStartT .^` Š » « » ¬ 1 zkEndeT .^` Š optional R .^falsch` ¼

ª FUH DF11  « «¬ ª FUH  « DF12 ¬«

1 hatLfdNrR .^11` Š

1 zkStartT .^` Š

ª FUH  « DF13 ¬«

1 hatLfdNrR .^13` Š

1 zkStartT .^` Š

ª FUH  « DF14 «¬

1 hatLfdNrR .^14` Š

ª FUH  « DF15 ¬«

º » 1 zkEndeT .^` Š 1 optional R .^falsch`»¼ 1 hatLfdNrR .^12` Š 1 zkStartT .^<Straße>` Š º » 1 zkEndeT .^` Š 1 optionalR .^falsch` ¼» 1 zkEndeT .^` Š

º » 1 optionalR .^falsch`¼»

1 zkStartT .^` Š º » 1 zkEndeT .^` Š 1 optionalR .^falsch`»¼ 1 hatLfdNrR .^15` Š 1 zkStartT .^` Š º » 1 zkEndeT .^` Š 1 optional R .^falsch`¼»

Axiom 84: Datenfeldgruppe 03 mit Datenfeldern (FUH-Ontologie)

Im Gegensatz zur EDIFACT-Nachricht enthält diese XML-Struktur keine Wiederholungsgruppe zur Spezifikation von Empfängeradressen. Stattdessen werden drei Gruppen für Empfängeradressen fest definiert, von denen allerdings nur die erste gefüllt sein muss.

6.3.4 Semantikebene 6.3.4.1 Nachricht "Transport"

Wie auch bei der Sendenachricht stellt der mereologische Kontext bei Empfangsnachrichten ein wichtiges semantisches Spezifikationsmittel dar. Die folgende Abbildung zeigt die gesamte Mereologie der Nachricht "Transport". Bei der formalen Spezifikation der einzelnen Bedeutungseinheiten werden, wie auch in der VER-Ontologie, nur deren direkte Meronyme berücksichtigt. Die gesamte Mereologie einer Nachricht ergibt

6.3 LBox des Fuhrunternehmers

309

sich aus der Summe der mereologischen Beziehungen ihrer Bedeutungseinheiten. Transport

Abladedatum

Verladedatum

Versandadresse

Empfangsadresse 1

Abladetag

Verladetag

Versandname

Empfangsname1

Ablademonat

Verlademonat

Versandstraße

Empfangsstraße1

Abladejahr

Verladejahr

Versandhausnummer

Empfangshausnummer1

VersandPLZ

EmpfangsPLZ1

Versandort

Empfangsort1

Transportfahrzeug Verpackungs -einheit Ladungsgewicht

Stückzahl

Abbildung 48: Mereologischer Kontext der Nachricht "Transport"

Anhand der dargestellten Mereologie sollen nun einige strukturelle Unterschiede zwischen der Sende- und Empfangsnachricht aufgezeigt werden. In der FUH-Ontologie wird die Empfangsadresse nicht wiederholt. Stattdessen sind physisch drei Datenfeldgruppen zum Transport jeweils einer Empfangsadresse vorgesehen. Auf der Semantikebene ist nur eine Empfangsadresse zu definieren, da die beiden anderen Empfangsadressen keine semantischen Unterschiede zur ersten Empfangsadresse aufweisen. Eine redundante semantische Repräsentation ist somit nicht erforderlich. Ein weiterer Unterschied besteht darin, dass in der FUH-Ontologie eine eigene Bedeutungseinheit zur Repräsentation von Hausnummern vorgesehen ist. Weiterhin sind die Ladungsdetails in dieser Ontologie nicht in einer Datenfeldgruppe zusammengefasst, sondern direkt als Meronyme der Nachricht zugeordnet. Die unten stehende Grafik zeigt den taxonomischen Kontext der Nachrichten-Konzeptklasse Transport FUH .

310

6 Anwendungsbeispiel Ereignis

Bewegung

Transport

Linienverkehr

Ladungsverkehr

Abbildung 49: Taxonomischer Kontext der Nachricht "Transport"

Es folgt eine formale Definition der Konzeptklasse Transport FUH . Transport FUH  ª 1 hatBER .NachFUH Š º « » «hatKompR .Abladedatum FUH Š hatKompR .VerladedatumFUH Š » « » «hatKompR .VersandadresseFUH Š hatKompR .EmpfangsadresseFUH Š » « » FUH FUH Š» Š hatKompR .Verpackungseinheit «hatKompR .Transportfahrzeug « » FUH Š hatKompR .Stückzahl FUH Š «hatKompR .Ladungsgewicht » « » FUH Š hyperVonR .Linienverkehr FUH Š «hyperVonR .Ladungsverkehr » « » 1 hyperVonR .Bewegung FUH »¼ ¬« Axiom 85: Konzeptklasse "Transport" (FUH-Ontologie)

Bei der nun folgenden Semantikspezifikation der FUH-Bedeutungseinheiten kommen Spezifikationsmittel zum Einsatz, die nur bei Empfangsnachrichten sinnvoll verwendet werden können. Hierzu gehören ƒ die Spezifikation der Geschäftsdatenstruktur, um die RA-Relevanz ermitteln zu können sowie ƒ die Spezifikation abgeschlossener Klassen, deren Individuenmengen aus Geschäftsdateneinheiten bestehen.

6.3 LBox des Fuhrunternehmers

311

Ist für die Konzeptklasse einer lokalen Ontologie ein Regulärer Ausdruck oder eine abgeschlossene Klasse definiert, so kann die zusammen mit einer Geschäftsnachricht empfangene Konzeptklasse nur dann semantisch äquivalent zu der lokalen Konzeptklasse sein, wenn der zugehörige Geschäftsdatenstrom der empfangenen Nachricht mit dem Regulären Ausdruck der lokalen Konzeptklasse kompatibel ist oder einem Element der abgeschlossenen Klasse entspricht. 6.3.4.2 Bedeutungseinheit "Transportfahrzeug"

Während in der VER -Ontologie die Anforderung an das zu nutzende Transportmittel codiert wurde, ist eine derartige Verschlüsselung bei der gezeigten XML-Nachricht nicht vorgesehen. Hier muss das Transportfahrzeug "LKW" als Klartext erscheinen. Die Konzeptklasse Transportfahrzeug FUH verfügt lediglich über eine mereologische Beziehung: sie ist ein Meronym der Konzeptklasse Transport FUH . Der in der FUH -Ontologie vorgesehene taxonomische Kontext der Konzeptklasse Transportfahrzeug FUH ist der unten stehenden Abbildung zu entnehmen. Fahrzeug

Motorfahrzeug

Transportfahrzeug

LKW

Zug

Schiff

Abbildung 50: Taxonomischer Kontext der Konzeptklasse "Transportfahrzeug"

Es sei nun die Konzeptklasse Transportfahrzeug FUH auch formal spezifiziert.

312

6 Anwendungsbeispiel

Transportfahrzeug FUH

FUH ª 1 hatBER .DF01 º Š « » « 1 hatKompR .Transport FUH Š » « »  «hyperVonR .LKW FUH Š hyperVonR .Zug FUH Š» « » «hyperVonR .Schiff FUH Š » « »  FUH « 1 hyperVonR .Motorfahrzeug » ¬ ¼

Axiom 86: Konzeptklasse "Transportfahrzeug" (FUH-Ontologie)

6.3.4.3 Bedeutungseinheit "Verpackungseinheit"

Die Konzeptklasse Verpackungseinheit FUH stellt eine abgeschlossene Klasse dar. Sie besteht aus den Individuen ^Palette` und ^Rollbox` . Andere Verpackungseinheiten kann oder will der Fuhrunternehmer nicht transportieren. Eine empfangene Konzeptklasse kann somit nur dann semantisch äquivalent zur Konzeptklasse Verpackungseinheit FUH sein, wenn ihre Geschäftsdateneinheit mit einem der in der abgeschlossenen Klasse definierten Individuen übereinstimmt. Als weiteres semantisches Spezifikationsmittel sollen die Synonyme der Konzeptklasse Verpackungseinheit FUH definiert werden. Verpackungseinheit FUH  FUH ª 1 hatBER .DF02 º Š 1 hatKompR .Transport FUH Š « » «^Palette,Rollbox` Š » « » «¬hatSynonymR .^Packmittel, Packstück,Versandverpackung `»¼

Axiom 87: Konzeptklasse "Verpackungseinheit" (FUH-Ontologie)

Weitere semantische Spezifikationsmittel sind bei dieser Konzeptklasse nicht erforderlich. 6.3.4.4 Bedeutungseinheiten "Ladungsgewicht" und "Stückzahl"

Die Bedeutungseinheit Ladungsgewicht FUH weist eine Besonderheit auf: im Gegensatz zu allen anderen Bedeutungseinheiten ist der dieser Konzeptklasse zugeordnete Transportcontainer als fakultativ gekennzeichnet. Somit muss nicht zwingend eine zu Ladungsgewicht FUH semantisch äquivalente Konzeptklasse aus der VER-Ontologie vorhanden sein.

6.3 LBox des Fuhrunternehmers Da

die

bereits

vorgestellte

313 EDIFACT-Nachricht

über

keine

zu

Ladungsgewicht FUH semantisch äquivalente Bedeutungseinheit verfügt,

bleibt der Transportcontainer der Konzeptklasse Ladungsgewicht FUH zumindest bei der Kommunikation mit VER-Agent leer. Zur semantischen Spezifikation der Konzeptklasse Ladungsgewicht FUH bietet sich die Definition der Geschäftsdatenstruktur sowie der Maßeinheit an. Die Geschäftsdaten dürfen aus Dezimalzahlen bis zu einem Maximalwert von "40" bestehen, wobei maximal zwei Dezimalstellen zulässig sind. Die Maßeinheit wird bei Ladungsgewichten von Lastkraftwagen in Tonnen angegeben. Als weiteres semantisches Spezifikationsmittel soll wieder eine Liste möglicher Synonyme angegeben werden.

Ladungsgewicht

FUH

ª « « «  « « « « «¬

FUH 1 hatBER .DF03 Š

1 1 1 1

º » » hatKompR .Transport FUH Š » reg R .^>1-4 @? >0  9 @^1` >,@>0  9 @^, 2`` Š » » hatSynonymR .^Zuladung ` Š » » hatMaßeinheitR .^t ` »¼

Axiom 88: Konzeptklasse "Ladungsgewicht" (FUH-Ontologie)

Die Bedeutungseinheit Stückzahl FUH gibt die Anzahl der Verpackungseinheiten an, die transportiert werden müssen. Es bietet sich daher an, die Maßeinheit ^Stück ` zu definieren. Die Struktur der Geschäftsdateneinheit muss in diesem Fall nicht spezifiziert werden, da diese Struktur durch die Angabe der Maßeinheit implizit vorgegeben wurde. Als Ergänzung zur Maßeinheit soll auch hier eine Liste möglicher Synonyme definiert werden. Stückzahl FUH

FUH ª 1 hatBER .DF04 Š 1 hatKompR .Transport FUH Š º « »  « 1 hatMaßeinheitR .^Stück ` Š » « » hatSynonymR .^Zahl, Anzahl, Menge, Mengenangabe`» ¬« ¼

Axiom 89: Konzeptklasse "Stückzahl" (FUH-Ontologie)

314

6 Anwendungsbeispiel

6.3.4.5 Bedeutungseinheiten "Verladedatum" und "Abladedatum"

Sowohl bei der Bedeutungseinheit Verladedatum FUH wie auch der Bedeutungseinheit Abladedatum FUH handelt es sich um Spezialisierungen der Konzeptklasse Datum FUH . Auch eine weitere Eigenschaft besitzen beide Konzeptklassen gemeinsam: sie sind Meronyme der Konzeptklasse Transport FUH . Unterschiede ergeben sich jedoch bei den jeweiligen Meronymen. Verladedatum FUH verfügt über die Meronyme x

Verladetag FUH ,

x

Verlademonat FUH ,

x

Verladejahr FUH .

Abladedatum FUH hingegen besitzt die Meronyme x

Abladetag FUH ,

x

Ablademonat FUH ,

x

Abladejahr FUH .

Wie auch in der VER-Ontologie soll sich die semantische Spezifikation von Datumsangaben in der FUH-Ontologie vor allem auf die Definition möglicher Synonyme stützen. Es sei nun zunächst die Konzeptklasse Verladedatum FUH formal definiert.

VerladedatumFUH

FUH ªDatumIDI Š 1 hatBER .DFG01 º Š « » FUH « hatKompR .Verladejahr » Š « » « 1 hatKompR .Transport FUH Š » »  «« hatKomp .Verladetag FUH Š » R « » FUH Š « hatKompR .Verlademonat » « » Ladedatum, Bunkerdatum, ­ ½ «hatSynonym . ® » ¾ R «¬ ¯Beladedatum, Aufladedatum ¿»¼

Axiom 90: Konzeptklasse "Verladedatum" (FUH-Ontologie)

6.3 LBox des Fuhrunternehmers

315

Die Bedeutung der drei Konzeptklassen Verladetag FUH , Verlademonat FUH und Verladejahr FUH ergibt sich zum einen implizit aus ihrer mereologischen Zuordnung zu ihrem Holonym Verladedatum FUH . Zum anderen wird ihre Bedeutung dadurch determiniert, dass sie Spezialisierungen der Konzeptklassen Tag IDI , Monat IDI und Jahr IDI sind. Darüber hinaus ist keine semantische Spezifikation erforderlich. §Tag IDI Š 1 hatKompR .Verladedatum FUH Š · ¸ Verladetag FUH  ¨ ¨ 1 hatBE  .DF FUH ¸ R 05 © ¹ § Monat IDI Š 1 hatKompR .Verladedatum FUH Š · ¸ Verlademonat FUH  ¨ ¨ 1 hatBE  .DF FUH ¸ R 06 © ¹ § Jahr IDI Š 1 hatKompR .Verladedatum FUH Š · ¸ Verladejahr FUH  ¨ ¨ 1 hatBE  .DF FUH ¸ R 07 © ¹ Axiom 91: Konzeptklassen "Verladetag", "Verlademonat" und "Verladejahr" (FUHOntologie)

Die Konzeptklasse Abladedatum FUH

unterscheidet sich von Verladedatum FUH

durch ihre Komponenten und ihre Synonyme.

AbladedatumFUH

FUH ªDatumIDI Š 1 hatBER .DFG02 Š « FUH «hatKompR .Abladejahr Š «  FUH « 1 hatKompR .Transport Š «  «hatKomp .Abladetag FUH Š R « FUH Š «hatKompR .Ablademonat « «hatSynonym . ­®Entladedatum, Löschdatum, R ¯ Ausladedatum ¬«

Axiom 92: Konzeptklasse "Abladedatum" (FUH-Ontologie)

Auch die Bedeutung der drei Konzeptklassen Abladetag FUH , Ablademonat FUH und Abladejahr FUH

º » » » » » » » » » ½» ¾» ¿¼

316

6 Anwendungsbeispiel

ergibt sich implizit aus ihren Hyperonymen und ihren Homonymen. §Tag IDI Š 1 hatKompR .Abladedatum FUH Š · ¸ Abladetag FUH  ¨ ¨ 1 hatBE  .DF FUH ¸ 08 R © ¹ § Monat IDI Š 1 hatKompR .Abladedatum FUH Š · ¸ Ablademonat FUH  ¨ ¨ 1 hatBE  .DF FUH ¸ 09 R © ¹ § Jahr IDI Š 1 hatKompR .Abladedatum FUH Š · ¸ Abladejahr FUH  ¨ ¨ 1 hatBE  .DF FUH ¸ R 10 © ¹ Axiom 93: Konzeptklassen "Abladetag", "Ablademonat" und "Abladejahr" (FUHOntologie)

6.3.4.6 Bedeutungseinheiten "Versandadresse" und "Empfangsadresse 1"

Die grundlegende Bedeutung der beiden Konzeptklassen Versandadresse FUH und Empfangsadresse1FUH

ergibt sich daraus, dass beide Konzeptklassen Spezialisierungen der Konzeptklasse AdresseIDI darstellen. Somit ist lediglich die Art der Spezialisierung zu definieren. Im Gegensatz zu den Adressenangaben in der EDIFACT-Nachricht sehen die beiden genannten Konzeptklassen eine separate Angabe von Straßenbezeichnung und Hausnummer vor. Das Realweltphänomen "Versandadresse" lässt sich kaum sinnvoll spezialisieren. Auch eine Generalisierung erscheint nur wenig praktikabel, nicht zuletzt, da mit der Konzeptklasse AdresseIDI bereits ein generalisierendes Konzept bekannt ist. Für die Konzeptklasse FUH Empfangsadresse1 gelten die gleichen Überlegungen. Technisch gesehen handelt es sich bei den Konzeptklassen Empfangsadresse2 FUH und Empfangsadresse3 FUH

um Wiederholungen der Konzeptklasse Empfangsadresse1FUH . Aus semantischer Perspektive bestehen zwischen diesen Konzeptklassen keine Unterschiede. Es wird somit nur Empfangsadresse1FUH betrachtet.

6.3 LBox des Fuhrunternehmers

317

Ähnlich zum Konzept der Datumsangabe soll die Art der Spezialisierung der Realweltphänomene "Versandadresse" und "Empfangsadresse" auch durch eine Liste möglicher Synonyme angegeben werden. Es sei nun zunächst die Konzeptklasse Versandadresse FUH definiert. VersandadresseFUH  ª§ AdresseIDI Š 1 hatBE  .DFG FUH Š · º R 03 «¨ ¸ » «¨ 1 hatKompR .Transport FUH Š ¸ » «¨ ¸ » «¨ hatKompR .VersandnameFUH Š hatKompR .Versandstraße FUH Š ¸ Š» «¨ ¸ » «¨ hatKompR .VersandPLZ FUH Š hatKompR .VersandStadt FUH ¸ » «¨ ¸ » FUH «¨ hatKompR .VersandHausnummer ¸ » ¹ » «© « » ­Ladestelle, Ladeplatz, Ladestandort, Ladestadt,½ « » °Beladeort, Beladestelle, Beladeplatz, ° ° «hatSynonym . ° » ¾ R ® « » Beladestandort, Beladestadt, ° ° « » °¯Ladeadresse, Beladeadresse, Ladeort °¿ ¼» ¬« Axiom 94: Konzeptklasse "Versandadresse" (FUH-Ontologie)

Die Bedeutung der Meronyme der Konzeptklasse Versandadresse FUH ergibt sich einerseits implizit aus ihrer Zugehörigkeit zu der Konzeptklasse Versandadresse FUH . Andererseits sind die Meronyme Spezialisierungen der Konzeptklassen NameIDI , StraßeIDI , Hausnummer IDI , PLZ IDI und Ort IDI . Die semantische Spezifikation bleibt somit auf die Nennung der generalisierenden Konzeptklasse sowie die Angabe der mereologischen Beziehung zu ihrem Homonym Versandadresse FUH beschränkt.



VersandnameVER  NameIDI Š



VersandstraßeVER  StraßeIDI Š

1 hatKompR .LadeadresseVER



1 hatKompR .LadeadresseVER



§ Hausnummer IDI Š · ¸ Versandhausnummer VER  ¨ ¨ 1 hatKomp  .LadeadresseVER ¸ R © ¹



VersandPLZVER  PLZ IDI Š



VersandStadtVER  Stadt IDI Š

1 hatKompR .LadeadresseVER



1 hatKompR .LadeadresseVER



Axiom 95: Meronyme der Bedeutungseinheit "Versandadresse" (FUH-Ontologie)

318

6 Anwendungsbeispiel

Es verbleibt die Definition der Empfangsadresse und ihrer Meronyme ªEmpfangsadresse1FUH  º « » FUH º» « ª§ AdresseIDI Š 1 hatBER .DFG04 · Š »» ¸ « «¨ »» ¸ « «¨ 1 hatKompR .Transport FUH Š »» ¸ « «¨ »» ¸ « «¨ hatKompR .EmpfangsnameFUH Š »» ¸ « «¨ »» ¸Š « «¨ hatKompR .EmpfangsstraßeFUH Š »» ¸ « «¨ FUH Š »» ¸ « «¨ hatKompR .EmpfangsPLZ »» ¸ « «¨ FUH »» ¸ « «¨ hatKompR .EmpfangsStadt »» « «¨ FUH ¸ ¸ »» « «¨© hatKompR .EmpfangsHausnummer ¹ »» «« ­Entladestelle, Entladeplatz, Entladestandort, ½» » «« °Entladestadt, Abladestelle, Abladeplatz, °» » «« °° °°» » «« « «hatSynonymR . ® Abladestandort, Abladestadt, Ausladestelle, ¾» » «« ° Ausladeplatz, Ausladestandort, Ausladestadt °» » «« ° °» » « «¬ Abladeadresse, Entladeort, Empfängeradresse ° ¯ ¿°»¼ »¼ ¬



EmpfangsnameVER  NameIDI Š

1 hatKompR .LadeadresseVER





1 hatKompR .LadeadresseVER

EmpfangsstraßeVER  StraßeIDI Š



§ Hausnummer IDI Š · ¸ Empfangshausnummer VER  ¨  VER ¨ 1 hatKomp .Ladeadresse ¸ R © ¹



1 hatKompR .LadeadresseVER

EmpfangsPLZVER  PLZ IDI Š EmpfangsStadt

VER



 Stadt

IDI

Š

1



hatKompR .LadeadresseVER



Axiom 96: Konzeptklasse "Empfangsadresse1" und Meronyme (FUH-Ontologie)

6.4 Matchingbeispiele 6.4.1 Protokollmatching Die Zielsetzung des Protokollmatchings besteht darin, den Kompatibilitätsstatus der beiden Protokolle und ihrer Sendevorgänge zu ermitteln. Die zu berücksichtigenden Kompatibilitätsbedingungen wurden in Kapitel 4.4.3.3 definiert. Damit zwei IDI-Agenten Geschäftsdaten austau-

6.4 Matchingbeispiele

319

schen können, müssen sie über kompatible Protokolle verfügen. Protokollkompatibilität setzt laut Bedingung 7 ("Protokollkompatibilität") voraus, dass alle obligatorischen Sendevorgänge der betrachteten Protokolle über genau einen kompatiblen Sendevorgang im Partnerprotokoll verfügen. Als erste Kompatibilitätsbedingung für Sendevorgänge wird in Bedingung 8 ("Gleiche Illokutionen bei Sendevorgangs-Kompatibilität") die Gleichheit der Illokutionen genannt. Diese Kompatibilitätsbedingung ermöglicht bereits in einem ersten Schritt, die Anzahl der Alternativen zur Bildung kompatibler Sendevorgangspaare aus den beiden Protokollen LaderaumnachfrageFUH und LaderaumsucheVER erheblich zu reduzieren. Mit Ausnahme von ^Rejective` ist jede Illokution in den Sendevorgängen der beiden Protokolle nur einmal vorhanden. Als zweite Kompatibilitätsbedingung sei die in Bedingung 9 ("Äquivalente Nachrichten bei Sendevorgangs-Kompatibilität") formulierte Nachrichtenäquivalenz betrachtet. Diese Kompatibilitätbedingung fordert nicht die Äquivalenz sämtlicher Nachrichtenbestandteile; lediglich die die Nachricht repräsentierenden Bedeutungseinheiten müssen inhaltsgleich sein. Diese Kompatibilitätsbedingung ist die einzige, deren Erfüllung erst nach dem ontologischen Matching geprüft werden kann. An dieser Stelle soll von der semantischen Äquivalenz der betreffenden Bedeutungseinheiten ausgegangen werden. Weiterhin ist die Gleichheit der inhaltlichen Bezüge zu untersuchen. Die Prüfung, ob diese Kompatibilitätsbedingung erfüllt ist, soll am Beispiel VER der Konzeptklasse SV05 gezeigt werden.

320 VER SV04

6 Anwendungsbeispiel Transportdienstl. Requestive

VER Rejective SV05

kompatibel

SV04FUH

kompatibel

SV05FUH

nicht kompatibel

SV06FUH

SV07FUH

Transport

Requestive

Rejective

Transport

Offer

Rejective

Abbildung 51: Beispiel für die Kompatibilitätsbedingung "Gleichheit der inhaltlichen Bezüge" VER Die Konzeptklasse SV05 verfügt über die Illokution ^Re jective` . Im

FUH-Protokoll existieren zwei Sendevorgänge mit der gleichen Illokution, die somit als potenzielle Kompatibilitätskandidaten infrage kommen: FUH FUH VER und SV07 . Sendevorgang SV05 bezieht die Sendevorgänge SV05 VER VER sich inhaltlich auf SV04 . SV04 wiederum kann nur kompatibel zu FUH sein, da nur dieser Sendevorgang im FUH-Protokoll über die IlSV04

lokution ^Requestive` verfügt. Somit verbleibt als KompatibilitätskandiVER FUH dat für SV05 ausschließlich der Sendevorgang SV05 , da dieser SenFUH devorgang einen gleichgerichteten inhaltlichen Bezug zu SV04 aufweist.

Die folgende Grafik zeigt die verbliebenen Kompatibilitätskandidaten, nachdem alle Sendevorgangspaare mit ungleichen Illokutionen sowie ungleichen inhaltlichen Bezügen ausgeschlossen wurden. Bereits in diesem Stadium verfügt jeder Sendevorgang, bezogen auf das vorliegende Anwendungsbeispiel, nur noch über jeweils einen Kompatibilitätskandidaten in der Partnerontologie.

6.4 Matchingbeispiele

321

Sendevorgänge der VER-Ontologie VER SV01

Sendevorgänge der FUH-Ontologie SV01FUH



VER ProtReject SV02

SV02FUH

ProtReject

VER ProtAccept SV03

SV03FUH

ProtAccept

VER SV04

SV04FUH

ProtOffer

Transportdienstl. Requestive

VER Rejective SV05

SV05FUH

VER SV06

SV06FUH

Transportdienstl.

Offer

VER Rejective SV07

VER Acceptance SV08

Transport

ProtOffer

Requestive

Rejective Transport

Offer

SV07FUH

Rejective

SV08FUH

Acceptance

Abbildung 52: Kandidaten für kompatible Sendevorgangspaare

Die Sendevorgänge der VER-Ontologie besitzen ausschließlich relative Zeitbezüge, in der FUH-Ontologie sind nur absolute Zeitbezüge definiert. Somit existiert keine Paarung von Sendevorgängen beider Protokolle, bei der beide Sendevorgänge über einen absoluten oder einen relativen Zeitbezug verfügen. Folglich müssen auch die entsprechenden Kompatibilitätsbedingungen, die in Bedingung 10 ("Konsistente Verwendung zweier "genau"-Rollen bei Sendevorgangs-Kompatibilität") bis Bedingung 13 ("Gleiche Ausrichtung relativer Zeitbezüge bei Sendevorgangs-Kompatibilität") formuliert sind, nicht geprüft werden. Zu prüfen ist die Kompatibilität gem. Bedingung 14 ("Mischung relativer und absoluter Zeitbezüge bei Sendevorgangs-Kompatibilität"). In der FUH-Ontologie sind drei Sendevorgänge mit einer absoluten ZeitvorgaFUH be belegt: SV04 darf frühestens am 20.12.2008 gesendet werden, FUH FUH SV07 und SV08 müssen spätestens am 28.12.2008 gesendet worden

sein. Die relativen zeitlichen Bezüge der VER-Ontologie sehen vor, dass VER VER der Sendevorgang SV06 gesendet nach dem Sendevorgang SV04 VER werden darf, erst im Anschluss hieran dürfen die Sendevorgänge SV07 VER und SV08 gesendet werden.

322

6 Anwendungsbeispiel

Die in der FUH-Ontologie durch die absoluten Zeitvorgaben implizit dargestellten relativen Zeitbezüge widersprechen also nicht den in der VER-Ontologie explizit dargestellten relativen Zeitbezügen. Diese Randbedingung ist somit erfüllt. In einem nächsten Schritt ist die Kompatibilität der logischen Verknüpfungen zu prüfen. An zwei Stellen trifft eine xoderR -Rolle der VEROntologie auf eine nundR -Rolle in der FUH-Ontologie. Allerdings besitzen beide Rollen einen gemeinsamen Wahrheitsbereich322. Somit wird die Kompatibilität der betrachteten Sendevorgänge von dieser Randbedingung nicht verletzt. Die in Bedingung 17 geforderte Überschneidung der Individuenmengen der Sender- und Empfängerkonzeptklassen ist bei dem dargestellten Anwendungsbeispiel gegeben. Dies sei anhand der folgenden Tabelle verdeutlicht. Die Tabelle enthält in jeder Zeile eines der in Abbildung 52 identifizierten Sendevorgangspaare. Für jeden Sendevorgang ist angegeben, welche Konzeptklassen in der jeweiligen Ontologie als Sender oder Empfänger vorgesehen sind.

VER-Ontologie

FUH-Ontologie

SV

Sender

VER SV01

^VER-Agent`

Agent

VER SV02

Agent IDI

VER SV03

VER SV04

322

Empfänger IDI

SV

Sender IDI

Empfänger

^FUH-Agent `

FUH SV01

Agent

^VER-Agent `

FUH SV02

^FUH-Agent `

Agent IDI

Agent IDI

^VER-Agent `

FUH SV03

^FUH-Agent `

Agent IDI

^VER-Agent`

Agent IDI

FUH SV04

Agent IDI

^FUH-Agent `

Zur Ermittlung eines gemeinsamen Wahrheitsbereichs vgl. Abschnitt 4.4.3.3.

6.4 Matchingbeispiele

323

VER-Ontologie SV

Sender

FUH-Ontologie Empfänger

SV

Sender

Empfänger

VER SV05

Agent

IDI

^VER-Agent `

FUH SV05

^FUH-Agent `

Agent IDI

VER SV06

Agent IDI

^VER-Agent `

FUH SV06

^FUH-Agent `

Agent IDI

VER SV07

^VER-Agent`

Agent IDI

FUH SV07

Agent IDI

^FUH-Agent `

VER SV08

^VER-Agent`

Agent IDI

FUH SV08

Agent IDI

^FUH-Agent `

Tabelle 26: Sender- und Empfängeragenten von Sendevorgängen

Bei der Gegenüberstellung der jeweiligen Sender- und Empfängerkonzepte ist zu erkennen, dass entweder der Sender oder der Empfänger durch die allgemeine Konzeptklasse Agent IDI repräsentiert wird. Somit verfügen Sender- und Empfängerkonzepte stets über eine gemeinsame Schnittmenge, da die Konzeptklasse Agent IDI die Gesamtheit aller Agentenindividuen repräsentiert. Da alle Sendevorgänge der betrachteten Protokolle über einen kompatiblen Partnersendevorgang verfügen, kann auch die Kompatibilität des Protokolls selbst festgestellt werden. Es seien daher nun abschließend die gemeinsamen Sendevorgänge der betrachteten Protokolle dargestellt. Die Verschmelzungsregeln zur Bildung gemeinsamer Sendevorgänge wurden in Kapitel 4.4.3.4 erarbeitet.

324

6 Anwendungsbeispiel ª «  « « ¬

1 hatSenderR .^VER-Agent ` Š

GEM SV01 &01

1 hatSenderR .^FUH-Agent ` Š

GEM SV02 &02

ª « «  « « « ¬« ª « «  « « « ¬«

1 hatSenderR .^FUH-Agent ` Š

ª « «  « « « ¬«

1 hatSenderR .^VER-Agent` Š

GEM SV03 &03

GEM SV04 &04

º » 1 hatEmpfängerR .^FUH-Agent ` Š» » 1 hatIlloR .^ProtOffer ` ¼ º » » GEM » 1 bezugZuR .SV01&01 Š» » ¼»

1 hatEmpfängerR .^VER-Agent ` Š 1 hatIlloR .^ProtReject ` Š GEM 1 xoderR .SV03 &03

1 hatEmpfängerR .^VER-Agent ` Š 1 hatIlloR .^ProtAccept ` Š

GEM 1 bezugZuR .SV01 &01

GEM 1 xoderR .SV02 &02

º » » » Š» » ¼»

1 frühestT .^20.12.2008` º » 1 hatEmpfängerR .^FUH-Agent ` Š » »  GEM 1 hatIlloR .^Requestive` Š 1 vorherR .SV03&03 Š » » 1 hatNachR .TransportdienstleistungVER Š ¼»

Definition 10: Gemeinsame Sendevorgänge des VER- und FUH-Protokolls, Sendevorgänge 1-4

6.4 Matchingbeispiele

GEM SV05 &05

GEM SV06 &06

GEM SV07 &07

GEM SV08 &08

325

ª « «  « « « ¬«

1 hatSenderR .^FUH-Agent ` Š

ª « « «  « « « « «¬ ª « «  « « « ¬«

1 hatSenderR .^FUH-Agent ` Š

ª « «  « « « ¬«

1 hatEmpfängerR .^VER-Agent ` Š 1 hatIlloR .^Rejective` Š GEM 1 xoderR .SV06 &06 Š

1 1 1 1

GEM 1 bezugZuR .SV04 &04

GEM 1 vorherR .SV04 &04

º » » » Š» » ¼»

º » hatEmpfängerR .^VER-Agent ` Š » » GEM hatIlloR .^Offer ` Š 1 bezugZuR .SV04&04 Š » » GEM GEM 1 vorherR .SV04 xoderR .SV05 &05 Š & 04 Š » » hatNachR .TransportdienstleistungVER »¼

1 hatSenderR .^VER-Agent ` Š

GEM º 1 xoderR .SV08 &08 Š » 1 hatEmpfängerR .^FUH-Agent ` Š » » GEM  1 hatIlloR .^Rejective` Š 1 vorherR .SV06 &06 Š » » GEM 1 bezugZuR .SV06 1 spätestT .^28.12.2008` &06 Š ¼»

1 hatSenderR .^VER-Agent ` Š

1 spätestT .^28.12.2008`º » 1 hatEmpfängerR .^FUH-Agent ` Š » »  GEM 1 hatIlloR .^ Acceptance` Š 1 vorherR .SV06 &06 Š » » GEM GEM 1 xoderR .SV07 &07 Š 1 bezugZuR .SV06 &06 Š ¼»

Definition 11: Gemeinsame Sendevorgänge des VER- und FUH-Protokolls, Sendevorgänge 5-8

6.4.2 Hypothesenfalsifikation auf der Semantikebene Die Hypothesenfalsifikation bildet den ersten Schritt des ontologischen Matchingprozesses. Zur Falsifikation werden als Eingabe die beiden Konzeptklassenmengen FUHBE und VERBE benötigt. FUHBE repräsentiert die Menge der Bedeutungseinheiten der Empfängerontologie, VERBE entspricht der Menge der Bedeutungseinheiten der Senderontologie. Das kartesische Produkt beider Mengen bildet die Hypothesenmenge H0 . Um die Hypothesenmenge H1 zu erhalten, sind alle Konzeptklassenpaare zu entfernen, die die formulierten notwendigen Äquivalenzbedingungen verletzen.

326

6 Anwendungsbeispiel

Zielsetzung dieses Abschnitts ist die Reduzierung der Hypothesenmenge H0 auf die Hypothesenmenge H1 . Ausgangspunkt der Betrachtung ist die FUH-Ontologie. Für jede der in Abbildung 41 aufgeführten Bedeutungseinheiten ist zu prüfen, welche der in Abbildung 48 vorgestellten Bedeutungseinheiten der VER-Ontologie die notwendigen Äquivalenzbedingungen verletzen. Somit wird für jedes Element aus FUHBE eine Menge potenzieller Äquivalenzkandidaten aus VERBE ermittelt. In Kapitel 5.4 wurden die folgenden notwendigen Äquivalenzbedingungen herausgearbeitet: ƒ RA-Kompatibilität, ƒ Strukturelementtypen-Übereinstimmung, ƒ GBox-Übereinstimmung, ƒ Maßeinheiten-Kompatibilität, ƒ Werttypen-Kompatibilität.

Es sei zunächst die Konzeptklasse Transport FUH betrachtet. Am restriktivsten wirkt bei dieser Nachrichten-Konzeptklasse die Anforderung der Strukturelementtypen-Übereinstimmung. Die VER-Ontologie verfügt nur über eine Konzeptklasse, der ebenfalls eine Nachricht als Strukturelementtyp zugeordnet ist: die Konzeptklasse TransportdienstleistungVER . Für die Konzeptklasse Transport FUH kommt somit nur die Konzeptklasse TransportdienstleistungVER als möglicher Äquivalenzkandidat infrage. Für diese beiden Konzeptklassen sind alle Äquivalenzbedingungen erfüllt. Bei den Konzeptklassen Abladedatum FUH und Verladedatum FUH ist vor allem die Äquivalenzbedingung der GBox-Übereinstimmung zu berücksichtigen. Beide Konzeptklassen sind Spezialisierungen der GBoxKonzeptklasse DatumIDI . Somit müssen semantische Äquivalenzkandidaten ebenfalls Spezialisierungen dieser GBox-Konzeptklasse darstellen. Als Äquivalenzkandidaten für Abladedatum FUH und Verladedatum FUH kommen daher aus der VER-Ontologie ausschließlich die Konzeptklassen EntladedatumVER und LadedatumVER infrage. Die

GBox-Übereinstimmung ist auch bei den Konzeptklassen und Verladedatum FUH sowie EntladedatumVER und LadedatumVER zu untersuchen. Sie repräsentieren Teile von DatumsanAbladedatum FUH

6.4 Matchingbeispiele

327

gaben; so kann z.B. ein Hyponym der Konzeptklasse Tag IDI nur zu einer Konzeptklasse semantisch äquivalent sein, die ebenfalls Hyponym dieser GBox-Konzeptklasse ist. Die gleichen Äquivalenzvoraussetzungen gelten für die Konzeptklassen Versandadresse FUH und Empfangsadresse1FUH sowie LadeortVER und EntladeortVER sowie die diesen Konzeptklassen untergeordneten Meronyme. Der Konzeptklasse Transportfahrzeug FUH ist ein Datenfeld als Strukturelementtyp zugeordnet. Semantisch äquivalent können also nur Bedeutungseinheiten sein, denen ebenfalls ein Datenfeld zugeordnet ist. Zudem stellt diese Bedeutungseinheit keine Spezialisierung einer GBoxKonzeptklasse dar; somit kann sie auch nicht zu einer solchen Bedeutungseinheit semantisch äquivalent sein. Schließlich verfügt die Konzeptklasse auch nicht über eine Maßeinheit. Somit verbleiben als Äquivalenzkandidaten für die Konzeptklasse Transportfahrzeug FUH drei Alternativen: Transportmittel VER , LadungVER und Packmittel VER . Die Konzeptklasse Verpackungseinheit FUH besitzt eine abgeschlossene Klasse: ^Palette,Rollbox` . Eine Bedeutungseinheit der VER-Ontologie kann zu dieser Konzeptklasse also nur dann semantisch äquivalent sein, wenn ihre Geschäftsdateneinheit mit einem Element der abgeschlossenen Klasse übereinstimmt. In der VER-Ontologie kommt als Äquivalenzkandidat nur die Konzeptklasse Packmittel VER infrage. Die Konzeptklasse Ladungsgewicht FUH verfügt über einen Regulären Ausdruck sowie eine Maßeinheit. Als Maßeinheit wurde "Tonne" (t) angegeben. Da keine Konzeptklasse der VER-Ontologie über eine hierzu kompatible Maßeinheit verfügt, existiert für die Konzeptklasse Ladungsgewicht FUH kein semantisch äquivalentes Konzept. Da es sich bei dieser Konzeptklasse um eine fakultative Konzeptklasse handelt, wird der Matchingprozess nicht gestoppt. Abschließend sei die Konzeptklasse Stückzahl FUH betrachtet. Durch die angegebene Maßeinheit "Stück" wird die Menge infrage kommender Äquivalenzkandidaten auf diejenigen Konzeptklassen eingeschränkt, die über die gleiche Maßeinheit verfügen.

328

6 Anwendungsbeispiel

Es sei nun die Hypothesenmenge H1 in Form einer Matrix präsentiert. Konzeptklassenpaare, bei denen die notwendigen Äquivalenzbedingungen erfüllt sind, sind mit einem "X" gekennzeichnet. Alle anderen Konzeptklassenpaare müssen bei der nun folgenden Berechnung eines Äquivalenzkoeffizienten nicht mehr berücksichtigt werden. In den Zeilen sind die Konzeptklassen der FUH-Ontologie notiert. Spalten enthalten die Konzeptklassen der VER-Ontologie. Aus Gründen der besseren Übersichtlichkeit wurde auf die Darstellung der Meronyme von Datums- und Adressenkonzepten verzichtet.

6.4 Matchingbeispiele

329

X

Versandadresse

X

X

Empfangsadresse

X

X X

X

Transportfahrzeug FUH-Ontologie

X

Packmittel

X

Anzahl

Verladedatum

Ladung

X

Transport

Transportmittel

X

Entladeort

Ladedatum

Abladedatum

Ladeort

Entladedatum

Transportdiensteitung

VER-Ontologie

X X

Verpackungseinheit Ladungsgewicht Stückzahl

X

Tabelle 27: Hypothesenmenge H1 des Anwendungsbeispiels

6.4.3 Ontologisches Matching: Berechnung der Äquivalenzindikatoren Die Zielsetzung der folgenden Abschnitte besteht nicht darin, die Kalkulation sämtlicher Äquivalenzindikatoren für das Anwendungsbeispiel zu demonstrieren. Vielmehr soll die grundsätzliche Anwendungsweise und die Berechnung einzelner Indikatoren an jeweils einem Beispiel gezeigt werden. Dabei soll die Aussagekraft einzelner Äquivalenzindikatoren bewertet und ggf. Grenzen ihres Einsatzes aufgezeigt werden. Durch die Hypothesenfalsifikation konnte die Anzahl potenziell äquivalenter Konzeptklassenpaare stark eingeschränkt werden. Die Berech-

330

6 Anwendungsbeispiel

nung der Äquivalenzindikatoren kann somit auf die in Tabelle 27 dargestellten Konzeptklassenpaare beschränkt bleiben. 6.4.3.1 Bezeichnerkoeffizient

Es sei nun für jede sich aus Tabelle 27 ergebende Konzeptklassenpaarung der jeweilige Bezeichnerkoeffizient simBEZ ermittelt. Das Ergebnis dieser Berechnung ist in der unten stehenden Tabelle 28 zusammengefasst. ƒ In der zweiten und dritten Tabellenspalte sind jeweils die Bezeichner der beiden Ontologien dargestellt. ƒ Die vierte Spalte ("d") zeigt, wie viele Manipulationsschritte erforderlich sind, um den VER-Bezeichner in den FUH-Bezeichner zu überführen. ƒ Die fünfte Spalte ("n") gibt die Zeichenzahl der längeren Zeichenkette an. ƒ Die sechste Spalte ("m") gibt die Zeichenzahl der kürzeren Zeichenkette an. ƒ Die siebte Spalte ("lcs") informiert über die Länge der längsten gemeinsamen Zeichenkette. ƒ Die Spalte "Soll" gibt an, ob die zu den Bezeichnern gehörenden Konzeptklassen semantisch äquivalent ("1") oder inäquivalent ("0") sind. ƒ Die letzte Spalte enthält den Wert des Äquivalenzindikators simBEZ .

Nr. FUH-Bezeichner

VER-Bezeichner

d

n

m lcs Soll sim

1

Transport

Transportdienstleistung

14

23

9

9

1 0,696

2

Verladedatum

Entladedatum

3

12

12

9

0 0,750

3

Verladedatum

Ladedatum

3

12

9

9

1 0,875

4

Abladedatum

Entladedatum

3

12

11

9

1 0,784

5

Abladedatum

Ladedatum

3

11

9

9

0 0,864

6

Versandadresse

Ladeort

14

14

7

2

1 0,143

7

Versandadresse

Entladeort

14

14

10

2

0 0,100

8

Empfangsadresse1

Ladeort

16

16

7

2

0 0,143

6.4 Matchingbeispiele

331

Nr. FUH-Bezeichner

VER-Bezeichner

d

n

m lcs Soll sim

9

Entladeort

15

16

10

2

1 0,131

10 Transportfahrzeug

Transportmittel

8

17

15

9

1 0,565

11 Transportfahrzeug

Ladung

16

17

6

1

0 0,113

12 Transportfahrzeug

Packmittel

17

17

10

1

0 0,050

13 Verpackungseinheit Packmittel

14

18

10

4

1 0,311

14 Stückzahl

5

9

6

4

1 0,556

Empfangsadresse1

Anzahl

Tabelle 28: Ergebnisse des Bezeichnerkoeffizienten

Angenommen, der Schwellenwert für Äquivalenz läge bei G Equ 

0, 5 .

In diesem Fall würde der Einsatz von simBEZ eine Korrektklassifikationsrate von 4 BEZ

9 14

0 , 64

ergeben. Die Überwindung von Bezeichnerheterogenität wird in Abschnitt 6.4.4.1 beispielhaft gezeigt. 6.4.3.2 RA-Relevanz

Die RA-Relevanz lässt sich für alle Konzeptklassenpaare berechnen, bei denen die KLO-Konzeptklasse über einen Regulären Ausdruck verfügt. In der FUH-Ontologie gehören hierzu die Konzeptklassen Abladedatum FUH , Verladedatum FUH , Versandadresse FUH und Empfangsadresse1FUH .

Diese vier Konzeptklassen sind Spezialisierung der Konzeptklassen DatumIDI oder AdresseIDI . Sie erben also ihren jeweiligen Regulären Ausdruck von den beiden genannten GBox-Konzeptklassen.

332

6 Anwendungsbeispiel

Die Berechnung der RA-Relevanz sei nun am Beispiel des Konzeptklassenpaares AbladedatumFUH ,EntladedatumVER gezeigt. Gesucht ist der





Äquivalenzindikator simRAW für diese beiden Konzeptklassen. In einem ersten Schritt ist die A-priori-Wahrscheinlichkeit für die Äquivalenz der beiden Konzeptklassen zu ermitteln. Die A-prioriWahrscheinlichkeit wird durch den Term



P Abladedatum FUH { EntladedatumVER



angegeben. Bei acht Bedeutungseinheiten in der VER-Ontologie323 beträgt der Wert für die A-priori-Wahrscheinlichkeit



P Abladedatum FUH { EntladedatumVER



1 8

0 , 125 .

Ohne weitere Information beträgt also die Äquivalenzwahrscheinlichkeit für das Konzeptklassenpaar

 AbladedatumFUH ,EntladedatumVER

12,5

Prozent. In einem zweiten Schritt ist die A-priori-Wahrscheinlichkeit der Kompatibilität des Geschäftdatenstroms von EntladedatumVER zum Regulären Ausdruck von Abladedatum FUH zu kalkulieren. Dieser Wahrscheinlichkeitswert wird durch den Term





P ªkompRA AbladedatumFUH ,EntladedatumVER º ¬ ¼

repräsentiert. Zwei Geschäftsdateneinheiten der empfangenen Nachricht sind zum Regulären Ausdruck von Abladedatum FUH kompatibel. Somit beträgt

323

Die Konzeptklasse der Nachrichtenebene muss unberücksichtigt bleiben, weil Bedeutungseinheiten nur dann semantisch äquivalent sein können, wenn ihnen der gleiche Strukturelementtyp zugeordnet ist. Vgl. Abschnitt 5.4.2. Für welche Konzeptklassenpaare aus der FUH- und VER-Ontologie semantische Äquivalenz zu ermitteln ist, ergibt sich aus der in Tabelle 27 dargestellten Hypothesenmenge.

6.4 Matchingbeispiele

333





P ª kompRA Abladedatum FUH ,EntladedatumVER º ¬ ¼

2 8

0 , 25 .



Nun lässt sich der Wert von simRAW AbladedatumFUH ,EntladedatumVER



entsprechend Formel 39 berechnen:



simRAW AbladedatumFUH ,EntladedatumVER



0,125 0, 25

0, 5 .

Die Wahrscheinlichkeit für die semantische Äquivalenz der Konzeptklassen EntladedatumVER und Abladedatum FUH beträgt 50%, wenn bekannt ist, dass der zu EntladedatumVER gehörende Geschäftsdatenstrom kompatibel zum Regulären Ausdruck von Abladedatum FUH ist. Die Kompatibilität der Geschäftsdateneinheit einer KME-Konzeptklasse zum Regulären Ausdruck einer KLO-Konzeptklasse wurde in Abschnitt 5.4.2 als notwendige Äquivalenzbedingung definiert. Einerseits liefern Reguläre Ausdrücke somit einen wertvollen Beitrag zur Hypothesenfalsifikation und zur Einengung des Suchraums. Andererseits trägt diese notwendige Äquivalenzbedingung zu einer nur eingeschränkten Nutzbarkeit der RA-Relevanz als Äquivalenzindikator bei. Weil der Wert für P ª¬ kompRA  Klo,Kme |  Klo { Kme º¼ immer "1" betragen muss, kann der Koeffizient simRAW nur Werte von "1", "0,5" oder kleiner annehmen. Die RA-Relevanz liefert keine stetigen Messgrößen, ihre Werte sind eher als ordinale Merkmale zu interpretieren. Ein Wert von simRAW 1 deutet auf eine sehr hohe Äquivalenzwahrscheinlichkeit hin. Der Wert von simRAW 0, 5 repräsentiert Indifferenz. Alle anderen Werte deuten auf eine geringe Äquivalenzwahrscheinlichkeit hin. 6.4.3.3 Graphenbasierter Äquivalenzindikator

Der Wert des graphenbasierten Äquivalenzindikators drückt den Übereinstimmungsgrad des Beziehungsgeflechts zweier Konzeptklassen aus; die Konzeptklassenbedeutung bleibt unberücksichtigt. Aufgrund der Berechnungskomplexität bleibt die Kalkulation des graphenbasierten Äquivalenzindikators auf ein Konzeptklassenpaar beschränkt. Es wurde das Konzeptklassenpaar

334

6 Anwendungsbeispiel



simGRA Transportfahrzeug FUH ,TransportmittelVER



ausgewählt. Für das ausgewählte Konzeptklassenpaar ist in einem ersten Schritt der Konnektivitätsgraph zu erstellen. FahrzeugVER FahrzeugFUH TAX

TransportdienstleistungVER

motorisiertes FahrzeugVER

TransportFUH

MotorfahrzeugFUH

MER

TAX

TransportmittelVER TAX

TransportfahrzeugFUH TAX

TAX

TAX

TAX

TAX

TAX

TAX

TAX

LKW VER

LKW VER

LKW VER

ZugVER

ZugVER

ZugVER

SchiffVER

SchiffVER

SchiffVER

LKW FUH

SchiffFUH

ZugFUH

LKW FUH

SchiffFUH

ZugFUH

LKW FUH

SchiffFUH

ZugFUH

Abbildung 53: Konnektivitätsgraph für die Konzeptklassen "Transportfahrzeug" und "Transportmittel"

Der Konnektivitätsgraph zeigt, welche Konzeptklassenpaare im Beziehungskontext der beiden Konzeptklassen

Transportfahrzeug FUH ,TransportmittelVER prinzipiell semantisch äquivalent sein könnten. Bspw. besitzen beide Konzeptklassen nur jeweils ein Homonym. Die Konzeptklasse Transportfahrzeug FUH verfügt über das Holonym Transport FUH , die Konzeptklasse Transportmittel VER

über das Homonym Transportdienstleistung VER .

6.4 Matchingbeispiele

335

Somit können alleine aus der Betrachtung des Beziehungskontextes heraus nur die beiden Konzeptklassen Transportdienstleistung VER und Transport FUH semantisch äquivalent sein. Diese beiden Konzeptklassen bilden daher einen Konnektivitätsknoten. Weniger eindeutig stellt sich die Bildung der Konnektivitätsknoten für die Hyponyme des betrachteten Konzeptklassenpaars dar. Beide Konzeptklassen verfügen jeweils über drei Hyponyme. Hieraus ergeben sich neun Kombinationsmöglichkeiten und somit auch neun Konnektivitäts-





knoten. Einer davon lautet bspw. LKW FUH ,LKW VER . Im nächsten Schritt ist der Propagationsgraph zu erstellen. Dabei werden die Kanten wie in Abschnitt 5.5.4 beschrieben gewichtet. FahrzeugVER FahrzeugFUH 1

1

TransportdienstleistungVER

motorisiertes FahrzeugVER

TransportFUH

MotorfahrzeugFUH 1

1

1

1

TransportmittelVER 0,11

1

0,11

TransportfahrzeugFUH 1

0,11

1

0,11 1

0,11 1

0,11 1

1 0,11

1

0,11

1

0,11

LKW VER

LKW VER

LKW VER

ZugVER

ZugVER

ZugVER

SchiffVER

SchiffVER

SchiffVER

LKW FUH

SchiffFUH

ZugFUH

LKW FUH

SchiffFUH

ZugFUH

LKW FUH

SchiffFUH

ZugFUH

Abbildung 54: Propagationsgraph für die Konzeptklassen "Transportfahrzeug" und "Transportmittel"

Die Kantengewichtung sei anhand zweier Beispiele demonstriert. Sowohl Transportfahrzeug FUH wie auch Transportmittel VER verfügen beide jeweils nur über eine holonyme Beziehung. Somit ist die Kante

336

6 Anwendungsbeispiel 1 o Transportfahrzeug FUH ,TransportmittelVER  Transport FUH ,TransportdienstleistungVER

mit dem Wert "1" zu versehen. Gleiches

gilt

für

die

Konzeptklassen

Transport FUH

und Transportdienstleistung : sie besitzen jeweils nur eine meronyme Beziehung. Entsprechend wird die Kante VER

1 o Transport FUH ,TransportdienstleistungVER  Transportfahrzeug FUH ,TransportmittelVER

ebenfalls mit dem Wert "1" markiert. Hingegen besitzen die beiden Konzeptklassen Transportfahrzeug FUH und Transportmittel VER jeweils drei hyperonyme Beziehungen. Somit ist der Knoten

Transportfahrzeug FUH ,TransportmittelVER mit insgesamt neun anderen Konnektivitätsknoten zu verbinden. Die Gewichtung aller dieser Kanten muss in Summe den Wert "1" ergeben; daher wird jede dieser Kanten mit dem Gewicht "0,11" versehen. Die Berechnung des Koeffizienten



simGRA Transportfahrzeug FUH ,Transportmittel VER



V 20 Transportfahrzeug FUH ,Transportmittel VER





sei nun anhand der unten dargestellten normalisierten Iterationstabelle gezeigt.

337

Transportdienstleist. (VER) Transport (FUH) Fahrzeug (VER) Fahrzeug (FUH) motorisiertes Fahrzeug (VER) Motorfahrzeug (FUH) LKW (VER) LKW (FUH) LKW (VER) Schiff (FUH) LKW (VER) Zug (FUH) Zug (VER) LKW (FUH) Zug (VER) Schiff (FUH) Zug (VER) Zug (FUH) Schiff (VER) LKW (FUH) Schiff (VER) Schiff (FUH) Schiff (VER) Zug (FUH) Transportmittel (VER) Transportfahrzeug (FUH)

6.4 Matchingbeispiele

n 0

1

1

1

1

1

1

1

1

1

1

1

1

1

1 0,167 0,167 0,250 0,093 0,093 0,093 0,093 0,093 0,093 0,093 0,093 0,093

1

2 0,519 0,185 0,630 0,090 0,090 0,090 0,090 0,090 0,090 0,090 0,090 0,090

1

3 0,513 0,275 0,613 0,068 0,068 0,068 0,068 0,068 0,068 0,068 0,068 0,068

1

4 0,553 0,325 0,691 0,065 0,065 0,065 0,065 0,065 0,065 0,065 0,065 0,065

1

5 0,549 0,359 0,713 0,062 0,062 0,062 0,062 0,062 0,062 0,062 0,062 0,062

1

6 0,550 0,380 0,735 0,061 0,061 0,061 0,061 0,061 0,061 0,061 0,061 0,061

1

7 0,547 0,394 0,747 0,060 0,060 0,060 0,060 0,060 0,060 0,060 0,060 0,060

1

8 0,545 0,402 0,755 0,060 0,060 0,060 0,060 0,060 0,060 0,060 0,060 0,060

1

9 0,544 0,407 0,759 0,060 0,060 0,060 0,060 0,060 0,060 0,060 0,060 0,060

1

10 0,543 0,410 0,762 0,060 0,060 0,060 0,060 0,060 0,060 0,060 0,060 0,060

1

11 0,543 0,412 0,764 0,060 0,060 0,060 0,060 0,060 0,060 0,060 0,060 0,060

1

12 0,542 0,414 0,765 0,060 0,060 0,060 0,060 0,060 0,060 0,060 0,060 0,060

1

13 0,542 0,414 0,766 0,060 0,060 0,060 0,060 0,060 0,060 0,060 0,060 0,060

1

14 0,542 0,415 0,766 0,060 0,060 0,060 0,060 0,060 0,060 0,060 0,060 0,060

1

15 0,542 0,415 0,767 0,060 0,060 0,060 0,060 0,060 0,060 0,060 0,060 0,060

1

16 0,542 0,415 0,767 0,060 0,060 0,060 0,060 0,060 0,060 0,060 0,060 0,060

1

17 0,542 0,415 0,767 0,060 0,060 0,060 0,060 0,060 0,060 0,060 0,060 0,060

1

n

6 Anwendungsbeispiel

Transportdienstleist. (VER) Transport (FUH) Fahrzeug (VER) Fahrzeug (FUH) motorisiertes Fahrzeug (VER) Motorfahrzeug (FUH) LKW (VER) LKW (FUH) LKW (VER) Schiff (FUH) LKW (VER) Zug (FUH) Zug (VER) LKW (FUH) Zug (VER) Schiff (FUH) Zug (VER) Zug (FUH) Schiff (VER) LKW (FUH) Schiff (VER) Schiff (FUH) Schiff (VER) Zug (FUH) Transportmittel (VER) Transportfahrzeug (FUH)

338

18 0,542 0,416 0,767 0,060 0,060 0,060 0,060 0,060 0,060 0,060 0,060 0,060

1

19 0,542 0,416 0,767 0,060 0,060 0,060 0,060 0,060 0,060 0,060 0,060 0,060

1

20 0,542 0,416 0,767 0,060 0,060 0,060 0,060 0,060 0,060 0,060 0,060 0,060

1

Tabelle 29: Iterationstabelle zur beispielhaften Berechnung des graphenbasierten Äquivalenzindikators

Jede Zeile der obigen Tabelle repräsentiert einen Iterationsschritt, die Spalten stellen die jeweiligen Konzeptklassenpaare dar. Somit lässt sich in den Tabellenzellen der Wert des graphenbasierten Äquivalenzindikators für ein bestimmtes Konzeptklassenpaar und einen bestimmten Iterationsschritt ablesen. Werden die Iterationswerte jeweils bis zur dritten Nachkommastelle berechnet, so sind die Endwerte bei diesem Rechenbeispiel nach der 15. Iterationsstufe erreicht. Für das betrachtete Konzeptklassenpaar

Transportfahrzeug FUH ,TransportmittelVER gibt der Koeffizient simGRA eine starke Äquivalenzhypothese aus. Alleine aufgrund des Beziehungsnetzwerks ist von der sicheren semantischen Äquivalenz dieser Konzeptklassen auszugehen. Gleichzeitig lässt sich anhand der obigen Tabelle allerdings auch zeigen, dass die mangelnde Berücksichtigung der Konzeptklassenbedeutung als eine der wesentlichen Schwächen des Ansatzes zu betrachten ist. So besitzen alle aus den Meronymen der beiden Konzeptklassen

Transportfahrzeug FUH ,TransportmittelVER

gebildeten Konnektivitätskno-

ten die gleiche geringe Äquivalenzwahrscheinlichkeit von simGRA

0,06 ,

6.4 Matchingbeispiele

339

obwohl drei dieser Knoten semantisch äquivalente Konzeptklassenpaare beinhalten. Dass

das

obige

Transportfahrzeug

FUH

Ergebnis

für

,Transportmittel

das

Konzeptklassenpaar

nur bedingt aussagekräftig ist, Transportfahrzeug FUH ,LadungVER

VER

soll an einem weiteren Beispielpaar

gezeigt werden. Es sei zunächst der Propagationsgraph für dieses Konzeptklassenpaar erstellt. ArtefaktVER FahrzeugFUH 1

1

TransportdienstleistungVER

WareVER

TransportFUH

MotorfahrzeugFUH 1

1

1

1

LadungVER TransportfahrzeugFUH 0

0

0 0

0 0

0

LKW FUH

0

0

AnzahlVER ZugFUH

0

PackmittelVER

SchiffFUH

Abbildung 55: Propagationsgraph für die Konzeptklassen "Transportfahrzeug" und "Ladung"

Aus diesem Propagationsgraph lässt sich die unten stehende Iterationstabelle ableiten.

0

1

Ladung (VER) Transportfahrzeug (FUH)

Packmittel (VER)

Anzahl (VER)

Zug (FUH)

LKW (FUH)

Schiff (FUH)

6 Anwendungsbeispiel Transportdienstleistung (VER) Transport (FUH) Artefakt (VER) Fahrzeug (FUH) Ware (VER) Motorfahrzeug (FUH)

340

1

1

1

1

1

1

1

1

1 0,667 0,667

1

0

0

0

0

0

1

2 0,625 0,625

1

0

0

0

0

0

1

3 0,619 0,619

1

0

0

0

0

0

1

4 0,618 0,618

1

0

0

0

0

0

1

5 0,618 0,618

1

0

0

0

0

0

1

Tabelle 30: Iterationstabelle Beispiel 2

Auch hier ergibt der Wert für den graphenbasierten Äquivalenzindikator



simGRA Transportfahrzeug FUH ,LadungVER



1.

An diesem Beispiel wird eine wesentliche Schwäche des graphenbasierten Äquivalenzindikators deutlich: es werden ausschließlich übereinstimmende Teile des Beziehungsnetzes berücksichtigt. Dass es für die drei Hyponyme der Konzeptklasse Transportfahrzeug FUH sowie die beiden Meronyme der Konzeptklasse LadungVER keine semantischen Äquivalente gibt, spiegelt sich in dem Wert für



simGRA Transportfahrzeug FUH ,LadungVER



nicht wider. Der graphenbasierte Äquivalenzindikator liefert vor allem dann gute Ergebnisse, wenn Konzeptklassen über eine charakteristische Beziehungsstruktur verfügen.

6.4 Matchingbeispiele

341

Der Einsatz des graphenbasierten Äquivalenzindikators kann sinnvoll sein, wenn der Suchraum für äquivalente Konzeptklassenpaare durch den Falsifikationsprozess nicht oder nur wenig eingeschränkt werden konnte. In diesem Fall kann der Koeffizient simGRA eine Liste möglicher Äquivalenzkandidaten ausgeben. 6.4.3.4 Taxonomiekoeffizient

Der Taxonomiekoeffizient stellt einen sog. sekundären Äquivalenzindikator dar. Somit ist der Rückgriff auf mindestens einen primären Äquivalenzindikator erforderlich. Aus Vereinfachungsgründen soll der Taxonomiekoeffizient für die im Folgenden gezeigte Beispielrechnung ausschließlich den Bezeichnerkoeffizienten als Eingabe verwenden. Als Beispiel zur Berechnung des Taxonomiekoeffizienten bietet sich das Konzeptklassenpaar

Transportfahrzeug FUH ,TransportmittelVER

an, da

beide Konzeptklassen über einen taxonomischen Kontext verfügen. In einem ersten Schritt wird für alle möglichen Konzeptklassenpaarungen im hyponymen und hyperonymen Kontext beider Konzeptklassen der Bezeichnerkoeffizient ermittelt. Wie in Kapitel 5.5.3 dargelegt, erfordert die Berechnung des Taxonomiekoeffizienten eine Definition der Schnittmengen der hyponymen und hyperonymen Kontexte der betrachteten Konzeptklassen. Abweichend zu Definition 6 soll hier bei der Bestimmung der Schnittmengen die Bezeichner-Ähnlichkeit, nicht jedoch die semantische Äquivalenz berücksichtigt werden. Entsprechend sind die Schnittmengendefinitionen anzupassen. Als Schwellenwert für die Bezeichnerübereinstimmung wurde ein Bezeichnerkoeffizient von 0,7 angenommen.

342

6 Anwendungsbeispiel §Transportfahrzeug FUH , · ¸: Hyperˆ ¨ ¨Transportmittel VER ¸ © ¹ ­ F1 ,F2  Hyper Transportfahrzeug FUH š ½ ° ° ° ° VER š V1 ,V2  Hyper Transportmittel °° °° ® F1 ,V1 ¾ 1 ªF1 ,  V2 :  simBEZ  F1 ,V2 ! 0,7 º š ° ° ¬ ¼ ° ° ° ° ªV1 , 1F2 :  simBEZ V1 ,F2 ! 0,7 º ¬ ¼ °¯ ¿°

 





§Transportfahrzeug FUH , · ¸: Hypoˆ ¨ ¨Transportmittel VER ¸ © ¹ ­ F1 ,F2  Hypo Transportfahrzeug FUH š ½ ° ° ° ° VER  š V ,V Hypo Transportmittel 1 2 °° °° ® F1 ,V1 ¾ ªF1 , 1V2 :  simBEZ  F1 ,V2 ! 0 ,7 º š ° ° ¬ ¼ ° ° ° ° ªV1 , 1F2 :  simBEZ V1 ,F2 ! 0,7 º °¯ ¬ ¼ °¿

 





Definition 12: Taxonomie-Schnittmengen des Fallbeispiels

Der taxonomische Kontext der betrachteten Konzeptklassen sowie die sich hieraus ergebenden Schnittmengen seien nun grafisch dargestellt. Die unten stehende Grafik zeigt die Werte der Bezeichnerkoeffizienten für die Konzeptklassenpaare im taxonomischen Kontext der Konzeptklassen Transportfahrzeug FUH und TransportmittelVER .

6.4 Matchingbeispiele

343

VER-Ontologie

FUH-Ontologie

Fahrzeug

simBEZ=1

Fahrzeug

motorisiertes Fahrzeug

simBEZ=0,603

Motorfahrzeug

Transportmittel

Transportfahrzeug

LKW

simBEZ=1

LKW

Schiff

simBEZ=1

Schiff

Zug

simBEZ=1

Zug

Abbildung 56: Ermittlung des Übereinstimmungsgrads des taxonomischen Kontextes im Fallbeispiel

Wie die obige Grafik zeigt, weist der taxonomische Kontext beider Konzeptklassen einen sehr hohen Übereinstimmungsgrad auf. Ausgehend von einem Schwellenwert OEqu  0,7 stimmt der hyponyme Kontext völlig, der hyperonyme Kontext zur Hälfte überein. Es lassen sich also die folgenden Mächtigkeiten der beiden Schnittmengen ermitteln: ª § Transportfahrzeug FUH , · º ¸» # «Hyperˆ ¨ ¨ Transportmittel VER ¸» «¬ © ¹¼

1;

ª § Transportfahrzeug FUH , · º ¸» # «Hypoˆ ¨ ¨TransportmittelVER ¸» «¬ © ¹¼

3

.

Somit ergeben sich die folgenden Werte für den Hyponymie- und Hyperonymie-Koeffizienten:

344

6 Anwendungsbeispiel §Transportfahrzeug FUH , · ¸ simHyper ¨ ¨Transportmittel VER ¸ © ¹ §Transportfahrzeug FUH , · ¸ simHypo ¨ ¨TransportmittelVER ¸ © ¹

2 ˜1 22

0, 5 .

2˜3 33

1

Nun lässt sich auch der Taxonomiekoeffizient ermitteln: §Transportfahrzeug FUH , · ¸ simTAX ¨ ¨TransportmittelVER ¸ © ¹

0, 5  1 2

0,75 .

Würde der errechnete Wert des Taxonomiekoeffizienten als heterogen eingestuft, bestünden in dem vorgestellten Anwendungsfall zwei aufeinander aufbauende Strategien zur Heterogenitätsüberwindung. Zum einen wäre zu untersuchen, ob und in welchem Umfang mögliche Heterogenitätseffekte durch die als Input verwendeten Bezeichnerkoeffizienten verursacht worden sind. Die Höhe der Korrektklassifikationsrate des Taxonomiekoeffizienten hängt maßgeblich von der Klassifizierungsgüte der zugrunde liegenden primären Äquivalenzindikatoren ab. Heterogenitätseffekte auf der Ebene der primären Äquivalenzindikatoren pflanzen sich also auf die Ebene der sekundären Äquivalenzindikatoren fort. Strategien zur Überwindung von Bezeichnerheterogenität wurden in Kapitel 5.7.3.1 dargestellt. Zum anderen kann Heterogenität auch direkt auf der Ebene der sekundären Äquivalenzindikatoren entstehen. Die Überwindung von Taxonomieheterogenität ist in Kapitel 5.7.3.4 Gegenstand dieser Arbeit. Die in Abschnitt 5.7.3.4 dargestellten Verfahren zur Überwindung von Taxonomieheterogenität versagen, wenn Heterogenität durch taxonomische Lücken verursacht wird. Eine solche Situation kann bspw. dann eintreten, wenn Realweltphänomene in unterschiedlichen Ontologien aus unterschiedlichen Perspektiven und somit durch unterschiedliche Eigenschaften bzw. Eigenschaftskategorien beschrieben werden. Als Folge stimmen möglicherweise die taxonomischen Kontexte der betrachteten Konzeptklassenpaare nicht überein. Eine Möglichkeit zur Überwindung auch solcher Heterogenitätsursachen kann darin bestehen, die taxonomischen Kontexte der KLO-

6.4 Matchingbeispiele

345

Konzeptklassen sukzessive zu erweitern. Immer dann, wenn zwei Konzeptklassen semantisch äquivalent sind und die erhaltene Konzeptklasse über unbekannte Konzepte in ihrem taxonomischen Kontext verfügt, werden diese unbekannten Konzepte dem taxonomischen Kontext der KLO-Konzeptklasse hinzugefügt. Auf diese Art und Weise nimmt die Anzahl der unbekannten taxonomischen Kontexte immer mehr ab, die Treffergenauigkeit verbessert sich aufgrund des hinzugewonnenen Wissens. Der Nachteil dieser Form der Wissenserweiterung besteht darin, dass zumindest zu Beginn der IDI-Nutzung die semantische Klassifikation heterogener Konzeptklassen durch menschliche Aufgabenträger begleitet werden müsste. Die Überwindung von Taxonomieheterogenität ist nicht Gegenstand des Anwendungsbeispiels. Stattdessen wird in Abschnitt 6.4.4.2 die Überwindung von Mereologieheterogenität gezeigt. Methodisch sind beide Verfahren identisch. 6.4.3.5 Mereologiekoeffizient

An letzter Stelle soll noch die Berechnung des Mereologiekoeffizienten an einem Beispiel demonstriert werden. Die mereologische Struktur der relevanten Bedeutungseinheiten ist in Abbildung 41 und Abbildung 48 zu finden. Wie sich aus Tabelle 27 ergibt, kann die Konzeptklasse Packmittel VER sowohl zur Konzeptklasse Transportfahrzeug FUH wie auch zur Konzeptklasse Verpackungseinheit FUH semantisch äquivalent sein. Somit erscheint es interessant, wie sich diese Unsicherheit in den Werten für den Mereologiekoeffizienten niederschlägt. Es wird daher der Mereologiekoeffizient für die Konzeptklassenpaare

Transportfahrzeug FUH ,PackmittelVER sowie Verpackungseinheit FUH ,PackmittelVER beispielhaft berechnet. Die Kalkulation des Mereologiekoeffizienten verläuft analog zu der des Taxonomiekoeffizienten. Auch hier gilt für die Schnittmengen im mereo-

346

6 Anwendungsbeispiel

logischen Kontext aus Vereinfachungsgründen die Vereinbarung, dass nicht semantische Äquivalenz, sondern der Übereinstimmungsgrad der Konzeptklassenbezeichner maßgeblich für die Zuordnung eines Konzeptklassenpaares zur Schnittmenge ist. Als Schwellenwert wird ebenfalls OEqu  0,7 angenommen. Auf eine formale Darstellung der Schnittmengendefinitionen sei an dieser Stelle verzichtet. Die Ermittlung der Bezeichnerkoeffizienten gestaltet sich vergleichsweise einfach, da die beiden betrachteten Konzeptklassen jeweils nur über ein Homonym verfügen. Somit muss nur der Bezeichnerkoeffizient für das aus diesen Homonymen bestehende Konzeptklassenpaar ( LadungVER ,Transport FUH ) kalkuliert werden. VER-Ontologie Ladung

Packmittel

FUH-Ontologie simBEZ=0,139

Transport

Transportfahrzeug

Abbildung 57: Ermittlung des Übereinstimmungsgrads des mereologischen Kontextes im ersten Mereologie-Anwendungsbeispiel

Da der Wert des Bezeichnerkoeffizienten unter einem angenommenen Schwellenwert von OEqu  0,7 liegt, beträgt der Wert des Mereologiekoeffizienten für das betrachtete Konzeptklassenpaar "0". Nun sei noch das zweite Anwendungsbeispiel zur Berechnung des Mereologiekoeffizienten betrachtet. Der mereologische Kontext weist hier die gleiche Struktur auf wie im vorangegangenen Beispiel.

6.4 Matchingbeispiele

347

VER-Ontologie Ladung

Packmittel

FUH-Ontologie simBEZ=0,139

Transport

Verpackungseinheit

Abbildung 58: Ermittlung des Übereinstimmungsgrades des mereologischen Kontextes im zweiten Mereologie-Anwendungsbeispiel

Der Wert des Mereologiekoeffizienten lautet auch hier



simMER Verpackungseinheit FUH ,PackmittelVER



0.

Während also der Mereologiekoeffizient das erste Konzeptklassenpaar korrekt als inäquivalent klassifiziert hat, erfolgte im zweiten Beispiel eine Fehlklassifizierung. Diese Fehlklassifizierung dient in Kapitel 6.4.4.2 als Beispiel zur Heterogenitätsüberwindung. Der Vorteil des Mereologiekoeffizienten besteht darin, dass die mereologische Struktur bei den meisten Formatstandards für den elektronischen Geschäftsdatenaustausch ohnehin vorgegeben ist. Diese mereologische Struktur kann zu Zwecken der semantischen Spezifikation und des ontologischen Matchings genutzt werden. Andererseits wird gerade an dem ersten Fallbeispiel auch eine Schwäche des Mereologiekoeffizienten offenbar. Nur ein ausreichend komplexer mereologischer Kontext kann zu aussagekräftigen Werten des Mereologiekoeffizienten führen. Bei zu flachen mereologischen Strukturen stellen im EDI-Umfeld die meisten Bedeutungseinheiten Meronyme der jeweiligen Nachrichten dar. Stimmen die Nachrichtenkonzeptklassen der betrachteten Ontologien semantisch überein, dann ergibt sich hieraus bereits ein Mereologiekoeffizient von mindestens 0,5. Der Mereologiekoeffizient beinhaltet also das Risiko, bei flachen mereologischen Strukturen die semantische Äquivalenz zu optimistisch einzuschätzen.

348

6 Anwendungsbeispiel

6.4.4 Beispiele zur Heterogenitätsüberwindung 6.4.4.1 Bezeichnerheterogenität

Zielsetzung dieses Abschnitts ist es, die Überwindung von Bezeichnerheterogenität an einem Beispiel zu demonstrieren. Hierzu sei das Konzeptklassenpaar

Verpackungseinheit FUH ,PackmittelVER aus Abschnitt 6.4.3.1 ausgewählt. Es sei angenommen, dass für dieses Konzeptklassenpaar ein Heterogenitätseffekt festgestellt wurde. Da der Wert des Bezeichnerkoeffizienten mit 0,311 unter einem angenommenen Schwellenwert für semantische Äquivalenz in Höhe von G Equ  0,7 liegt, ist auf dieses Konzeptklassenpaar die Methode zur Überwindung von Bezeichnerheterogenität anzuwenden. An erster Stelle ist zu hinterfragen, ob der hier festgestellte Heterogenitätseffekt auf Homonymie oder Synonymie zurückzuführen ist. Es ist also einer der in Bedingung 22 ("Hinreichende und notwendige Bedingungen für Synonymie") oder Bedingung 23 ("Hinreichende und notwendige Bedingungen für Homonymie") definierten Zustände festzustellen. Homonymie kommt als Heterogenitätsursache nicht infrage, da weder für Verpackungseinheit FUH noch für Packmittel VER in der jeweiligen Ontologie eine Konzeptklasse mit gleichem Bezeichner existiert. Allerdings lässt sich Synonymie feststellen. So besitzt die Konzeptklasse Verpackungseinheit FUH eine als synonym gekennzeichnete Zeichenkette "Packmittel". Somit ist die in Bedingung 22 ("Hinreichende und notwendige Bedingungen für Synonymie") definierte hinreichende und notwendige Bedingung für Synonymie erfüllt. Der Bezeichnerkoeffizient für





das Konzeptklassenpaar Verpackungseinheit FUH ,Packmittel VER kann auf den Wert "1" gesetzt werden, die Heterogenitätsursache ist überwunden. Der Bezeichnerkoeffizient liefert nur eingeschränkt brauchbare Ergebnisse, wenn Ontologien über viele semantisch ähnliche Bedeutungseinheiten mit entsprechend ähnlichen Bezeichnern verfügen. Bezogen auf das Fallbeispiel sind vor allem die Datums- und Adressenangaben als semantisch ähnlich einzustufen. Semantisch ähnliche Bedeutungseinheiten

6.4 Matchingbeispiele

349

verfügen oft über Bezeichner mit identischen Teilzeichenketten. Diese identischen Teilzeichenketten führen zu überhöhten Werten des Bezeichnerkoeffizienten, obwohl die zugehörigen Konzeptklassen semantisch inäquivalent sind. Zumindest in dem betrachteten Anwendungsfall hat sich gezeigt, dass Synonymenlisten zur Heterogenitätsüberwindung und somit zur Steigerung der Korrektklassifikationsrate beitragen können. Bei einer umfassenden Pflege dieser Synonymenlisten, die sich zur Laufzeit sukzessive erweitern lassen, sollte eine hohe Korrektklassifikationsrate für den Bezeichnerkoeffizienten erreicht werden können. 6.4.4.2 Mereologieheterogenität

Am Beispiel des in Abschnitt 6.4.3.5 kalkulierten Mereologiekoeffizienten soll nun die Überwindung von Mereologieheterogenität demonstriert werden. Aufgrund der großen methodischen Ähnlichkeit können die Erkenntnisse dieses Abschnitts grundsätzlich auch zur Überwindung von Taxonomieheterogenität angewendet werden. Die Überwindung der unter dem Stichwort der Taxonomieheterogenität zusammengefassten Heterogenitätsursachen wird daher nicht separat betrachtet. In

Abschnitt

6.4.3.5

Verpackungseinheit

FUH

wurde

,Packmittel

VER

für

das

Konzeptklassenpaar

ein Mereologiekoeffizient von



simMER Verpackungseinheit FUH ,PackmittelVER



0

ermittelt. Somit liegt der Heterogenitätseffekt HetMER vor, wenn gleichzeitig zwei Bedingungen erfüllt sind: Erstens muss der Wert des Äquivalenzkoeffizienten



ECO Verpackungseinheit FUH ,Packmittel VER



unter der Äquivalenzschwelle liegen. Zweitens muss das Konzeptklassenpaar

Verpackungseinheit FUH ,PackmittelVER Bestandteil der aktuell betrachteten Hypothesenmenge sein. Nun sind die Ursachen für diesen Heterogenitätseffekt zu identifizieren.

350

6 Anwendungsbeispiel

Ursache-

Maschinell überwindbar?

Ursache

EffektZusammenhang

GD-Transform. erforderlich?

Die in Tabelle 21 präsentierten Heterogenitätsketten werden genutzt, um mögliche Heterogenitätsursachen zu analysieren. Dazu seien in der folgenden Tabelle noch einmal diejenigen Heterogenitätsketten rekapituliert, die den Heterogenitätseffekt HetMER verursachen können.

Verschmelzungskonflikt (bVKONF )

U Ÿ  E1 › ! › En X

X

Trennungskonflikt (b TKONF )

U Ÿ  E1 › ! › En X

X

Fehlende mereologische Beziehungen (b FBMER )

U Ÿ  E1 › ! › En

X

Mereologische Lücken (b LÜMER )

U Ÿ  E1 › ! › En

Granularitätskonflikte (b GKONF )

U Ÿ  E1 › ! › En X

Tabelle 31: Heterogenitätsketten, die Mereologieheterogenität auslösen können

Alle Heterogenitätsketten, die den Effekt HetMER verursachen, sind Ursache-Wirkungs-mehrdeutig. Es ist also jede der infrage kommenden Ursachen zu prüfen. Maschinell überwindbar wären prinzipiell alle Heterogenitätsursachen mit Ausnahme mereologischer Lücken. Eine Transformation der empfangenen Geschäftsdaten wäre bei den ersten beiden Heterogenitätsursachen anzustoßen. Sollte der Heterogenitätskonflikt



HetMER Verpackungseinheit FUH ,Packmittel VER



durch einen Verschmelzungskonflikt verursacht worden sein, müsste





eine Äquivalenzgruppe EG Packmittel VER ,Verx mit

PackmittelVER ,Verx VER u VER existieren, sodass gälte:

6.4 Matchingbeispiele

351





Equ  ªVerpackungseinheit FUH ,EG PackmittelVER ,Verx º . ¬ ¼

Eine solche Konstellation würde jedoch der in Tabelle 27 dargestellten Hypothesenmenge widersprechen, denn gemäß den notwendigen Äquivalenzbedingungen kann nur Packmittel VER zu Verpackungseinheit FUH semantisch äquivalent sein. Allerdings lässt die Hypothesenmenge einen Trennungskonflikt zu. Da sowohl die Konzeptklasse Transportfahrzeug FUH wie auch die Konzeptklasse Verpackungseinheit FUH semantisch äquivalent zu Packmittel VER sein können, wäre auch ein Trennungskonflikt mit der Äquivalenzgrup-





pe EG Transportfahrzeug FUH ,Verpackungseinheit FUH möglich. Die in Bedingung 27 ("Hinreichende und notwendige Bedingungen für Trennungskonflikte") dargestellten Bedingungen für Trennungskonflikte sind jedoch nicht erfüllt, da sich bei der Kalkulation des Äquivalenzkoeffizienten für die Äquivalenzgruppe



EG Transportfahrzeug FUH ,Verpackungseinheit FUH



mit der Konzeptklasse Packmittel VER keine Hinweise für semantische Äquivalenz ergeben. Als nächstes sind fehlende mereologische Beziehungen als Heterogenitätsursache zu untersuchen. Sowohl die Konzeptklasse Verpackungseinheit FUH wie auch die Konzeptklasse PackmittelVER besitzen jeweils lediglich eine mereologische Beziehung zu einem Homonym. Diese beiden Homonyme Transport FUH und LadungVER sind jedoch eindeutig inäquivalent. Da keine weiteren mereologischen Beziehungen bestehen, kommt auch eine fehlende mereologische Beziehung nicht als Heterogenitätsursache infrage. Aus dem gleichen Grund ist auch eine mereologische Lücke als Heterogenitätsursache der beiden Konzeptklassen Verpackungseinheit FUH und Packmittel VER auszuschließen. Beide Konzepte verfügen über genau ein Homonym. Somit kann das Fehlen einer Konzeptklasse nicht Heterogenitätsursache sein.

352

6 Anwendungsbeispiel

Abschließend ist noch zu prüfen, ob ein Granularitätskonflikt vorliegt. Hierzu sei der mereologische Kontext der betrachteten Konzeptklassen in der folgenden Abbildung noch einmal rekapituliert. Es wird angenommen, dass auch zwischen den Konzeptklassen Transport FUH und TransportdienstleistungVER Mereologieheterogenität festgestellt wurde.

FUH-Ontologie

VER-Ontologie Transportdienstleistung

HetMER

Ladung

?

Packmittel

HetMER

Transport

Verpackungseinheit

Abbildung 59: Mereologische Struktur der Konzeptklassen "Packmittel" und "Verpackungseinheit"

Diese Konstellation entspricht der in Abbildung 37 dargestellten Struktur, auf einen formalen Nachweis wird daher an dieser Stelle verzichtet. Bei dem in der FUH-Ontologie fehlenden Gegenstück zur Konzeptklasse LadungVER handelt es sich um eine Knotenkonzeptklasse, da dieses Konzept gleichzeitig über ein Homonym und ein Meronym verfügen würde. Zur Überwindung des oben gezeigten Granularitätskonflikts ist die Konzeptklasse LadungVER bei der Kalkulation des Mereologiekoeffizienten unberücksichtigt zu lassen.

7 Zusammenfassung und Ausblick Der Forschungsbeitrag der vorliegenden Arbeit besteht in der Entwicklung einer ontologiebasierten Architektur, die den automatisierten und interventionsfreien Geschäftsdatenaustausch zwischen IDI-Agenten in Regelprozessen ermöglicht. Diese Architektur besteht zum einen aus dem Domänenvokabular, das eine formale Darstellung und Speicherung des für die Anwendungsdomäne IDI relevanten Domänenwissens erlaubt. Zum anderen umfasst die Architektur Methoden für das ontologische Matching sowie das Protokollmatching. Der Forschungsbeitrag dieser Arbeit auf der Syntaxebene besteht in der Entwicklung eines Syntaxvokabulars zur Beschreibung beliebiger Nachrichtenformate. Es konnte für zwei Beispielnachrichten gezeigt werden, dass sich die Syntax dieser Geschäftsnachrichten uneingeschränkt mittels des vorgestellten Syntaxvokabulars beschreiben lässt. Die in Kapitel 2.3 aufgestellte Hypothese 1 kann daher für die beiden Anwendungsbeispiele als verifiziert betrachtet werden. Auf der Semantikebene wurde gezeigt, mithilfe welcher ontologischen Merkmale sich die Bedeutung von Geschäftsinhalten darstellen lässt. Die formale Spezifikation dieser Merkmale mithilfe des ebenfalls in dieser Arbeit entwickelten Semantikvokabulars bildet die Grundlage für das ontologische Matching. Auf Basis der erarbeiteten ontologischen Merkmale wurde eine IDIspezifische Matchingstrategie entwickelt, die es den IDI-Agenten ermöglicht, Geschäftsinhalte interventionsfrei interpretieren zu können. Der Forschungsbeitrag des IDI-Ansatzes besteht in der Anwendung, Erweiterung und Modifikation bestehender Matchingansätze für einen Einsatz in der Anwendungsdomäne IDI. Die IDI-Matchingstrategie beruht auf vier Säulen: ƒ Reduktion des Suchraums durch Hypothesenfalsifikation; A. Köhler, Intelligent Data Interchange (IDI), DOI 10.1007/978-3-8348-9767-1_7, © Vieweg+Teubner Verlag |Springer Fachmedien Wiesbaden GmbH 2010

354

7 Zusammenfassung und Ausblick

ƒ Berechnung mehrerer Äquivalenzindikatoren, um den Übereinstimmungsgrad bestimmter Merkmale zweier Konzeptklassen erfassen zu können; ƒ Aggregation der Äquivalenzindikatoren zu einem Äquivalenzkoeffizienten, der als Ergebnis die Äquivalenzwahrscheinlichkeit der betrachteten Konzeptklassenpaare ausgibt; ƒ Heterogenitätsüberwindung durch die formale Analyse von Heterogenitätsursachen und -effekten sowie einer hieraus formallogisch abgeleiteten Überwindung der Heterogenitätskonflikte.

In Kapitel 6 wurde die grundlegende Funktionsweise des IDI-Matchings anhand zweier Beispielnachrichten demonstriert. Forschungshypothese 2 ist als eingeschränkt verifiziert zu betrachten. Es erscheinen weitere Forschungsanstrengungen nötig zu sein, um die Korrektklassifikationsrate des ontologischen Matchings in der IDI-Architektur weiter steigern zu können. So könnte etwa eine Ausweitung des Einsatzes maschineller Lernverfahren geprüft werden. Die Zielsetzung eines verstärkten Einsatzes maschineller Lernverfahren könnte darin bestehen, die taxonomischen, mereologischen oder Attributkontexte sukzessive während der Laufzeit zu erweitern. So ließen sich etwa die mereologischen und taxonomischen Kontexte der lokalen Konzeptklassen um die Kontexte derjenigen Konzeptklassen ergänzen, die vom lokalen IDI-Agenten als heterogen, von einem menschlichen Aufgabenträger jedoch trotzdem als semantisch äquivalent klassifiziert wurden. Somit würde die Gefahr, auf einen unbekannten Kontext einer ansonsten semantisch äquivalenten Konzeptklasse zu stoßen und diese als inäquivalent oder heterogen zu klassifizieren, beständig abnehmen. Auf der Pragmatikebene konnte dargelegt werden, wie sich aus der Sprechakttheorie ein formalsprachliches Vokabular zur Repräsentation der mit einer Nachricht verbundenen Handlungsabsicht ableiten lässt. Mithilfe des erarbeiteten Vokabulars konnten alle Handlungsabsichten der betrachteten Anwendungsbeispiele repräsentiert werden. In dieser Hinsicht konnte also die Forschungshypothese 3 bestätigt werden.

7 Zusammenfassung und Ausblick

355

Auf der Protokollebene wurden zwei Forschungsschwerpunkte bearbeitet. Zum einen wurde ein Vorschlag zur konzeptionellen Gestaltung von Interaktionsprotokollen vorgestellt. Dieser Vorschlag wurde ebenfalls in ein formales Vokabular überführt. Zum anderen wurde ein Metaprotokoll präsentiert, das die Protokollvereinbarung zwischen IDI-Agenten ermöglicht. Im Rahmen des Anwendungsbeispiels konnte die prinzipielle Funktionsfähigkeit des Metaprotokolls gezeigt werden. Hypothese 4 ist daher, wenigstens hinsichtlich der in diesem Forschungsbeitrag dargestellten Anwendungsszenarien, als verifiziert zu betrachten. Der vorliegende Forschungsbeitrag hat die grundsätzliche Realisierbarkeit eines interventionsfreien Geschäftsdatenaustausches zwischen IDIAgenten in Regelprozessen aufgezeigt. Dabei wurde deutlich, dass zur Umsetzung einer IDI-Architektur die Verfügbarkeit einer global gültigen Domänenontologie als Interoperabilitätsbasis von großer Bedeutung ist. Trotzdem können, das wurde ebenfalls deutlich, Situationen auftreten, in denen ein automatisiertes ontologisches Matching aufgrund von Heterogenität nicht möglich ist. Ein für den elektronischen Geschäftsdatenaustausch wichtiges, in dieser Arbeit jedoch nicht betrachtetes Thema betrifft Fragen der Datensicherheit und Datenintegrität. In klassischen EDI-Systemen werden sicherheitsrelevante Fragen vor Beginn der Nachrichtenübertragung geklärt: ƒ Unbestreitbarkeit des Nachrichtenursprungs ("Non-Repudiation of Origin“), ƒ Unbestreitbarkeit des Nachrichtenempfangs ("Non-Repudiation of Receipt"), ƒ Authentizität des Senders, ƒ Mechanismen zur Sicherstellung der Datenintegrität.

In IDI-Architekturen lassen sich diesbezügliche Vereinbarungen nicht vor Beginn des Nachrichtenaustausches treffen. Somit bleibt zu klären, wie sich hier die Sicherheit und Integrität von Geschäftsdaten gewährleisten lässt.

Anhang A: Literaturverzeichnis Ahlemann et al. 2006 Ahlemann, F.; Teuteberg, F.; Brune, G. (2006): Ontologie-basierte Attributierung von Informationsmodellen: Grundlagen und Anwendungsgebiete. Arbeitsbericht Nr. 01/2006, ISPRI-Forschungszentrum für Informationssysteme in Projekt- und Innovationsnetzwerken, Universität Osnabrück. Ahn et al. 2002 Hyung Jun Ahn, Habin Lee, Hongsoon Yim, Sung Joo Park (2002): Handshaking Mechanism for Conversation Policy Agreements in Dynamic Agent Environment. http://www.agentcities.org/Challenge02/Proc/Papers/ch02_9_ahn.pdf, Abruf am 2006-11-20. Alpar et al. 2008 Alpar, Paul; Gron, Heinz Lothar; Weimann, Peter; Winter, Robert (2008): Anwendungsorientierte Wirtschaftsinformatik – Strategische Planung, Entwicklung und Nutzung von Informations- und Kommunikationssystemen. 5. Aufl., Vieweg-Verlag, Wiesbaden. Anderson 2001 Anderson, John R. (2001): Kognitive Psychologie. 3. Aufl., Akad. Verlag, Heidelberg, Berlin. Antoniou, van Harmelen 2004 Antoniou, Grigoris; van Harmelen, Frank (2004): Web Ontology Language: OWL. In: Staab, Steffen; Studer, Rudi (Editors): Handbook on Ontologies. Springer Verlag, Berlin, Heidelberg, S. 67-92. Austin 1979 Austin, John L. (1979): Zur Theorie der Sprechakte (How to do things with words). Deutsche Bearbeitung von Eike von Savigny, 2. Aufl., Reclam, Stuttgart.

A. Köhler, Intelligent Data Interchange (IDI), DOI 10.1007/978-3-8348-9767-1, © Vieweg+Teubner Verlag |Springer Fachmedien Wiesbaden GmbH 2010

358

Anhang A: Literaturverzeichnis

Apel, Habermas 2004 Apel, K.-O.; Habermas, J. (2004): Pragmatik. In: Mittelstraß, Jürgen (Hrsg.): Enzyklopädie Philosophie und Wissenschaftstheorie, Bd. 3, Sonderausgabe, J.B. Metzler, S. 323. Baader et al. 2004 Baader, Franz; Horrocks, Ian; Sattler, Ulrike (2004): Description Logics. In: Staab, Steffen; Studer, Rudi (Editors): Handbook on Ontologies. Springer Verlag, Berlin, Heidelberg, S. 3-28. Baader, Nutt 2002 Baader, Franz; Nutt, Werner (2002): Basic Description Logics. In: Baader, Franz; McGuinness, Deborah; Nardi, Daniele, Patel-Schneider, Peter (Eds.): The Description Logic Handbook: Theory, implementation, and applications. Cambridge University Press, S. 47-100. Baeza-Yates, Ribeiro-Neto 1999 Baeza-Yates, Ricardo; Ribeiro-Neto, Berthier (1999): Modern Information Retrieval. ACM Press, New York. Bamberg, Baur 2002 Bamberg, Günter; Baur, Franz (2002): Statistik. 12. Aufl., Oldenbourg Verlag, München, Wien. Bauer et al. 2001 Bauer, Bernhard; Müller, Jörg P.; Odell, James (2001): Agent UML: A Formalism for Specifying Multiagent Interaction. In: Ciancarini, Paolo; Wooldridge, Michael (Eds.): Agent-Oriented Software Engineering. First International Workshop, AOSE 2000, Springer-Verlag, Berlin, S. 91-103. Baumgarten 1996 Baumgarten, Bernd (1996): Petri-Netze, Grundlagen und Anwendungen. 2. Aufl., Spektrum Akademischer Verlag, Heidelberg, Berlin, Oxford. Berges et al. 2008 Berges, Idoia; Bermúdez, Jesús; Goni, Alredo; Riarramendi, Arantza (2008): Semantic Web Technology for Agent Communication Protocols. In: Bechhofer, Sean; Hauswirth, Manfred; Hoffmann, Jörg; Koubarakis, Manolis (Eds.): The Semantic Web: Research and Applications. 5th European Semantic Web Conference, ESWC 2008, Proceedings, Springer Verlag, Berlin et al., S. 5-18.

Anhang A: Literaturverzeichnis

359

Becker, Pfeiffer 2006 Becker, Jörg; Pfeiffer, Daniel (2006): Konzeptionelle Modelle in der Wirtschaftsinformatik — Konstruktion und Evaluation. In: WISU 12/06, S. 1551-1557. Berlin, Motro 2001 Berlin, Jacob; Motro, Amihai (2001): Autoplex: Automated Discovery of Content for Virtual Databases. In: Lecture Notes In Computer Science, Vol. 2172, Proceedings of the 9th International Conference on Cooperative Information Systems, Springer-Verlag, S. 108-122. Besana, Robertson 2005 Besana, Paolo; Robertson, Dave (2005): Contexts in Dynamic Ontology Mapping. In: Shvaiko, Pavel et al. (Eds.): Contexts and Ontologies: Theory, Practice and Applications. Papers from the 2005 AAAI Workshop, American Association for Artificial Intelligence, Menlo Park, S. 92-95. Verwendete Online-Version: http://homepages.inf.ed.ac.uk/s0454959/docs/WS105BesanaP.pdf, Abruf am 2008-05-10. Bibel et al. 1993 Bibel, Wolfgang; Hölldobler, Steffen; Schaub, Torsten (1993): Wissensrepräsentation und Inferenz – Eine grundlegende Einführung. ViewegVerlag, Braunschweig, Wiesbaden. Bijlsma 2002 Bijlsma, Marcel; Fielt, Erwin; Koolwaaij, Johan (2002): Web Services and Business-to-Business Integration, Project reference GigaTS/D3.1.7, Telematica Instituut, Niederlande. Bilenko et al. 2003 Bilenko, Mikhail; Mooney, Raymond; Cohen, William; Ravikumar, Pradeep; Fienberg, Stephen (2003): Adaptive Name Matching in Information Integration. In: IEEE Intelligent Systems, Vol. 18, Issue 5, S. 16-23. Biron, Malhotra 2004 Biron, Paul V.; Malhotra, Ashok (Editors): XML Schema Part 2: Datatypes. 2nd Edition, W3C Recommendation. http://www.w3.org/TR/xmlschema-2/, Abruf am 2007-11-21.

360

Anhang A: Literaturverzeichnis

Borgelt et al. 2000 Borgelt, Christian; Timm, Heiko; Kruse, Rudolf (2000): Unsicheres und vages Wissen. In: Görz, Günter; Rollinger, Claus-Rainer; Schneeberger, Josef (Hrsg.): Handbuch der Künstlichen Intelligenz. 3. Aufl., OldenbourgVerlag, München, Wien, S. 291-347. Bornhövd 2001 Bornhövd, Christof (2001): Semantikbeschreibende Metadaten zur Integration heterogener Daten aus dem Internet. Shaker Verlag. Bouquet et al. 2005 Bouquet, Paolo et al. (2005): Specification of a common framework for characterizing alignment, Document Identifier KWEB/2004/D2.2.1/v2.0, Version 2.0 (final), Projektbericht. Brachman, Levesque 2004 Brachman, Ronald J.; Levesque, Hector J. (2004): Knowledge Representation and Reasoning. Morgan Kaufmann Publishers, San Francisco. Bullinger et al. 1997 Bullinger, Hans-Jörg; Wörner, Kai; Prieto, Juan (1997): Wissensmanagement heute. Daten, Fakten, Trends, Studie des Instituts für Arbeitswissenschaft und Organisation, Fraunhofer Gesellschaft. Calvanese et al. 1998 Calvanese, D.; Lenzerini, M.; Nardi, D. (1998): Description Logics for Conceptual Data Modeling. In: Chomicki, J.; Saake, G. (Eds.): Logics for Databases and Information Systems. Kluwer, S. 229-264. Carnap 1968 Carnap, Rudolf (1968): Logische Syntax der Sprache. 2. Aufl., SpringerVerlag, Wien, New York. Castano et al. 2006 Castano, Silvana; Ferrara, Alfio; Montanelli, Stefano (2006): Matching Ontologies in Open Networked Systems: Techniques and Applications. In: Spaccapletra, S. et al. (Eds.): Journal on Data Semantics V. LNCS 3870, Springer-Verlag, Berlin, Heidelberg, S. 25-63.

Anhang A: Literaturverzeichnis

361

Cavnar, Trenkle 1994 Cavnar, William B.; Trenkle, John M. (1994): N-Gram-Based Text Categorization. In: Proceedings of the Third Annual Symposium on Document Analysis and Information Retrieval, Las Vegas, S. 161-175. Verwendete Online-Version: http://www.info.unicaen.fr/~giguet/classif/cavnar_trenkle_ngram.ps, Abruf am 2008-04-20. Chaib-Draa, Dignum 2002 Chaib-Draa, B.; Dignum, F. (2002): Trends in agent communication languages. In: Computational Intelligence, Vol.18, No.2, S. 89-101. Chen et al. 2005 Chen, Warren; Li, Xin; Dioan, AnHai (2005): Constraint-Based Entity Matching, in: Veloso, Manuela M.; Kambhampati, Subbarao (Eds.): Proceedings of The Twentieth National Conference on Artificial Intelligence and the Seventeenth Innovative Applications of Artificial Intelligence Conference (AAAI), The MIT Press, S. 862-867. Verwendete Online-Version: http://pages.cs.wisc.edu/~whshen/papers/cmediate.pdf, Abruf am 2008-01-19. Chinnici et al. 2007 Chinnici, Roberto et al. (2007): Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language. http://www.w3.org/TR/wsdl20/, Abruf am 2008-10-20. Clark, Cormack 1997 Clarke, Charles L. A.; Cormack, Gordon V. (1997): On the use of regular expressions for searching text. In: ACM Transactions on Programming Languages and Systems (TOPLAS), Vol. 19, Issue 3, S. 413-426. Clement et al. 2004 Clement, Luc et al. (Eds.)(2004): UDDI Version 3.0.2. http://uddi.org/pubs/uddi_v3.htm, Abruf am 2008-10-20.

362

Anhang A: Literaturverzeichnis

Cohen et al. 2003 Cohen, William W.; Ravikumar, Pradeep; Fienberg, Stephen E. (2003): A comparison of string distance metrics for name-matching tasks. In: Proceedings of the IJCAI-2003 Workshop on Information Integration on the Web. Verwendete Online-Version: http://www.isi.edu/info-agents/workshops/ijcai03/papers/Cohen-p.pdf, Abruf am 2007-10-01. Davis et al. 1993 Davis, Randall; Shrobe, Howard; Szolovits, Peter (1993): What is a Knowledge Representation? In: AI Magazine, Vol. 14(1), S. 17-33. Deutsch 1995 Deutsch, Markus (1995): Unternehmenserfolg mit EDI: Strategie und Realisierung des elektronischen Datenaustausches. Vieweg-Verlag, Braunschweig. DIN 1998 DIN (Hrsg.) (1998): EDIFACT-Syntax Version 4. 2. Aufl., Beuth Verlag, Berlin, Wien, Zürich. Do, Rahm 2002 Do, Hong-Hai; Rahm, Erhard: COMA – A System for Flexible Combination of Schema Matching Approaches. http://www.cse.ust.hk/vldb2002/VLDB2002proceedings/papers/S17P03.pdf, Abruf am 2006-12-05. Do et al. 2002 Do, Hong-Hai; Melnik, Sergey; Rahm, Erhard (2002): Comparison of Schema Matching Evaluations. http://www.izbi.unileipzig.de/izbi/publikationen/publi_2002/do_showDoc.pdf, Abruf am 2008-02-10. Doan 2002 Doan, AnHai (2002): Learning to map between Structured Representations of Data. Dissertation, University of Washington.

Anhang A: Literaturverzeichnis

363

Doan et al. 2002 Doan, AnHai; Madhavan, Jayant; Domingos, Pedro; Halevy, Alon (2002): Learning to Map between Ontologies on the Semantic Web. In: Proceedings of the 11th international conference on World Wide Web, Hawaii 2002, S. 662-673. Ehrig, Staab 2004 Ehrig, Marc; Staab, Steffen (2004): Efficiency of Ontology Mapping Approaches. In: Euzenat, Jerome et al (Eds.): Semantic Intelligent Middleware for the Web and the Grid. Proceedings of the ECAI 2004 Workshop on Semantic Intelligent Middleware for the Web and the Grid, Valencia. Verwendete Online-Version: http://ftp.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-111/05Ehrig.pdf, Abruf am 2008-02-11. Ehrig, Sure 2004 Ehrig, Marc; Sure, York (2004): Ontology Mapping – An Integrated Approach. In: Bussler, Christoph; Davies, John; Fensel, Dieter; Studer, Rudi (Eds.): The Semantic Web: Research and Applications. First European SemanticWeb Symposium, ESWS 2004, Proceedings, Lecture Notes in Computer Science, Vol. 3053, S. 76-91. Euzenat et al. 2004 Euzenat, Jérôme (Coordinator) et al. (2004): State of the art on ontology alignment. Doc.-No. KWEB/2004/D2.2.3/v1.2, final, Knowledge Web Consortium. Euzenat, Shvaiko 2007 Euzenat, Jérôme; Shvaiko, Pavel (2007): Ontology Matching. SpringerVerlag, Berlin, Heidelberg. Fensel 2000 Fensel, Dieter (2000): Ontologies: silver bullet for knowledge management and electronic commerce. Springer Verlag, Berlin, Heidelberg. Ferber 2001 Ferber, Jacques (2001): Multiagentensysteme. Eine Einführung in die Verteilte Künstliche Intelligenz. Addison-Wesley Verlag, München.

364

Anhang A: Literaturverzeichnis

Ferber 2003 Ferber, Reginald (2003): Information Retrieval, Suchmodelle und DataMining-Verfahren für Textsammlungen und das Web. 1. Aufl., DpunktVerlag, Heidelberg. Ferstl 1979 Ferstl, Otto K. (1979): Konstruktion und Analyse von Simulationsmodellen. Beiträge zur Datenverarbeitung und Unternehmensforschung, Bd. 22, Hain Verlag, Königstein/Ts. Feßenbecker 2002 Feßenbecker, Matthias (2002): Zahlreiche B-to-B-Standards konkurrieren. http://www.computerwoche.de/1060228, Abruf am 2008-10-15. Finch 2005 Finch, Holmes (2005): Comparison of Distance Measures in Cluster Analysis with Dichotomous Data. In: Journal of Data Science, Vol. 3, No. 1, S. 85100. Finin et al. 1993 Finin, Tim et al. (1993): DRAFT Specification of the KQML Agent Communication Language. The DARPA Knowledge Sharing Initiative, External Interfaces Working Group. FIPA 2002 Foundation for Intelligent Physical Agents (2002): FIPA ACL Message Structure Specification. Document number SC00061G. Fleisch et al. 2003 Fleisch, Elgar; Mattern, Friedemann; Billinger, Stephan (2003): Betriebswirtschaftliche Applikationen des Ubiquitous Computing – Beispiele, Bausteine und Nutzenpotentiale. http://www.vs.inf.ethz.ch/publ/papers/BW_ApplUbicomp.pdf, Abruf am 2008-10-25. Foxvog, Bussler 2005 Foxvog, Douglas; Bussler, Christoph (2005): Ontologizing EDI: First Steps and Initial Experience. In: Proceedings of the International Workshop on Data Engineering Issues in E-Commerce. Washington DC, S. 49-58.

Anhang A: Literaturverzeichnis

365

Frank, Schauer 2001 Frank, Ulrich; Schauer, Hanno (2001): Potentiale und Herausforderungen des Wissensmanagements aus der Sicht der Wirtschaftsinformatik. In: Schreyögg, Georg (Hrsg.): Wissen in Unternehmen: Konzepte – Maßnahmen – Methoden. Erich Schmidt Verlag, Berlin, S. 163-182. Geibig 2007 Geibig, Oliver (2007): Agentenbasierte Unterstützung Öffentlicher Ausschreibungen von Bauleistungen unter Verwendung von Methoden der Künstlichen Intelligenz. Dissertation, Fachbereich Bauwissenschaften, Universität Duisburg-Essen. Goldfarb, Prescod 1999 Goldfarb, Charles F.; Prescod, Paul (1999): XML-Handbuch. Prentice Hall, München et al. Gruber 1993 Gruber, Thomas R. (1993): Towards Principles for The Design of Ontologies Used for Knowledge Sharing. Technical Report KSL 93-04, Knowledge Systems Laboratory, Stanford University. Gudgin et al. 2007 Gudgin, Martin et al. (2007): SOAP Version 1.2 Part 1: Messaging Framework. http://www.w3.org/TR/soap12-part1, Abruf am 2008-10-20. Guarino 1998 Guarino, Nicola (1998): Formal Ontology and Information Systems. Amended version of a paper appeared in: Guarino, Nicola (Ed.): Formal Ontology in Information Systems. Proceedings of FOIS'98, Trento, Italy, IOS Press, S. 3-15. Verwendete Online-Version: www.loa-cnr.it/Papers/FOIS98.pdf, Abruf am 2008-02-25. Habermann 2001 Habermann, Frank (2001): Management von Geschäftsprozesswissen – ITbasierte Systeme und Architektur. Deutscher Universitäts-Verlag, Wiesbaden. Haefner 2000 Haefner, Klaus (2000): Gewinnung und Darstellung wissenschaftlicher Erkenntnisse, insbesondere für universitäre Studien, Staatsexamens-, Dip-

366

Anhang A: Literaturverzeichnis lom- und Doktorarbeiten. Oldenbourg Wissenschaftsverlag, München, Wien.

Hakimpour, Geppert 2002 Hakimpour, Farshad; Geppert, Andreas (2002): Global Schema Generation Using Formal Ontologies. In: Spaccapietra, Stefano; March, Salvatore T. ; Kambayashi, Yahiko (Eds.): Proceedings of the 21st International Conference on Conceptual Modeling. Lecture Notes In Computer Science; Vol. 2503, Springer-Verlag, London, S. 307-321. Hasenkamp, Roßbach 1998 Hasenkamp, Ulrich; Roßbach, Peter (1998): Wissensmanagement. In: WISU, Heft 8-9, 27. Jg., S. 956-963. Haun 2000 Haun, Matthias (2000): Wissensbasierte Systeme – Eine praxisorientierte Einführung. Expert-Verlag, Renningen-Malmsheim. Heinsohn, Socher-Ambrosius 1999 Heinsohn, Jochen; Socher-Ambrosius, Rolf (1999): Wissensverarbeitung: eine Einführung. Spektrum Akademischer Verlag, Heidelberg, Berlin. Helbig 1996 Helbig, Hermann (1996): Künstliche Intelligenz und automatische Wissensverarbeitung. 2. Aufl., Berlin. Hennings 1991 Hennings, Ralf-Dirk (1991): Informations- und Wissensverarbeitung: Theoretische Grundlagen Wissensbasierter Systeme. De Gruyter Verlag, Berlin, New York. Herden, Hein 1990 Herden, W.; Hein, H.-W. (Hrsg.)(1990): Kurzlexikon Wissensbasierte Systeme. Oldenbourg Verlag, München, Wien. Hermes 1991 Hermes, Hartmut (1991): Syntax-Regeln für den elektronischen Datenaustausch. In: DIN Deutsches Institut für Normung e.V. (Hrsg.), Einführung in EDIFACT. 4. Aufl., Berlin, S. 7-12.

Anhang A: Literaturverzeichnis

367

Hesse 2002 Hesse, Wolfgang (2002): Ontologien. In: Informatik Spektrum, Band 25, Heft 6, S. 477-480. Hitzler et al. 2008 Hitzler, Pascal et al.: Semantic Web – Grundlagen. 1. Aufl., Springer Verlag 2008. Hofreiter, Huemer 2002 Hofreiter, Birgit; Huemer, Christian (2002): B2B Integration – Aligning ebXML and Ontology Approaches. In: Shafazand, Hassan; Tjoa, A Min (Eds.): EurAsia-ICT 2002: Information and Communication Technology. Proceedings, Lecture Notes In Computer Science; Vol. 2510, Springer Verlag, S. 339-349. Hopcroft et al. 2002 Hopcroft, John E.; Motwani, Rajeev; Ullman, Jeffrey D. (2002): Einführung in die Automatentheorie, Formale Sprachen und Komplexitätstheorie. 2., überarbeitete Aufl., Pearson Studium. Horrocks et al. 2000 Horrocks, I. et al. (2000): The Ontology Inference Layer OIL. http://www.ontoknowledge.org/oil/TR/oil.long.html, Abruf am 2004-10-15. Horrocks, Patel-Schneider 2003 Horrocks, Ian; Patel-Schneider, Peter F. (2003): Reducing OWL Entailment to Description Logic Satisfiability. In: Fensel, Dieter; Sycara, Katia; Mylopoulos, John (Eds.): The Semantic Web – ISWC 2003. Second International Semantic Web Conference, Sanibel Island, Proceedings, Lecture Notes in Computer Science, Vol. 2870, Springer-Verlag, S. 17-29. Horrocks, Sattler 2001 Horrocks, Ian; Sattler, Ulrike (2001): Ontology reasoning in the SHOQ(D) description logic. In: Proceedings of the Seventeenth International Joint Conference on Artificial Intelligence (IJCAI 2001), Seattle, Washington, Morgan Kaufmann, S. 199-204.

368

Anhang A: Literaturverzeichnis

Jakobs 2007 Jakobs, Holger (2007): XML: Schemas. https://www.bg.bib.de/portale/xml/pdf/XML-Schema.pdf, Abruf am 2008-10-12. Kalfoglou et al. 2005 Kalfoglou, Y. et al. (2005): Semantic Integration Technologies Survey. CROSI project, 6th month deliverable, University of Southampton, Technical Report. Kalfoglou, Schorlemmer 2003 Kalfoglou, Yannis; Schorlemmer, Marco (2003): Ontology mapping: the state of the art. In: The Knowledge Engineering Review, Vol. 18, Issue 1, Cambridge University Press, S. 1-31. Karttunen et al. 1996 Karttunen, L.; Chanod, J.-P.; Grefenstette, G.; Schiller, A. (1996): Regular expressions for language engineering. In: Natural Language Engineering, Vol. 2, Issue 4, Cambridge University Press, S. 305-328. Kastens, Kleine Büning 2005 Kastens, Uwe; Kleine Büning, Hans (2005): Modellierung. Grundlagen und formale Methoden. Carl Hanser Verlag, München, Wien. Kelly 2003 Kelly, John (2003): Logik im Klartext, Pearson Studium, München. Klein 2001 Klein, Michel (2001): Combining and relating ontologies: an analysis of problems and solutions. http://www.let.uu.nl/~paola.monachesi/personal/papers/klein.pdf, Abruf am 2007-12-22. König et al. 1999 König, Wolfgang et al. (Hrsg.)(1999): Taschenbuch der Wirtschaftsinformatik und Wirtschaftsmathematik. 1. Aufl., Verlag Harry Deutsch, Frankfurt a.M., Thun. Küster 2003 Küster, Marc Wilhelm (2003): Web Services – Versprechen und Realität. In: Fröschle, Hans-Peter (Hrsg.): Web-Services. HMD 234, Dpunkt-Verlag, Heidelberg, S. 5-15.

Anhang A: Literaturverzeichnis

369

Lakemeyer, Nebel 1994 Lakemeyer, Gerhard; Nebel, Bernhard (1994): Foundations of Knowledge Representation and Reasoning. In: Lakemeyer, Gerhard; Nebel, Bernhard (Hrsg.): Foundations of Knowledge Representation and Reasoning. Springer-Verlag, Berlin, Heidelberg, New York, S. 1-12. Lamprecht 1998 Lamprecht, Axel (1998): Elektronischer Datenaustausch (EDI) in Verbundgruppen. Dt. Univ.-Verl., Wiesbaden. Lehmann, Ortner 1997 Lehmann, Frank R.; Ortner, Erich (1997): Entwicklung von WorkflowManagement-Anwendungen im Kontext von Geschäftsprozeß- und Organisationsmodellierung. In: Information Management 4/97, S. 62-69. Levenstein 1966 Levenstein, Vladimir I. (1966): Binary codes capable of correcting deletions, insertions, and reversals. In: Doklady Akademii Nauk SSSR, 163(4) S. 845-848, 1965 (Russisch). Englische Übersetzung in: Soviet Physics Doklady, 10(8) S. 707-710. Levinson 1994 Levinson, Stephen C. (1994): Pragmatik. Ins Deutsche übersetzt von Ursula Fries, 2. Aufl., Max Niemeyer Verlag, Tübingen. Lewis 1998 Lewis, David D. (1998): Naive (Bayes) at Forty: The Independence Assumption in Information Retrieval. In: Nédellec, Claire; Rouveirol, Céline (Eds.): Machine Learning: ECML-98, Proceedings of the 10th European Conference on Machine Learning, Lecture Notes In Computer Science, Vol. 1398, Springer Verlag, Berlin et al., S. 4-15. Löbner 2003 Löbner, Sebastian (2003): Semantik. Eine Einführung. De Gruyter Studienbuch, Walter de Gruyter, Berlin, New York. Lorenz 2004a Löbner, Sebastian (2003): Semantik. Eine Einführung. De Gruyter Studienbuch, Walter de Gruyter, Berlin, New York.

370

Anhang A: Literaturverzeichnis

Lorenz 2004b Lorenz, Kuno (2004): Semantik. In: Mittelstraß, Jürgen (Hrsg.): Enzyklopädie Philosophie und Wissenschaftstheorie. Bd. 3, Sonderausgabe, J.B. Metzler, S. 768-775. Luger 2001 Luger, Georg F. (2001): Künstliche Intelligenz, Strategien zur Lösung komplexer Probleme. 4. Aufl., Pearson Studium, München. Madhavan et al. 2001 Madhavan, Jayant; Bernstein, Philip A.; Rahm, Erhard (2001): Generic Schema Matching with Cupid. Technical Report MSR-TR-2001-58, Microsoft Corporation. Magnini et al. 2002 Magnini, Bernardo; Serafini, Luciano; Speranza, Manuela (2002): Linguistic Based Matching of Local Ontologies. In: Bouquet, Paolo (Chair): Meaning Negotiation. Papers from the AAAI Workshop, Technical Report WS02-09, AAAI Press, S. 42-50. Verwendete Online-Version: http://sra.itc.it/people/serafini/distribution/aaai-ws-ctxmatch.pdf, Abruf am 2008-08-02. Manola, Miller 2004 Manola, Frank; Miller, Eric (2004): RDF Primer. http://www.w3.org/TR/rdf-primer/, Abruf am 2008-10-28. Mattern 2003 Mattern, Friedemann (2003): Vom Verschwinden des Computers – Die Vision des Ubiquitous Computing. In: Mattern, Friedemann (Hrsg.): Total vernetzt: Szenarien einer informatisierten Welt. 7. Berliner Kolloquium Gottlieb Daimler- und Karl Benz-Stiftung, Springer-Verlag, Berlin, S. 1-41. Meibauer 2001 Meibauer, Jörg (2001): Pragmatik: eine Einführung. 2. Aufl., Stauffenburg Verlag, Tübingen. Melnik et al. 2002 Melnik, Sergey; Garcia-Molina, Hector; Rahm, Erhard (2002): Similarity Flooding: A Versatile Graph Matching Algorithm and Its Application to Schema Matching. In: Agrawal, Rakesh; Dittrich, Klaus; Ngu, Anne H.H.:

Anhang A: Literaturverzeichnis

371

Proceedings of the 18th International Conference on Data Engineering, IEEE Computer Society, S. 117-128. Milo, Zohar 1998 Milo, Tova; Zohar, Sagit (1998): Using Schema Matching to Simplify Heterogeneous Data Translation. In: Proceedings of the 24rd International Conference on Very Large Data Bases, Morgan Kaufmann Publishers, S. 122-133. Mohammad, Hirst 2005 Mohammad, Saif; Hirst, Graeme (2005): Distributional measures as proxies for semantic relatedness. http://www.umiacs.umd.edu/~saif/WebDocs/MohammadHirst.pdf, Abruf am 2007-06-20. Moore 1998 Moore, Scott A. (1998): Categorizing automated messages. In: Decision Support Systems, Vol. 22, Issue 3, Elsevier Sience Publishers B.V., S. 213241. Moore 2000 Moore, Scott A. (2000): A foundation for flexible automated electronic communication. Working Paper, University of Michigan Business School. Müller-Berg 1995 Müller-Berg, Tanja (Hrsg.)(1995): EDI-Knigge, Elektronischer Datenaustausch am Beispiel der Ausschreibung, Vergabe und Abrechnung (AVA) von Bauleistungen. 1. Aufl., Springer-Verlag, Berlin, Heidelberg. Nardi, Brachman 2002 Nardi, Danile; Brachman, Ronald J. (2002): An Introduction to Description Logics. In: Baader, Franz; McGuinness, Deborah; Nardi, Daniele, PatelSchneider, Peter (Eds.): The Description Logic Handbook: Theory, implementation, and applications. Cambridge University Press, S. 5-44. Nowostawski et al. 2001 Nowostawski, Mariusz; Purvis, Martin; Cranefield, Stephen (2001): A Layered Approach for Modelling Agent Conversations. The Information Science Discussion Paper Series, Number 2001/05, University of Otago, New Zealand.

372

Anhang A: Literaturverzeichnis

Noy 2005 Noy, Natasha (2005): Representing Classes As Property Values on the Semantic Web. W3C Working Group Note, http://www.w3.org/TR/2005/NOTE-swbp-classes-as-values-20050405/, Abruf am 2007-20-10. Noy, Musen 2002 Noy, Natalya F.; Musen, Mark A. (2002): Evaluating Ontology-Mapping Tools. SMI Report SMI-2002-0936, Stanford Medical Informatics, Stanford. o.V. 1993 o.V. (1993): Electronic Data Interchange – Streamlining Business Communication. 2. Aufl., Computer Technology Research Corp., Charleston. o.V. 2004 o.V. (2004): RFID – Bedeutung für die Logistik. Netzwerk Elektronischer Geschäftsverkehr, Bremen. OASIS 2002 OASIS (2002): Collaboration-Protocol Profile and Agreement Specification Version 2.0, http://www.oasis-open.org/committees/download.php/204/ebcpp-2.0.pdf, Abruf am 2008-10-10. Odell et al. 2001 Odell, James; Van Dyke Parunak, H.; Bauer, Bernhard (2001): Representing Agent Interaction Protocols in UML. In: Ciancarini, Paolo; Wooldridge, Michael (Eds.): Agent-Oriented Software Engineering. First International Workshop, AOSE 2000, Springer-Verlag, Berlin, S. 121-140. Paurobally, Cunningham 2002 Paurobally, Shamimabi; Cunningham, Jim (2002): Achieving common interaction protocols in open agent environments. In: Proceedings of the 2nd international workshop on Challenges in Open Agent Environments, Melbourne. Verwendete Online-Version: http://www.agentcities.org/Challenge03/Proc/Papers/ch03_paurobally.pdf, Abruf am 2005-09-15.

Anhang A: Literaturverzeichnis

373

Pan, Horrocks 2002 Pan, Jeff Z.; Horrocks, Ian (2002): Extending Datatype Support in Web Ontology Reasoning. In: Meersman, Robert; Zahir, Tari (Eds.): On the Move to Meaningful Internet Systems 2002: CoopIS, DOA, and ODBASE. Confederated International Conferences CoopIS, DOA, and ODBASE 2002, Proceedings, Lecture Notes in Computer Science, Vol. 2519, SpringerVerlag, Berlin et al., S. 1067-1081. Pan, Horrocks 2003 Pan, Jeff Z.; Horrocks, Ian (2003): Web Ontology Reasoning with Datatype Groups. In: Fensel, D.; Sycara, K.; Mylopoulos, J. (Eds.): The Semantic Web – ISCW 2003. Proc. of the 2nd International Semantic Web Conference, Lecture Notes in Computer Science, Springer-Verlag, Berlin et al., S. 47-63. Pan, Horrocks 2004 Pan, Jeff Z.; Horrocks, Ian (2004): OWL-E: Extending OWL with Expressive Datatype Expressions. Document Identifier IMG/2004/KR-SW-01/v1.0, IMG Technical Report, Information Management Group, School of Computer Science, University of Manchester. Pearl 1988 Pearl, Judea (1988): Probabilistic Reasoning in Intelligent Systems: Networks of Plausible Inference. Revised Second Printing, Morgan Kaufmann Publishers, San Francisco. Picot et al. 2003 Picot, Arnold; Reichwald, Ralf; Wigand, Rolf T. (2003): Die grenzenlose Unternehmung: Information, Organisation und Management. 5. Aufl., Gabler Verlag, Wiesbaden. Picot, Rohrbach 1995 Picot, Arnold; Rohrbach, Peter (1995): Organisatorische Aspekte von Workflow-Management-Systemen. In: Information Management 1/95, S. 28-35. Predoiu et al. 2005 Predoiu, Livia et al. (2005): State-of-the-art survey on Ontology Merging and Aligning. Report, Deliverable D4.2.2, Digital Enterprise Research Institute, University of Innsbruck.

374

Anhang A: Literaturverzeichnis

›’Ž‹ŽȱŽȱŠ•ǯȱŘŖŖśȱ ȱPriebe, Torsten; Kolter, Jan; Kiss, Christine (2005): Semiautomatische Annotation von Textdokumenten mit semantischen Metadaten. In: Proc. 7. Internationale Tagung Wirtschaftsinformatik (WI 2005), Bamberg, S. 13091328. PTB 2004 Physikalisch Technische Bundesanstalt (Hrsg.)(2004): Die gesetzlichen Einheiten in Deutschland. Broschüre, Braunschweig, http://www.ptb.de/de/publikationen/download/einheiten.pdf, Abruf am 08.04.2007. Puppe et al. 2000 Puppe, F.; Stoyan, H.; Studer, R. (2000): Knowledge Engineering. In: Görz, Günter; Rollinger, Claus-Rainer; Schneeberger, Josef (Hrsg.): Handbuch der Künstlichen Intelligenz. 3. Aufl., Oldenbourg-Verlag, München, Wien, S. 599-641. Quantz, Wichmann 2003 Quantz, Joachim; Wichmann, Thorsten (2003): E-Business Standards in Deutschland – Bestandsaufnahme, Problem, Perspektiven. Ein Forschungsauftrag des Bundesministeriums für Wirtschaft und Arbeit, Berlecon Research, Berlin. Rahm, Bernstein 2001a Rahm, Erhard; Bernstein, Philip A. (2001): A survey of approaches to automatic schema matching. In: The VLDB Journal, The International Journal on Very Large Data Bases, Volume 10, Issue 4, Springer-Verlag, S. 334-350. Rahm, Bernstein 2001b Rahm, Erhard; Bernstein, Philip A. (2001): On Matching Schemas Automatically. Report Nr. 1(2001), Institut für Informatik, Universität Leipzig. Ray 2004 Ray, Erik T. (2004): Einführung in XML. 2. Aufl., O'Reilly Verlag, Köln. Rebstock et al. 2008 Rebstock, Michael; Fengel, Janina; Paulheim, Heiko (2008): OntologiesBased Business Integration. Springer-Verlag, Berlin, Heidelberg.

Anhang A: Literaturverzeichnis

375

Reed et al. 2002 Reed, Chris; Norman, Timothy J.; Jennings, Nicolas R. (2002): Negotiating the Semantics of Agent Communication Languages. In: Computational Intelligence, Vol. 18, Number 2, S. 229-252. Reimer 1991 Reimer, Ulrich (1991): Einführung in die Wissensrepräsentation: netzartige und schemabasierte Repräsentationsformate. Teubner-Verlag, Stuttgart. Rodriguez, Egenhofer 2003 Rodriguez, Andrea M.; Egenhofer, Max J. (2003): Determining Semantic Similarity among Entity Classes from Different Ontologies. In: IEEE Transactions on Knowledge and Data Engineering, Vol. 15, Issue 2, S. 442456. Roman et al. 2005 Roman, Dumitru et al. (2005): Web Service Modeling Ontology. In: Applied Ontology, Vol. 1, No. 1/2005, IOS Press, S. 77-106. Russel, Norvig 2004 Russel, Stuart; Norvig, Peter (2004): Künstliche Intelligenz – Ein moderner Ansatz. 2. Aufl., Pearson Studium, München. Scheckenbach 1997 Scheckenbach, Rainer (1997): Semantische Geschäftsprozessintegration. Dt. Univ.-Verl., Wiesbaden. Scheckenbach, Zeier 2003 Scheckenbach, Rainer; Zeier, Alexander (2003): Collaborative SCM in Branchen. 1. Aufl., Galileo Press, Bonn. Schefe 1986 Schefe, Peter (1986): Künstliche Intelligenz, Überblick und Grundlagen: grundlegende Konzepte und Methoden zur Realisierung von Systemen der künstl. Intelligenz, Mannheim, Wien, Zürich. Schmid, Kindsmüller 1996 Schmid, Ute; Kindsmüller, Martin Christof (1996): Kognitive Modellierung. Eine Einführung in die logischen und algorithmischen Grundlagen. Spektrum Akademische Verlag, Heidelberg, Berlin, Oxford.

376

Anhang A: Literaturverzeichnis

Schmoll, Nommensen 1996 Schmoll, Thomas; Nommensen, Olaf (1996): EDI: Wettbewerbsvorteile durch electronic Business. Markt und Technik, Haar bei München. Schoch, Strassner 2003 Schoch, Thomas; Strassner, Martin (2003): Wie smarte Dinge Prozesse unterstützen. http://www.vs.inf.ethz.ch/res/papers/Smarte-DingeProzessunterstuetzung.pdf, Abruf am 2008-10-26. Schulze 2001 Schulze, Dirk (2001): Grundlagen der wissensbasierten Konstruktion von Modellen betrieblicher Systeme. Shaker-Verlag. Schwarz et al. 2001 Schwarz, Sven; Abecker, Andreas; Maus, Heiko; Sintek, Michael (2001): Anforderungen an die Workflow-Unterstützung für wissensintensive Geschäftsprozesse. In: Proceedings des Workshops „Geschäftsprozessorientiertes Wissensmanagement“ auf der WM'2001, Baden-Baden. Verwendete Online-Version: http://www.dfki.unikl.de/~schwarz/docs/SchwarzAbeckerMausSintek2001.pdf, Abruf am 2008-05-14. Schwarz, Chur 2004 Schwarz, Monika; Chur, Jeannette (2004): Semantik. Ein Arbeitsbuch. 4. Aufl., Gunter Narr Verlag, Tübingen. Searle 1983 Searle, John R. (1983): Sprechakte, ein sprachphilosophischer Essay. Übersetzt von R. und R. Wiggershaus, Suhrkamp. Shapiro 1998 Shapiro, Stuart C. (1998): Belief Revision and Truth Maintenance Systems: An Overview and a Proposal. CSE Technical Report 98-10, Department of Computer Science and Engineering, State University of New York. Sheth, Kashyap 1992 Sheth, A. ; Kashyap, V. (1992): So Far (Schematically) yet So Near (Semantically). http://knoesis.wright.edu/library/download/SK92b.pdf, Abruf am 2006-11-20.

Anhang A: Literaturverzeichnis

377

Shvaiko 2004 Shvaiko, Pavel (2004): A Classification of Schema-Based Matching Approaches. Technical Report DIT-04-093, Informatica e Telecomunicazioni, University of Trento. Shvaiko, Euzenat 2004 Shvaiko, Pavel; Euzenat, Jerome (2004): A Survey of Schema-based Matching Approaches. Technical Report DIT-04-087, Informatica e Telecomunicazioni, University of Trento. Singh 1993 Singh, Munindar P. (1993): A semantics for speech acts. In: Annals of Mathematics and Artificial Intelligence, Vol. 8, No. (1-2), S 47-71. Sinz 1996 Sinz, Elmar J. (1996): Ansätze zur fachlichen Modellierung betrieblicher Informationssysteme – Entwicklung, aktueller Stand und Trends. In: Heilmann, Heidi (Hrsg.): Information Engineering: Wirtschaftsinformatik im Schnittpunkt von Wirtschafts-, Sozial- und Ingenieurwissenschaften. München, S. 123-143. Sinz 1999 Sinz, Elmar J. (1999): Konstruktion von Informationssystemen. Bamberger Beiträge zur Wirtschaftsinformatik Nr. 53. Verwendete Online-Version: http://141.13.6.53:8080/downloads/no53.pdf, Abruf am 2008-05-10. Skulschus, Wiederstein 2004 Skulschus, Marco; Wiederstein, Marcus (2004): XML Schema. 1. Aufl., Galileo Press, Bonn. Smith et al. 2004 Smith, Michael K.; Welty, Chris; McGuinness, Deborah L. (2004): OWL Web Ontology Language Guide, W3C Recommendation, http://www.w3.org/TR/2004/REC-owl-guide-20040210/, Abruf am 2008-0229. Socher 2003 Socher, Rolf (2003): Theoretische Grundlagen der Informatik. Fachbuchverlag, Leipzig. ȱ ȱ ȱ

378

Anhang A: Literaturverzeichnis

™’Žœȱŗşşřȱ ȱSpies, Marcus (1993): Unsicheres Wissen: Wahrscheinlichkeit, FuzzyLogik, neuronale Netze und menschliches Denken. Spektrum Akad. Verlag, Heidelberg, Berlin, Oxford. Spies 2004 Spies, Marcus (2004): Einführung in die Logik – Werkzeuge für Wissensrepräsentation und Wissensmanagement. 1. Aufl., Spektrum Akademischer Verlag, Heidelberg, Berlin. Stahlknecht, Hasenkamp 2002 Stahlknecht, Peter; Hasenkamp, Ulrich (2002): Einführung in die Wirtschaftsinformatik. 10. Aufl., Springer-Verlag, Berlin, Heidelberg. Stollberg 2007 Stollberg, Michael (2007): Semantic Web: Services finden. http://www.computerwoche.de/heftarchiv/2007/02/1217382/, Abruf am 2008-10-21. Stuckenschmidt 2002 Stuckenschmidt, Heiner (2002): Exploiting Partially Shared Ontologies for Multi-agent Communication. In: Klusch, M. ; Ossowski, S. ; Shehory, O. (Eds.) : Proceedings of the 6th International Workshop on Cooperative Information Agents VI. Lecture Notes In Computer Science, Vol. 2446, Springer-Verlag, S. 249-263. Stuckenschmidt, Timm 2002 Stuckenschmidt, Heiner; Timm, Ingo J. (2002): Adapting Communication Vocabularies using Shared Ontologies. In: Proceedings of the Second International Workshop on Ontologies in Agent Systems, 1st International Joint Conference on Autonomous Agents and Multi-Agent Systems, Bologna, S. 6-12. Su 2002 Su, Xiaomeng (2002): A Text Categorization Perspective for Ontology Mapping. Position Paper, Dept. of Computer and Information Science, Norwegian University of Science and Technology. Tamma et al. 2002 Tamma, Valentina; Woolridge, Michael; Dickinson, Ian (2002): An Ontology for Automated Negotiation. In: Proceedings of the Second International Workshop on Ontologies in Agent Systems, 1st International Joint

Anhang A: Literaturverzeichnis

379

Conference on Autonomous Agents and Multi-Agent Systems, Bologna, S. 62-69. Tang et al. 2005 Tang, Jie; Bang-Yong, Liang; Juan-Zi, Li (2005): Toward Detecting Mapping Strategies for Ontology Interoperability. In: Proceedings of The Semantic Computing Initiative (SeC 2005). Verwendete Online-Version: http://www.instsec.org/2005ws/papers/tang.pdf, Abruf am 2007-08-08. Thomas 2005 Thomas, Oliver (2005): Das Modellverständnis in der Wirtschaftsinformatik: Historie, Literaturanalyse und Begriffsexplikation. Veröffentlichungen des Instituts für Wirtschaftsinformatik, Heft 184, Institut für Wirtschaftsinformatik (IWi) im Deutschen Forschungszentrum für Künstliche Intelligenz (DFKI), Saarbrücken. UN/CEFACT 2001 UN/CEFACT (2001): CODES FOR MODES OF TRANSPORT. RECOMMENDATION No. 19, 2nd Edition. http://www.unece.org/cefact/recommendations/rec19/rec19_01cf19e.pdf, Abruf am 2008-06-30. UN/CEFACT 2007 UN/CEFACT (2007): Core Components Technical Specification. Version 3.0, 2nd Public Review. http://www.unece.org/cefact/forum_grps/tmg/CCTS-PublicReview.pdf, Abruf am 2008-09-22. UN/ECE 2008 UN/ECE (2008): Recommendation N°. 21 – Codes for Passengers, Types of Cargo, Packages and Packaging Materials (with Complementary Codes for Package Names). http://www.unece.org/cefact/recommendations/rec20/Rec20_rev5e_2008.xl s, Abruf am 2008-10-20. UN/EDIFACT 2005 UN/EDIFACT (2005): United Nations Directories for Electronic Data Interchange for Administration, Commerce and Transport, Chapter 5: Data element directory EDED.

380

Anhang A: Literaturverzeichnis http://www.unece.org/trade/untdid/d05b/tred/tredi1.htm, Abruf am 200806-30.

UN/EDIFACT 2006 UN/EDIFACT (2006): Message Type : IFTMBP. http://www.unece.org/trade/untdid/d05b/trmd/iftmbp_c.htm, Abruf am 2008-06-30. Uschold 2000 Uschold, Mike (2000): Creating, integrating and maintaining local and global ontologies. In: Proceedings of the First Workshop on Ontology Learning (OL-2000) in conjunction with the 14th European Conference on Artificial Intelligence (ECAI 2000). Verwendete Online-Version: http://delicias.dia.fi.upm.es/WORKSHOP/ECAI00/13.pdf, Abruf am 200410-20. Uschold, Gruninger 1996 Uschold, Mike; Gruninger, Michael (1996): Ontologies: Principles, Methods and Applications. Arbeitsbericht AIAI-TR-191, University of Edinburgh. Van Heijst et al. 1997 Van Heijst, G.; Schreiber, A. Th.; Wielinga, B. J. (1997): Using explicit ontologies in KBS development. In: International Journal of HumanComputer Studies, Vol. 46, Iss. 2-3, S. 183-292. Vater 1999 Vater, Heinz (1999): Einführung in die Sprachwissenschaften. 3. Aufl., UTB (Uni Taschenbücher), Wilhelm Fink Verlag, München. Visser et al. 1997 Visser, Pepijn R.S.; Jones, Dean M.; Bench-Capon, T.J.M.; Shave, M.J.R. (1997): An analysis of ontology mismatches; heterogeneity versus interoperability. In: Farquhar, Adam, Gruninger, Michael: Ontological Engineering. Papers from the 1997 AAAI Symposium, Technical report SS-9706, AAAI Press, Stanford, S. 164-172. Wache et al. 2001 Wache, H.; Vögele, T.; Visser, U.; Stuckenschmidt, H.; Schuster, G.; Neumann, H.; Hübner, S. (2001): Ontology-based integration of information – a survey of existing approaches. In: Gomez Perez, A.; Gruninger, M.; StuckŽ—-

Anhang A: Literaturverzeichnis

381

schmidt, H.; Uschold, M. (Eds.), Proceedings of the IJCAI-01 Workshop on Ontologies and Information Sharing, S. 108-117. Walton, Robertson 2002 Walton, Christopher; Robertson, David (2002): Flexible multi-agent protocols. Informatics Research Report EDI-INF-RR-0164, School of Informatics, University of Edinburgh. Weitzel et al. 2001 Weitzel, Tim; Harder, Thomas; Buxmann, Peter (2001): Electronic Business und EDI mit XML. dpunkt-Verlag, Heidelberg. Westarp et al. 1999 Westarp, Falk von; Buxmann, Peter; Weitzel, Tim; König, Wolfgang (1999): The Management of Software Standards in Enterprises – First Results of an Empirical Study in Germany and the US. Research Project “Economics of Standards in Information Networks”. Institut für Wirtschaftsinformatik, J. W. Goethe-Universität, Frankfurt am Main. Winston et al. 1987 Winston, Morton E.; Chaffin, Roger; Herrmann, Douglas (1987): A Taxonomy of Part-Whole Relations. In: Cognitive Science, No. 11/1987, S. 417444. Wombacher, Mahlecko 2002 Wombacher, Andreas; Mahlecko, Bendick (2002): Finding Trading Partners to Establish Ad-hoc Business Processes. In: Meersman, Robert; Tari, Zahir (Eds.): On the Move to Meaningful Internet Systems 2002: CoopIS, DOA, and ODBASE. Lecture Notes in Computer Science, Vol. 2519, Springer-Verlag, Berlin, Heidelberg, S. 339-355. Wolff 1993 Wolff, Karl Erich (1993): A first course in Formal Concept Analysis – How to understand line diagrams. Forschungsgruppe Begriffsanalyse, Ernst Schröder Zentrum für Begriffliche Wissensverarbeitung, Fachhochschule Darmstadt. Yancey 2004 Yancey, William E. (2004): An Adaptive String Comparator for Record Linkage. Research Report Series, Statistics #2004-02, Statistical Research Division, US Bureau of the Census, Washington.

382

Anhang A: Literaturverzeichnis

Zelewski et al. 2001 Zelewski, Stephan; Schütte, Reinhard; Siedentopf, Jukka (2001): Ontologien zur Repräsentation von Domänen. In: Schreyögg, Georg (Hrsg.): Wissen in Unternehmen: Konzepte – Maßnahmen – Methoden. Erich Schmidt Verlag, Berlin, S. 183-221. ZKA 2008 Zentraler Kreditausschuss (2008): Anlage 3 der Schnittstellenspezifikation für die Datenfernübertragung zwischen Kunde und Kreditinstitut gemäß DFÜ-Abkommen "Spezifikation der Datenformate". Version 2.3, Final Version.

Anhang B: Verzeichnis der IDIIllokutionen

IDI-Illokution

Assertive

Bedeutung

Der Sender (S) verpflichtet sich auf die Wahrheit der in der Nachricht (N) übermittelten Inhalte, geht jedoch darüber hinaus keine Verpflichtung ein. Es handelt sich also um eine Information; hieraus ergeben sich keine weiteren Pflichten für S.

Nachrichteninhalt

Informationen, die S dem Empfänger (E) mitteilen möchte.

Vorbedingung S möchte, dass E von den Inhalten der Nachricht (N) Kenntnis erlangt. Ergebnis

E hat Kenntnis über N erlangt.

Beispiel

Katalog- und Preisinformationen (EDIFACT: PRICAT)

A. Köhler, Intelligent Data Interchange (IDI), DOI 10.1007/978-3-8348-9767-1, © Vieweg+Teubner Verlag |Springer Fachmedien Wiesbaden GmbH 2010

384

Anhang B: Verzeichnis der IDI-Illokutionen

IDI-Illokution

Offer

Bedeutung

S äußert E gegenüber in N eine Willenserklärung, durch die S sich verpflichtet, bestimmte Leistungen zu erbringen oder Handlungen zu vollziehen.

Mögliche Antworten von E: "Acceptance" oder "Rejective". Nachrichteninhalt

Die von S angebotene Leistung oder Handlung.

Vorbedingung S möchte die durch N beschriebene Leistung für E erbringen. Ergebnis

S hat sich verpflichtet, die durch N beschriebene Leistung zu erbringen und ist an diese Willenserklärung gebunden, bis E das Angebot ablehnt oder das Angebot seine Gültigkeit verliert.

Beispiel

Bestellung (EDIFACT: ORDERS)

IDI-Illokution

Acceptance

Bedeutung

S nimmt das in N beschriebene Angebot des E an.

Nachrichteninhalt

Das Angebot, auf das sich S und E geeinigt haben.

Vorbedingung S verfügt über ein verbindliches Angebot des E. Ergebnis

Es ist eine Vereinbarung zwischen S und E zustande gekommen, aus der sich für beide Parteien die in der Nachricht spezifizierten Rechte und Pflichten ergeben.

Beispiel

Bestellantwort (EDIFACT: ORDRSP).

Anhang B: Verzeichnis der IDI-Illokutionen IDI-Illokution

Authorization Request

Bedeutung

Anfrage des S an E, die in N beschriebene Handlung vornehmen zu dürfen.

385

Mögliche Antworten von E: "Permissive" oder "Rejective". Nachrichteninhalt

Die zu autorisierende Handlung.

Vorbedingung S möchte eine Handlung ausführen, die durch E autorisiert werden muss. Ergebnis

S hat eine Bitte gegenüber E vorgetragen. Unterschied zu "Offer": S geht keine Verpflichtung ein, es kommt keine Vereinbarung zustande.

Beispiel

Aufforderung zur Containerfreistellung (EDIFACT: COREOR)

IDI-Illokution

Permissive

Bedeutung

S gestattet E, die in N beschriebene Handlung vorzunehmen.

Nachrichteninhalt

Die zu autorisierende Handlung.

Vorbedingung E möchte eine Handlung autorisieren, um deren Ausführung S gebeten hat. Ergebnis

S ist, im Gegensatz zu "Acceptance", keine verbindliche Vereinbarung eingegangen. Die in N beschriebene Autorisierung kann auch wieder zurückgenommen werden.

Beispiel

Autorisierung eines Lieferplans (EDIFACT: DELFOR)

386

Anhang B: Verzeichnis der IDI-Illokutionen

IDI-Illokution

Requirement

Bedeutung

S fordert E auf, die in N beschriebene Handlung vorzunehmen,

Nachrichteninhalt

Die vorzunehmende Handlung.

Vorbedingung E hat eine Verpflichtung S gegenüber. Ergebnis

E hat von S die Aufforderung zur Erfüllung von Verpflichtungen erhalten.

Beispiel

Zahlungsauftrag (EDIFACT: PAYORD)

IDI-Illokution

Confirmative

Bedeutung

Bestätigung von S, die in N beschriebenen Pflichten gegenüber E erfüllen zu wollen und zu können.

Nachrichteninhalt

Aufzählung der Pflichten, die S gegenüber E zu erbringen hat.

Vorbedingung S hat eine Verpflichtung E gegenüber. Ergebnis

E weiß, dass S seine Pflichten vereinbarungsgemäß erfüllen wird.

Beispiel

Bestellbestätigung (EDIFACT: ORDRSP)

Anhang B: Verzeichnis der IDI-Illokutionen

387

IDI-Illokution

Requestive

Bedeutung

S bittet E, die in N beschriebene Handlung vorzunehmen.

Nachrichteninhalt

Die von E vorzunehmende Handlung.

Vorbedingung S möchte, dass E die in N beschriebene Handlung vornimmt. Unterschied zu "Requirement": E ist hierzu nicht verpflichtet. Ergebnis

E kennt die Bitte des S, die in N beschriebene Handlung vorzunehmen.

Beispiel

Anfrage zur Kalkulation von Sendungskosten (EDIFACT: IFTCCA)

IDI-Illokution

Rejective

Bedeutung

S teilt E mit, die in N beschriebene Handlung nicht vorzunehmen bzw. das in N beschriebene Angebot nicht anzunehmen. Kann als Reaktion auf "Offer" und "Requestive" gesendet werden.

Nachrichteninhalt

Die vorzunehmende Handlung.

Vorbedingung E möchte, dass S die in N beschriebene Handlung vornimmt. Ergebnis

E weiß, dass S die in N beschriebene Handlung nicht vornehmen wird.

Beispiel

Ablehnung einer Bestellung (EDIFACT: ORDRSP).

388

Anhang B: Verzeichnis der IDI-Illokutionen

IDI-Illokution

Feedback

Bedeutung

Rückmeldung des S über eine erbrachte Leistung oder eine Handlung des E. Dabei kann es sich auch um eine Reklamation handeln.

Nachrichteninhalt

Rückmeldung über die erbrachte Leistung des E. Ggf. Informationen über den Leistungsbestandteil, der von S als nicht vereinbarungsgemäß betrachtet wurde.

Vorbedingung E hat eine Leistung für S erbracht. Ergebnis

E hat Kenntnis darüber erhalten, ob die von ihm erbrachte Leistung als vereinbarungsgemäß erachtet wurde oder nicht.

Beispiel

Wareneingangsmeldung (EDIFACT: RECADV).

IDI-Illokution

Informative

Bedeutung

Rückmeldung des S an E über eine erbrachte Leistung oder eine Handlung des S.

Nachrichteninhalt

Die von S erbrachte Leistung oder Handlung.

Vorbedingung S hat eine Leistung erbracht oder eine Handlung vollzogen, die für E von Interesse ist. Ergebnis

E weiß, dass S die in N beschriebene Leistung erbracht oder Handlung vollzogen hat.

Beispiel

Zahlungsavis (EDIFACT: REMADV).

Anhang B: Verzeichnis der IDI-Illokutionen

389

IDI-Illokution

Predictive

Bedeutung

Ankündigung von S, eine in N beschriebene Handlung vorzunehmen oder Ankündigung eines in N beschriebenen Ereignisses.

Nachrichteninhalt

Die von S angekündigte Handlung oder das von S angekündigte Ereignis.

Vorbedingung S möchte eine Handlung vollziehen, die für E von Interesse ist. Ergebnis

E kennt die von S angekündigte Handlung oder das von S angekündigte Ereignis.

Beispiel

Ankündigung der Warenrückgabe (EDIFACT: RETANN)

IDI-Illokution

Retrodictive

Bedeutung

Meldung von S, eine in N beschriebene Handlung vorgenommen zu haben.

Nachrichteninhalt

Die von S vorgenommene Handlung.

Vorbedingung S hat die in N beschriebene Handlung vorgenommen. Ergebnis

E weiß, dass S die in N beschriebene Handlung vorgenommen hat.

Beispiel

Liefermeldung (EDIFACT: DESADV)

390

Anhang B: Verzeichnis der IDI-Illokutionen

IDI-Illokution

Verdictive

Bedeutung

Rechtlich bindende Erklärung einer Behörde an E.

Nachrichteninhalt

Die behördliche Erklärung.

Vorbedingung Der Status von E erfordert eine verbindliche behördliche Erklärung. Ergebnis

E hat Kenntnis über die in N mitgeteilte behördliche Erklärung erlangt.

Beispiel

Verwaltungsnachricht für den internationalen Warenverkehr (EDIFACT: SANCRT)

IDI-Illokution

Declarative

Bedeutung

Rechtlich bindende Erklärung von S an eine Behörde.

Nachrichteninhalt

Die Erklärung des S.

Vorbedingung Der Status von S erfordert eine verbindliche Erklärung an eine Behörde. Ergebnis

Die Behörde hat Kenntnis über die Erklärung N erhalten.

Beispiel

Zollanmeldung (EDIFACT: CUSDEC)

Anhang B: Verzeichnis der IDI-Illokutionen

391

IDI-Illokution

Service

Bedeutung

S teilt E den Verarbeitungsstatus eines Sendevorgangs mit.

Nachrichteninhalt

Der Sendevorgang, dessen Verarbeitungsstatus kommuniziert werden soll.

Vorbedingung S hat eine Nachricht erhalten, deren Verarbeitungsstatus für E von Interesse ist. Ergebnis

E kennt den Verarbeitungsstatus von N.

Beispiel

Semantische Prüfung, z.B. Vorhandensein von Pflichtangaben, Verwendung korrekter Codes etc. (EDIFACT: APERAK)

IDI-Illokution

ProtOffer

Bedeutung

S sendet E einen Protokollvorschlag.

Nachrichteninhalt

Protokoll mit sämtlichen Sendevorgängen und ihren Eigenschaften.

Vorbedingung keine Ergebnis

E kennt den von S gesendeten Protokollvorschlag.

Beispiel

keines

392

Anhang B: Verzeichnis der IDI-Illokutionen

IDI-Illokution

ProtAccept

Bedeutung

S signalisiert E die Zustimmung zu seinem Protokollvorschlag.

Nachrichteninhalt

keiner

Vorbedingung keine Ergebnis

S und E haben sich auf ein gemeinsames Protokoll geeinigt.

Beispiel

keines

IDI-Illokution

ProtReject

Bedeutung

S signalisiert E die Ablehnung seines Protokollvorschlags.

Nachrichteninhalt

keiner

Vorbedingung keine Ergebnis

S und E haben sich nicht auf ein gemeinsames Protokoll geeinigt.

Beispiel

keines

Anhang C: Sachverzeichnis + '!&() 56, 59

Axiomensystem 39, 58

ABox 42

Bayes-Formel 180

Agentenklasse 133, 134

Bedeutungseinheit 47, 100, 102

Agentenprotokoll 41, 132, 143

Beschreibungslogik 51, 56, 59

gemeinsames 147

Bezeichnerformat 84, 94

Kompatibilität 148

Bezeichnerkoeffizient 190

Allquantor 55

Bildbereich 66, 77

Äquipollenz 230

Cosinusmaß 198

Äquivalenz

Daten 33

Bedingungen 175, 185

Datenfeld 82, 87

extensionale 174

Datenfeldgruppe 87

Indikatoren 170, 176, 181

Dicekoeffizient 178

intensionale 174

Disjunktionsklasse 63

Schwellenwerte 223

Disjunktionsrolle 64

Äquivalenzgruppe 242

Domänenbereich 66, 78

Attribut 113

ebXML 12

Attributbeziehung 107

EDI 5

Attributheterogenität 253

Schwächen 7

Attributkoeffizient 202

Systeme 6

Attribut-Zuordnungskonflikte 255 Ausgangsnachricht 135

EDIFACT 8, 101, 106, 127, 264 Eingangsnachricht 135

Aussagenlogik 50

Electronic Data Interchange Siehe EDI

Axiom 27, 39, 75

Empfängerontologie 161, 164

A. Köhler, Intelligent Data Interchange (IDI), DOI 10.1007/978-3-8348-9767-1, © Vieweg+Teubner Verlag |Springer Fachmedien Wiesbaden GmbH 2010

394

Anhang C: Sachverzeichnis

Empfangsnachricht 100

Illokutionärer Akt 126

Existenzquantor 55

Indikatorheterogenität 227

Explikation 35

Individuen 38, 56

Extension 38

Individuenaxiom 79

Festsatzformat 84, 93

Individuenkonstante 54

Formalisierung 33

Individuenvariable 54

Formel 27

Induktive Inferenz 216

Funktion 54

Informationen 33

GBox 42, 44

Intelligent Data Interchange 18

Geschäftsdateneinheit 43

Intension 38

Geschäftsdatenstruktur 107

Interaktionsprotokoll Siehe Agentenprotokoll

Geschäftsdatentransformation 260

Interpretationsfähigkeit 19

Granularitätskonflikte 241, 257

Interpretationsfunktion 60

Graphenbasierter Äquivalenzindikator 206

Jaromaß 195

Heterogenitätseffekt 225, 227

Kardinalitätseinschränkung 68

Heterogenitätskette 229

Klassen

Junktor 52

Heterogenitätsursache 225, 227

Abgeschlossene 62

Holonym 111

Äquivalenz 75

Homonymie 237

atomare 56

Hybridformat 84

Definition 75

Hyperonym 109, 204, 205

Koeffizientenheterogenität 226

Hyponym 109, 204, 205

Kompatibilität 187

Hypothesenfalsifikation 184

Werttypen 188

IDI-Agenten 18, 22

Konjunktionsklasse 63

IDI-Architektur 21

Konjunktionsrolle 64

Illokution 126, 127, 136, 141, 148

Konkrete Domäne 69

Anhang C: Sachverzeichnis

395

Konnektivitätsgraph 207

Meronym 111

Konsistenzbedingung 27

Metamodell 36

Konstruktor 57, 62

Metaprotokoll 133, 142

Kontravalenzrolle 64 Konzept 37

Mittlere quadratische Abweichung 201

Konzeptinklusion 76

Nachricht 86, 266

Konzeptualisierung 35

Naive Bayes-Formel 217

Kopfteil 86

Namensheterogenität 234

Korrektklassifikationsrate 184

Negationsklasse 63

LBox 42, 46

N-Gram 193

Levensteinmaß 191

N-Gramatischen Ähnlichkeit 193

Literal 52

Normalisierungskonstante 180

Lokutionärer Akt 125

Ontologie 34, 36

Mapping 162 Maßeinheit 116, 187 Matching 103, 105, 162, 166 constraintbasiertes 169 CUPID-Ansatz 170

Hybridarchitektur 41 Öffentliche 22, 40 Private 22, 40

Ontology Merging 163 Positionsteil 86

GLUE-Ansatz 171

Prädikat 53

individuenbasiertes 171

Prädikatenlogik 53

lexikalisches 168

Prädikation 126

linguistisches 168

Pragmatik 124

Prozess 183

Pragmatikvokabular 46

Mengendefinition 27

Propagationsgraph 208

Mereologie 85, 106, 111

Propositionaler Akt 125

Mereologieheterogenität 250

Protokoll Siehe Agentenprotokoll

Mereologiekoeffizient 211

Protokollmatching 165

Mereologische Lücke 253

Protokollvokabular 46

396

Anhang C: Sachverzeichnis

Quantor 66

gemeinsamer 155

Randbedingung 133

Kompatibilität 148, 151

RA-Relevanz 213

Sendung 47

Referenzmodell 36

Sequenz 47

Regelprozesse 10

SI-Einheiten 116

Reguläre Ausdrücke 118

Similarity Flooding 171, 206

Repräsentationsfähigkeit 19

Sprechakttheorie 124, 125

RFID 24

Strukturelement 47, 85

Rollen 38

Strukturirrelevanz 239

atomare 56

Strukturkonflikte 238

Attributrollen 28

Strukturrelevanz 239

Konkrete 28

Synonymie 235

sonstige 28

Syntax 82

Rollendefinition 77

Syntaxvokabular 45

Rollenerster 66

Syntaxwissen 82

Rolleninversion 65

Taxonomie 106, 109

Rollensymmetrie 78

Taxonomieheterogenität 244

Rollentransitivität 78

Taxonomiekoeffizient 203

Rollenzweiter 66

Taxonomische Distanz 204

Routineprozesse 10

Taxonomische Lücke 247

Segment 266

TBox 42

Semantik 103

Transportcontainer 43, 92

Semantikvokabular 45

Trennungskonflikte 241, 244

Semantikwissen 103

Trennzeichenformat 84, 94

Semiotik 125

Trennzeichenteilung 95, 97, 98

Sendenachricht 100

Ubiquitous Computing 24

Senderontologie 161, 164

Verschmelzungskonflikte 241, 243

Sendevorgang 44, 132, 135

Anhang C: Sachverzeichnis

397

Vokabular 49

explizites 33

Wahrscheinlichkeit 179

implizites 33

bedingte 179, 181

kategoriales 34, 48

unbedingte 179

zustandsabhängiges 35, 42

Web Services 25

zustandsunabhängiges 35, 42

Wertemenge 116

Wissensbasis 34

Werterestriktion 66

Wissensrepräsentation 32

Wissen 32

XML 298