Qualitative Abstraktion von Zeit für Annotation und Retrieval im Semantic Web

Inhaltsverzeichnis

1 Einleitung und Motivation
1.1 Vom World Wide Web zum Semantic Web
1.1.1 Annotation mit Metadaten
1.1.2 Zielsetzung
1.2 Aufbau der Arbeit

I Grundlagen
2 Annotation
2.1 Sprachen
2.1.1 XML
2.1.2 DTD und XML Schema
2.1.3 Erweiterungen
2.1.3.1 Namespaces
2.1.3.2 XInclude
2.2 Metadatenformate
2.2.1 RDF
2.2.2 RDF Schema
2.2.3 Dublin Core
2.2.3.1 W3C Date Time Format
2.2.3.2 DCMI Period
2.3 Temporale Annotation
2.3.1 Anforderungen an temporale Annotation
2.3.1.1 Benennung
2.3.1.2 Grenzen
2.3.1.3 Strukturen
2.3.1.4 Explizite qualitative Relationen
2.3.2 Bewertung bestehender Ansätze
3 Temporale Repr äsentation und temporales Schließen
3.1 Punktstrukturen
3.2 Periodenstrukturen
3.3 Allens Zeitlogik
3.4 Freksa: Konzeptuelle Nachbarschaft
3.5 Bewertung bestehender Ansätze

II Konzeption und Realisierung
4 Das temporale Modell: period names
4.1 Definition und Benennung
4.2 Grenzen
4.2.1 Exakte Grenzen
4.2.2 Unscharfe Grenzen
4.2.3 Persistente Grenzen
4.2.4 Unbekannte Grenzen
4.2.5 Kombinationen
4.3 Datumsformat RFC3339mod
4.4 Referenzierung
4.5 Relationen
4.6 Formeln
5 Temporale Relevanz
5.1 Abstand zwischen Perioden
5.2 ÜberschneidungvonPerioden
5.3 ÜberschneidungstattAbstand
6 Reasoning
6.1 Beschreibung des Problemumfangs . .
6.2 Relationsbestimmung
6.2.1 Relationen zwischen Grenzen
6.2.2 Relationen zwischen zwei Perioden
6.2.2.1 Positiv und negativ hinreichende Bedingungen
6.2.3 Relationen zwischen mehreren Perioden
6.3 Implementierung eines Reasoners
6.3.1 Interne Repräsentation
6.3.1.1 Transitive Expansion
6.3.1.2 Behandlung von contemporary
6.3.1.3 Verifikation: Erkennung von Inkonsistenzen .
6.3.2 Anfrage

III Anwendung und Diskussion
7 Anwendung
7.1 Rein qualitative Aussagen
7.2 Rein quantitative Aussagen
7.3 Inkonsistenz I: quantitativ/qualitativ
7.4 Inkonsistenz II: Reasoner-implizit/qualitativ
7.5 Inkonsistenz III: qualitativ/qualitativ
8 Diskussion der Arbeit
8.1 Abschlussbetrachtung
8.1.1 period names
8.1.2 Temporale Relevanz
8.1.3 Reasoning
8.2 Ausblick

IV Anhang

A XML Schema

A.1 periodNames.xsd

Kapitel Einleitung und Motivation

1.1 Vom World Wide Web zum Semantic Web

Das World Wide Web [W3C01a, BLF99], neben eMail der prominenteste Bestandteil des Internets, hat sich in den letzten Jahren zu einer der wichtigsten Informationsquellen des täglichen Lebens entwickelt. Es wird zusammen mit Zeitung, Fernsehen und Radio zur Einholung von tagesaktuellen Nachrichten genutzt, leistet aber auch wertvolle Dienste als Nachschlagewerk und für den Austausch und die Konservierung von Erfahrungen, Erlebnissen und Berichten

Dabei ist es durch seine ursprüngliche Bedeutung als Veröffentlichungsmedi- um für Wissenschaftler [Con00, Gro02] stark an den Belangen des Nutzers orien- tiert, vor allem an seinen visuellen Bedürfnissen, da der enthaltene Text in erster Linie gut lesbar sein sollte. Diese Orientierung hat über die Jahre mit der enormen Erweiterung der grafischen Möglichkeiten und der Erhöhung der dem Leser zur Verfügung stehenden Bandbreite noch zugenommen. Die in der Sprache HTML (HyperText Markup Language) [W3C99a, ISO00b] verfassten Webseiten sind zwar weiterhin maschinenlesbar, logische Textauszeichnungen wie em (emphatisch), strong (stark betont), samp (Beispiel) oder cite (Zitat), die zumindest einen rudimentären Hinweis auf den Inhalt geben, sind dagegen fast vollständig ver- schwunden. Davon, dass Maschinen den Inhalt einer Seite verstehen, kann keine Rede sein. In HTML können zwar auch über die Verwendung von Meta-Tags wie description und keywords zusätzliche Informationen, sogenannte Metada- ten, in die Seiten eingebettet werden; das folgende Beispiel gibt aber schon einen Hinweis auf die dabei auftretenden Unzulänglichkeiten:

<meta description="Die Homepage des TZI in Bremen ...">

<meta keywords="TZI, Technologie-Zentrum Informatik, ...">

In der Beschreibung steht Fließtext, der zwar für einen menschlichen Leser gute Hinweise gibt, mangels Standardisierung für eine Maschine aber völlig unverständlich bleibt. Für die Schlüsselwörter gilt ähnliches; ob ein Programm aus ihnen eine Bedeutung herauslesen kann, bleibt Zufall.

In Anbetracht dieser Situation bleibt für das Auffinden von bestimmten Infor- mationen in der überhand nehmenden Flut der Daten zunächst nur die Volltext- suche, also der Abgleich von Suchwörtern der Anfrage mit den Wörtern, die in den zu durchsuchenden Webseiten vorkommen. GOOGLE [GOO], eine der der- zeit populärsten und leistungsfähigsten Suchmaschinen, indiziert im Herbst 2002 ungefähr drei Milliarden Seiten. Da eine Volltextsuche oft hunderte bis tausen- de von Treffern ergeben kann, haben die Betreiber hochkomplexe Bewertungs- verfahren entwickelt, um dem Benutzer ein Ranking der möglichen Antworten präsentieren zu können. Dabei werden beispielsweise Seiten, die von anderen Sei- ten besonders häufig verlinkt werden, höher bewertet als wenig verlinkte Seiten; GOOGLE bezeichnet dies als ”PageRank“[BP[98]].EswerdenvielfältigeAnstren- gungen unternommen, um die wahrscheinlich für den Anfrager als am wichtigs- ten einzuschätzenden Informationen an die Spitzenplätze zu setzen; so oder ähn- lich arbeiten die allermeisten Suchmaschinen. Daneben gibt es noch die Meta- Suchmaschinen, die die Resultate anderer Suchmaschinen sammeln und die Er- gebnisse unter der Berücksichtigung weiterer Kriterien neu zusammensetzen, bei- spielsweise METAGER [MET].

Alle Volltextansätze haben aber den entscheidenden Nachteil, dass ein Such- begriff in einer Seite auch exakt¹ in dieser Schreibweise vorkommen muss, damit sie überhaupt ins Ranking aufgenommen wird. Alle Webseiten, die abgewandel- te Schreibweisen der Suchbegriffe verwenden, bekommt der Anfragende gar nicht erst zu Gesicht; auch die Problemfelder der Synonyme oder der Sprachenvielfalt im Internet sind durch noch so ausgefeilte Rankingmechanismen nicht in den Griff zu bekommen.

Es fehlt zusammenfassend an Standards, um den Inhalt einer Webseite - oder allgemein einer Datenquelle im Internet - maschinenverständlich festzuhalten, um so die Anfrage für die Suche nach Informationen leistungsfähiger, komfortabler und damit einfacher als bisher zu gestalten, und um vollständigere und korrektere Antworten zu finden.

1.1.1 Annotation mit Metadaten

Das Hinzufügen von zusätzlichen, beschreibenden Hinweisen an eine Webseite, Datenquelle oder allgemein eine beliebige Entität wird als Annotation bezeichnet, die Hinweise selbst als Metadaten ( ”DatenüberDaten“)[Las[98]].

Dieses Prinzip ist altbekannt und wird vielfältig verwendet; so finden sich auf jedem Buch Angaben über den Verfasser, den Verlag oder das Veröffentlichungs- jahr, und jede Bibliothek führt Kataloge über die vorhandenen Bände, ihre Stand- orte (Stockwerk, Regal, Brett, . . . ) oder Gattungen (Kinderroman, Sachbuch/Bio- logie, Lexikon, . . . ). Gerade beim Auffinden eines Buches zu einem bestimmten Problembereich in einer riesigen Bibliothek ist die Art der erfassten Metadaten - in diesem Beispiel vor allem Schlüsselwörter und Kurzbeschreibungen - von

1.1. VOM WORLD WIDE WEB ZUM SEMANTIC WEB

