titel: von den „leiden des jungen werther“ bis zu...

F. Sasaki, Aspekte der Verknüpfung heterogener Ressourcen

Von den „Leiden des jungen Werther“ bis zu Metadaten für Multimedia:

Aspekte der Verknüpfung heterogener RessourcenFelix Sasaki

1. Einleitung

Dieser Artikel beruht auf Vorträgen an der Fachhochschule Potsdam im Dezember 2008 und an der

Universität Potsdam im Mai 2009. Ich diskutiere Aspekte der Verknüpfung heterogener Ressourcen.

Wie der Titel deutlich macht ist die Spannbreite der Thematik groß. Die verschiedenen Teilthemata

werden zusammengehalten durch wiederkehrende Aspekte, und durch eine Sicht auf Ressourcen

und ihre Verknüpfung, die sich folgendermaßen beschreiben lässt, vergleiche Abbildung 1.

1

Abbildung 1: Ressourcen und ihre Verknüpfung


Ressourcen haben Namen, (wiederkehrende) Strukturen, Beschränkungen dieser Strukturen, und

eine Semantik. Der Begriff „Semantik“ ist hier nicht im linguistischen oder etwa

informationstechnischen Sinne zu verstehen. Er wird als ein Platzhalter für die Bedeutung der

Ressource im jeweiligen Anwendungsszenario benutzt.

Ressourcen sollen mit mehr oder weniger Informationsverlust ineinander überführt werden, oder

auf einer übergreifenden Ebene soll ein potentiell generalisierender Zugriff auf sie möglich sein.

Ressourcen müssen eindeutig identifizierbar sein. Sie greifen auf mehr oder weniger standardisierte

Vokabulare zurück, um Teileigenschaften zu beschreiben. Es gilt auch, diese Vokabulare bei der

Verknüpfung eindeutig zu identifizieren, sowie die Möglichkeit der Vokabularsverknüpfung

auszuloten.

Die LeserInnen werden sich vielleicht fragen, wie diese Sicht auf Ressourcen zu Stande gekommen

ist. Ein persönlicher Einblick: 1999 hieß ich mit Nachnamen „Müller”, und habe mich mit den

„Leiden des jungen Werther” im Sprachkontrast beschäftigt, d.h. der Vergleich des deutschen

Originals mit verschiedenen Übersetzungen ins Japanische. Heute heiße ich Sasaki und beschäftige

mich mit in hohem Maße mit Ressourcen im Web. Im Web besitzt so genanntes „loose coupling“,

die lose Verbindung von Ressourcen, einen Mehrwert und ist zugleich ein Problem. Denken Sie

etwa an die Ressource Wikipedia, bei der Informationen von verschiedenen Autoren erstellt werden,

die sich teilweise aufeinander beziehen, oder zu Wikipedia externe Quellen nutzen. Der Mehrwert

aus der losen Verbindung ist, dass neues Wissen entstehen kann und die Grenzen wissenschaftlicher

oder etwa künstlerischer Disziplinen fallen. Der Nachteil ist neben der Qualität der einzelnen

Beiträge zu Wikipedia, dass die Kompatibilität der Informationen zueinander auf Grund der losen

Verbindung nicht gewährleistet werden kann.

Anders ausgedrückt: Zentralisierung von Informationen und Dezentralisierung lassen sich nicht

gleichzeitig erzielen; es gilt, die Vorteile beider miteinander zu verknüpfen, also den Mehrwert des

„loose coupling“ nicht aufzugeben, aber zumindest „Best Practices“, das heißt Ratschläge oder

Empfehlungen für den Umgang mit verteilten Informationen zu geben. Der vorliegende Artikel tut

dies für sehr verschiedenartige Ressourcen: Linguistische Datensammlungen aus verschiedenen

Sprachen versus Metadaten zu Multimedia. Trotz ihrer Verschiedenheit können Projekte, die sich

