Metadaten für Einsteiger

Im Gegensatz zur Bedeutung von Metadaten sind die Meinungen deutlich heterogener, wenn es darum geht, was Metadaten eigentlich sind und wie man ein so genanntes Metadatenkonzept entwickelt. Basierend auf unserem erfolgreichen Workshop „Metadaten für Einsteiger“ klären wir in diesem Artikel, was Metadaten sind und wozu wir diese in der Technischen Kommunikation einsetzen. Wir zeigen an einem konkreten Beispiel, wie man Schritt für Schritt und anhand einfacher Regeln von der Beschreibung digitaler Ressourcen zu einem – sogar iiRDS-fähigen – Metadatenkonzept kommt.

Sinn und Zweck von Metadaten

Bevor wir uns der Frage zuwenden, was Metadaten sind, überlegen wir, wozu wir überhaupt Metadaten benötigen. Die Arbeit in vielen Projekten hat uns gezeigt, dass in nahezu allen Technischen Redaktionen Diskussionen um die folgenden Fragen geführt werden:

• Wie können wir unsere redaktionellen Abläufe, zum Beispiel die Freigabe oder Publikation, optimieren bzw. automatisieren?
• Was müssen wir tun, um unsere digitalen Ressourcen in einem Component-Content-Management- System (CCMS) suchen und finden zu können?
• Wie können wir existierende Topics einfach und verlässlich wiederverwenden?
• Wie lässt sich die Variantenbildung unserer Informationsprodukte steuern?
• Wie können wir unsere Informationsprodukte, zum Beispiel basierend auf einer Stückliste, (teil-)automatisiert erzeugen?
• Was müssen wir berücksichtigen, damit unsere (End)Kunden unsere digitalen Ressourcen in einem Content-Delivery-Portal (CDP) suchen und finden können?
• Wie steuern wir, dass bestimmte Anwendergruppen nur auf die Ressourcen zugreifen können, die für sie bestimmt sind?
• Wie stellen wir sicher, dass unterschiedliche digitale Ressourcen aus ggf. unterschiedlichen Quell- systemen vernetzt werden können?

Es kommt nicht überraschend. Die Antworten auf alle diese Fragen (und vermutlich einige weitere mehr) haben, wenn auch nicht ausschließlich, sehr viel mit Metadaten zu tun. Metadaten sind essenziell, um digitale Ressourcen klassifizieren, organisieren und verwalten, bereitstellen und nutzen zu können. Erst Metadaten erlauben es, mit unseren digitalen Ressourcen intelligent umgehen zu können [1].

Definition von Metadaten

Was nun aber sind Metadaten? Die genannten Anforderungen haben gezeigt, dass sich Metadaten auf sehr unterschiedliche Entitäten wie Prozesse, Daten oder Informationen beziehen können. Daher ist die weit verbreitete Definition von Rockley und Cooper [2] entsprechend weit gefasst: „[Metadata are] all physical data (contained in software and other media) and knowledge (contained in employees and various media) from inside and outside an organization, including information about the physical data, technical and business processes, rules and constraints of the data, and structures of the data used by a corporation.“ Alternativ und viel kürzer können wir Metadaten auch mit „Daten über Daten“ definieren.

Der Weg zum Konzept

Die digitalen Ressourcen der Technischen Kommunikation sind vielfältig. Sie reichen von digitalen Assets wie Illustrationen und Animationen über Dokumente und Topics bis hin zu Informationen über Werkzeuge, Ersatzteile oder Verbrauchsmaterialien. Zu Illustrationszwecken konzentrieren wir uns an dieser Stelle auf die „klassischen“ Ressourcen der Technischen Kommunikation: Dokumente und Topics. Abbildung 01 repräsentiert ein Dokument, Abbildung 02 ein Topic. Wir gehen davon aus, dass das Topic in dem Dokument enthalten ist.

Abb. 01 Repräsentant eines typischen Dokuments. Quelle Martin Ley und Sofia Darie

Auf unserem Weg zum Metadatenkonzept gehen wir in drei Schritten vor:

1. Schritt: Wir beschreiben die entsprechenden Ressourcen.
2. Schritt: Wir unterscheiden zwischen Metadatenklasse und Metadatenwert.
3. Schritt: Wir gruppieren unsere Metadaten in Kategorien.

