Goobi und die Deutsche Digitale Bibliothek

Liebe Community,

etliche Einrichtungen werden ja ihre Daten an die Deutsche Digitale Bibliothek (DDB) liefern. Mit der Lieferung verbunden ist auch ein Report der DDB mit Hinweisen zu (mehr oder weniger) relevanten Fehlern bzw. Unstimmigkeiten in den gelieferten Metadaten.

Für unser letztes Datenset wurden insgesamt 27.238 “Fehler” angezeigt. Bei 525 Werken empfand ich diese Zahl als doch recht hoch. Allerdings handelte es sich bei dem Datenset um Vorgänge aus der Zeit vor Goobi, als wir noch kein Mets/ Mods erzeugt haben. Wir konnten die Anzahl der Fehler jetzt deutlich reduzieren, bei Null sind wir aber immer noch nicht.

Nun meine Frage: Ist es mit Goobi überhaupt möglich, die Anforderungen der DDB allumfassend zu erfüllen? Oder bleibt hier immer eine Restmenge an Fehlern übrig?

Viele Grüße, Andreas

1 „Gefällt mir“

Hallo Andreas,

der überwiegende Teil der Fehler werden Verstöße gegen die Namenskonventionen der Strukturelemente sein, erlaubt ist nur folgende Liste: http://dfg-viewer.de/strukturdatenset/

Da dabei jedes Strukturelement einzeln gezählt wird, kommen sehr schnell eine Menge Fehler zusammen, wenn z.B. statt “chapter” das Wort “Chapter” verwendet wurde. Das lässt sich zum Glück leicht beheben.

Schwieriger wird es, wenn ihr Sturkturelemente defniert habt, für die es in der DFG Liste keine Entsprechung gibt. Dann müsst ihr entweder die Elemente ändern oder damit leben, dass hier eine Meldung kommt und das Element beim Import in die DDB zu “section” geändert wird.

Gerüchte weise gibt es in den Testdaten “grüne” Datensätze, in freier Wildbahn habe ich jedoch noch keine zu Gesicht bekommen. Spätestens wenn Sammlungen verwendet werden, wird gegen die DDB Vorgaben verstoßen. Wobei diese Verstöße ja nur bedeuten, dass dieses betroffene Metadatum in der DDB nicht ausgewertet wird. Valide sind die Daten trotzdem.

Viele Grüße,
Robert

1 „Gefällt mir“

Hallo Robert,

danke für die weiterführenden Informationen. Bei uns wird unter anderem “Chapter” statt “chapter” (3.788 Fehler) verwendet, ebenso “Cover” statt “cover” (509 Fehler). Statt “Errata” müßte eigentlich “corrigenda” verwendet werden. Insgesamt machen diese abweichenden Bezeichnungen knapp 50% aller Fehler aus.

Verwendet Ihr standardmäßig diese http://dfg-viewer.de/strukturdatenset/ Liste? Eine sichtbare Änderung z.B. im Metadateneditor dürfte es doch nicht geben, wenn in der xml-Datei “chapter” statt “Chapter” verwendet wird?

Viele Grüße, Andreas

Wir hadern ja mit den standardisierten und nicht-standardisierten Datumsangaben, wobei wir letztere für die Anzeige im Viewer behalten wollen, so dass wir diese auch exportieren mit dem Attribut ‘displayLabel’:

<mods:dateIssued displayLabel="displayDate">[1911]</mods:dateIssued>
<mods:dateIssued encoding="w3cdtf" keyDate="yes">1911</mods:dateIssued>

Die DDB wollte unsere Unterscheidung hier nicht mittels der unterschiedlichen XML-Attribute abprüfen und berücksichtigt nur das erste Auftreten von ‘mods:dateIssued’.

Wir haben im Regelsatz (ruleset.xml) nun die Abbildung des standardisierten Datum-Werts vor der anderen Abbildung aufgeführt - und in den exportierten METS-Dateien entspricht unsere nun der von der DDB geforderte Reihenfolge:

<mods:dateIssued encoding="w3cdtf" keyDate="yes">1911</mods:dateIssued>
<mods:dateIssued displayLabel="displayDate">[1911]</mods:dateIssued>

Das hier vielleicht als kleiner Hinweis, der vielleicht nützlich sein kann.

2 „Gefällt mir“

Interessant, dieses Problem haben wir auch. Das müßte doch eigentlich für alle Goobi-Anwender gelten?

Dabei müßte es sich um diesen Fehler aus dem DDB-Protokoll handeln:

2.3.2 Datumsangaben sind nicht standardkonform
Die Datumsangaben in mods:dateIssued, mods:dateCreated und mods:dateCaptured müssen ISO
8601 konform sein. Ist dies nicht der Fall, kann es vorkommen, dass bei der Transformation der Daten
Datumsangaben verloren gehen.
Weitere Informationen zu diesem Element finden Sie im MODS-Anwendungsprofil Kapitel 2.4.2.4 –
2.4.2.6.

