Einsatz eines semantischen Wikis in einem wissensintensiven Umfeld am Beispiel Concept Development & Experimentation

Inhaltsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

Abkürzungsverzeichnis

1 Einleitung
1.1 Eingrenzung und Aufbau dieser Arbeit
1.2 Die wissensintensive Domäne CD&E

2 Semantische Wikis zur Unterstützung von Wissensmanagement
2.1 Wissensmanagement in Unternehmen
2.2 Organisationale Wikis
2.3 Semantische Erweiterung
2.3.1 Formale Beschreibungssprachen für das Semantische Web
2.3.2 Einsatzgebiete semantischer Wikis
2.3.3 Übersicht bestehender Systeme
2.3.4 Auswahl der Plattform
2.3.5 Semantic MediaWiki

3 Analyse der Domäne und Konzeption des semantischen Wikis
3.1 Zielstellung
3.1.1 Vorgehensmodell
3.1.2 Methoden, Modelle und Instrumente
3.1.3 Experimente
3.1.4 Erreichbarkeit des Wissens
3.1.5 Benutzerfreundlichkeit
3.2 Entwurf der Ontologie
3.2.1 Klassen und Instanzen
3.2.2 Attribute

4 Realisierung des Wikis
4.1 Technische Voraussetzungen
4.1.1 Basissoftware
4.1.2 Installierte Erweiterungen
4.2 Wiki-Elemente von der Ontologie zur fertigen Seite
4.3 Vorgehensmodell
4.4 Werkzeugkasten
4.4.1 Instrumente
4.4.2 Konzeptionelle Modelle
4.4.3 Wissenschaftliche Methoden
4.5 Experimente
4.5.1 Bereich Experimente
4.5.2 Bereich Experimentphasen
4.5.3 Bereich Produkte
4.5.4 Erweiterung der Phasen und Werkzeuge
4.5.5 Bereich Personen
4.6 Wissensmanagement mit den SMW+-Erweiterungen
4.6.1 Halo
4.6.2 Semantic Gardening
4.7 Schwierigkeiten bei Realisierung und Nutzung

5 Zusammenfassung
5.1 Empfohlenes Vorgehen
5.2 Bewertung

6 Literaturverzeichnis

7 Ehrenwörtliche Erklärung

8 Anhang
8.1 Auszug LocalSettings.php
8.2 Vorlage Experiment
8.3 Quelltext Ontologie-Export
8.4 Ontologie des CD&E-Wikis

Abbildungsverzeichnis

Abbildung 1-1: Idealtypischer Ablauf einer Experimentserie (aus [Zen06, S. 19])

Abbildung 2-1: Werkzeuge und Techniken von Wissensmanagement in KMU

Abbildung 2-2: Kommunikation an der Grenze zwischen Wiki und Leser [Bla08, S. 187]

Abbildung 2-3: RDF-Graph der Stadt-Ontologie

Abbildung 2-4: Nicht-Äquivalenz von domain/range und einer allValuesFrom-Restriction

Abbildung 2-5: Attribute anzeigen

Abbildung 3-1: Die vier Vorgehensphasen und deren Produkte

Abbildung 3-2: Klassenhierarchie Werkzeugkasten

Abbildung 3-3: Werkzeugkasten mit Attributen und assoziierten Klassen

Abbildung 3-4: Vorgehensmodell und Experimente – Klassen und Attribute

Abbildung 3-5: Vorgehensmodell und Experimente – Beispiel einer Instanziierung

Abbildung 3-6: Personen – Klassen und Attribute

Abbildung 4-1: Spezialseiten von Semantic Forms

Abbildung 4-2: Attribut erstellen

Abbildung 4-3: Vorlage erstellen

Abbildung 4-4: Formular erstellen

Abbildung 4-5: Kategorie erstellen

Abbildung 4-6: Phase mit Formular bearbeiten

Abbildung 4-7: Ergebnis der Abfrage nach Phasen und Produktarten

Abbildung 4-8: Automatisch erzeugte Rückwärtsverlinkung

Abbildung 4-9: Formular Instrument

Abbildung 4-10: Hilfskategorie „Zweck“ am Beispiel Datenerhebung

Abbildung 4-11: Formular konzeptionelles Modell

Abbildung 4-12: Spezialseiten von Semantic Drilldown

Abbildung 4-13: Filter erstellen

Abbildung 4-14: Semantic Drilldown für Methoden, alle Ergebnisse

Abbildung 4-15: Semantic Drilldown für Methoden, gefilterte Ergebnisse

Abbildung 4-16: Übersicht Experimente

Abbildung 4-17: Produkte eines Experimentes

Abbildung 4-18: Phasen eines Experiments (Auszug)

Abbildung 4-19: Abfragen bei Experimenttypen

Abbildung 4-20: Formular Experimentphase

Abbildung 4-21: Produktseite

Abbildung 4-22: Phase im Vorgehensmodell (ergänzt)

Abbildung 4-23: Personenseite

Abbildung 4-24: Link für WYSIWYG-Editor in Formularen

Abbildung 4-25: Ansicht Seite annotieren

Abbildung 4-26: Markierten Text annotieren

Abbildung 4-27: Fertig annotierter Text

Abbildung 4-28: Attribut mit Halo erstellen

Abbildung 4-29: Kategorie mit Halo bearbeiten (Wissenschaftliche Methode)

Abbildung 4-30: Attribut mit Halo bearbeiten (IstExperimentphaseVon)

Abbildung 4-31: Query Interface – Beispielabfrage Hauptebene

Abbildung 4-32: Query Interface – Unterabfrage

Abbildung 4-33: Der Ontologiebrowser am Beispiel wissenschaftliche Methode

Abbildung 4-34: Konsistenzprüfung von Semantic Gardening

Abbildung 4-35: Vergleich der Protégé-erzeugten Ontologie „Interview“ mit der exportierten Ontologie

Tabellenverzeichnis

Tabelle 2-1: Semantische Wikis im Vergleich [Sch07, S. 437]

Tabelle 2-2: RDF-Konstrukte in SMW

Tabelle 3-1: Mit Elementen des Werkzeugkastens assoziierte Klassen

Tabelle 3-2: Weitere Attribute im Bereich Experimente

Tabelle 4-1: Verwendete Software

Tabelle 4-2: Vergleich der Möglichkeiten, strukturierten Freitext vorzugeben

Tabelle 4-3: Importierbare OWL-Konstrukte

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Einleitung

“Properly designed, the Semantic Web can assist the evolution of human knowledge as a whole.”

Tim Berners-Lee – bekannt als der „Erfinder“ des Internet und Vorsitzender des World Wide Web Consortium – erregte 2001 mit seinem Artikel „The Semantic Web“ im Scientific American Magazine Aufsehen, als er seine Vision von der Zukunft des Internet beschrieb [Ber01]. Was sind die Ideen, die sich hinter dem Begriff verbergen und was ist fast ein Jahrzehnt danach aus dieser Vision geworden?

Das Internet begann als geschlossenes Medium, dessen Nutzer vor allem Inhalte lesen und nicht schreiben konnten – auch wenn das von Berners-Lee ursprünglich anders geplant war. Erst einige Jahre später begann eine Entwicklung, die oft als „Web 2.0“ bezeichnet wird: Das Internet ist zum Read-Write-Medium geworden. Getrieben wurde diese Entwicklung vor allem von Weblogs und Wikis, die einer sehr viel größeren Anzahl von Nutzern die Veröffentlichung von Inhalten ermöglichte. Die erzeugten und gespeicherten Informationen wachsen seitdem noch deutlich schneller als zuvor und die Frage, „wie man diese Informationsmengen noch organisieren und sinnvoll zusammenführen kann“, wird drängender [Vra06, S. 790]. Die Möglichkeiten, die das Web 2.0 bietet, und die Probleme und Herausforderungen des Wissensmanagements sind natürlich auch längst in unternehmensinternen Netzen angekommen.

Das Semantische Web soll das bisherige nicht ersetzen, sondern erweitern. Die Idee des Semantischen Webs lässt sich leicht zusammenfassen: Inhalte und Links im Internet werden mit einer Bedeutung (Semantik) versehen, so dass sie für Maschinen und nicht nur für Menschen lesbar sind. Mit Maschinen sind zum Beispiel Suchmaschinen, aber auch beliebige andere Computerprogramme gemeint, die im Internet Informationen auswerten oder finden sollen.

