"Primärdaten als Grundlagen für Veröffentlichungen sollen auf haltbaren und gesicherten Trägern in der Institution, wo sie entstanden sind, für zehn Jahre aufbewahrt werden."
Empfehlungen zur gesicherten Aufbewahrung und Bereitstellung digitaler Forschungsprimärdaten, DFG: Ausschuss für Wissenschaftliche Bibliotheken und Informationssysteme, Unterausschuss für Informationsmanagement, S. 2, Januar 2009.

Standardisierung von Datenkategorien in CMDI: ISOcat bietet Unterstützung

Details
Erstellt am Donnerstag, 02. September 2010 13:04
Geschrieben von Christina Hoppermann

Um Metadaten, genauer Metadateninstanzen, für eine Ressource erstellen zu können, benötigt man Beschreibungsmuster, welche die zu verwendenden Datenkategorien (DatCats) für einen Ressourcentyp definieren. Bei solchen Beschreibungsmustern handelt es sich um Metadatenschemas bzw. Metadatenstandards (i.e. ein standardisiertes Metadatenschema). Die meisten Metadatenstandards besitzen eine festgelegte Anzahl an standardisierten Datenkategorien, die zur Kategorisierung der Metadaten einer Ressource dienen (Beispiel: title als DatCat für den Titel einer Ressource), wie beispielsweise der aus 15 Kernelementen bestehende Dublin Core (DC) Metadatenstandard. Neben diesen traditionellen Metadatenstandards existiert jedoch auch ein kürzlich im Kontext von CLARIN entwickeltes Metadatenschema, das nicht über eine festgelegte Anzahl an vordefinierten Datenkategorien verfügt, sondern individuelle Anpassungen ermöglicht: das komponentenbasierte Metadatenschema CMDI (Component Metadata Infrastructure).

CMDI zeichnet sich insbesondere durch seine Flexibilität in Hinblick auf die nach individuellen Bedürfnissen ausgerichtete Struktur der Metadateninstanzen aus. Dazu zählt u.a. auch, dass Datenkategorien vom Ersteller der Metadaten selbst definiert werden können, wenn keine zutreffenden bereits eingeführten DatCats für konkrete Beschreibungsfälle existieren. Dadurch kann ein zentrales Problem beim Erstellen von Metadateninstanzen vermieden werden: Tag Abuse. Der Begriff Tag Abuse bezeichnet den Gebrauch eines Tags bzw. Elements, d.h. der Repräsentation einer Datenkategorie in einer Markupsprache wie z.B. der Extensible Markup Language - XML (vgl. Glossar für weitere Informationen), für einen Zweck, der nicht der Definition der jeweiligen DatCat entspricht. Häufig tritt dieses Problem u.a. auf, wenn ein Metadatenschema nur über eine geringe Anzahl an Datenkategorien verfügt, die einen konkreten Anwendungsfall in den Metadaten nicht adäquat repräsentieren können. Oftmals führt dies dazu, dass eine Datenkategorie entfremdet wird und nicht mehr ihrem vom Metadatenschema festgelegten Gebrauch entspricht. Dieses Phänomen hat letztlich zur Folge, dass ein wesentliches Ziel der Metadaten nicht mehr korrekt ausgeführt werden kann: die Extraktion von Informationen auf der Grundlage von Metadaten. Wenn also die Inhalte einer Datenkategorie nicht ihrer Definition entsprechen (d.h. wenn z.B. die Datenkategorie creator keine Informationen über den Ersteller einer Ressource enthält, sondern andere Angaben, die nicht im Bezug zum Ersteller stehen), können für den Suchkontext nur falsche Informationen anstelle der gewünschten Angaben abgerufen werden. Daher bietet CMDI an dieser Stelle die Möglichkeit, passende Datenkategorien auszuwählen oder neue einzuführen. Nichtsdestotrotz bedarf dieser Ansatz ebenso einer Dokumentation wie Standardisierung der Datenkategorien, um Suchprozesse erfolgreich durchführen zu können. Wie kann jedoch eine solche Standardisierung umgesetzt werden, ohne die Flexibilität von CMDI zu mindern?