1. Ressourcen beschreiben

Wenden wir uns bei der Beschreibung unserer Ressourcen zunächst dem Dokument als Ganzem zu. Das in Abbildung 01 repräsentierte Dokument lässt sich näher beschreiben bzw. charakterisieren: Es handelt sich um eine Montageanleitung in deutscher Sprache im PDF-Format. Es gilt für die Sortieranlage 1.0 und wurde im Jahr 2019 erstellt/freigegeben. Hersteller der Anlage ist die Anlagen AG. Weitere, auf dem Deckblatt nicht ersichtliche Angaben sind etwa, dass das Dokument für die Wartungsphase vorgesehen ist, von der Hochschule München erstellt wurde, freigegeben und an einem bestimmten Ort gespeichert ist.

Abb. 02 Repräsentant eines typischen Topics. Quelle Martin Ley und Sofia Darie

Da das Topic in Abbildung 02 Bestandteil des Dokuments in Abbildung 01 ist, hat es einige Eigenschaften des Dokuments (geerbt). Es gehört auch zur Sortieranlage und liegt als PDF vor. Es lässt sich aber durch weitere Eigenschaften charakterisieren. So können wir beispielsweise feststellen, dass es sich um ein anleitendes Montagetopic handelt. Zudem bezieht sich das Topic nicht auf die gesamte Sortieranlage, sondern nur auf einen speziellen Teil davon, nämlich die Membranpumpe. Zudem ist es explizit für Servicetechniker vorgesehen und enthält eine Angabe zur Befestigungsschraube M8.

2. Klassen und Werte unterscheiden

Im 1. Schritt haben wir die digitalen Ressourcen beschrieben bzw. charakterisiert, wir haben ihnen also Metadaten zugewiesen. Wir können unser Vorgehen jedoch ein kleines bisschen präzisieren. Denn streng genommen haben wir unseren Ressourcen nicht Metadaten, sondern Metadatenwerte zugewiesen. Dies bringt uns zu einer grundlegenden Unterscheidung beim Modellieren von Metadaten (Tab. 01). Auf der einen Seite haben wir die eigentliche Charakterisierung, die Metadatenwerte, auf der anderen die so genannte Metadatenklasse. Dieser Punkt kann leicht am Beispiel illustriert werden. In unserer vorherigen Beschreibung des Dokuments ist der Hersteller der Anlage mit Anlagen AG angegeben. Die Anlagen AG ist hier der Metadatenwert, die Metadatenklasse ist der Hersteller. Bei der Metadatenklasse handelt es sich also um ein abstraktes Konzept oder Schema. Der Metadatenwert wiederum ist eine Ausprägung dieser Klasse. Es ist der konkrete oder tatsächliche Wert, der unserer digitalen Ressource zugeschrieben wird.

In Tabelle 01 haben wir darüber hinaus eine weitere Spalte „Gültigkeitsbereich“ eingefügt. Damit machen wir deutlich, dass Metadaten für unterschiedliche Ressourcen bzw. auf verschiedenen Ebenen vergeben werden können. Während einige Metadaten exklusiv auf der Dokument- oder Topicebene zulässig sind (wie zum Beispiel Dokumenttyp oder Topictyp), können andere auch auf beiden Ebenen vorkommen (wie zum Beispiel Status). Dieser Unterschied wird öfters durch die Bezeichnungen Dokument-bezogene bzw. Topic-bezogene Metadaten ausgedrückt.

3. Kategorien bilden

Um bei einer großen Anzahl den Überblick nicht zu verlieren, bietet es sich an, verwandte Metadaten zu übergeordneten Kategorien zusammenzufassen. Auf die eigentliche Vergabe der Metadaten haben diese Kategorien nur bedingt eine Auswirkung.

Generell gilt, dass wir Metadaten etwa in diese Kategorien einteilen können:

• Beschreibende Metadaten – beschreiben den Inhalt oder die Eigenschaften der digitalen Ressourcen.
• Administrative Metadaten – identifizieren digitale Ressourcen und machen diese auffindbar; hierzu zählen auch rechtsbezogene Metadaten oder Metadaten über die Provenienz.
• Prozessuale Metadaten – unterstützen etwa den Workflow beim Erstellen und Verteilen der digitalen Ressourcen.

