| Text DINI-Zertifikat 2013 | Bemerkungen | |
---|
M.6-5 | - 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.
| 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. - 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! | |
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
| 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
| 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? | |
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. | | |
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. | |
E.A.2-3 | Die Lebensdauer von Resumption Tokens beträgt mindestens 24 Stunden | | |
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.
- Diese Elemente sind für eine minimale Beschreibung wissenschaftlicher elektronischer Dokumente erforderlich
| | |
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.
| | |
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.
| | |
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
| | |
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.
| das sollte kompatibel zum Endergebnis der COAR IG Vocabularies sein | |
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. 34 35 36 37 | | |