Einheitliche Repräsentation heterogener Datenquellen

Transcription

Fachbereich Informatik
Fachgebiet Sicherheit in der Informationstechnik
Fraunhofer-Institut für Sichere Informationstechnologie SIT
Prof. Dr. Claudia Eckert
Technische Universität Darmstadt
Diplomarbeit
Einheitliche Repräsentation
heterogener Datenquellen mit
Topic Maps
Johannes Bergmann
Januar 2006
Betreuer:
Prof. Dr. Claudia Eckert
Dipl. Inform. Jens Heider
Inhaltsverzeichnis
Inhaltsverzeichnis
1. Einleitung
1.1. Sichere mobile Informationsverteilung
1.1.1. E-Mail . . . . . . . . . . . . .
1.1.2. Das MIDMAY Konzept . . .
1.2. Bearbeiteter Teilaspekt . . . . . . . .
.
.
.
.
1
1
1
2
2
2. Problemanalyse
2.1. Benutzung der Repräsentation . . . . . . . . . . . . . . . . . . . . .
2.1.1. Finden von Informationsobjekten . . . . . . . . . . . . . . .
2.1.2. Verwalten der Informationsobjekte und ihrer Repräsentation
2.2. Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.1. Funktionale Anforderungen . . . . . . . . . . . . . . . . . .
2.2.2. Nicht-Funktionale Anforderungen . . . . . . . . . . . . . . .
2.3. Aktuelle Ansätze . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.1. Suchmaschinen . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.2. Verwaltungs-Systeme (Content Management) . . . . . . . .
2.3.3. Knowledge Management Systeme . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
4
5
5
6
6
7
9
11
11
12
13
3. Formate zur Repräsentation von Wissen
3.1. Topic Maps . . . . . . . . . . . . . . . . . . . . .
3.1.1. Topics . . . . . . . . . . . . . . . . . . . .
3.1.2. Occurrences . . . . . . . . . . . . . . . . .
3.1.3. Associations . . . . . . . . . . . . . . . . .
3.1.4. Scope . . . . . . . . . . . . . . . . . . . .
3.1.5. Subject Identity . . . . . . . . . . . . . . .
3.2. RDF . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.1. RDF Konzepte . . . . . . . . . . . . . . .
3.2.2. RDF-Schema . . . . . . . . . . . . . . . .
3.2.3. Web Ontology Language (OWL) . . . . .
3.3. Vergleich . . . . . . . . . . . . . . . . . . . . . . .
3.3.1. Ziele der Technologien . . . . . . . . . . .
3.3.2. Einordnung der Standards von Topic Maps
3.3.3. Identität . . . . . . . . . . . . . . . . . . .
3.3.4. Aussagen . . . . . . . . . . . . . . . . . .
3.3.5. Constraint Languages . . . . . . . . . . . .
3.3.6. Interoperabilität von Repräsentationen . .
3.3.7. Syntax . . . . . . . . . . . . . . . . . . . .
3.3.8. Fazit . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
13
14
14
15
15
17
18
18
19
19
20
21
21
22
22
23
26
28
28
29
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
und RDF
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4. Lösungsansatz
31
4.1. Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
I
Inhaltsverzeichnis
4.1.1. Komponenten . . . . . . . . . . . . . . . . . . . . . .
4.1.2. Schnittstellen . . . . . . . . . . . . . . . . . . . . . .
4.2. Sicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.1. Authentifizierung und sichere Datenübertragung . . .
4.2.2. Schutz der Zugangs- und Repräsentationsdaten . . .
4.2.3. Mehrbenutzer-Aspekte . . . . . . . . . . . . . . . . .
4.3. Darstellung und Navigation . . . . . . . . . . . . . . . . . .
4.3.1. Visualisierung von Topic Maps als Graph . . . . . . .
4.3.2. Visualisierung von Hierarchien . . . . . . . . . . . . .
4.3.3. Klassifizierung von Informationen durch Facets . . .
4.3.4. Darstellung einzelner Topics . . . . . . . . . . . . . .
4.4. Modellierung . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4.1. Published Subjects . . . . . . . . . . . . . . . . . . .
4.4.2. Topic Map Templates . . . . . . . . . . . . . . . . . .
4.4.3. Patterns für Topic Maps . . . . . . . . . . . . . . . .
4.4.4. Topic Map Modell zur Indizierung von Datenquellen
4.4.5. Dateisysteme . . . . . . . . . . . . . . . . . . . . . .
4.4.6. E-Mail . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4.7. Eigenschafts-Hierarchien . . . . . . . . . . . . . . . .
4.4.8. Modellierung weiterer Datenquellen . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
32
35
37
38
38
38
39
40
42
42
43
44
44
45
46
48
49
52
54
56
5. Implementierung
5.1. Topic Map APIs für Java . . . . . . . . . . . . . . . . . . . . . . .
5.1.1. TMAPI . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.2. TinyTIM . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.3. TM4J . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.4. Verwendete API . . . . . . . . . . . . . . . . . . . . . . . .
5.2. API für Topic Map Patterns . . . . . . . . . . . . . . . . . . . . .
5.3. Data Retrieval Modul . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.1. Zugriff auf die Datenquelle . . . . . . . . . . . . . . . . . .
5.3.2. Extraktion von Metadaten . . . . . . . . . . . . . . . . . .
5.3.3. Information Mapping . . . . . . . . . . . . . . . . . . . . .
5.3.4. Information Object Retrieval . . . . . . . . . . . . . . . .
5.4. Unified Representation Modul . . . . . . . . . . . . . . . . . . . .
5.4.1. Konfiguration der Extraktoren . . . . . . . . . . . . . . . .
5.4.2. Extraktoren und InputMaps . . . . . . . . . . . . . . . . .
5.4.3. Vereinigen der Topic Maps . . . . . . . . . . . . . . . . . .
5.4.4. Zugriff auf die Repräsentation und die Informationsobjekte
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
58
59
59
59
60
60
60
62
62
63
64
65
65
65
67
67
70
6. Fazit
72
6.1. Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
6.2. Bewertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.2.1. Konzepte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
II
Inhaltsverzeichnis
6.2.2. Software Architektur und Schnittstellen .
6.2.3. Implementierung . . . . . . . . . . . . .
6.2.4. Bewertung gegenüber den Anforderungen
6.3. Ausblick . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
A. Abkürzungen und Definitionen
73
73
74
77
78
B. Verwendete Published Subject Identifiers
B.1. Generische Topics . . . . . . . . . . . . .
B.2. Eigenschaften von Informationsobjekten
B.3. Dateisystem . . . . . . . . . . . . . . . .
B.4. E-Mail . . . . . . . . . . . . . . . . . . .
III
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
79
79
80
81
82
Inhaltsverzeichnis
Eidesstattliche Erklärung
Hiermit versichere ich, dass ich die vorliegende Diplomarbeit ohne Hilfe Dritter
und nur mit den angegebenen Quellen und Hilfsmitteln angefertigt habe. Diese
Arbeit hat in gleicher oder ähnlicher Form noch keiner Prüfungsbehörde vorgelegen.
IV
1 EINLEITUNG
1. Einleitung
1.1. Sichere mobile Informationsverteilung
Digitale Informationen werden in der heutigen Zeit Dank einer guten Kommunikations-Infrastruktur in großen Mengen schnell und zuverlässig übertragen. Dabei
kommen viele unterschiedliche Protokolle für die Übertragung und Datenformate für
die Speicherung der Informationen zum Einsatz. Wenn ein Benutzer Informationen
an einen bestimmten Empfänger übermitteln möchte, ist er daran interessiert, die
Informationen schnell aufzufinden und ohne großen Aufwand versenden zu können.
Sind seine Informationen jedoch über unterschiedliche Datenquellen verteilt, muss
er je nach Übertragungsprotokoll unterschiedliche Programme verwenden um die zu
versendenden Informationen zusammenzustellen, wie es z. B. bei der Informationsverteilung per E-Mail der Fall ist.
1.1.1. E-Mail
Der Informationsaustausch über E-Mail bietet die Möglichkeit Informationen in unterschiedlichen Datenformaten zusammen mit der E-Mail-Nachricht zu versenden
und ist durch komfortable E-Mail Clients sehr benutzerfreundlich. Das E-Mail Konzept hat jedoch einige Nachteile, insbesondere wenn ein sicherer Datenaustausch
gewünscht wird oder mobile Endgeräte zum Versenden der Informationen genutzt
werden sollen.
Um Informationen vertraulich übertragen zu können, ist eine Kryptographie-Infrastruktur notwendig. Deren Nutzung bedeutet jedoch einen höheren Aufwand in der
Konfiguration und Benutzung des E-Mail Clients durch den Anwender, weil Zertifikate von Authentifizierungsstellen oder Kommunikationspartnern vom Benutzer
verwaltet werden müssen.
Weiterhin ist es nur möglich Informationen vertraulich zu senden, wenn sie auf dem
benutzten Rechner lokal vorhanden sind, da sie vom E-Mail Client mit dem öffentlichen Schlüssel des Empfängers verschlüsselt werden. Insbesondere bei der Nutzung
eines E-Mail Clients auf einem mobilen Endgerät mit beschränkter Bandbreite und
hohen Übertragungskosten ist es unvorteilhaft, dass die Daten vorher vollständig
zum Client übertragen werden müssen. Dieses Problem kann gelöst werden, indem
die Entschlüsselung von E-Mails auf einem speziellen Server durchgeführt wird. Da
der Server den mobilen Client über neue E-Mails sofort benachrichtigt, wird dieser Service als Push“-Service bezeichnet. Die E-Mail gelangt so direkt vom Sender
”
zum Empfänger, der nun entscheiden kann, welche Anhänge der E-Mail auch auf
sein mobiles Gerät übertragen werden sollen.
1
1 EINLEITUNG
Um seine Informationen verwalten zu können, muss der Benutzer auf unterschiedliche verteilte Datenquellen wie Dateiserver, Datenbanken und E-Mails zugreifen und
dafür verschiedene Protokolle und Programme verwenden. Dabei erhält er Sichten
auf seine Informationen, die vom Zugriffsprotokoll und Datenformat und nicht vom
Inhalt der Information abhängen. Die Verwaltung wird auch dadurch erschwert,
dass die Eigenschaften der verteilt gespeicherten Informationen nicht direkt miteinander vergleichbar sind. Außerdem fehlen Funktionen, mit denen die Informationen
miteinander in Beziehung gesetzt werden können.
1.1.2. Das MIDMAY Konzept
Um den Anforderungen einer sicheren Verwaltung und Verteilung von Information
über mobile Endgeräte gerecht zu werden, wird ein neues Konzept der Informationsverteilung benötigt. Das MIDMAY Konzept (Mobile Information Distribution and
Access for You!) [10] soll dem Benutzer eine einheitliche Sicht auf verteilt gespeicherte Informationen bieten und den vertraulichen Informationsaustausch zwischen
zwei sich zuvor unbekannten Personen ermöglichen. Es basiert auf einem mobilen
Client zur Präsentation und Auswahl der verteilt gespeicherten Informationen des
Benutzers, und einer Homebase, welche auf die verteilten Datenquellen zugreifen
kann.
In Abbildung 1 wird gezeigt, wie die Kommunikation zwischen zwei MIDMAY
Benutzern abläuft, die zum ersten Mal Informationen austauschen wollen. Zuerst
werden die MIDMAY-Identitäten zwischen den mobilen Geräte ausgetauscht (1).
Die Identitäten enthalten den öffentlichen Schlüssel und die Homebase-Adresse des
Kommunikationspartners. Über den Client wird die zu versendende Information ausgewählt (2) und die Homebase angewiesen diese Informationen von den verteilten
Datenquellen auf die Homebase zu laden (3+4), um sie von dort verschlüsselt an
die Homebase des Kommunikationspartners zu senden (5). Ist das Endgerät des
Empfängers erreichbar, kann dieser benachrichtigt werden (6) und entscheiden, an
welches Ausgabegerät die Informationen weitergeleitet oder wo sie abgelegt werden
sollen (7+8). Alternativ kann die Homebase auch selbstständig über die Ablage der
Informationen entscheiden, z. B. wenn das Endgerät nicht erreichbar ist.
1.2. Bearbeiteter Teilaspekt
Ein großer Vorteil von MIDMAY ist, dass der Benutzer Informationen vor dem Versenden nicht erst selbst mit Hilfe von verschiedenen Anwendungen und Protokollen
auf sein mobiles Gerät übertragen muss, sondern von seinem MIDMAY-Client eine einheitliche Sicht auf seine Informationen erhält. Die einheitliche Sicht wird von
der MIDMAY-Homebase als Repräsentation aller verteilt gespeicherten Informationen des Benutzers erstellt. Mit Hilfe der Repräsentation bietet MIDMAY Positions-
2
1 EINLEITUNG
2.
Informationsauswahl
3.
Instruktion der Homebase
Homebase (Sender)
Sender
1.
Drahtloser
Austausch
4.
Abfrage der Informationen
Informationen
und Metadaten
MIDMAY
Identität
Empfänger
5.
Übertragung
Homebase (Empfänger)
6.
Benachrichtigung
7.
Ablageinstruktionen
8.
Ablage/Weiterleitung
Abbildung 1: MIDMAY Szenario
und Zugriffstransparenz [8]. Der Benutzer kann auf seinem MIDMAY-Client ein Informationsobjekt auswählen, ohne dass er den physischen Speicherort des Objekts
kennt (Positionstransparenz). Für die Suche nach Informationsobjekten stehen dem
Benutzer dabei unabhängig von der Art der Datenquelle, ob E-Mail-Postfach oder
Dateisystem, die gleichen Operationen zur Verfügung (Zugriffstransparenz).
Ziel dieser Arbeit ist es, ein Konzept zur Erstellung der einheitlichen Repräsentation
aus den Informationen der verteilten Datenquellen zu entwickeln und prototypisch zu
implementieren. Dazu muss untersucht werden, wie die Datenquellen modelliert und
ihre Informationen abgebildet werden, welche Datenstruktur sich für die Repräsentation eignet und welche Anforderungen an das Software-Modul zur Erstellung der
Repräsentation bestehen.
Im MIDMAY Konzept sind zwei Software-Module vorgegeben, die zusammen für die
Repräsentation der Datenquellen verantwortlich sind. Das Data Retrieval Module
(DRM) ist für den Zugriff auf die verschiedenen verteilten Datenquellen zuständig.
Es indiziert die auf den Datenquellen vorhandenen Informationen und bildet sie
in die Datenstruktur der Repräsentation ab. Das Unified Representation Module
(URM) ist für die Verwaltung dieser Datenstruktur zuständig. Es bietet dem DRM
3
2 PROBLEMANALYSE
und dem Client Schnittstellen für den Zugriff auf die Repräsentation. Das DRM
muss zur Erstellung und Aktualisierung der Repräsentation mit dem URM kommunizieren. Der Client muss auf die Repräsentation zugreifen können, damit der
Benutzer in der Repräsentation seiner Informationen navigieren, suchen und diese
strukturieren kann. Abbildung 2 zeigt alle Module der MIDMAY Homebase und
veranschaulicht, welche Funktionen die Module DRM und URM erfüllen müssen.
Die Anforderungen an Data Retrieval Module“ und Unified Representation Mo”
”
dule“ sollen in dieser Diplomarbeit ermittelt und in einem demonstrationsfähigen
Prototyp in der Programmiersprache Java umgesetzt werden.
Client
Informationen suchen
und auswählen
Homebase
Unified Representation
Module
(URM)
ID Management
Module
(IDM)
Context Awareness
Module
(CAM)
Data Retrieval
Module
(DRM)
Security Assertion
Module
(SAM)
Data Transfer
Module
(DTM)
Austausch von
Informationen
Indizierung von
Informationen
Homebase
Verteilte Datenquellen
Abbildung 2: MIDMAY Module
2. Problemanalyse
Innerhalb MIDMAY ist die Hauptaufgabe der einheitlichen Repräsentation, den
Benutzer beim Auffinden und Verwalten seiner verteilt gespeicherter Informationsobjekte zu unterstützen. Es wird im folgenden beschrieben, wie die Benutzung der
Repräsentation aussehen soll, um daraus Anforderungen an ein System zur Erstellung, Verarbeitung und Bereitstellung der Repräsentation herzuleiten. Abschließend
4
2 PROBLEMANALYSE
werden bereits bestehende Ansätze für den einheitlichen Zugriff auf heterogene Datenquellen betrachtet und bezüglich der aufgestellten Anforderungen bewertet.
2.1. Benutzung der Repräsentation
Zur Verwaltung- und Verteilung der gespeicherten Informationen sollen im
MIDMAY-Konzept mobile Geräte wie Smartphones, PDAs oder Notebooks zum
Einsatz kommen. Diese Geräte verwenden kabellose Kommunikationsverbindungen,
um auf die Repräsentation der Informationen zuzugreifen. Um eine größtmögliche
Verfügbarkeit der Repräsentation für den Benutzer zu ermöglichen, ist die Zugriffsmöglichkeit über stationäre öffentliche Internet-PCs ebenfalls sinnvoll. Sobald
sich der Benutzer bei seiner Homebase angemeldet und authentifiziert hat, kann
er mit der Repräsentation seiner verteilt gespeicherten Informationen arbeiten. Er
kann nun Funktionen zum Auffinden und zur Verwaltung seiner Informationsobjekte
nutzen.
2.1.1. Finden von Informationsobjekten
Für die Suche nach Informationen auf einer entfernten Datenquelle ist der Benutzer
auf die Funktionen angewiesen, die ihm das jeweilige Protokoll oder das ClientProgramm anbietet. Die Repräsentation der Informationsobjekte seiner verteilten
Datenquellen ermöglicht dagegen eine Suche, die unabhängig von Datenquelle, Protokoll und Client ist.
Angenommen der Benutzer möchte ein Dokument X versenden, das die Projektplanung des Projekts P enthält. Falls er den Speicherort von X (z. B. einen
FTP-Fileserver) kennt, kann er diese Datenquelle auswählen und wie in einem
Dateisystem-Browser zu dem entsprechenden Verzeichnis navigieren. Ist der Speicherort von X unbekannt aber der Name (oder ein Teil des Namens) bekannt, kann
er eine Volltextsuche innerhalb der Repräsentation ausführen und so das Dokument über alle repräsentierten Datenquellen hinweg suchen. Weiß der Benutzer den
Namen nicht, kann ihm die Angabe verschiedener Metainformationen oder Eigenschaften des Informationsobjekts helfen. Der Benutzer könnte z. B. wissen, dass das
gesuchte Dokument im PDF Format vorliegt und dass es in einem bestimmten Zeitraum gespeichert wurde (nämlich in dem Zeitraum, in dem Projekt P geplant wurde)
und sich alle passenden Informationsobjekte anzeigen lassen. Es könnte auch sein,
dass das Projekt P selbst in der Repräsentation repräsentiert ist. Dann kann der
Benutzer das Projekt P auswählen, um zu allen Dokumenten zu gelangen die mit
Projekt P in Zusammenhang stehen. Dafür muss zuvor das Projekt P selbst in die
Repräsentation aufgenommen, und eine Verbindung zwischen P und den zugehörigen Informationsobjekten hergestellt worden sein. Damit solche Erweiterungen in
5
2 PROBLEMANALYSE
der Repräsentation vorgenommen werden können, sollten Verwaltungsfunktionen
zur Verfügung gestellt werden.
2.1.2. Verwalten der Informationsobjekte und ihrer Repräsentation
Das Verwalten von Informationen erfolgt auf zwei unterschiedlichen Ebenen: Zum
einen werden empfangene Informationsobjekte an einem passenden Ort abgelegt.
Zum anderen kann die Repräsentation dieser Informationsobjekte erweitert und
strukturiert werden. Die Verwaltung auf diesen beiden Ebenen kann wiederum
durch zwei unterschiedliche Akteure erfolgen, durch den Benutzer und durch weitere
Software-Module.
Der Benutzer hat das Ziel seine Informationsobjekte logisch so abzulegen, dass er
sie möglichst leicht wiederfindet. Dabei muss er sich jedoch für einen Ablageort entscheiden, wenn er die Information nicht redundant abspeichern will. Er kann so nur
eine eindimensional Einordnung der Information vornehmen. In der Repräsentation
der Informationsobjekte kann dagegen ein einzelnes Informationsobjekt zugleich in
verschiedene logische Strukturen eingeordnet werden, je nach dem aus welcher Sicht
es betrachtet wird. In obigem Beispiel könnte Dokument X einmal als Dokument
”
des Projekts P“ eingeordnet werden, aber ebenso als Dokument in Bearbeitung“
”
und als Dokument von Autor A“. Der Benutzer benötigt die Möglichkeit, die Re”
präsentation um eigene Konzepte zu erweitern und ihr eine Struktur zu geben, die
ihm das Auffinden seiner Informationen erleichtert.
Die Aufgabe Informationsobjekte einzuordnen sollte soweit möglich durch SoftwareModule unterstützt werden. Dass ein Dokument von Autor A bearbeitet wird, könnte
z. B. innerhalb des Dokuments als Metainformation gespeichert sein, so dass dieses
Dokument automatisch als Dokument von Autor A“ klassifiziert werden kann. In
”
anderen Fällen, in denen eine vollautomatische Einordnung zu unzuverlässig wäre,
könnten zumindest Vorschläge für den Benutzer generiert werden. Das MIDMAYKonzept sieht auch ein Kontext-Modul vor, das Kontextinformationen bereitstellt,
die zusammen mit den Informationsobjekten versendet werden. Die Kontextinformationen können dann beim Empfänger dazu benutzt werden, automatisch zu bestimmen, an welchem Ort das Informationsobjekt abgespeichert und wie es in die
Repräsentation eingeordnet werden soll.
2.2. Anforderungen
In Abschnitt 1.2 wurden Umfang und Aufgaben der MIDMAY-Module URM und
DRM bereits kurz dargestellt. Im vorhergehenden Abschnitt wurde näher auf die
Benutzung der Repräsentation eingegangen. In diesem Abschnitt werden die bereits
6
2 PROBLEMANALYSE
beschriebenen Funktionen und Eigenschaften in konkrete Anforderungen an ein System zur Erstellung, Verarbeitung und Bereitstellung der Repräsentation gefasst.
2.2.1. Funktionale Anforderungen
1. Erstellung
a) Indizierung
Die Informationen unterschiedlicher verteilter Datenquellen sollen indiziert werden
Informationen darüber, welche Informationsobjekte mit welchen Eigenschaften auf einer Datenquelle vorliegen, sollen in die Repräsentation
übertragen werden. Falls die Informationsobjekte als Container für weitere Informationsobjekte dienen, wie es z. B. bei einer E-Mail mit Dateianhängen der Fall ist, sollen auch diese untergeordneten Informationsobjekte mit in die Repräsentation aufgenommen werden.
Das System zur Erstellung der Repräsentation soll um beliebige Arten von
persönlichen Datenquellen erweiterbar sein. Mit persönlichen Datenquellen sind solche gemeint, auf denen persönliche Dokumente, Nachrichten
und Informationen gespeichert sind und die nur für einen beschränkten
Nutzerkreis zugänglich sind.
b) Repräsentation von Metainformationen
Zu den Informationsobjekten sollen Metainformationen in der Repräsentation gespeichert werden
Bei der Abbildung eines Informationsobjekts in die Repräsentation sollen verschiedene Eigenschaften des Informationsobjekts extrahiert und
repräsentiert werden. Solche Eigenschaften können z. B. der Typ, der Autor oder das Erstellungsdatum eines Informationsobjekts sein. Andere Informationen, die in irgendeiner Weise in Bezug zum Informationsobjekt
stehen, sollen ebenfalls als Metainformation repräsentiert werden können.
Darunter fallen z. B. Informationen über den Kontext, in dem ein Informationsobjekt versendet wurde oder Informationen, welche Dokumente
projektbezogen zusammengehören (siehe 2.1.2)). Solche zu repräsentierenden Metainformationen können sowohl vom Benutzer erstellt als auch
von Software-Modulen generiert werden.
c) Einheitliche Repräsentation
Bei der Repräsentation von Informationsobjekten und Metainformationen sollen, soweit möglich, gemeinsame einheitliche Typen verwendet
werden
Bestimmte Eigenschaftstypen, wie Autor oder Erstellungsdatum, können
zur Beschreibung von Informationsobjekten unterschiedlicher Datenquel-
7
2 PROBLEMANALYSE
len dienen. Innerhalb der Repräsentation sollten daher solche Typen zur
Angabe von Metainformationen einheitlich definiert und genutzt werden.
So können die Informationsobjekte unabhängig von ihrer Datenquelle anhand ihrer Metainformationen betrachtet werden.
2. Zugriff
a) Geräteunabhängiger Zugriff
Die Anzeige und Bearbeitung der Repräsentation soll auf Geräten mit
unterschiedlichen Eingabe- und Darstellungsmöglichkeiten möglich sein
Der Zugriff auf die Repräsentation soll unabhängig von den Möglichkeiten des verwendeten Gerät erfolgen können. Nicht nur PCs sollen
für die Informationssuche, Auswahl und Verwaltung verwendet werden
können, sondern auch Geräte mit kleinen Displays oder beschränkten Eingabemöglichkeiten wie Handys oder PDAs. Die Client-Schnittstelle muss
also den Abruf von Information und die Navigation in der Repräsentation
für verschiedene Geräte ermöglichen. Client-Implementierungen müssen
dabei nicht immer alle Funktionen der Client-Schnittstelle nutzen. Bestimmte Grundfunktionen zum Auffinden von Objekten sollten mit jedem Gerät ausführbar sein. Weitere Funktionen, wie z. B. das in Anforderung 3c beschriebene Strukturieren der Repräsentation, können je nach
Möglichkeiten des jeweiligen Endgeräts angeboten werden.
b) Mobiler Zugriff
Der Zugriff auf die Repräsentation soll ortsunabhängig und mit mobilen
Geräten möglich sein
Das in Abschnitt 1.1.2 beschriebenen Szenario geht davon aus, dass ein
Zugriff gerade dann möglich ist, wenn der Benutzer sich in einer fremden Umgebung befindet und Informationen mit einer zuvor unbekannten
Person austauschen möchte. Der Benutzer sollte also unabhängig vom
Standort möglichst jederzeit in der Lage sein auf die Repräsentation zuzugreifen. Um dieser Anforderung gerecht zu werden, müssen die Daten
vom mobilen Endgerät mit einer kabelloser Kommunikationsverbindung
übertragen werden können. Da bei mobilen kabellosen Kommunikationsverbindungen meistens geringere Übertragungsgeschwindigkeiten möglich
sind als bei stationär vernetzten PCs, ergibt sich hieraus auch die Anforderung, die übertragenen Daten möglichst gering zu halten oder zu
komprimieren.
3. Benutzung
a) Datenquellen übergreifende Suche
Die Suche nach einem Informationsobjekt soll ohne Angabe seiner Datenquelle möglich sein
Wenn der Benutzer eine bestimmte Information, z. B. eine Datei sucht,
8
2 PROBLEMANALYSE
wird von ihm nicht verlangt die Datenquelle zu kennen, auf der die Information vorhanden ist. Stattdessen kann er in der Repräsentation über alle Datenquellen hinweg z. B. nach dem Namen eines Informationsobjekts
suchen. Weitere von den Datenquellen unabhängige Suchmöglichkeiten
werden in Anforderung 3b beschrieben.
b) Suche über Metainformationen
Ein Informationsobjekt soll durch die Angabe von Metainformationen aufgefunden werden können
Nach Anforderung 1b sind in der Repräsentation die Eigenschaften eines Informationsobjekts als Metainformationen gespeichert. Der Benutzer soll die Möglichkeit haben ein Informationsobjekt zu finden, indem
er eine oder mehrere Eigenschaften des gesuchten Objekts angibt, so wie
es in Abschnitt 2.1.1 beschrieben ist. Ihm werden dann als Ergebnis alle
Informationsobjekte präsentiert, die diese Eigenschaften besitzen.
c) Strukturierung der Repräsentation
Der Benutzer soll der Repräsentation Informationen hinzufügen und sie
strukturieren können
Das Hinzufügen von Informationen ermöglicht dem Benutzer, seine eigenen gedachten Konzepte in die Repräsentation zu integrieren (siehe Abschnitt 2.1.2) und Metainformationen zu den Informationsobjekten anzugeben (vergleiche Anforderung 1b). In der Repräsentation kann er Verbindungen zwischen den Informationsobjekten und seinen hinzugefügten
Konzepten erstellen, die ihm ein späteres Auffinden der so eingeordneten
Informationsobjekte erleichtern.
2.2.2. Nicht-Funktionale Anforderungen
4. Benutztbarkeit
a) Aktualität
Es soll ein möglichst aktueller Stand der Datenquellen repräsentiert werden
Der Benutzer soll auch erst kürzlich empfangene oder erstellte Informationen in der Repräsentation auswählen können. Dazu muss die Repräsentation zum Zeitpunkt des Zugriffs den aktuellen Stand der Datenquellen
repräsentieren. Eine Repräsentation, die zu jedem Zeitpunkt den vorhandenen Informationen entspricht, ist jedoch nicht möglich, da für das Erkennen von Veränderungen auf den Datenquellen und für die Abbildung
der Informationen in die Repräsentation Zeit benötigt wird. Es kann also
nicht garantiert werden, dass immer alle Informationen der Datenquellen
in der Repräsentation vorhanden sind.
9
2 PROBLEMANALYSE
b) Kurze Antwortzeit
Operationen auf der Repräsentation sollen in angemessener Zeit ein Ergebnis liefern
Damit der MIDMAY-Client auf Aktionen des Benutzers reagieren kann,
benötigt er möglichst schnell bestimmte Daten der Repräsentation. Die
Antwortzeit von der Anfrage bis zum Ergebnis hängt dabei nicht nur
von der Geschwindigkeit ab, mit der das Repräsentations-Modul die gesuchten Daten findet. Insbesondere bei mobilen Clients spielt die Menge der übertragenen Daten auch eine Rolle. Die Schnittstelle des Repräsentations-Moduls zum Client sollte daher so gestaltet werden, dass
der Client gezielt auf bestimmte Ausschnitte der Repräsentation zugreifen
kann. Der Client hat dann die Möglichkeit, Daten nur dann anzufordern,
wenn sie vom Benutzer jetzt oder wahrscheinlich in Zukunft benötigt
werden.
5. Sicherheit
a) Sichere Kommunikation
Der Datenaustausch zwischen Client und dem URM der MIDMAYHomebase sowie zwischen Datenquellen und dem DRM soll über einen
sicheren Kommunikationskanal ablaufen
Die Daten, welche der Benutzer über seinen Client anfordert, sollen nicht
von Dritten eingesehen oder verändert werden können. Damit sie nicht
eingesehen werden können, ist ein verschlüsselter Kommunikationskanal
nötig. Um die Verfälschung der Daten durch einen Dritten zu verhindern,
müssen sich Client und MIDMAY-Homebase gegenseitig authentifizieren.
b) Schutz der Repräsentations-Daten
Die Daten der Repräsentation sollen vor unberechtigtem Zugriff und vor
Manipulation geschützt sein
Die Repräsentations-Daten müssen so abgespeichert werden, dass sie
nur über die Schnittstellen des URM zugänglich sind. Das URM besitzt
Schnittstellen in zwei Richtungen: Einmal zum Client hin, für den Zugriff
durch den Benutzer, und zum anderen für weitere MIDMAY SoftwareModule, die Informationen der Repräsentation erstellen oder nutzen. Weiterhin muss durch Authentifizierung- und Autorisierungsmechanismen sichergestellt werden, dass über diese Schnittstellen keine unberechtigten
Benutzer bzw. Software-Module auf die Repräsentation zugreifen.
c) Schutz der Zugangsdaten
Schutz der Zugangsdaten des Benutzers vor unberechtigtem Zugriff
Um die Informationen der verteilten Datenquellen abzurufen und sie in
die Repräsentation abzubilden zu können, werden die Zugangsdaten der
Datenquellen benötigt. Die Repräsentation muss regelmäßig und automatisch aktualisiert werden um immer den aktuellen Stand zu repräsentieren
10
2 PROBLEMANALYSE
(Anforderung 4a). Deshalb müssen die Zugangsdaten der Datenquellen
auf der MIDMAY-Homebase hinterlegt sein. Weil diese Daten den Zugriff auf beliebige Informationen des Benutzers ermöglichen, müssen sie
vor unberechtigtem Zugriff geschützt werden. Nur MIDMAY SoftwareModule sollen auf die Zugangsdaten zugreifen dürfen, und die Zugangsdaten dürfen die MIDMAY-Homebase ausschließlich zum Zweck der Anmeldung bei einer Datenquelle verlassen.
2.3. Aktuelle Ansätze
Um eine mobile Informationsverteilung und -verwaltung zu realisieren, benötigt
MIDMAY Funktionen, die teilweise auch von anderen Software-Produkten angeboten werden. Insbesondere die Funktionen über verschiedene Datenquellen hinweg
Informationen zu indizieren und einheitlich zu repräsentieren (Anforderungen 1a,
1b und 1c), werden in vielen Informationssystemen benötigt. In diesem Abschnitt
werden drei verschiedene Ansätze zur Erfassung und Bereitstellung von Informationen vorgestellt. Zu den betrachteten Ansätzen gehören Suchmaschinen, Systeme
zur Verwaltung von Informationen (Content Management Systeme) und System zur
Verwaltung von Wissen“ (Knowledge Management Systeme). Suchmaschinen sind
”
darauf spezialisiert Informationen innerhalb großer Datenmengen zu finden. Content
Management Systeme verwalten Informationen, indem sie Funktionen zur Erfassung, Überarbeitung und Veröffentlichung der Informationen bieten. In Knowledge
Management Systemen wird das Wissen eines Unternehmens erfasst und verwaltet. Im Folgenden wird untersucht, welche Funktionen und Vorgehensweisen dieser
drei Ansätze sich auch in MIDMAY wiederfinden und wo sich MIDMAY von den
existierenden Software-Produkten unterscheidet.
2.3.1. Suchmaschinen
Suchmaschinen werden zur Suche nach Informationen in großen Datenmengen verwendet. Suchmaschinen müssen dazu die vorliegenden Informationen indexieren. Sie
bauen eine Datenstruktur auf, die dabei hilft den Ort einer Ressource anhand der
Eigenschaften einer Information zu bestimmen. Bei den Informationen kann es sich
um strukturierte Informationen handeln, beispielsweise um Produktinformationen
in einer Datenbank oder in einem XML-Format, oder um unstrukturierte, meist
verteilt gespeicherte Informationen, wie z. B. Webseiten und Dateien im Internet.
Auch in MIDMAY soll für die Suche in unstrukturierten verteilten Informationen
die MIDMAY-Repräsentation als Index erstellt werden. Mit Hilfe der Repräsentation soll jedoch auch visualisiert werden können, welche Informationen vorhanden
sind und wie diese durch ihre Eigenschaften zusammenhängen. Eine Suchmaschine
11
2 PROBLEMANALYSE
liefert auf eine Suchanfrage nur eine Liste mit passenden, nach Relevanz geordneten Informationen zurück, so dass keine Visualisierung von Zusammenhängen und
Navigation in den Informationen möglich ist.
So genannte Desktop-Suchmaschinen“ kommen dem MIDMAY Ziel den Benutzer
”
beim Auffinden persönlicher Informationen zu unterstützen am nächsten. Bei diesen
Suchmaschinen werden die Dateien eines PC indiziert, so dass sich der PC auf gleiche Weise durchsuchen lässt wie das Internet mit einer Internet-Suchmaschine. Die
Google Desktop Search Software1 indiziert beispielsweise die gängigsten Dateiformate und auch E-Mails. Allerdings findet die Suche nur lokal auf dem Dateisystem
statt. Andere Datenquellen könnten aber durch Plugins integriert werden. Es existiert bereits ein Plugin2 für die Integration entfernter Dateisysteme und eines, das
den entfernten Zugriff auf die lokale Desktop-Suchmaschine ermöglicht.
2.3.2. Verwaltungs-Systeme (Content Management)
Systeme zur Verwaltung von Informationen werden auch als Content Management
Systeme (CMS) bezeichnet. Unter dem Begriff Content werden inhaltlichen Informationen jeglicher Art, z. B. strukturierte Datensätze, Textdokumente oder Bilder
verstanden. Content setzt sich aus dem Inhalt und zugehörigen Meta-Informationen
zusammen. Die Meta-Informationen sind nicht unbedingt für den Nutzer sichtbar,
sondern können auch nur zur Verwaltung und Kontrolle des eigentlichen Inhalts
dienen. Die Funktionen eines Content Management Systems sind nicht einheitlich
definiert, sie sind vom Einsatzbereich des Systems abhängig. Im Internet können
z. B. Web Content Management Systeme (WCMS) eingesetzt werden, um die Inhalte von Webseiten zu erstellen und zu verwalten. Zur Speicherung der Inhalte kommt
meistens eine Datenbank zum Einsatz.
Im Unterschied zu MIDMAY wird durch ein Content Management System keine
Repräsentation verteilter Informationen erstellt, sondern Informationen werden in
das CMS übertragen und dort gespeichert. Das CMS hat so die Kontrolle über
die Informationen und kann Funktionen wie Versionierung, Suche, Verteilung und
Aufbereitung der Inhalte anbieten. Der Nachteil ist, dass Informationen zur Bearbeitung aus dem CMS geholt und nach der Bearbeitung wieder in das System
übertragen werden müssen. In MIDMAY ist es nicht nötig Informationen von ihrer
eigentlichen Datenquelle auf einen Server zu übertragen, um sie für eine Suche oder
Verteilung verfügbar zu machen. Statt der eigentlichen Inhalte werden nur die MetaInformationen erfasst, auf die MIDMAY Homebase übertragen und dort verwaltet.
1
2
Google Desktop Search: http://desktop.google.de/
Google Desktop Search Plugins: http://desktop.google.de/plugins.html
12
3 FORMATE ZUR REPRÄSENTATION VON WISSEN
2.3.3. Knowledge Management Systeme
Mit einem Knowledge Management System (KMS) soll das gesamte in einer Organisation verankerte Wissen erfasst, verwaltet und verfügbar gemacht werden. Knowledge Management Systeme und MIDMAY haben als gemeinsames Ziel, verteilte
Informationen verfügbar zu machen. Dafür ist die Integration verschiedener existierender Datenquellen in das System notwendig. Es ist aber auch möglich, dass
externe globale Ressourcen (das Internet) oder menschliche Ressourcen (Kollegen,
Berater) über ein KMS befragt werden können, wie es in [25] beschrieben wird. Wissensmanagement mit einem KMS geht jedoch über die Versorgung der Benutzer mit
Informationen hinaus. Ein KMS muss den Benutzern auch die Möglichkeit geben,
ihre Informationen und ihr Wissen in das System einzugeben oder bestehende Informationen zu bearbeiten. Daten, Informationen, Prozesse und Fähigkeiten innerhalb
einer Organisation sollen so explizit gemacht und im KMS gespeichert werden. Der
Fokus in MIDMAY liegt auf der Strukturierung von Informationen, die außerhalb
von MIDMAY erstellt und bearbeitet werden. Das Wissen darüber, wo Informationen abgelegt sind und wie sie in Beziehung zueinander stehen, soll explizit gemacht
werden.
3. Formate zur Repräsentation von Wissen
Eine Wissensrepräsentation ist ein Platzhalter für reale Objekte, Eigenschaften oder
Ereignisse. Sie bildet die Grundlage zur intelligenten Herleitung von weiterem Wissen und dient als Medium zur Kommunikation über Wissen [3]. In der natürlichen
Sprache wird Wissen informal repräsentiert, für die maschinelle Verarbeitung ist dagegen eine formale Darstellung notwendig. In diesem Abschnitt soll untersucht werden, welches Format sich zur Repräsentation des Wissens über Inhalte und Strukturen von Datenquellen eignet. Ein solches Format muss einzelne Dateneinheiten
der Datenquellen und ihre Eigenschaften und Beziehungen untereinander darstellen
können. Die Dateneinheiten können unterschiedliche Informationsobjekte wie z. B.
Dateien und Ordner eines Dateisystems, aber auch Termine einer Terminverwaltung
sein.
Die meisten Menschen werden ein gemeinsames Verständnis davon haben was ein
Termin“ ist und vielleicht auch unter dem Begriff Datei“ dasselbe verstehen. Ein
”
”
Format zur formalen Wissensrepräsentation muss sich jedoch auf Ontologien stützen,
damit eine Eindeutigkeit der verwendeten Symbole und Begriffe und so eine Wiederverwendung und Interoperabilität des repräsentierten Wissens möglich ist. Eine
Ontologie ist die explizite Spezifikation einer vereinfachten Sicht auf einen Ausschnitt
der Welt (Konzeptualisierung) [9]. Mit ihr wird formal festgelegt, welche abstrakten
und konkreten Objekte, Konzepte und Relationen im repräsentierten Weltausschnitt
13
existieren. Einzelne Objekte einer Wissensrepräsentation können dann mit dem festgelegten Vokabular der Ontologie beschreiben werden.
Ein Format zur Wissensrepräsentation sollte sich jedoch nicht nur prinzipiell zur
Erfassung und Verarbeitung des beabsichtigten Wissensbereichs eignen, sondern es
sollten auch Werkzeuge für das Format verfügbar sein. Aus diesem Grund werden
hier die beiden standardisierten Formate Topic Maps und RDF betrachtet, für die
bereits verschiedene Verarbeitung-Werkzeuge existieren. Die Grundlagen dieser Formate werden erläutert, sowie Ziele und Einsatzgebiete untersucht.
3.1. Topic Maps
Topic Maps ermöglichen die Beschreibung von Wissensstrukturen und die Verknüpfung dieser Wissensstrukturen mit existierenden Informationsressourcen [21].
Eine Topic Map bildet eine strukturierte Informationsschicht über diesen Informationsressourcen, die dadurch mit weiteren Informationen angereichert werden können.
Topic Maps als Format zur Beschreibung und zum Austausch von Wissensstrukturen wurden im ISO Standard 13250 [11] auf Basis von SGML standardisiert. Später
wurde die XML Topic Map Syntax XTM [27] in den ISO Standard mit aufgenommen. Zwischen dem Austauschformat der ursprünglichen ISO Spezifikation und der
XTM Syntax von Topic Maps gibt es leichte Unterschiede, so dass noch nicht geklärt
ist, wie sich die beiden Formate aufeinander abbilden lassen [12]. Zur Zeit wird an
einem formalen Topic Map Daten-Modell gearbeitet, welches als Referenz-Modell
zur Einbindung verschiedener Syntax-Definitionen dienen soll [13].
Gegenwärtig ist die XTM Spezifikation [27] der aktuellste gültige Standard und
durch die Verwendung von XML als Austauschformat auch einfacher anzuwenden.
Deshalb bezieht sich die folgende Beschreibung der Topic-Map-Konzepte, soweit
nicht anders angegeben, auf diese Spezifikation.
In den nächsten Abschnitten werden die wesentlichen Bestandteile einer Topic Map
beschrieben: Topics (Themen), Occurrences (Vorkommensangaben) und Associations (Assoziationen). Als weitere wichtige Konzepte werden Subject Identity und
Scope vorgestellt. Um Topic Map Bestandteile und Strukturen zu veranschaulichen,
wird auf eine in [1] beschriebene UML basierte Notation für Topic Maps zurückgegriffen.
3.1.1. Topics
In einer Topic Map wird jedes Ding, ob Objekt, Begriff oder Idee, als Topic repräsentiert. Im Topic-Map-Standard werden die Dinge der realen Welt, für die ein Topic
steht, Subjects genannt. Topics (als Repräsentanten) und Subjects (als repräsentierte
14
Objekte) sollten möglichst in einer Eins-zu-Eins Beziehung stehen, um Redundanzen
und Widersprüche in der Repräsentation zu vermeiden.
Ein Topic wird durch drei Eigenschaften charakterisiert: Namen, Occurrences (Vorkommensangaben) und Rollen in den Assoziationen. Als Namen kann ein Topic
verschiedene Basenames und Variantnames besitzen (siehe Abbildung 3). Ein Basename ist ein Name in Form einer Zeichenkette, während ein Variantname eine
Ressource referenziert und deshalb eine beliebige andere Form haben kann. Ein Variantname gibt eine alternative Form des Basename an, und legt mit einem oder
mehreren Topics als Parameter den Verarbeitungskontext fest, in dem der Variantname verwendet werden soll. Als Parameter für das Anzeigen bzw. Sortieren eines
Topics sind bereits die Topics Display und Sort definiert.
«Topic»
1
1
*
«Base Name»
Base Name String
*
«Variant»
Variant Name
1
*
«Occurence»
1 *
«Parameter»
Abbildung 3: Zusammenhang zwischen Topic, Basename, Variantname und Occurrence
Die beiden Topic-Eigenschaften Ocurrences und Rollen werden in den nächsten zwei
Abschnitten erläutert.
3.1.2. Occurrences
Durch Vorkommensangaben werden Topics mit Ressourcen verbunden, die relevante
Informationen zu diesem Topic enthalten. Dies sind z. B. nähere Beschreibungen,
Dokumente oder Bilder, die etwas über das Subject aussagen, welches das Topic
repräsentiert. Die Ressourcen müssen nicht in der Topic-Map selbst vorhanden sein,
sondern es können unterschiedliche externe Quellen referenziert werden. In XTM
wird eine Vorkommensangabe durch einen URI referenziert. Die Topic-Map bildet
durch diese Möglichkeit der Referenzierung eine strukturierte Informationsschicht
über den unzusammenhängenden referenzierten Ressourcen.
3.1.3. Associations
Eine Beziehung zwischen zwei oder mehreren Topics wird durch eine Assoziation
beschrieben. Eine Assoziation ist eine ungerichtete Relation auf den Topics. In der
15
Assoziation werden die teilnehmenden Topics definiert und die jeweilige Rolle, die
sie in der Assoziation spielen. Im Standard bereits definiert sind die superclasssubclass und die class-instance Assoziation mit zugehörigen Rollen. Die superclasssubclass Assoziation kann verwendet werden um Klassenhierarchien zu definieren.
Abbildung 4 zeigt auf der linken Seite ein Beispiel einer solchen Assoziation und
auf der rechten Seite die Darstellung des gleichen Sachverhalts in UML. Das Topic
Adresse“ nimmt hier in der Rolle superclass in der Beziehung teil, das Topic E”
”
Mail Adresse“ in der Rolle subclass. Durch die Assoziation wird beschrieben, dass
Adresse“ eine Generalisierung des Topics E-Mail Adresse“ ist, bzw. dass E-Mail
”
”
”
Adresse“ eine Spezialisierung des Topics Adresse“ ist.
”
Adresse
supeclass-subclass
Adresse
superclass
subclass
E-Mail Adresse
E-Mail Adresse
Abbildung 4: Eine superclass-subclass Assoziation (links) und die entsprechende
UML Beschreibung (rechts)
Die class-instance Assoziation wird verwendet um Topics als Instanzen anderer Topics zu deklarieren. Abbildung 5 zeigt eine class-instance Assoziation die beschreibt,
dass alice@xyz.com“ eine Instanz des Topics E-Mail Adresse“ ist.
”
”
E-Mail Adresse
class-instance
E-Mail Adresse
class
«instanceOf»
instance
alice@xyz.com
alice@xyz.com
Abbildung 5: Eine class-instance Assoziation (links) und die Beschreibung in UML
(rechts)
Rollen wie class, instance, superclass und subclass sind selbst Topics der Topic Map.
Jedes Topic kann als Rolle für Topics in Assoziationen oder als Typ für andere
Topics oder Assoziationen verwendet werden. Durch dieses Konzept können Topicund Assoziationstypen und deren Bedeutung frei definiert werden.
Die Topic-Map-Spezifikation lässt allerdings offen, wie Assoziations-Eigenschaften
oder Bedingungen für Assoziationen definiert werden. Die Eigenschaften einer Assoziationen wie Transitivität, Reflexivität oder Symmetrie ermöglichen zusammen
16
mit Inferenzregeln das automatische Herleiten von weiterem impliziten Wissen aus
einer Topic Map oder auch eine Konsistenzprüfung der repräsentierten Aussagen.
Bedingungen für Assoziationen, z. B. wieviele Topics in welchen Rollen teilnehmen
dürfen, ermöglichen die Validation einer Topic Map gegen die festgelegten Bedingungen. Auch wenn die notwendigen Konzepte für Inferenz, Konsistenzprüfung oder
Validation der Inhalte einer Topic Map nicht von vornherein im Standard spezifiziert
sind, bieten Topic Maps die Möglichkeit diese Konzepte selbst als Topics innerhalb
einer Topic Map zu definieren und für die entsprechenden Zwecke anzuwenden [24].
3.1.4. Scope
Aussagen über ein Topic werden durch die bereits beschriebenen Topic-Eigenschaften (Namen, Vorkommensangaben und Rollen in Assoziationen) gemacht. Diese Aussagen müssen jedoch nicht universell gültig sein, sondern können mit der Angabe
eines Scope auf einen bestimmten Gültigkeitsbereich beschränkt werden. So kann
z. B. angegeben werden, dass ein Topic-Name nur im Kontext einer bestimmten
Sprache gültig ist oder eine Assoziation nur eine einzelne Meinung repräsentiert, die
nicht von allen geteilt wird. Der Scope (Gültigkeitsbereich) einer Topic-Eigenschaft
kann durch die Angabe einer Menge von Scoping-Topics festgelegt werden. Die Vereinigung dieser Topics bestimmt den Kontext, in dem die Topic-Eigenschaften gültig
ist. Ohne diese Angabe liegt eine Topic-Eigenschaft im Unconstrained Scope und ist
damit immer gültig. Es gibt jedoch keine weiteren Vorgaben, wie die Scope-Angabe
bei der Verarbeitung einer Topic Map verwendet werden soll. Insbesondere für die
Herleitung der Gültigkeit einer Topic-Eigenschaft bei gegebenem Kontext gibt es
verschiedene Möglichkeiten, die in [23] betrachtet werden.
Bei Topic-Basenames legt ein angegebener Scope nicht nur den Gültigkeitsbereich
des Namens fest, sondern definiert auch einen Namensraum. Es gilt das so genannte Topic Naming Constraint: Es darf keine zwei Topics in einer Topic Map geben,
die den selben Basename im selben Scope besitzen. Falls das doch der Fall ist,
repräsentieren die beiden Topics das selbe Subject und müssen zu einem Topic vereinigt werden. Das resultierende Topic besitzt die Eigenschaften beider Topics, also
alle Namen, Vorkommensangaben und Rollen in Assoziationen, welche die beiden
Topics charakterisieren.
Unter Topic Map Experten ist jedoch umstritten, ob das Topic Naming Constraint
sinnvoll ist [5], da es in jedem Fall Scope-Angaben für Topics erzwingt, um Namen eindeutig zu halten. In der realen Welt sind eindeutige Namen jedoch eher
die Ausnahme3 . Im neusten Topic Map Draft des ISO Komitees [13] wird deswegen
3
Um z. B. ein Telefonbuch zu repräsentieren, könnten die eingetragenen Personen durch eine Assoziation mit ihrer Telefonnummer verknüpft werden. Die Namen in einem Telefonbuch sind
aber nicht eindeutig und die Telefonnummer müsste deshalb im Scope für den Namen einer Per-
17
die Eindeutigkeit der Namen nicht mehr vorgeschrieben. Stattdessen werden NameTypen eingeführt, mit denen unter anderem auch die Eindeutigkeit eines Basename
auf Wunsch definiert werden kann.
3.1.5. Subject Identity
Topics sind Stellvertreter für Dinge innerhalb und außerhalb der Topic Map. Deshalb
können in unterschiedlichen Topic Maps verschiedene Topics das gleiche Subject der
realen Welt repräsentieren. Wenn das Wissen zweier Topic-Maps vereinigt werden
soll, ist es sinnvoll für jedes Topic wieder eine Eins-zu-Eins Beziehung zwischen Topic
und Subject herzustellen, um einen einzigen Zugriffspunkt auf das Wissen über ein
Subject zu haben.
Das Konzept der Subject Identity ermöglicht es festzustellen, ob zwei Topics das selbe
Subject repräsentieren. Wenn das der Fall ist, können die Eigenschaften der beiden
Topics vereinigt werden. Die Identität eines Subjects kann auf zwei verschiedene Arten definiert werden. Wenn eine elektronische Ressource repräsentiert werden soll,
kann einfach deren URL als Subject Address verwendet werden. Topics, welche die
gleiche Subject Address besitzen, repräsentieren das selbe Subject. Für andere Objekte oder gedachte Begriffe ist es jedoch notwendig eine URI-Adresse zur indirekten
Identifikation des Subjects zu definieren. Eine solche Adresse wird als Subject Identifier bezeichnet, die Informationsressource auf die sie zeigt als Subject Indicator. Die
Subject Identifier Adresse wird vom Computer fast auf die gleiche Weise verwendet wie die Subject Address eines direkt adressierbaren Subjects. Haben zwei Topics
einen Subject Identifier gemeinsam, repräsentieren sie das selbe Subject. Der Subject
Indicator wird nicht vom Computer verwendet, sondern vom Menschen. Die Informationsressource weist Menschen darauf hin (engl.: to indicate) um welches Subject
es sich handelt. Werden Subject Identifiers und Subject Indicators explizit für die
Identifikation von Subjects definiert und erstellt, wird von Published Subject Identifiers (PSIDs) und Published Subject Indicators (PSIs) gesprochen. Die Definition
von PSIDs und PSIs geschieht nicht zentral, sondern als offener verteilter Prozess.
Jeder kann PSIs verwenden oder eigene definieren, wobei er sich an Empfehlungen
des OASIS Published Subjects Komitees zur Erstellung von PSIs [19] orientieren
kann.
3.2. RDF
Das Ressource Description Framework (RDF) wurde entwickelt, um der Vision des
Semantic Web [2] näher zu kommen, indem es die Strukturierung und Beschreison benutzt werden. Dann enthält die Topic Map aber redundante Information, die konsistent
gehalten werden muss.
18
bung von Ressourcen im World Wide Web ermöglicht. Es können verschiedene Vokabularien für die Beschreibung von Ressourcen bestimmter Anwendungsdomänen
definiert werden. Mit RDF und darauf aufbauenden Ontologiesprachen wie OWL
kann der Kontext von Ressourcen explizit beschrieben werden, so dass sie durch
den Computer besser interpretiert werden können. Zur RDF-Spezifikation gehört
ein Datenmodell mit einer XML-Syntax [30] sowie eine Syntax zur Definition von
Vokabularien (RDFS [29]).
3.2.1. RDF Konzepte
Das RDF Datenmodell besteht aus den Kernkonzepten Ressource, Property und
Statement. Jedes Ding, das beschrieben werden kann, wird in der RDF-Spezifikation
als Ressource bezeichnet. Im Topic-Map-Standard wird statt Ressource“ der Begriff
”
Subject“ verwendet. Die beschriebenen Dinge werden in RDF, durch einen RDF”
Knoten (Node) repräsentiert und durch einen URI identifiziert. Um die Eigenschaft
einer Ressource zu beschreiben, werden so genannte RDF-Properties als Prädikate
auf der Ressource benutzt. Mit einer RDF-Property kann eine gerichtete Eigenschaftsbeziehung zwischen zwei Ressourcen, dem Subjekt und dem Objekt hergestellt werden. Das Tripel aus Subjekt, Prädikat und Objekt wird als RDF-Statement
(Aussage) bezeichnet. Abbildung 6 zeigt ein RDF-Statement in GraphensyntaxNotation.
Subject
http://articles/xyz.html
Prädikat
authoredBy
Objekt
http://alice.net
Abbildung 6: Beispiel für ein RDF-Statement
Ebenso wie in Topic Maps ist es möglich Aussagen über Aussagen zu machen. Dazu
wird ein RDF-Statement wieder als Ressource betrachtet werden und kann so in
einem weiteren RDF-Statement verwendet werden.
3.2.2. RDF-Schema
Ein RDF-Schema (RDFS) enthält Aussagen, um die Konzepte einer bestimmten Anwendungsdomäne zu definieren. Dazu werden unter anderem RDF-Klassen verwendet. Als RDF-Klassen werden die Ressourcen innerhalb eines Schemas bezeichnet,
19
von denen in einer RDF-Beschreibung Instanzen gebildet werden können. Sie dienen also der Typisierung von RDF-Ressourcen. Außerdem kann für eine RDF-Klasse
festgelegt werden, welche Arten von Eigenschaften die Instanz dieser Klasse besitzen
kann. Weiterhin können Klassen- und Eigenschaftshierarchien definiert werden, um
Spezialisierungsbeziehungen zu modellieren.
RDF-Schemata können erweitert und miteinander kombiniert werden. Durch die
Verwendung bereits vorhandener RDF-Schemata soll die Interoperabilität von RDFRessourcenbeschreibungen im Web verbessert werden. Eine RDF-Beschreibung kann
unterschiedliche RDF-Schemata nebeneinander verwenden. Wenn ein RDF-Schema
verwendet werden soll, wird es durch eine URI referenziert. Die XML-Syntax von
RDF erlaubt es, den Namen einer RDF-Klasse im XML-Tag zu verwenden, um eine
Instanz dieser Klasse zu erzeugen (Abbildung 7 zeigt das Statement aus Abbildung 6
in XML-Syntax). Dadurch ist die Menge der XML-Tags für die XML-Syntax von
RDF nicht festgelegt, wie es bei der XML-Syntax von Topic Maps der Fall ist.
Abbildung 7: RDF Statement in XML Syntax
3.2.3. Web Ontology Language (OWL)
Die Web Ontology Language (OWL) ist eine formale Beschreibungssprache für Ontologien, die auf RDF-Konzepten aufbaut. Zusätzlich definierte Sprachkonstrukte
erlauben es, Ausdrücke ähnlich der Prädikatenlogik zu formulieren. OWL soll als
Nachfolger der Ontologiesprache DAML+OIL für die Verwirklichung des Seman”
tic Web“ eingesetzt werden, und wird gegenwärtig vom W3C standardisiert [28]. In
OWL wird zwischen Klassen und Individuen als Instanzen der Klassen unterschieden. Individuen werden durch Eigenschaften beschrieben, wobei entweder XMLSchema-Datentypen oder andere Individuen als Eigenschaftswerte verwendet werden können. Für Klassen können verschiedene Eigenschaftsbeschränkungen festgelegt werden, die ihre Instanzen erfüllen müssen.
OWL existiert in drei unterschiedlichen Varianten, OWL Lite, OWL DL und OWL
Full, die sich durch ihre Ausdrucksmächtigkeit unterscheiden. OWL Lite ist die
einfachste Variante, mit der die Hauptkomponenten einer Ontologie, Hierarchien zur
20
Klassifizierung von Individuen, beschrieben werden können. OWL DL4 soll möglichst
umfangreiche Beschreibungsmöglichkeiten bieten, wobei die Entscheidbarkeit jeder
Aussage jedoch garantiert bleiben soll. In OWL DL gibt es als Ergänzung zu den
hierarchischen Beziehungen zwischen Klassen weitere Typen von Beziehungen, mit
denen z. B. ausgedrückt werden kann, dass zwei Klassen disjunkt oder äquivalent
sind. OWL Full bietet die größte Ausdrucksstärke und kann mit den Möglichkeiten,
die RDF und RDFS bieten, um eigene Konzepte zur Beschreibung von Ontologien
erweitert werden.
3.3. Vergleich
RDF und Topic Maps haben viele Gemeinsamkeiten. Beides sind Technologien, die
eine formale Beschreibung verschiedener Dinge, Ressourcen, Konzepte oder Aussagen ermöglichen. Die Entwicklung der beiden Technologien wurde jedoch von unterschiedlichen Zielen geleitet, so dass beide verschiedene Schwerpunkte für ihren
Einsatz haben. In diesem Abschnitt werden die Unterschiede der Technologien betrachtet, um abschließend bewerten zu können, zu welchen Vor- und Nachteilen ein
Einsatz von Topic Maps in MIDMAY führt.
3.3.1. Ziele der Technologien
Dass die beiden ähnlichen Technologien RDF und Topic Maps nebeneinander existieren, ist vor allem historisch bedingt. Zwei verschiedene Arbeitsgruppen haben
unabhängig, ohne voneinander zu wissen, begonnen ihre“ Technologie für einen be”
stimmten Zweck zu entwickeln [7]. Topic Maps sind als Format für die Indizierung
von Informationsressourcen entwickelt, und von der ISO standardisiert worden. Das
Hauptziel bestand darin, ein Austauschformat für Indizes zu schaffen, dessen Datenmodell eine Navigation“ durch die Informationen ermöglicht und die Vereinigung
”
verschiedener Indizes unterstützt [5]. RDF wurde vom W3C zur Unterstützung des
Semantic Web“ entwickelt. Das Semantic Web“ ist eine Erweiterung des herkömm”
”
lichen Webs, in der Informationen mit eindeutigen Bedeutungen versehen werden, so
dass Computer und Menschen besser zusammenarbeiten können. [2]. Ziel von RDF
ist es, ein Datenmodell für die Beschreibung von Ressourcen im World Wide Web
(WWW) anzubieten. Mit diesem Datenmodell können Ressourcen durch strukturierte Metadaten beschrieben werden, die als Grundlage für Interferenz-Mechanismen
dienen. Suchmaschinen oder Software-Agenten haben durch die eindeutige Beschreibung bessere Möglichkeiten, für den Menschen relevante Informationen zu finden.
4
DL steht für Description Logics
21
Abbildung 8: Einordnung der Topic-Maps- und RDF-Standards (nach [7])
3.3.2. Einordnung der Standards von Topic Maps und RDF
Um Topic Maps und RDF vergleichen zu können, muss berücksichtigt werden, aus
welchen verschiedenen Standards die beiden Technologien bestehen. Zum einen gibt
es die mit den Begriffen Topic Maps“ und RDF“ bezeichneten Datenmodelle. Die
”
”
Datenmodelle allein ermöglichen jedoch noch keinen Austausch von Informationen,
hierfür sind Syntax-Definitionen notwendig. Mit Constraint-Languages können die
Datenmodelle für eigene Zwecke und verschiedene Einsatzbereiche angepasst werden. Abbildung 8 zeigt, welche Topic Map- und RDF-Standards auf welcher Ebene
einzuordnen sind.
Den Datenmodellen gemeinsam ist das Konzept, Symbole“ für identifizierbare
”
Dinge“ zu benutzen, um Aussagen über diese Dinge machen zu können. Die Din”
”
ge“ werden in den Standards unterschiedlich bezeichnet. Im Topic-Map-Standard
wird von Subjects gesprochen, in RDF von Ressourcen. Der Begriff Ressource bezeichnet in RDF nicht nur elektronische Ressourcen wie Dokumente, Audio- oder
Video-Dateien, sondern beliebige Dinge, ebenso wie der Begriff Subjects in Topic
Maps5 . Die benutzten Symbole werden in RDF Knoten“ (Nodes) und in Topic
”
Maps Topics“ genannt.
”
3.3.3. Identität
Identität“ ist die Summe aller Merkmale eines Objekts und ermöglicht die Ent”
scheidung, ob zwei Objekte identisch sind oder nicht. Sind zwei Objekte identisch,
besitzen sie die selben Merkmale (Leibnizsches Gesetz). Damit Aussagen in RDF
und Topic Maps immer eindeutig bleiben, müssen die in den Aussagen verwendeten Symbole eindeutig einem Objekt zugeordnet werden können. Es können durchaus mehrere Symbole für identische Objekte verwendet werden, so wie sprachlich
5
Im RDF-Standard [30] ist der Begriff Ressource definiert als alles was Identität besitzt“
”
22
unterschiedliche Begriffe für identische Dinge oder den selben Sachverhalt verwendet werden. Wenn in einem Gespräch zum Beispiel das Wort Blatt“ als Symbol
”
verwendet wird, kann ein Mensch normalerweise anhand des Gesprächskontexts
das gemeinte Objekt identifizieren. Steht der Begriff jedoch wie hier für sich alleine, kann nicht entschieden werden ob ein Papierblatt zum Beschreiben“ oder
”
ein Blatt einer Pflanze“ gemeint ist. In formalen Repräsentationen muss deshalb
”
jedes Symbol nur für ein einziges Objekt verwendet werden. Dazu wird für jedes
repräsentierte Objekt ein eindeutiges Merkmal benötigt. Sowohl in RDF als auch
Topic Maps werden als eindeutiges Merkmal URIs verwendet. Für elektronische Ressourcen können die URIs verwendet werden, an denen sie gespeichert sind. Für die
nicht-elektronischen Ressourcen müssen URIs definiert werden. Ein und die selbe
URI kann so aber auf zwei unterschiedliche Arten zur Identifikation verwendet werden: Einmal direkt um eine elektronische Ressource zu identifizieren, oder indirekt
um eine nicht-elektronische Ressource zu identifizieren [22]. In RDF gibt es keine
Möglichkeit zwischen diesen beiden Verwendungen zu unterscheiden. Wird beispielsweise die URL http://www.topicmaps.org als URI für die Identifikation benutzt,
könnte damit die Webseite der TopicMaps.org Arbeitsgruppe oder die Arbeitsgruppe selbst gemeint sein. In Topic Maps kann diese URL dagegen problemlos auf beide
Arten verwendet werden. Wird sie einem Topic als Subject Address mit dem RessourceRef -Element zugeordnet, wird durch dieses Topic die Webseite repräsentiert.
Mit dem subjectIndicatorRef -Element wird die URL statt dessen als Subject Identifier zur indirekten Identifikation genutzt, um etwas anderes als die elektronische
Ressource zu identifizieren6 .
3.3.4. Aussagen
Aussagen über repräsentierte Objekte
In beiden Datenmodellen können Aussagen über die repräsentierten Objekte gemacht werden. In RDF wird eine Aussage durch ein RDF-Statement realisiert. Dabei wird einer RDF-Ressource (Subject) durch eine RDF-Property mit einer zweiten
RDF-Ressource (Object) verbunden. Die Verbindung ist gerichtet (das Subject hat
eine Eigenschaft mit dem Wert Object) und hat einen definierten Typ (die verwendete RDF-Property). Verbindungen zwischen mehreren Objekten (so genannte n-äre
Relationen) müssen unter Verwendung von mehreren binären RDF-Property Relationen modelliert werden. In UML lässt sich ein RDF-Statement durch eine binäre
unidirektionale Assoziation beschreiben. Abbildung 9 zeigt in der unteren Hälfte die
UML-Darstellung des RDF-Statements Faust“ wurde von Goethe“ geschrieben.
”
”
In der oberen Hälfte der Abbildung werden für die Typisierung der teilnehmenden
6
Im genannten Beispiel ist dies sehr wahrscheinlich die Arbeitsgruppe TopicMaps.org. Welches
Ding durch eine Subject Identifier -URI identifiziert wird, sollte in weniger eindeutigen Fällen
öffentlich zugänglich als Published Subject Indicator definiert werden (siehe Abschnitt 3.1.5)
23
writtenBy
rdf:domain
rdf:range
Drama
Person
rdf:type
rdf:type
Faust
writtenBy
Goethe
Abbildung 9: RDF-Aussage in UML-Darstellung
Objekte Faust“ und Goethe“ und zur Definition der RDF-Property writtenBy“
”
”
”
weitere RDF-Statements verwendet.
In Topic Maps gibt es verschiedene Möglichkeiten Aussagen zu machen. Die einfachste besteht darin, dass einem repräsentierten Objekt eine Zeichenkette als Name
zugeordnet wird. Als weitere Möglichkeit können Occurrences für Aussagen verwendet werden. Occurrences sind von der Struktur her genauso aufgebaut wie RDFAussagen mit RDF-Properties, sie werden jedoch nicht wie diese für alle Arten von
Aussagen verwendet (siehe Abschnitt 3.1.2 zur Verwendung von Occurrences). Um
Aussagen mit selbst definierter Semantik zu bilden, bieten Associations vielfältige
Möglichkeiten. Sie beschreiben typisierte Beziehungen zwischen den repräsentierten
Objekten. Im Gegensatz zu den gerichteten Eigenschaftsbeziehungen in RDF sind
Associations ungerichtet. Die teilnehmenden Objekte nehmen an einer Beziehung
in verschiedenen Rollen teil. Dadurch kann eine Beziehung immer von jedem der
teilnehmenden Objekte aus betrachtet werden. Die Association in Topic Maps entspricht in UML-Beschreibung einer zwei- oder höherwertigen Assoziation, die durch
eine Assoziationsklasse beschrieben wird, in jede Richtung navigierbar ist und Rollenbeschreibungen enthält. Assoziationsklassen dienen in UML dazu Eigenschaften
näher zu beschreiben, die keiner der teilnehmenden Klassen der Assoziation zugeordnet werden können [15]. Diese Voraussetzung trifft auf Associations in Topic Maps
zu. Eine Association wird nicht als Eigenschaft der teilnehmenden Topics, sondern
als eigenes Objekt behandelt. In Abbildung 10 ist die Aussage Goethe“ schrieb
”
Faust“ mit den Möglichkeiten des Topic-Maps-Modells in UML dargestellt.
”
Aussagen über Aussagen
In Topic Maps oder RDF können nicht nur Aussagen über Objekte gemacht wer-
24
Drama
Person
«instanceOf»
«instanceOf»
writtenBy
Faust
Goethe
work
author
Abbildung 10: TopicMaps-Aussage durch eine Association in UML-Darstellung
den. Die beiden Datenmodelle ermöglichen es auch, Aussagen über Aussagen zu
machen. Der Prozess eine Aussage als Gegenstand aufzufassen, so dass sie in anderen Aussagen verwendet werden kann, wird Reifikation ( Vergegenständlichung“)
”
genannt. Dazu muss für eine Aussage A, über die etwas ausgesagt werden soll, ein
Symbol erstellt werden. Das erstellte Symbol repräsentiert Aussage A und kann nun
in anderen Aussagen verwendet werden.
Auch wenn das Konzept der Reifikation erst einmal umständlich erscheint, hat es
tatsächlich viele praktische Anwendungen. Etwas über eine Aussage aussagen zu
können, ist immer dann notwendig, wenn die Aussage nur in einem gewissen Kontext
gilt. Wenn repräsentiert werden soll, wer eine Aussage gemacht hat, unter welchen
Umständen (wann oder wo) sie gilt oder wie wahrscheinlich die Richtigkeit einer
Aussage ist, wird Reifikation benötigt.
In Topic Maps können Associations oder Occurrence-Aussagen reifiziert werden.
Dazu wird ein Topic als neues Symbol erstellt. Das Topic erhält einen Subject Identifier, der auf die Association oder Occurrence-Aussage verweist, die reifiziert werden
soll. Ein Vorteil im Topic Maps Datenmodell ist, dass eine Aussage für die Reifikation nicht verändert werden muss. Außerdem können andere Aussagen die reifizierte
Aussage genauso verwenden, als wäre es ein repräsentiertes Objekt (Abbildung 11).
In RDF muss ein existierendes RDF-Statement noch einmal anders repräsentiert
werden, damit es in einer weiteren Aussage verwendet werden kann. Es wird ein neuer
Knoten vom Typ rdf:statement erzeugt. Mit den drei Properties rdf:subject,
rdf:property und rdf:object wird der neue Knoten mit dem Subjekt, Prädikat
und Objekt des ursprünglichen RDF-Statements verbunden (Abbildung 12). Die
so geschaffene Aussage bietet gegenüber dem ursprünglichen RDF-Statement keine
neuen Informationen, ist aber nötig, damit andere Aussagen sich auf sie beziehen
können. Das ursprüngliche Statement kann also entfernt werden. So ergibt sich als
25
knows
Alice
writtenBy
learner
fact
Faust
Goethe
work
author
Abbildung 11: Beispiel für Reifikation in Topic Maps
Nachteil, dass reifizierte Aussagen auf andere Weise repräsentiert werden als nichtreifizierte Aussagen.
In einem Beitrag von Steven R. Newcomb in der OASIS topicmaps-comment“
”
Mailing-Liste [18] wird das Reifikations-Konzept von RDF als late/lazy reificati”
on bezeichnet, weil Aussagen gemacht werden können, ohne dass sie für die Reifi”
kation vorbereitet sind. Dies hat den Vorteil, dass eine Aussage mit einer einzigen
Verbindung zwischen zwei Knoten gemacht werden kann. Um dagegen eine Aussage
in einer Topic Map zu machen, muss eine Association und damit ein eigenes Symbol
für die Aussage geschaffen werden, von der zwei Verbindungen zu den teilnehmenden
Topics gehen. Durch dieses Symbol ist die Aussage für eine mögliche Reifikation aber
schon vorbereitet, was als early/preemptive reification“ bezeichnet werden kann.
”
3.3.5. Constraint Languages
Die Datenmodelle von Topic Maps und RDF sind für viele Anwendungen zu mächtig,
da sie es erlauben beliebige Dinge und Aussagen zu repräsentieren. Mit einer Constraint Language können die Möglichkeiten der Datenmodelle zugunsten erweiterter Verarbeitungsmöglichkeiten von Repräsentationen durch den Computer eingeschränkt werden. Mit der Verwendung von definierten Begriffen kann zum einen die
Erstellung, Verarbeitung und Darstellung von Wissen bestimmter Bereiche besser
unterstützt werden. Zum anderen können formalere Beschreibungen erzwungen werden, so dass z. B. die Überprüfung der Konsistenz des repräsentierten Wissens oder
das Herleiten von weiterem Wissen aus dem Vorhandenen möglich wird.
Mit einer Constraint Language können Einschränkungen und Bedingungen für eine
Repräsentation spezifiziert werden. Eine solche Spezifikation wird auch als Schema“
”
26
rdf:statement
rdf:type
Alice
knows
«empty node»
rdf:subject
rdf:predicate
rdf:object
writtenBy
Faust
Goethe
Abbildung 12: Beispiel für Reifikation in RDF
bezeichnet. Ein Schema dient dazu, Begriffe und Konzepte für ein bestimmtes Wissensgebiet zu definieren, welche als Vokabular“ in verschiedenen Repräsentationen
”
verwendet werden können. Eine Repräsentation, die sich an ein Schema hält, verweist auf dieses Schema (Commitment). Auf diese Weise kann automatisch validiert
werden, ob sie alle Einschränkungen wirklich erfüllt.
In RDF können Schema-Definitionen nach dem RDFS-Standard [29] erstellt werden,
der in Abschnitt 3.2.2 kurz beschrieben wurde. RDF-Schemata ermöglichen die Definition von Konzepten in Klassenhierarchien und RDF-Properties in EigenschaftsHierarchien. Topic Maps besitzen keinen eigenen Standard um solche KonzeptHierarchien oder Assoziationsklassen zu definieren. Statt dessen können diese in der
Topic Map selbst repräsentiert werden, oder auch in externen Topic Map Templa”
te“ genannten Topic Maps. Allerdings lässt sich so nicht überprüfen, ob eine Topic
Map nur die in Templates definierten Topics verwendet.
Weitere Einschränkungen und Bedingungen, die mit einer Constraint Language definiert werden können, betreffen die Eigenschaften der repräsentierten Objekte (z. B.
erlaubte Namen, Eigenschaftswerte, Datentypen) und die Beziehungen, in denen sie
zueinander stehen können (z. B. minimale und maximale Kardinalitäten). Für RDF
bietet die in Abschnitt 3.2.3 beschriebene Ontologiesprache OWL unter anderem diese Möglichkeiten. Für Topic Maps existiert erst ein unvollständiges working draft“
”
für eine eigene Constraint Language [14]. Diese besteht aus zwei Teilen. Der Teil
TMCL-Schema soll die Beschreibung von Bedingungen für Topic- und Assoziations-
27
klassen ermöglichen. Mit dem Teil TMCL-Rule sollen Regeln für eine regelbasierte
Validation von Topic Maps aufgestellt werden können.
3.3.6. Interoperabilität von Repräsentationen
Wissensrepräsentationen über die selben Wissensgebiete entstehen oft unabhängig
durch verschiedene Autoren. Die Repräsentationen können dann vereinigt werden,
wenn alle Autoren das selbe Vokabular für ihre Repräsentation verwenden. Zu diesem
Zweck Vokabularien zu standardisieren ist nicht unbedingt sinnvoll, da ein Standard
nie den Umfang und die Vielschichtigkeit der Realität wiedergeben kann. Satt dessen ist es wichtig Methoden zu entwickeln, welche Definition und die Übersetzung
unterschiedlicher Vokabularien ermöglichen [26].
RDF und Topic Maps unterscheiden sich in ihren Möglichkeiten, Repräsentationen
zu vereinigen, die für die selben Begriffe und Konzepte unterschiedliches Vokabular
verwenden. Ein solcher Fall liegt in RDF vor, wenn zwei RDF-Repräsentationen
jeweils das Vokabular zweier unterschiedlicher RDF-Schemata verwenden. Die Vereinigung dieser Repräsentationen ist in diesem Fall aufwändig. Die beiden Schemata
müssen zueinander in Beziehung gesetzt werden, was z. B. mit der Web Ontology
Language OWL möglich ist. Es muss eine Ontologie erstellt werden, die eine Vereinigung der RDF-Repräsentationen mit Inferenzmechanismen ermöglicht. Das Topic
Map Datenmodell ist von vornherein auf die Vereinigung von Topic Maps ausgelegt.
Um Topics aus zwei unterschiedlichen Topic Maps zu vereinigen, wird das SubjectIdentity-Konzept 3.1.5 verwendet. Sollen zwei Topics vereinigt werden, müssen sie
nur einen Subject-Indicator gemeinsam haben. Welche Topics zweier Topic Maps
gleich sind, kann entweder in einer der beiden Topic Maps oder auch in einer dritten
Topic Map definiert werden7 .
3.3.7. Syntax
Sowohl für RDF als auch für Topic Maps existieren verschiedene Syntax-Formate.
Die standardisierten XML-Formate (XTM für Topic Maps und XML/RDF für
RDF), werden am häufigsten eingesetzt, da es viele Programmbibliotheken und Tools
zur Verarbeitung von XML gibt.
Ein Unterschied in den Anwendungsmöglichkeiten der beiden XML Formate besteht darin, dass die RDF/XML-Syntax in andere XML Dokumente eingebettet
werden kann, XTM jedoch nur eingeschränkt. Die Einbettung von RDF erlaubt es,
in einem XML-Dokument RDF-Syntax an beliebigen Stellen zu benutzen. Damit
7
In einer dritten Topic Map wird für zwei zu vereinigende Topics ein neues Topic mit jeweils einem
Subject-Indicator der beiden anderen Topics erstellt. Anschließend können alle drei Topic Maps
vereinigt werden.
28
können Metadaten zu verschiedenen Abschnitten des XML-Dokuments gespeichert
werden. Eine Topic Map in XTM-Syntax darf dagegen nur am Stück“ in ein ande”
res XML-Dokument eingebettet werden. Hier tritt wieder das Topic-Map-Konzept
der Trennung der Topic Map Ebene von den Ressourcen hervor. Wäre eine Topic
Map über ein anderes Dokument hinweg verteilt, kann sie nicht mehr so verarbeitet
werden wie eine unabhängige Topic Map. Sie kann nicht einfach verändert oder herausgelöst werden, da das XML-Dokument sonst vielleicht für andere Anwendungen
nicht mehr brauchbar ist.
3.3.8. Fazit
In Tabelle 1 werden die wesentlichen Merkmale von Topic Maps und RDF genannt
und die Unterschiede noch einmal verdeutlicht. Da Topic Maps und RDF für unterschiedliche Zwecke entwickelt wurden, sehen die jeweiligen Entwickler der Standards die Technologien nicht in Konkurrenz zueinander. Mit Topic Maps soll sich
der menschliche Benutzer besser in Informationen zurecht finden, RDF wurde entwickelt, damit Programme (Software-Agenten) die Informationen der Menschen verstehen. In MIDMAY steht das Auffinden von Informationen durch den Benutzer im
Vordergrund. Eine Wissensrepräsentation soll dabei helfen, Informationen zu strukturieren und so besser auffinden zu können. Topic Maps sind dafür geeignet, da sie
eine eigene Informations- und Strukturierungsschicht über existierenden Informationsressourcen bilden und diese Ressourcen nicht verändert werden müssen. Mit dem
Identitäts-Konzept von Topic Maps ist die Unterscheidung zwischen elektronischen
und sonstigen Ressourcen möglich. Dadurch können Web-Adressen wie z. B. die
Homepage einer Person zur indirekten und zur direkten Identifizierung verwendet
werden.
Um Aussagen zu machen sind Assoziationen und Rollen in Topic Maps intuitiv
verständlich. Mit Assoziationen kann der Benutzer bestimmte Objekte semantisch
miteinander verbinden. Hier haben Topic Maps den Vorteil, dass neue Topic- und
Assoziations-Typen zu jeder Zeit in der Topic Map selbst erstellt werden können
und nicht in einem externen RDF-Schema definiert werden müssen. Reifikation ist
in Topic Maps ebenfalls einfacher anzuwenden als in RDF, da jede Assoziation allein
durch das Erstellen eines weiteren Topics als eigene Ressource verwendet werden
kann.
Mit dem Merging-Konzept bieten Topic Maps einen definierten automatischen Prozess um verschiedene Topic Maps in einer Topic Map zu vereinigen. So sind Topic
Maps modular verwendbar und machen ein verteiltes oder iteratives Entwickeln von
Wissensrepräsentationen einfacher. In MIDMAY wäre es von Vorteil, wenn Teile der
Repräsentation eines Benutzers mit der eines anderen Benutzers vereinigt werden
können. So könnten Metadaten als Topic-Map zusammen mit den eigentlichen Informationen übertragen und in die Topic-Map des Empfängers eingebunden werden.
29
Ursprüngliches
Verwendungsziel
Fokus
Verwendete
Identitätsmerkmale
Unterscheidung
zwischen
digitalen/anderen
Ressourcen
Darstellung von
Beziehungen
Reifikation
Kontext Konzept
Repräsentation von
Konzepthierarchien
Schema-Definitionen
(Constraints)
Interoperabilität
(Vereinigung von
Repräsentationen mit
unterschiedlichem
Vokabular)
Einbettung in andere
XML Dokumente
Topic Maps
Index für Informationsressourcen: Navigation durch Informationen,
Austausch/Vereinigung
der Indizes
Menschlicher Nutzer
URIs
RDF
Semantic Web“: Softwa”
re Agenten sollen Informationen besser verarbeiten können
Ja (URI als RessourceRef
oder als SubjectIdentityRef )
Nein
n-är, ungerichtet (Association mit Rollenangeben)
Ja, Early reification“
”
Ja, Scope“
”
Ja
Binär, gerichtet (Statement mit Subject, Property und Object)
Ja, Late reification“
”
Nein
Ja, in RDFS definiert
Möglich,
Standard
(TMCL) noch nicht
fertig
Durch definierten Merging-Prozess basierend
auf
dem
IdentitätsKonzept
Ja, mit RDFS oder OWL
Eingeschränkt, nur am
”
Stück“
Ja
Maschinen
URIs
Durch erstellen einer
OWL Ontologie und
Inferenzmechanismen
Tabelle 1: Merkmale von Topic Maps und RDF
Der Nachteil, dass Topic Maps innerhalb anderer XML-Dokumente nicht so gut eingebunden werden können wie RDF, ist für MIDMAY nicht relevant. Die Repräsentation soll als eigene Navigations- und Strukturierungsebene über den Dokumenten
verwendet werden, welche unverändert bleiben.
Nach ausführlicher Betrachtung der Technologien Topic Maps und RDF wird deutlich, dass Topic Maps viele Möglichkeiten bieten, die für ihren Einsatz als Repräsentationsformat in MIDMAY sprechen. RDF zusammen mit OWL ist vor allem für die
Informationsverarbeitung im Bereich der künstlichen Intelligenz geeignet, während
30
4 LÖSUNGSANSATZ
die Topic-Map-Konzepte intuitiver sind und deshalb auch einfacher vom Benutzer
verwendet werden können.
4. Lösungsansatz
Je nach dem auf welcher Datenquelle Informationen gespeichert sind, unterscheidet
sich auch die Art und die Möglichkeiten in den Informationen zu navigieren und nach
Informationen zu suchen. Damit es keinen Unterschied macht, auf welcher Datenquelle eine Information gespeichert ist, soll innerhalb einer einheitlichen Repräsentation der Datenquellen navigiert und gesucht werden können. In diesem Abschnitt
wird ein Lösungsansatz für die Erstellung der einheitlichen Repräsentation mit Topic
Maps beschrieben. Topic Maps stellen Konzepte und Elemente bereit, mit denen die
Informationseinheiten, ihre Eigenschaften (z. B. Speicherort und Format) und ihre
Metainformationen (z. B. Titel und Autor) beschrieben werden können. All diese
Informationen werden in das Topic-Map-Datenmodell abgebildet, und liegen damit
syntaktisch einheitlich als Topics und Assoziationen vor. Doch auch auf semantischer
Ebene kann die Beschreibung der Informationsobjekte vereinheitlicht werden. Dazu
werden Topics und Topic-Map-Strukturen definiert, die bei der Abbildung verschiedener Datenquellen in die Topic-Map-Repräsentation einheitlich verwendet werden
können.
Für die Erstellung der einheitlichen Repräsentation wird nachfolgend eine SoftwareArchitektur vorgestellt, mit der die Anforderungen aus Abschnitt 2.2 erfüllt werden
können. Weiterhin werden Lösungsansätze für die dort gestellten Sicherheitsanforderungen beschrieben. Da die Repräsentation dazu verwendet werden soll, den Benutzer bei Suche und Navigation in seinen verteilten Informationen zu unterstützen,
werden verschiedene Möglichkeiten der Visualisierung von Topic Maps betrachtet.
Bei der Modellierung der Repräsentation geht es schließlich darum, wie Informationen und Strukturen einzelner Datenquellen in Topic Maps abgebildet werden
können.
4.1. Architektur
Das MIDMAY Konzept schlägt für die Erstellung der einheitlichen Repräsentation zwei Module vor. Das Data Retrieval Module (DRM) greift auf die verteilten
Datenquellen zu und liefert Repräsentationen der Datenquellen, die vom Unified
Representation Module (URM) in einer einheitliche Repräsentation vereinigt werden. Weiterhin bietet das URM die Zugriffs-Schnittstelle, über die der Client auf die
Repräsentation zugreifen kann. In diesem Abschnitt wird eine Architektur für das
DRM und URM vorgestellt. Die Module werden in einzelne Komponenten unterteilt,
funktionale Zuständigkeiten werden definiert und die Schnittstellen beschrieben.
31
4 LÖSUNGSANSATZ
4.1.1. Komponenten
Das Komponenten-Diagramm in Abbildung 13 zeigt die Komponenten von URM
und DRM und ihre Abhängigkeiten voneinander. In diesem Abschnitt werden die
Komponenten des Data Retrieval Module (DRM) und des Unified Representation
Module (URM) beschrieben.
Komponenten des DRM:
Extractor
Information Mapping
Metadata Extraction
Information-Object Retrieval
Komponenten des URM:
Representation Manager
Configuration
Communication
Extractor Komponente
Die Extractor Komponente besteht aus mehreren Extraktoren für verschiedene Datenquellen. Jeder Extraktor ist für die Erstellung einer Repräsentation seiner Datenquelle verantwortlich. Er unterstützt das Zugriffsprotokoll der Datenquelle und
liefert Objekte, welche die Informationseinheiten der Datenquelle kapseln. Ein Extraktor für ein Dateisystem liefert zum Beispiel File-Objekte, während ein E-MailExtraktor E-Mail - und MIME-Objekte liefern könnte. Die erzeugten Objekte werden
an die Information Mapping Komponente weitergegeben, welche für die Abbildung
in das Datenformat der einheitlichen Repräsentation zuständig ist. Konfiguriert und
gesteuert wird jeder Extraktor von der Representation Manager Komponente.
Information Mapping Komponente
Die Information Mapping Komponente verarbeitet Objekte die Informationseinheiten einer Datenquelle kapseln. Diese Objekte werden von den Extraktoren erzeugt
und beschreiben die Eigenschaften einer Informationseinheit mit einem, für die Datenquelle spezifischen Vokabular. Die Aufgabe der Information Mapping Komponente besteht darin, die Eigenschaften und Metainformationen einer Informationseinheit
in ein einheitliches Datenformat abzubilden. Dies bedeutet, dass die Eigenschaften
und Metainformationen in ein anderes Datenformat übertragen, und dort mit einem
einheitlichen Vokabular beschrieben werden. Durch die Verwendung eines einheitlichen Vokabulars wird die Beschreibung des Informationsobjekts unabhängig von der
32
4 LÖSUNGSANSATZ
Client
Unfied Representation Module
Communication
Configuration
Representation
Manager
Data Retrieval Module
Extractor
Information
Mapping
InformationObject Retrieval
Metadata
Extraction
Abbildung 13: Komponenten-Diagramm
verwendeten Datenquelle. Nur so ist eine Suche über Metainformationen möglich,
wie sie in Anforderung 3b gefordert wird.
Metadata Extraction Komponente
In den Datenobjekten die eine Extraktor erstellt, sind jeweils nur die Eigenschaften
einer Informationseinheit abgelegt, welche die Datenquelle zu der Informationseinheit speichert. Das sind Informationen wie z. B. der Name einer Informationseinheit und das Datum der Erstellung, welche die Datenquelle zu jeder Dateneinheit
verwaltet. Je nach Datenformat sind innerhalb der Informationseinheit weitere Metainformationen enthalten, die nicht von der Datenquelle verwaltet werden. Aus
Acrobat-PDF- und Microsoft-Word-Dokumenten lassen sich zum Beispiel The”
ma“ und Autor“ extrahieren. Diese Informationen sind jedoch je nach Datenformat
”
der Informationseinheit unterschiedlich codiert. Die Metadata Extraction Komponente kann die Metainformationen verschiedener Datenformate extrahieren, so dass
sie von der Information Mapping Komponente verwendet werden können.
33
4 LÖSUNGSANSATZ
Information-Object Retrieval Komponente
Die Information-Object Retrieval Komponente hat die Aufgabe, die Daten eines in
der Repräsentation ausgewählten Informationsobjekts, auf die Homebase zu übertragen. Dazu muss die Informationseinheit, die vom ausgewählten Informationsobjekt repräsentiert wird, auf der Datenquelle ermittelt werden. Von der Datenquelle werden dann die Daten der Informationseinheit abgerufen und für andere
MIDMAY-Module bereitgestellt. Damit wird eine einheitliche, von den Datenquellen unabhängige Schnittstelle angeboten, welche die Daten einer Informationseinheit
so zurückgibt, wie sie auf der Datenquelle vorliegt. Wenn ein MIDMAY-Modul aus
der codierten Informationseinheit ein Datenobjekt erzeugen will, kann der Typ des
Informationsobjekts (z. B. Datei, E-Mail, E-Mail-Attachment) aus der Repräsentation ermitteln werden. Ohne die einheitliche Schnittstelle müsste für jede Datenquelle
eine eigene Schnittstelle angeboten werden, die für ihre Informationseinheiten ein
entsprechende Datenobjekte erzeugen und zurückgeben kann. Das Erweitern von
MIDMAY um eine neue Datenquelle würde dann Änderungen in allen Modulen
nach sich ziehen, welche diese Schnittstellen benutzen.
Representation Manager Komponente
Die Representation Manager Komponente verwaltet die Erstellung und den Zugriff
auf die einheitliche Repräsentation der verteilten Datenquellen.
Zur Verwaltung der Erstellung werden von ihr die Extraktoren der Extractor Komponente erzeugt, konfiguriert und gesteuert. Ein Extraktor muss mit den Zugangsdaten einer Datenquelle konfiguriert werden, die von der Configuration Komponente
verwaltet werden. Gesteuert wird, wann ein Extraktor die Informationen der Datenquelle extrahiert. Für den Zugriff auf die Repräsentation durch den Client stellt
die Representation Manager Komponente Funktionen zur Navigation und Suche in
der Repräsentation und zum Ergänzen und Strukturieren der Repräsentation bereit. Zur Kommunikation mit dem entfernten Client wird dabei die Communication
Komponente benutzt.
Configuration Komponente
Von der Configuration Komponente wird verwaltet, von welchen Datenquellen Informationen extrahiert werden und welche Einstellungen dabei gelten. Diese Konfigurationsdaten werden von der Representation Manager Komponente benutzt, um
Einstellungen innerhalb des URM vorzunehmen und die Extraktoren zu konfigurieren.
Communication Komponente
Die Communication Komponente stellt Methoden für die Representation Manager
Komponente bereit, um Nachrichten zwischen URM und Client auszutauschen. Sie
34
4 LÖSUNGSANSATZ
ist dafür zuständig, Verbindungen zum Client aufzubauen, die zu versendenden Datenobjekte zu serialisieren, sowie die empfangenen zu de-serialisieren.
4.1.2. Schnittstellen
Damit dem Client die im Abschnitt Anforderungen (2.2) beschriebenen Funktionen
angeboten werden können, müssen entsprechende Schnittstellen definiert werden
werden. In diesem Abschnitt werden Lösungsansätze zur Gestaltung und Realisierung der Schnittstellen vorgestellt.
Zugriff durch den Client
Der Client benötigt die Daten der Repräsentation um sie in irgendeiner Form anzeigen zu können. Dabei ist es aufgrund des großen Datenvolumens nicht möglich, die
ganze Repräsentation auf den Client zu übertragen. Wie in Anforderung 4b bereits
beschrieben, benötigt der Client Funktionen, mit denen er bestimmte Ausschnitte
der Repräsentation abfragen kann. Damit der Client angeben kann, welchen Teil der
Repräsentation er als Rückgabe wünscht, könnte vom URM entweder eine Schnittstelle mit spezifischen Funktionen oder eine Abfrage-Schnittstelle mit einer (QueryLanguage) angeboten werden. Eine Abfragesprache bietet vielfältigere Möglichkeiten
bei der Auswahl des Ausschnitts. Außerdem können Anfragen formuliert werden, die
Topics mit speziellen Eigenschaften zurückliefern. Allerdings ist eine Query-Engine
notwendig, welche die Abfrage interpretieren und das entsprechende Ergebnis ermitteln kann. Spezifische Funktionen sind dagegen weniger flexibel, können aber oft
effizienter implementiert werden. Für Topic Maps existiert noch keine standardisierte Abfragesprache. Daher werden vorerst spezifische Funktionen für die Abfrage von
Ausschnitten verwendet. Später könnte die Schnittstelle um eine Abfragemöglichkeit
mittels Abfragesprache erweitert werden.
Für den Zugriff auf die Repräsentation sind folgende Funktionen vorgesehen:
Von einem Topic ausgehend werden die Topics und Assoziationen in einem
bestimmten Umkreis in eine neue Topic Map kopiert. Die neue Topic Map
wird als Ergebnis zurückgeliefert. Mit Hilfe dieser Funktion kann der Client
eine Navigation innerhalb der Repräsentation realisieren.
Eine Volltextsuche über die Namen aller Topics liefert die Topics zurück, die
eine bestimmte Zeichenkette enthalten.
Bearbeitung der Repräsentation
Neben der Abfrage von Repräsentationsdaten soll die Repräsentation durch den
Benutzer auch erweitert und strukturiert werden können (Anforderung 3c). Hier
35
4 LÖSUNGSANSATZ
stellt sich die Frage, welche Möglichkeiten dem Client eingeräumt werden, die Repräsentationsdaten zu verändern. Um den möglichen Funktionsumfang eines Clients
nicht schon auf Ebene des URM einzuschränken, sollten möglichst universelle Funktionen zur Bearbeitung der Repräsentation zur Verfügung gestellt werden. Wenn
der Client allerdings die gesamte Repräsentation beliebig verändern darf, kann sie
möglicherweise vom URM Modul der MIDMAY-Homebase nicht mehr verarbeitet
werden. Es muss z. B. vermieden werden, dass für die Verarbeitung essenzielle Informationen vom Client gelöscht werden können. Mit Topic Maps kann dies durch
einen modularen Aufbau der Repräsentation realisiert werden. Dem Benutzer wird
eine eigene Topic Map zugeordnet, die ein Client ohne Einschränkungen bearbeiten
kann. In dieser Topic Map werden alle Informationen gespeichert, die der Benutzer
der Repräsentation hinzufügt. Die extrahierten Informationen werden in anderen
Topic Maps gespeichert, so dass der Benutzer sie nicht direkt ändern kann. Trotzdem können in der Benutzer-Topic-Map die repräsentierten Informationen anderer
Topic Maps strukturiert werden, indem die Topics der extrahierten Topic Maps referenziert werden. Der Client kann dabei auch Assoziationstypen verwenden, welche
dem URM nicht bekannt sein müssen. Bei verschiedenen Client-Implementierungen,
sollten allerdings bestimmte Typen definiert werden, die von den Clients dann einheitlich unterstützt werden können. Falls Informationen beim Extrahieren falsch eingeordnet werden, können die entsprechenden Assoziationen vom Client zwar nicht
gelöscht, aber durch Reifikation als falsche Aussage markiert werden. Ist z. B. in einem Dokument ein falscher Autor angegeben, wird diese Angabe automatisch in die
Repräsentation übertragen. Der Benutzer korrigiert auf seinem MIDMAY-Client,
den Autor. Der Client erstellt in der Benutzer-Topic-Map die korrekte Assoziation
und die Aussage, dass die ursprüngliche Assoziation falsch ist.
Für die Bearbeitung der Repräsentation durch den Client oder andere MIDMAY
Module sind folgende Funktionen vorgesehen:
Hinzufügen von Informationen zur Benutzer-Topic-Map.
Löschen von Informationen aus der Benutzer-Topic-Map.
Abruf und Speicherung der gesamten Benutzer-Topic-Map (für Clients mit hoher Bandbreite und Rechenkapazität oder für andere MIDMAY-Module (siehe
Schnittstellen für MIDMAY Module)).
Schnittstellen für MIDMAY Module
Außer dem DRM müssen auch andere MIDMAY Module mit der vom URM verwalteten Repräsentation arbeiten. Es müssen z. B. Daten aus der Repräsentation
gelesen werden können, damit das Data Transfer Modul beim Versenden von Datenobjekten an eine andere MIDMAY-Homebase auch Informationen der Repräsentation mitsenden kann. Um Repräsentationsdaten zu lesen, können MIDMAY-Module
die selbe Schnittstelle verwenden wie der Client. Das Erweitern der Repräsentati-
36
4 LÖSUNGSANSATZ
on ist notwendig, wenn Daten von einer anderen MIDMAY-Homebase eintreffen.
MIDMAY-Module, die der Repräsentation Informationen hinzufügen müssen, erhalten wie der Benutzer ihre eigene Topic Map. Die Bearbeitung dieser Topic Map
erfolgt über die gleiche Schnittstelle wie die Bearbeitung der Benutzer-Topic-Map
durch den Client. Abbildung 14 zeigt, wie die Topic Maps innerhalb der MIDMAY
Homebase vom DRM, dem Client und weiteren MIDMAY Modulen verwendet und
bearbeitet werden können.
MIDMAY Homebase
Client fragt Teile
der Repräsentation ab
MIDMAY Modul
holt Ausschnitte
der Repräsentation
Client
URM
vereinigt
Topic Maps
MIDMAY
Modul
verändert
eigene
Topic Map
Client verändert
Benutzer-Topic-Map
DRM
extrahiert Topic Maps
aus Datenquellen
Datenquellen
Abbildung 14: Bearbeitung der einzelnen Topic Maps
4.2. Sicherheit
In MIDMAY sollen die Informationen des Benutzers geschützt werden (Anforderungen 5b und 5c) und auch alle Kommunikationsdaten sollen sicher übertragen werden
(Anforderung 5a). In diesem Abschnitt werden Lösungsansätze betrachtet, welche
die beschriebenen Sicherheitskriterien erfüllen können.
37
4 LÖSUNGSANSATZ
4.2.1. Authentifizierung und sichere Datenübertragung
Auf Informationen der MIDMAY-Homebase sollen nur autorisierte Benutzer Zugriff
haben. Dazu authentifiziert sich der Benutzer bei seinem Client und der Client bei
der MIDMAY-Homebase. Für die Authentifizierung zwischen Client und MIDMAYHomebase ist in der Homebase ein ID-Management-Modul vorgesehen. Dieses Modul
soll eine Single-Sign-On-Möglichkeit bieten, so dass auch andere externe Dienste
durch die Authentifizierung bei der MIDMAY-Homebase genutzt werden können.
Die Funktionalität für den Aufbau einer sicheren Verbindung zwischen einem
MIDMAY-Modul und dem Client sollte durch eine eigene Komponente innerhalb
des ID-Management-Moduls realisiert werden. Diese Kommunikations-Komponente
arbeitet dann als lokaler Proxy für die MIDMAY-Homebase-Module. Jede Kommunikation des Clients mit seiner Homebase läuft so über das ID-Management-Modul,
das die Sicherheit der übertragenen Daten gewährleistet.
4.2.2. Schutz der Zugangs- und Repräsentationsdaten
Die Zugangsdaten für die Datenquellen werden vom ID-Management Modul verwaltet. Sie sollten weder von außen über das Netzwerk, noch von innen durch fremde Software ausgelesen oder verändert werden können. Um die Zugangsdaten vom
Zugriff von außen zu schützen, müssen sie auf der MIDMAY-Homebase in einem
Bereich abgelegt werden, der nur lokal verfügbar ist. Die Daten der Repräsentation
können ebenfalls auf diese Weise geschützt werden. Vor fremder, lokal ausgeführter Software können die Zugangsdaten durch verschlüsseltes Abspeichern geschützt
werden. Bestimmte MIDMAY-Module wie z. B. das Data-Retrieval-Modul, müssen
die Möglichkeit haben, die Zugangsdaten vom ID-Management-Modul zu erhalten.
4.2.3. Mehrbenutzer-Aspekte
Eine Repräsentation von Informationen verschiedener Datenquellen könnte für einen
einzigen Benutzer oder für mehrere Benutzer erstellt werden. Wird sie für mehrere Benutzer erstellt, dann können diese Benutzer die Repräsentation gemeinsam
verwenden, verwalten und strukturieren. Damit bestimmte Informationen trotzdem
vertraulich bleiben, sind unterschiedliche Zugriffsrechte auf die Repräsentation und
die repräsentierten Informationen nötig. Dadurch wird auch für die Datenquellen
ein Mehrbenutzer-Konzept geboten, denen ein solches fehlt. Allerdings darf auf diese Quellen dann nur über die Repräsentation zugegriffen werden. Sind bereits Zugriffsrechte in einer Datenquelle definiert, ist eine Übertragung dieser vorhandenen
Rechte in die Repräsentation kaum möglich. Die Mehrbenutzer-Modelle unterschiedlicher Datenquellen müssten in ein einheitliches Modell abgebildet werden.
38
4 LÖSUNGSANSATZ
Um bei mehrere Benutzern den Zugriff auf unterschiedliche Bereiche der Repräsentation zu regeln, ist daher eine eigenständige Verwaltung der Benutzer und ihrer
Rechte notwendig. Dabei werden hier zwei unterschiedliche Lösungen vorgestellt,
wie MIDMAY-Homebase, Repräsentation und Benutzer in Bezug zueinander stehen
könnten:
1. Auf einer MIDMAY-Homebase wird für jeden Benutzer eine Repräsentation
erstellt, welche die Informationen repräsentiert, die ihm zugänglich sind
Für jeden Benutzer wird eine eigene Repräsentation erstellt, wobei seine Zugangsdaten und damit automatisch auch seine Rechte innerhalb der einzelnen Datenquellen verwendet werden. Durch getrennte Repräsentation geht jedoch wieder der Vorteil Informationen gemeinsam verwalten zu können, verloren. Deshalb müssen die Repräsentationen entweder zu einer gemeinsamen
Repräsentation vereinigt werden, oder Änderungen gemeinsam benutzter Informationen müssen in die anderen Repräsentationen übertragen werden. Ein
Nachteil für den Benutzer ist, dass er nur mit den Personen gemeinsam Informationen verwalten kann, die zu seiner MIDMAY-Homebase gehören.
2. Für jeden Benutzer wird eine eigene MIDMAY-Homebase verwendet, welche
eine Repräsentation seiner Informationen enthält. Der Benutzer kann Zugriffsrechte für weitere Benutzer vergeben
Der Benutzer einer Repräsentation kann verschiedene Bereiche für andere Benutzer freigeben, so dass eine gemeinsame Verwaltung möglich ist. Der Benutzer arbeitet als Administrator, und muss den Überblick über die vergebenen
Rechte behalten. Nachteilig ist, dass fremde freigegebene Informationen nicht
zu eigenen Informationen in Beziehung gesetzt werden können, da sie in verschiedenen Repräsentationen auf jeweils einer MIDMAY-Homebase vorliegen.
Die beide vorgestellten Lösungen sind mit den genannten Nachteilen beide nicht
optimal. Während bei der ersten die Flexibilität fehlt, in verschiedenen Gruppen arbeiten zu können, ist bei der zweiten die gleichzeitige Nutzung von gemeinsamer und
privater Information nicht möglich. Da MIDMAY nicht als Plattform für gemeinsames Arbeiten, sondern in erster Linie zur Verteilung von Informationen gedacht
ist, wird im Prototyp für die Erstellung der Repräsentation keine der vorgestellten
Lösungen implementiert. Statt dessen wird einem Benutzer der Zugriff auf die gesamte Repräsentation gewährt, so dass eine Repräsentation entweder nur von einer
einzelnen Personen oder von mehreren gleichberechtigt genutzt werden kann.
4.3. Darstellung und Navigation
Zu den Aufgaben eines MIDMAY-Clients gehört es, dem Benutzer die Repräsentation der verteilten Informationen zu visualisieren. Die Visualisierung umfasst die
Darstellung der Repräsentation in einer geeigneten Form, und eine Navigation in-
39
4 LÖSUNGSANSATZ
nerhalb der Darstellung. In [16] werden Anforderungen an die Visualisierung von
Topic Maps gestellt und verschiedene Ansätze zur Visualisierung bewertet. Die Darstellung einer Topic Map soll einerseits einen Überblick ermöglichen, andererseits
soll sie auch Details zu bestimmten Topics liefern können. Eine gute Navigation soll
dem Benutzer die Möglichkeit geben, die Topic Map intuitiv zu erkunden.
Die Realisierung eines MIDMAY-Clients und damit die Visualisierung der Repräsentation ist nicht Teil dieser Arbeit. Die Datenquellen müssen jedoch so als Topic Map
repräsentiert werden, dass eine effektive, von der Art der Datenquelle unabhängige
Visualisierung möglich ist. Außerdem setzen manche Techniken zur Visualisierung,
wie etwa die Darstellung als hierarchischer Baum, eine bestimmte Struktur innerhalb
der Topic Map voraus. Sollen diese Visualisierungstechniken auf einem MIDMAYClient angewendet werden, müssen bereits bei der Erstellung der Topic Maps die
notwendigen Informationen passend abgebildet werden.
4.3.1. Visualisierung von Topic Maps als Graph
Da eine Topic Map ein Netzwerk aus Topics als Knoten und Assoziationen als Kanten
bildet, können sie gut als Graph dargestellt werden. In einem Graph können Zusammenhänge zwischen Topics vom Menschen schnell erfasst werden. Topics, die durch
eine Assoziation verbunden oder vom gleichen Typ sind, werden dazu möglichst
nahe beieinander angezeigt. Bei vielen Knoten wird es allerdings schwierig, sie so
anzuordnen, dass die Informationen weiterhin erkennbar und übersichtlich sind.
Es existieren bereits mehrere freie Tools, die eine Topic Map als Graph darstellen
können. Der Ontopia Omnigator 8 ist eine Server-Anwendung, die Topic Maps als
Webseiten zur Verfügung stellt und mit einem Applet auch als Graph visualisieren
kann. Die Software TwoMore 9 erlaubt nicht nur die Darstellung von Topic Maps 2D
oder 3D-Graph, sie kann auch als graphischer Editor für Topic Maps dienen. Verschiedene Darstellungsmöglichkeiten für Topic Maps bietet TMNav 10 . Abbildung 15
zeigt, wie die Anzeige eines Topic-Map-Ausschnitts durch die genannten Tools aussieht.
Die generische Visualisierung von Topic Maps als Graph zeigt eindrucksvoll, wie
viele Informationen und Zusammenhänge in einer Topic Map gespeichert sind. Sie
kann jedoch nicht immer den Zweck erfüllen, den Benutzer schnell zu dem zu führen,
was er eigentlich sucht. Da umfangreiche Topic Maps immer nur ausschnittsweise
angezeigt werden können, muss der Benutzer von Topic zu Topic navigieren. Sind die
Topics durch viele Assoziationen verbunden, ist der Weg zu einem bestimmten Topic
zwar kürzer, wegen einer höheren Informationsdichte allerdings auch schwieriger zu
8
Ontopia Omnigator: http://www.ontopia.net/omnigator
TwoMore: http://www.pi.informatik.tu-darmstadt.de/se2004/byteme/
10
TMNav: http://tm4j.org/tmnav.html
9
40
4 LÖSUNGSANSATZ
(a) TwoMore - 2D Visualization
(b) TMNav - Tree-View und Hypergraph
(c) Omnigator - Container-Containee Hierarchie
Abbildung 15: Visualisierung von Topic Maps
finden. Die Herausforderung besteht darin, dem Benutzer von der globalen Sicht bis
zu den Einzelheiten verschiedene Ebenen der Navigation anzubieten.
Sollen die Informationseinheiten unterschiedlicher Datenquellen visualisiert werden,
ist ein Graph zur Darstellung der semantischen Zusammenhänge zwischen den Informationsobjekten geeignet. Semantische Zusammenhänge können z. B. der gleiche Inhalt, Autor oder Absender eines Informationsobjekts sein. Auf einem mobilen Gerät
mit kleinem Bildschirm ist die Visualisierung als Graph allerdings kaum möglich.
Wird außerdem eine solche Visualisierung alleine angeboten, fehlen dem Benutzer
die gewohnten Möglichkeiten zur Navigation. Er kann sich nicht durch einen Ver-
41
4 LÖSUNGSANSATZ
zeichnisbaum zu seinen Dateien bewegen und neue Nachrichten findet er nicht mehr
im Posteingang“, sondern als Nachbarknoten des Knotens Neue Nachrichten“. Da
”
”
die Benutzer-Akzeptanz einer solchen Navigation wohl gering wäre, ist eine reine
Graphen-Visualisierung der Datenquellen ist nicht geeignet.
4.3.2. Visualisierung von Hierarchien
Hierarchien werden in vielen Zusammenhängen zur Strukturierung von Informationen und zur Navigation in Informationen eingesetzt. In Dateisystemen und dem
Internet sind die Ressourcen hierarchisch strukturiert, auf Webseiten wird eine hierarchische Navigation angeboten und in Internet-Foren erhalten Diskussionen eine
hierarchische Struktur.
In einer Topic Map sind die Informationen zwar nicht hierarchisch geordnet, oft
bilden aber Teile der Topic Map eine Hierarchie. Wenn Datenquellen mit hierarchisch strukturierten Informationen als Topic Map repräsentiert werden sollen, ist
es sinnvoll die hierarchische Ordnung in die Topic Map zu übertragen. Die Darstellung von Informationen in einer Hierarchie ist überschaubarer als in einem Graph,
und die Navigation kann genauso erfolgen, wie es der Benutzer von der Navigation
mit Datei-Browser und E-Mail-Client gewohnt ist. In den Topic Map Tools TMNav
und TwoMore können Hierarchien innerhalb einer Topic Map jedoch nicht für eine
hierarchische Darstellung genutzt werden. Die beiden Tools können nur die Details
eines Topics als Baum darstellen (Abbildung 15(b), linke Seite des Fensters). Diese
Darstellung ist aber missverständlich, da zwei im Baum hierarchisch angeordnete
Topics nicht unbedingt in einer hierarchischen Beziehung zueinander stehen. Der
Ontopia Omnigator kann dagegen Hierarchien anzeigen, die durch bestimmte Assoziationen innerhalb einer Topic Map gebildet wurden. Auf der rechten Seite der
Abbildung 15(c) ist eine durch container-containee Assoziationen definierte Hierarchie zu sehen.
4.3.3. Klassifizierung von Informationen durch Facets
Datenquellen bieten eine hierarchische Struktur an, damit Informationen strukturiert abgelegt werden können. Die hierarchische Struktur wird dazu verwendet Informationen zu klassifizieren, um sie schneller wiederfinden zu können. In einem
Dateisystem werden z. B. die Ordner Bilder“, Dokumente“ oder Projekte“ an”
”
”
gelegt und Dateien entsprechend dort abgespeichert. Wo aber speichert man ein
Dokument eines Projekts, an dem gerade geschrieben wird? Wo sind Bilder gespeichert, welche die Arbeit an einem Projekt dokumentieren? Das Problem ist, dass
viele Informationen nicht eindeutig klassifiziert werden können, sondern mehrere
unabhängige Dimensionen der Klassifikation möglich sind. Eine Information kann
42
4 LÖSUNGSANSATZ
z. B. danach klassifiziert werden, in welchem Datentyp sie vorliegt, in welchem Zusammenhang sie verwendet wird, wer sie erstellt hat oder ob sie wichtig oder unwichtig ist. Während in Dateisystemen oder IMAP E-Mail-Postfächern ein Objekt
nur in einem einzigen Ordner gespeichert werden kann, ist in der Repräsentation
die Einordnung eines Informationsobjekts in verschiedene Hierarchien möglich. Die
Klassifizierung von Objekten in mehreren voneinander unabhängigen Hierarchien
wird als Faceted Classification bezeichnet. Jede Hierarchie strukturiert die Objekte
auf eine andere Art und wird deshalb Facet (Facette/Aspekt) genannt. Wenn in der
MIDMAY Repräsentation Informationsobjekte in mehrere Hierarchien eingeordnet
werden, kann ein MIDMAY-Client dem Benutzer eine Facet-basierte Navigation anbieten. Der Benutzer kann sich also eine bestimmte Hierarchie aussuchen, über die er
zu einem gesuchten Informationsobjekt navigieren kann. In manchen Internet-Shops
wird eine Facet-Navigation angeboten, damit der Benutzer alle für ihn relevanten
Produkte leichter finden kann. Ein Beispiel für eine solche Navigation kann auf der
Webseite http://facetmap.com/browse/ ausprobiert werden. Weitere Informationen zur Faceted Classification und deren Einsatz auf Webseiten liefert [4].
4.3.4. Darstellung einzelner Topics
Bei der Darstellung von einzelnen Topics kann auf bestimmte Topic-Eigenschaften
zurückgegriffen werden.
Topic-Typ
Topics können anhand ihres Typs unterschiedlich dargestellt werden. Wenn die Darstellung generisch erfolgen soll, können den Topic-Typen automatisch bestimmte
Darstellungsformen zugewiesen werden. Bei der graphischen Visualisierung des Ontopia Omnigator wird für jeden Typ eine andere Farbe verwendet. Sind die Typen
der darzustellenden Topics bekannt, kann jedem Typ ein Icon zur Darstellung der
Topics zugeordnet werden. Diese Topic-Darstellung ist in TwoMore möglich (Abbildung 16). Der Typ eines Topcis und seine Bedeutung kann so visuell erfasst werden.
Auch MIDMAY-Clients könnten Icons bei der Topic-Darstellung verwenden, da in
der MIDMAY Repräsentation nur vorher definierte Topic-Typen verwendet werden.
Scope
Mit dem Scope Konzept können bei der Anzeige von Topics verschiedene Sprachen unterstützt werden. Einem Topic wird für jede Sprache ein Name zugeordnet, und die Sprache jeweils als Scope (Gültigkeitsbereich) des Namens definiert. Diese mehrsprachigen“ Topics können dann bei der Visualisierung, in der
”
vom Benutzer ausgewählten Sprache angezeigt werden. Um den Scope der TopicNamen zu definieren, werden Topics benötigt, welche existierende Sprachen re-
43
4 LÖSUNGSANSATZ
Abbildung 16: Visualisierung des Topic-Typs in TwoMore
präsentieren. Subject Identifier für diese Sprach-Topics wurden von OASIS unter
http://psi.oasis-open.org/iso/639/ veröffentlicht.
4.4. Modellierung
Durch die Topic-Map-Repräsentation der Datenquellen wird eine einheitliche Sicht
auf die Informationseinheiten unterschiedlicher Datenquellen ermöglicht. In diesem
Abschnitt wird beschrieben, welche Topic-Map-Konzepte und -Strukturen bei der
Abbildung von Datenquellen in die Topic-Map-Repräsentation verwendet werden
können. Für einzelne Datenquellen wird gezeigt, wie ihre Informationseinheiten in
die Repräsentation übertragen werden können. Außerdem wird diskutiert, wie eine einheitliche Beschreibung der Eigenschaften der Informationsobjekte realisiert
werden kann.
4.4.1. Published Subjects
In Topic Maps werden URIs als Subject Address oder Subject Identifiers verwendet,
damit repräsentierte Dinge eindeutig identifiziert werden können. In der Repräsentation der Datenquellen ist die Identifizierbarkeit notwendig, um das automatische
Merging zu unterstützen und Topics anhand ihrer Subject Address oder ihres Subject
Identifiers adressieren zu können. Für manche Datenquellen, z. B. für Dateisysteme,
gibt es bereits ein URL-Schema, mit dem für jede Informationseinheit eine URLAdresse gebildet werden kann. Diese URL kann direkt als Subject Address eines
Topics verwendet werden. Es ist jedoch nicht für jede Datenquelle ein geeignetes
URL-Schema zur Adressierung der Informationseinheiten verfügbar. Beispielsweise
gibt es für das POP3-Email-Protokoll ein Schema, mit dem zwar der Mailserver,
jedoch nicht eine einzelne E-Mail oder ein Datei-Anhang adressiert werden kann. In
44
4 LÖSUNGSANSATZ
solchen Fällen muss eine geeignete Vorschrift zur Bildung der URL einer Informationseinheit eigenständig definiert werden.
Subjects, die für die Typisierung von Topics bestimmt sind, z. B. Datei“, E-Mail“,
”
”
Mailadresse“ oder Person“, sind keine elektronischen Ressourcen und müssen des”
”
halb über PSIs identifiziert werden. Bis jetzt gibt es für die genannten Subjects
aber noch keine öffentlichen PSIs, die einfach übernommen werden könnten. Als
PSI kann prinzipiell jede Informationsressource verwendet werden, die Hinweise auf
das gewünschte Subject liefert und durch eine URI adressierbar ist. Es könnten also
auch vorhandene Definitionen aus Online-Wörterbüchern oder RDF-Vokabularien
verwendet werden. Beide Lösungen würden jedoch nicht vollständig den OASISAnforderungen für PSIs entsprechen [19]. Webseiten eines Online-Wörterbuchs als
Publish Subject Indicators erfüllen die Anforderung, dass die Auflösung einer Subject Identifier URI einen von Menschen interpretierbaren Publish Subject Indicator
zurückliefern soll. Es wird aber dagegen verstoßen, dass PSIs explizit die URI angeben sollen, die als PSID verwendet wird. Hinzu kommt, dass sich die URL für das
Nachschlagen eines bestimmten Begriffs ändern kann und nicht zwingend bestehen
bleibt. Unter diesem Aspekt wären mit RDF-Schema definierte RDF-Klassen als
PSIs geeignet, da sie über eine URI identifiziert werden, die nicht verändert wird.
Allerdings ist es in RDF nicht erforderlich, dass die URI eine vorhandene Informationsressource adressiert. Selbst wenn eine Informationsressource mit einer solchen
URI vorhanden ist, muss sie nicht wie gefordert menschenlesbare Information enthalten. Eine Lösung, bei der alle OASIS Anforderungen berücksichtigt werden, ist
die selbstständige Definition von Subject Identifiern und PSIs. So kann z. B. für das
Konzept einer Datei“ die Adresse http://www.sit.fraunhofer.de/midmay/psi/
”
filesystem/#file definiert werden und als Published Subject Indicator unter dieser
Adresse eine informelle Definition des Konzepts Datei“ abgelegt werden. PSIs die
”
auf diese Weise für die Abbildung von Datenquellen in die MIDMAY Repräsentation
definiert wurden, sind im Anhang B aufgelistet.
4.4.2. Topic Map Templates
Um eine Topic Map per Hand oder automatisiert zu erstellen, müssen als erstes Topics definiert werden, die als Typen für Assoziationen und weitere Topics verwendet
werden können. Eine Topic Map die solche Typisierungs-Topics enthält, wird Topic
Map Template genannt. Neben den Typisierungs-Topics können auch Scoping-Topics
und Rollen-Topics in einem Template definiert werden. Topic Map Templates sind
nicht Teil eines Standards, sondern ein Begriff für Topic Map Konstrukte, welche die
Struktur einer Topic Map in irgendeiner Weise vorgeben. Es sind auch komplexere
Templates möglich, in denen Inferenz-Regeln und Constraints definiert werden (siehe [20], Kapitel 14). Constraints wären für die Wissensrepräsentation in MIDMAY
wünschenswert, um die Struktur der extrahierten Topic Map formal zu definieren.
45
4 LÖSUNGSANSATZ
Da jedoch noch kein Standard zur Definition von Constraints existiert, müsste deren Definition und Überprüfung selbst entwickelt und implementiert werden. Die
Strukturen der zu extrahierenden Topic Maps werden deshalb nicht als Constraints
definiert, sondern in dieser Arbeit sowohl informal, als auch mit der aus Abschnitt 3.1
(Topic Maps) bekannten UML Notation beschrieben.
4.4.3. Patterns für Topic Maps
Ebenso wie Software-Design Patterns beschreiben auch Patterns für Topic Maps
häufig verwendete Lösungen für wiederkehrende Design-Probleme. Ein Pattern gibt
wie ein Topic Map Template die Struktur einer Topic Map vor. Während in einem
Template die Topics für ein bestimmtes Anwendungsgebiet definiert werden, beschreiben Patterns abstraktere Strukturen, die unabhängig vom Anwendungsgebiet
der Topic Map verwendet werden können. Kal Ahmed stellt in [1] Patterns für Topic
Maps vor, von denen das Hierarchical Classification Pattern und das Faceted Classification Pattern zur Verwendung in der Repräsentation der Datenquellen geeignet
sind.
Hierarchical Classification Pattern
Das Hierarchical Classification Pattern ermöglicht es, in einer Topic Map mehrere Hierarchien mit unterschiedlichen Assoziationstypen zu definieren. So sind z. B.
Parent-Child“ oder Container-Containee“ zwei verschiedene Assoziationstypen,
”
”
welche aber die selbe hierarchische Semantik besitzen. Für solche hierarchischen Assoziationstypen wird der gemeinsame Supertyp Hierarchical Relationship Type definiert. Ebenso erhalten die Rollenspezifikationen wie Parent“ und Child“ jeweils
”
”
einen Supertyp für die über- bzw. untergeordnete Rolle in der hierarchischen Assoziation. Ein beliebiges Topic kann zur Instanz einer Klasse innerhalb der Hierarchie
gemacht werden, indem es durch eine Classified As Assoziation mit dieser Klasse
verbunden wird. Abbildung 17 zeigt das Hierarchical Classification Pattern als UML
Diagramm. Die durch dieses Pattern definierten Topics sind kursiv geschrieben. Mit
Hilfe dieses Patterns können alle hierarchischen Assoziationstypen explizit als solche
gekennzeichnet werden. Dadurch ist es möglich verschiedene Hierarchien einheitlich
zu behandeln, z. B. könnten sie durch eine einzige Software-Komponente einheitlich
visualisiert werden.
Faceted Classification Pattern
Mit dem Hierarchical Classification Pattern allein ist es sehr umständlich, eine Facet
basierte Navigation in Topic Maps zu realisieren. Es fehlt die Möglichkeit alle in einer
Topic Map vorhandenen Hierarchien und deren Wurzelelemente auf einfache Weise
zu bestimmen. Abhilfe schafft das Faceted Classification Pattern (Abbildung 18).
Jede Hierarchie wird durch ein eigenes Topic vom Typ Facet repräsentiert. Dieses
46
4 LÖSUNGSANSATZ
Hierarchical
Relationship Type
Classified as
«Topic»
Instance
«Topic»
Classification
«instanceOf»
1 Parent
Derived
Hierarchy Type
* Child
Subordinated
Role Type
Superordinated
Role Type
«instanceOf»
«instanceOf»
Child
Parent
Abbildung 17: Hierarchical Classification Pattern
Topic ist über die Facet Has Root Assoziation mit dem Wurzelelement der Hierarchie
verbunden. Der Assoziationstyp der Hierarchie wird mit der Facet Has Hierrachy
Type Assoziation definiert.
Facet
«instanceOf»
Facet
1
1 Facet
Hierarchical
Relationship Type
Facet Root
1
«Topic»
A Facet
1 Parent
Facet Has
Hierarchy Type
«instanceOf»
Derived
Hierarchy Type
1 Facet Hierarchy Type
* Child
Abbildung 18: Faceted Classification Pattern
47
4 LÖSUNGSANSATZ
4.4.4. Topic Map Modell zur Indizierung von Datenquellen
Um eine einheitliche Sicht auf die Informationen von Datenquellen zu ermöglichen,
ist ein generisches Modell nötig. Dieses Modell gibt bestimmte Typen und Strukturen zur Indizierung von Datenquellen vor. Es wird als generisch bezeichnet, weil die
Struktur jeder Datenquelle auf dieses Modell abgebildet werden muss. Eine einheitliche Struktur der Informationen ist nötig, damit nicht für jede Datenquelle neben
der Extraktionskomponente auch eine spezifische Darstellungskomponente implementiert werden muss. Mit den im generischen Modell definierten Strukturen soll
bereits eine benutzerfreundliche Navigation in den Informationen möglich sein. Allerdings darf die Möglichkeit der Integration unterschiedlichster Datenquellen durch
die vorgegebene Struktur auch nicht zu sehr eingeschränkt werden.
Um dem Benutzer wie in Abschnitt 4.3.2 beschrieben, eine Baumstruktur zur Navigation anbieten zu können, muss die hierarchische Organisation der Informationen
bei Datenquellen wie z. B. Dateisystemen oder E-Mail-Postfächern erhalten bleiben.
Um die hierarchische Struktur einer Datenquelle zu repräsentieren wird auf das
vorgestellte Topic Map Pattern Hierarchical Classification“ zurückgegriffen. Da”
mit kann für jede hierarchisch strukturierte Datenquelle eine eigene hierarchische
Beziehung zwischen ihren Informationseinheiten definiert werden. Für eine Ordnerstruktur wäre z. B. eine Container-Containee“ Assoziation geeignet.
”
Wenn man es zulässt, dass Informationseinheiten bei der Abbildung nicht nur in eine Hierarchie, sondern in mehrere eingeordnet werden können, erhält man das Konzept der Faceted-Classification. Informationseinheiten können dann nicht nur in die
Hierarchie eingeordnet werden, welche die hierarchische Struktur der Datenquelle repräsentiert (z. B. eine Ordnerstruktur wie in Abbildung 19(a)), sie können auch nach
ihren Eigenschaften klassifiziert werden. Dazu wird eine Eigenschafts-Hierarchie definiert, in der Eigenschaften von Informationsobjekten hierarchisch angeordnet sind
(Beispiel: Abbildung 19(b)). Wird ein Informationsobjekt auf diese Weise klassifiziert, können verschiedene Sichten auf das Informationsobjekt realisiert werden. Es
kann einerseits als Element der hierarchischen Struktur der Datenquelle, andererseits
auch als Träger bestimmter Eigenschaften dargestellt werden.
Damit die Betrachtung der Informationsobjekte als Träger bestimmter Eigenschaften unabhängig von der Datenquelle funktioniert, müssen die Eigenschaften über
verschiedene Datenquellen hinweg einheitlich definiert und verwendet werden (siehe
Anforderung 1c). Eigenschaften, die in Informationseinheiten verschiedener Datenquellen auftauchen können und jeweils die gleiche Semantik besitzen, sind z. B. das
Erstellungsdatum, der Autor oder der Datentyp einer Informationseinheit. Es ist
jedoch nicht notwendig alle Eigenschaften von vornherein im generischen Modell
festzulegen. Stattdessen können Eigenschaften von Informationseinheiten nach und
nach bei der Integration verschiedener Datenquellen definiert werden.
48
4 LÖSUNGSANSATZ
(a) Hierarchische Struktur einer Datenquelle (b) Eigenschaften von Informationsobjekten als
Hierarchie
Abbildung 19: Verschiedene Facets für Informationsobjekte
4.4.5. Dateisysteme
In einem hierarchischen Dateisystem sind die Dateien in Verzeichnisse eingeordnet,
die wiederum weitere Verzeichnisse enthalten können. Dadurch entsteht eine hierarchische Verzeichnisstruktur. Von einem Verzeichnis ausgehend, sollen die Dateien
und Verzeichnisse aus einem Teilbaum der Verzeichnisstruktur in eine Topic Map
abgebildet werden. Für jede Datei und jedes Verzeichnis wird in der Topic Map
ein Topic erstellt. Wie im Dateisystem sollen auch in der Topic Map die in einem
Verzeichnis enthaltenen Dateien und Unterverzeichnisse ermittelt werden können.
Um ein Verzeichnis-Topic mit den enthaltenen Elementen zu verbinden, wird eine
Container-Containee Assoziationen definiert, und mit dem Hierarchical Classification Pattern als hierarchische Assoziation gekennzeichnet. Das UML-Diagramm in
Abbildung 20 zeigt, welche Topic-Typen dabei verwendet werden. Für die abgebildete Verzeichnisstruktur wird ein eigenes Facet erstellt, damit das Wurzelverzeichnis
und die hierarchische Assoziation bestimmt werden können.
Datei-Eigenschaften
Außer den Dateien und Verzeichnissen selbst sollen auch verschiedene Eigenschaften der Dateien als Metadaten in die Topic Map aufgenommen werden. Der Name
der Datei wird als Basename des Datei-Topics gespeichert. Für alle weiteren Datei-
49
4 LÖSUNGSANSATZ
Facet Has
Root
Folder
facet
«File System Facet»
«instanceOf»
«Folder Topic»
Information Object
Type
1 Container
«instanceOf»
1
File
Container
Container-Containee
* Containee
Container-Containee
«instanceOf»
«File Topic»
Facet Has
Hierarchy Type
facet-root
* Containee
Subordinated
Role Type
Superordinated
Role Type
«instanceOf»
«instanceOf»
Containee
Container
Abbildung 20: Topic Map Modell für Verzeichnisse und Dateien
Eigenschaften, die ermittelt werden können, wird jeweils ein eigenes Topic erstellt
und über eine Assoziation mit dem Datei-Topic verbunden. Vom Dateisystem zur
Verfügung gestellte Eigenschaften sind z. B. das Erstellungsdatum und das Datum
der letzten Änderung an der Datei. Für jede Datei-Eigenschaft muss ein eigener
Assoziationstyp definiert werden. Für das Erstellungsdatum wird z. B. das Topic
Object-Created Relation definiert und als Assoziationstyp für die Assoziation zwischen einem Datei-Topic und einem Datum-Topic verwendet wird. Eine solche Assoziation ist in Abbildung 21 dargestellt. Das Topic Object-Created Relation erhält
für jede Rolle der Assoziation einen eigenen Namen. Dadurch kann die Assoziation
aus dem Kontext eines teilnehmenden Topics dargestellt und entsprechend benannt
werden. Aus Sicht des test.doc Topics, wird der Name was created at“ verwendet,
”
vom Datum aus gesehen der Name is creation date of“.
”
«Basename»
"was created at"
«Basename»
"is creation date of"
«scope»
Information Object
test.doc
«scope»
Object-Created
Relation
Information Object
Created
Created
15.08.2005, 09:45:42
Abbildung 21: Assoziation zur Repräsentation des Erstellungsdatums einer Datei
50
4 LÖSUNGSANSATZ
Metainformationen
Neben den Datei-Eigenschaften, die das Dateisystem zur Verfügung stellt, können
weitere Informationen aus den Dateien selbst gewonnen werden. In MS Office- oder
PDF-Dateien sind z. B. der Titel und Autor eines Dokuments gespeichert. Solche Metainformationen sind jedoch je nach Dateiformat unterschiedlich codiert. Sie können
nur durch spezielle Software-Komponenten extrahiert werden, die das Dateiformat
verstehen“. Für die Extraktion von Metainformationen ist also je nach Dateifor”
mat eine andere Komponente zuständig. Das Dateiformat kann anhand der Dateiendung oder bestimmten Bytefolgen in der Datei ermittelt und, ebenfalls als DateiEigenschaft, in die Topic Map übertragen werden.
Identifikation inhaltlich gleicher Dateien
Die Information, ob zwei Dateien den gleichen Inhalt besitzen, wird normalerweise
nicht vom Dateisystem zur Verfügung gestellt. Um inhaltlich gleiche Dateien ermitteln zu können, wird für jede Datei ein Hashwert über ihre Daten benötigt. Zur
Berechnung des Hashwerts einer Datei muss diese vollständig gelesen werden. Der
Hashwert wird in der Repräsentation dann wie jede andere Datei-Eigenschaft gespeichert. Wenn also zwei Dateien den selben Hashwert besitzen, werden sie trotzdem
noch durch zwei verschiedene Topics repräsentiert, die beide eine Assoziation zu
ihrem gemeinsamen Hashwert-Topic besitzen. Es wäre auch möglich, solche Topics
zu einem Topic mit mehreren Namen zu vereinigen. Dabei geht jedoch die Information verloren, welche Datei sich in welchem Verzeichnis befindet. Ein vereinigtes
Topic, welche mehrere Dateien gleichen Inhalts repräsentiert, könnte mit mehreren
Verzeichnis-Topics assoziiert sein. Dann wäre aber die Darstellung der Verzeichnishierarchie als Baum nicht mehr möglich.
Speicherort
Informationseinheiten müssen von ihrer Datenquelle geladen werden können, damit sie dem Benutzer angezeigt oder durch MIDMAY an andere Benutzer verteilt
werden können. Deshalb muss jedes Topic, das eine Informationseinheit repräsentiert, den Speicherort der Informationseinheit enthalten. Der Speicherort wird als
URL-Adresse der repräsentierten Informationseinheit angegeben und im Topic als
Subject Address gespeichert. Die Subject Address macht nicht nur die Lokalisierung
der Informationseinheit auf der Datenquelle möglich, sie dient gleichzeitig auch der
eindeutigen Identifikation des Topics (siehe Abschnitt 3.1.5 und 4.4.1). Die URLAdresse einer lokalen Datei kann nach den Regeln des File-URL-Schema11 gebildet
werden.
11
definiert in RFC 1738 - Uniform Ressource Locators, http://www.faqs.org/rfcs/rfc1738.
html
51
4 LÖSUNGSANSATZ
4.4.6. E-Mail
E-Mails werden auf einem E-Mail-Server gespeichert, und über ein Kommunikationsprotokoll verwaltet und von dort abgerufen. Die zwei am häufigsten verwendeten
Mail-Protokolle POP3 und IMAP sollen von MIDMAY unterstützt werden. Das
POP3-Protokoll ist dafür gedacht E-Mails vom Server auf den lokalen Computer
zu holen und sie anschließend auf dem Server zu löschen. IMAP unterstützt dagegen auch die Verwaltung der E-Mails auf dem Server. Die Mails bleiben auf dem
Server, damit sie von verschiedenen Computern aus über das Netz zugänglich sind.
Zur Strukturierung der E-Mails auf dem IMAP-Server werden Ordner wie in einem
Dateisystem verwendet.
Aus einem POP3 oder IMAP E-Mail-Postfach sollen die E-Mails und Datei-Anhänge
als Informationsobjekte in die Topic Map Repräsentation abgebildet werden. Bei
IMAP-Servern soll auch die hierarchische Ordnerstruktur repräsentiert werden. Bei
POP3-Servern gibt es keine hierarchische Strukturierung der E-Mails, sie liegen alle
auf einer Ebene. Wie im UML-Diagramm in Abbildung 22 zu sehen, werden die
Ordner eines IMAP-Postfachs auf gleiche Weise in die Topic-Map abgebildet, wie
die Verzeichnisse eines Dateisystems. Doch nicht nur die Ordner, sondern auch die EMails können die Rolle Container in der Container-Containee-Assoziation spielen,
falls sie angehängte Dateien (Attachments) enthalten.
Facet Has
Root
Folder
facet
«Email Facet»
«instanceOf»
Information Object
Type
«Folder Topic»
1 Container
«instanceOf»
«instanceOf»
Email
facet-root
1
Facet Has
Hierarchy Type
Container-Containee
* Containee
Container
«instanceOf»
«Email Topic»
* Containee
Attachment
1
«instanceOf»
«Attachment Topic»
Container
* Containee
Abbildung 22: Topic Map Modell für E-Mails und IMAP-Ordner
52
4 LÖSUNGSANSATZ
E-Mail-Eigenschaften
Ebenso wie bei Datei-Eigenschaften sollen auch E-Mail-Eigenschaften in der Topic
Map repräsentiert werden. Die E-Mail-Adresse des Absenders und die Adressen der
Empfänger können als Eigenschaften einer E-Mail mit dem E-Mail-Topic assoziiert
werden (siehe UML-Diagramm in Abbildung 23). In der E-Mail-Adresse ist oft auch
der Name der Person enthalten, welcher die entsprechende Adresse gehört (z. B.
"Johannes Bergmann" <bergmann@rbg.informatik.tu-darmstadt.de>). Wenn
das der Fall ist, kann ein Topic vom Typ Person mit diesem Namen erstellt, und mit
dem Email Address-Topic verbunden werden. Weiterhin kann von der Person des
Absenders eine Assoziation zur E-Mail gebildet werden, die beschreibt, dass diese
Person der Autor der E-Mail ist. Diese Object-Author-Relation kann einheitlich und
unabhängig von der Datenquelle verwendet, um auf den Autoren eines Informationsobjekts zu verweisen. So kann sie z. B. auch zur Assoziation einer Datei mit
ihrem Autor verwendet werden, falls in der Datei der Autor als Metainformation
gespeichert ist (siehe Abschnitt 4.4.5 Metainformationen).
Person
Object - Author
Relation
«instanceOf»
«Person»
Author *
1 Person
* Information Object
«Email»
Object - Sender
Relation
* InformationObject
* InformationObejct
Sender 1
Receiver *
Person - Address
Relation
* Email Address
«Email Address»
Email Address
«instanceOf»
Object - Receiver
Relation
Abbildung 23: Topic-Map Struktur für E-Mail Eigenschaften
Angehängte Dateien
Jeder Datei-Anhang wird als eigenes Topic vom Typ Attachment modelliert. Der
Name des Anhangs kann aus der E-Mail ermittelt werden. Besitzt der Anhang
ein bekanntes Dateiformat, können vorhandene Metainformationen wie Titel“ und
”
Autor“ aus der angehängten Datei auf die gleiche Weise wie bei der Datei eines
”
Dateisystems extrahiert werden.
53
4 LÖSUNGSANSATZ
Inhaltliche Identifikation
Damit eine angehängte Datei als inhaltlich identisch zu einer anderen Datei identifiziert werden soll, muss wie bei der Datei eines Dateisystems ihr Hashwert gebildet
und mit dem Attachment-Topic assoziiert werden. Nachteilig ist, dass für die Bildung
eines Hashwerts der Anhang vom E-Mail-Server vollständig heruntergeladen werden
muss. Allerdings ist zur Extraktion von Metainformationen das Herunterladen der
Datei sowieso nötig.
Speicherort
Für jede Informationseinheit einer Datenquelle muss eine URL-Adresse gebildet
werden können, die es erlaubt die entsprechende Informationseinheit auf der Datenquelle wiederzufinden. Bei einem E-Mail-Server als Datenquelle muss eine URL
für jede E-Mail und jeden Datei-Anhang gebildet werden. Für IMAP gibt es ein
URL-Schema12 , nach dem diese URLs gebildet werden können. Die URL einer EMail enthält die Adresse des Servers, den Ordner, in dem die E-Mail gespeichert ist
und eine eindeutige ID der E-Mail (Message-ID). Für die URL eines Datei-Anhangs
wird zusätzlich noch der relevante Teil der E-Mail (Section) angegeben. URLs für
POP3 E-Mails und Datei-Anhänge können auf gleiche Weise konstruiert werden wie
die IMAP-URLs.
4.4.7. Eigenschafts-Hierarchien
Eine Eigenschafts-Hierarchie ermöglicht es, Informationsobjekte unabhängig von ihrem Speicherort auf ihrer Datenquelle über eine ihrer Eigenschaften aufzufinden
(siehe Abschnitt 4.4.4). Durch eine Eigenschafts-Hierarchie werden die Eigenschaften der repräsentierten Informationseinheiten strukturiert. Für die Visualisierung
der Repräsentation kann der Wurzelknoten einer Eigenschafts-Hierarchie als Einstiegspunkt verwendet werden. Vom Wurzelknoten aus sollte der Benutzer zu den
verfügbaren Eigenschaften navigieren können.
Abbildung 24 zeigt eine Eigenschafts-Hierarchie für die Eigenschaft Dateiformat“.
”
Die Topics PDF“, DOC“, JPG“ und PNG“ sind Eigenschafts-Topics, die ein
”
”
”
”
bestimmtes Dateiformat repräsentieren. Die Klassifizierung der Informationsobjekte erfolgt über Eigenschafts-Assoziationen, welche Datei-Topics mit EigenschaftsTopics verbinden. Eine Hierarchie nach dem Hierarchical Classification Pattern
müsste eigentlich die Classified as“-Assoziation für die Klassifikation der Infor”
mationsobjekte verwenden. Wird diese Assoziation aber anstelle der verschiedenen Eigenschafts-Assoziationen verwendet, geht Information verloren. Eine mögliche Lösung wäre die Definition eines gemeinsamen Supertyps für KlassifizierungsAssoziationen, so wie es den Hierarchical Relation Type für hierarchische Assoziatio12
definiert in RFC 2192 - IMAP URL Scheme, http://www.faqs.org/rfcs/rfc2192.html
54
4 LÖSUNGSANSATZ
Eigenschafts-Hierarchie
«Properties Facet»
facet
Facet Has
Hierarchy Type
facet-root
File Type
File,
Attachment,...
Supercategory
Supercategory - Subcategory
«Information Object Type»
Subcategory
Information Object File Type
Document
Image
«instanceOf»
« Information Object Topic»
Information Object File Type
PDF
DOC
JPG
PNG
Abbildung 24: Eigenschafts-Hierarchie für die Eigenschaft Dateiformat“ (File”
Type)
nen im Hierarchical Classification Pattern gibt. So könnten bestimmte Assoziationen
als Klassifizierungs-Assoziationen typisiert werden. Es ist aber auch eine einfachere
Lösung möglich, die als implizite“ Klassifikation bezeichnet werden kann und hier
”
verwendet wird. Dabei werden Topics, die durch eine beliebige Assoziation mit einem
Topic innerhalb der Hierarchie verbunden sind, als Instanzen des Hierarchie-Topics
betrachtet. Damit ist jede Assoziation potenziell eine klassifizierende Assoziation. Sie
wird als klassifizierende Assoziation interpretiert, sobald eines ihrer teilnehmenden
Topics in einer Hierarchie vorkommt. Ausgenommen werden nur die hierarchischen
Assoziationen, welche der Beschreibung der Hierarchie dienen.
Im Beispiel in Abbildung 24 kann die Eigenschafts-Hierarchie bereits vor der Extraktion der Topic Map einer Datenquelle gebildet werden. Dazu werden in der
Eigenschafts-Hierarchie eine Menge möglicher Eigenschafts-Topics ( PDF“, DOC“,
”
”
JPG“,...) definiert. Jedes Eigenschafts-Topic muss einen Subject Indicator besit”
zen, durch den es in beiden Topic Maps als identisch identifiziert werden kann.
Die Eigenschafts-Topics einer abgebildeten Topic Map und die der EigenschaftsHierarchie werden durch den Merging-Prozess vereinigt.
Wenn die Eigenschaften erst während der Abbildung einer Datenquelle bekannt werden, sind Eigenschafts-Hierarchie und extrahierte Topic Map nicht mehr unabhängig
voneinander. Die Hierarchie muss während des Abbildungsvorgangs ergänzt werden.
Soll z. B. die Absender-Adresse einer E-Mail als Eigenschaft in einer Hierarchie vorkommen, dann muss diese E-Mail-Adresse in der Hierarchie als Kind-Element eines
Email Sender“-Topics eingeordnet werden (siehe Abbildung 25). Andererseits ist
”
die Information, dass diese E-Mail-Adresse als Absender-Adresse verwendet wurde,
eigentlich schon in der Rollenspezifikation Sender der Information Object-Sender Assoziation vorhanden. Eine Ergänzungen der Hierarchie während der Abbildung
wäre nicht notwendig, wenn Topics, welche die Rolle Sender spielen, in einer Hierarchie automatisch als Kindelemente des Sender“-Topics aufgefasst werden. Eine
”
55
4 LÖSUNGSANSATZ
Visualisierungs-Komponente für Topic Maps müsste also Hierarchien auf diese Weise dynamisch erweitern. Da eine solche Visualisierung jedoch noch nicht existiert,
muss vorerst auf die Methode zurückgegriffen werden, Hierarchien während des Abbildungsvorgangs zu erweitern.
Diese Assoziation muss erstellt
werden, sobald die E-Mail-Adresse
eines Absenders in die Topic Map
übertragen wird.
Communication
Partners
Hierarchy Relation Type
«instanceOf»
Supercategory
Supercategory - Subcategory
Subcategory
Email Sender
Email Receiver
Information Object Sender
«Email»
Information Object
Sender
«Email Address»
Abbildung 25: Erweitern einer Eigenschafts-Hierarchie während des Abbildungsvorgangs
4.4.8. Modellierung weiterer Datenquellen
In den vorhergehenden Abschnitten wurde beschrieben, wie die Informationen eines
Dateisystems und eines E-Mail-Postfachs in die Topic-Map-Repräsentation abgebildet werden können. Die Topics wurden dabei möglichst allgemein definiert, so dass
sie sich auch für andere Datenquellen eignen, auf denen Dateien bzw. Nachrichten gespeichert sind. Weiterhin geht das generische Modell von hierarchisch strukturierten und adressierbaren Informationseinheiten aus, wie es bei Dateisystemen,
IMAP-Mail-Servern und Protokollen für den Dateizugriff (z. B. für FTP, HTTP oder
WebDAV) der Fall ist. Dennoch können anders strukturierte Datenquellen, wie z. B.
Terminkalender oder Datenbanken auf die hierarchische Struktur des generischen
Modells abgebildet werden.
Eindimensional strukturierte Datenquellen (Listen)
Aus einer Listen kann eine Hierarchie erstellt werden, in der sich alle Blätter direkt
unterhalb der Wurzel befinden. Dazu wird eine Wurzel definiert, und jedes Element der Liste als Kind der Wurzel eingeordnet. Soll die Ordnung der Liste bei der
Abbildung erhalten bleiben, kann diese entweder durch zusätzliche Assoziationen
zwischen den Elementen oder durch einen Variantname als Sortierschlüssel (siehe
Abschnitt 3.1.1) repräsentiert werden. Als Beispiel kann eine Liste von Terminen in
einem Terminkalender betrachtet werden. Als Wurzelknoten wird ein Knoten mit
dem Namen Termine definiert. Alle Termin-Topics werden als Kinder dieses Knotens eingeordnet. Die Reihenfolge der Termin-Topics kann durch einen Variantname
definiert werden, der das Datum des Termins in einer Form angibt, bei der die alphabetische Sortierung der zeitlichen Sortierung entspricht (z. B. 2005.09.27 11:30“
”
56
4 LÖSUNGSANSATZ
für den 27.September 2005 um 11:30 Uhr). Die Termin-Topics können wie auch
Datei- und E-Mail-Topics durch Assoziationen mit Eigenschafts-Topics verbunden
werden. Als Eigenschafts-Topics eines Termins eigenen sich z. B. die teilnehmenden
Personen, die E-Mails dieser Personen oder die Datei-Topics der für den Termin
benötigten elektronischen Dokumente.
Zweidimensional strukturierte Datenquellen (Tabellen)
Zweidimensionale Strukturen, wie z. B. Tabellen einer relationalen Datenbank,
können ebenfalls in eine Hierarchie abgebildet werden. Die Informationen einer Tabelle sind als Tupel (Datensätze) in den Zeilen der Tabelle gespeichert. Jeder Datensatz wird als Informationseinheit der Tabelle gesehen und in ein Datensatz-Topic
abgebildet. Dabei werden Information von einem oder mehreren Feldern des Datensatzes verwendet. Weitere Felder des Datensatzes können als Eigenschaften des
Datensatz-Topics modelliert werden. Die Datensatz-Topics bilden zusammen eine
Liste, die wie oben beschrieben in eine Hierarchie abgebildet wird.
ID
0
1
2
Name
"Smith"
Vorname
Adresse
"Alice
...
E-Mail
Geburtstag
"alice@xyz.com" 27.09.1972
Bild
...
Person - Address
Relation
E-Mail-Adress
Alice Smith
Person
Person
alice@xyz.com
Person - Birthday
Relation
Birthday
«Variant»
"Smith, Alice"
«Parameter»
Sort
«Scope»
27.09.1972
«Base Name»
"1972.09.27"
Abbildung 26: Abbildung eines Datensatzes in eine Topic-Map
Das Beispiel in Abbildung 26 zeigt, wie aus dem Datensatz einer Tabelle mit Personendaten ein Topic gebildet wird. Aus den Feldern Vorname“ und Nachname“
”
”
wird das Datensatz-Topic erstellt und die Felder E-Mail“ und Geburtstag“ werden
”
”
als Eigenschafts-Topics abgebildet. Es müssen nicht alle Felder abgebildet werden,
57
5 IMPLEMENTIERUNG
da der komplette Datensatz auf Wunsch durch MIDMAY aus der Tabelle geholt
werden kann. Außer der hier gezeigten Möglichkeit gibt es noch weitere Varianten
die Tabelle als Topic Map abzubilden. Welche Variante gewählt wird, hängt davon ab, welche Art von Informationen die Tabelle als Datenquelle hauptsächlich
liefern soll. Im Beispiel wird sie als Quelle für personenbezogene Daten verwendet.
Sie könnte aber auch ausschließlich als Quelle für Bilder von Personen verwendet
werden. In diesem Fall wäre nicht der gesamte Datensatz das Informationsobjekt,
sondern nur das Bild. Als einziges Eigenschafts-Topic könnte dann die Person mit
dem Bild-Topic assoziiert werden.
Auch mehrdimensional strukturierte Datenquellen können auf die oben beschriebene
Weise abgebildet werden, da sie in relationale Modelle übertragen werden können.
Mehrdimensionale Datensichten werden z. B. im Bereich Data-Warehousing zur Analyse von Kennzahlen benutzt. Die Speicherung der Daten erfolgt aber in relationaler
Form. Die Aufgabe bei der Abbildung mehrdimensional strukturierter Informationen
in eine Hierarchie besteht darin, eine Dimension auszuwählen, deren Werte als eigene Informationsobjekte betrachtet werden können. Es wird nur eine der möglichen
Sichten für die Abbildung der Informationen verwendet. Während bei der Abbildung
einfach strukturierter Datenquellen durch die Modellierung von Eigenschaften und
Metainformationen zusätzliche Sichten auf die Informationsobjekte entstehen, muss
bei komplexer strukturierten Datenquellen ein Verlust an Abfragemöglichkeiten in
Kauf genommen werden.
5. Implementierung
Durch MIDMAY sollen die Informationseinheiten verschiedener Datenquellen in eine
Topic Map abgebildet werden, so dass eine einheitliche Repräsentation der verteilt
gespeicherten Informationen entsteht. Eine Software-Architektur zur Erstellung dieser Repräsentation wurde in Abschnitt 4.1 beschrieben. Hier wird die Realisierung
dieser Software-Architektur mit der Programmiersprache Java vorgestellt. Um Topic
Maps als Format der Repräsentation nutzen zu können, musste eine geeignete Topic
Map API ausgewählt und verwendet werden. Für die in Abschnitt 4.4.3 vorgestellten
Topic Map Patterns, welche zur Modellierung von hierarchischen Strukturen verwendet werden, wurde eine eigene API definiert und implementiert. Das Data Retrieval
Module wurde als Framework implementiert, das die Anbindungvon unterschiedlicher Datenquellen an MIDMAY ermöglicht. Um einen bestimmten Datenquelle
zu unterstützen, muss ein Extraktor implementiert werden, der die Informationen
dieser Datenquelle in eine Topic Map abbilden kann. Die Implementierungen des
Unified Representation Module sorgt für die Verwaltung der einzelnen Extraktoren,
vereinigt ihre erstellten Topic Maps zu einer Repräsentation und realisiert die in
58
5 IMPLEMENTIERUNG
Abschnitt 4.1.2 beschrieben Schnittstellen zur Bearbeitung und Abfrage der Repräsentation.
5.1. Topic Map APIs für Java
Um Topic Maps mit einer Programmiersprache bearbeiten zu können, wird eine
Topic-Map-Engine mit einer dazugehörigen Topic-Map-API benötigt. Eine TopicMap-API definiert die Funktionen, mit denen eine Topic Map bearbeitet werden
kann. Eine Topic-Map-Engine verwaltet eine Datenstruktur die dem Topic Map Datenmodell [13] entspricht und implementiert die von der API definierten Funktionen.
Zunächst werden, als Open-Source verfügbare Topic-Map-APIs und -Engines für die
Programmiersprache Java vorgestellt. Abschließend wird begründet, warum TM4J
als Topic-Map-Engine für die Implementierung der beiden MIDMAY-Module URM
und DRM verwendet wurde.
5.1.1. TMAPI
TMAPI steht für Topic Map Application Programming Interface“ und ist ei”
ne Schnittstellendefinition für die Verarbeitung von Topic Maps13 . Die definierte
Schnittstelle soll von verschiedenen Topic-Map-Engines als gemeinsames Topic-MapInterface implementiert werden. Damit soll dem Programmierer von Topic-Map Anwendungen eine einzige einheitliche Schnittstelle zur Verfügung stehen, die von der
konkreten Implementierung des Topic-Map-Datenmodells unabhängig ist. Die in der
TMAPI Spezifikation definierte Schnittstelle wird als Java-Interfaces zur Verfügung
gestellt.
5.1.2. TinyTIM
Die Topic-Map-Engine tinyTIM14 implementiert die TMAPI-Schnittstelle. Da
tinyTIM sich auf die in TMAPI definierten Funktionen beschränkt, ist es eine klei”
ne“ Implementierung die mit wenig Arbeitsspeicher auskommt. Allerdings sind in
TMAPI nur die grundlegenden Funktionen zur Bearbeitung einer Topic-Map definiert, so dass komplexere Operationen, wie z. B. das Extrahieren eines Teils einer
Topic Map, selbst programmiert werden müssten. Bereits verfügbar sind TMAPIUtilities zum Einlesen von XTM-Dateien und zur XTM-Serialisierung, die mit
tinyTIM zusammen verwendet werden können.
13
14
TMAPI Webseite: http://www.tmapi.org
tinyTIM Webseite: http://tinytim.sourceforge.net
59
5 IMPLEMENTIERUNG
5.1.3. TM4J
Die Schnittstelle der Topic-Map-Engine TM4J15 bietet Funktionen zur Erstellung
und Bearbeitung von Topic Maps. Die TM4J-Engine kann über die TMAPI Schnittstelle verwendet werden, bietet aber auch viele weitere Funktionen. So gibt es z. B.
Hilfsklassen, mit denen ein Ausschnitt einer Topic Map extrahiert werden kann oder
mit denen eine Topic Map auf bestimmte Weise durchlaufen werden kann. TM4J
kann Topic Maps als XTM-Datei speichern und in XTM- oder LTM-Syntax gespeicherte Topic Maps einlesen. Es ist aber auch eine persistente Speicherung der Topic
Maps in einer Datenbank möglich. Dafür kann entweder die objektrelationale Datenbank Ozone16 oder eine relationale Datenbank über Hibernate17 eingesetzt werden.
Außerdem bietet TM4J Query-Funktionen unter Benutzung der Abfragesprache Tolog18 .
5.1.4. Verwendete API
In der Implementierung wurde die TM4J Topic-Map-Engine und -Schnittstelle verwendet, da so auf den großen Funktionsumfang von TM4J zurückgegriffen werden kann. TMAPI bietet als Vorteil zwar die Austauschbarkeit der Topic-MapEngine, allerdings kommen zur Zeit nur tinyTIM und TM4J als Engine in Frage.
Die ausschließliche Verwendung von TMAPI als Topic-Map-Schnittstelle hätte die
Implementierung aufwändiger gemacht, da die Programmierung verschiedener Hilfsfunktionen zur Bearbeitung wiederkehrender Aufgaben notwendig gewesen wäre. In
TM4J existieren bereits viele solcher Hilfsfunktionen. Außerdem besteht die Möglichkeit die Schnittstellen zur persistenten Speicherung von Topic Maps zu nutzen
oder die Abfrage-Sprache Tolog zu verwenden. Die Verwendung von TM4J auf der
MIDMAY-Homebase schließt es nicht aus, auf einem MIDMAY-Client eine andere
Topic-Map-Engine zu verwenden. So wäre für einen mobilen Client möglicherweise tinyTIM geeignet, da tinyTIM nicht wie TM4J von weiteren Java-Bibliotheken
abhängig ist und damit zur Laufzeit weniger Speicher belegt.
5.2. API für Topic Map Patterns
Das Modell zur Abbildung der Datenquellen in eine Topic Map aus Abschnitt 4.4.4
sieht vor, dass für jede Datenquelle eine hierarchische Struktur mit dem Hierarchical
15
TM4J Webseite: http://www.tm4j.org
Ozone ist ein Java basiertes objektrelationales Datenbankmanagementsystem ( http://www.
ozone-db.org)
17
Hibernate ist eine Software-Komponente für die Abbildung von Java-Objekten in ein relationales
SQL-Schema (http://www.hibernate.org)
18
Tolog ist eine von Ontopia entwickelte Abfragesprache für Topic Maps (http://www.ontopia.
net/topicmaps/materials/tolog.html)
16
60
5 IMPLEMENTIERUNG
Classification Pattern und dem Faceted Classification Pattern aufgebaut wird. Auch
die Eigenschaften der Informationsobjekte sollen mit Hilfe dieser Patterns hierarchisch strukturiert werden können. In der Implementierung werden deshalb sowohl
die in den Patterns definierten Topics als auch Funktionen zur Bildung von Facets
und Hierarchien benötigt.
Für die Verwendung von Topic Map Patterns wie Hierarchical Classification oder
Faceted Classification wurde eine eigene API definiert. Für jedes Pattern werden
Funktionen angeboten, mit denen auf einfache Weise eine Topic Map erstellt und
verarbeitet werden kann, welche die Topics und Strukturen des Patterns enthält.
Die Verwendung einer API für Topic Map Patterns garantiert außerdem, dass die
vom Pattern vorgegebenen Strukturen in der Topic Map eingehalten werden, und
dass die spezifischen Pattern-Topics in einer Topic Map nur einmal angelegt werden.
In der Pattern-API wird ein Pattern als Java-Interface definiert. Eine Factory-Klasse
ist dafür zuständig, für eine gegebene Topic Map ein Pattern-Objekt zu erstellen (Abbildung 27). Pattern-Objekte können wiederum eine createXXXTool()Factory-Methode besitzen, mit der ein Objekt zur Bearbeitung einer Ausprägung
des Patterns erstellt wird. Beispielsweise ist ein HierarchyTool-Objekt für einen
bestimmten hierarchischen Assoziationstyp verantwortlich, während ein HierarchyObjekt auf allen hierarchischen Assoziationen der Topic Map arbeitet. Mit einem
HierarchyTool-Objekt kann eine konkrete Hierarchie mit einem bestimmten Assoziationstyp aufgebaut werden. Welche hierarchischen Assoziationstypen in einer
Topic Map vorhanden sind, kann dagegen mit dem Hierarchy-Objekt ermittelt
werden.
PatternFactory
+createPattern(Pattern, TopicMap)
«creates»
«Interface»
Pattern
+setTopicMap(TopicMap workMap)
+ ...
«Interface»
Hierarchy
+createHierarchyTool(relationshipType: Topic, ...):
HierarchyTool
+getHierarchicalRelationshipTopics(): Collection
«creates»
+ ...
«Interface»
HierarchyTool
+classifyAs(t: Topic, classTopic: Topic)
+getSuperordinateTopic(subTopic: Topic): Topic
+createParentChildRelation(aParent, aChild: Topic)
+ ...
«Interface»
FacetedClassification
+FacetTool createFacetTool(...)
+Collection getAllFacets()
+Topic getFacetRootOf(aFacet:Topic)
«creates»
+ ...
«Interface»
FacetedClassificationTool
+getFacet(): Topic
+getFacetRoot(): Topic
+getFacetHierarchyType(): Topic
+ ...
Abbildung 27: Klassendiagramm der API für Topic Map Patterns (Ausschnitt)
61
5 IMPLEMENTIERUNG
5.3. Data Retrieval Modul
Das Data Retrieval Modul hat die Aufgabe, auf unterschiedliche Datenquellen zuzugreifen und Informationen über die dort gespeicherten Informationseinheiten zu
liefern. Um unterschiedliche Datenquellen integrieren zu können, wurde ein Framework für Extraktoren erstellt. Ein Extraktor realisiert den Zugriff auf eine Datenquelle und die Abbildung der dort gespeicherten Informationseinheiten in eine
Topic-Map-Repräsentation. Eine Extraktor-Implementierung ist jeweils für einen
bestimmten Datenquellentyp zuständig. Auf Basis des Frameworks wurde ein Extraktor für Dateisysteme und ein Extraktor für POP3- und IMAP-Mail-Server implementiert. Der Zugriff auf das Dateisystem wurde mit der java.io API realisiert.
Für den Mail-Zugriff wird die JavaMail API verwendet. Ein weiterer Extraktor zeigt
exemplarisch, wie mit der Open-Source API iCal4j Termine im iCal-Format in die
Repräsentation aufgenommen werden können.
Für die Implementierung neuer Extraktoren kann entweder die Klasse
AbstractExtractor oder TreeSourceExtractor erweitert werden. TreeSourceExtractor bietet bereits eine Implementierung der extract()-Methode des
Extractor-Interface, mit der hierarchisch strukturierte Datenquellen abgebildet werden können. Diese Klasse wird auch von FilesystemExtractor und
EmailExtractor als Basisklasse verwendet. TreeSourceExtractor arbeitet mit
Node Objekten, welche einen Knoten in der Struktur der Datenquelle repräsentieren. Ein Node-Objekt muss die Methode getChildren() implementieren, mit der
die Kindelemente des Knotens ermittelt werden können. Abbildung 28 zeigt die
Klassen des Extractor-Frameworks und der Implementation eines Extraktors für
Dateisysteme.
Im folgenden wird beschrieben, welche Aufgaben in welchen Klassen implementiert
werden. Implementierungen der Interfaces werden am Beispiel des DateisystemExtraktors erläutert.
5.3.1. Zugriff auf die Datenquelle
Das FilesystemExtractor-Objekt hat die Aufgabe ein Node-Objekt als Startknoten für die Extraktion zu erstellen. Von dem Startknoten aus kann der
TreeSourceExtractor die Baumstruktur der Datenquelle durchlaufen. Bei entfernten Datenquellen muss zuvor eine Verbindung zur Datenquelle aufgebaut und
nach der Extraktion wieder geschlossen werden. Als Startknoten bei Dateisystemen
wird ein DirectoryNode-Objekt erstellt. Als Kindelemente gibt die getChildren()Methode für jedes Unterverzeichnis eine DirectoryNode und für jede Datei eine
FileNode zurück.
62
5 IMPLEMENTIERUNG
«Interface»
Extract
+extract()
+getInformationStream(subjectIdentifier: String): InputStream
Node
+getChildren(): [ ]Node
+accept(v: Visitor, t: Topic)
...
AbstractExtractor
...
FileNode
+getName()
...
DirectoryNode
+getName()
...
TreeSourceExtractor
#getRootNode(): Node
#createTopicInformation(n: Node, t:Topic)
...
calls v.visit(t)
rootNode
calls n.accept(informationCreator, t)
FilesystemExtractor
+createTopicInformation(n: Node, t: Topic)
...
«Interface»
Visitor
informationCreator
«Interface»
FileInformationVisitor
+visit(FileNode, Topic)
+visit(DirectoryNode, Topic)
Abbildung 28: Extractor-Framework
Extraktors
EmailExtractor
...
FileInformationCreator
mit
Implementierung
des
Dateisystem-
5.3.2. Extraktion von Metadaten
Um die Eigenschaften und Metainformationen einer Informationseinheit zu ermitteln müssen verschiedene APIs verwendet werden, die spezifisch Funktionen für die
Datenquelle oder für ein bestimmtes Datenformat bieten. In einem Dateisystem
kann z. B. der Dateiname oder das Erstellungsdatum einer Datei mit dem java.ioPackage ermittelt werden. Der Autor einer PDF-Datei muss mit einer geeigneten
externen API extrahiert werden. Zur Extraktion der Metadaten einer MS-WordDatei wird wiederum eine andere API benötigt. Die Benutzung verschiedener APIs
zur Ermittlung der Eigenschaften einer Informationseinheit wird im Node-Objekt
gekapselt. Die Implementierung eines Node-Objekts kann verschiedene Methoden
anbieten, welche zu der Informationseinheit auf der Datenquelle bestimmte Eigenschaften und Metainformationen zurückliefern.
Die APIs zur Extraktion verschiedener Dateieigenschaften wurden im Package
documeta gebündelt (Abbildung 29). Um das Format einer Datei zu ermitteln wird
das metadata-Package19 von Marco Schmidt verwendet. Die Dateiformate, die er19
ffident - file format identification library: http://schmidt.devlib.org/ffident/index.html
63
5 IMPLEMENTIERUNG
kannt werden sollen, können in der Datei (formats.txt) zusammen mit ihrem spezifischen Bytemuster (so genannte Magic Bytes“) eingetragen werden. Die Funk”
tionalität wurde erweitert, so dass für Dateiformate ohne spezifisches Bytemuster
die Endung des Dateinamens zur Identifikation verwendet wird. Metadaten, die innerhalb bestimmter Dateien gespeichert sind, können ebenfalls über das documeta-Package extrahiert werden. Es wurde eine gemeinsame Schnittstelle definiert,
über die unterschiedliche APIs für verschiedene Dateiformate eingebunden werden
können. Mit der derzeitigen Implementierung können Autor und Titel von MSOffice- und PDF-Dateien bestimmt werden. Um Metadaten aus MS-Office-Dateien
zu extrahieren, wurde die Jakarta POI 20 -API der Apache Software Foundation verwendet. Für PDF-Dateien wurde iText 21 von Bruno Lowagie eingebunden.
documeta
DocumentMetadata
+getDocumentType(fileName: String): String
+createRetriever(documentType: String,
documentInputStream: InputStream): MetadataRetriever
«creates»
«Interface»
MetadataRetriever
+getMetadata(): HashMap
«creates»
OleInformation
«uses»
«uses»
metadata
Jakarta POI
PdfInformation
«uses»
iText
Abbildung 29: Das documeta-Package zur Extraktion von Metadaten
5.3.3. Information Mapping
Für das Information Mapping“ des Dateisystem-Extraktors ist die Klasse
”
FileInformationCreator verantwortlich. Sie enthält für jeden Node-Typ der
Extraktor-Implementierung eine eigene visit-Methode. Innerhalb der visitMethoden werden die Eigenschaften des Node-Objekts als Topics und Assoziationen in die Topic Map übertragen. Durch die Node-Objekte ist die Klasse
FileInformationCreator unabhängig davon, auf welche Weise und mit welchen
APIs die Metadaten ermittelt werden. Mit dem Software-Design-Pattern Visitor (siehe Gamma et al. [6]) erfolgt die Abbildung unterschiedlicher Typen von
20
21
Jakarta POI - Java API To Access Microsoft Format Files: http://jakarta.apache.org/poi/
iText: http://www.lowagie.com/iText/
64
5 IMPLEMENTIERUNG
Informationseinheiten jeweils in einer eigenen Methode. Das Visitor-Pattern ist
dafür zuständig, dass für einen bestimmen Node-Typ die passende visit-Methode
aufgerufen wird. Dadurch wird eine einzelne große Methode vermieden, welche
die verschieden Node-Typen mit Hilfe von Fallunterscheidungen unterschiedlich
behandeln müsste. Die visit-Methoden für den Dateisystem-Extraktor und die
Methoden, welche für ihren Aufruf zuständig sind, können der Abbildung 28
entnommen werden.
5.3.4. Information Object Retrieval
Die Schnittstelle, mit der ein Informationsobjekt vollständig von der Datenquelle auf
die MIDMAY-Homebase übertragen werden kann, ist im Extractor-Interface definiert. Die Methode getInformationStream nimmt als Argument einen SubjectIdentifier entgegen. Dieser SubjectIdentifier gibt das Topic an, dessen korrespondierende
Informationseinheit von der Datenquelle geladen werden soll. Außerdem ermöglicht
er es, diese Informationseinheit auf der Datenquelle zu lokalisieren. Ein ExtractorObjekt muss innerhalb der getInformationStream-Methode zuerst überprüfen, ob
das ausgewählte Topic überhaupt von diesem Extraktor erstellt wurde. Wenn das der
Fall ist, wird von der getInformationStream-Methode ein java.io.InputStream
zurückgegeben, mit dem die einzelnen Bytes des Informationsobjekts gelesen werden
können.
5.4. Unified Representation Modul
Mit dem Unified Representation Module werden die Extraktoren verwaltet und die
erstellten Topic Maps zu einer Repräsentation aller Datenquellen vereinigt. Das
Modul bietet eine Schnittstelle, mit denen andere Software-Komponenten auf die
Repräsentation zugreifen und diese ergänzen können. Mit dieser Schnittstelle können
auch Zugriffs- und Bearbeitungsfunktionen für MIDMAY-Clients realisiert werden.
5.4.1. Konfiguration der Extraktoren
Die Konfiguration der Extraktoren wird über Property-Dateien gesteuert. Für jede
Datenquelle, die in die Repräsentation abgebildet werden soll, wird eine PropertyDatei angelegt. Eine solche Datei enthält in jeder Zeile Parameter-Wert-Zuweisungen
in der Form Parameter = Wert. Abbildung 30 zeigt den Aufbau der Konfigurationsdateien. In jeder Konfigurationsdatei wird die Extractor-Klasse (class = ...)
angegeben, die für die Abbildung der Datenquelle zuständig ist. Auch der Ort, an
dem der Extraktor die Topic Map speichern soll, muss immer angegeben werden
(tmbase = ...). Ansonsten werden je nach Datenquelle unterschiedliche Parameter
65
5 IMPLEMENTIERUNG
zum Herstellen der Verbindung benötigt. Welche anderen Parameter noch angegeben
werden müssen hängt deshalb von der Extractor-Implementierung ab.
class = extract.filesystem.FilesystemExtractor
tmbase = <Ort der TopicMap>
root = <Wurzelverzeichnis der abzubildenden Dateien>
(a) Dateiysystem
class = extract.email.EmailExtractor
protocol = imap | pop3
host = <Host-Adresse des Mailservers>
port = <Port des Mailservers>
username = <Benutzername des Mail-Accounts>
password = <Passwort des Mail-Accounts>
[ssl]
[sslAuthentication
trustStore = <Java Trust-Store>
trustStorePassword = <Passwort des Trust-Store>]
(b) Mail-Server
class = extract.ical.IcalExtractor
file = <Pfad der iCal-Datei>
(c) iCal -Termine
Abbildung 30: Aufbau der Konfigurationsdateien
Optionale Parameter sind hier in eckigen Klammern ( [“, ]“) notiert. So kann z. B.
” ”
die Kommunikation mit einem Mail-Server über SSL verschlüsselt werden, indem der
Parameter ssl verwendet wird. Allerdings wird dabei keine Authentifizierung des
Mail-Servers vorgenommen. Für die SSL-Authentifizierung des Mail-Servers ist es
notwendig das Server-Zertifikat in einen Java Trust-Store zu importieren. So kann
vom Programm das bei Verbindungsaufbau übertragene Server-Zertifikat mit dem
Zertifikat im Trust-Store verglichen werden. Für die SSL-Authentifizierung müssen
in der Konfigurationsdatei die Paramater sslAuthentication, trustStore und
trustStorePassword angegeben werden.
Der Extraktor für iCal -Termine benötigt als Parameter die iCal -Datei, in der die
Termine gespeichert sind (Abbildung 5.4.1). Verschiedenen Kalender-Anwendungen
wie Mozilla Sunbird, KOrganizer (für Linux) oder iCal (für Mac OS) können dort
eingetragene Termine als iCal -Datei exportieren. In dieser Datei wird jeder Termine
66
5 IMPLEMENTIERUNG
als Ereignis (in iCal: VEVENT) repräsentiert. Jedes Ereignis der iCal -Datei wird durch
den iCalExtraktor als einzelnes Topic in die Repräsentation übertragen.
Die Konfigurationsdateien werden beim Start der MIDMAY-Homebase eingelesen
und entsprechende Extractor-Objekte erstellt und konfiguriert. Eine Konfigurationsdatei kann auch zur Laufzeit erneut eingelesen werden, damit Änderungen an
der Konfiguration während dem Betrieb der MIDMAY-Homebase möglich sind.
5.4.2. Extraktoren und InputMaps
Die MIDMAY-Repräsentation wird nicht nur durch die Extraktoren um Informationen in Form von Topic Maps erweitert. Auch andere Software-Komponenten können
Topic Maps bearbeiten und sie zur Repräsentation hinzufügen (siehe Abbildung 14 in
Abschnitt 4.1.2). Dazu wurde das Interface InputMap definiert. Über diese Schnittstelle können Software-Module ihre eigene Topic Map bereitstellen.
Für die Verwaltung der Extractor- und InputMap-Objekte ist die Klasse
RepresentationManager zuständig (Abbildung 31). Jedes Extractor- und
InputMap-Objekt wird beim RepresentationManager registriert. Die Abbildung
bestimmter Datenquellen kann vom RepresentationManager zu beliebigen Zeitpunkten veranlasst werden. Die Extraktoren können einzeln, sequentiell oder parallel
als eigene Threads gestartet werden. Über die Schnittstellen ExtractorController
und InputMapController, benachrichtigen die Extractor- bzw. InputMap-Objekte
den RepresentationManager darüber, dass ihre Topic Map dafür bereit ist, in die
gesamte Repräsentation aufgenommen zu werden.
Durch die InputMap-Schnittstelle ist es für andere Software-Module möglich, ihre eigenen Objekte und Konzepte in die MIDMAY-Repräsentation aufzunehmen.
Auch die Client-Schnittstelle zur Bearbeitung der Benutzer-Topic-Map kann mit
einer InputMap-Klasse implementiert werden. Zur Demonstration wurde die Klasse UserInputMap erstellt. Mit ihr können Projekt-Topics sowie Assoziationen zwischen Informationsobjekten und Projekten angelegt und auch wieder gelöscht werden können.
5.4.3. Vereinigen der Topic Maps
Die einzelnen Topic Maps, welche von Extractor- und InputMap-Objekten erstellt
werden, müssen zu einer einzigen Repräsentation vereinigt werden. Die Vereinigung
wird vom RepresentationManager-Objekt als Topic-Map-Merging-Prozess veranlasst. Dabei werden Topics vereinigt, die das selbe Subject repräsentieren. Das TopicNaming-Constraint wird nicht berücksichtigt, da sonst viele Topics, die nicht das
gleiche Subject repräsentieren, anhand des Namens vereinigt würden. Wie im Bei-
67
5 IMPLEMENTIERUNG
«Interface»
ManagedMap
+getTopicMap(): TopicMap
+getTopicMapSource(): TopicMapSource
«Interface»
Extractor
+extract()
...
«Interface»
InputMap
+commitNewMap()
+commitInputMap()
AbstracManagedMap
...
AbstractExtractor
...
«Interface»
ExtractorController
+extractionFinished(Extractor)
AbstractInputMap
...
«Interface»
InputMapController
+inputMapExtended(InputMap, newMap: ManagedMap)
+inputMapChanged(changedInputMap: InputMap )
RepresentationManager
+registerExtractor(Extractor)
+registerInputMap(InputMap)
+startAllExtractors()
...
Abbildung 31: Verwaltung von Extractor- und InputMap-Objekten durch die
RepresentationManager-Klasse
spiel in Abschnitt 3.1.4 gezeigt wird, ist es nicht sinnvoll die Eindeutigkeit nicht
eindeutiger Namen zu erzwingen.
Von der Topic-Map-Engine TM4J wird mit dem UnifiedTopicMap-Interface eine
Möglichkeit angeboten, auf verschiedene Topic Maps so zuzugreifen, als ob sie in
einer Topic Map vereinigt sind. Diese Schnittstelle konnte leider nicht verwendet
werden, da es nicht möglich war die vereinigte“ Topic Map oder nur Ausschnitte
”
davon zu serialisieren. Diese Funktion wird aber für die Zugriffs-Schnittstelle der
Repräsentation unbedingt benötigt. Deshalb muss statt einem on-the-fly-merging“,
”
wie es das UnifiedTopicMap-Interface anbietet, der komplette Merging-Prozess zu
bestimmten Zeitpunkten gestartet werden. Der Merging-Prozess beansprucht jedoch
bei großen Topic Maps viel Rechenleistung und Arbeitsspeicher. Damit das Merging
nicht unnötig oft geschieht und trotzdem eine möglichst aktuelle Repräsentation
vorliegt, ist es am günstigsten, alle Extraktoren hintereinander oder gleichzeitig zu
starten. Sobald der letzte Extraktor fertig ist werden die Topic Maps dann vereinigt.
68
5 IMPLEMENTIERUNG
MergedMap
Extractor
Map A
Extractor
Map B
Extractor
Map C
Input
Map 1
Input
Map 2
Input
Map 3
(a) Merging Strategie 1
MergedMap
MergedMap
2. <<merge in>>
1. <<rename>>
MergedExtractorMap
Extractor
Map A
Extractor
Map B
MergedInputMap
Extractor
Map C
Input
Map 1
Input
Map 2
MergedExtractorMap
Input
Map 3
Extractor
Map A
(b) Merging Strategie 2
Extractor
Map B
MergedInputMap
Extractor
Map C
Input
Map 1
Input
Map 2
Input
Map 3
(c) Verbesserte Strategie 2
Abbildung 32: Erstellung der Gesamtrepräsentation aus den einzelnen Topic Maps
Die InputMap kann im Gegensatz zu einem Extraktor selbst den Zeitpunkt
bestimmten, zu dem Änderungen an ihrer eigenen Topic Map in die gesamte Repräsentation übertragen werden sollen. Aus Effizienzgründen bietet das
InputMapController-Interface dafür zwei verschiedene Methoden (siehe Abbildung 31). Die inputMapExtended-Methode Methode wird vom InputMap-Objekt
aufgerufen, wenn es ihrer Topic Map nur neue Informationen hinzugefügt hat. In
diesem Fall müssen nur die neuen Informationen mit der schon bestehenden Gesamtrepräsentation vereinigt werden. Die inputMapChanged-Methode muss verwendet
werden, wenn in der Topic Map etwas gelöscht wurde. Die Gesamtrepräsentation
muss dann aus den einzelnen Topic Maps neu erstellt werden. Jedesmal wenn eine
Input-Topic-Map sich ändert, müssten also auch alle Extraktor-Topic-Maps vereinigt
werden (Abbildung 32(a)). Um das zu vermeiden, erfolgt die Erstellung der Gesamtrepräsentation in mehreren Stufen (Abbildung 32(b)). Alle Extraktor-Topic-Maps
werden zuerst in der zusätzlichen Topic Map MergedExtractorMap vereinigt, die
Input-Topic-Maps in der Topic Map MergedInputMap. So können MergedInputMap
und MergedExtractorMap jeweils einzeln aktualisiert werden. Ändert sich nur eine
dieser beiden Topic Maps, kann die andere zur Erstellung der Gesamtrepräsentation
MergedMap verwendet werden, ohne dass alle einzelnen Topic-Maps erneut vereinigt werden müssen. Mit dieser mehrstufigen Vereinigung sollte eigentlich die Dauer
zur Erstellung der Gesamtrepräsentation verringert werden, da einige VereinigungsVorgänge eingespart werden. Bei Testläufen stellte sich aber heraus, dass die Erstellung der Gesamtrepräsentation sehr lange dauerte, da bei der abschließenden Vereinigung von MergedInputMap und MergedExtractorMap der Arbeitsspeicherbedarf
sehr hoch war. Häufige Auslagerungen des Arbeitsspeichers durch das Betriebssys-
69
5 IMPLEMENTIERUNG
tem führten zu dem schlechten Ergebnis. Eine bessere Performanz konnte erzielt
werden, indem zur Erstellung der mergedMap die MergedExtractorMap gespeichert
wird und dann im Arbeitsspeicher in MergedMap“ umbenannt wird. Anschließend
”
kann die MergedInputMap mit der MergedMap vereinigt werden (Abbildung 32(c)).
5.4.4. Zugriff auf die Repräsentation und die Informationsobjekte
Für den Zugriff auf die Repräsentation wurde das Interface TopicMapAccess definiert (Abbildung 33). Damit können verschiedene Abfragen auf der Topic Map
ausgeführt werden. Es ist z. B. möglich alle vorhandenen Hierarchien abzufragen
(getAllFacetTopics()), eine Hierarchie zu extrahieren (getHierarchy(...)) oder
bestimmte Ausschnitt der Repräsentation mit der getFragment-Methode abzufragen. Alle Methoden sind zustandsunabhängig ( stateless“) implementiert. Eine Na”
vigation in der Repräsentation kann realisiert werden, indem ein Topic aus einem
Ausschnitt der Repräsentation wieder als Ausgangspunkt einer weiteren Abfrage
verwendet wird.
«Interface»
RepresentationProvider
+getRepresentationMap(): TopicMap
«Interface»
TopicMapAccess
+getIdByIdentifier(subjectIdentifier: String): String
+getIdByIndicator(subjectIndicator: String): String
+getAllFacetTopics(): TopicMap
+getHierarchy(facetTopicId: String): TopicMap
+getInstances(classTopicId: String): TopicMap
+getFragment(startTopicId: String, radius: int): TopicMap
+getDescribingMap(topicId: String): TopicMap
+findTopicsWithString(substringOfBaseName: String):
TopicMap
RepresentationManager
...
+createTopicMapAccessInstance(): TopicMapAccess
+createInformationAccessInstance(): InformationRetriever
«Interface»
InformationRetriever
+getInformationStream(subjectIdentifier: String):
InputStream
Abbildung 33: Schnittstellen zum Zugriff auf die Repräsentation und auf Informationsobjekte
Nicht nur auf die Repräsentation selbst, sondern auch auf jedes repräsentierte Informationsobjekt kann zugegriffen werden. Das InformationRetriever-Interface
(Abbildung 33) bietet die Methode getInformationStream, mit der auf die Daten eines Informationsobjekts zugegriffen werden kann. In der Implemenetierung
wird die gleichnamige Methode jedes Extractor-Objekts aufgerufen (siehe Abschnitt 5.3.4), bis der für die Datenquelle zuständige Extraktor gefunden ist und
einen InputStream des Informationsobjekts zurückliefert.
Die Abfragemethoden der Repräsentation sind bis jetzt nur lokal zugänglich. Um
die Methoden demonstrieren zu können, wurde ein textbasiertes Interface programmiert, das zusammen mit der MIDMAY-Homebase gestartet wird. Mit verschiedenen Kommandos können zur Laufzeit die Methoden des TopicMapAccess-Interface
70
5 IMPLEMENTIERUNG
Abbildung 34: Kommandos der MIDMAY-Homebase-Benutzerschnittstelle
aufgerufen werden. Kommandos zum Starten der Extraktoren und zum Zugriff auf
die Informationsobjekte werden ebenfalls angeboten. Abbildung 34 zeigt die Kommandos, die zur Verfügung stehen. Um z. B. die Extraktion aller Datenquellen zu
veranlassen, wird das Kommando all verwendet. Die Extraktoren greifen dann auf
ihre Datenquellen zu und erstellen einzelne Topic Maps, die anschließend, wie in
Abschnitt 5.4.3 beschrieben, vereinigt werden. Mit map kann dann die gesamte Repräsentation ausgegeben oder in eine Datei gespeichert werden. Weitere Kommandos
erlauben es, Ausschnitte der Repräsentation zu extrahieren. Mit fragment wird eine
Topic Map zurückgegeben, die ein definiertes Topic zusammen mit allen Topics und
Assoziationen in einem bestimmten Umkreis um dieses Topic enthält. Das gewünschte Topic wird über seine ID spezifiziert. Da diese ID von der Topic-Map-Engine bei
der Erstellung eines Topics automatisch generiert wird, ändert sie sich sobald die
Repräsentation neu erstellt wird. Eine stabile Eigenschaft eines Topic ist dagegen
die Subject Address (falls das Topic eine Ressource repräsentiert) oder der Subject
Identifier (falls das Topic keine Ressource repräsentiert). Mit den Kommandos resid
oder indid kann die ID eines Topics bei bekannter Subject Address oder bekanntem Subject Identifier ermittelt werden. Sind noch keine Topics bekannt, kann das
Kommando facets als Einstieg für eine Navigation durch die Repräsentation genutzt
71
6 FAZIT
werden. Es gibt alle Facet-Topics der Repräsentation zurück. Jedes Facet-Topic steht
für eine Hierarchie, die in der Repräsentation enthalten ist. Da jede Datenquelle als
Hierarchie in die Repräsentation abgebildet wird, werden so auch alle repräsentierten Datenquellen identifiziert. Der Baum einer Hierarchie kann mit dem Kommando
hierarchy extrahiert werden. Wie die Benutzer-Topic-Map bearbeitet werden kann,
wird mit den Kommandos new und del demonstriert. Damit können Projekt-Topics
und Assoziation angelegt oder gelöscht werden.
6. Fazit
6.1. Ergebnisse
In dieser Arbeit wurde untersucht, wie heterogene Datenquellen in eine einheitliche
Topic-Map-Repräsentation abgebildet werden können. Eine solche Repräsentation
wird in MIDMAY als Navigations- und Strukturierungsebene über den verteilt gespeicherten Informationen benötigt. Um herauszufinden, inwieweit sich Topic Maps
als Repräsentationsformat eignen, wurden die beiden Technologien Topic Maps und
RDF miteinander verglichen. Es zeigte sich, dass für den Einsatz als MIDMAYRepräsentationsformat Topic Maps einige Vorteile gegenüber RDF bieten. Schließlich wurde eine Lösung vorgestellt, wie die Informationen verschiedener Datenquellen in eine Topic-Map-Repräsentation abgebildet werden können, wobei auch die
Visualisierungsmöglichkeiten der Repräsentation berücksichtigt wurden. Für Dateisysteme und E-Mail-Server wurde gezeigt, wie Struktur und Informationen einer
Datenquelle im Detail in einer Topic Map repräsentiert werden können.
Ebenfalls Teil dieser Arbeit war die Realisierung eines Systems zur Erstellung und
Bereitstellung der Repräsentation. Die Aufgaben und Funktionen des System wurden genauer analysiert und als Anforderungen beschrieben. Es wurde eine SoftwareArchitektur entworfen, die es ermöglicht weitere Datenquellen anzubinden und für
den Zugriff auf die Repräsentation eine Schnittstelle bietet, mit der verschiedene
Arten der Darstellung und Navigation realisiert werden können. Bei der Realisierung der Software-Architektur mit Java wurde auf objektorientiertes Design geachtet und auf verschiedene Design Patterns zurückgegriffen. So ist nicht nur die
Anbindung unterschiedlicher Datenquellen, sondern auch die Integration weiterer
Metadaten-APIs möglich. Die aktuelle Implementierung unterstützt Dateisysteme
und E-Mail-Server als Datenquellen, sowie die Extraktion von Metadaten aus PDFund Word-Dokumenten. Die Schnittstellen für den Zugriff auf die Repräsentation
sind bereits lokal verfügbar. Schnittstellen und eine Basis-Implementierung für das
Versenden und Empfangen von Informationsobjekten sind ebenfalls vorhanden.
72
6 FAZIT
6.2. Bewertung
6.2.1. Konzepte
Sowohl konzeptionell als auch in einer konkreten Implementierung konnte gezeigt
werden, wie mit Topic Maps eine Navigations- und Strukturierungsebene über verteilt gespeicherten Informationen realisiert werden kann. Die Frage, wie die verschiedenen Topic Map Konstrukte zur Erstellung konkreter Repräsentationen am
sinnvollsten eingesetzt werden, kann durch die verschiedenen Möglichkeiten der Modellierung nie eindeutig beantwortet werden. Speziell für die MIDMAY-Repräsentation könnte noch untersucht werden, ob es für die Topic Map Konstrukte Scope,
Occurrences und Variantnames weitere Einsatzgebiete gibt. Variantnames könnten
z. B. bei der Visualisierung verwendet werden, um verschiedene Darstellungsmöglichkeiten für ein Topic zu definieren. Mit der Topic Map Version 1.1 [13] kommt die
Möglichkeit hinzu, einem Basename ein Topic als Typ zuzuweisen. Auf diese Weise
kann z. B. das Naming Constraint nur für ausgewählte Basenames als gültig deklariert werden oder es besteht die Möglichkeit, zu einem Basename einen Datentyp
anzugeben.
6.2.2. Software Architektur und Schnittstellen
Die Herausforderung bei der Erstellung der Software-Architektur bestand darin, die
allerersten Module des MIDMAY-Systems zu realisieren. Es musste darauf geachtet
werden die Schnittstellen so zu definieren, dass die Möglichkeiten eines Clients und
der noch zu entwickelnden MIDMAY-Module nicht von vorn herein eingeschränkt
werden. Um dieses Problem zu lösen, werden Topic Maps zum Informationsaustausch mit anderen MIDMAY-Modulen und mit dem Client verwendet. Das bringt
den Nachteil mit sich, dass alle Module mit Topic Maps arbeiten müssen. Der Vorteil liegt darin, dass eine Topic Maps als Wissensrepräsentation unabhängig vom
späteren Verwendungszweck ist und beliebig erweitert werden kann. Jedes Modul
kann eigene Informationen später in die Repräsentation integrieren, ohne das Art
und Struktur der Informationen bereits jetzt spezifiziert werden müssen.
6.2.3. Implementierung
Mit dem Data Retrieval Module und dem Unified Representation Module ist in
MIDMAY das Erstellen der Topic-Map-Repräsentation und der Zugriff auf die verteilt gespeicherten Informationen möglich. Zur Realisierung dieser beiden Module
mussten verschiedene APIs eingesetzt werden, deren Funktionsweise und Verwendung teilweise erst erarbeitet werden musste. Schwierigkeiten bereitete z. B. die
SSL-Authentifizierung eines E-Mail-Servers, da die notwendige Konfiguration der
73
6 FAZIT
Java-Objekte in der Dokumentation unzureichend beschrieben war. Ebenfalls als
problematisch stellte sich die Vereinigung der verschiedenen Topic Maps zu einer
Repräsentation heraus. Hier mussten verschiedene Varianten ausprobiert werden,
um während des Vorgangs nicht unnötig viel Arbeitsspeicher zu belegen, der erst im
weiteren Verlauf wieder freigegeben wird.
An einem realen Beispiel wurde untersucht, wie sich die Größe der Topic Maps auf
die Zeit für das Merging auswirkt. Hierzu wurde die Anzahl der Topics und Assoziationen der zu vereinigenden Topic Maps bestimmt22 und die Zeit für den Vereinigungsvorgang dieser Topic Maps gemessen. Es zeigte sich, dass der Zeitaufwand für
den Vereinigungsvorgang linear zur Größe der vereinigten Topic-Maps ist (siehe Abbildung 35). Sobald die zu vereinigenden Topic Maps nicht mehr in den physischen
Arbeitsspeicher passen, also auch der virtuellen Speicher verwendet werden muss,
ist der Vorgang allerdings bedeutend langsamer. Hier könnte noch untersucht werden, ob die Verwaltung der Topic Maps in einer Datenbank eine bessere Performanz
und Skalierbarkeit mit sich bringt. Die Topic-Map-Engine TM4J bietet die Anbindung eines relationalen Datenbank-Management-Systems über Hibernate oder die
Anbindung des objektorientierten Datenbank-Management-Systems Ozone an.
Nicht mehr implementiert werden konnte die Communication Komponente des
URM, durch welche die Funktionen der MIDMAY-Homebase von entfernten Clients
aufgerufen werden können. Hier muss noch ein geeignetes Protokoll ausgewählt und
eine entsprechende Serialisierung und Deserialisierung der Anfragen und Rückgaben
implementiert werden. Eine Serialisierung nach XML ist ohne Probleme möglich, da
die Funktionen zum Zugriff auf die Repräsentation entweder Strings oder Topic
Maps zurückgeben. Auch ein WebDAV-Extraktor wurde nicht mehr implementiert.
WebDAV-Quellen können jedoch in das lokale Dateisystem eingebunden und dann
über den Dateisystem-Extraktor abgebildet werden.
6.2.4. Bewertung gegenüber den Anforderungen
In Abschnitt 2.2 wurden Anforderungen an ein System zur Erstellung, Verarbeitung und Bereitstellung der MIDMAY-Repräsentation aufgestellt. Tabelle 2 gibt
Aufschluss darüber, welche der einzelnen Anforderungen in der vorliegenden Implementierung bereits erfüllt werden. Dabei ist zu berücksichtigen, dass bestimmte
Anforderungen nicht alleine durch die Funktionalität der beiden implementierten
MIDMAY-Module DRM und URM erfüllt werden können. Die Anforderungen für
den Zugriff auf Repräsentation können noch nicht als erfüllt bewertet werden, da
noch keine Schnittstelle für den entfernten Zugriff auf die Repräsentation verfügbar
ist. Da aber die notwendigen Zugriffsfunktionen im Unified Representation Module
22
Die Anzahl der Topics, Assoziationen und Occurrences einer Topic Map kann mit dem TM4JTool stats ermittelt werden
74
6 FAZIT
Eingangsdaten
Topic Map
Größe / KB Topics Assozia- Dateien
Ordner
tionen
bzw. Mails
A Mail Postfach
26677
10674
46111
4738
B Dateien (Workspace)
11973
9906
18717
2530
967
C Dateien (Projekte)
1622
1495
2467
313
52
D Dateien (Dokumente)
953
903
1440
402
59
E iCal
11
22
3
F MIDMAY Mail
57
70
57
7
G Dateien (Testdateien)
380
343
560
69
54
E UserInputMap
14
17
4
Messungen
Verwendete Topic Maps GesamtTAO (Topics +
Merging
Laden
größe / KB Assoziationen)
Zeit / s
Zeit / s
41687
92789
350
122
Alle
29714
64166
226
63
ohne B
28092
62859
214
58
ohne B,C
15010
46496
80
32
ohne A
3037
7381
12
6
ohne B,A
TAO: TAO = Topics+Associations+Occurences
Merging: Einzelne Topic Maps zu mergedExtractorMap
vereinigen, mergedExtractorMap umbenennen,
konsistent machen und mergedInputMap einmischen
Laden: Laden der Gesamtrepräsentation beim Starten von
Midmay
Zeitmessungen
400
Zeit / Sekunden
350
300
Merging-Zeit
250
Ladezeit
200
150
100
50
0
0
20000
40000
60000
80000
100000
Größe der Eingangs-Topic-Maps (Topics+Assoziationen)
Abbildung 35: Zeitaufwand beim Vereinigungsvorgang
75
6 FAZIT
Anforderungen
1. Erstellung
a) Indizierung
b) Repräsentation von Metainformationen
c) Einheitliche Repräsentation
2. Zugriff
a) Geräteunabhängiger Zugriff
b) Mobiler Zugriff
3. Benutzung
a) Datenquellen übergreifende Suche
b) Suche über Metainformationen
c) Strukturierung der Repräsentation
4. Benutzbarkeit
a) Aktualität
Bewertung
erfüllt
erfüllt
erfüllt
erfüllt
vorbereitet
(Funktionen lokal verfügbar)
erfüllt
erfüllt
vorbereitet
(generische Schnittstelle zum
Bearbeiten der Benutzer-TopicMap)
zu untersuchen
(Skalierbarkeit noch nicht gegeben)
vorbereitet
b) Kurze Antwortzeit
5. Sicherheit
a) Sichere Kommunikation
b) Schutz der Repräsentations-Daten
c) Schutz der Zugangsdaten
teilweise implementiert
(Zugriff auf Mail-Server über
SSL)
nicht implementiert
(Abhängig von der Konfiguration
des MIDMAY-Servers)
nicht implementiert
(Aufgabe des ID-ManagementModuls)
Tabelle 2: Bewertung der Implementierung
bereits implementiert sind, wird die Erfüllung der Zugriffs-Anforderungen als vor”
bereitet“ bewertet.
Ob die Aktualität der Repräsentation gewährleistet ist, kann ebenfalls noch nicht
abschließend beurteilt werden. Die Aktualität der Repräsentation hängt zum einen
davon ab, wie oft die Extraktoren gestartet werden. Zum anderen muss auch die
Vereinigung der Topic-Maps nach der Extraktion in einer angemessenen Zeit erfolgen
(siehe Abschnitt 6.2.3).
76
6 FAZIT
Die Sicherheits-Anforderungen sind in der derzeitigen Implementierung noch nicht
erfüllt, da die benötigte Funktionalität größtenteils in den Aufgabenbereich anderer
MIDMAY Module fällt. Für die sichere Verwaltung der Zugangsdaten ist z. B. das
ID Management Modul zuständig. Der Schutz der Repräsentations-Daten hängt von
der Konfiguration des MIDMAY-Homebase-Servers ab.
6.3. Ausblick
Unter Verwendung der implementierten Module DRM und URM kann nun auch
die Benutzer-Schnittstelle und das Modul für das sichere Versenden und Empfangen
von Informationen entwickelt werden. Für das Benutzer-Interface wurden bereits
verschiedene Möglichkeiten der Darstellung von Topic Maps beschrieben. Für die
Realisierung eines Clients muss noch überlegt werden, wie zu den Informationen navigiert werden kann und wie die Topics der Repräsentation vom Benutzer strukturiert werden können. Zur Strukturierung könnte z. B. die bei öffentlichen Bookmarks
populäre Tagging-Technik verwendet werden (siehe [17]). Mit der derzeitigen ClientSchnittstelle kann die Benutzer-Topic-Map auf beliebige Weise bearbeitet werden.
Aufbauend auf der vorhandenen Schnittstelle können spezifische Navigations- und
Strukturierungsfunktionen für den Client implementiert werden.
Auf Seite der MIDMAY-Homebase kann die vorliegende Implementierung zur Erstellung der Repräsentation weiter verbessert und ergänzt werden. Die Verwaltung
und der Vereinigungsvorgang der Topic Maps kann möglicherweise durch die Anbindung einer Datenbank optimiert werden. Ergänzt werden kann die Implementierung
um weitere Extraktoren verschiedener Datenquellen und Dateiformate. Als weitere Datenquellen können z. B. Terminkalender oder Datenbanktabellen unterstützt
werden. Semantische Verbindungen zwischen den Informationsobjekten können vor
allem durch die Extraktion von Metadaten gewonnen werden. Außer den bisher unterstützen MS-Office und PDF-Dateien, könnten Metadaten unter anderem aus elektronischen Visitenkarten (vCard), aus Metadaten-Angaben im Dublin-Core-Format
und aus verschiedenen Medienformaten extrahiert werden.
Die Möglichkeit eine Repräsentation heterogener, verteilt gespeicherter Informationen erstellen zu können, war der erste Schritt zur Umsetzung der MIDMAY-Vision
einer sicheren mobilen Informations-Verteilung, Verwaltung und Abfrage. In den folgenden Schritten wird es darauf ankommen, die Sicherheitsanforderungen zu gewährleisten und das Potenzial der Repräsentation auf einem mobilen Client zu nutzen.
77
A ABKÜRZUNGEN UND DEFINITIONEN
A. Abkürzungen und Definitionen
CMS
Dublin Core
FTP
HTTP
iCal
IMAP
Informationseinheit
Informationsobjekt
ISO
KMS
MIME
OASIS
OIL
OWL
PDF
Content Management System
Dublin Core ist ein Metadaten-Schema zur Beschreibung von
elektronischen Dokumenten,
siehe http://dublincore.org/
File Transfer Protocol,
definiert in RFC 959 http://www.ietf.org/rfc/rfc959.
txt
Hypertext Transfer Protocol - HTTP/1.1,
txt
Internet Calendaring and Scheduling Core Object Specification (iCalendar),
Standard zum Austausch von Kalenderinformationen,
txt
Internet Message Access Protocol,
definiert in RFC 3501 http://www.faqs.org/rfcs/
rfc3501.html
Eine Einheit einer Datenquelle, welche für den Menschen relevante Informationen enthält (z.B. Datei, E Mail, Anhang einer
E Mail, Termin, ...)
Ein Objekt, welches für den Menschen relavante Informationen enthält, und unabhängig von seinem physischen Speicherort betrachtet wird
International Organization for Standardisation,
siehe http://www.iso.org
Knowledge Management System,
siehe http://www.rfc-editor.org/
Multi-Purpose Internet Mail Extensions,
txt
Organization for the Advancement of Structured Information
Standards,
siehe http://www.oasis-open.org
Ontology Inference/Interchange Language
Web Ontology Language
Portable Document Format
78
B VERWENDETE PUBLISHED SUBJECT IDENTIFIERS
POP3
PSI
RDFS
RDF
SGML
SSL
TM
Topic Map
UML
URI
URL
UR
vCard
W3C
WebDAV
XTM
Post Office Protocol - Version 3,
definiert in RFC 1939 http://www.faqs.org/rfcs/
rfc1939.html
Published Subject Identifier
Ressource Description Framework Schema,
siehe http://www.w3.org/RDF/
Ressource Description Framework,
siehe http://www.w3.org/RDF/
Standard Generalized Markup Language,
siehe http://www.w3.org/MarkUp/SGML/
Secure Sockets Layer
Topic Map
Standard zur Repräsentation und zum Austausch von Wissensstrukturen
Unified Modeling Language,
siehe http://www.uml.org/
Uniform Resource Identifier,
siehe http://www.w3.org/Addressing/
Uniform Resource Locator,
siehe http://www.w3.org/Addressing/
Unified Representation
Einheitliche Repräsentation der Informationsobjekte aller Datenquellen in MIDMAY
vCard ist eine Spezifikation für elektronische Visitenkarten,
siehe http://www.imc.org/pdi/
World Wide Web Consortium,
siehe http://www.w3.org/
Web-based Distributed Authoring and Versioning,
siehe http://www.webdav.org/
XML Topic Maps:
XML Format zum Austausch von Topic Maps,
siehe http://www.topicmaps.org/xtm/
B. Verwendete Published Subject Identifiers
B.1. Generische Topics
Folgende Topics werden generisch für die Abbildung von verschiedenen Datenquellen
genutzt:
79
Information Object Type
http://www.sit.fraunhofer.de/midmay/psi/generic/#information-objecttype
Ein Topic als Typ für die Topics, die eine bestimmte Art von Informationsobjekten
repräsentieren (z. B. als Typ für das File-Topic).
Information Object
http://www.sit.fraunhofer.de/midmay/psi/generic/#information-object
Ein Topic das als Rollenspezifikation in Assoziationen verwendet wird, welche ein
Informationsobjekte mit einer Eigenschaft des Informationsobjekts verbinden.
Container-Containee Relation
http://www.sit.fraunhofer.de/midmay/psi/generic/#container-containeerelation
Ein Assoziations-Typ für Assoziationen zwischen einem Topic, welches die Rolle
Container spielt und einem Topic welches die Rolle Containee spielt
Container
http://www.sit.fraunhofer.de/midmay/psi/generic/#container
Ein Topic für die Rollenspezifikation in der Container-Containee Relation.
Containee
http://www.sit.fraunhofer.de/midmay/psi/generic/#containee
Ein Topic für die Rollenspezifikation in der Container-Containee Relation
B.2. Eigenschaften von Informationsobjekten
Folgende Topics werden zur Beschreibung der Eigenschaften von Informationsobjekten definiert, die von der Datenquelle vollkommen unabhängig sind:
Author Relation
http://www.sit.fraunhofer.de/midmay/psi/information/#object-authorrelation
Author spielt und einem Topic welches die Rolle Information Object spielt. Mit
einer Assoziation dieses Typs wird einem Informationsobjekt ein Autor zugeordnet.
Author
http://www.sit.fraunhofer.de/midmay/psi/information/#author
Ein Topic für die Rollenspezifikation eines Topics als Autor in der Author Relation.
Title Relation
http://www.sit.fraunhofer.de/midmay/psi/information/#object-titlerelation
80
Assoziations-Typ für Assoziationen zwischen einem Topic, welches die Rolle Title spielt und einem Topic welches die Rolle Information Object spielt. Mit einer
Assoziation dieses Typs wird einem Informationsobjekt ein Titel zugeordnet.
Title
http://www.sit.fraunhofer.de/midmay/psi/information/#title
Ein Topic welches das Konzept des Titels eines Dokuments repräsentiert. Es wird
als Topic-Typ und für die Rollenspezifikation eines Topics in einer Assoziation vom
Typ Title Relation genutzt.
Lastmodifed Relation
http://www.sit.fraunhofer.de/midmay/psi/filesystem/#object-lastmodifiedrelation
Lastmodied spielt und einem Topic welches die Rolle Information Object spielt.
Mit einer Assoziation dieses Typs wird einem Informationsobjekt ein Zeitpunkt
zugeordnet, der die letzte Änderung des Informationsobjekts angibt.
Lastmodifed
http://www.sit.fraunhofer.de/midmay/psi/filesystem/#lastmodified
Ein Topic für die Rollenspezifikation eines Topics, das einen Zeitpunkt repräsentiert,
in der Lastmodifed Relation.
B.3. Dateisystem
Folgende Topics werden für die Abbildung von Verzeichnissen, Dateien und speziellen Datei-Eigenschaften definiert:
Directory
http://www.sit.fraunhofer.de/midmay/psi/filesystem/#directory
Ein Topic, welches das Konzept eines Verzeichnisses oder Ordners repräsentiert, in
dem Informationsobjekte abgelegt sein können.
File
http://www.sit.fraunhofer.de/midmay/psi/filesystem/#file
Ein Topic, welches das Konzept einer Datei in einem Dateisystem repräsentiert.
Filetype Relation
http://www.sit.fraunhofer.de/midmay/psi/filesystem/#object-filetyperelation
Ein Assoziations-Typ für Assoziationen zwischen einem Topic, welches die Rolle Filetype spielt und einem Topic welches die Rolle Information Object spielt. Mit einer
Assoziation dieses Typs wird einem Informationsobjekt ein Dateiformat zugeordnet.
81
Filetype
http://www.sit.fraunhofer.de/midmay/psi/filesystem/#filetype
Ein Topic welches das Konzept Dateiformat“ repräsentiert.
”
B.4. E-Mail
Folgende Topics werden für die Abbildung von E-Mails, Datei-Anhängen und speziellen E-Mail-Eigenschaften definiert:
Email
http://www.sit.fraunhofer.de/midmay/psi/email/#email
Ein Topic welches das Konzept E-Mail“ repräsentiert.
”
Attachment
http://www.sit.fraunhofer.de/midmay/psi/email/#attachment
Ein Topic welches das Konzept Datei-Anhang einer E-Mail“ repräsentiert.
”
Mailaddress
http://www.sit.fraunhofer.de/midmay/psi/email/#mailadress
Ein Topic welches das Konzept E-Mail Adresse“ repräsentiert.
”
Person
http://www.sit.fraunhofer.de/midmay/psi/email/#person
Ein Topic welches das Konzept einer Person repräsentiert.
Address-Person Relation
http://www.sit.fraunhofer.de/midmay/psi/email/#address-person
Ein Assoziations-Typ für Assoziationen zwischen einem Topic welches die Rolle Address spielt und einem Topic welches die Rolle Person spielt. Mit einer Assoziation
dieses Typs wird einer Person eine Adresse zugeordnet, unter der die Person zu
erreichen ist.
Sender Relation
http://www.sit.fraunhofer.de/midmay/psi/email/#object-sender-relation
Sender spielt und einem Topic welches die Rolle Information Object spielt. Mit einer
Assoziation dieses Typs wird einem Informationsobjekt die Adresse des Absender
dieses Informationsobjekts zugeordnet.
Sender
http://www.sit.fraunhofer.de/midmay/psi/email/#sender
Ein Topic für die Rollenspezifikation eines Topics in der Sender Relation, als Adresse
des Absenders.
82
Receiver Relation
http://www.sit.fraunhofer.de/midmay/psi/email/#object-receiverrelation
Ein Assoziations-Typ für Assoziationen zwischen einem Topic, welches die Rolle Receiver spielt und einem Topic welches die Rolle Information Object spielt. Mit einer
Assoziation dieses Typs wird einem Informationsobjekt die Adresse des Empfängers
dieses Informationsobjekts zugeordnet.
Receiver
http://www.sit.fraunhofer.de/midmay/psi/email/#receiver
Ein Topic für die Rollenspezifikation eines Topics in der Receiver Relation, als Adresse des Empfängers.
83
Literatur
Literatur
[1] Ahmed, Kal: Beyond PSIs : Topic Map design patterns. In: Extreme Markup
Languages, 2003
[2] Berners-Lee, Hendler J. Lasilla O.: The Semantic Web. May 2001
[3] Davis, Randall ; Shrobe, Howard E. ; Szolovits, Peter: What Is a Knowledge
Representation? In: AI Magazine 14 (1993), Nr. 1, 17-33. http://citeseer.
ist.psu.edu/davis93what.html
[4] Denton, William: How to Make a Faceted Classification and Put It On the
Web. http://www.miskatonic.org/library/facet-web-howto.html, 2003.
– University of Toronto, Faculty of Information Studies
[5] Freese, Eric: So why aren’t Topic Maps ruling the world? In: Extreme Markup
Languages, 2002
[6] Gamma, Erich ; Helm, Richard ; Johnson, Ralph ; Vlissides, John: Design
Patterns. Addison-Wesley Professional, 1995
[7] Garshol, Lars M.: Living with topic maps and RDF. http://www.ontopia.
net/topicmaps/materials/tmrdf.html,
[8] George Coulouris, Tim K.: Verteilte Systeme: Konzepte und Design. 3.
München : Pearson Studium, 2002
[9] Gruber, T. R.: Towards Principles for the Design of Ontologies Used for
Knowledge Sharing. In: Guarino, N. (Hrsg.) ; Poli, R. (Hrsg.): Formal Ontology in Conceptual Analysis and Knowledge Representation. Deventer, The
Netherlands, 1993
[10] Heider, Jens: Vision und Realisierung einer sicheren mobilen InformationsVerteilung, Verwaltung und Abfrage. Fraunhofer Institut für Sichere Informationstechnologie SIT, 2005
[11] International Organization for Standardisation: ISO/IEC 13250,
Information technology – SGML applications – Topic maps. 2000
[12] International Organization for Standardisation: Guide to the topic
map standards. http://www.y12.doe.gov/sgml/sc34/document/0323.htm,
2002
[13] International Organization for Standardisation: ISO 13250-2: Topic Maps – Data Model. http://www.isotopicmaps.org/sam/sam-model/, 1
2005. – Final committee draft
84
Literatur
[14] International Organization for Standardisation: Topic Maps Constraint Language. http://www.isotopicmaps.org/tmcl/tmcl-2005-02-12.
html, 2 2005. – Draft for review
[15] Jeckle, Mario ; Rupp, Chris ; Hahn, Jürgen ; Queins, Stefan ; Zengler,
Barbara: UML 2 glasklar. Hanser, 2004
[16] Le Grand, B. ; Soto, M.: Information management – Topic maps visualization. In: Sixth International Conference on Information Visualisation (IV’02).
London, 2002
[17] Mathes, Adam: Folksonomies - Cooperative Classification and Communication Through Shared Metadata. http://www.adammathes.com/academic/
computer-mediated-communication/folksonomies.html, 12 2004
[18] Newcomb, Steven R.:
RDF/Topic Maps: late/lazy reification vs.
http://lists.oasis-open.org/archives/
early/preemptive reification.
topicmaps-comment/200109/msg00093.html, 9 2001. – Mailing List Beitrag
[19] OASIS Published Subjects Technical Committee: Published Subjects: Introduction and Basic Requirements. http://www.oasis-open.org/
committees/download.php/3050/pubsubj-pt1-1.02-cs.pdf, 6 2003. – Recommendation
[20] Park, Jack ; Hunting, Sam ; Engelbart, Douglas C.: XML Topic Maps:
Creating and Using Topic Maps for the Web. Prentice Hall, 2003
[21] Pepper, S.: The TAO of Topic Maps - finding the way in the age of infoglut.
http://www.ontopia.net/topicmaps/materials/tao.html, 2000
[22] Pepper, Steve: Curing the Web’s Identity Crisis. http://www.ontopia.net/
topicmaps/materials/identitycrisis.html,
[23] Pepper, Steve ; Gronmo, Geir O.: Towards a General Theory of Scope. In:
Extreme Markup Languages. Montreal, Canada, 2001
[24] Rath, H. H.: Topic maps self-control. In: Markup Languages: Theory and
Practice 2 (2000), September, Nr. 4, S. 367–388
[25] Schatten, Alexander ; Inselkammer, Franz ; Tjoa, A M.: System Integration and Unified Information Access using Question Based Knowledge Management Strategies. In: Proceedings of the fifth International Conference on
Information Integration and Web-based Applications & Services (IIWAS2003),
2003
[26] Kapitel Ontology, Metadata, and Semiotics. In: Sowa, John F.: Conceptual
Structures: Logical, Linguistic, and Computational Issues. Berlin : Springer,
2000 (Lecture Notes in AI 1867), S. 55–81
85
Literatur
[27] Topicmaps.org ; Pepper, Steve (Hrsg.) ; Moore, Graham (Hrsg.): XML
Topic Maps (XTM) 1.0. http://www.topicmaps.org/xtm/1.0, 2001
[28] W3C: OWL Web Ontology Language Overview. http://www.w3.org/TR/
2004/REC-owl-features-20040210/, 2 2004. – Recommendation
[29] W3C: RDF Vocabulary Description Language 1.0: RDF Schema. http://www.
w3.org/TR/2004/REC-rdf-schema-20040210/, 2 2004. – Recommendation
[30] W3C: RDF/XML Syntax Specification (Revised). http://www.w3.org/TR/
2004/REC-rdf-syntax-grammar-20040210/, 2 2004. – Recommendation
86

Einheitliche Repräsentation heterogener Datenquellen

Transcription

Similar documents

Datenmodellierung und Datenbanktechnik

Diplomarbeit - Lehrstuhl für Informatik VI

genugate Version 7.0 Release Notes

als PDF downloaden - Die Yoga