Einen Lösungsansatz bietet die Verwendung eines Verzeichnisses zur Verwaltung, Dokumentation und Standardisierung von Datenkategorien: ISOcat (Data Category Registry for ISO TC 37). ISOcat wird im Bereich der Terminologieverwaltungssysteme und Sprachressourcen verwendet und am Max Planck Institut für Psycholinguistik (MPI) in Nijmegen (Niederlande) verwaltet. Dieses Verzeichnis enthält sowohl bereits standardisierte Datenkategorien traditioneller Metadatenstandards, wie z.B. Dublin Core (DC), als auch Definitionen von Datenkategorien, die in CMDI verwendet werden können und größtenteils noch den ISO-Standardisierungsprozess durchlaufen müssen. Das Verzeichnis bietet dem Nutzer nicht nur die Möglichkeit nach Datenkategorien zu suchen, sondern auch vorhandene zu editieren oder neue einzuführen. Neue Kategorien können zunächst im privaten Arbeitsplatz gespeichert und schließlich nach einer erfolgreich abgeschlossenen Standardisierung veröffentlicht werden. Nutzer können somit das komponentenbasierte Verfahren von CMDI nutzen und durch die Unterstützung von ISOcat den eigenen Bedürfnissen entsprechende Datenkategorien verwenden. Durch diese Verfahrensweise wird somit erricht, dass die Flexibilität von CMDI nicht gemindert wird. Vielmehr wird sie sogar erweitert, da sowohl durch die in ISOcat vorhandenen Datenkategorien anderer Metadatenstandards die Kompatibilität von CMDI zu diesen Standards als auch die Nachhaltigkeit aller Datenkategorien durch die Standardisierung im Verzeichnis gewährleistet wird. Beide Aspekte werden durch die Vergabe eines Persistent Identifier (PID) für jede Datenkategorie realisiert. Durch dieses Vorhandensein spielt die Benennung eines Elements nicht die wichtigste Rolle beim Verweis auf eine Datenkategorie, weil stattdessen ein PID durch seine Persistenz, d.h. seine Dauerhaftigkeit, sicherstellt, dass immer eindeutig auf dieselbe Datenkategorie referenziert werden kann.

Exkurs: Persistent Identifier
Ein Persistent Identifier (PID) ist ein spezieller Typ der Identifikatoren, der auf eine Ressource referenziert und sich durch seine Persistenz auszeichnet. Im Gegensatz zum Auffinden von Ressourcen über URLs, die zwar eindeutig, aber als Referenzen auf eine Ressource beim Ändern der Adressierung nicht mehr gültig sind, treten diese Problematiken bei der Verwendung von PIDs nicht auf. Ein Persistent Identifier trennt die Vergabe eines eindeutigen Identifikators für eine Ressource und die Adressierung der Ressource voneinander. So bleiben die vergebenen PIDs auch bei Standortwechseln der Ressource gültig, sodass diese dauerhaft aufgefunden werden können. Aus technischer Sicht wird ein eindeutiger PID für eine Ressource vergeben, der in einem Zwischenprozess in die zugehörige URL umgewandelt wird. Dabei kann eine Ressource auch mehrere Standorte aufweisen, aber es wird pro Ressource nur ein PID vergeben, der den zutreffenden URLs zugeordnet wird. Für diesen Prozess sind Systeme erforderlich, die PIDs vergeben und den URLs langfristig zuordnen, wie z.B. das Handle-System. Weitere Informationen finden sich unter: http://www.pidconsortium.eu/, http://handle.net/

Neben der Angabe des PID enthält jeder Eintrag für eine Datenkategorie in ISOcat außerdem drei verschiedene Informationstypen zu der jeweiligen Kategorie: administrative, beschreibende und konzeptuelle Informationen. Administrative Informationen beinhalten z.B. den Namen einer Kategorie, ihren Status im ISO-Standardisierungsprozess und das Erstellungsdatum. Informationen zur Beschreibung der Datenkategorie werden in verschiedenen Sprachen angegeben und geben z.B. den Namen der Datenkategorie und eine Inhaltsdefinition an. Konzeptuelle Informationen legen den zulässigen Wertebereich einer Datenkategorie fest (z.B. das Format einer Datumsangabe, kontrolliertes Vokabular). Des Weiteren werden Angaben zum Urheber und Typ der Datenkategorie gemacht.

Abschließend gilt es festzuhalten, dass trotz der Flexibilität von CMDI Standardisierungen von Datenkategorien notwendig sind, die beispielsweise Suchprozessen, dem Austausch zwischen verschiedenen Metadatenschemas oder der Gewährleistung von Nachhaltigkeit dienen. Durch das unterstützend zur Verfügung stehende Verzeichnis ISOcat können Datenkategorien ohne einen Verlust an Flexibilität für das komponentenbasierte Metadatenschema CMDI standardisiert und nachhaltig bereitgestellt werden.

Weitere Informationen zu ISOcat finden sich auf folgender Webseite: http://www.isocat.org

Zugang zum ISOcat-Verzeichnis erhält man direkt über den folgenden Link: http://www.isocat.org/interface/index.html