10. November 2011
von Stefan Buddenbohm
Mit OAI-PMH und Dublin Core Simple existiert nun schon seit Jahren ein “dynamisches Duo” aus Harvesting-Protokoll und Metadatenformat dessen Verbreitungsgrad in der digitalen Repositorienlandschaft den eigenen Erfolg markiert. Begünstigt wurde dieser Erfolg sicherlich nicht zuletzt auch durch die Einfachheit, Flexibilität und damit Umsetzbarkeit von DC-Simple, jedoch sollte sich diese Flexibilität neben dem Segen auch als Fluch erweisen.
Dem Ziel der Austauschbarkeit von Metadaten und der formalen Vereinheitlichung zur Schaffung durchsuchbarer und vergleichbarer Metadaten steht die Freiheit der Data Provider gegenüber genau dieses Ziel sehr leicht aus den Augen verlieren zu dürfen. Die Inhalte der einzelnen Felder und ihre innere Struktur sind nur fachlichen Vorgaben unterlegen, nicht jedoch formalen. So dürfen diese Felder schliesslich frei belegt werden, solange sie auf irgendeine Weise die geforderte fachliche Anforderung erfüllen. Angefangen von der einfachen Nennung des Autors, finden sich in den dc:author-Feldern beispielsweise Angaben wie ‘Vorname Nachname’, ‘Nachname, Vorname’ bis hinzu ‘Nachname Vorname’. Das ganze dann noch kombiniert mit Kürzeln, Titeln und zusätzlichen Vornamen einer Person wird dann maschinell doch zu einer Herausforderung, wenn diese Feldinhalte nicht nur als Ganzes erfasst werden sollen.
Ähnlich aufregend ist beispielsweise auch die Zuordnung zu fachlichen Klassifikationen. Aus einer Angabe ‘ddc:004′ lässt sich ablesen das es sich sehr wahrscheinlich um eine Zuordnung zum Fachgebiet Informatik nach der Dewey-Dezimalklassifikation handelt. Bei der Angabe ’004′ liesse sich der gleiche Informationsgehalt noch mutmaßen, während der Versuch der Zuordnung einer ’4′ schon zum Glücksspiel zählt.
Die Data Provider kann man dafür nur bedingt kritisieren, halten sie sich doch streng genommen mit diesen Angaben weitgehend an die Vorgaben des Duos. welches womöglich nicht so erfolgreich wäre, wenn es als Trio mit einer zusätzlichen Anwendungreferenz zu DC-Simple die Bühne betreten hätte. So obliegt es den aggregierenden Service Providern diese finale Homogenisierung der Metadaten vorzunehmen, um die OAI-Vision bestmöglich zu verwirklichen. In der Folge sind neben dem Mapping auf bestimmte Vokabulare und einfachen Algorithmen zum Zuordnen von Feldinhalten auch entsprechende Guidelines für Data Provider aggregatorseitig (Driver-Guidelines, OpenAIRE-Guidelines, DINI-Zertifikat etc.) geschaffen worden, um aus dieser einseitigen Vereinheitlichung auch die Repositorienbetrieber wieder vermehrt in die Verantwortung zu nehmen . Letztendlich erfordert es ein beidseitiges Zutun, um einen optimalen maschinellen Dialog zu ermöglichen.
Ein Hilfsmittel zur Überprüfung und Steigerung der tatsächlichen Metadatenqualität eines Repositories sind Validatoren. Zum einen dienen diese den Data Providern bei der technischen Umsetzung von OAI-PMH-Schnittstellen und dem formal korrekten Export der Metadaten mit Blick auf weiterführende Guidelines. Zum anderen helfen sie den Service Providern zu erkennen, welche Metadatenqualität ein Repository mit sich bringt.
Auch OA-Netzwerk hat es sich zum Ziel gemacht die Repositorienbetreiber mit technischen Hilfsmitteln bei der Umsetzung einer OAI-PMH Schnittstelle und den konkreten Anforderungen des aktuellen DINI-Zertifikats zu unterstützen. Aufbauend auf einem Validator der im Rahmen von OpenAIRE reimplmentiert wurde (Vielen Dank für den Support an die OpenAIRE Kollegen der University of Athens), haben wir diesen um diverse Funktionen erweitert. Zum einen wurde dieser um ein eigenes Scoring-System zur Bewertung der DINI-Zertifikatskonformität erweitert. Dies war nötig da wir in einem ersten Schritt verschiedene Testtypen zu Gesamttests aggregierbar gemacht haben, damit es letztlich nur den einen DINI-Check gibt, und nicht verschiedene aus denen die Fehler zusammengesucht werden müssen. Darüber hinaus wollten wir eine bestmögliche Veranschaulichung der entstandenen Fehlerquellen bieten, damit Betreiber auf den ersten Blick erkennen können, welche Kriterien nicht erfüllt sind und wie sie konkret zu erfüllen sind. Auf Metadatensatzebene werden die Fehler in den konkreten Server-Responses grafisch hervorgehoben. (Error Highlighting)
Eine erste Testversion des OA-Netzwerk/DINI-Validators ist derzeit unter folgender Adresse erreichbar:
http://oanet.cms.hu-berlin.de/validator
Nach Eingabe der Base-URL einer OAI-Schnittstelle wird die Prüfung durchgeführt. Nach Abschluss der Prüfung erhalten Sie eine Mail-Benachrichtigung. Das Ergebnis des Checks ist dabei nur für Sie einsehbar, d.h. nicht öffentlich verfügbar. Bitte beachten Sie, das sich der Validator noch in der Entwicklung befindet und daher nicht durchgehend verfügbar ist. Kritische Anmerkungen zum Validator, dem Verfahren und der Ergebnisdarstellung sind willkommen und können direkt an Sammy David, dem Autor dieses Eintrags geschickt werden.
Sammy David, Computer- und Medienservice der Humboldt Universität zu Berlin (sammy.davidATcms.hu-berlin.de)
