Betatest - Fehler und Vorschläge

Auf dieser Seite sind alle Fehler, Vorschläge und Probleme mit der Beta des SUB Regelsatzes für Drucke dokumentiert - gegliedert durch Überschriften.

Bereits abgeschlossene Probleme werden auf die folgende Seite verschoben:

• SUB Regelsatz für Drucke - BETA (abgeschlossene Punkte)

Kurz vor Ende der BETA muss die Dokumentation überprüft werden:

• Entsprechen alle Bezeichnungen in der Dokumentation denen im Regelsatz?
• Ist das Mapping vollständig
  • TODOs prüfen
• Sind alle Strukturtypen dokumentiert
  • Wie PeriodicalVolume dokumentieren?
  • Reihenfolge dem Regelsatz anpassen?

Updates

• 24.02.2017
  • Reihenfolge der Metadaten für alle Strukturtypen angepasst (Liste von Cordula und Karsten)
  • PeriodicalVolume nicht extra dokumentiert, die Unterschiede sind marginal
  • Bezeichungen von Mapping, oberer Strukturelemente und Regelsatz im Rahmen der Soriterung abgeglichen, noch einmal abschließend durchgehen
• 1.3.2017
  • Untergeordnete Strukturelemente Doku und Regelsatz abgeglichen (Erlaubte Unterelemente, Metadaten, Häufigkeiten)
  • Label für Personen / Körperschaften („Beziehungskennzeichen“) verglichen
  • Mapping der Beziehungskennzeichen geprüft (bei mehreren meist nur Anzahl)
  • Texte in der Dokumentation überarbeitet und ergänzt

Timo gibt die METS-Dateien der Testvorgänge an Steffi und Stephan zur Prüfung - für Feedback von unabhängigen Profis.

Korrigiert man den ATS / TSL von Hand, z.B. weil er von Goobi nicht richtig gebildet wurde, wird er durch erneutes Generieren wieder in die falsche Form gebracht. Generiert man nicht erneut, wird zwar der Vorgangstitel korrekt gebildet, in den Metadaten erscheint jedoch der falsche alte Vorgangstitel.

Updates:

• Der ATS/TSL wird nicht mehr von Goobi generiert, sondern aus den GVK übernommen
  • Das ist aufgrund der Umstellung der Titelfelder nötig geworden
  • „Wir“ haben die Generierung in der Hand und nicht „geheime“ Goobi Scripte
• Die Übernahme aus dem GVK führt zu dem beschriebenen Verhalten
  • Beim „Generieren“ werden die Daten neue aus dem GVK importiert, dabei werden alle Felder, die aus dem GVK gefüllt werden wieder überschrieben
    • das ATS/TSL Feld ja, der Vogangstitel wird nicht (direkt) übernommen, daher bleibt er erhalten
  • Beim Anlegen des Vorgangs werden erneut alle Daten aus dem GVK imporiter, daher wird as Feld ATS / TSL überschrieben
  • Karsten: Aktuell wird immer, wenn irgendeine Person in einem Feld 30XX vorkommt, ein ATS gebildet. Auch dann, wenn es sich dabei nur um den Verleger, Drucker oder eine sonstige Person handelt. Das ist nicht dramatisch, ist aber kein „ATS“ mehr. Vorschlag: ATS wird gebildet, wenn 3000 gefüllt ist, ansonsten TSL
    • 3.2.2017: Das ist technisch leider nicht möglich
• Karsten
  • Bei Nachnamen, die kürzer als vier Zeichen sind, müsste der erste Teil des ATS auf 4 Zeichen ergänzt werden. Zur Ergänzung sollten Unterstriche genommen werden. Beispiel: 028A $aPyl → ATS: „Pyl_“ + 2. ATS Teil vom Titel
  • Bei der ATS-Bildung wird derzeit ein Umlaut durch ZWEI „x“e ersetzt, Beispiel: 028A $aKühl wird im ATS zu „kxxh“, korrekt wäre aber „kxhl“