mit derartigen Ressourcen beschäftigen, und eventuell auch in Zukunft zu entwickelnde

Ausbildungsinhalte für Informationswissenschaftler, von den Best Practices des vorliegenden

Artikels profitieren.

2


2. Namen und Strukturen

Beginnen wir mit der Beschreibung von Namen und Strukturen. Als Beispiel dient ein Satz aus den

„Leiden des Jungen Werther“ und seine Übersetzung ins Japanische:

„Bester Freund, was ist das Herz des Menschen!”

“愛するとも、人間の心なんて何という妙なものだろう!“

Diese Sätze sind Ausschnitte aus zwei Ressourcen: „Ausschnitt aus dem Werther im Original” vs.

„Übersetzung des Werther”. Eine Semantik im Anwendungsszenario „Sprachkontrast“ ist,

linguistisch funktionale Entsprechungen zu finden, etwa für den Satztyp „Exklamation“ (Ausruf).

Diese Semantik spielt im Folgenden keine Rolle, sondern soll den LeserInnen nur den

Anwendungskontext der Ressourcen verdeutlichen.

Um diese Ressourcen verknüpfen zu können, sollen zunächst Namen für Einheiten bestimmt

werden. Die grundlegende Einheit sind Sätze, also wählen wir den Namen „s”. Die Sätze

unterscheiden sich in beiden Sprachen, weshalb wir die Namen in Namensräumen vergeben: „d” für

Deutsch und „j” für Japanisch:

Ein deutscher Satz „d:s“: „Bester Freund ... !“

Ein japanischer Satz „j:s“: “愛するともよ ... ！”

Wir vergeben ebenfalls Namen für Wörter „w“ und Interpunktionen „p”. Als nächsten Schritt führen

wir Strukturierungen ein: Sätze enthalten Wörter und Interpunktionen:

<d:s><d:w>Bester</d:w>...<d:p>!</d:p></d:s>

<j:s><j:w>愛する</j:w>...<j:p>！</j:p></j:s>

Mit diesen Benennungen von Einheiten und der Einführung von Strukturierungen lassen sich in

einer kombinierten Ressource „Deutsch-japanisches Korpus von Exklamationen” übergreifende

Anfragen stellen, etwa „Wie viele Interpunktionen werden pro Exklamation verwendet?”, oder

„Wie viele Ausrufezeichen gibt es?”.

Den LeserInnen ist vielleicht aufgefallen, dass die Daten in den Beispielen in XML repräsentiert ist.

Entscheidend ist dies jedoch nicht für die folgende, erste Best Practice:

„Vergebe vergleichbare Namen und Strukturierung!“

Egal, ob Daten in XML repräsentiert sind, in einem anderen Format elektronisch vorliegen, oder

Informationen nicht einmal elektronisch erfasst sind: Die Vorteile von eindeutiger Benennung und

Strukturierung von Informationen liegen auf der Hand. XML hat in den letzten Jahren einen

3


Siegeszug als Hilfsmittel zur Realisierung dieser Best Practice erlangt. Notwendig ist es jedoch

nicht.

3. Beschränkungen

Nun zu den Beschränkungen. Hier wollen wir Beschränkungen für Strukturen der deutschen

beziehungsweise japanischen Exklamationen verknüpfen. Wir nehmen an, dass die Exklamationen

in bestimmten Mustern vorkommen. Ein allgemeines Muster ist zum Beispiel die Verwendung des

Ausrufezeichens am Ende der Exklamation in beiden Sprachen. Ein für das Deutsche spezifische

Muster ist die zusätzliche Verwendung des Frageworts „was“. In einem Muster für das Japanische

taucht ebenfalls ein Fragewort auf, allerdings wird dies noch durch weitere grammatikalische, für

das Japanische spezifische Formen begleitet.

Die Verknüpfung solcher Muster kann interessant sein für sprachkontrastive Fragestellungen wie