Berners-Lee beginnt in seinem Artikel mit der Beschreibung eines komplexen Szenarios, in dem mehrere menschliche Akteure solche „Maschinen“ nutzen – bezeichnet als semantic web agents. Sie können Termine untereinander und mit Dienstleistern in der Nähe abstimmen, Auswahlkriterien priorisieren. Sogar alle Geräte mit der Eigenschaft „Hat Lautstärkeregelung“ im Haus werden automatisch leiser geregelt, wenn ein Anruf angenommen wird. Agenten „können nicht nur ihre Umgebung wahrnehmen und darauf reagieren, sondern sind in der Lage, ihr Agieren zu planen, zu kommunizieren und aus Erfahrung zu lernen“ [Läm08, S. 21].

Zukunftsmusik? Sicherlich – viele dieser Anwendungsfälle können heute auch ohne das „Semantische Web“ abgedeckt werden. Alles in allem bleiben das jedoch noch Insellösungen, die zum Beispiel auf speziellen, nicht-öffentlichen Datenbanken mit festen, definierten Datenstrukturen beruhen.

In der Literatur werden viele weitere beeindruckende Anwendungsbeispiele genannt. Alle ist ein Grundprinzip gemeinsam: Daten werden „klassifiziert, typisiert und zueinander in Beziehung gesetzt“ [Vra06, S. 792]. Aber anders als in Datenbanken hat das Web einen offenen, immer unvollständigen Charakter. Sogar die Erzeugung „neuen Wissens“, also solchem, das nicht implizit angegeben wurde, wird möglich. Auch diesem Aspekt widmet sich diese Arbeit.

Die Vision von Berners-Lee ist bisher nur in kleinen Teilen des Internet realisiert und noch ist unklar, ob es je dieses „neue“ Web in seiner ganzen Breite geben wird. Ein Bereich, in dem es aktive Entwicklungen und Forschungen gibt, sind die semantischen Wikis. Deswegen liegt hier das Hauptaugenmerk dieser Arbeit. Besonders interessant ist dabei die Vermischung einer etablierten Web-2.0-Technologie mit der neuen Idee der Maschinenlesbarkeit. Damit diese Betrachtungen nicht rein theoretischer Natur bleiben, soll ein solches Wiki auch für ein konkretes Projekt umgesetzt werden.

Ziel dieser Arbeit ist eine Bewertung, inwieweit semantische Technologien einen Mehrwert für ein Wiki bringen können – ganz im Sinne der Mehrwerte, die Tim Berners-Lee für das Web als Ganzes gesehen hat.

1.1 Eingrenzung und Aufbau dieser Arbeit

Da eine Betrachtung des gesamten Semantischen Webs unmöglich ist, wird – wie bereits erwähnt – in dieser Arbeit ein semantisches Wiki realisiert. Der Kontext, in dem das Wiki geplant ist, muss zunächst erläutert und seine Eignung für ein solches Wiki begründet werden.

Bevor sich die Arbeit auf das konkrete Wiki konzentrieren kann, werden in Kapitel 2 ausführlich die Grundlagen dafür gelegt. Einige Fragestellungen sind zu beantworten: Was verbirgt sich hinter dem Wiki-Prinzip und warum ist das auch für Unternehmen, also im nicht-öffentlichen Umfeld interessant? Zwei Schlüsselbegriffe – Kommunikation und Kollaboration – werden sich dabei herauskristallisieren. Was macht ein Wiki zum semantischen Wiki, welche Technologien können sich dahinter verbergen? Abschließend kann ein aktueller Überblick über verfügbare und in Planung befindliche Plattformen gegeben werden um eine Entscheidungsgrundlage für die Auswahl eines bestimmten Wikisystems zu haben. Was in dieser Arbeit nicht geleistet werden kann, ist ein paralleles Implementieren auf verschiedenen Plattformen um die Ergebnisse vergleichen zu können.

Der Schwerpunkt der Arbeit wird in den Kapiteln 3 und 4 liegen. Ausgehend von Analyse und Design wird eine Implementierung vorgeschlagen – eine Orientierung am klassischen Vorgehen der Softwareentwicklung. Die Auswahl der Plattform soll anhand der ermittelten Anforderungen erfolgen. Besonderes Augenmerk muss auch auf den Punkten liegen, die zwar wünschenswert, aber (derzeit) nicht realisierbar sind. Ansonsten liegt die Konzentration im Kapitel der Realisierung bei den Sprachmitteln und -mustern der gewählten Wiki-Plattform. Abgeschlossen wird dieses Kapitel mit einem Resümee über erkannte technische Probleme der gewählten Plattform.

Im Laufe der Realisierung des Wikis ergibt sich ein Vorgehen, wie das konkrete Problem mit der konkreten Wiki-Plattform gelöst werden kann. Dieses Vorgehen wird im letzten Kapitel noch einmal zusammengefasst. Dabei soll auch soweit abstrahiert werden, dass zumindest ähnlich strukturierte Probleme mit diesem Ansatz bearbeitet werden können. Ein allgemeingültiges Metamodell zur Überführung eines realen Problems in ein semantisches Wiki wird diese Arbeit nicht leisten können. Dafür kann aber die zentrale Frage beantwortet werden: Kann das semantische Wiki in einem wissensintensiven Umfeld Mehrwerte bringen, die den Mehraufwand des Erlernens und Umsetzens einer neuen Technologie rechtfertigen?

Der Anhang schließt die Arbeit ab. In ihm werden unter anderem einige Quelltexte aufgeführt, die im Wiki Verwendung finden, aber in der Arbeit nur referenziert werden. Außerdem wird eine formale Darstellung der gesamten Semantik nachgereicht, die bei der Analyse des Problems erstellt und später implementiert wurde.

Zunächst wird jedoch die Einleitung abgeschlossen mit einer Vorstellung des betrachteten Problembereichs – der Domäne CD&E.

1.2 Die wissensintensive Domäne CD&E

CD&E bedeutet in der deutschen Übersetzung Konzeptentwicklung und deren experimentelle Überprüfung. CD&E „ist nicht nur eine neue Methode für die Streitkräfte, sondern gleichzeitig auch eine schwierige, komplexe und dynamische Aufgabe“ [Zen06, S. 6]. Die Erfahrungen haben gezeigt, dass sich die Probleme des Verfahrens vor allem bei der praktischen Anwendung ergeben und „ein hohes Maß an fachlicher Expertise und Erfahrung bei den Durchführenden“ erfordern. Die Vorlage für CD&E bei der Bundeswehr stammt aus dem US-Amerikanischen Verteidigungsministerium, wo Ende der 90er Jahre der „Code of Best Practice for Experimentation“ entwickelt wurde. Die Bedeutung für die Neuausrichtung des Militärs – auch außerhalb der USA – ist seitdem stetig gestiegen.

Die Inhalte des CD&E-Leitfadens sollen in diesem Abschnitt zusammengefasst werden um einen Überblick über die Domäne zu erhalten und im Besonderen um deutlich werden zu lassen, dass es sich um eine wissensintensive Domäne handelt. Dabei wird vor allem der Teil 1 „Einführung in CD&E“ betrachtet, der einen Überblick über CD&E gibt.

2003 wurde in den Verteidigungspolitischen Richtlinien die Transformation als „umfassendes Prinzip zur Weiterentwicklung der Streitkräfte festgeschrieben“. Transformation beinhaltet dabei die Konzentration auf

- die wahrscheinlichsten Einsätze als Beteiligung an multinationalen Operationen,
- bundeswehr- und streitkräftegemeinsames Denken und Handeln,
- die Befähigung zur Vernetzten Operationsführung – die Führung und der Einsatz von Streitkräften auf der Grundlage eines streitkräftegemeinsamen, interoperablen und führungsebenenübergreifenden Kommunikations- und Informationsverbundes

Das übergeordnete Ziel dieses „fortlaufenden, vorausschauenden Anpassungsprozesses“ ist kurz gesagt die Verbesserung der Einsatzfähigkeit der Bundeswehr [Gen06, S. 3]. Dabei wird explizit die „Nutzung von Innovationen im technologischen Bereich“ eingeschlossen. Die Konzeption der Bundeswehr vom August 2004 baut auf den Verteidigungspolitischen Richtlinien auf und nennt Konzeptentwicklung und deren experimentelle Überprüfung erstmals eine wesentliche Methode um Transformation zu gestalten. Mit ihr soll Innovationspotenzial erkenn- und nutzbar gemacht werden [Zen06, S. 8].