besonderer Bedeutung. Mit der zunehmenden Verbreitung der Computer, der ”De- mokratisierung“ des Zugriffs auf vielfältigste Informationen durch normale Bürger und den rapide anwachsenden Umfang dieser Informationen steigt außerdem der Anspruch an die Leistungsfähigkeit des Umgangs mit den Metadaten. War es vor einiger Zeit für einen Bibliothekar noch selbstverständlich, sich durch umfang- reiche Kataloge zu arbeiten, fordern heutige Benutzer komfortablen Zugriff und schnelle, gute Ergebnisse der Anfragen. Entwicklungen in diesem Bereich verbes- sern allgemein die Kommunikation zwischen Mensch und Maschine.

Zusätzlich steigt durch die vermehrte, mittlerweile selbstverständliche und all- gegenwärtige Vernetzung der Computersysteme die Notwendigkeit der Interope- rabilität dieser Systeme. Datenbanken tauschen Informationen aus, aktualisieren selbstständig ihre Bestände, finden Inkonsistenzen, generieren neue Informationen oder reichen Benutzeranfragen weiter und bearbeiten sie gemeinsan. Gerade für diesen Bereich, der Kommunikation zwischen Maschinen, ist eine Standardisie- rung entscheidend für die Möglichkeiten und die Mächtigkeit: Zwei Programme, die miteinander kommunizieren (in diesen Fall spricht man häufig auch von Agen- ten), können nur dann sinnvoll Daten austauschen, wenn sie die gleiche sprechen. ”Sprache“

Im Hinblick auf das Internet geht es also vor allem darum, durch die Erwei- terung des World Wide Web um Metadaten die Mächtigkeit der Informationsauf- findung und die Interoperabilität zu verbessern. Ein zentraler Begriff ist dabei der des Semantic Web [BLHL01, W3C01c]. 1998 von Tim Berners-Lee in einer Road Map [BL98] festgehalten, beschreibt er heute eine Initiative [SWO] des WORLD WIDE WEB CONSORTIUMS (W3C) [W3C02c], die vielfältige Anstrengungen zur Verbesserung der beschriebenen Probleme unternimmt und rege Beachtung und Unterstützung aus vielen Gebieten aktueller Forschung genießt. Sehr wichtig ist in diesem Zusammenhang der Begriff der Semantik, der häufig als Synonym für Bedeutung verwendet wird. Die Semantic Web Initiative stützt sich zur Erreichung ihrer Ziele unter anderem auf Bausteine, auf die in dieser Arbeit ausführlich einge- gangen wird; hervorzuheben sind hier vor allem die eXtensible Markup Language (XML) [W3C00a] (Abschnitt 2.1.1 ab Seite 11) als grundlegende Sprache zum Formulierung beliebiger (Meta-)Daten und das darauf aufbauende Resource Des- cription Framework (RDF) [W3C99c] (Abschnitt 2.2.1 ab Seite 17) zur Annotation von Metadaten.

Das RDF bildet wiederum eine Notationsgrundlage für den Dublin Core Me- tadata Standard (DC) [DCM] (Abschnitt 2.2.3 ab Seite 20), der fünfzehn Ele- mente zur Beschreibung von vernetzten Ressourcen definiert, darunter Title, Creator oder Subject. Jedes dieser Elemente hat eine festgelegte Bedeutung; außerdem gibt es Empfehlungen, auf welche Art (Vokabular, Datenformat, . . . ) die Elemente zu füllen sind, um Interoperabilität zu gewährleisten. In der An- wendung zeigt sich aber, dass die Empfehlungen teilweise nicht ausdrucksmächtig (z.B. Relation) oder nicht exakt genug definiert (z.B. Description) sind.

1.1.2 Zielsetzung

Die vorliegende Arbeit konzentriert sich auf die Verwendung von temporalen Me- tadaten, die in zwei verschiedene Bereiche unterteilt werden können. Bei dem ers- ten handelt es sich um Ereignisse bzw. Zeitpunkte von Ereignissen, die für den Lebenszyklus einer (Netz-)Ressource eine besondere Bedeutung haben; typischer- weise gehören dazu das Erstellungsdatum, der Zeitpunkt der letzten Änderung oder der Beginn der Verfügbarkeit. Für diese Anwendungsfälle existiert das Du- blin Core-Element Date mit seinen Verfeinerungen Date.Created, Date. Modified, Date.Available etc.

Interessanter für den Einsatz im Semantic Web sind aber weniger diese ”tech- nischen“ Details, sondern viel mehr der davon unabhängige Betrachtungszeitraum einer Informationsquelle. So liegt bei einem Zeitungsartikel der zeitliche Unter- schied zwischen dem Stattfinden eines Ereignisses und der Verbreitung der Be- schreibung für gewöhnlich in der Größenordnung einiger Stunden; bei einer Bio- graphie können es dagegen Jahrzehnte oder Jahrhunderte sein. Ebenso kann sich eine halbstündige Fernsehreportage mit Zeiträumen befassen, die wesentlich länger oder auch wesentlich kürzer sind, und die in der Zukunft oder der Vergangenheit liegen können. Der Lebenszyklus einer Information bzw. einer Informationsquelle ist damit unabhängig von ihrem Betrachtungszeitraum. Für diesen zweiten Bereich temporaler Metadaten ist eine Verfeinerung des Dublin Core-Elements Coverage vorgesehen: Coverage.Temporal. Zu dessen Füllung wurde die DCMI Period [DCM00a] eingeführt (Abschnitt 2.2.3.2 ab Seite 23), die einen Zeitraum mit Hilfe eines Start- und eines Endpunkts definiert. Ergänzend kann für diesen Zeitraum ein nicht-norminativer (nur der Beschreibung dienender) Name angegeben werden.

Betrachtungszeiträume haben wie viele andere Zeiträume aus dem täglichen Leben häufig eine Eigenschaft, die bei der Verwendung von Maschinen zunächst zu Komplikationen führen kann: Sie sind oft nicht genau definiert, haben also keine exakt anzugebenden Start- und Endpunkte. Manchmal sind Beginn oder Ende so- gar völlig unbekannt. Darüber hinaus ist es für Menschen üblich, diese Zeiträume lediglich über den Namen zu referenzieren, ohne weitere Angaben über die La- ge oder die Dauer zu machen; ”indenSommerferien“oder ”imletztenWinter“ sind dafür Beispiele. Zusätzlich sind viele Zeiträume eng miteinander verknüpft, indem das Ende eines Zeitraums vom Beginn eines anderen markiert wird. Eben- so kann der Fall auftreten, dass über Zeiträume nur qualitative Aussagen getroffen werden können, ohne dass exakte Zeitpunkte bekannt sind: ”PersonAlebtevor Person B“. Es ist wünschenswert, diese für Menschen geläufigen Eigenschaften von Zeiträumen auf ein Computer-Modell übertragen zu können, mit dessen Hilfe dann Aussagen getroffen (Annotation) und Anfragen formuliert (Retrieval) werden k önnen.

Bei einer genaueren Bestimmung der Anforderungen temporaler Annotation (Abschnitt 2.3.1 ab Seite24 ) und einer anschließenden Bewertung der DCMI Peri- od unter diesen Gesichtspunkten ergibt sich die Notwendigkeit, den beschrittenen Weg weiterzuverfolgen, aber einen eigenen Ansatz zu entwickeln. Die Zielsetzung dieser Arbeit ist deshalb vor allem in der Verbessung der temporalen Annotation zu sehen, um bei der Beschreibung der Metadaten mehr Flexibilität und Praxistauglichkeit zu erreichen. Daneben soll diese Funktionalität aber auch bei der Anfrage zur Verfügung zu stehen.

Im Speziellen soll die Möglichkeit geschaffen werden, bei Annotation und Re- trieval umgangssprachliche Begriffe und Relationen zu benutzen, also auch qua- litativ statt ausschließlich quantitativ mit Zeit umzugehen. Dazu werden in der vorliegenden Arbeit die Grundlagen temporaler Repräsentation identifiziert und f ür die Domäne Semantic Web erweitert, eine Syntax für die Kodierung der Me- tadaten eingeführt und temporale Schlussfolgerungsalgorithmen beschrieben und implementiert.

Außerdem wird die temporale Relevanz definiert, die eine Bewertung der Er- gebnisse einer Anfrage ermöglicht. Bei der oben beschriebenen Volltextsuche wer- den erst die ÜbereinstimmungenbestimmtundnurdiesedannineinemRanking nach geschätzter Wichtigkeit sortiert; im Gegensatz dazu werden hier zunächst alle Informationsquellen als mögliche Ergebnisse angesehen, die sich aber untereinan- der durch den Grad an Relevanz bezüglich der Anfrage unterscheiden. Sie können so in eine Reihenfolge gebracht und als Gesamtergebnis präsentiert werden.

1.2 Aufbau der Arbeit

Teil I: Grundlagen