„Welche ähnlichen oder unterschiedlichen strukturellen Möglichkeiten gibt es in verschiedenen

Sprachen zum Ausdruck von Exklamationen?“ Zur Beantwortung der Frage ist die Verknüpfung

von Beschreibungen von Beschränkungen der Strukturen hilfreich. Solche Beschränkungen werden

in der Linguistik oder auch der Informatik als „formale Grammatiken“ bezeichnet. Wir werden hier

nicht tief in dieses Thema eintauchen, wollen aber deutlich machen, dass die Vergleichbarkeit von

Muster- bzw. Beschränkungsbeschreibungen abhängig ist von der Art der formalen Grammatik.

Wir haben im Folgenden drei Grammatiken für Sätze definiert, die Beschränkungen für Sätze auf

unterschiedliche Weise beschreiben:

(1) s → (w | p)+

(2a) s (in Text) → (w | p)+

(2b) s (in Satzliste) → (w)+

(3a) s (als Exklamation Deutsch in Text) → (...)

(3b) s (als Exklamation Japanisch in Text) → (...)

Formale Grammatiken umfassen Regeln mit Symbolen auf einer linken und einer rechten

Regelseite. Die Arten der Grammatiken, die wir hier betrachten, so genannte Baumgrammatiken,

lassen sich nach dem Verhältnis der Symbole auf beiden Seiten unterscheiden: „local“ (1), „single-

type“ (2) oder „regular“ (3). „local” bedeutet, dass nur die linke Seite einer Regel die Symbole der

rechten Seite festlegt. Im Beispiel (1) ist es nur das Symbol „s“ (Satz), welches bestimmt, dass „w“

4


(Wörter) oder Interpunktionszeichen („p“) auf der linken Seite der Grammatikregel vorkommen

dürfen.

„single-type“ bedeutet, dass in verschiedenen Kontexten für die gleiche linke Seite unterschiedliche

rechte Seiten vorliegen können. Im Beispiel gibt es zwei Varianten: „s (in Text)“ sind Sätze in

Texten, „s in Satzlisten“ sind Sätze in Satzlisten, das heißt ohne weitere, beispielsweise auf das

Dokument bezogene Strukturierungen.

„regular” bedeutet, dass unterschiedliche rechte Seiten einer Regel im gleichen Kontext möglich

sind. Im vorliegenden Fall nehmen wir an, dass Exklamationen aus den beiden Sprachen im

Kontext „s“ Satz vorkommen und nicht zwischen japanischen und deutschen Sätzen unterschieden

wird.

Welche Form von Grammatik soll man nun für die Beschreibung von Strukturmuster in Ressourcen

verwenden, wenn man diese mit anderen Ressourcen verknüpfen will? Was man wählt, hängt vom

Zweck der Ressourcenverknüpfung ab. „local“ und „single-type“ Grammatiken erlauben eine

eindeutige Interpretation, z.B. in der Suche in eventuell heterogenen Ressourcen: „Finde alle

Instanzen vom Typ Satz oder Satz in Text” ergibt hier immer eindeutige Ergebnisse. Dies gilt nicht

für die Anfrage nach Einheiten, welche mittels regulärer Grammatiken modelliert wurden. Hier gibt

es Ambiguität: Ist etwas eine gegebene Exklamation vom Muster „Exklamation Deutsch” oder vom

Muster „Exklamation Japanisch?”.

Wenn also die Aufgabe ist, Ressourcen anhand eindeutig interpretierbarer Strukturbeschreibungen

zu verknüpfen, so muss man auf „local“ Grammatiken zurückgreifen. Wenn die Interpretierbarkeit

von Kontext der verknüpften Ressourcen abhängig ist, sind „single-type“ Grammatiken geeignet.

Wenn die Interpretierbarkeit für die Verknüpfung der Ressourcen unbedeutend ist, kann Ambiguität