Das Schlüsselprinzip von CD&E sind „disruptive Innovationen“ – also nicht der kontinuierliche Verbesserungsprozess, sondern völlig neue Ansätze und Verfahren. Eingefahrene Denkmuster sollen losgelassen werden um zu neuen Ideen und Lösungen zu kommen. Dabei sind „Fehlschläge“ einkalkuliert und kein Hindernis, sondern eventuell ein nötiger Zwischenschritt zu einer noch besseren Lösung.

Veränderungen können und sollen in mehreren Dimensionen gleichzeitig in Betracht gezogen werden:

- Menschen,
- Technologie,
- Struktur und
- Prozesse.

Die für umfassende Verbesserungen notwendigen mehrdimensionalen Veränderungen bedeuten aber gleichzeitig komplexe neue Problemstellungen, bedingt durch die vielfältigen Wechselwirkungen: Rein theoretische Überlegungen werden nicht ausreichen um in einem Zug einsatztaugliche Lösungen zu entwerfen. Das liegt auch an fehlenden Erfahrungen beim menschlichen Verhalten auf neue Ansätze und an dem fortwährenden Dialog „zwischen Aufgabensteller und Konzeptentwickler“, der dafür nötig ist. CD&E ist ein iterativer Prozess und weist Ähnlichkeiten zu agilen Softwareentwicklungsmethoden auf. Nutzer sollen frühzeitig und kontinuierlich eingebunden werden um den „Schritt von der theoretischen Konzeptentwicklung zum praktischen Fähigkeitsgewinn fortwährend“ überprüfen zu können [Zen06, S. 12].

Wichtigstes Element zur Durchführung von CD&E-Vorhaben sind Experimente. Experimentieren erfordert Überlegungen im Vorfeld, sowie „Kontrolle und Präzision bei der Durchführung“ [Zen06, S. 13]. Gefordert sind kontrollierte Variation und präzise Messung oder Beobachtung erwirkter Effekte.

Experimente sind im Kontext von militärischer CD&E „die praktische Überprüfung und Weiterentwicklung eines theoretisch fundierten […] Konzeptes mit dem langfristigen Ziel der Verbesserung der Fähigkeiten“ [Zen06, S. 14]. Beide Bestandteile zum Erreichen dieses Ziels sind wichtig und bedingen einander.

Auch wenn beispielsweise ausschließlich Simulationsmodelle in einem Experiment eingesetzt werden können, ist das hauptsächliche Anliegen eine realistische Konzeptumsetzung unter „aktiver Beteiligung der Anwender“. Das unterscheidet CD&E-Experimente von klassischen Experimenten oder solchen, die bisher – vor allem bei den Wehrtechnischen Dienststellen – durchgeführt wurden und werden.

Bei CD&E handelt es sich um einen iterativen Prozess, der kontinuierlich zwischen den Phasen Konzeptentwicklung und der experimentellen Überprüfung wechselt. Der Wissensgewinn erfolgt also schrittweise bis zum endgültigen Konzept – oder „Fehlentwicklungen [werden] frühzeitig aufgedeckt“ [Zen06, S. 15].

Von weiter außen betrachtet reicht auch die Durchführung nur eines einzelnen Experimentes nicht aus um die Ziele zu erreichen. Dafür sind die Problemstellungen der Transformation zu komplex. Wiederholung (um Zufälle auszuschließen und Robustheit nachzuweisen) und Weiterentwicklung der Experimente sind Gründe für Durchführung ganzer Experimentserien. Auch hier ist also ein iterativer Prozess erkennbar. Einzelexperimente können nur spezifische Fragestellungen untersuchen, Experimentserien „die relative Wichtigkeit und den Einfluss einer Vielzahl von Faktoren im gesamten […] Problemraum […] durchleuchten“ [Zen06, S. 16].

Drei Experimentarten wurden identifiziert, die verschiedene Zielsetzungen verfolgen:

- Discovery-Experimente – etwas völlig Neues ausprobieren und die Auswirkungen studieren
- Hypothesen-Test-Experimente – Hypothesen gezielt untersuchen und Grenzen ausloten
- Demonstrator-Experimente – die praktische Durchführbarkeit eines Konzepts anschaulich demonstrieren

Abbildung 1-1 zeigt einen idealtypischen Ablauf, wie mit einer Experimentserie die Reife des Konzeptes stetig verbessert wird. In der Praxis wird sich natürlich meistens ein veränderter Ablauf ergeben, was aber der Grundidee nicht widerspricht.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1-1: Idealtypischer Ablauf einer Experimentserie (aus [Zen06, S. 19])

Für die Auswertung der Experimente nach den vorher festgelegten Kriterien sind Analysten im Zentrum für Transformation der Bundeswehr verantwortlich. Die Analyse ist jedoch nicht nur nach dem Experiment durchzuführen, sondern begleitet den gesamten Prozess. Unter anderem müssen Analyse- und Datenerhebungsplan erstellt werden. Das zur Durchführung dieser Aufgaben nötige Wissen ist vielfältig, was die Analyse zu einer anspruchsvollen Tätigkeit macht. Die Bereiche, in denen ein Analyst kompetent sein muss, sind unter anderem

- CD&E im Allgemeinen,
- Konzeptionelle Modelle,
- Wissenschaftliche Methoden,
- Instrumente zur Datenerhebung und -auswertung.

Allein die Auswahl einer geeigneten Methode für ein Experiment oder einen Teil eines Experimentes ist eine Herausforderung und abhängig von vielen Einflussfaktoren.

An der Universität der Bundeswehr München wird derzeit für das Zentrum für Transformation der Bundeswehr eine Studie erstellt, die den Prozess der Analyse auf eine wissenschaftliche Grundlage stellen (Analyseleitfaden) und damit Handlungssicherheit erzeugen soll.

CD&E steht auch mit anderen Themen in engem Kontext, was die Wissensintensivität weiter steigert. Ohne in dieser Arbeit auf diese Themen näher einzugehen, sollen sie in einer Auflistung genannt werden:

- Übungen/ Ausbildung (als Kernaufgabe der Streitkräfte und in Abgrenzung zu Experimenten)
- Vernetzte Operationsführung (als weiteres Kernelement der Transformation und als Ziel von CD&E)
- Operations Research, Modellbildung und Simulation (Optimierung bestimmter Prozesse und Verfahren und nutzbar zur Unterstützung von Experimenten)

Welcher Ansatz ergibt sich für ein semantisches Wiki? Bisher werden sehr viele der in den Experimenten gewonnenen Kenntnisse nicht oder unstrukturiert (also nicht maschinenlesbar) vorgehalten. Schon die beispielhaften folgenden Fragestellungen lassen sich derzeit nur sehr schwer beantworten: Wer waren die Analyseverantwortlichen der letzten drei Demonstrator-Experimente? Welche Methoden wurden am häufigsten bei Discovery-Experimenten eingesetzt, und mit welchen Instrumenten wurde darin gearbeitet? Die Informationen zur Beantwortung dieser Fragen sind vorhanden – sie sollen aber auch systematisch nutzbar gemacht werden.

Ein weiterer Ansatzpunkt ist der Analyseleitfaden der Universität der Bundeswehr München. Das dort erzeugte Wissen, wie zum Beispiel ein Vorgehensmodell für Experimente wird derzeit nur in Word-Dokumenten vorgehalten. Dabei ist der Leitfaden auch ein „living document“, das von mehreren Bearbeitern bearbeitet und weiterentwickelt wird. Eine Integration in das Wiki ist sinnvoll.

In diesem Abschnitt wurde die Domäne CD&E vorgestellt, ohne sehr detailliert zu werden. Die wichtigste Erkenntnis aus dieser Zusammenfassung ist die hohe Komplexität und die große Bandbreite an nötigem Wissen, mit denen ein Analyst konfrontiert wird, der Projekte im Rahmen von CD&E bearbeitet. Im Kapitel 3 wird die aktuell durchgeführte Studie der Universität der Bundeswehr München auf die Anforderungen an das semantische Wiki hin untersucht.

2 Semantische Wikis zur Unterstützung von Wissensmanagement

Eine einzig gültige Definition von Wissensmanagement zu finden, gestaltet sich schwierig bis unmöglich, zu facettenreich ist dieser Begriff. Das fängt bereits bei der Unterscheidung zwischen individuellem und organisationalem Wissensmanagement an. Letzteres wird das für diese Arbeit interessante sein. Organisationales Wissensmanagement entwickelt sich immer mehr zu einer unverzichtbaren Aufgabe in Unternehmen, da es zu einem Faktor für die Wettbewerbsfähigkeit geworden ist. Selbst, wenn es sich beim Zentrum für Transformation der Bundeswehr nicht um ein Unternehmen im wirtschaftlichen Sinne handelt, gilt es doch, die Zusammenarbeit mehrerer Mitarbeiter, auch hierarchieübergreifend, zu verbessern.

