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

Kriterienbereich Schnittstellen

Verantwortlich

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

Grundsätzliches

Digitale Sammlungen enthalten zahlreiche digitale Objekte mit sehr heterogener Beschaffenheit. Entsprechend müssen Metadaten zur Beschreibung die heterogenen Attribute beschreiben können. Andererseits können die enthaltenen Objekte in zahlreichen Kontexten (fachspezifisch, geographisch, Themenbereich) von Interesse sein und daher ist eine allgemeine generische Bereitstellung ein ebenso wichtiges Kriterium. Offene Schnittstellen sollten daher beide Aspekte bedienen und sowohl eine ihren Kontext berücksichtigende Struktur als auch eine allgemeine kontext-übergreifende Semantik berücksichtigen. Das gilt sowohl für verwendete Metadatenformate als auch unterstützte Klassifikationssysteme.

 

 

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
    Da bin ich persoenlich skeptischer, siehe Anmerkung unten (FSu)
 
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.
dito. 
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!

UM, 20150622:
Ergibt sich dies rein formal nicht schon aus der Forderung nach Gültigkeit?
Jedenfalls schadet es nichts, diesen Hinweis als weiteren Kommentar in die Anforderung mit aufzunehmen!

 
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)

UM: Übernehmen!

FSU: Gilt für Digitale Sammlungen ganz besonders, da nach meiner Erfahrung die Zahl der Objekte über dem Durchschnitt liegt!

 
M.A.1-5
Die OAI-Schnittstelle verwendet Set-Informationen in konsistenter Form.
  • Dazu zählt insbesondere, dass alle Sets, denen Datensätze zugeordnet 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
UM: Übernehmen! 
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.


UM: Was machen wir aus dieser Anforderung für die digitalen Sammlungen?

FSu: Nach unseren aktuellen Ansaetzen und Erfahrungen halte ich den dritten Weg, auf Dokumentebene (in DC mit dc:rights) den OA Status, aber auch Lizenzinformationen mit Vokabularnutzung auszuliefern, für die Vorzugsalternative. Letzteres ist fuer Europeana und vermutlich auch die DDB sehr relevant. Aus meiner Sicht zu ergänzen.

 
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), siehe M.6-3 
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), siehe M.6-4 
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)

UM: Mögliche Formulierung:
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. Sollte die Größe eines ausgelieferten Datensatzes 10 kB überschreiten, gilt abweichend: Die Harvest Batch Size ist so gewählt, dass die Größe einer XML-Antwort in der Regel zwischen 1 MB und 5 MB liegt.

FSu: Ist damit eine flexible Anpassung gemeint? Im Hinbick auf das Format und die jeweiligen Datensätze?


 
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.
.
OAI-PMH-relevant. Uneingeschränkt gültig (FSu) 
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
Uneingeschränkt gültig (FSu) 
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.

  • Diese Elemente sind für eine minimale Beschreibung wissenschaftlicher elektronischer Dokumente erforderlich
Gibt es hier Einschränkungen (creator?) (FSu) 
M.A.3-2
In jedem verwendeten DC-Element wird immer nur genau ein Wert referenziert.

  • Jedes DC-Element kann und darf innerhalb eines Metadatensatzes beliebig wiederholt werden.
  • Beispielsweise sollte jeder Autor/-innenname in einem einzelnen creator-Element erscheinen, jedes Schlagwort in einem eigenen subject-Element, jede URL in einem eigenen-identifier-Element usw
  • Damit werden eine klare Trennung der Einzelbestandteile und die korrekte Indexierung ermöglicht.
Eine Strukturfrage. Uneingeschränkt gültig (FSu) 
M.A.3-3
Für jeden Datensatz wird in mindestens einem identifier-Element eine operable URL auf der Basis eines Persistent Identifier angegeben.

  • Diese operable URL kann auf eine Einstiegsseite (Landing Page) oder direkt auf den Volltext führen.
  • Damit ein Persistent Identifier (beispielsweise ein URN oder ein DOI) zu einer operablen URL wird, muss ihm die Basis-URL eines entsprechenden Resolver-Dienstes vorangestellt werden (siehe Kriterium 5 – Informationssicherheit, Abschnitt 2.5, Mindestanforderungen M.5-7 und M.5-8)

  • Daneben können weitere identifier-Elemente URLs zu einer Landing Page, zu alternativen Versionen des Dokuments (beispielsweise in einem anderen Dateiformat) oder andere Identifikatoren (ISBN, DOI 34, ISSN, INSPIRE ID 35, arXiv-Identifier 36 u. ä.) enthalten.
    Identifier zu alternativen Versionen können im Element relation ergänzt werden.
Wichtig. Uneingeschränkt gültig (FSu) 
M.A.3-4
Für das Element creator wird folgende Binnenstruktur verwendet:
Nachname, Vorname.

Dasselbe gilt für das Element contributor, sofern darin ein Personenname genannt wird

