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 beruäücksichtigen. Das gilt sowohl für verwendete Metadatenformate als auch ünterstützte Klassifikationssysteme.
Anforderungen/Empfehlungen aus dem DINI-Zertifikat 2013
Text DINI-Zertifikat 2013 | Bemerkungen | ||
---|---|---|---|
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.
|
| |
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.
| ||
M.A.1-1 | Die OAI-Schnittstelle verhält sich konform gemäß der Protokollspezifikation in der Version 2.0
| 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.
| 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-Schemas und weiterer verwendeter XML-Schemata für die Metadatenformate gültig.
| XML-Schema des Metadatenformats verpflichtend mit angeben! UM, 20150622: | |
M.A.1-4 | Die OAI-Schnittstelle unterstützt das inkrementelle Harvesting in korrekter Form.
| 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.
| 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 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.
| ||
E.A.1-3 | Die Antwort auf die OAI-Anfrage Identify liefert umfassende Angaben zum Dienst.
| 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.
| ||
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
| 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.
| 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.
| 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.
| ||
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.
| 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: | |
E.A.2-3 | Die Lebensdauer von Resumption Tokens beträgt mindestens 24 Stunden
| OAI-PMH-relevant. Uneingeschränkt gültig (FSu) | |
E.A.2-4 | Das Attribut completeListSize wird verwendet
| 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.
| Gibt es hier Einschränkungen (creator?) (FSu) | |
M.A.3-2 | In jedem verwendeten DC-Element wird immer nur genau ein Wert referenziert.
| 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.
| 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.
| das sollte kompatibel zum Endergebnis der COAR IG Vocabularies sein.
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.
| 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.
| 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.
| ||
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.
| Hier koennten die spezifischen Angaben zu digitalen Versionen eine Rolle spielen, auch im Bezug zu dc:relation (FSu), s. auch naechste Zeile | |
E.A.3-4 | Das Element relation wird für die Nennung von Objekten verwendet, die mit dem beschriebenen Dokument in einer Beziehung stehen
| ||
E.A.3-5 | Das Element subject wird für Angaben über das Thema des beschriebenen Dokuments verwendet
| ||
E.A.3-6 | Das Element date wird pro Metadatensatz nur einmalig angegeben.
| Ü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
| Übertragbar (FSu) | |
E.A.3-8 | In einem identifier-Element wird ein direkter Link zum Volltext geliefert.
| 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.
| siehe http://www.loc.gov/standards/sru/sru-1-2.html | |
E | Die SRU-Schnittstelle erfüllt den Standard SRU 2.0.
| 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.
| 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.
| siehe http://iiif.io/api/image/2.0/ |