Dieses Kapitel der Arbeit wird sich zuerst mit Herausforderungen und Möglichkeiten des Wissensmanagements in kleineren Organisationen beschäftigen, bevor der Fokus auf Wikis gerichtet wird, zuerst allgemein und dann in der semantischen Variante.

2.1 Wissensmanagement in Unternehmen

Verschiedene Aspekte des organisationales Wissensmanagements wiederholen sich in den unterschiedlichen Definitionen. Das Ziel ist die Optimierung von Prozessen der Produktion und Kommunikation oder, weiter gefasst, die Verbesserung von Effektivität und Effizienz des gesamten Unternehmens. Erreicht werden soll das durch Analysieren, Sammeln, Systematisieren, Verknüpfen und Bereitstellen des vorhandenen Wissens aller Mitarbeiter.

Werkzeuge und Methoden für das Bewältigen dieser Aufgaben gibt es sehr viele und deren Einsatz hängt auch von der Größe der Organisation ab. Bei Klein- und Mittelständischen Unternehmen (KMU) steht der Mitarbeiter im Mittelpunkt und weniger das leistungsfähige Wissensmanagementsystem, das nur „unterstützende Wirkung“ haben soll [Gus08, S. 127]. Die Betrachtungen, die für KMU gelten, werden hier auch als relevant für das Zentrum für Transformation angenommen. Das gilt besonders auch für die Annahme, dass die Funktion des „Wissensmanagers“ im Normalfall keine Vollzeitstelle sein wird.

Neben den Werkzeugen, von denen einige im Anschluss vorgestellt werden, sind auch die eigentliche Unternehmenskultur und der Prozess der Einführung eines Wissensmanagementsystems entscheidend für den Erfolg [Gus08, S. 128]:

- Die Wichtigkeit von Wissen für das Unternehmen muss jedem klar sein.
- Von Vorteil ist ein offenes Betriebsklima, um den Wissenstransfer nicht nur zwischen den Mitarbeitern eines Teams, sondern auch zwischen den Hierarchieebenen oder über Abteilungsgrenzen hinweg zu fördern.
- Mitarbeiter müssen motiviert und bereit sein, ihr Wissen und ihre Erfahrungen auszutauschen, also sowohl zu hinterlegen als auch abzufragen. Sie müssen erkennen, dass es nicht nur dem Unternehmen, sondern auch ihnen selbst nutzt. Dieser Nutzen muss aber auch vermittelt und erkennbar gemacht werden.
- Die Wissensziele müssen von der Unternehmensführung aus den Unternehmenszielen abgeleitet werden.

Für die einzelnen Bestandteile des Wissensmanagements kommen unterschiedliche Werkzeuge und Techniken in Frage. Abbildung 2-1 führt einige davon auf, angelehnt an [Gus08, S. 129 ff.]. Wissen wird demnach identifiziert, entwickelt, verteilt und bewahrt. Manche Werkzeuge, wie zum Beispiel Wikis, kommen für mehrere Punkte in Frage. Auf eine weitergehende Beschreibung aller einzelnen Punkte wird hier verzichtet. Eine generelle Empfehlung, welches Werkzeug zum Einsatz kommen soll, kann nicht gegeben werden und ist vom konkreten Umfeld, dem ermittelten Informationsbedarf und vom Budget abhängig. Viele Produkte sind auch als Open-Source-Software verfügbar.

Aus jedem Bereich soll beispielhaft ein Werkzeug vorgestellt werden.

Wissenskarten sind grafisch aufbereitete Darstellungen von Wissensträgern, -bes­tänden, -quellen, -strukturen bzw. -anwendungen. Sie dienen der Wissenstransparenz und dem „Einordnen von neuem Wissen in bestehendes“ [Gus08, S. 129]. Bestehende Wissenskarten unterstützen dementsprechend auch die Wissensverteilung.

Lessons learned bedeutet Lernen aus Erfahrungen. So sollen beispielsweise Projekte nach Abschluss reflektiert werden um sowohl aus Fehlern zu lernen als auch besonders gut Gelungenes wiederholen zu können. Die Differenz aus dem, was geplant war und dem, was passiert ist, wird analysiert und dokumentiert.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-1: Werkzeuge und Techniken von Wissensmanagement in KMU

Interne Foren entsprechen technisch den weitverbreiteten Internetforen. Hier kann gezielt auf Aussagen von Experten und Mitarbeitern zurückgegriffen werden oder in Form eines Dialogs Problemstellungen gelöst werden.

Debriefing im Zusammenhang mit Wissensmanagement kann als Interview verstanden werden, „in dem das Wissen bestimmter Experten ermittelt und [...] letztlich in Datenbanken abgespeichert“ wird [Gus08, S. 129]. Das (implizite) Wissen, das dabei erhoben wird, soll also in explizites und für mehrere Personen verfügbares Wissen umgewandelt werden.

2.2 Organisationale Wikis

Organisationales Wissensmanagement wird im Folgenden am Beispiel der Unternehmens-Wikis konkretisiert. Dabei wird neben dem eigentlichen Wiki-Prinzip auf Herausforderungen, Nutzen, und Problemstellungen bei der Einführung eingegangen, die auch auf Wissensmanagement-Werkzeuge im Allgemeinen übertragbar sind.

Das „Prinzip Wiki“ lässt sich sehr einfach beschreiben. Bei einem Wiki handelt es sich um eine Web-Oberfläche einer Datenbank, die mit einem beliebigen Internetbrowser angezeigt werden kann. Die Oberfläche stellt Web-Seiten (Artikel) dar, deren Inhalte grundsätzlich von jedem Nutzer erstellt, bearbeitet, verschoben, kommentiert und gelöscht werden können. Sämtliche Änderungen an Inhalten werden in einer Versionsgeschichte mit „Wer, was und wann?“ protokolliert und sind von jedem einsehbar und revidierbar. Die Inhalte können mit einer Wiki-spezifischen Syntax formatiert werden, so dass strukturierter Text, Bilder, Dateianhänge oder Tabellen möglich sind. Ein weiteres bedeutendes Merkmal von Wikis sind Links zwischen den einzelnen Artikeln, die ebenfalls von den Nutzern leicht erstellt werden können. Damit bilden sich zum Teil dichte Netze aus Beziehungen zwischen Inhalten. Diese Beziehungen sind allerdings grundsätzlich in ihrer „Bedeutung“ nur für Menschen und aus dem Textzusammenhang erfassbar. Schwierig bis unmöglich gestaltet sich dagegen eine automatische Erfassung des vernetzten Wissens durch Maschinen.

Zwei Schlüsselwörter sind im Zusammenhang mit der immer stärkeren Verbreitung von Wikis in Unternehmen von zentraler Bedeutung: Kommunikation und Kollaboration.

Die Kommunikation zwischen zwei Nutzern des Wikis geschieht über das Wiki selbst. Ein Nutzer schreibt zum Zeitpunkt t einen Text in das Wiki, übernimmt also die Rolle eines Autors. Ein zweiter Nutzer kann diesen Text nun lesen. Von einer Kommunikation kann aber erst gesprochen werden, „wenn ein Leser sich des Verstehens einer Webseite bemüht“ [Bla08, S. 187]. Dieses Verstehen ist an sich natürlich nicht direkt sichtbar, denn Kommunikation entsteht nicht auf der Webseite, sondern „genau nur an der Grenze zwischen Wiki und Leser“ [Bla08, S. 187]. Genau das wird auch in Abbildung 2-2 deutlich.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-2: Kommunikation an der Grenze zwischen Wiki und Leser [Bla08, S. 187]

Wenn eine Kommunikation stattgefunden hat, kann das dennoch belegt werden – an der Versionsgeschichte der Seite. Denn wenn ein Leser selbst zum Autor wird und den Artikel bearbeitet, kann man davon ausgehen, dass er das Gelesene auch verstanden hat. Diese Bearbeitung lässt sich nachvollziehen. Ein typischer Leser unterscheidet nicht, wer vor ihm welche Veränderungen vorgenommen hat; es können auch mehrere sein. Seine eigene Autorentätigkeit bezieht also unter Umständen das Verstehen der Informationen von einer ganzen Gruppe anderer Autoren ein – in dem Fall kann von „indirekter Kommunikation“ ausgegangen werden, die „alle vorhergehenden Bearbeitungen mit einbezieht“ [Bla08, S. 188].

