Logo der OA Zeitschrift BRaIn

Wir | Editionsrichtlinien | Impressum | Disclaimer
Inhaltsverzeichnis
Ausgabe I/2008 Ausgabe II/2008
subglobal5 link | subglobal5 link | subglobal5 link | subglobal5 link | subglobal5 link | subglobal5 link | subglobal5 link
subglobal6 link | subglobal6 link | subglobal6 link | subglobal6 link | subglobal6 link | subglobal6 link | subglobal6 link
subglobal7 link | subglobal7 link | subglobal7 link | subglobal7 link | subglobal7 link | subglobal7 link | subglobal7 link
subglobal8 link | subglobal8 link | subglobal8 link | subglobal8 link | subglobal8 link | subglobal8 link | subglobal8 link

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

Aspekte der Verknüpfung heterogener Ressourcen

Felix 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, (vergl. Abb. 1)
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.

Ressourcen und ihre Verknüpfung
Abb.1: Ressourcen und ihre Verknüpfung
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. 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!”
Bester Freund... auf japanisch

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:

Beispiel 2



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:

Beispiel 3






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 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“ (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!“

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.
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 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.
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“
- „URIs for W3C Namespaces“
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!“
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&ldquo:. 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 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“.

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.

| ©2008 FH-Potsdam, FB Informationswissenschaften | Stand: 17.06.2009