Administrative und prozessuale Metadaten nutzen wir normalerweise in unserem CCMS und CDP. Wir werden auf diese hier nicht näher eingehen. Dafür verdienen die beschreibenden Metadaten weitere Aufmerksamkeit. Denn es hat sich in der Technischen Kommunikation als nützlich erwiesen, diese in verschiedene Kategorien einzuteilen. Einige der Metadaten aus Tabelle 01 dienen nämlich eindeutig der Charakterisierung der digitalen Ressourcen selbst, wie zum Beispiel Dokumenttyp oder Topictyp. Andere Metadaten wiederum nennen die Produkte oder Komponenten, auf die sich diese Ressourcen beziehen. Wir nennen diese Kategorien die Informations- respektive Produkt-bezogenen Metadaten. Als dritte sinnvolle Metadatenkategorie führen wir die so genannten funktionalen Metadaten ein. Dazu zählt die Zielgruppe. Beispielhaft haben wir die Metadaten in einige Metadatenkategorien „organisiert“.

Regeln anwenden

Unsere Arbeit an Metadatenkonzepten hat gezeigt: An einer sorgfältigen Inhaltsanalyse der digitalen Ressourcen führt kein Weg vorbei. Dann aber lässt sich ein Metadatenkonzept relativ problemlos anhand einiger (goldener) Regeln entwickeln:

• Regel I: Wir bilden Metadatenklassen.
• Regel II: Wir ordnen den Metadatenklassen die Metadatenwerte (redundanzfrei) zu.
• Regel III: Wir entwickeln flache Metadatenhierarchien.
• Regel IV: Wir organisieren die Metadatenklassen in systematischen Kategorien.
• Regel V: Wir befolgen Regel I–IV, starten im Kleinen und skalieren bei Bedarf.

Normalerweise beginnen wir mit Metadatenklassen. Anschließend ordnen wir die ermittelten Metadatenwerte diesen Klassen zu. Wichtig ist, dass dies redundanzfrei geschieht. Das bedeutet, dass ein Metadatenwert in der Regel nur einer Klasse zugewiesen wird. Die Mehrfachklassifikation zu mehr als einer Metadatenklasse, so genannte Polyhierarchien, kann im ungünstigen Fall zu einer schlechten automatischen Weiterarbeitung der mit Metadaten angereicherten Ressourcen führen. Das Ergebnis dabei ist eine relativ flache Metadatenhierarchie; es sind also nur wenige Hierarchieebenen vorhanden. Dafür kann die Liste an Metadatenklassen eventuell sehr lang sein. Damit wir weiterhin den Durchblick bewahren und unser Metadatenmodell auch in Zukunft gut skaliert werden kann, organisieren wir die Klassen in systematischen Kategorien.

Bevor wir nun starten, das Modell umzusetzen, prüfen wir, ob das Modell mit einer langfristigen Content-Strategie kompatibel ist – wir wollen schließlich sicherstellen, dass wir uns mit unserem Metdatenkonzept nicht den Weg in die digitale Zukunft verbauen. Dann starten wir im Kleinen und skalieren bei Bedarf. Dies ist insbesondere relevant, wenn wir ein Metadatenkonzept für digitale Ressourcen aus unterschiedlichen Informationsquellen entwickeln.

Passendes Werkzeug wählen

Wie Tabelle 01 zeigt, lässt sich ein Metadatenkonzept relativ einfach als Excel-Tabelle darstellen. Dabei kann die Abhängigkeit von Metadatenkategorien, -klassen und -werten in verschiedenen Spalten repräsentiert werden. Bei umfangreicheren Metadatenkonzepten stößt die tabellarische Darstellung jedoch leicht an ihre Grenzen. Aber auch andere Werkzeuge können hier eingesetzt werden. Als gute Alternative zu Excel bieten sich MindMaps an. Dieses Instrument ist gerade in kreativen Phasen eine sehr gute Möglichkeit, ein Metadatenkonzept in Form von Haupt- und Unterästen zu entwickeln und visuell darzustellen (und bei Bedarf auch schnell zu „re-organisieren“). Eine weitere, professionelle Möglichkeit stellen so genannte Metadaten-Plattformen dar. Diese dienen der Entwicklung von Begriffs- bzw. Konzepthierarchien nach dem bewährten SKOS-Schema, wie zum Beispiel Definition, Vorzugsbenennung oder alternative Benennung [4]. Sie lassen sich hervorragend für Metadatenmodelle nutzen und können darüber hinaus weitere, semantisch noch aussagekräftigere Formen der Wissensrepräsentation wie zum Beispiel Ontologien integrieren [1].