Im ersten Teil werden die Grundlagen der Metadaten-Annotation und der temporalen Repräsentation vorgestellt und eine Bewertung bestehender Ansätze im Hinblick auf die Zielsetzung dieser Arbeit vorgenommen.

Kapitel 2: Annotation

Zunächst werden die Basistechnologien betrachtet: eXtensible Markup Language, Document Type Definition, XML Schema, Resource Des- cription Framework und RDF Schema. Danach wird das Metadaten- format Dublin Core mit seiner Zeitraumrepräsentation DCMI Period vorgestellt und nach der Formulierung von Anforderungen an die tem- porale Annotation auch bewertet.

Kapitel 3: Temporale Repräsentation und temporales Schließen

Es werden verschiedene Modelle für Zeitpunkte und Zeiträume vor- gestellt, die Repräsentation von Zeit und Schlussfolgerungen in der Zeit erlauben: Punktstrukturen, Periodenstrukturen, Allens Zeitlogik und Freksas konzeptuelle Nachbarschaften. Anhand der in Kapitel 2 formulierten Anforderungen wird eine Bewertung der einzelnen Mo- delle vorgenommen.

Teil II: Konzeption und Realisierung

Im zweiten Teil werden aufbauend auf den Grundlagen des ersten Teils Modifikationen und Erweiterungen der bestehenden Ansätze entwickelt, die temporale Relevanz eingeführt und Algorithmen für das Reasoning mit den neuen Konzepten vorgestellt.

Kapitel 4: Das temporale Modell: period names

Als Gegenentwurf zu den bestehenden Modellen wird das Konzept pe- riod name eingeführt und vollständig beschrieben; dies umfasst die Verwendung von exakten, unscharfen, persistenten und unbekannten Grenzen, die Referenzierung bereits bekannter Perioden zum Aufbau von Strukturen, deren Anreicherung mit expliziten Relationen und den Einsatz von Formeln. Ergänzend wird das Datumsformat RFC3339- mod definiert, dass einen größeren Zeitrahmen abdeckt als die etablierten Formate und deshalb bei period names zum Einsatz kommt.

Kapitel 5: Temporale Relevanz

Um die Bewertung von Ergebnissen bezüglich einer Anfrage vorneh- men zu können, wird die temporale Relevanz und ihre Berechnung vor- gestellt. Die Besonderheiten des Konzepts period name (verschiedene Grenzarten, etc.) finden dabei ausführlich Beachtung. Kapitel 6: Reasoning Zunächst wird die Ermittlung der Relationen zwischen zwei Grenzen beschrieben, auf der die Ermittlung der Relationen zwischen zwei Peri- oden aufbaut. Dabei wird die Verwendung von positiv und negativ hin- reichenden Bedingungen vorgestellt, durch die auch bei nur teilweise bestimmten Perioden eine Ableitung der Lage zueinander vorgenom- men werden kann. Außerdem werden die interne Repräsentation des implementierten Reasoners und die Vorgänge bei der Überprüfung der Konsistenz eines Modells beschrieben.

Teil III: Anwendung und Diskussion

Der dritte Teil befasst sich mit der Evaluation und der Verifikation der neu erarbeiteten Konzepte im Rahmen von mehreren typischen Beispielen. An- schließend werden die Ergebnisse diskutiert und Ausblicke auf zukünftige Arbeiten gegeben.

Kapitel 7: Anwendung

Das Verhalten des temporalen Reasoners bei korrekten sowie inkonsis- tenten Modellen wird erläutert. Dabei werden vor allem die verschie- denen Arten von Inkonsistenzen - beispielsweise Widersprüche zwi- schen implizit aus den Randpunkten ableitbaren und explizit angege- benen Relationen - betrachtet und deren Erkennung gezeigt.

Kapitel 8: Diskussion

Die Arbeit wird abgeschlossen durch einen Überblick über die vorgestellten Konzepte und Methoden und einen Ausblick auf zukünftige Erweiterungen und sich anschließende Arbeiten.

Am Ende eines jeden Kapitels werden die Ergebnisse zusammengefasst und die wichtigsten Punkte nochmals kurz hervorgehoben.

Teil I Grundlagen

Kapitel 2 Annotation

Das folgende erste Grundlagenkapitel befasst sich mit der Annotation von Metadaten, speziell ihrer Notation und Standardisierung.

Dazu geht es zunächst auf Sprachen ein, die zur Strukturierung von Daten benötigt werden, namentlich die eXtensible Markup Language (XML) und die beiden unterstützenden, Vokabulare beschreibenden Sprachen Document Type Definition (DTD) und XML Schema.

Auf ihrer Grundlage bauen Metadatenformate auf, die anschließend in Form des Resource Description Framework (RDF) betrachtet werden. RDF erhält Unter- stützung durch das RDF Schema (RDFS), das ebenfalls genauer beschrieben wird. Der durch RDF und RDFS bereitgestellte Rahmen wird von Dublin Core genutzt, um einen Metadatenstandard zu definieren, der ausführlich vorgestellt wird.

Nachdem ein Überblick über existierende Standards gegeben wurde, werden Anforderungen an die Möglichkeiten temporaler Annotation formuliert und Bewertungen der bestehenden Ansätze vorgenommen.

2.1 Sprachen

Die fortschreitende Vernetzung über das Internet hat den Drang zur Interoperabilität zwischen Systemen und Programmen stark in den Vordergrund gebracht. Als Standardformat für den Austausch von Daten hat sich die eXtensible Markup Language (XML) etabliert, deren Verwendung im folgenden Abschnitt motiviert wird und deren Eigenschaften beschrieben werden.

2.1.1 XML

Bei der maschinellen Datenverarbeitung entsteht immer auch die Notwendigkeit der Datensicherung, der Datenkonservierung. Dabei müssen häufig die gesich-er- ten Daten von mehreren unterschiedlichen Programmen weiterverarbeitet werden, die möglichweise sogar von verschiedenen Herstellern stammen können. Weiter- hin entsteht durch die heute gängige Vernetzung von Computersystemen über Intra- oder Internet der Zwang zur Kommunikation zwischen Programmen. Deshalb sind Absprachen bzw. Protokolle notwendig, die von allen Beteiligten verstanden wer- den.

Zur Sicherung von Daten und zu deren Austausch wurde Mitte der 80er Jah- re die Standard Generalized Markup Language (SGML) [ISO86] normiert. Sie bietet vielfältige Möglichkeiten, die abzulegenden Daten zu strukturieren, um so die Interoperabilität verschiedener Systeme zu gewährleisten. SGML ist zwar sehr mächtig, die Verwendung stellte sich aber schnell als sehr kompliziert heraus. Um SGML-konform zu sein, also Dateien in SGML-Syntax lesen und generieren zu k önnen, müssen Programme sehr mächtig und komplex aufgebaut sein, und dies lässt die Sprache in der Anwendung eher unpraktisch erscheinen.

1996 wurden unter der Schirmherrschaft des WORLD WIDE WEB CONSOR- TIUMS (W3C) [W3C] das SGML EDITORIAL REVIEW BOARD und eine SGML- Arbeitsgruppe gegründet, aus denen sich später eine XML-Arbeitsgruppe und die XML SPECIAL INTEREST GROUP entwickelten. Unter Wahrung der Kompati- bilität zu SGML sollte eine neue, einfachere, universell einsetzbare Sprache für vielfältigste Anwendungen im Internet entstehen, die die Probleme von SGML vermied. So sollte es mit weniger Aufwand verbunden sein, Programme zu schrei- ben, die die sprachkonformen Dateien verarbeiten könnten. Auch sollte das Erzeu- gen und Warten dieser Dateien vereinfacht werden. So war es einer der Grundan- sprüche an die neue Sprache, dass sie für Menschen lesbar und (mit einiger Erfah- rung) verständlich sein müsste.

Das Ergebnis dieser Bemühungen ist die eXtensible Markup Language (XML) [W3C00a], eine eingeschränkte Form bzw. Untermenge von SGML [Cla97]. Sie beschreibt eine Klasse von Datenobjekten, die sogenannten XML-Dokumente und stützt sich dabei auf etablierte Standards, wie beispielsweise UNICODE [UCC96] f ür die Zeichendarstellung. Programme oder Programmteile, die diese Dokumente verarbeiten können, werden als XML-Prozessoren bezeichnet.

Datenobjekte, die der XML-Spezifikation [W3C00a] entsprechen, also XML- Dokumente, werden als wohlgeformt bezeichnet. Sie haben eine Baumstruktur mit einem Wurzelelement und mehreren Kindelementen, die ihrerseits Kindelemente haben können. Die Elemente werden in XML Entities genannt. Die Entities können aus Zeichendaten oder aus Markup bestehen; die Zeichendaten spiegeln die eigent- lichen Daten wieder, die in diesem Dokument abgelegt sind, die Markup-Entities bestimmen die logische Struktur. Enthält das Dokument eine Dokumenttypdekla- ration, und genügt seine Struktur diesem Typ, wird es als g ültig bezeichnet. Die Definition von Dokumenttypen wird im nächsten Abschnitt ab Seite 14 beschrie- ben.