• 17.2.2017
  • Die Übersetzung von Umlauten in zwei Zeichen hängt mit dem für MM21 verwendetn Perl Modul zusammen, eine Korrektur ist nicht möglihc
• ⇒ Der ATS und TSL wird sich von den bisherigen unterscheiden, was z. b. bei Zeitschriften dazu führen kann, dass Bände unterschiedliche Vorgangs-IDs haben

Bei der Datenübernahme von Zeitschriften fehlen viele Informationen, da sie nach RDA nicht mehr in der O-Aufnahme enthalten und und zwischen den O-Aufnahmen von Zeitschriften und der A-Aufnahme gibt es keinen direkten Link, sondern nur einen indirekten über die ZDB-ID. Beispiel: PPN 866749241

• http://unapi.gbv.de/?format=picaxml&id=gvk:ppn:866749241
• http://www.eromm.org/cgi-bin/pica2marc.pl?version=1.1&operation=searchRetrieve&query=866749241&maximumRecords=5&recordSchema=marcxml

<datafield tag="039I">
  <subfield code="c">Elektronische Reproduktion von</subfield>
  <subfield code="t">Dämonion oder das Reich des Lasters und der Thorheit</subfield>
  <subfield code="f">1799-1799</subfield>
  <subfield code="C">ZDB</subfield>
  <subfield code="6">1273620-x</subfield>
  <subfield code="C">DNB</subfield>
  <subfield code="6">017851246</subfield>
</datafield>

Dann Abfrage über SRU?

• http://sru.gbv.de/gvk?version=1.1&operation=searchRetrieve&query=1273620-x&maximumRecords=5&recordSchema=picaxml

Problemfälle

• 515979694
  • RAK Aufnahmen, Verknüpfung in 039D
  • wiederholte 009P, beim Vorgang wurden die Angaben der BSB übernommen
• 731824857
  • RAK Aufnahmen, Verknüpfung in 039D
• 734013132
  • RAK, keine DNB-ID in 039D, nur ZDB-ID
• 623662582
  • Als Physische Beschreibung wird „Online Resource“ übernommen
    • ⇒ nicht als RDA Satz ausgezeichnet
  • Fehlerhafte Beschreibung des Digitalisats
    • Es werden auch Informationen zu einem Digitalisat aus München und einer Mikroform aus Weimar übernommen
    • das Digitalisierungsdatum fehlt

Updates

• 1.3.2017
  • MM21 angepasst
• 2.3.2017
  • Problemfälle ergänzt
    • ob RAK Aufnahmen relevant sind ist noch unklar
  • Nachfrage bei Jakob: unApi geht nur mit PPN, andere „Indices“ sind nicht möglich
    • er empfiehlt in dem Fall SRU
• 10.3.2017
  • Probleme mit ZDB-O-Aufnahmen
    • Vermischung von unterschiedlichen Objekten
    • Sind die alten Ab-Aufnahmen der SUB noch da oder wurden sie ersetzt?
  • Wie soll mit den Problemen umgegangen werden?
    • Bei der Datenübernahmen per Hand immer nachbessern?
    • Beim Konvertieren der alten Vorgänge versuchen zu fixen (ist das überhaupt mit vertretbarem Aufwand möglich?) oder Zeitschrfiten nicht anfassen?
      • Filtern auf „Göttingen“ bzw. „SUB“??
• 15.3.2017 - Treffen
  • in MM21 werden die Angaben zum Digitalisat hardgecoded
    • außer das Erscheinungsjahr, dass soll aus den vorliegenden METS-Dateien (Goobi-intern) übernommen werden
      • Details klären Timo und Alex
  • Bei den Altdaten
    • Prüfen, wie viele Digitalisate nicht in Göttingen erzeugt wurden
      • Ist hardcoden sinnvoll oder macht es zu viel kaputt?
      • mit Rolf und Cordula klären
  • Karsten prüft nochmal die Datenübernahem ZDB ⇒ GVK
  • nächster Termin 23.3. 14:30 Uhr