Umgesetzt werden Metadatenkonzepte in den einschlägigen Systemen wie einem CCMS. Sie können dort etwa in Form von Taxonomiebäumen manuell aufgesetzt werden. Alternativ besteht die Möglichkeit, den Fluss der Metadaten aus einer Metadatenplattform in ein „konsumierendes“ System zu automatisieren.

Tab. 01 Quelle Martin Ley, Sofia Darie

Definieren und weiterentwickeln

Mit Metadaten beschreiben wir unsere digitalen Ressourcen. Wir benennen, um was für Ressourcen es sich handelt (Informations-spezifische Metadaten) und zu welchem Produkt sie gehören (Produkt-spezifische Metadaten); wir geben an, wie diese Ressourcen administriert werden (administrative Metadaten) und ob es weitere Abhängigkeiten zu anderen Ressourcen gibt (funktionale Metadaten). Innerhalb der einzelnen Kategorien werden die Metadaten immer spezifischer. Oder anders ausgedrückt: Wenn wir die Hierarchie von unten nach oben durchlaufen, drückt sie stets eine so genannte „ist-ein“-Relation aus. Das heißt, ein bestimmtes Objekt ist ein Task, ein Task ist ein Topictyp, ein Topictyp ist ein Informations-spezifisches Metadatum.

Beachten wir die bereits aufgestellten Regeln, folgen wir (im Großen und Ganzen) dem etablierten Metadatenstandard der tekom: iiRDS, dem intelligent information Request and Delivery Standard [3]. Auch wenn die Metadatenklassen und -werte dieses Standards womöglich von den Unternehmens-spezifisch entwickelten Metadaten abweichen, ist ein Mapping auf iiRDS möglich. Zum Beispiel wird eine spezifische Metadatenklasse „Informationsprodukt“ auf die iiRDS-Klasse „Dokumenttyp“ gemappt. Oder ein neuer Metadatenwert „Systemübersicht“ erweitert die Werte der Metadatenklasse „Topictyp“.

Durch dieses Zusammenspiel mit iiRDS wird auch bereits die Tragweite eines sauber aufgesetzten Metadatenkonzepts sichtbar. Hier wird die Basis für ein zukünftiges Verwalten und Verteilen digitaler Ressourcen gelegt. Für die Verteilung spezifischer Informationen für konkrete Zielgruppen zum Beispiel in einem CDP sind Metadaten unabdingbar.

Die Frage, die sich viele Akteure in den Technischen Redaktionen dennoch weiterhin stellen, lautet: Wie viele Metadaten müssen wir eigentlich vergeben? Lohnt es sich, heute schon an die Metadaten von morgen zu denken? Die Antwort kann unserer Erfahrung nach nur lauten: Überlegen Sie heute, was Sie morgen benötigen. Ansonsten passen Sie Ihre digitalen Ressourcen ein erneutes Mal an und beschreiben sie erneut mit den dann erforderlichen Metadaten – oder Sie werden niemals zu semantisch angereicherten, intelligent vernetzbaren Informationen kommen.

Links und Literatur zum Artikel

[1] Ley, Martin (2018): Informationen erhalten Bedeutung. In: technische kommunikation, H. 4, S. 50–55.

[2] Rockley, A./Cooper, C. (2012): Managing Enterprise Content: A Unified Content Strategy.

[3] tekom: iiRDS – The Intelligent Information Request and Delivery Standard. https://iirds.org

[4] W3C: SKOS – Simple Knowledge Organization System. https://www.w3.org/2004/02/skos/