Das sind natuerlich westlich gepraegte Strukturen mit Vor, Nachname. (FSu) 
M.A.3-5
Allen Dokumenten sind Dokument- bzw. Publikationstypen gemäß den Vorgaben aus den DINI-Empfehlungen Gemeinsames Vokabular für Publikations‑und Dokumenttypen in je eigenen type-Elementen zugewiesen.

  • Diese DINI-Empfehlung spricht sich dafür aus, immer auch zusätzlich einen Wert aus dem Dublin Core Type Vocabulary in einem eigenen type-Element anzugeben.
  • Für das zu verwendende Vokabular siehe die erste Spalte in Tabelle 2 in Abschnitt A.2.3

das sollte kompatibel zum Endergebnis der COAR IG Vocabularies sein.

FSu: Das wird noch eine interessante Diskussion (FSu, 7.12.15)

 

Denkbar sind Ergänzungen jenseits des IR-Ansatzes (FSu)

 

 
M.A.3-6
Für jeden Datensatz wird in mindestens einem subject-Element eine DNB-Sachgruppe angegeben, in die das beschriebene Dokument eingeordnet ist
Für das zu verwendende Vokabular siehe die erste Spalte in Tabelle 1 in Abschnitt A.2.2.
Diskussion (FSu) 
M.A.3-7
Der Inhalt des Elements language wird gemäß einer der ISO-Normen ISO 639-2 oder 639-3 angegeben.

Der Code für die Sprache Deutsch ist beispielsweise ger (ISO 639-2) bzw. deu (ISO 639-3), für Englisch lautet er eng
(beide Standard-Versionen)
 Uneingeschränkt übertragbar (FSu) 
M.A.3-8
Der Inhalt des Elements date wird gemäß der ISO-Norm 8601angegeben.
  • Das entspricht der Form YYYY-MM-DD

Uneingeschränkt übertragbar (FSu) 
E.A.3-1
Die Reihenfolge der identifier-Elemente innerhalb eines Metadatensatzes ist so gewählt, dass der bevorzugt zu verwendende an erster Stelle steht.

  • Viele Service Provider nehmen die Position als Anhaltspunkt für die Priorität, mit denen die URLs verwendet werden sollen. Aus Sicht von Betreibern von Open-Access-Repositorien und -
    Publikationsdiensten ist in der Regel der Link zur Einstiegsseite des Dokuments bevorzugt.

  • In Dublin Core spielt die Reihenfolge der Elemente zwar formal keine Rolle, die Beachtung dieser Konvention hat sich aber als pragmatischer Weg erwiesen, Service Providern die bevorzugt zu verwendende URL zu empfehlen.
Das ist eine DC-Strukturfrage und übertragbar (FSu) 
 E.A.3-2
Das Element contributor wird verwendet und enthält (pro Vorkommen) den Namen einer an der Erstellung des beschriebenen Dokuments beteiligten Person oder Institution.

  • Das kann beispielsweise der/die Gutachter/-in einer Dissertation oder der/die Herausgeber/-in eines Sammelbandes sein.

FSu: Die Erklärung ist IR-spezifisch. Entweder weglassen oder modifizieren 
E.A.3-3
Für das Element source werden die Vorgaben der Guidelines for Encoding Bibliographic Citation Information in Dublin Core Metadata berücksichtigt.
  • Das Element dient zur Nennung einer Vorlage für die elektronische Version

Hier koennten die spezifischen Angaben zu digitalen Versionen eine Rolle spielen, auch im

Bezug zu dc:relation (FSu), s. auch naechste Zeile

Daher eher wichtiger als bei IRs!

 
E.A.3-4
Das Element relation wird für die Nennung von Objekten verwendet, die mit dem beschriebenen Dokument in einer Beziehung stehen
  • Derartige Beziehungen sind beispielsweise hierarchische Zugehörigkeit (isPartOf) oder Aktualisierungen (isVersionOf)
  • Identifier zu derart verbundenen Objekten können ebenfalls im Feld relation angegeben werden.
  
E.A.3-5
Das Element subject wird für Angaben über das Thema des beschriebenen Dokuments verwendet
  • Üblicherweise wird das Thema durch Stichwörter, Schlagwörter oder Notationen aus Klassifikationssystemen beschrieben.
  
E.A.3-6
Das Element date wird pro Metadatensatz nur einmalig angegeben.

  • Dabei ist das Publikationsdatum gegenüber anderen Daten – etwa dem Einstell- oder Erzeugungsdatum – zu bevorzugen, da es für Endnutzer/-innen die größte Bedeutung hat.