• 23.3.2017 - Treffen
  • Ergebnisse
    • Projekte ZBW und MPDL* ignorieren
    • alle anderen Projekte haben als Artist das GDZ, daher können alle Werte außer das Digitalisierungsdatum pauschal gesetzt werden
      • Timo baut das irgendwie in die Konvesion ein, das komplette „originInfo digitization“, Datum dann aus Datenbank irgendwie
    • „Technische Angaben“ wurden erst im GVK nachgetragen, nicht in der ZDB

Zu prüfen:

• Alle Strukturdaten vorhanden?
• Alle Unterlemente verfügbar?
• Labels in Ordnung?
• Reihenfolge?
• Standardsichtbarkeit?
• Kardinalitäten / Häufigkeiten

Updates

• von Cordula gestestet
• Echte Tests mit Digiwunschbuch und Repro

Die „Ortsfacette“ im neuen GDZ Portal verdeutlicht die Probleme mit den zahlreichen unterschiedlichen Bezeichnungen für Erscheinungsorte. An der Verwendung von GND-URIs wird gearbeitet, die Umsetzung ist aber noch weit entfernt und kann daher für den neuen Regelsatz zurzeit nicht mehr abgewartet werden.

Seit 2010/11 wird im GBV zusätzlich zur Vorlageform (4030 / 033A $p) eine normierte Ortsbezeichnung (4033 / 033B/03 $p, nicht in der Katalogisierungsrichtlinie dokumentiert) erfasst. Beispiel:

• PPN 142265845

Die Regeln für 4033 sind:

• Es wird immer von allen Erscheinungsorten eine normierte Form erfasst, auch wenn sie identisch mit der Vorlageform ist
• Bei einer fingierten Ortsangabe in der Vorlage wird folgendermaßen erfasst:
  • ist der Erscheinungsort nicht bekannt, wird „fingiert“ als normierter Erscheinungsort eingetragen
  • ist der Erscheinungsort bekannt, wird dessen normierte Form eingetragen

MODS kann unterschiedliche Namensformen von Orten abbilden:

<mods:originInfo>
   <mods:place>
      <mods:placeTerm type="text">Frankfurt</mods:placeTerm>
      <mods:placeTerm type="text" authority="GBV">Frankfurt, Main</mods:placeTerm>
   </mods:place>
   <mods:place>
      <mods:placeTerm type="text">Leipzig</mods:placeTerm>
      <mods:placeTerm type="text" authority="GBV">Leipzig</mods:placeTerm>
   </mods:place>
</mods:originInfo>

Diese optimale Lösung ist leider nicht realisierbar weil zum einen der Bezug von Vorlage- und normierter Form in Pica3 nicht mit erfasst wird und zum anderen diese Struktur in Goobi nicht modellierbar ist.

Es gibt verschiedenen Lösungsideen:

• sowohl Vorlageform und normierte Form als „Ort“ übernehmen
  • d.h. jeder Form kommt in ein eigenes mods:place/mods:placeTerm
    • die normierte Form könnte wie im Beispiel oben ausgezeichnet werden
  • diese Abbildung in MODS wäre falsch, weil dadurch aus zwei Orten vier werden
• bei der Datenübernhamen nur die normierte Form übernehmen
  • die Vorlageform geht verloren
  • bei fingierten Orten gibt es keine Ortsbezeichnung, bzw. eine von der Vorlageform abweichenden Ort
• Die Vorlageform wie gewohnt übernehmen und die normierte Form in ein neues Feld übernehmen, das in mods:extension/… gemappt wird

Alle Lösungen ermöglichen die Verwendung der normierten Form für die Suche und die Facettierung. Technisch kann das neue GDZ die Elemente verarbeiten („Wenn keine normierte Form vorhanden ist, nimm die Vorlageform“).

Updates:

• 10.3.2017
  • Die „extension“-Lösung wird favorisiert (bzw. als das kleinste Übel angesehen).
  • Vorschlag zur Umsetzung:

<mods:extension>
  <mods:mods>
    <mods:originInfo>
      <mods:place>
        <mods:placeTerm type="text" authority="GBV">Frankfurt, Main</mods:placeTerm>
      </mods:place>
      <mods:place>
        <mods:placeTerm type="text" authority="GBV">Leipzig</mods:placeTerm>
      </mods:place>
    </mods:originInfo>
  </mods:mods>