Markup wird in Form von Tags in das Dokument integriert, die den Tags in HTML (HyperText Markup Language) sehr ähnlich sind.¹ Tags treten normaler- weise paarweise auf und bestehen aus einem Start- und einem End-Tag, zwischen denen die Kindelemente aufgereiht sind:

Abbildung in dieser Leseprobe nicht enthalten

F ür Entities ohne Kindelemente gibt es eine gesonderte Notation, die die Schreibweise abkürzt:

Abbildung in dieser Leseprobe nicht enthalten

Desweiteren können Tags unabhängig von eventuell enthaltenen Kindelementen sogenannte Attribute haben. Für jedes Attribut muss sein Wert aufgeführt werden, weshalb man auch von Attribut-Wert-Paaren spricht.

Abbildung in dieser Leseprobe nicht enthalten

Um deutlich zu machen, dass es sich bei einer Datei um ein XML-konformes Dokument handelt, enthält die erste Zeile immer den sogenannten Prolog, der außerdem Auskunft geben kann über die verwendete XML-Version, die benutzte Zeichenkodierung oder den Dokumenttyp. Eine wohlgeformte² XML-Datei könnte damit beispielsweise so aussehen:

Abbildung in dieser Leseprobe nicht enthalten

Der daraus resultierende Entitätenbaum ist in Abbildung 2.1 auf der nächsten Seite dargestellt.

Ein sehr wichtiger und dehalb namensgebender Aspekt von XML ist die Er- weiterbarkeit: Die Tags, die für das Markup benutzt werden, sind nicht festgelegt,

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1: Mitarbeiterliste: XML-Dokument als Entitätenbaum

sondern können je nach Domäne und Anwendungszweck selbst definiert werden. XML ist eine Metasprache, die zur Definition der eigentlichen Datensicherungsoder Datenaustausch-Sprache nur den standardisierten Rahmen liefert. Auf ihrer Basis sind viele Sprachen aufgebaut worden, darunter Industriestandards wie das Simple Object Access Protocol (SOAP) [W3C00b] oder die Web Services Description Language (WSDL) [W3C02e].

2.1.2 DTD und XML Schema

Der große Vorteil von XML, eigene Tags je nach Bedarf einführen zu können, stellt sich aber schnell als problembehaftet heraus: Bei geeigneter Wahl der Bezeichner scheinen die Tags zwar für den menschlichen Leser eine immanente Bedeutung zu haben, tatsächlich ist diese formal aber gar nicht spezifiziert. Ebenso ist weder festgelegt, welche Bedeutung die eingebetteten Daten haben, noch, wozu man sie benutzen kann.

Alle an einem Datenaustausch über XML-Dokumente Beiteiligten müssen sich deshalb zunächst auf ein gemeinsames Vokabular einigen. Für diesen Zweck exis- tieren zwei Verfahren, die Document Type Definition (DTD) [W3C00a, Abschnitt 2.8: Prolog and Document Type Declaration]³ und das XML Schema [W3C01d]. Beide dienen dazu, die zur Verfügung stehenden Elemente und deren Attribute zu definieren. Außerdem können sie von sogenannten Validatoren benutzt werden, um zu prüfen, ob ein Dokument gültig ist (siehe Seite 12).

Die DTD, das ältere der beiden Formate, ist etwas komplizierter zu handhaben und bietet weniger Möglichkeiten. Einfache Strukturen lassen sich damit aber gut beschreiben: Neben den erlaubten Elementen beschreibt es ihre möglichen Attri- bute, außerdem die Stellen, an denen Zeichendaten stehen dürfen. Für das obige Beispiel würde das bedeuten, dass jedes Element vom Typ person ein Attribut name und ein Kindelement telefon haben muss, beide jeweils vom Inhaltstyp Zeichenkette.

Der Nachfolger XML Schema, der die DTD ablösen soll, bietet darüber hin- aus noch weitere Möglichkeiten, genauere Regeln für die Dokumentenstruktur zu definieren. So wäre es im obigen Beispiel sinnvoll, das Auftreten des Kindele- ments telefon mehrmals, das des Kindelements raum hingegen nur einmal zu- zulassen. Weiterhin können Alternativen (im Beispiel: wias oder sh) oder Stan- dardwerte (hier beispielsweise für eine optionale Faxnummer) angegeben werden. Die Datentypen können außerdem sehr viel genauer spezifiziert werden; so ste- hen mehr vorgefertigte Typen zur Verfügung (für raum würde sich eine positive Ganzzahl anbieten), zusätzlich können neue Typen über reguläre Ausdrücke sehr exakt abgebildet werden (für telefon: Ziffern, Leerzeichen, Schrägstrich, run- de Klammern; am Anfang eine optionale Vorwahl in Klammern, die Klammern immer paarweise, etc.). Mittels Inklusion und Ableitung lassen sich einmal spe- zifizierte Schemata komfortabel weiterentwickeln und weiterbenutzen. Ein XML Schema wird im Gegensatz zu einer DTD in XML notiert, stellt also selbst ein wohlgeformtes, gültiges Dokument dar.

2.1.3 Erweiterungen

XML bietet mehrere Erweiterungen, die die Entwicklung neuer XML-basierter Sprachen wesentlich vereinfachen und verbessern. Zwei davon sollen hier kurz näher betrachtet werden, da sie für den späteren Verlauf der Arbeit relevant sein werden: Namespaces und XML Inclusions.

2.1.3.1 Namespaces

Modularisierung ist in der Softwareentwicklung ein verbreiteter Weg, um durch den Einsatz bereits entwickelter und getesteter Programmteile mehr Komfort (Weiterbenutzung bereits implementierter, nützlicher Funktionen) und Sicherheit (die Module sind schon weitestmöglich auf ihre Korrektheit verifiziert) zu erreichen. Es liegt nahe, diesen Ansatz auch bei der Benutzung XML-basierter Sprachen zu verfolgen. Bei der Verwendung von bekanntem (well known) Vokabular kann sich so der Entwicklungsaufwand erheblich reduzieren.

Der Mechanismus, um Elementen die Zugehörigkeit zu einer bestimmten Do- mäne bzw. zu einem bestimmten Vokabular zuzuschreiben, wird als Namespaces [W3C99b] bezeichnet und ist sehr ähnlich zu der gleichnamigen Technik in C++ oder der Paketstruktur von JAVA. Dabei werden die benutzten Tags qualifiziert; da- zu werden ihnen mit einem Doppelpunkt abgetrennte Bezeichner vorangestellt. Die Zuordnungen dieser Präfixe zu den Domänen, aus denen sie stammen, werden für gewöhnlich über Schlüsselwörter im Wurzelelement des Dokuments hergestellt; dort wird auch der Standard-Namespace für alle Kindelemente festgelegt. Zusätzlich kann man an jeder Stelle auch direkt zu einem beliebigen Tag das benutzte Vokabular angeben. Beide Vorgehensweisen benutzen Uniform Resource Identifiers (URI) [BLFM98], um den Urheber oder den Standard und somit die Herkunft der Elemente eindeutig zu kennzeichnen.

Das folgende Beispiel erweitert jenes von Seite 13 um einen Standard-Name- space, der an den URI http//www.tzi.de/ns/default gebunden ist, Na- mespaces, die bei allen Kindelementen benutzt werden können (int, mob), und die explizite Angabe eines eigenen Namespaces bei dem Tag status:

Abbildung in dieser Leseprobe nicht enthalten

Die Unterscheidung zwischen den beiden telefon-Varianten könnte an dieser Stelle sinnvoll sein, wenn man über ein XML Schema nur ganz bestimmte Schreib- weisen zulassen wollte: bei int:telefon beispielsweise vier Ziffern, bei mob: telefon eine Aneinanderreihung von der 01??-Vorwahl, einem Schrägstrich und sechs bis zehn Ziffern.⁴ Dies verdeutlicht auch noch eine weitere Vereinfa- chung durch die Benutzung von Namespaces: Tag-Namen können mehrfach ver- wendet werden - auch aus ganz unterschiedlichen Quellen respektive Standards -, da durch die Qualifizierung mit den Bezeichnern keine Ambiguitäten auftreten k önnen.

2.1.3.2 XInclude

Ein ebenfalls von den Modularisierungsbestrebungen etablierter Programmierspra- chen adaptierter Mechanismus ist das Einbinden (Inkludieren) von bestehenden Dokumenten oder Dokumentfragmenten: XML Inclusions (XInclude) [W3C02g]. Da dazu normale XML-Konstrukte, namentlich Elemente, Attribute und URIs be- nutzt werden, fügt sich diese Technik nahtlos in die Dokumentenstruktur ein. Das folgende Beispiel repräsentiert damit ein neues Dokument, das aus den drei ange- gebenen Dateien zusammengesetzt ist.