Von Kollaboration wird gesprochen, wenn mehrere Personen an einem Thema (oder Projekt) im Wiki zusammenarbeiten. Diese Kollaboration „kommt dabei ausschließlich kommunikativ zustande“ [Bla08, S. 189]. Für das Wiki bedeutet Kollaboration, dass zwei oder mehr Autoren gemeinsam eine Seite bearbeiten. Dabei bleibt es aber eine Definitionsfrage, ab wann man konkret von Kollaboration ausgehen kann. [Bla08, S. 189] definiert zum Beispiel zweimaliges Kommunizieren als Kollaborieren oder ständige Wartungsarbeiten (Rechtschreibkorrektur), jedoch nicht das Korrigieren eines Satzzeichens. Wenn solche Definitionen getroffen sind, lassen sich auch empirische Betrachtungen von Kommunikation und Kollaboration in Wikis anstellen um die Entwicklung und den Erfolg eines Wikis für ein Unternehmen mathematisch bemessen zu können^[1]. Die Untersuchungen eines Unternehmenswikis in [Bla08] führten zu dem Ergebnis, dass die gemeinschaftliche Wissenserzeugung durch Kollaboration – ein Hauptmerkmal von Wikipedia – in Unternehmen nur sehr beschränkt stattfindet. Viele Inhalte werden durch Vorbefüllung oder von den Personen erstellt, die auch funktional mit dieser Arbeit betraut wurden.

Unternehmenswikis unterscheiden sich in mehreren Punkten von öffentlichen Wikis wie der Wikipedia. Das Wissen des Unternehmens muss vor unberechtigten Zugriffen geschützt werden und ist deshalb in der Regel nur im Firmenintranet verfügbar. Aus der Verfügbarkeit im Intranet ergeben sich natürlich Vorteile. [War07, S. 47] spricht von der „Entgrenzung von IT-Systemen im Wissensmanagement“ – über alle Fachbereiche hinweg „haben potenziell alle Mitarbeiter die Chance, […] bei Bedarf einfach und schnell zusammenzuarbeiten“. Einzeln administrierte Intranet-Bereiche der Fachabteilungen werden durch eine Gesamtlösung ersetzt.

Auch innerhalb organisationaler Wikis werden oft rollenbasierte Zugriffsrechte benötigt um z.B. dem Management andere Bereiche anzeigen zu können als Praktikanten oder technischen Redakteuren, die die Inhalte pflegen. In einem solchen Wiki könnte sich von Besprechungsprotokollen bis zu sensiblen Daten künftiger Produkte grundsätzlich alles befinden. Ein weiterer Unterschied ist, dass sich Nutzer in Firmen-Wikis namentlich anmelden müssen, sich also nicht „anonym“ hinter einer IP-Adresse verbergen können wie bei Wikipedia. Daraus folgt automatisch ein Maß an Seriosität bei den Bearbeitungen; Vandalismus ist ebenso wenig ein Problem.

Nachteilig wirkt sich allerdings neben der subjektiven Zeitbeschränkung für Mitarbeiter (solche, die aus fehlender Eigenmotivation resultiert) auch eine objektive Zeitbeschränkung aus: „Auch hoch motivierten Mitarbeitern fehlt häufig die Zeit, sich systematisch auf Wiki-Arbeit einzustellen“ [War07, S. 46].

Eine Komplettlösung bieten Wikis in Unternehmen noch nicht: Die Konkurrenz zu Email, Office oder Content Management Systemen ist vorhanden und noch nicht aufgelöst [War07, S. 47]. Der stetig wachsenden Beliebtheit tut das derzeit keinen Abbruch.

2.3 Semantische Erweiterung

Neben dem seit Jahren verbreiteten und akzeptierten Wiki-Prinzip der Kommunikation und Kollaboration ist derzeit die semantische Erweiterung Gegenstand wissenschaftlicher Betrachtungen und erster praktischer Umsetzungen. Welche Mehrwerte semantische Wikis bringen sollen, wo sie eingesetzt werden und werden können und welche Systeme es derzeit gibt, soll in diesem Abschnitt betrachtet werden.

Zunächst wird jedoch die syntaktische Grundlage des Semantischen Webs und damit auch von semantischen Wikis gelegt: die formale Beschreibungssprache. Hier gibt es eine historische Entwicklung, von XML über RDF und RDFS hin zu OWL und OWL 2. Die folgenden Abschnitte vollziehen diese Entwicklung nach.

2.3.1 Formale Beschreibungssprachen für das Semantische Web

Ohne einheitliche Standards wird sich das semantische Web nicht durchsetzen können. Deshalb hat das World Wide Web Consortium (W3C) Standards entwickelt und veröffentlicht, die sich (unter anderem) auch für die Realisierung dieser aktuellen Technologie einsetzen lassen. Diese Sprachen – XML, RDF, RDF Schema und die Varianten von OWL sollen in diesem Abschnitt vorgestellt werden. Es kann sich im Rahmen dieser Arbeit jedoch nur um einen Einblick handeln. Ziel ist es, anhand von Beispielen die Hauptmerkmale der Sprachen herauszustellen, was sie leisten und nicht leisten können und in welchen Bereichen sie eingesetzt werden.

2.3.1.1 XML

XML steht für “e X tensible M arkup L anguage” und ist eine Auszeichnungssprache und dient folglich dazu, Daten und teilweise deren Verarbeitung zu beschreiben. XML-Dokumente sind dazu geeignet, eine logische Struktur zu beschreiben und andere Auszeichnungssprachen zu definieren. Beispiele dafür sind XHTML, RSS, GPX, aber auch die Definitionen von RDF(S) und OWL. Wie gezeigt wird, ist XML keine für das Semantische Web geeignete Sprache, aber als Metasprache die Grundlage solcher Sprachen.

Ein entscheidendes Merkmal von XML ist die Maschinenlesbarkeit. XML besteht nur aus Textdaten (nicht binäre), beschreibt hierarchisch Strukturen und hat einen eindeutigen, wohlgeformten Aufbau.

Der Aufbau eines XML-Dokumentes ist in der W3C-Spezifikation^[2] definiert. Das erste Element ist die Deklaration des Dokumentes mit Versionsnummer und optional dem verwendeten Zeichensatz.

<?xml version= "1.0" encoding= "utf-8" ?>

Hauptbestandteil von XML-Dokumenten sind Elemente. Diese werden durch Tags begrenzt (in der Regel Start- und End-Tag, aber auch leere Elemente). Zwischen diesen Tags steht der Inhalt des Elements – das können Daten in Form von Zeichen oder auch andere Elemente sein, womit sich eine Hierarchie wie in folgendem Beispiel ergibt:

Abbildung in dieser Leseprobe nicht enthalten

Das erste Element nach dem Deklarationsteil heißt Wurzelelement und in diesem Element müssen alle anderen verschachtelt sein.

Der zweite wesentliche Bestandteil in Dokumenten sind Attribute. Attribute können nicht allein stehen, sondern sind immer Bestandteil eines Elements und gelten auch nur lokal für dieses Element. Sie „bieten die Möglichkeit, gewissen Aspekten eines XML-Elements Werte zuzuweisen“ [Hit08, S. 20]. Im Start-Tag werden die Attribute definiert, die für jeweils das enthaltene Element gelten, wie im folgenden Beispiel zu sehen ist:

Abbildung in dieser Leseprobe nicht enthalten

Beim Einsatz von Attributen sind meistens Design-Varianten möglich. So könnte obiges Beispiel auch nur mit Elementen formuliert werden (Auszug):

Abbildung in dieser Leseprobe nicht enthalten

Die gespeicherten Daten sind zwar die gleichen, die logische Bedeutung ist aber eine völlig andere als in der ersten Variante. Welche Variante einzusetzen ist, kann man häufig anhand genereller Richtlinien ermitteln [Hit08, S. 20f.]. Verschachtelte Elemente sind dann geeignet, wenn die Daten bereits eine eigene Struktur haben. Attribute bieten sich an, wenn das Element beschrieben werden soll, also Informationen darüber ausgedrückt werden sollen. Außerdem muss berücksichtigt werden, dass Attribute keine Struktur besitzen, die von einem XML-Parser ausgewertet werden könnte, und nicht erweitert werden können.

Ein vordefiniertes Attribut von XML ist xml:lang; damit lässt sich die Sprache eines Elements festlegen, z.B. mit xml:lang="de".