bei Strukturbeschränkungen in Kauf genommen werden.

Ein Wort zu Technologien: Zur Repräsentation der Beschränkung kamen auf XML basierte, so

genannte Schemasprachen zum Einsatz: XML DTDs haben die Ausdruckskraft „local“, XML

Schema hat die Ausdruckskraft „single-type“, und RELAX NG hat die Ausdruckskraft „regular“.

Wenn man die Daten in XML repräsentiert muss man also die entsprechende Schemasprache zur

Beschränkungsbeschreibung auswählen. Wie auch bei der ersten Best Practice ist aber die folgende,

zweite Best Practice generell ausgelegt und nicht technologiespezifisch:

„Entscheide Dich zwischen freien und eindeutig interpretierbaren Strukturbeschränkungen!“

5


4. Namen, Strukturen und Kollaborateure

Kommen wir noch einmal zur Gesamtheit von Namen, Strukturen und Beschränkungen.

Ressourcen werden oft von verschiedenen Personen zu unterschiedlichen Zeiten bearbeitet. Dabei

können unterschiedliche beziehungsweise widersprüchliche Informationen zustande kommen, etwa:

Nutzer 1: „Das ist eine Exklamation.“

Nutzer 2: „Nö, Fragesatz, Ausrufezeichen ist falsch verstanden.”

Nutzer3: „Quatsch, Nutzer1 hat recht!”

Deshalb sind Mechanismen nötig, um derartige Konflikte aufzulösen. Diese Thematik ist

insbesondere relevant für das „Webszenario“, wo Kollaborieren inzwischen zum Alltag gehört.

Eine Möglichkeit, derartige Konflikte aufzulösen ist die Regel „Der Letzte hat immer recht!”. Bei

der Verknüpfung von Ressourcen wird dann jeweils die als letztes hinzugefügte Veränderung

genutzt. Wichtig ist, dass diese Regel nur exemplarischen Charakter hat. Es lassen sich viele

Mechanismen zur Konfliktlösung annehmen. Die zugrunde liegende Best Practice lautet:

„Bedenke die kooperative Verwendung der Ressourcen, und stelle Mechanismen zur Lösung von

Konflikten bereit!“

5. Übergreifender Zugriff auf Ressourcen

Kommen wir nun zum übergreifenden Zugriff auf Ressourcen.

Hier muss man sich darüber klar werden, ob im eventuell verteilten Szenario, vergleiche wieder den

Begriff “loose coupling”, man eindeutige Interpretation der Werte in Ressourcen erwarten möchte.

Person A erstellt eine Ressource, etwa eine Sammlung japanischer Daten, Person B eine andere,

etwa deutsche Daten. Nun möchte Person A Anfragen an die Daten von Person B stellen, wie „Wie

viele Exklamationen nach dem Muster M1 gibt es in den japanischen Daten?“.

Wenn das Muster M1 als „local“ Grammatik (vergleiche Abschnitt 3) vorliegt, lassen sich diese

Anfragen ohne Ambiguität beantworten. Wenn das Muster als „single-type“ oder „regular“

Grammatik vorliegt, ist die Anfrage eventuell nur kontextabhängig oder grundsätzlich uneindeutig.

Dies bedeutet jedoch nicht, dass der übergreifende Zugriff unmöglich ist. Die Uneindeutigkeit

bezieht sich nur auf Ergebnisse des Zugriffs. Man kann also Anfragen stellen wie „Wie viele

Exklamationen gibt es?“, wenn man auf die Spezifikation der Muster verzichtet.

6


Wieder ist die obige Beschreibung nicht spezifisch für Technologien, hat aber einen engen Bezug:

Abfragen von (heterogenen oder nicht heterogenen) Daten können zu Ergebnissen mit eindeutigen

„Typen“ führen, oder zu Ergebnissen mit Unklarheit über den „Typ“ der Daten. Die eindeutigen

