"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.

Optional oder Pflicht: Welche Metadatenfelder ausfüllen

Details
Erstellt am Dienstag, 10. Januar 2012 08:24
Geschrieben von Thorsten Trippel

Häufig wurden wir in jüngerer Zeit bei Metadaten nach dem CMDI-Modell gefragt, was denn ausgefüllt werden sollte, was nicht, was optional sei und was Pflichtfelder wären. Daher wollen wir kurz erläutern, welche Grundlagen wir verwenden, wenn ein Profil, also ein Schema, für Metadaten angelegt wird. Die Abgrenzung ist dabei häufig nicht trennscharf, d.h. es ist nicht immer eindeutig, wie etwas zu geschehen hat, da einige der zugrundeliegenden Prinzipien in einem Spannungsverhältnis zueinander stehen.

Prinzip 1: Alles beschreiben können, was Experten für einen Ressourcentyp zur Beschreibung haben möchten

Experten in einem Fachbereich haben häufig sehr konkrete Vorstellungen davon, was angegeben muss, um ihre Ressource mit einer anderen Ressource zu vergleichen. Dies ist von Bereich zu Bereich verschieden und hier bietet sich das CMDI-Modell natürlich an. In Kooperation mit den Bereichsexperten können so Metadatenprofile erstellt werden, die eine Ressource eines bestimmten Typs gut beschreiben.

Da verschiedene Experten eines Bereiches allerdings auf unterschiedliche Beschreibungen achten, kommt es vor, dass hier die Profile viel reicher sind, als der einzelne Experte es gerne hätte. Die Möglichkeit, alles beschreiben zu können, was mindestens ein Experte für einen konkreten Ressourcentyp für sinnvoll erachtet, erhöht damit die Komplexität des Profils.

Alles, was für Experten zur Beschreibung einer Ressource notwendig und sinnvoll erscheint, sollte also verpflichtend angegegeben werden. Allerdings ist das nicht immer möglich.

Prinzip 2: Nichts verpflichtend machen, was für einen Ressourcentyp möglicherweise nicht angegegeben werden kann

Sogar in älteren Metadatenschemas wie Dublin Core ist im Prinzip erstmal jede Datenkategorie optional. Dies liegt daran, dass man für fast jede Datenkategorie Fälle konstruieren kann oder sogar Beispiele dafür vorliegen, dass man etwas nicht angeben kann. Internationale Standards zum Beispiel geben keine Autoren oder Herausgeber an, bei älteren Daten ist das Entstehungsdatum oder das Veröffentlichungsdatum nicht zu ermitteln, manche Dokumente haben mehrere Bezeichnungen, aber keinen Titel, etc.

Zentral für alle Arten von Ressourcen ist daher nur ein Identifikator, eine eindeutige, vielleicht sogar kryptische Bezeichnung wie eine Inventarnummer, eine URI, etc.

Für einzelne Ressourcentypen ist es allerdings auch möglich, weitere Pflichtfelder zu verlangen, z.B. weil sie sonst unbrauchbar wären. So ist es für Computerprogramme, die als Webservice realisiert werden, erforderlich, die URL des Service zu kennen, um ihn benutzen zu können, und er muss ebenfalls eine URL besitzen. Für die meisten Ressourcen ist es möglich und sinnvoll, einen Kontakt anzugeben, von dem man die Ressource erhalten kann, etc. Gerade bei neu erstellten Ressourcen ist es meist möglich, sehr detaillierte Angaben zu machen.

Auch für neue Ressourcen ist es aber möglich, dass es Gründe gibt, warum bestimmte Angaben nicht gemacht werden sollen. So ist es für Experimente zum Teil problematisch, eine konkrete Beschreibung zu erfassen, wenn die zugehörige Publikation noch nicht erschienen ist, um dem Review-Prozess, der Vermeidung von Doppelveröffentlichungen, etc., nicht vorzugreifen.

Damit sollten also die fraglichen Datenkategorien optional sein. Optionalität führt aber dazu, dass Applikationen sie nicht verlässlich verwenden können, was zum folgenden Prinzip führt:

Prinzip 3: Alles ausfüllen, was möglich und sinnvoll ist, ohne Datenkategorien zu weit zu interpretieren

Grundsätzlich gilt, dass die Angaben aller Datenkategorien, die angeboten werden, ausgefüllt werden sollten, wenn der erstellende Experte einen sinnvollen Inhalt angeben kann. Dabei darf die Datenkategorie nicht zu weit interpretiert werden, was zu einem sogenannten Tag-Abuse führen könnte.

Je vollständiger eine Beschreibung ausgefüllt ist, desto mehr Applikationen können sinnvoll mit den Beschreibungen umgehen und desto genauer ist eine Beschreibung für einen anderen Experten, der die Beschreibung sieht. Das heißt, auch wenn jemand meint, eine Datenkategorie sei redundant oder wenig aussagekräftig, so ist es doch möglich, dass eine Anwendung, die von jemand anderem erdacht wurde, diese Datenkategorie verwendet. Da Profile eine Vereinheitlichung für die Beschreibung von Ressourcen darstellen, ist es auch dann sinnvoll, solche Kategorien auszufüllen.

Die Entscheidung, welche Datenkategorie ausgefüllt werden sollte, ist daher nicht immer leicht. Aber gerade die Einfachheit ist Teil eines weiteren Prinzips und soll dazu führen, dass die Nutzer von den Profilen Gebrauch machen.

Prinzip 4: So einfach wie möglich bleiben und möglichst wenig Strukturen verlangen

Da komplexe Strukturen und eine große Anzahl von Datenkategorien einen erheblichen Aufwand erfordern, sollte im Interesse der Kooperationswilligkeit der Experten eine Einfachheit angestrebt werden, so dass Experten schnell und ohne Schwierigkeiten die Beschreibungen anfertigen können.

Es gibt allerdings auch Strukturen, die zur Einfachheit beitragen, also zur Strukturierung der Eingabe für Benutzer. Sofern es sinnvoll erscheint, sollten entsprechende Strukturen daher eingeführt werden.

Spannungsfelder

Insbesondere das Prinzip 4 der Einfachheit führt häufig bei den anderen Prinzipien zu Problemen. Wenn man Experten mit Prinzip 1 jegliche Beschreibungsmächtigkeit an die Hand gibt, dann kann dies genau zu einer höheren Komplexität führen.

Das Prinzip 2, nichts verpflichtend zu machen, was möglicherweise nicht ausgefüllt werden kann, steht in einem möglichen Spannungsverhältnis zu Prinzip 3, möglichst alles auszufülen. Und beide zusammen, auf Grund der Variabilität, überlassen die Entscheidung damit dem Benutzer, was wiederum eine höhere Komplexität bedeutet, ein Widerspruch zu Prinzip 4.

Resümee

Auch wenn es einfache Leitlinien bei der Erstellung von Profilen gibt, ist es am Ende nicht immer eindeutig, wie ein Profil die Frage beantworten kann, ob ein Element optional oder verpflichtend sein muss, daher wird man sich in der Praxis häufig für die schwächeren Anforderungen entscheiden und Datenkategorien optional machen. Wenn ein Benutzer aber in einem Metadateneditor die Datenkategorien sieht, dann sollte er sie als dringende Empfehlung interpretieren, sie auszufüllen, wenn es möglich ist, nicht als "optional" im Sinne von "freiwillig".