In diesem Abschnitt wird die Nutzung der integrierten OAI-Schnittstelle erläutert. Diese Schnittstelle liefert jedoch nicht die konkreten ausgelieferten Datenformate für das eigene Datenmodell wie Dublin Core, MODS, LIDO usw. Die hierfür erforderlichen Stylesheets müssen selbst erstellt werden.
Im folgenden soll die Konfiguration der OAI-Schnittstelle beschrieben werden. Zum Austausch von Metadaten unterstützt MyCoRe das Open Archives Initiative Protocol for Metadata Harvesting (OAI-PMH). Die Beschreibung des Standards finden Sie unter https://www.openarchives.org/pmh/. Machen Sie sich zunächst grob mit diesem Standard vertraut. In die Implementierung sind auch Anforderungen aus dem DINI-Zertifikat 2010 ( https://www.dini.de/dini-zertifikat/) eingeflossen.
Es ist möglich mehrere OAI-Provider parallel zu betreiben. So kann man beispielsweise einen OAIProvider für das Melden der Dissertationen an die Deutsche Nationalbibliothek verwenden und mit einem zweiten OAIProvider den gesamten Dokumentenbestand für OpenAccess-Portale wie OAIster oder BASE bereit stellen.
Als Unterscheidungskriterium gilt der Servlet-Name, wie er in der web.xml verwendet wird. Er ist auch Bestandteil der Property-Namen in den Konfigurationsdateien. Die Verwendung derselben Servletklasse ist möglich.
Das OAI2 Servlet muss in der web.xml aktiviert werden:
|
|
Für die Konfiguration der Schnittstelle sind eine Reihe von Properties notwendig. Viele können in der Defaulteinstellung verwendet werden, einige sind jedoch in der eigenen Anwendung zu überschreiben.
Für die Visualisierung der OAI-Requests im Webbrowser wird das OAI2 to HTML XSLT Style Sheet von Eprints verwendet.
Folgendes Property gibt den Pfad zu diesem Stylesheet in der eigenen Anwendung an:
|
|
Für die genaue Bedeutung der Properties und ihre möglichen Werte sei ein Blick in den OAI-Standard empfohlen:
|
|
Mittels Resumption Tokens kann die Rückgabe großer Mengen an Dokumenten partitioniert werden. Genauere Angaben entnehmen Sie der OAI-Spezifikation.
Für die Konfiguration werden folgende Properties verwendet:
|
|
Mit dem OAIAdapter wird der einheitliche, protokoll-spezifische Teil der OAImplementierung von den konkreten Anforderungen der Anwendung (MIR, MILESS, PAPYRI usw.) getrennt. Für MyCoRe-Anwendungen steht die Klasse MCROAIAdapter zur Verfügung. In wenigen Ausnahmefällen kann es notwendig sein, diese Klasse neu zu implementieren oder zu erweitern.
|
|
Die Erzeugung des Header- und des Metadatenteils eines OAI-Responses erfolgt generisch, es können aber auch Stylesheets dieses generische Verhalten überschreiben. Dann müssen entsprechende XSL-Dateien hinterlegt werden.
|
|
Mit den folgenden Properties lässt sich die Menge der Dokumente, die über die OAI-Schnittstelle ausgeliefert werden, einschränken und sortieren.
|
|
Das Konzept der Sets im OAI-Standard lässt sich mit dem Klassifikationskonzept von MyCoRe vergleichen. Daher bietet es sich an, Klassifikationen als Sets zu verwenden.
Mit dem Property FilterEmptySets kann bestimmt werden, ob auch leere Sets bei einem List-Sets-Request zurückgegeben werden.
|
|
Mit dem folgenden Property werden zunächst alle Sets definiert, die in der Anwendung verwendet werden sollen:
|
|
Mit einem XSLT-Stylesheet und unter Verwendung des URI-Resolvers kann aus einer MyCoRe-Klassifikation die entsprechende Ausgabe für einen OAI-List-Sets-Request generiert werden:
|
|
Mit dem Property FilterDisabledCategories kann hierbei pro Klassifikation bestimmt werden, ob Sets für
Klassifikationswerte ausgelassen werden sollen, die mit
<label xml:lang="x-disable" text="true" />
markiert sind.
|
|
Für die Suche nach Dokumenten, die als Inhalt eines Sets zurückgegeben werden sollen, kann einem Set-Namen ein Klassifikationsname zugeordnet werden:
|
|
Alternativ besteht auch die Möglichkeit, per URI-Resolver direkt eine XML-Datei mit der Set-Konfiguration anzugeben:
|
|
Beispiel für eine statische Sets Datei im XML Format:
|
|
Zu Beachten ist hierbei die Verwendung des OAI Namensraumes.
Bei statisch definierte Sets muss für jeden Eintrag ein Property gesetzt werden, welches eine Suchanfrage auf die Dokumente innerhalb des Sets zurückliefert:
|
|
Wenn die ID des Sets (setSpec) Doppelpunkte enthält, werden diese mit einem Backslash gequotet:
|
|
Zunächst sind die unterstützten Metadatenformate aufzulisten und dann jeweils Namensraum und URL der XMLSchema-Definition anzugeben:
|
|
Für jedes Metadatenformat ist außerdem ein XSL-Stylesheet zu erstellen, welches aus dem MyCoRe-Datenmodell das entsprechende Ausgabeformat erzeugt. Im MIR befinden sich beispielhafte Implementierungen für mods2oai_dc.xsl und mods2epicur.xsl. Diese sind jedoch in der Regel an das eigene Datenmodell anzupassen.
Damit das Repository OpenAIRE-compliant ist, müssen entsprechend der OpenAIRE-Spezifikation Informationen zum Forschungsprojekt erfasst werden. In der MIR-Anwendung stehen dafür die notwendigen Formular-Templates bereit. Auch sind die nötigen Suchfelder und Stylesheets vorhanden, um ein OpenAIRE-kompatibles DublinCore-Format aus dem MODS zu erzeugen. Wenn man dies nutzen und die OAI-Schnittstelle dafür konfigurieren möchte, sind die nachfolgenden Properties zu setzen. Wobei der obere Block für alle Anwendungen gleich bleiben sollte - hier werden nur die Sets an sich definiert. Der zweite Block zeigt die Solr-Anfragen, mit denen die Sets gebildet werden. Diese sind natürlich stark von den Inhalten abhängig. Das hier gezeigte Beispiel gilt für MODS in der MIR-Anwendung.
|
|
Hat man auch Forschungsdaten im Repository, könnte das datacite-Format interessant werden, dass OpenAIRE von Daten-Archiven verlangt. Auch hierfür ist für MODS bereits alles vorbereitet. Es müssen nur die nachfolgend spezifizierten properties gesetzt werden, um über die OAI-Schnittstelle auch das oai_datacite-Format auszuliefern.
|
|
Es gibt verschiedene Validatoren für die eigene OAI-Schnittstelle. Hier eine kurze Liste bekannter Seiten (Stand 10/2015):
Deutsch
English