"Der Wissenschaftsrat fordert insbesondere die Forschungsförderer auf, Anreize zu schaffen, um qualitativ hochwertige Daten zu archivieren und langfristig zu sichern. Zu diesem Zweck sollten Referenz- und entsprechende Zitationsmöglichkeiten für Datensätze aufgebaut werden. Persistent Identifier (PID) bzw. Digital Object Identifier (DOI) erlauben eine eindeutige Identifizierung und Zitierbarkeit digital hinterlegter Daten selbst dann, wenn sie ihre Speicherorte (in der Regel referenziert über den Uniform Resource Locator, URL) wechseln."
Empfehlung zu Forschungsinfrastrukturen in den Geistes und Sozialwissenschaften, Wissenschaftsrat, Berlin, 28.01.2011, S.58

Persistenz und Metadaten

Bücher in einer Bibliothek haben eine dauerhafte Buchnummer, Inventar hat eine dauerhafte Inventarnummer, Ressourcen bekommen einen dauerhaften Identifikator (PID). Es stellt sich die Frage, wie das bei Metadatendateien aussieht.

Persistente Identifikatoren für Sprachressourcen, wie sie z.B. durch ISO 24619:2011 (Language resource management -- Persistent identification and sustainable access (PISA)) beschrieben werden, dienen dazu, dass man verlässlichen Zugriff auf Ressourcen hat und zwar über einen eindeutigen Identifikator. Eindeutig bedeutet, dass dieser Identifikator nur genau eine Ressource beschreibt.

Bei Büchern kann z.B. für eine neue Auflage eine neue ISBN vergeben werden. Wenn man sich auf eine bestimmte ISBN bezieht, sollte man sich darauf verlassen können, dass Zitate, Verweise, Seitenangaben, etc. immer gleich bleiben. Kann und sollte zeigt aber bereits, dass es auch bei Büchern Unterschiede gibt: Druckfehler werden zwischen zwei Drucken stillschweigend entfernt, ohne dass explizit darauf hingewiesen wird, dass das Buch eine neue ISBN erhält oder es als andere Ausgabe verkauft wird. Wie umfangreich solche Änderungen sein können, hängt im Wesentlichen von den Verlagen selbst ab.

Persistente Identifikatoren für elektronische Daten, z.B. DOI, URN, etc., verlangen normalerweise, dass eine Ressource nicht verändert werden darf. Das kann z.B. dadurch gewährleistet werden, dass die Datei digital signiert, ein MD5-Hash gebildet oder sonst ein Weg gefunden wird, um sicherzustellen, dass eine Datei identisch bleibt, auch wenn sie an unterschiedlichen Stellen aufbewahrt wird. Korrekturen von kleinen Fehlern etc. sind im Prinzip nicht vorgesehen. Daher stellt sich die Frage, was mit Metadaten passiert, die per Definitionem bestimmte anzupassende Bereiche haben: Über die Jahre können sich Institutionsnamen ändern, Ansprechpersonen bekommen andere Telefonnummern, Ressourcen werden an einem anderen Ort aufbewahrt und der Aufbewahrungsort steht in den Metadaten, etc. Gleichzeitig wird die Masterkopie der Metadaten, also die Version, von der alle anderen Services eine Kopie machen, mit der Ressource zusammen abgelegt und erhält schon aus praktischen Gründen eine PID, die die Ressource repräsentiert.

Bei uns im Repository bekommt jeder Data-Stream, der das Repository verlassen könnte, eine Handle-PID, d.h. auch Dokumentation und CMDI-Metadaten (nicht aber Fedora-Commons-interne Security Policies für das digitale Objekt, etc.). Aber die Frage ist, wie persistent insbesondere die Metadaten sind: Wollen wir bei der Anpassung einer Kontaktadresse eine neue Metadaten-Version und damit eine neue PID vergeben? Wir haben uns nach langer Diskussion entschieden, dass wir bei Anpassungen von CMDI-Metadaten immer von kleineren Änderungen, vergleichbar mit stillschweigenden Korrekturen im Verlagsbereich, ausgehen. Wenn sich die Ressource (= Medienfile, Annotation, etc.) nicht verändert, gibt es für das digitale Objekt keine neue PID, also auch nicht für die CMDI-Metadaten. Kommt ein Data Stream dazu (z.B. eine neue Dokumentation), wird dies ergänzt, wenn die Metadaten aktualisiert werden, d.h. es wird immer noch als "eine Ausgabe" gewertet. Abweichungen sind möglich, aber müssten durch einen Repository-Administrator durchgeführt werden.

Handles erlauben dabei gewisse Änderungen: "This allows the name to persist over changes of location, ownership, and other 'current state' conditions." (aus der Beschreibung der Handles). Metadaten werden daher als current state conditions interpretiert.

Dies stellt natürlich ein Paradoxon dar: Bei Metadata as Data würde man lieber auch Versionen unterscheiden, bei Metadata als reines Katalogformat braucht man vielleicht nicht unbedingt eine PID. Unsere Lösung ist daher ein Kompromiss. Bisher ist die Frage nach Versionierung von Metadaten eher ein hypothetisches Problem. Änderungen an den Metadaten sind bisher als Ersatz der alten Metadaten und Fehlerkorrektur gedacht. Daher erhalten sie keine neue PID, es wird aber davon ausgegangen, dass sie einen Wert an sich haben und daher eine PID benötigen.