Typen von Muster, die auf „local“ und „single-type“ Grammatiken beruhen sowie uneindeutige

Typen auf der Basis von „regular“ Grammatiken sind Beispiele, bei denen die Uneindeutigkeit mit

der Art der formalen Grammatik zu tun hat. Allerdings gibt es bei verteilt vorliegenden Ressourcen

auch andere Gründe auf Typdefinitionen für Abfragen zu verzichten, etwa die eventuelle Unklarheit

über Datentypen der Ressourcen im Web, die man selbst nicht kontrolliert. Wichtig ist in jedem Fall

die folgende Best Practice zu beachten:

„Werde Dir klar über die Möglichkeit oder Einschränkungen, Ressourcen unter Nutzung von

Typinformationen zu verknüpfen!“

6. Verwendung standardisierter Vokabulare

Kommen wir nun zur Verwendung standardisierter Vokabulare. Einheiten wie “d:s” oder “d:w” oder

die vorgestellten formalen Grammatiken sind „Spielzeugbeispiele“. Die Wiederverwendung und

Verknüpfung von Ressourcen profitiert von der Nutzung standardisierter Formate. Dabei gilt es

jedoch, die Version der Formate und deren Kompatibilität zu beachten. Hierzu ein Beispiel.

Nehmen wir an, „Werther“ wurde auch ins Chinesische übersetzt, und es gibt verschiedene

Übersetzungen, also Ressourcen, die miteinander verknüpft werden sollen. Die Frage lautet nun:

Mit welchem Sprachcode soll das Metadatum ausgedrückt werden, welches die Übersetzung ins

Chinesische identifiziert? Alternativen sind etwa „zh“, „zh-cmn“, oder „cmn“.

Beim Umgang mit standardisierten Formaten steht man oft vor derartigen Fragen. Es gibt eine

Vielzahl von Standards und Versionen und man hat die „Qual der Wahl“. Im Bereich Sprachencodes

gibt es unter anderem eine Reihe von ISO Standards (639), von denen einer auf Codes der Library

of Congress beruht (MARC Liste) oder einen IETF Standard „BCP 47“. Um aus den geeigneten

Standards wählen zu können, muss man zunächst den Anwendungskontext kennen. So sind in

internationalen Bibliotheken die ISO 639-2 Sprachencodes (die MARC Liste) bzw. eine Teilmenge

davon verbreitet. In deutschen Bibliotheken wird teilweise die DIN 2335 verwendet. Im

Webkontext ist der IETF Standard „BCP 47“ häufig anzutreffen. Zusätzlich ist es wichtig, die

Beziehungen zwischen den Standards zu kennen. Der erwähnte Standard BCP 47 etwa bietet ein

7


Rahmenwerk für die Nutzung von Sprachencodes aus verschiedenen Teilen der ISO 639 Serie und

anderen Standards.

Schließlich ist Wissen um Implementationen hilfreich. Mit Implementationen meine ich hier die

Nutzung eines Standards, z.B. der Sprachcodes, in einer technischen Infrastruktur. Die

Sprachencodes des Z39.53 Standards etwa werden im technischen Protokoll Z39.50 verwendet.

BCP 47 findet Anwendung in einer Reihe von Web- und Internetstandards, z.B. HTTP.

Aus diesem Beispiel lässt sich die folgende „Best Practice” ableiten:

„Nutze standardisierte Vokabulare – aber beachte ihre Version(en) und den Anwendungskontext

(Domäne, Protokolle)!“

Ein Beispiel, wo diese Praxis teilweise nicht befolgt wird, und was die Problematik des „loose

coupling“ wieder aufzeigt, ist Wikipedia. Hier werden teilweise Sprachcodes wie zh-classical für

klassisches Chinesisch genutzt, die keinem der beschriebenen Standards entsprechen, die aber auf

Grund der Nutzung in Wikipedia eine gewisse Akzeptanz erreicht haben.