</mods:extension>

• 10.3.2017
  • in die gleiche mods:extension wie die Digitalen Kollektionen und Stichwörter
  • MODS Struktur verwenden für ein Mindestmaß an Interoperabilität
    • Wert für @authority noch abschließend zu klären
• 16.3.2017
  • Feld im Regelsatz angelegt
  • Mapping dokumentiert (MM21 Feld fehlt noch)
  • Feld dokumentiert, eingeordnet nach dem Erscheinungsort (Vorlageform)
  • Die normierten Ortsnamen stammen aus Druckorte des 16. bis 19. Jahrhunderts : Ansetzungs- und Verweisungsformen / erarb. von der Bayerischen Staatsbibliothek. – Wiesbaden : Reichert, 1991. ISBN 3-88226-519-1
    • Vorschläge für die @authority, ggf. @authorityURI
      • BSB
      • 3-88226-519-1
• 24.3.2017
  • so implementiert
  • in MODS: @authority=„GBV“
  • In MM21: Ausgabe in 269$a
• 30.3.2017
  • Im Regelsatz umgesetzt
  • leider erlaubt das MODS Schema im @authority nur marcgac, marccountry und iso3166.
    • einfach ohne?
• 12.4.2017
  • keine authority verwendet, ist ja eh in der extenstion, also:

<mods:extension>
  <mods:mods>
    <mods:originInfo>
      <mods:place>
        <mods:placeTerm type="text">Frankfurt, Main</mods:placeTerm>
      </mods:place>
      <mods:place>
        <mods:placeTerm type="text">Leipzig</mods:placeTerm>
      </mods:place>
    </mods:originInfo>
  </mods:mods>
</mods:extension>

Die Konversion von Pica+ zu MM21 und MODS muss anhand von Testendatensätzen, die alle unterstützen Felder enthalten, geprüft werden.

Die Testdatensätze umfassen die drei relevanten bibliothekarischen Erscheinungsweisen und sind jeweils nach RDA und RAK (Altdaten, Umstellung der vorhandenen Vorgängen) katalogisiert.

• Monographie
  • RDA
    • Oav = 871633507
    • Aau = 857311204
  • RAK
    • Oav = 884600157
    • Aau = 884599205
• Band einer mehrteiligen Monographie / eines mehrbändigen Werkes
  • RDA
    • Ofv = 881951706
    • Ocv = 881951447
    • Afv = 881950890
    • Acv = 881936200
  • RAK
    • OFu: 881967319
    • AFu: 881966533
    • Ocu: 881967211
    • Acu: 881961469
• Zeitschrift
  • RDA
    • Obu = 88193884X
    • Abu = 881843229
  • RAK
    • Obu: 88195411X
    • Abu: 881953962
• Nicht zitierfähiger Bandttitel (RDA)
  • Ofv: 871344289
  • Afv: 804397112

Updates

• 14.3.2017
  • Testdatensätze im GVK von Cordula und Karsten erstellt und ergänzt.

Beim Treffen am 23.3.2017 haben Cordula und Karsten über die Fehler während des BETA-Tests berichtet.

