• Erstellt von Unbekannter Benutzer (muelleru), zuletzt geändert von Unbekannter Benutzer (summannf) am 2015-06-19

Sie zeigen eine alte Version dieser Seite an. Zeigen Sie die aktuelle Version an.

Unterschiede anzeigen Seitenhistorie anzeigen

« Vorherige Version anzeigen Version 10 Nächste Version anzeigen »

Kriterienbereich Schnittstellen

Verantwortlich

  • Friedrich Summann (OAI: Anhang A1, A2)
  • Stefanie Rühle (OAI: Anhang A3)
  • Sebastian Meyer (SRU)

Grundsätzliches

Anforderungen/Empfehlungen aus dem DINI-Zertifikat 2013

 

 Text DINI-Zertifikat 2013Bemerkungen 
M.6-5
 Es existiert eine Webschnittstelle für Endnutzer/‑innen, über die auf alle vorgehaltenen Dokumente und die dazugehörigen Metadaten zugegriffen werden kann.
  • Darüber ist der gesamte Bestand, der über den Dienst bereitgestellt wird, erreichbar.  
  • Ziel: Webzugriff für Endnutzer (Webschnittstelle nochmal genauer definieren: "standardkonforme Browseransicht" HTML/JS o.ä.)
  • DFG-Viewer-Ansicht wäre auch ausreichend
 
M.6-6
Es ist eine OAI-Schnittstelle vorhanden, die den Anforderungen des OAI-PMH 2.0 entspricht und den OAI-Richtlinien von DINI genügt.
  •  Die Richtlinien für die OAI-Schnittstelle finden sich in Anhang A in diesem Dokument.
  
M.A.1-1
Die OAI-Schnittstelle verhält sich konform gemäß der Protokollspezifikation in der Version 2.0
  • Daraus ergeben sich alle anderen Mindestanforderungen in diesem Abschnitt. 
Diese Anforderung gilt, da es die technischen Grundlagen betrifft, uneingeschränkt auch für Digitale Sammlungen 
M.A.1-2
Die OAI-Schnittstelle ist dauerhaft unter der registrierten Basis-URL erreichbar und verfügt über eine hinreichende Performanz.
  • Dies ist für die zuverlässige Nutzung der Schnittstelle durch Service Provider unerlässlich und sorgt unter anderem dafür, dass Kommunikationsprobleme – insbesondere vorzeitigabgebrochene Harvesting-Vorgänge  – minimiert werden.
  
M.A.1-3

Alle durch die OAI-Schnittstelle ausgelieferten Antworten sind im Sinne von XML wohlgeformt und hinsichtlich des in der OAI-Spezifikation angegebenen XML-Sche­mas und weiterer verwendeter XML-Schemata für die Metadatenformate gültig.

  • Schwierigkeiten treten regelmäßig vor allem mit Zeichenkodierungen und Sonderzeichen innerhalb der Metadatenelemente sowie durch in den XML-Stream eingestreute Fehlermeldungen aus Datenbanken oder Anwendungen auf.
  • XML-Schema des Metadatenformats verpflichtend mit angeben!
 
M.A.1-4
Die OAI-Schnittstelle unterstützt das inkrementelle Harvesting in korrekter Form.

  • Voraussetzung dafür ist, dass im Timestamp-Element jedes Datensatzes das Datum der Erstellung bzw. der letzten Aktualisierung der Metadaten angegeben wird – und nicht beispielsweise das Publikationsdatum des dazugehörigen Dokuments.
  • Dadurch können Service Provider regelmäßig den Datenbestand abgleichen, ohne jeweils alle Metadatensätze anzufordern. Dazu muss der Data Provider
    für die OAI-Anfragen ListRecords und ListIdentifiers die Parameter from und until unterstützen und dabei jeweils die korrekten Teilmengen des Datenbestandes liefern, und zwar zumindest mit der tagesaktuellen Granularität (YYYY-MM-DD)

  
M.A.1-5
Die OAI-Schnittstelle verwendet Set-Informationen in konsistenter Form.
  • Dazu zählt insbesondere, dass alle Sets, denen Datensätzezugeordnet sind, auch in der Antwort auf die Anfrage
  • ListSets geliefert werden, und dass alle Datensätze, die auf eine mit dem Parameter set qualifizierte Anfrage der Typen
  • ListRecords bzw. ListIdentifiers geliefert werden, gemäß ihren Header-Informationen zu dem betreffenden Set gehören
  
E.A.1-1
Die OAI-Schnittstelle wird durch den Betreiber in regelmäßigen Abständen überprüft (durch manuelle Tests) und maschinell validiert (durch automatische Werkzeuge)
  • Damit wird gewährleistet, dass interne Probleme der OAI-Schnittstelle nicht unentdeckt bleiben
  • Siehe dazu Fußnote xx
Damit soll die Verfügbarkeit des Systems und seiner Schnittstellen optimiert werden. 
E.A.1-2
Bei gravierenden Änderungen an der OAI-Schnittstelle werden entsprechende Informationen an die Instanzen (Verzeichnisse) weitergegeben, bei denen die OAI-Schnittstelle bzw. der Dienst registriert ist.
  • Dadurch wird es für Service Provider möglich, auf Veränderungen adäquat zu reagieren. Zu relevanten Änderungen im Sinne dieser Empfehlung gehören Versionsumstellungen, die Änderung der Basis-URL und ein Wechsel der Software, mit der der Dienst betrieben wird.
  • Für die einschlägigen Verzeichnisse siehe auch Kriterium 1 –  Sichtbarkeit des Gesamtangebotes im Abschnitt xx
  