das oben genannte Beispiel ist kein valides MODS. Das Attribut displayLabel ist an dieser Stelle nicht erlaubt. Wenn es erlaubt wäre, könnte man das auch in einer Zeile ausgeben:

<mods:dateIssued encoding="w3cdtf" keyDate="yes" displayLabel="[1911]">1911</mods:dateIssued>

Da aber weder displayLabel noch etwas vergleichbares an dieser Stelle genutzt werden darf, würde ich das Anzeigejahr einfach nach mods:extension packen. Dann steht das normierte Datum in validem mods und unterhalb von mods:extension ist man sehr frei.

Hallo Robert,
kannst du das noch mit einem Beispiel versehen? (d.h. Angabe der Abbildung im Regelsatz, Erscheinen im METS, Adressierung in der Indexierungs-Konfiguration).
Vielen Dank!
Michael

1 „Gefällt mir“

Hallo Robert,

ich schließe mich dem Wunsch von @michael_zlb_berlin an. Ein Beispiel wäre super.

Vielen Dank und viele Grüße, Andreas

Ich schiebe das Thema mal wieder nach oben. Können @robert.sehr oder @oliver.paetzel dazu etwas sagen? Das müßte ja eigentlich alle Goobi-Instanzen betreffen?

@michael_zlb_berlin @Schlueter_HAAB

In der Goobi viewer Dokumentation haben wir einen dokumentierten Anwendungsfall für Subthemes, siehe hier:

Dort ist aufgelistet, wie im Regelsatz dafür ein Metadatum definiert wird inklusive eines eigenen Namespaces sowie der Export nach mods:extension. Weiter unten wird auch die Konfiguration für den Goobi viewer Indexer gezeigt.

Viele Grüße,

Jan :slight_smile:

1 „Gefällt mir“

Vielen Dank für den Hinweis. Wäre es sinnvoll, die Datumsangabe standardmäßig so umzusetzen, wie es das MODS-Anwendungsprofil erfordert? Das scheint bei Goobi ja momentan nicht der Fall zu sein? Oder schafft die Umsetzung, so wie die DDB sie verlangt, wieder an anderer (Euch bekannter) Stelle Probleme?

Hallo Andreas,

das kann im Regelsatz ganz leicht forciert werden. Du kannst z.B. einen regulären Ausdruck setzten, der prüft, dass dort nur 4-stellige Zahlenwerte erlaubt sind.

Das Problem an der ganzen Sache ist aber, dass sich hier die Anforderungen des DFG-Viewer MODS Profils und der Bibliothekskataloge widersprechen. In MODS wird 1950 verlangt, je nach Katalogstyp kommen in den importierten Daten aber auch ca 1950, [1950], 19XX, 19??, um 1950 oder 20. Jh. vor. Dies sind für den Katalog valide Angaben, für das MODS Profil jedoch nicht.

Man kann konfigurieren, dass bei solchen Angaben nur die Zahl extrahiert und konfiguriert wird. Dann wären die Daten aus ca, um oder [ ] richtig importiert, aber bei XX, ?? oder 20. Jh. kommt auch so eine Lösung an ihre Grenzen.

Viele Grüße
Robert

Hallo Robert,

könnte man dafür nicht die Sortierform der Datumsangabe verwenden? Die wird ja ohnehin erfasst und ist schon normalisiert?

Viele Grüße, Andreas

Wo das möglich ist, machen wir das auch. Bei euch gibt es z.B. zwei verschiedene Metadaten für das Erscheinungsjahr:

  <Metadata>
    <Name>PublicationYearSort</Name>
    <picaMainTag>011@</picaMainTag>
    <picaSubTag>a</picaSubTag>
  </Metadata>
  <Metadata>
    <Name>PublicationYear</Name>
    <picaMainTag>011@</picaMainTag>
    <picaSubTag>n</picaSubTag>
  </Metadata>

Mal ein ganz konkretes Beispiel. Hier würde die DDB einen Fehler auswerfen, weil die Angabe in der ersten Zeile nicht korrekt ist. Und da immer nur die erste Zeile ausgelesen wird, führt das dazu, dass das Datum nicht von der DDB übernommen wird.

grafik

Ein weiteres Beispiel mit dem gleichen Ergebnis.

grafik

Ein Tausch der Positionen würde wie von @michael_zlb_berlin weiter oben vorgeschlagen, zwar das Problem für die DDB lösen, wäre aber immer noch nicht MODS-konform.

Robert schlägt das hier vor:

Damit wäre a) der DDB gedient , und es wäre b) MODS-konform

Vorraussetzung ist, dass in der jeweiligen Goobi-Instanz dieser Wert vorliegen muss, der ja auch für die Sortierfunktion im Goobi viewer herangezogen wird:
grafik

Habe ich bei meiner Zusammenfassung etwas vergessen?