• Probleme mit Zeitschriften
  • Beispiele für alle Punkte:
    • RDA
      • 88193884X (MM21)
      • 88193884X (Pica+)
    • RAK
      • 88195411X (MM21)
      • 88195411X (Pica+)
  • Zeitschriften Paralleltitel (und Zusatz) wird nicht übernommen, da abweichendes Feld bei ZDB Aufnahmen
    • RDA: 4000$f
      • Pica+: 021A$f (Zusatz dann nach „ : “)
      • in 249$ $a $b $z - nicht 940?
    • RAK: 4000 nach „ = “
      • Pica+: 021A$d nach „ = “ (Zusatz dann nach „ : “)
      • in 249$ $a $b $z - nicht 940?
  • nur RDA: ISSN wird doppelt übernommen
    • wird doppelt im MM21 ausgegeben
  • überwiegend RAK: Körperschaften werden immer als Mitwirkender übernommen
    • Zuordnung erfolgt im MM21
    • Unterscheidung kann nur abhängig von der Kategorie erfolgen
      • Vorschlag von Karsten:
        • 310X (029A) „Primärkörperschaft“: cre
          • Da die genaue Funktion nicht erkennbar ist, am besten allgemein: GeistigeR SchöpferIn
        • 312X (029F) „Sekundärköperschaft“: oth
          • Sonstige Körperschaft
        • 314X (029E) „Körperschaft als Interpret“: ctb
          • Heute ist das ein „AusführendeR“, wir mappen das aber auf das übergeordnete: MitwirkendeR
        • 315X (029K) „Sonstige Körperschaften“: oth
        • 317X (029H) „Konkurrenz-Primärkörperschaft (MBW)“: cre
          • Auch dieses Feld gibt es weiterhin (nur in f-Sätzen)
          • auch RDA ich glaube ehrlichgesagt nicht dass die Codes so richtig sind, bspw. ist eine Primärks. in RAK aufnahmen nicht notwendigerweise der geistige Schöpfer („… veranlasst und herausgegeben“), andererseits kann die Rolle der Sekundärks. genau die gleiche sein wie bei der Primärks. (RAK und RDA), habe das jetzt aber so wie gewünscht implementiert
• Werktitel wird bei der Verknüpfung mit Normdatensätzen nicht übernommen (3210)
  • Der Werktitel befindet sich dann nicht in $a sondern in $Y
  • Beispiele:
    • 873190696 (mit Normdatenverknüpfung)
    • 88193884X (ohne Normdatenverknüpfung)

• * 2275$A + $p (007P$A + $p)
  • Allgemeine Bemerkung ⇒ Angaben zum Fingerprint werden nicht vollständig übernommen
    • nicht im MM21 enthalten, laut Datenmapping 500$a
    • Beispiel:
      • 871633507
      • Fingerprint ist in dessen A-Satz 857311204
      • ⇒ 871633507 (MM21)
  • Nach Diskussion beim Treffen 23.3.: Übernahme aus MM21 entfernen (bzw. nicht korrigeren), da nicht relevant ohne den Zusammenhang zum Fingerprint Bitte ein Beispiel was nicht vollständig ausgegeben wird. Das ist die Fn. „Fingerprint nach dem Exemplar …“ die steht auch in PICA separat vom Fingerprint
  • Karsten: Hier geht es nicht um die allgemeine Anmerkung (4201/037A$a) sondern um die ergänzenden Anmerkungen zum Fingerprint, die in 2275 (007P) in den Unterfeldern $A und $p stehen. Diese sind nur sinnvoll, wenn sie dem genannten Fingerprint unmittelbar zuzuordnen sind, wenn sie aber in mods im allgemeine „note“-Feld landen, sind sie nutzlos, daher bitte weglassen
• 30.3.2017 - Treffen
  • Fingerprint bleibt granular als Identifier
  • für die Ausgabe von 2275 (007P) $A und $p w in MM21 500$a wird der Fingerprint ncoh einmal dupliziert um den Zusammenhang zu erhalten

• Dokumentation, Datenmapping
  • 3060 fehlt
    • Im Datenmapping ergänzt
  • 1110
    • Link korrigiert
  • 4020 Link im Datenmapping defekt und Wiederholbarkeit falsch (nur 0-1), auch in Strukturen prüfen
    • Wiederholbarkeit in der Doku (Datenmappping, übergeordnete Strukturelemente) und Regelsatz korrigiert
  • 4221 Link im Datenmapping falsch
    • korrigiert
  • 2290 ist obsolet und durch 2198 abgelöst, prüfen wie wir damit umgehen
  • „Oj“ wird als Monographie erkannt, das könnte zu Fehlern führen
    • Beispiel: 882702475
    • Alex hat den MARC Leader angepasst, Goobi wirft jetzt bei der Datenübernahme von Oj Sätzen eine schöne Exception.