E.A.1-3
Die Antwort auf die OAI-Anfrage Identify liefert umfassende Angaben zum Dienst.
  • Dazu zählen insbesondere eine gültige E-Mail-Adresse des Administrators/der Administratorin (Element adminEmail) und eine kurze Beschreibung des Dienstes (Element description) in englischer Sprache.
 Damit soll die globale Sichtbarkeit des Systems und ihrer Inhalte gewährleistet werden! 
E.A.1-4
Für die einzelnen Metadatensätze, die auf die OAI-Anfragen ListRecords und GetRecord geliefert werden, kann das Element provenance im
About-Container verwendet werden
  
E.A.1-5
Die deskriptiven Informationen innerhalb der OAI-Antworten sind in Englisch angegeben.
  • dazu zählen beispielsweise die Elemente in der Antwort auf die Anfrage Identify und die Beschreibungen der Sets mit dem Element setName in der Antwort auf die Anfrage ListSets
  
M.A.2-1

Es existiert ein Set mit der Bezeichnung (setSpec) „open_access“. Zu diesem Set gehören alle Metadatensätze, die sich auf Open-Access-Dokumente beziehen, d.h. bei diesen steht ein zugehöriger und verlinkter Volltext frei zur Verfügung

  • Diese Anforderung gilt auch für Dienste, bei denen grundsätzlich alle Dokumente im Sinne von Open Access veröffentlicht werden. In diesem Fall würden alle Metadatensätze in dieses Set fallen.


  
M.A.2-2

Es existiert eine Set-Struktur wie in Tabelle 1 abgebildet, in die alle Metadatensätze gemäß der fachlichen Zuordnung der dazugehörigen Dokumente eingeordnet sind.

  • Eine Zuordnung zu mehreren DDC-Klassen ist möglich
Anpassen (FSu) 
M.A.2-3

Es existiert eine Set-Struktur wie in Tabelle 2 abgebildet, in die alle Metadatensätze gemäß der Zuordnung zu Dokument- und Publikationstypen der dazugehörigen Dokumente eingeordnet sind.

  • Gemäß den Erläuterungen, die in den DINI-Empfehlungen Gemeinsames Vokabular für Publikations- und Dokumenttypen enthalten sind, ist die Zuordnung von Dokumenten zu mehreren Publikations- und Dokumenttypen erlaubt und sogar empfohlen (siehe Beispiel 1).


Anpassen (FSu) 
E.A.2-1
Es existiert eine Set-Struktur wie in Tabelle 3 abgebildet, in die alle Metadatensätze gemäß dem jeweiligen Status im Publikationsprozess der zugehörigen Dokumente eingeordnet sind
  
M.A.2-4
Als Deleting Strategy für den Data Provider ist einer der Werte persistent oder transient gewählt.
  • OAI-PMH erlaubt die Optionen no, transient oder persistent. Wenn no angegeben ist, werden keine Informationen zu gelöschten Datensätzen übermittelt, was zu inkonsistenten Daten aufseiten von Service Providern führen kann.
  • Wenn die Option transient verwendet wird, müssen für gelöschte Dokumente noch mindestens einen Monat nach
    dem Löschdatum Records abrufbar sein, die die Löschung anzeigen.
  
E.A.2-2

Die Harvest Batch Size, also die maximale Anzahl der ausgelieferten Datensätze auf eine OAI-Anfrage ListRecords, beträgt mindestens 100 und höchstens 500.

  • Kleinere Datenpakete erhöhen die Anzahl der erforderlichen OAI-Anfragen und damit Laufzeiten und Fehleranfälligkeit der Kommunikation unnötig. Bei größeren Datenpaketen erhöht sich die Gefahr von Übertragungsfehlern.


 Speichergröße als Parameter berücksichtigen! (vor allem für komplexe Datenformate mit potentiell sehr großen Record-Größen, z.B. METS/MODS, EAD) 
E.A.2-3
Die Lebensdauer von Resumption Tokens beträgt mindestens 24 Stunden
  • Mit der Lebensdauer, die im Attribut lifeSpan angegeben wird, ist die Zeitspanne gemeint, innerhalb derer der Data Provider die Fortsetzung einer unvollständigen Datenlieferung garantiert. Ist sie zu kurz ausgelegt, kann dies unter Umständen zum Abbruch des gesamten Harvesting
    -Vorgangs führen, weil sie beendet ist, bevor die Daten der vorhergehenden Lieferung vollständig übertragen wurden.

  • In manchen Fällen kommt es zu Problemen beim Handling der Resumption Tokens, d.h. Folge-Anfragen mit Resumption Tokens werden nicht oder nicht korrekt beantwortet. Daher sollte die Funktionsfähigkeit explizit geprüft werden.
.
  
E.A.2-4
Das Attribut completeListSize wird verwendet

 

  • Darin kann die Größe der gesamten Ergebnismenge angegeben werden, die für die Steuerung und Überprüfung des gesamten Harvesting-Vorgangs eine wichtige Information darstellt, laut Protokollspezifikation allerdings optional ist
  
M.A.3-1
In den im Format Dublin Core (oai_dc) ausgelieferten Datensätzen werden zumindest die Elemente creator, title, date, type und identifier mit Inhalt ausgeliefert.
  

 

 

 

  • Keine Stichwörter