Abbildung in dieser Leseprobe nicht enthalten

Der XInclude-Standard stellt dabei nur das Vokabular und den Namespace zur Verfügung; um den tatsächlichen Vorgang des Zusammenfügens muss sich der Pro- grammentwickler kümmern. Leistungsfähige Parser wie XERCES aus dem APA- CHE XML PROJECT [AXP, ASF], die als Softwaremodule zur Verfügung stehen, bieten aber mittlerweile Erweiterungen, die das Einbinden transparent vornehmen.

2.2 Metadatenformate

XML wird dazu eingesetzt, strukturierte Daten in einer maschinen- und menschenlesbaren Form abzulegen; XML Schemata dienen dazu, die Form der Daten festzuschreiben, indem Markup-Elemente und Datentypen festgelegt und zu einer Dokumentenstruktur zusammengefügt werden.

Diese Basis kann aber nicht nur dazu benutzt werden, um Daten standardisiert ablegen und austauschen zu können. Auch die bereits in Abschnitt 1.1.1 auf Seite 2 eingeführten Metadaten können in XML notiert werden.

2.2.1 RDF

Das Resource Description Framework (RDF) [W3C99c] ist ein Formalismus, um Metadaten, also Daten über Daten, festzuhalten. Obwohl der Ansatz nicht zwingend den Gebrauch von XML-Syntax vorschreibt, wird im praktischen Einsatz im Internet meist sinnvollerweise diese Notation benutzt. RDF ist domänenneutral und deshalb im Rahmen seiner Möglichkeiten universell einsetzbar.

Die Grundlage von RDF bilden die drei Konzepte Resource, Property und Statement. Als Ressource werden all die Objekte bezeichnet, deren Metadaten fest- gehalten werden sollen. Dabei kann es sich um Gegenstände, Personen oder belie- bige andere Entitäten handeln; im Internet werden dies meistens Webseiten oder

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2: Webseitenannotation: RDF-Struktur in Graphnotation

andere Informationsquellen sein. Properties sind die Eigenschaften oder Aspek- te einer Resource, die beschrieben werden sollen. Statements sind schließlich die Aussagen, die ein in RDF notiertes Dokument trifft. Sie bestehen aus Tripeln, die aus einem Subjekt, einem Prädikat und einem Objekt aufgebaut sind. Das Subjekt beschreibt eine Ressource, über die eine Aussage getroffen werden soll, das Prädi- kat eine ihrer Properties, und das Objekt den Wert dieser Property. Bei letzterem kann es sich wiederum um eine Ressource handeln - dann beschreibt das Statement eine Relation zwischen zwei Ressourcen -, oder um ein Literal, beispielsweise eine Zeichenkette oder eine Zahl.

Abbildung 2.2 zeigt ein Beispiel in Graphnotation; in XML-Notation hat es die folgende Form:

Abbildung in dieser Leseprobe nicht enthalten

Es trifft über die Ressource ”http://www.tzi.de/˜visser/“mehrereAussagen: Die Ressource hat eine Eigenschaft benannte Ressource ist. ”Creator“,derenWerteineandere,un- Diese unbenannte Ressource hat eine Eigenschaft ”Ubbo“alsWert, außerdem besitzt sie eine weitere Eigenschaft ”Name“mitdemLiteral ”Fon“mitdemWert ”7840“.

RDF macht keinerlei Aussagen über die zur Verfügung stehenden Properties oder deren Bedeutung. Ebenso wie XML, das auch nur den Rahmen vorgibt und XML Schema für die konkrete Spezifikation einer Datenaustauschsprache benutzt, benötigt RDF eine Erweiterung, um domänen- und anwendungsspezifische Struk- turen zu definieren.

2.2.2 RDF Schema

Zur Festlegung von Properties kommt in RDF ein RDF Schema (RDFS) [W3C02b] zum Einsatz. Außerdem können Klassen von Ressourcen spezifiziert werden, de- nen die Properties zugeordnet werden, oder die als Argument von Properties in Betracht kommen. Beispielsweise ist bei einer Klasse ”Buch“eineEigenschaft ”Autor“sinnvoll,fürderenBelegungnureineRessourcevomTyp ”Mensch“oder ”Person“zugelassenist.GenauwieeinXMLSchemafüreinXML-Dokumentde- finiert also ein RDF Schema das für das RDF-Dokument zur Verfügung stehende Vokabular.