Zwei Probleme sollen erwähnt werden, die mit XML bestehen. Elementbezeichner können mehrdeutig sein, beliebtes Beispiel ist der „Titel“. Titel kann zum einen als Bezeichnung eines akademischen Grades als auch als Titel einer Veröffentlichung gemeint sein. Ein XML-Dokument, in dem beide vorkommen, z.B. in einer Bestandsübersicht einer Bibliothek, wird damit mehrdeutig.

Dieses Problem wird in XML durch sogenannte XML-Namensräume (Namespaces) gelöst. Namensräume ermöglichen die Zusammenfassung von XML-Elementnamen um sie in Untermengen aufzuteilen, zu modularisieren [Hit08, S. 25]. Zusammen mit dem Namensraum ergeben sich damit einheitliche und eindeutige Bezeichner, die in anderen XML-Dokumenten beliebig wiederverwendet werden können. Die Bezeichner werden über URIs^[3] erzeugt.

Um einen Namensraum zu verwenden, wird dieser als Attribut im Start-Tag eines Elementes angegeben und ist innerhalb dieses Experimentes gültig, also auch in allen darin verschachtelten Elementen. In einem Element können beliebig viele Namensräume angegeben werden und genau ein Standard-Namensraum. Das W3C selbst hat einige Namensräume in Empfehlungen veröffentlicht, von denen unter anderem folgende auch für die weiteren Betrachtungen relevant sind:

- RDF/XML:
- RDFS:
- OWL:

Hinter den URIs verbergen sich wiederum XML-Dokumente, die ihrerseits auch wieder mit Namensräumen arbeiten. Um Elemente aus den Namensräumen im eigenen XML-Dokument zu nutzen, müssen nur die Bezeichner vor den eigentlichen Elementnamen gesetzt werden, z.B. <owl:Class rdf:about="...">.

Die Namensräume sind nur für Elemente und nicht für Attribute nutzbar – diese sind, wie erwähnt, nur lokal im Element gültig und befinden sich dementsprechend auch nicht im Sichtbarkeitsbereich von verweisenden Dokumenten. Das ist ein weiterer Punkt, der beachtet werden muss, wenn die Entscheidung getroffen werden muss, ob eine Struktur durch Elemente oder mit Attributen gebildet werden soll.

Die Struktur von XML-Dokumenten – also „welche Element- und Attribut-Namen überhaupt erlaubt sind, wie Tags verschachtelt und wie Elemente und Attribute verwendet werden dürfen“ [Hit08, S. 22] – kann zusätzlich vorgegeben werden. Dazu existieren DTD und das umfangreichere XML Schema. Mit Hilfe entsprechender validierender Parser kann dann geprüft werden, ob ein XML-Dokument gültig ist in Bezug auf die vorgeschriebene Struktur.

XML kann trotz seiner vielen Vorteile (vor allem die Maschinenlesbarkeit) nicht für das Semantische Web genutzt werden: Eine Maschine kann zwar die Struktur eines XML-Dokumentes verstehen, aber nicht den Sinn, der sich hinter den Elementen und Attributen verbirgt. Es handelt sich lediglich um frei wählbare Bezeichner, die zwar einen Sinn für Menschen haben können und sollten, „für Maschinen jedoch sind sie nach wie vor bedeutungslos im Sinne von ‚ohne Semantik‘“ [Hit08, S. 30]. In den Tags sind die Bedeutungen der Worte und vor allem deren Beziehungen untereinander nicht kodiert. XML wird also nur dazu dienen können, eine „syntaktische Grundlage anderer Beschreibungssprachen“ [Hit08, S. 31] zu sein. Auch XML-Schema und DTD sind zu ausdrucksschwache Mittel um eine Semantik abzubilden.

Ein anderes Problem liegt in der Baumstruktur begründet, denn damit lassen sich nur hierarchische Strukturen darstellen. Viele reale Beziehungen sind jedoch nicht hierarchisch, sondern auf „gleicher Ebene“ und dort stößt eine Baumstruktur an ihre Grenzen. Im folgenden Abschnitt wird die mit XML definierte Sprache RDF beschrieben, die selbst nicht mehr Bäume abbildet, sondern Graphen.

2.3.1.2 RDF und RDF Schema

RDF bedeutet Ressource Description Framework und wurde ebenfalls vom W3C als Standard veröffentlicht. RDF soll nicht nur Dokumente korrekt darstellen, sondern auch „die Kombination und Weiterverarbeitung der enthaltenen Informationen“ ermöglichen und zum Austausch von Daten im Web dienen, „ohne dass ihre ursprüngliche Information verloren geht“ [Hit08, S. 35]. Mit RDF(S) sollen also einfache Ontologien erstellt werden können, Definitionen der Begriffe und Beziehungen, mit denen das Wissensgebiet modelliert wird. Damit ist RDF als Grundlage des Semantischen Webs prädestiniert. Für RDF existieren mittlerweile viele Werkzeuge, auch Programmiersprachen bieten Schnittstellen an und die Auswertung von RDF-Daten wird durch frei verfügbare Werkzeuge ermöglicht.

Sämtliche Graphen in diesem Abschnitt (und später beim Entwurf der Ontologie) wurden mit der der Java-Anwendung RDF-Gravity^[4] erstellt, einer frei verfügbaren Software der Salzburg Research Forschungsgesellschaft mbH. Damit können RDF- und OWL-Dokumente visualisiert werden und beliebig Details ein- und ausgeblendet werden. Auf die unterschiedlichen textuellen Darstellungsformen für RDF (RDF/XML, N3, Turtle, N-Triples) wird dagegen nicht eingegangen^[5].

Zur Erstellung der Dokumente in RDF(S) und OWL wurde Protégé^[6] verwendet – ein frei verfügbarer und plattformunabhängiger Ontologie-Editor, der ursprünglich von der Stanford Universität entwickelt wurde. Protégé unterstützt sämtliche hier vorgestellte Sprachen.

Wie bereits erwähnt, beschreibt ein RDF-Dokument einen (gerichteten) Graphen, also durch Kanten verbundene Knoten. Mit einem solchen Graphen lassen sich Beziehungen am besten darstellen, außerdem ist er leicht kombinier- und erweiterbar mit anderen RDF-Graphen aus externen Quellen. Graphen „sind also für die Komposition dezentraler Informationen geeignet“ [Hit08, S. 37]. Die Kanten, die – genau wie Knoten – durch URIs bezeichnet werden, stellen die Verbindung zwischen genau zwei Knoten her und drücken damit deren Beziehung zueinander aus. Der Graph besteht also aus einer Menge von Tripeln, die als Subjekt-Prädikat-Objekt-Beziehung gelesen werden können.

Ein Instrument von RDF sind Literale um Datenwerte darzustellen. Literale haben einen oder keinen Datentypen. Wenn kein Datentyp angegeben ist, wird der Wert als Zeichenkette angenommen. Literale können stets nur Endpunkt eines Tripels sein, also Objekt – über Literale können also keine Aussagen gemacht werden. Neben ungetypten Literalen gibt es Zeichenketten, Wahrheitswerte, Daten oder numerische Typen. In RDF/XML wird der Datentyp als Wert des Attributes rdf:datatype zum Literal angegeben. Der Datentyp spielt für die Verarbeitung des Literals eine große Rolle [Hit08, S. 51]:

- Der Wertebereich beschreibt unterschiedliche Interpretation für Literale dieses Typs.
- Der lexikalische Bereich des Typs beschreibt die Menge der syntaktisch zulässigen Ausprägungen.
- Die Abbildung des lexikalischen in den Wertebereich weist jeder syntaktischen Angabe einen konkreten Bereich zu.

Mit RDF lassen sich mit Hilfe binärer auch n-äre Beziehungen darstellen. Dazu müssen lediglich Hilfsknoten eingeführt werden, die mit einer eigenen URI bezeichnet werden, oder auch als leere Knoten (Blank Nodes) ohne Bezeichner verwendet werden. Mit leeren Knoten werden auch offene Listen (Container) und geschlossene Listen (Collection) möglich – im Endeffekt basieren aber auch diese Konstrukte auf dem Tripel Subjekt-Prädikat-Objekt aus zwei Knoten und einer Kante dazwischen.