7. Nachhaltige Identifikation von Ressourcen

Um Ressourcen nachhaltig miteinander zu verknüpfen, sind Identifikatoren für Ressourcen oder

Teilressourcen nötig. Diese beruhen auf Schemata, welche den Aufbau der Identifikatoren

beschreiben, und teilweise auf Protokolle, welche Regeln für den Einsatz der Identifikatoren im

Informationsaustausch definieren.

Bei Schemata zur Identifikation von Ressourcen gibt es einen Wald – und dieser Wald ist dicht.

Einige Schemata sind eng mit Protokollen verknüpft, z.B. das „http“ Schema, oder die Schemata

„Z39.50r“ sowie „Z39.50s“. Andere sind mit Absicht nicht an Protokolle gebunden, z.B. „urn“.

Manche Schemata umfassen mehr oder wenige explizite Nachhaltigkeitsversprechen, vgl. „urn“:

„Universal Resource Name“.

Die Fragen lauten nun: Welches Schema soll man wählen? Sollte man ein neues, für die jeweilige

Community und Verknüpfungsanforderungen spezifisches Schema erfinden?

Die Antwort ist einfach und wahrscheinlich zunächst unbefriedigend: Das „http“ Schema ist

ausreichend um Ressourcen nachhaltig zu identifizieren. Die soziale Bereitschaft, eine Form von

„http“ URI („Universal Resource Identifier“) in einem existierenden Schema zu nutzen, ist

entscheidend.

8


Diese Sicht wird von vielen wissenschaftlichen „Communities“ nicht geteilt. Sie entwickeln andere

Formen der Identifikation und teilweise spezifische Protokolle, von denen sie sich nachhaltige

Identifizierbarkeit und Zugänglichkeit zu Ressourcen erhoffen. Ein Grund hierfür liegt in den

schlechten Erfahrungen mit Nachhaltigkeit im Web. Die dezentralisierte Architektur des Webs führt

dazu, dass eine „http“ URI jederzeit ins Leere führen kann und die Ressource verschwindet.

Dennoch sollen in diesem Aufsatz „http“ URIs propagiert werden als das am besten geeignete

Mittel, um Ressourcen nachhaltig zu identifizieren. Entscheidend ist nicht das Schema von

Identifikatoren und das Protokoll, sondern Übereinkünfte in der Community über die

Nachhaltigkeit oder Kurzlebigkeit ausgewählter Ressourcen. Diese Übereinkünfte sind sozialer

Natur. „http“ URIs zu nutzen hat den bekannten „Netzwerkeffekt“, dass neue Communities

zwischen zuvor unbekannten Gruppen leicht entstehen, während bei anderen Schemata die Grenzen

der Nutzer oft spezifisch zu existierenden Gruppen ist. Selten treten Synergien mit bisher

Unbeteiligten auf.

Soziale Übereinkünfte über Nachhaltigkeit werden von verschiedenen Organisationen auch

öffentlich bekannt gemacht. Das W3C etwa hat Dokumente entwickelt, um soziale Bereitschaft für

Nachhaltigkeit von Ressourcen zu demonstrieren und sich selbst hinsichtlich der eigenen

Ressourcen zu verpflichten:

- „Referencing electronic documents from W3C specifications“, vergleiche

http://www.w3.org/2001/06/manual/#ref-section

- „URIs for W3C Namespaces“, vergleiche http://www.w3.org/2005/07/13-nsuri

Zusätzlich gibt es Tools wie den „Linkchecker“ die es erleichtern Verweise zwischen Ressourcen zu

überprüfen. Da der Anwendungskontext das Web, also eine geringe Menge standardisierter und

verhältnismäßig einfach implementier- und nutzbarer Formate und Protokolle ist, finden diese Tools

leicht einen weiten Anwenderkreis. Die Anwender folgen dabei der Best Practice:

„Sichere eindeutige Identifizierbarkeit der Ressourcen, unter Nutzung standardisierter

Identifikatoren und Protokolle!“

8. Zusammenfassung der Best Practices

Im Folgenden sind noch einmal alle Best Practices aufgeführt:

1) „Vergebe vergleichbare Namen und Strukturierung!“

9


2) „Entscheide Dich zwischen freien und eindeutig interpretierbaren Strukturbeschränkungen!“

3) „Bedenke die kooperative Verwendung der Ressourcen, und stelle Mechanismen zur Lösung von

Konflikten bereit!“

4) „Werde Dir klar über die Möglichkeit oder Einschränkungen, Ressourcen unter Nutzung von

Typinformationen zu verknüpfen!“

5) „Nutze standardisierte Vokabulare – aber beachte ihre Version(en) und den Anwendungskontext

(Domäne, Protokolle)!“

6) „Sichere eindeutige Identifizierbarkeit der Ressourcen, unter Nutzung standardisierter

Identifikatoren und Protokolle!“

Zu einem Aspekt der Verknüpfung heterogener Ressourcen haben wir noch nichts gesagt – der

Semantik. Der Grund ist einfach und wurde schon angedeutet: Die Semantik der Ressourcen ist

projektspezifisch – die Definition des Wortes „Semantik“ an sich ist abhängig von der jeweiligen

wissenschaftlichen Domäne. Deshalb hält dieser Aufsatz keine Best Practices im Bereich Semantik

bereit. Diese Aufgabe erfüllen die jeweiligen Communities selbst.

9. Und nun: Metadaten für Multimedia!

Kommen wir nun zum zweiten Themenbereich dieses Aufsatzes und machen einen Sprung: Vom

„Jungen Werther“ zu Metadaten für Multimedia!

Hintergrund dieses Themas ist die W3C Arbeitsgruppe für heterogene Multimediaformate „Media

Annotations Working Group”, vergleiche http://www.w3.org/2008/WebVideo/Annotations/. Das

Ziel dieser Arbeitsgruppe ist unter anderem die Entwicklung von Empfehlungen für die

Verknüpfung der heterogenen Formate und Möglichkeiten des Zugriff auf einer übergreifenden, das

heißt vom jeweiligen Format unabhängigen Ebene. Genauere Anforderungen sind unter

http://www.w3.org/TR/media-annot-reqs/ beschrieben.

Die Verknüpfung von verschiedenen Multimediaformaten ist deshalb ein aktuelles und wichtiges

Thema, da mehr und mehr Multimediaressourcen im Web verfügbar sind. Anders als bei textuellen

Daten sind jedoch Verfahren der automatischen Analyse nicht weit genug fortgeschritten, um

befriedigende Ergebnisse bei Suchanfragen zu erhalten. Metadaten sind deshalb eine wichtige

Informationsquelle, um Audio, Bilder und Videos leichter auffindbar zu machen.

Es gibt eine Vielzahl von Metadaten in diesem Bereich. Oft werden dabei ähnliche Informationen in

10


unterschiedlich benannten Metadatenkategorien dargestellt. Und es überrascht nicht, dass die sechs

Best Practices auch für diesen Bereich relevant sind. Im Folgenden werden wir die Best Practices

wiederholen und anhand der beiden Formate Dublin Core und MPEG-7 den Bezug zu Metadaten

für Multimedia herstellen.

1) „Vergebe vergleichbare Namen und Strukturierung!“: Bei neu zu erstellenden Metadaten für

Multimedia sollte man sich entscheiden für gemeinsame Namen und Strukturierungen von

Metadatenkategorien. Eine einfache, weitgehend unstrukturierte Variante stellt Dublin Core dar,

MPEG-7 ist komplexer und tiefer strukturiert. Je größer der zu erwartende Nutzerkreis ist, desto

eher wird die Entscheidung zu Gunsten von Dublin Core fallen.