• Datenmapping: Körperschaften (s.o.) ergänzt
• Zeitschriften nur RDA: 4212 (046C) / 4213 (046D)
  • Unterfeld $b wird nicht richtig übernommen sondern als String angehängt
  • Das wird bereits in Pica+ so ausgegeben
    • http://unapi.gbv.de/?format=picaxml&id=gvk:ppn:88193884X
  • Katalogisierungsfehler, ist korrigiert
• Zeitschriften: Unterreihen werden nicht übernommen
  • RDA und RAK: 4005
    • Pica+: 021C
  • 1. Idee: An den Zeitschriftentitel hängen mit „ / “, Wiederholbarkeit beachten
    • Entscheidung am Treffen 30.3.
• 30.3.2017 Treffen
  • Die Unterreihe wird an den Titel angehängt mit „. “.
    • z.B.: „Zeitschrift der Akademie der Wissenschaften. Mathematisch-naturwissenschaftliche Veröffentlichungen“
• 31.3.2017
  • Unterreihen werden in 245$b ausgegeben

• Zeitschriften nach RAK
  • Beilagen fehlen, 4241, 4242 (mit Link)
    • bisher nicht im Mapping vorgesehen
    • bisher nicht übernommen, daher auch in Zukunft nicht
  • Paralelle Ausgabe fehlt
    • bisher nicht übernommen, daher auch in Zukunft nicht
  • Vorgänger, Nachfolger b
    • bisher nicht übernommen, daher auch in Zukunft nicht

Für weitere Tests (vor allem auch Strukturdaten) ist angedacht, produktiv verwendete Vorlagen auf den neuen Regelsatz umzustellen. Vorschlag:

• Digiwunschbuch
  • DigiWunschbuch
• Reproaufträge
  • Reproauftraege_Movingwall
  • Reproauftraege_nicht_Online
  • Reproauftraege_Online
• DVD-Archiv (Vorschlag von Rolf)
  • DVD-Archiv_Gesperrt
  • DVD-Archiv_Movingwall
  • DVD-Archiv_Online

In den Projekten DigiWunschbuch und Reproaufträge wird gearbeitet, aber die Anzahl neuer Vorgänge ist überschaubar. Mit Anja kommt noch einmal ein Blick von „außen“ dazu, dabei kann auch die Dokumentation geprüft werden. Bei Digiwunschbuch ist noch zu prüfen, ob die Felder für den „Paten“ irgendwie berücksichtigt werden müssen.

Der Test beginnt frühestens Mitte April.

Updates

• 24.3.2017
  • die Felder für den „Paten“ hängen nur am Vorgang und haben keinen Einfluss auf den Regelsatz
• 27.4.2017
  • Rolf schlägt zusätzlich das Projekt „DVD-Archiv“ vor
  • viele Vorgänge werden hier zwar automatisch erzeugt, aber Werke von denen es keine bzw. keine „richtige“ O-Aufnahme gibt, müssen von Hand angelegt werden
  • Er wird Cordula eine Liste geben
• 28.4.2017
  • Die Umstellung der o. g. Produktionsvorlagen ist für den 5. Mai geplant

Der EROMM Server soll demnächst komplett auf HTTPS umgestellt werden. Leider arbeitet Goobi nicht mit unserer „SRU-Schnittstelle“ über https zusammen sondern wirft eine Exception bei der Datenübernahme.

Updates

• 24.3.2017
  • Robert
    • Https funktioniert prinzipiell, aber der Java Trust Store vertraut den letsencrpyt Zertifikaten noch nicht
    • in neueren Java Versionen ist das Root-Zertifikat schon hinterlegt
    • es kann auch in der alten Version nachgepflegt werden
    • Intranda testet
  • Alternativ könnten wir die Scripte wahrscheinlich auch über die CERL Domäne laufen lassen

Karsten: am besten immer aus dem A-Satz übernehmen, O-Satz ist unsicher

• DNB-Nummer fehlt im MM21 (908$a)
  • Beispiel
    • 871633507(Pica+)
    • 871633507(MM21)
    • 006G$0 A-Satz