Ein Nachteil von RDF ist, dass sich kein Schemawissen hinterlegen lässt, also Hintergrundwissen über die Bedeutung der Bezeichner. Wie in XML sind die Bezeichner nur Zeichenketten, die zwar ein Mensch „verstehen“ kann, aber keine Maschine. Schlüsse wird eine Maschine erst ziehen können, wenn sie die Zusammenhänge und die Bedeutung der Zusammenhänge mitgeteilt bekommt. Dafür wurde RDF Schema (RDFS) als Empfehlung des W3C veröffentlicht. RDFS ist eine Variante von RDF und demzufolge sind diese Dokumente immer auch korrekte RDF-Dokumente.

Mit RDFS werden Ausdrucksmittel bereitgestellt, mit denen „innerhalb eines RDFS-Dokuments Aussagen über die semantischen Beziehungen der Termini eines beliebigen nutzerdefinierten Vokabulars“ gemacht werden können [Hit08, S. 67]. Damit ist RDFS eine Wissensrepräsentations- oder Ontologiesprache, mit der einfache Ontologien abgebildet werden können. Das Vokabular beschreibt eine Domäne.

Einige neue Sprachmittel werden dafür zur Verfügung gestellt [Hit08, S. 68 ff.], viele sind aus der Objektorientierung bekannt. Die wichtigsten werden vorgestellt und für das aus dem vorigen Abschnitt bekannte Stadt-Beispiel umgesetzt. Abbildung 2-3 zeigt den RDF-Graphen, dessen Bestandteile beschrieben werden^[7].

Klassen und Instanzen: Klassen sind eine Menge von Ressourcen (Instanzen). Um eine Ressource zu einer Klasseninstanz zu machen, muss sie mit dem Attribut rdf:type annotiert werden. Die Klassenbezeichner werden, wie die Instanzen auch, als URI definiert. Das reicht natürlich nicht aus, denn für eine Maschine ist die Klasse bis hierhin auch nur ein Bezeichner. Die Klassenressource muss zusätzlich mit rdf:type auf die Metaklasse rdfs:Class (Klasse aller Klassen) getypt werden. In der grafischen Darstellung von RDF Gravity erkennt man die Klassen Stadt und Stadtteil an blauen Rechtecken mit den rdf:type-Kanten zu rdfs:Class. Die Instanzen „Berlin“ und „München“ werden dann mit Stadt getypt, „Giesing“ und „Sendling“ mit Stadtteil.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-3: RDF-Graph der Stadt-Ontologie

Klassenhierarchien sind auch aus der Objektorientierung bekannt um typische Spezialisierungsbeziehungen zu beschreiben. So könnte eine Stadt eine spezielle Siedlung sein (so wie zum Beispiel Dorf und Markt). In RDFS wird eine solche Beziehung durch rdfs:subClassOf dargestellt. Sie geht also immer von der speziellen zur allgemeinen (Ober-)Klasse. Damit wird die Erweiterbarkeit sichergestellt, weil die Oberklasse nicht darüber „informiert werden“ muss, welche Klassen Unterklassen von ihr sind. Im Beispiel-Graph sind keine Klassenhierarchien vorhanden.

Eigenschaften bzw. Attribute (Propertys): Nachdem in den RDFS-Tripeln Subjekte und Objekte durch Instanzen, Klassen und Literale spezifiziert werden können, fehlt noch eine Möglichkeit, die Prädikate (also die Kanten) so zu deklarieren, dass sie als Beziehungen erkennbar sind. Bereits in RDF ist der Klassenbezeichner rdf:Property verfügbar, mit der eine Eigenschaft getypt wird. In RDF Gravity sind Eigenschaften als rote Dreiecke zu erkennen (HatStadtteil, HatEinwohner, HatKennzeichen).

Attributeinschränkungen mit Domain und Range: Um zu verhindern, dass Attribute zwischen „falschen“ Klasseninstanzen oder unsinnigen Literalen verwendet werden, können mit RDFS Einschränkungen getroffen werden. Dabei wird mit rdfs:domain der Typ des Subjektes und mit rdfs:domain der Typ des Objektes (auch Literals) angegeben. Domain und Range stellen also „das semantische Bindeglied zwischen Klassen und Propertys“ dar [Hit08, S. 77]. So ist im Beispiel die Eigenschaft HatEinwohner über rdfs:domain mit Stadt und über rdfs:range mit dem Datentypen xsd:int verbunden.

Ein Modellierungsaspekt muss noch angesprochen werden: Bei Domain und Range müssen immer die allgemeinsten Klassen angegeben werden, deren Instanzen für die Beziehung in Frage kommen. Werden stattdessen mehrere Domain- oder Range-Angaben für eine Eigenschaft getroffen, bedeutet das keine oder- sondern eine und-Verknüpfung.

Eigenschaftenhierarchien können ähnlich wie Klassenhierarchien gebildet werden. Dazu wird eine Eigenschaft mit rdf:subPropertyOf spezifiziert. So könnte HatStadtteil eine Untereigenschaft von HatTeil sein. Damit kann für eine Maschine aus dem RDFS-Tripel München – HatStadtteil – Giesing abgeleitet werden, dass auch München – HatTeil – Giesing gilt (nicht umgekehrt). Im Beispiel-Graph sind keine Eigenschaftenhierarchien vorhanden.

Die vorgestellten Sprachmittel von RDFS stellen nicht den gesamten Umfang dar – daneben gibt es noch offene und geschlossene Listen, Aussagen über Aussagen (Reifikation) und das Angeben von zusätzlichen Informationen (Kommentare, Labels).

Die formale Semantik von RDFS wurde erst nachträglich eingeführt, weil es „zu Inkompatibilitäten und Inkonsistenzen zwischen verschiedenen Implementierungen der Spezifikation“ kam [Hit08, S. 91]. So wurden beispielsweise identische Anfragen an RDF-Datenspeicher mit unterschiedlichen Ergebnissen beantwortet. Die formale Semantik legt einen Standard fest, mit dem aus den Sätzen (Tripeln) von RDF(S) Aussagen durch Schlussfolgerung getroffen werden. Das bedeutet, dass bewiesen werden soll, dass ein Graph (eine Behauptung) aus einem anderen Graphen (dem Wissen) folgt. Die mathematisch logischen Grundlagen für dieses Schlussfolgern (mit Hilfe der Deduktions- bzw. Ableitungsregeln) würden über den Inhalt dieser Arbeit weit hinausgehen, dafür sei auf die entsprechende Fachliteratur verwiesen. Dennoch sollen hier einige wichtige dieser Regeln genannt werden [Hit08, S. 110 ff.]:

- Domain und Range: Wenn das Subjekt eines Tripels mit einem Prädikat verbunden ist, das eine Domain-Einschränkung hat, kann gefolgert werden, dass das Subjekt eine Instanz des Domain-Typs ist. Das gilt analog auch für das Objekt eines Tripels bei einer Range-Einschränkung des Prädikats.
- Reflexivität von Untereigenschaften: Jede Eigenschaft ist Untereigenschaft von sich selbst.
- Transitivität von Untereigenschaften: Wenn eine Eigenschaft p1 Untereigenschaft von p2 ist, und p2 Untereigenschaft von p3, dann ist p1 auch eine Untereigenschaft von p3.
- Definierende Eigenschaft von Untereigenschaften: Wenn p1 eine Untereigenschaft von p2 ist und das Tripel S-p1-O gilt, gilt auch S-p2-O (siehe Stadt-Beispiel).
- Vererbung der Klasse: Wenn K1 Unterklasse von K2 ist und R Instanz von K1 ist, dann ist R auch in K2 enthalten.
- Reflexivität von Unterklassen: Jede Klasse ist Unterklasse von sich selbst.
- Transitivität von Unterklassen: Wenn eine Klasse K1 Unterklasse von K2 ist, und K2 Unterklasse von K3, dann ist K1 auch eine Unterklasse von K3.

Auch für Datentypen, Literale und Listen (Container) existieren Ableitungsregeln. Die Standard-Semantik ist dennoch bewusst schwach gehalten, damit leicht zu implementierende (und vor allem performante) Ableitungsregeln definiert sind.

Die Grenzen von der RDFS-Semantik und von RDFS im Allgemeinen zeigen sich zum Beispiel in folgenden Fällen [Hit08, S. 119]:

- Die Übertragung der Einschränkung einer Eigenschaft auf ihre Oberklasse kann nicht geschlussfolgert werden, auch wenn das sinnvoll erscheint: Der Range von ist und ist ein – es kann aber nicht geschlussfolgert werden, dass den Range hat.
- Es ist unmöglich auszudrücken, dass etwas nicht gilt. Die bloße Abwesenheit einer Aussage impliziert nicht, dass sie nicht gilt^[8]. So kann z.B. nicht modelliert werden, dass die Klassen Stadt und Buch keine gemeinsamen Elemente enthalten dürfen.
- Mengenangaben (Kardinalitäten) lassen sich nicht modellieren. Es gibt keine Möglichkeit auszudrücken, dass eine Stadt mindestens einen Stadtteil haben muss, oder dass ein Experiment aus genau fünf Phasen besteht.

Die Sprache OWL soll diese Mängel beseitigen und damit wesentlich komplexere Ontologien und Schlussfolgerungen ermöglichen – verbunden allerdings mit deutlich schlechterem Laufzeitverhalten bei der Dekuktion.

2.3.1.3 OWL

OWL steht für Web Ontology Language und wurde 2004 vom W3C standardisiert. OWL basiert auf PL1 (Prädikatenlogik erster Stufe, siehe [Läm08, S. 54 ff.]) und kann implizites Wissen durch logisches Schlussfolgern ableiten. Um dem Anwender „die Wahl zwischen verschiedenen Ausdrucksstärken zu ermöglichen“ und damit das je nach Anwendungsfall optimale Verhältnis zwischen Ausdrucksstärke und Skalierbarkeit^[9] zur Verfügung zu stellen, gibt es drei OWL-Varianten: OWL Lite, OWL DL und OWL Full [Hit08, S. 125 f.]. Die drei Teilsprachen sind in dieser Reihenfolge echte Teilsprachen voneinander. In der Praxis wird vor allem OWL DL verwendet.

Ohne auf Prädikatenlogik und die formale Semantik von OWL näher eingehen zu müssen, werden die Möglichkeiten der Ableitung neuen Wissens im Folgenden zusammen mit den Sprachmitteln von OWL angesprochen [Hit08, S. 129 ff.]. Die übliche Syntax von OWL ist RDF-konform und wird deshalb auch OWL-RDF-Syntax genannt.

OWL-Dokumente bestehen aus einem Kopf und dem Wurzelelement owl:Ontology. Der OWL-Namensraum ist mit "http://www.w3.org/2002/07/owl#" vereinbart. Andere OWL-Ontologien können mit owl:imports importiert werden und sind dann Teil der eigenen Ontologie.

Hauptinstrumente von OWL sind wie in RDFS Klassen, Objekte und Propertys (auch Rollen genannt), die aber mit Hilfe logischer Konstruktoren in Beziehung zueinander gesetzt werden können – weit über das Maß von RDFS hinaus.

Klassen werden in OWL durch owl:Class definiert (einer Unterklasse von rdfs:Class). Die Klassen owl:Thing und owl:Nothing sind vordefiniert und enthalten alles (Thing) bzw. sind leer (Nothing). Jede selbstdefinierte Klasse ist also eine Unterklasse von owl:Thing. owl:Nothing ist dagegen Unterklasse jeder anderen Klasse.

Propertys (Rollen) werden unterschieden in abstrakte und konkrete Rollen. Abstrakte Rollen verbinden zwei Objekte miteinander und werden mit owl:ObjectProperty definiert. Konkrete Rollen verbinden ein Objekt mit einem Datentyp-Wert und werden mit owl:DatatypeProperty definiert. Für beide Arten von Rollen können wie bei RDFS Range und Domain angegeben werden.

Beziehungen zwischen Klassen: Wie in RDFS gibt es (transitive) Unterklassen-Beziehungen.

Mit owl:disjointWith können Klassen als disjunkt gekennzeichnet werden, woraufhin kein Objekt beiden Klassen angehören kann. Durch owl:equivalentClass werden Klassen hingegen gleich. Dadurch wird ein Objekt der einen Klasse auch Objekt der anderen Klasse. Klassen, die gegenseitig Unterklassen voneinander sind, sind automatisch auch gleich.

Beziehungen zwischen Individuen: Mit owl:sameAs und owl:differentFrom lässt sich darstellen, dass zwei Objekte identisch oder unterschiedlich sind.

Abgeschlossene Klassen sind Klassen, bei denen mit einer Kollektion alle dazugehörigen Individuen aufgezählt werden. Ein Objekt, das nicht darin enthalten ist, ist kein Mitglied der Klasse. Damit kann die angesprochene open world assumption „umgangen“ werden.

Logische Konstruktoren auf Klassen: Atomare Klassen (bisher der Fall) können durch logische Konstruktoren (und, oder, nicht) zu komplexen Klassen zusammengeführt werden. Dazu wird die Klasse als Unterklasse einer konstruierten Klasse definiert. Eine Klasse, die mit owl:intersectionOf aus mehreren Klassen erzeugt wird, enthält genau die Objekte, die in allen atomaren Klassen gleichzeitig vorhanden sind (Und-Verknüpfung, Konjunktion).

owl:unionOf ist dagegen die Disjunktion mehrerer Klassen (Oder-Verknüpfung) und sagt aus, dass ein Objekt einer solchen Klasse Objekt mindestens einer der genannten Klassen ist.

Schlussendlich kann mit owl:complementOf das Komplement einer Klasse beschrieben werden (Negation). Sie enthält damit automatisch alle Objekte, die in der komplementären Klasse nicht enthalten sind. Logische Konstruktoren können beliebig geschachtelt werden.

Rolleneinschränkungen dienen dazu, neue komplexe Klassen zu definieren, die durch bestimmte Anforderungen an Rollen gekennzeichnet sind.

Mit owl:allValuesFrom (einer Klasse K) in Verbindung mit einer Rolle R wird ausgedrückt, dass die daraus definierte Klasse Kdef die Menge aller Objekte ist, für die R immer einen Wert aus K annimmt. Das entspricht dem Allquantor in der Prädikatenlogik. Dies ist allerdings nicht gleichbedeutend mit einer Angabe von Domain und Range für R.

Abbildung 2-4 verdeutlicht das für das Stadt-Beispiel. Stadt_Def wird konstruiert aus einer (anonymen) Rolleneinschränkung bestehend aus owl:onProperty und owl:allValuesFrom. Es wird sichergestellt, dass Stadt_Def nur Instanzen von Stadtteil über das Attribut HatStadtteil hat. Allerdings bedeutet das nicht, dass HatStadtteil die Domain Stadt_Def und den Range Stadtteil hat. Wenn das ausgedrückt werden soll, muss das explizit angegeben werden (wie in der Abbildung mit Stadt und Stadtteil geschehen). Auf diese Thematik wird hier deshalb so ausführlich eingegangen, weil das in einem späteren Abschnitt noch bedeutend wird (4.6.2.2 Exportieren von Ontologien).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-4: Nicht-Äquivalenz von domain/range und einer allValuesFrom-Restriction

Bei owl:someValuesFrom hat R mindestens ein Objekt der Klasse K als Wert, entsprechend dem Existenzquantor in der Prädikatenlogik.

Mit owl:minCardinality, owl:maxCardinality und owl:Cardinality kann die Anzahl festgelegt werden. Beispielsweise kann man eine Klasse Großstadt definieren, die dadurch gekennzeichnet ist, dass sie mindestens zehn Stadtteile hat.

[...]

^[1] Zum Beispiel durch Ko-Autoren-Netzwerke oder klassischer Zentralitätsmaße wie Betweenness-, Closeness-, Indegree- und Outdegree-Zentralität, vgl. [Bla08, S. 198 ff.]

^[2] Alle offiziellen Dokumente sind unter http://www.w3.org/XML/ zu finden

^[3] U niform R esource I dentifier, Zeichenfolge, die zur Identifizierung einer Ressource dient. URIs werden hauptsächlich im WWW verwendet und sind nach definierten einem Schema aufgebaut.

^[4] RDF GRA ph VI sualization T ool

^[5] Für die wichtigste Syntax-Form, RDF/XML, gibt es vom W3C einen Dienst zur Validierung eines Dokuments, mit dem auch zugehörige Graphen und Tripel erzeugt werden können: http://www.w3.org/RDF/Validator/

^[6] http://protege.stanford.edu/

^[7] RDF Gravity stellt URIs nicht durch Namensräume abgekürzt dar.

^[8] Das ist die sogenannte open world assumption, die bei RDF(S) und auch OWL gilt. Es wird immer angenommen, dass die Wissensbasis potenziell unvollständig ist. Die Annahme wurde (im Gegensatz zu Datenbanken) getroffen, weil das Wissen im www ständig expandiert.

^[9] Im Sinne von effizientem Schlussfolgern.