Mit Hilfe von Class/subClassOf- bzw. Property/subPropertyOf- Konstrukten erlaubt RDFS das Anlegen von Klassen- bzw. Eigenschafts-Hierar- chien. Welche Klassen von Ressourcen eine bestimmte Eigenschaft besitzen bzw. welche Klassen als deren Ausprägung in Frage kommen, wird über domain bzw. range festgelegt. Im Beispiel aus dem letzten Absatz hätten alle Bücher den type ”Buch“,dereineUnterklassevon ”Veröffentlichung“darstellenkönnte.Alle Veröffentlichungen hätten eine Eigenschaft hätten), deren Ausprägungen alle der Klasse ”Autor“(dendamitauchalleBücher ”Mensch“angehörenmüssten.Abbil- dung 2.3 auf der nächsten Seite zeigt diese Zusammenhänge in Graphnotation.

Mit dem durch ein RDF Schema definierten Vokabular ist es nun möglich, Informationen über Ressourcen in RDF zu notieren, diese Metadaten zu interpretieren und zu validieren. Allerdings muss auch hier zunächst festgelegt werden, welches Vokabular zum Einsatz kommt, welche Klassen von Ressourcen und welche Properties demnach eingesetzt werden können.

Es sind also weiterreichende Standards nötig, die auf der Basis von XML/XML Schema/RDF/RDFS aufbauen und den Metadaten eine festgelegte Bedeutung zu- schreiben. Es gibt mehrere Initiativen, die sich dieser Problematik angenommen haben, darunter die Simple HTML Ontology Extensions (SHOE) [LSRH97, SHO] (SHOE wird mittlerweile zu Gunsten von OWL und DAML+OIL nicht mehr wei- terentwickelt), das Ontology Inference Layer (OIL) [FHvH 00, OIL], die DARPA Agent Markup Language (DAML) [DAR], DAML+OIL [DOC01, W3C01b] und die erst als Working Draft des W3C existierende Ontology Web Language (OWL) [W3C02d].

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.3: Klassen, Eigenschaften, Typen: RDFS-Struktur in Graphnotation

2.2.3 Dublin Core

Die für diese Arbeit wichtigste RDF/RDFS-Anwendung bzw. -Erweiterung⁵ ist der Dublin Core Metadata Standard (Dublin Core, DC). Er wird von der DUBLIN CO- RE METADATA INITIATIVE (DCMI) [DCM] definiert, einer internationalen, inter- disziplinären Gruppe von Experten für Büchereiwesen, Informationstechnologie, Textrepräsentation, Museumswesen und verwandte Bereiche [Hil01d].

Dublin Core etabliert zur Annotation 15 Kernelemente [DCM99], deren Auswahl und Semantik durch die Expertengruppe festgelegt wurde; Ziel war hierbei, die Anwendung einfach und effektiv zu halten und trotzdem eine große Bandbreite von Netzresourcen beschreiben zu können - auch wenn der Fokus klar auf (Text-) Dokumenten und dokumentenähnlichen Ressourcen liegt.

Die Tabelle 2.1 auf der nächsten Seite zeigt einen Überblick über die zur Verfü- gung stehenden Elemente und deren Zugehörigkeit zu den Bereichen Content, In- tellectual Property und Instantiation. Grundsätzlich sind die Elemente alle optional und können beliebig oft wiederholt werden, wobei das mehrfache Aufführen eine Reihenfolge oder Prioritätenvergabe implizieren kann, aber nicht muss. Der Inhalt wird im einfachsten Fall über eine Zeichenkette angegeben. Hier zeigen sich aber

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2.1: Dublin Core Metadata Element Set

schnell zwei Unzulänglichkeiten des Basisansatzes: Das Thema eines Elements kann zu weit gefasst sein, außerdem ist die Beschränkung auf eine Zeichenkette nicht rigide genug; tatsächlich kann man in einem String beliebige Daten ablegen.

Beide Problemfelder haben zur Erweiterung des Standards durch Qualifier geführt [DCM00b]. Diese haben zwei zentrale Aufgaben:

Element Refinement Die Bedeutung eines Elements soll eingeschränkter oder spezifischer werden. Da es sich hier um eine Beschränkung und nicht um eine Erweiterung handelt, können Benutzer, die eine bestimmte Verfeine- rung nicht kennen, diese ignorieren, und die enthaltenen Daten unter der Bedeutung des übergeordneten Elements betrachten.

Ein Beispiel ist hierfür das Element Description: Die beiden Qualifier Description.tableOfContents und Description.abstract weisen viel genauer als das Grundelement allein auf den Inhalt hin. Trotzdem ist es möglich, die Verfeinerungen nicht zu beachten und den Inhalt weiterhin unter der Bedeutung ”Beschreibung“zubetrachten.

Encoding Scheme Häufig ist es sehr sinnvoll, genauere Angaben zum erlaubten Inhalt bzw. zu dessen Kodierung zu machen. Sehr empfehlenswert sind da- bei kontrollierte Vokabulare, die nur ganz bestimmte Ausprägungen eines Elements erlauben. Alternativ kann man der Form, in der Daten auftreten k önnen, restriktivere Beschränkungen über formale Notationen oder Par- sing-Regeln auferlegen.

Bei dem Element Subject wird deshalb beispielsweise vorgeschlagen, eta- blierte kontrollierte Vokabulare wie die LIBRARY OF CONGRESS CLASSI- FICATION (LCC) [LCC] oder die MEDICAL SUBJECT HEADINGS (MeSH) [MeS] einzusetzen; das hat als praktischen Nutzen auch den Vorteil, dass sich ein Entwickler nicht um die Erzeugung und Pflege der Listen kümmern muss, da dies von ausgewiesenen Experten übernommen wird.

Es gibt darüber hinaus auch Qualifier, die verfeinern und zusätzlich dem In- halt Beschränkungen auferlegen. So wird das sehr allgemein gehaltene Ele- ment Relation wesentlich spezifischer beschrieben durch Relation.

replaces, Relation.isReplacedBy, Relation.hasPart, Relation.isPartOf, etc.; darüber hinaus wird für die enthaltene Zeichenkette das URI-Format [BLFM98] des W3C festgelegt.

Obwohl Dublin Core von vornherein dafür ausgelegt war, sehr unterschiedliche Ressourcen beschreiben zu können, war ebenso die Notwendigkeit abzusehen, neue Qualifier einzuführen, die andere Verfeinerungen und/oder Notationen böten. Deshalb wurden für die Neuentwicklungen Ansprüche formuliert, die neben den oben erwähnten grundsätzlichen Eigenschaften zu erfüllen sind:

1. Die Definitionen neuer Element-Refinements müssen öffentlich zugänglich sein.
2. Die explizite Beschreibung eines Encoding Schemes muss klar definiert und öffentlich zugänglich sein.

Bei den Erweiterungen von Dublin Core, die in der vorliegenden Arbeit vorgeschlagen werden, finden beide Anforderungen Berücksichtigung.

Bei einer Arbeit, die sich mit Zeit beschäftigt, sind die beiden Dublin Core Ele- mente, die temporale Aspekte betreffen, von besonderer Bedeutung. Bei dem einen Element handelt es sich um das Feld Date mit seinen Verfeinerungen Created,

Valid, Available, Issued und Modified. Der eher ”technischen“Aus- richtung dieses Elements wird dadurch Rechnung getragen, dass es zum Bereich Instantiation zählt (Tabelle 2.1 auf der vorherigen Seite). Die in der Zielsetzung gesetzten Schwerpunkte liegen aber stärker auf dem Betrachtungszeitraum.⁶

Das Element Coverage und speziell seine Verfeinerung Coverage.Temporal (C.T) sind deshalb von wesentlich größerer Bedeutung für diese Arbeit. C.T wird dabei definiert als ”Temporalcharacteristicsoftheintellectualcontentoftheresource.“

[DCM00b] Offensichtlich fällt der Betrachtungszeitraum unter diesen ”intellectualcontent“, auch wenn die obige Definition so ungenau ist, dass eigentlich eine weitere Verfei- nerung notwendig wäre. Leider sieht Dublin Core zweistufige Qualifier nicht vor. Das Element ist aber auch so für die Zwecke dieser Arbeit sinnvoll einzusetzen.

Zwei Encoding Schemes werden für C.T vorgeschlagen. Es sind die glei- chen, die auch bei Date und seinen Verfeinerungen zur Anwendung kommen sollen: Das W3C Date Time Format (W3C-DTF) [W3C98] und die DCMI Peri- od [DCM00a].

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2.2: W3C Date Time Format: Granularitätsebenen

2.2.3.1 W3C Date Time Format

Ersteres ist eine Vereinfachung von ISO 8601 [ISO00a], dem internationalen Stan- dard für Datums- und Zeitangaben. Dieser enthält aber mehrere verschiedene No- tationsmöglichkeiten mit vielen optionalen Elementen. W3C-DTF bietet dagegen eine einfache Syntax mit sechs auf einander aufbauenden Granularitätsebenen, die in Tabelle 2.2 aufgeführt sind. Trotz dieser Beschränkungen, die die Entwicklung standardkonformer Programme wesentlich vereinfachen, bleibt der Mangel, dass mit diesem Format nur Zeitpunkte und keine Zeitintervalle beschrieben werden k önnen.

2.2.3.2 DCMI Period

Die DCMI Period kombiniert deshalb bis zu zwei W3C-DTF-Instanzen zu einem Intervall, wobei auch offene Grenzen Beachtung finden: Die beiden Seiten haben die Standardwerte negativ bzw. positiv unendlich und repräsentieren damit eine schon bzw. noch andauernde Zeitspanne. Außerdem ist die Angabe von Namen f ür Zeitintervalle erlaubt, sowohl zur Benennung einer neuen DCMI Period, als auch als Referenz für den Beginn oder das Ende bei ihrer Definition. Zum Stan- dard gehört zwei Notationen, die Daten in einen String oder in ein XML-Element kodieren; letzteres findet im folgenden Beispiel Anwendung:

Abbildung in dieser Leseprobe nicht enthalten

2.3 Temporale Annotation

Nachdem die Grundlagen auf den verschiedenen Ebenen - Datenbeschreibungs- sprache, Metadatenbeschreibungssprache, Metadatenstandard - gelegt wurden, er- gibt sich die Frage, welche Anforderungen an die temporale Annotation gestellt werden und ob sie von den bestehenden Ansätzen schon erfüllt werden können.

2.3.1 Anforderungen an temporale Annotation

Aus den in Abschnitt 1.1.2 auf Seite 4 gesteckten Zielen, Annotation und Retrieval im Semantic Web flexibler, komfortabler und praxistauglicher als bisher zu machen, ergeben sich eine Reihe von Anforderungen an die Funktionalitäten der dazu eingesetzten Zeitintervalle. Dabei sollen dem Anfragenden oder dem Modellierenden möglichst vielfältige Optionen zur Verfügung stehen, aus denen er die für seine Anwendungszwecke adäquateste Variation auswählen kann.

2.3.1.1 Benennung

Die erste und wichtigste Anforderung stellt dabei die Möglichkeit dar, intuitive Namen bei der Definition der Intervalle zu vergeben. Diese Namen sollen dann bei der Anfrage und bei der Annotation benutzt werden können. Dazu zählt auch die Möglichkeit, die Intervalldefinitionen zu veröffentlichen und damit als Refe- renzintervalle für die weitere interne oder externe Verwendung bereitzustellen.

Um der weltweiten Verbreitung des Internets gerecht zu werden, sind neben dem lateinischen Alphabet auch Umlaute, Akzente und andere landes- und sprach- typische Besonderheiten zu berücksichtigen. Es bietet sich an, die in diesem Be- reich existierenden Standards heranzuziehen, allen voran UNICODE [UCC96]. Da die zu vergebenden Namen normierende Funktion haben sollen (Abschnitt 2.3.1.3), ist es sinnvoll, den Unicode-Standard geringfügig einzuschränken und den XML- Standard für Namen [W3C00a, Abschnitt 2.3: Common Syntactic Constructs/Na- mes and Tokens] als maßgebend vorzuschreiben, um die Kompatibilität mit XML zu gewährleisten.

2.3.1.2 Grenzen

Die Grenzen der Intervalle sollen in mehreren Ausprägungen zur Verfügung stehen, um so unterschiedlichen Bedürfnissen gerecht zu werden. Dabei ist es notwendig, dass die Grenzen auf beiden Seiten des Intervalls unterschiedlichen Typs sein d ürfen; im Folgenden wird deshalb nur auf die verschiedenen Arten eingegangen, alle sich daraus ergebenden Kombinationen müssen erlaubt sein.

Exakte Grenzen repräsentieren einen bekannten, genauen Anfang bzw. ein eben- solches Ende, und stellen damit den einfachsten Fall dar. Als Grundlage für das Enkodierungsschema bietet sich hier der Internetstandard W3C-DTF an ([W3C98]; Abschnitt 2.2.3.1 auf Seite 23 in dieser Arbeit).

Das Format bietet verschiedene Granularitätsebenen, von der reinen Jahres- nennung bis zur Angabe eines Datums mit Uhrzeit auf Millisekundenniveau. Durch die Bandbreite der im Internet gesammelten Daten sind diese Abstu- fungen sinnvoll und nötig: Historische Beschreibungen werden häufig mit der Angabe von Jahr, Monat und Tag auskommen (Regierungszeiten, Le- bensläufe), bei aktuellen Informationen werden oft zusätzlich Uhrzeiten zur Anwendung kommen (Nachrichten, Veranstaltungen), und bei technisch ori- entierten Daten kann die Angabe des genauen Zeitraums bis hinunter zur Millisekunde nötig sein (Experimentaldaten, Transaktionsprotokolle).

Trotzdem ist das W3C-DTF noch nicht ausdrucksmächtig genug, da es nur einen Bereich zwischen dem Jahr 1 und dem Jahr 9999 unserer Zeitrech- nung definiert. Obwohl die obere Grenze als ausreichend für den bei weitem überwiegenden Teil der betrachteten Informationen angesehen werden kann, stellt die untere Grenze eine zu große Einschränkung für den praktischen Einsatz dar: Schon eine Biografie von Julius Caesar könnte nicht zeitlich be- schrieben werden. Eine Erweiterung in die vorchristliche Zeit ist demnach dringend notwendig.

Unscharfe Grenzen spiegeln den Fall wieder, dass eine Begrenzung zwar un- gefähr bekannt ist, aber nicht exakt festgelegt werden kann. Für den Be- ginn eines Intervalls ist es dann sinnvoll, den ”frühestenAnfang“undden ”spätestenAnfang“anzugeben;beieinemunscharfenEndewirdebensover- fahren.

Dieser Typ einer Grenze kommt zum Einsatz, wenn es über ihre Ausprägung unterschiedliche Ansichten, beispielsweise Expertenmeinungen, gibt, oder die Angabe einer exakten Grenze nicht sinnvoll erscheint bzw. der intuitiven Auffassung widerspricht. Diese Fälle treten bei sehr vielen umgangssprachlichen Begriffen auf, sind demnach sehr häufig anzutreffen und dementsprechend wichtig. So hat der Benutzer zwar für gewöhnlich eine sehr genaue Vorstellung davon, welchen Zeitraum er mit ”Mittelalter“repräsen- tiert wissen möchte, er kann ihn aber nicht auf exakte Zeitpunkte für die Intervallgrenzen beschränken.

Bei der Berechnung der Relevanz eines solchen Intervalls bezüglich einer Anfrage muss diese Besonderheit dann berücksichtigt werden. Ein unschar- fer Anfang definiert so eine ansteigende, ein unscharfes Ende eine fallende Relevanz (Kapitel 5 ab Seite 71). Da hier Techniken in Anlehnung an die Fuzzytheorie Verwendung finden, werden derartige Grenzen in diesem Mo- dell alternativ auch als ”fuzzy“bezeichnet.

Persistente Grenzen werden bei der Definition verwendet, wenn die angegebene Seite unbeschränkt ist, das Intervall also schon bzw. noch andauert.

Dieser Grenztyp wird für das Intervallende benötigt, wenn der Zeitraum zum Zeitpunkt der Betrachtung noch nicht beendet ist und eine Beendigung auch nicht abgeschätzt werden kann.⁷ Bei wissenschaftlichen Beschreibungen ist dieser Fall wesentlich häufiger anzutreffen als in der zivilen Praxis, da hier Zeiträume zum Einsatz kommen, die einen definierten Anfangszeitpunkt, aber kein geplantes Ende haben; die Aussendung einer Sonde in den Welt- raum oder die Durchführung einer Langzeitbeobachtung sind hier typische Beispiele.

Bei einem Intervallanfang ist der verwandte Fall möglich, dass ein Zeitraum vor dem annotierbaren Zeitrahmen begann. Anstatt jenen minimalen Wert als Grenze einzutragen, der von einer tatsächlich auf diesem Punkt liegenden Grenze nicht zu unterscheiden wäre, kann dann der Typ persistent verwendet werden.

Unbekannte Grenzen werden nötig, wenn keinerlei Daten bekannt sind, um An- fang bzw. Ende eines Intervalls einzugrenzen. Mit ihnen wird es möglich Intervalle zu definieren, bei denen nur eine der beiden Seiten begrenzt ist, über die andere aber keine Aussage getroffen wird. Selbst wenn beide Gren- zen unbekannt sind, besteht immer noch die Möglichkeit, Aussagen über qualitative Relationen bezüglich anderer Intervalle zu treffen.

Die Abgrenzung zu unscharfen oder persistenten Grenzen ist nicht immer eindeutig und hängt von der Intention bei der Modellierung eines Intervalls ab. Ist beispielsweise von einer Person der Geburtstag bekannt, der Todes- tag aber nicht, liegt die Verwendung einer unbekannten Grenze für das En- de der Lebensspanne nahe. Vielleicht existieren aber Hinweise, zu welchen Zeitpunkten die Person auf jeden Fall noch gelebt hat (Briefe, amtliche Ver- merke), und zu welchen sie auf jeden Fall schon tot war (ebenfalls Briefe, Berichte, etc.); damit könnte dann eine unscharfe Grenze beschrieben wer- den. Lebt die Person dagegen noch, könnte auch eine persistente Grenze benutzt werden, um diesen Umstand zu berücksichtigen. Bei der Modellie- rung muss entscheiden werden, welche Variation für den speziellen Fall am geeignetesten ist.

2.3. TEMPORALE ANNOTATION

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2.3: Kombinationen von Intervallgrenzen

Der Sonderfall von zwei unbekannten Grenzen führt zunächst zu der grundsätzlichen Aussage, dass ein Intervall mit dem angegebenen Namen existiert. Im Zusammenhang mit expliziten Relationen (s.u.) können dennoch weitere Aussagen getroffen werden.

In der Tabelle 2.3 werden einige Kombinationen von Intervallgrenzen beispielhaft aufgeführt und erläutert.

2.3.1.3 Strukturen

Intervalle sollen auf anderen Intervallen - selbst definierten oder importierten - aufbauen können. Dazu müssen sowohl die exakten als auch die unscharfen Gren- zen von Anfang und Ende herangezogen werden können; dadurch kann beispiels- weise das exakte Ende eines Intervalls durch den frühesten Beginn eines anderen bestimmt werden. Da für diese Verknüpfung Zeitpunkte benötigt werden, müs- sen Funktionen zur Verfügung stehen, die diese signifikanten Punkte aus den Re- ferenzen extrahieren ( ”Anfangvon“, ”Endevon“bzw. ”frühesterAnfangvon“, ”spätesterAnfangvon“, ”frühestesEndevon“, ”spätestesEndevon“).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.4: Intervallstruktur

Ein Beispiel für die Verknüpfung der verschiedenen Möglichkeiten ist das In- tervall ”Mittelalter“(Abbildung2.4 ),dashistorischnichteindeutigfestgemacht werden kann. Es gibt aber verschiedene Ereignisse, die als Anfangs- bzw. End- punkt diskutiert werden. Welche davon für eine eigene Definition dieses Zeit- raums benutzt werden, hängt davon ab, welche Quellen oder Experten für maßge- bend oder besonders wichtig gehalten werden; die hier gezeigte Version entstammt [Pit 02, Ise 02 ].

Durch die Referenzierung ergeben sich auf einander aufbauende Strukturen, und damit auch implizite qualitative Relationen zwischen den Intervallen. Sie müs- sen zusätzlich zu den explizit angegebenen (siehe nächster Abschnitt) für Anfra- gen zur Verfügung stehen und auch die gleiche Mächtigkeit bieten (Weitergabe von transitiven Relationen, etc.). Wird wie im obigen Beispiel für den frühesten Anfang des Mittelalters das (eventuell unscharfe) Ende des Weströmischen Rei- ches herangezogen, ergibt sich daraus, dass ersteres später beginnt als zweiteres, zwischen den beiden also die gerichtete Beziehung richtung ”jünger“bzw.inderGegen- ”älter“gilt.WeiterhinergibtsichausderobigenAbbildung,dasssichdas Mittelalter und die Herrschaft Karls des Großen überschneiden, beide Intervalle also teilweise gleichzeitig existierten.

2.3.1.4 Explizite qualitative Relationen

Weiterhin soll es möglich sein, bei der Definition qualitative Aussagen über Rela- tionen zwischen Intervallen zu treffen. Neben den impliziten Relationen, die sich

Abbildung in dieser Leseprobe nicht enthalten

aus der Referenzierung von Anfangs- und Endpunkten zur Festlegung von schar- fen oder unscharfen Grenzen ergeben (siehe vorheriger Abschnitt), können damit auch Aussagen zu Intervallen mit persistenten oder unbekannten Grenzen gemacht werden.

Sogar mit unbekannten, aber benannten Zeiträumen kann so gearbeitet werden. Dies ist sehr nützlich, wenn auf exakte Festlegungen kein Wert gelegt wird und nur die qualitativen Beziehungen von Bedeutung sind. So wird es beispielsweise m öglich historische Epochen zu definieren, zeitlich zu ordnen, andere Zeitspannen (Regierungszeiten, Lebensläufe, Reisen, Entwicklungen, etc.) als teilweise gleich- zeitig zu den Epochen zu beschreiben und dann zwischen jenen die zeitlichen Be- ziehungen ableiten zu lassen.

Es existieren sehr viele umgangssprachliche Begriffe für qualitative Beziehun- gen zwischen Intervallen. Je mehr davon zur Modellierung der Annotation oder der Anfrage zur Verfügung bestehen, desto komfortabler wird ein eingesetztes System zu benutzen sein.

2.3.2 Bewertung bestehender Ans ätze

Dublin Core stellt mit dem verfeinerten Element Coverage.Temporal die geeignete Umgebung bereit, um relevante zeitbezogene Daten wie den Betrachtungszeitraum abzulegen. Das zur Beschreibung von Zeitspannen vorgeschlagene Format DCMI Period bietet aber nicht die nötige Mächtigkeit, um die im obigen Abschnitt beschriebenen Anforderungen zu erfüllen.

Benennung Der Name, der für ein solches Intervall vergeben werden kann, ist grundsätzlich optional und nicht-norminativ, er kann nur zusätzlich zu den maßgebenden Intervallgrenzen vergeben werden. Tritt ein ”Konflikt“(was das alles umfassen soll, ist im Standard nicht genauer ausgeführt) zwischen dem Namen und den Grenzen auf, haben letztere Vorrang. Wie diese Konflikte, die als Widersprüche interpretiert werden können, identifiziert werden sollen, ist ebenfalls nicht beschrieben. Ebenso wird keine Aussage über das zu verwendende Kodierungsformat gemacht.

Letztendlich dient die Vergabe eines Namens hier eher der Anzeige (Webseite, grafische Benutzeroberfläche) als der Verbesserung der Mächtigkeit der Annotation und des Retrievals.

Grenzen Die Intervalldefinition kennt nur exakte oder persistente Grenzen, wobei letztere den Standardwert darstellen.

Bei den exakten Grenzen wird als Kodierungsschema das W3C-DTF als n ützlich angesehen, weshalb dies auch als Standardwert für einen optionalen, die Kodierung beschreibenden Parameter vorgegeben ist. Wie oben beschrie- ben (Abschnitt 2.3.1.2) kann das W3C-DTF aber nicht mit Datumsangaben vor dem Beginn unserer Zeitrechnung umgehen, was durch die Angabe und Verwendung eines anderen Formats kompensiert werden müsste.

Da unscharfe und unbekannte Grenzen nicht zur Definition benutzt werden k önnen, ist bei der Modellierung häufig zu entscheiden, ob fälschlicherwei- se ein exakter Wert angeben wird, der nicht von einem tatsächlich an diesem Zeitpunkt liegenden Anfang bzw. Ende zu unterscheiden ist, oder ob kein Wert angegeben wird und eine persistente Begrenzung Verwendendung findet, was in den meisten Fällen noch weniger sinnvoll erscheint.

Strukturen Zur Definition können auch bereits bekannte Intervalle herangezogen werden. Dabei kommt ”maximaleInklusion“zumEinsatz:Wirdbeispiels- weise zur Festlegung des Startpunkts ein weiterer, benannter Zeitraum her- angezogen, wird von diesem der Beginn übernommen; die Definition des Endpunkts wird analog vorgenommen. Mit diesem Vorgehen ist es nicht m öglich, für den Beginn eines Intervalls das Ende eines anderen zu ver- wenden. Dies geht nur über die Benutzung von expliziten Daten, mit allen sich daraus ergebenden Problematiken: Inkonsistenzen, Überschneidungen, L öcher bei eigentlich kontinuierlich geplantem Zeitverlauf, etc.

Der Standard bietet so zwar die Möglichkeit auf einander aufbauender Strukturen; der Verwendung sind aber enge Grenzen gesetzt, die Mächtigkeit ist stark eingeschränkt.

Explizite qualitative Relationen Die explizite Angabe von qualitativen Relatio- nen ist im Standard nicht vorgesehen, ist im Umfeld seiner derzeitigen Aus- prägung aber auch gar nicht sinnvoll. Da nur exakte und persistente Grenzen bei der Intervalldefinition zur Verfügung stehen, können alle Relationen di- rekt errechnet werden, auch wenn auf diese Möglichkeit gar nicht eingegan- gen wird.

Erst bei einer Erweiterung um unbekannte Grenzen ergibt sich die Notwen- digkeit, durch zusätzlich angegebene Beziehungen zwischen den eingeführ- ten Intervallen die Schlussfolgerungsmöglichkeiten erheblich zu erhöhen. Da unbekannte Grenzen aber deutlich mehr Variationsmöglichkeiten bieten und die Leistungsfähigkeit bei der Modellierung stark erhöhen, ist dieser Schritt dringend erforderlich.

Zusammenfassung

Abschließend ergibt sich die Feststellung, dass die DCMI Period bei der tempo- ralen Annoation zwar einen guten Ausgangspunkt als Format für Coverage. Temporal bietet, die formulierten Anforderungen aber nur teilweise erfüllt wer- den können. Daraus leitet sich die Notwendigkeit zur Entwicklung von eigenen Konzepten und Vorgehensweisen ab. Im folgenden Kapitel werden deshalb zu- nächst die Grundlagen zeitlicher Repräsentation und Schlussfolgerungsstrategien beschrieben, um daran anschließend in Teil II einen eigenen Ansatz vorzustellen.

Kapitel 3 Temporale Repräsentation und temporales Schließen

Im letzten Kapitel wurden die Grundlagen für die Daten- und Metadatenrepräsentation gelegt und Anforderungen an die temporale Annotation formuliert. In dem folgenden Kapiteln werden nun die Repräsentation von Zeit und das Schließen mit zeitlichen Relationen näher betrachtet.

Zeit und Raum

Jedwedes menschliches Verhalten ist in Zeit und Raum verankert [HHPS00], auch wenn sich der Mensch dieses Umstandes nicht dauernd bewusst ist. Er wird viel- mehr als ganz ”natürlich“angesehen,wasdazuführt,dassReferenzierungenvon Zeitpunkte/Zeiträumen oder Orten, wenn sie denn auftreten, fast durchweg von qualitativer Ausprägung sind und stark abstrahieren. Typische Formulierungen wie ”WirgehenheuteabendinsKino.“oder ”MeinAutostehthinterdemHaus.“wei- sen darauf hin, dass eine größere Exaktheit meist gar nicht notwendig, oftmals sogar hinderlich ist: Es ist unnötig, eine genaue Uhrzeit für den Kinobesuch anzugeben, wenn es viel mehr um das abendliche Ziel an sich geht, und es ist höchst unsinnig, den genauen Standort des Autos mit Längen- und Breitengrad anzugeben, wenn die obige Beschreibung erklärend genug ist. Letzteres Beispiel verdeutlicht dabei den Nachteil, dass zu hohe Genauigkeit den gegenteiligen Effekt haben kann, die Angabe also ihre erklärende Wirkung verliert.

Vor allem im technischen Bereich gibt es aber durchaus Situationen, in denen Exaktheit von Nöten ist, so bei der Herstellung von Geräten oder Werkzeugen oder bei der Planung von Abläufen. Ebenso ist die Wissenschaft auf die Genauigkeit ihrer Messergebnisse und Berechnungen angewiesen. Damit ergibt sich folgendes Bild: Der Mensch baut sich Repräsentationen von Zeit und Raum auf, die je nach Situation adäquat für die Umstände sein müssen.

[...]

---

¹ Sogenannte Wildcards bieten hier nur bedingt mehr Flexibilität: Auto* passt zwar auf Auto, Autos, Automobil und Automobile, aber auch auf Autor, Autopsie, etc.

¹ Tatsächlich ist HTML eine in SGML beschriebene Sprache. Da XML restriktiver ist als SGML, ist HTML nicht zu XML kompatibel; es existiert aber eine Neudefinition von HTML 4 namens XTML [W3C02f], die diese Kompatibilität herstellt.

² Wohlgeformt, aber nicht gültig: Im Beispiel ist keine Dokumenttypdefinition enthalten.

³ Der Prolog eines XML-Dokuments enthält eine Document Type Declaration, die auf eine Document Type Definition zeigt.

⁴ Nach [W3C01f] hätten die beiden dazu notwendigen regulären Ausdrücke die Form bzw. ”\d4 “ ”01 \d\d/\d6,10 “.

⁵ Dublin Core kann auch auf der Grundlage von meta -Tags in HTML-Seiten eingebaut wer- den [Hil01c, Hil01b], das Hauptaugenmerk gilt an dieser Stelle aber dem Zusammenspiel mit RDF/RDFS.

⁶ Die in Teil II eingeführten Konzepte können aber auch bei Date sinnvoll eingesetzt werden.

⁷ Ist das Ende abschätzbar, ist der alternative Einsatz von unscharfen Grenzen möglicherweise sinnvoller.