• Fehlende Felder im MM21 anhand Beispiel PPN 881951706 (Pica+, Pica+ A-Satz, MM21)
  • Bibliografische Zitate (007S$0 (A-Satz) ⇒ 510$9)
  • EAN (007L$0 (A-Satz) ⇒ 903$a)
  • Amtliche Druckschriftennummer (007B$0 (A-Satz) ⇒ 913$a)
  • CODEN (007C$0 (A-Satz) ⇒ 914$a)
  • Verlags-, Produktions- u. Bestellnummer (007D$0 (A-Satz) ⇒ 915$a)
  • Hochschulschriften-Nummer (007E$0 (A-Satz) ⇒ 916$a)
  • Reportnummer (007F$0 (A-Satz) ⇒ 917$a)
  • Normnummer (007H$0 (A-Satz) ⇒ 918$a)
  • Kontraktnummer (007Z$0 (A-Satz) ⇒ 919$a)
  • PPN gelöschte Aufnahme (003D$0 (A-Satz) ⇒ 901$a)
  • Beziehungen auf Manifestationsebene (039D diverse Unterfelder (A-Satz) ⇒ 530$a)
  • Ursprüngliches Erscheinungsjahr (011@$r (A-Satz) ⇒ 260$O)
• Beispiel Zeitschrift RDA anhand PPN 88193884X (Pica+, Pica+ A-Satz, MM21)
  • die 264 enthält die gleichen Orte und Verlag wie die 260 (A-Satz und O-Satz)
    • könnte am Testndatensatz liegen noch zu prüfen
    • abweichend vom MODS werden hier in der 264 alle Orte übernommen
    • hier nochmal grundsätzlich überlegen, wie Angaben zum Digitalisat bei Zeitschriften-Anchor-Dateien behandelt werden sollen
  • ZDB-Nummer vom O-Satz (006Z$0) wird in MM21 ausgegeben 912$a - sollte auch die ZDB-Nummer des A-Satzes übernommen werden?
    • Steffis Vorschlag (abgeleitet vom Zeitungs-AP):
      • O-ZDB wie gehabt in mods:identifier[@type='zdb'] und A-ZDB in mods:relatedItem[@type=„original“]/mods:identifier[@type=„zdb“]
        • ⇒ dafür wäre eine Unterscheidung in MM21 nötig und ein neues Feld in Goobi
      • Alternativen?
• Beispiel Mono RAK anhand PPN 884600157 (Pica+, Pica+ A-Satz, MM21)
  • Dokumenttyp (DIN 31631-4) fehlt in 655$a aus 013@$0
    • Werte werden übersetzt? (s. MODS)
  • Abweichende Titel und spätere Haupttitel (4212 | 046C$a + $b) soll laut Datenmapping in die Allgemeine Bemerkung (500$a), wird aber als Abweichender Titel ausgegeben (hier 934)
    • Nochmal prüfen, was gewollt ist
  • Weiterer Identifier aus 007G (2240, Identnummer der erstkatalogisierenden Institution) fehlt in 920$a
• Beispiel Zeitschrift RAK anhand PPN 88195411X (Pica+, Pica+ A-Satz, MM21)
  • OCLC-Identifikationsnummer fehlt (A-Satz 003O$a) in 902$a
  • Swets-Nummer fehlt (A-Satz 006N$0) in 911$a
  • ZDB-Nummer fehlt (A-Satz 006Z$0) in 912$a
  • ISSN fehlt (A-Satz 005A$0) in 924$a

Updates

• x

Momentan sind im Regelsatz zwei Felder für Informationen zum Fingerprint vorgesehen:

• granular in mods:identifier[@type='fingerprint']
• dupliziert mit weiteren Informationen (Exemplar usw.) in mods:note Fingerprint

Für die granulare Speicherung im mods:identifer ist daher momentan keine Unterscheidung zwischen den Methoden („fei“ und „stcnf“) möglich. Wäre eine Unterscheidung (realisierbar über ein weiteren @type) sinnvoll?

Updates:

• x