Übertragbar (FSu) 
E.A.3-7
Werden die Metadaten eines Dienstes von einem Aggregator-Dienst bereitgestellt, muss dieser die Möglichkeit bieten, die von ihm erfassten Dienste einzeln zu harvesten. Dies kann durch eine Set-Gruppierung oder separate Basis-URLs geschehen

 

  • Dabei sollte die Schnittstelle des Aggregators die Auflistung und Zuordnung der erfassten selbstständigen Dienste und ihrer Institutionen ermöglichen.
  • Besonderes Gewicht ist auf die Punkte Normalisierung, Aktualität und Dublettenkontrolle der aggregierten Daten zu legen
Übertragbar (FSu) 
E.A.3-8
In einem identifier-Element wird ein direkter Link zum Objekt geliefert.
  • Für dieses Element ist auch die Verwendung eines Persistent Identifier (mit vorangestelltem Resolver) vorzuziehen (siehe M.5-8).
  • Im Gegensatz zum Link zur Landing Page ermöglicht ein zusätzlicher direkter Link zum Volltext dessen Nutzung für darauf aufsetzende externe Zusatzdienste (z.B. übergreifende Volltextsuche, Text‑Mining)

Das ist text-orientiert und könnte in

'zum Objekt' verändert werden.

 
E

Es ist eine SRU-Schnittstelle verfügbar, über die Suchanfragen an die Digitale Sammlung gerichtet werden können. Die Schnittstelle entspricht mindestens dem Standard SRU 1.2 und indexiert alle verfügbaren Metadaten.

  • Darüber ist der gesamte Bestand, der über den Dienst bereitgestellt wird, erreichbar.
siehe http://www.loc.gov/standards/sru/sru-1-2.html 
E

Die SRU-Schnittstelle erfüllt den Standard SRU 2.0.

  • SRU 2.0 ist ein anerkannter OASIS-Standard.
  • SRU 2.0 ist abwärtskompatibel zu SRU 1.2, bietet aber darüber hinaus weitergehende Möglichkeiten wie etwa die Verwendung der Abfragesprache CQL zur Formulierung komplexer Suchanfragen.
  • SRU 2.0 unterstützt zusätzlich ein OpenSearch-Binding und ermöglicht darüber z.B. die Implementierung eines Browser-Suchdienstes.
siehe http://www.loc.gov/standards/sru/sru-2-0.html und https://www.oasis-open.org/news/announcements/searchretrieve-version-1-0-oasis-standard-published 
E

Die SRU-Schnittstelle erfüllt den Standard SRU 2.0 und ermöglicht zusätzlich die Suche in den vorhandenen Volltexten.

  • Für die Volltextsuche ist ein eigener queryType zu definieren.
Ggf. sollte ein queryType vorgegeben werden, um hier Einheitlichkeit zu erreichen? 
E

Die Digitalisate werden über eine dem IIIF 2.0-Standard entsprechende Image Delivery API zur Verfügung gestellt.

  • Referenzierungen auf Digitalisate innerhalb der Metadaten sind bereits entsprechend vorformuliert, so dass sie ohne Kenntnis der API dereferenziert werden können.
  • Es ist in den Metadaten kenntlich gemacht, dass die Digitale Sammlung die IIIF Image API unterstützt.
siehe http://iiif.io/api/image/2.0/ 

 

 

 

  • Keine Stichwörter

2 Kommentare

  1. Unbekannter Benutzer (summannf) sagt:

    Bei der DFG-Viewer-Ansicht bin ich skeptisch. Beim IR-DINI-Zertifikat geht es auch darum, das komplette Angebot transparent und einheitlich zu vermitteln. Und das sehe ich beim DFG-Viewer nicht.

    Die Speichergroesse als Parameter verstehe ich nicht. Die Harvest Batch Size wird vom Data Provider festgelegt und mir sind bisher nur einheitliche Festlegungen fuer saemtliche angebotenen Formate (da das ResumptionToken-Handling auch fuer ListSets und ListMetadataFormats moeglich ist, sogar auch fuer alle in Frage kommenden OAI Verbs) untergekommen. Ich kann mir aber vorstellen, dass man in der Software, die die OAI-PMH-Schnittstelle bereitstellt, das Metadaten-Format beruecksichtigt.

    Noch eine Ergänzung: Der Formatumfang haengt natuerlich noch von anderen Groessen, z.B. wesentlich auch von der Länge der evtl. Information in description (Abstract, Table of Contents u.ä.)

    Bei unserem PUB-Repository habe ich den Groessenordnung zwischen oai_dc und mods verglichen und einen Unterschied von etwa 4 festgestellt.

     

     

  2. Rühle, Stefanie sagt:

    Der Größenunterschied zwischen oai_dc und mods ist nicht das Problem, sondern der Unterschied zwischen oai_dc und mets/mods. Vgl. z. B.

    http://www.digizeitschriften.de/oai2/?verb=GetRecord&metadataPrefix=oai_dc&identifier=oai:www.digizeitschriften.de:PPN345575393_0024

    und

    http://www.digizeitschriften.de/oai2/?verb=GetRecord&metadataPrefix=mets&identifier=oai:www.digizeitschriften.de:PPN345575393_0024