2) „Entscheide Dich zwischen freien und eindeutig interpretierbaren Strukturbeschränkungen!“:

Dublin Core umfasst strukturell einfache Metadatenkategorien. MPEG-7 definiert Beschränkungen

für Metadaten, welche weit über die vorgestellten, formalgrammatischen Varianten („local“,

„single-type“, „regular“) hinaus gehen und eine strukturell eindeutige Interpretierbarkeit nicht

unbedingt ermöglichen.

3) „Bedenke die kooperative Verwendung der Ressourcen, und stelle Mechanismen zur Lösung von

Konflikten bereit!“: Konflikte im Bereich Multimedia sind vorstellbar, wenn Metadaten

verschiedener Art für das gleiche Multimediaobjekt vorhanden sind. In diesem Fall könnte eine

Lösung die einfache Richtlinie sein: „Präferiere Dublin Core in jedem Fall“.

4) „Werde Dir klar über die Möglichkeit oder Einschränkungen, Ressourcen unter Nutzung von

Typinformationen zu verknüpfen!“: Wenn man Abfragen nach den kompletten Metadaten für ein

Multimediaobjekt durchführen will, ist der Typ der Daten unerheblich. Bei spezielleren Abfragen ist

der Typ eventuell entscheidend, und man muss den oder die verschiedenen potentiell auftretenden

Typen abgrenzen können.

5) „Nutze standardisierte Vokabulare – aber beachte ihre Version(en) und den Anwendungskontext

(Domäne, Protokolle)!“ Der Bezug zum Thema Multimedia erklärt sich bereits durch die

thematisierten Formate Dublin Core und MPEG-7.”

6) „Sichere eindeutige Identifizierbarkeit der Ressourcen, unter Nutzung standardisierter

Identifikatoren und Protokolle!“ Dieser Bezug wird eindeutig durch das Anwendungsszenario

„Multimediaobjekte und ihre Metadaten im Web“.

11


10. Zum Schluss: Wer muss das alles wissen?

Dieser Aufsatz hat ein große Spannbreite in zweierlei Hinsicht. Zum einen wurden sehr

unterschiedliche Anwendungsbereiche von Ressourcenverknüpfung vorgestellt. Zum anderen sind

sehr unterschiedliche Wissensbereiche angesprochen worden: Von formalen Grammatiken zu

sozialen Richtlinien für nachhaltige Identifikatoren.

Wer soll dies alles wissen? Zur Beantwortung dieser Frage hilft es, das nötige Wissen in

verschiedene Bereiche abzugrenzen:

1) Wissen um Technologien, beispielsweise XML und Schemasprachen.

2) Wissen um Potentiale (und Nachteile) der Modellierung von Daten oder Datenbeschränkungen,

beispielsweise den Eigenschaften formaler Grammatiken.

3) Wissen um standardisiere Formate und Protokolle, beispielsweise im Bereich Sprachencodes.

4) Wissen von Experten einer Domäne, etwa im Bereich Linguistik, wenn es um sprachkontrastive

Untersuchungen geht, oder im Bereich Bildannotation, wenn Metadaten für Multimedia im Zentrum

stehen.

Wissen der Art 1-3 ist meiner Ansicht nach für Informationswissenschaftler sinnvoll und sollte Teil

eines Grundlagencurriculums sein. Wissen im Sinne von 4) ist abhängig von der

Anwendungsdomäne, also der „Semantik“. Am wichtigsten ist jedoch, dass es Orte nicht nur im

physikalischen Sinne gibt, wo Wissen aus allen vier Bereichen aufeinander trifft. Dort wird die

Verknüpfung heterogener Ressourcen dann nicht mehr danach beurteilt welche (wissenschaftliche)

Gruppe dazu beigetragen hat, sondern ob sie zufriedenstellend verläuft.

12

titel: von den „leiden des jungen werther“ bis zu...

Documents