Auf dieser Seite sind alle Fehler, Vorschläge und Probleme mit der Beta des SUB Regelsatzes für Drucke dokumentiert, die bereits erledigt sind. Die Sortierung ist willkührlich.

Momentan ist es noch nicht möglich, Vorgänge mit Mehrbändigen Werken und Zeitschriften anzulegen:

• Publikationstyp wird nicht erkannt
  • Mehrbändige Werke werden trotdzem korrekt angelegt
• das manuelle Umstellen des Publikationstyps auf Mehrbändiges Werk nachdem Daten übernommen worden führt zu eine Goobi Fehlermeldung
• Das Anlegen mit Zeitschriftenbänden führt zu einer Goobi Fehlermeldung

Updates:

• Erkennung von Zeitschriften funktioniert, Speicher noch nicht
• Mehrbändige Werke werden jetzt korrekt erkannt, Zeitschriften noch offen
• Robert hat das Problem mit den Zeitschriften gefunden
  • Goobi benötigt für Zeitschriftenbände das Strukturelement „PeriodicalVolume“, wobei im Regelsatz (wie auch im DFG-Viewer) kein Unterschied bei den Bänden gemacht wird
  • mögliche Lösungen
    • Für Bände zwei Strukturelemente anlegen (PeriodicalVolumen noch ergänzen)
    • in der nächsten Goobi Version kann dieses Verhalten konfiguriert werden und „Volume“ für beide Bandarten verwendet werden
      • evtl. kann Intranda unsere Version um diese Funktionalität erweitern (Die neue Goobi Version kommt erst im 1. Quartal 2017)
  • Vorgehen ist zu diskutieren
• Diskussionsergebnis (Details s. nächster Punkt)
  • „Volume“ für MBW und Zeitschriften verwenden

Enthält ein Titel keinen nichtsortierende Zeichen, wird für das Feld „Titel (nicht sortierende Zeichen)“ der komplette Titel übernommen, was der Konfiguration wiederspricht. Das Feld sollte dann nicht angelegt werden.

Updates:

• Goobi baut sich intern ein Unterfeld „x“ um hier den Titel ohne Nichtsortierzeichen (gemäß Indikator 2). Das Feld ist in MARC eigentlich nicht belegt und deswegen haben wir es in MM21 verwendet und dadurch kamen die „merkwürdigen“ Titel her
• in MM21 wird der nichtsortierende Teil des Titels nun in $q ausgegeben (gilt für alle Titelformen)
• Es kommen nun keine Titel mehr im MODS an, sondern jetzt nur noch die nichtsortierenden Bestandteile und der Titelzusatz, s.schugewe_PPN873261321_0005_Test_KO
  • Fehler im Regelsatz, korrigiert

Präfixe aus dem Unterfeld $c werden an den Vornamen angehängt Beispiel: beustrac_PPN798761202_test_CF

Updates:

• Über den Regelsatz ist da leider nichts zu machen, aber vielleicht können wir in MM21 etwas drehen.
• Präfix wird momentan im MM21 an den Vornamen gehängt, Leerzeichen hat gefehlt, das ist korrigiert
• Diskussion Dienstag
  • Ist das Präfix nach dem Vornamen an der richtigen Stelle? Ein eigenes Feld gibt es in Goobi und MODS nicht.
• Präfix wird an den Vornamen gehängt, das fehlende Leerzeichen ist ergänzt (Fehler im MM21)

Beispiel knopdiss_PPN872778428_test_KO

Die Angabe zur Digitalen sammlung „VD18 digital“ landet in MODS im Element

<mods:titleInfo type="uniform">
 <mods:title>
 ...
  <mods:title>VD18 digital</mods:title> 
  </mods:title>
</mods:titleInfo>

gehört aber wohl eher nach

<mods:relatedItem type="series" />

Es fehlt hier auch das Elementende </mods: relatedItem>

Updates:

• Fehler in Goobi, da muss Intranda ran
  • Timo hat zwar einen Workaround gefunden, darauf möchte er sich aber nicht verlassen.
• Robert hatte Lösung
  • # im Mapping der Gruppenelemente

Personen, die als Drucker (Beziehungskennzeichen prt) gekennzeichnet sind, kommen korrekt nach Goobi, aber beim MODS-Export tauchen diese Personen dann 3x auf: 1x korrekt als Drucker:

<mods:name authority="gnd" authorityURI="http://d-nb.info/gnd/" type="personal" valueURI="http://d-nb.info/gnd/137434464">
  <mods:role>
    <mods:roleTerm authority="marcrelator" type="code" valueURI="http://id.loc.gov/vocabulary/relators/prt">prt</mods:roleTerm>
  </mods:role>
  <mods:namePart type="family">Pockwitz</mods:namePart>
  <mods:namePart type="given">Hieronymus Michael</mods:namePart>
  <mods:displayForm>Pockwitz, Hieronymus Michael</mods:displayForm></mods:name>

… und dann noch überflüssigerweise als Präses (pra) und Respondent (rsp):

<mods:name authority="gnd" authorityURI="http://d-nb.info/gnd/" type="personal" valueURI="http://d-nb.info/gnd/137434464">
  <mods:role>
    <mods:roleTerm authority="marcrelator" type="code" valueURI="http://id.loc.gov/vocabulary/relators/pra">pra</mods:roleTerm>
  </mods:role>
  <mods:namePart type="family">Pockwitz</mods:namePart>
  <mods:namePart type="given">Hieronymus Michael</mods:namePart>
  <mods:displayForm>Pockwitz, Hieronymus Michael</mods:displayForm>
</mods:name>
...
<mods:name authority="gnd" authorityURI="http://d-nb.info/gnd/" type="personal" valueURI="http://d-nb.info/gnd/137434464">
  <mods:role>
    <mods:roleTerm authority="marcrelator" type="code" valueURI="http://id.loc.gov/vocabulary/relators/rsp">rsp</mods:roleTerm>
  </mods:role>
  <mods:namePart type="family">Pockwitz</mods:namePart>
  <mods:namePart type="given">Hieronymus Michael</mods:namePart>
  <mods:displayForm>Pockwitz, Hieronymus Michael</mods:displayForm>
</mods:name>

Updates:

• Das war ein Fehler in der Regelsatzkonfiguration

Die Übernahme von Werktiteln (Feld 3210 / 022A) müsste noch der von Titeln angepasst werden (Nichtsortierzeichen). Derzeit wird der Titel „Das gewerbfleißige Deutschland“ folgendermaßen importiert: Titel (nicht sortierende Zeichen) „Das“ = korrekt; Titel (ohne nicht sortierende Zeichen) ist leer = falsch; Titel = Das gewerbfleißige Deutschland„ = korrekt. Es existiert in dieser Metadatengruppe noch ein weiteres Feld „Titel“, das den Inhalt enthält, der eigentlich in das Feld Titel (ohne nicht sortierende Zeichen) gehört. Beispiel: schugewe_PPN873252691_0001_Test_KO

Updates:

• Das war ein Fehler in der Regelsatzkonfigration, korrigiert
• Der Fehler betraf auch alle anderen Titel-Metadatengruppen
• Reihenfolge der Felder getauscht

Als Sacherschließung werden nur die Gattungsbegriffe übernommen. Die Kategorien 530X tauchen nicht auf. Bsp.: mollin_PPN683358480_Test_CF

Updates:

• Die automatische Übernahme ist momentan nicht vorgesehen, da die korrekte Speicherung in Goobi nicht möglich ist (Stichwort „Schlagwortketten“)

Die Rolle der Personen wird nicht immer korrekt übernommen. Bsp.: drecevol_PPN858811294_test_CF. Magdalene Elisabeth von Voß hat die Rolle sonstige Person ist aber in der Titelaufnahme Gefeierte.

Updates:

• Fehler in der Regelsatzkonfiguration, korrigiert

Die Felder 4060 bis 4063 werden in MODS zusammengefaßt. Vielleicht sollte man das Goobi-Feld von Umfang in Physikalische Beschreibung umbenennen.

Updates:

• Änderung kein Problem
• Entscheidung Dienstag
  • Umbennennen in „Physische Form“
  • ⇒ umgesetzt

Soll der normierte Erscheinungsort (4033) übernommen werden und wo kann er in MODS gespeichert werden?

Updates

• Steffis Aussage dazu: <zensiert>
  • ⇒ Übernehmen wir nicht

Bei den Metadaten wird unten noch ein weiteres Titelfeld angezeigt.

Updates:

• Das war ein Relikt vom Testen mit den Titel-Fehlern - entfernt.

Bei Fortlaufenden Ressourcen 4170 / 4180 wird die Verantwortlichkeitsangabe Unterfeld $c nicht übernommen.

Updates:

• technisch nicht möglich
  • 036E$h wird nicht exportiert, da eindeutige Zuordnung nicht möglich. Falls $h tatsächl. einmal verwendet wird muss man die Verantw.-Ang. manuell nachtragen

Nummer Sortierung sollte nicht übernommen werden. GVK Zählung weicht von Goobi Zählung ab. s. cajuvon_PPN861397428_Cont_1_Test_CF Übernommen wurde _12 1708 Goobi Zählung wäre 20.

Updates:

• Die Sortierzählung wird nicht mehr aus dem GVK übernommen

Die PPN die A-Satzes ist manchmal nicht im MM21 (922$a) enthalten. Z. B:

• http://www.eromm.org/cgi-bin/pica2marc.pl?version=1.1&recordSchema=marcxml&recordPacking=xml&operation=searchRetrieve&query=pica.ppn%3D657496510&maximumRecords=2

Ergänzung hierzu von Karsten: Wenn die PPN übernommen wird, fehlt „PPN“ am Anfang im Feld „PPN (A-Satz)“.

Updates:

• in MM21 gefixed, klappt jetzt für das Beispiel
• Präfix „PPN“ ist jetzt auch für den A-Satz gesetzt

Die PPN des O-Satzes wird noch einmal als weiterer Identifier aufgeführt. Ist das notwendig?

Updates:

• Die PPN des O-Satzes kommt im MM21 nochmal in der 920$a vor, die mehrere Identifier Felder zusammenfasst, u. a. die Identnummer der erstkatalogisierenden Institution (2240). Um eine erneute Übernahme zu verhindern müsste MM21 angepasst werden
• Technisch ist es nicht notwendig die Nummer doppelt mitzuführen, sie kann für die Ausgabe in MODS auch dupliziert werden
• Die Frage ist, wie sinnvoll ist die Übernahme dieses Feldes und wie häufig sind auch Nummern aus anderen Verbünden dabei?
• @Alex Braucen wir da nicht noch ein „Verbund-Präfix“? Bei O-Sätzen brauchen wird die EKI eigentlich nicht mit übernehmen — Alex Jahnke 2016/12/02 13:43

Die PPN wird in Goobi mit „PPN“ gepräfixed - sollte das beibehalten werden?

• Vorgangstitel: sicher ja, historisch bedingt
• recordIdentifier: fraglich?
  • historisch bedingt schon immer so gemacht
  • eigentlich nicht nötig
  • Konsequenzen, wenn wir es ändern?
• weitere PPNs in MODS: eigentlich macht das in MODS keinen Sinn, da über ein source Attribut die Herkunft angegeben werden kann - PPN an sich ist auch nicht eindeutig (andere Verbünde verwenden auch PPN)

Goobi gibt die PPNs zurzeit folgendermaßen aus:

<mods:recordInfo>
  <!-- O-Satz -->
  <mods:recordIdentifier source="gbv-ppn">PPN872693163</mods:recordIdentifier>
</mods:recordInfo>
<!-- A-Satz -->
<mods:identifier type="PPNanalog">PPN150039549</mods:identifier>

TCE erzeugt:

<mods:recordInfo>
  <!-- O-Satz -->
  <mods:recordIdentifier source="gbv-ppn">PPN718075641</mods:recordIdentifier>
  <!-- O-Satz -->
  <mods:recordIdentifier source="info:isil/DE-7">PPN718075641</mods:recordIdentifier>
</mods:recordInfo>
<!-- O-Satz -->
<mods:identifier type="GBVKat">718075641</mods:identifier>
<!-- O-Satz -->
<mods:identifier type="firstCataloguingId">GBV: 718075641</mods:identifier>

Updates:

• PPN mit Präfix bleibt wie gehabt in mods:recordInfo/mods:recordIdentifier
  • Dieses Element dient als Identifier und muss weiter so gefüllt werden
• die PPN wird zusätzlich als mods:identifier übernommen wie in Alex TCE
• firstCataloguingId nicht übernehmen

<mods:recordInfo>
  <!-- O-Satz -->
  <mods:recordIdentifier source="gbv-ppn">PPN718075641</mods:recordIdentifier>
</mods:recordInfo>
<!-- O-Satz -->
<mods:identifier type="GBVKat">718075641</mods:identifier>
<!-- A-Satz -->
<mods:identifier type="PPNanalog">PPN150039549</mods:identifier>

Wenn in Feld 4030 (Pica+: 003A) mehrere Erscheinungsorte getrennt durch „_;_“ stehen, gibt es mehrere Unterfelder $p. Aktuell wird nur eines der Unterfelder $p nach Goobi übernommen. Beispiel: schugewe_PPN873252691_0001_Test_KO

Vorschlag: Beide Felder, getrennt durch „_;_“ in das Goobi-Feld „Erscheinungsort“ übernehmen.

Updates:

• Der zweite Erscheinungsort kommt nicht im MM21 an
• Ist jetzt wie vorgeschlgen gefixt. Mir ist aber nicht klar, ob die Feldinhalte dann in verschiedene mods:place/mods::placeTerm exportiert werden können — Alex Jahnke 2016/11/29 14:15
• 1.12.2016
  • Da in Goobi keine gruppierte Übernahme möglich ist, soll der Erscheinungsort doch granular in wiederholte 260$a im MM21
• 22.12.2016
  • umgesetzt

Abteilungen von mehrbändigen Werken werde nicht aus PICA übernommen. Es handelt sich um die Felder 4151ff bzw. 036C/01ff. Sie sollten nach meinem Verständnis am besten bei <mods:relatedItem> landen

Beispiel: PPN 873261321 bzw schugewe_PPN873261321_0005_Test_KO

Die schöne Lösung, aber nicht AP-konform:

<mods:relatedItem type="host">
  <mods:titleInfo>
    <mods:title>Abteilungen (031C)</mods:title>
    <mods:subtitle>...</mods:subtitle>
    <mods:partNumber>031C/01 $l</mods:partNumber>
    <mods:partName>031C/01 $a</mods:partName>
    <mods:partNumber>031C/02 $l</mods:partNumber>
    <mods:partName>031C/02 $a</mods:partName>   
    ...
  </mods:titleInfo>
  <!-- automatisch von Goobi -->
  <mods:recordInfo>
    <mods:recordIdentifier>PPN123454678</mods:recordIdentifier>
  </mods:recordInfo>
</mods:relatedItem>

Wir nehmen diese Lösung nicht, da sie nicht DFG-Viewer AP konform ist und schreiben alles in den Titel.

• Bisher gibt Goobi im relatedItem host nur die PPN in einen recordInfo/recordIdentifier aus
  • Timo prüft, ob auch der Titel übernommen in das gleiche relatedItem übernommen werden kann
  • UPDATE Export des zusamengesetzten Titels in 895$a

Nach weiterer Diskussion mit Steffi und Alex:

• bei Bänden ohne zitierfähigen Titel wird mods:titleInfo/mods:title nicht belegt
  • das ist MODS AP konform
  • der Titel der mehrteiligen Monographie wird nicht mehr kopiert
• nicht zitierfähige Bandtitel in mods:part[@type=„volume“]/mods:detail/mods:title
  • mods:titleInfo/mods:title wird nicht belegt
• Abteilungen alle in einem Text vereint in mods:relatedItem[@type=„host“]/mods:titleInfo/mods:title

<mods:relatedItem type="host">
  <mods:titleInfo>
    <mods:title>Alle 036C</mods:title>
  </mods:titleInfo>
  <!-- automatisch von Goobi -->
  <mods:recordInfo>
    <mods:recordIdentifier>PPN123454678</mods:recordIdentifier>
  </mods:recordInfo>
</mods:relatedItem>
<mods:part type="volume" order="50">
  <mods:detail>
    <mods:number>
      Bandzählung (Vorlageform)
    </mods:number>
    <mods:title>
      Nicht zitierfähiger Bandtitel
    </mods:title>
  </mods:detail>
</mods:part>

Updates:

• Diskussion hinzugefügt
• Nachtrag hinzugefügt
• 22.12.2016
  • Export des Titels der f-Stufe in MM21 in Feld 891 (Syntax ist identisch mit 245)
  • Feld und Mapping (891$z) im Regelsatz konfiguriert

Wenn beim Band kein Titel vorhanden ist, wird der Titel aus der c-Stufe per Hand übernommen. Die Felder „Titel (nicht sortierende Zeichen) und Titel (ohne sortierende Zeichen) sind dann beim Band nicht besetzt.

Updates:

• Bei Bänden ohne Titel soll der Titel nicht mehr übenommen werden
• Alle Titelfelder sind für „Band“ auf optional gesetzt
• für nicht zitierfähige Titel wird es ein neues Feld geben
• 8.12.2016
  • Mapping nach MODS getestet - funktioniert.
  • Neues Feld angelegt „Nicht zitierfähiger Bandtitel“
  • MM21 Umsetzung steht noch aus
• 22.12.2016
  • erledigt, s. o.

Goobi kann wiederholte Sonstige Titelinformationen (oder andere gruppierte Daten) nicht in wiederholte Metadatengruppen übernehmen. Idee:

• Für jede Widerholung ein eigenes Feld in MM21 vewenden für n Wiederholungen

Updates:

• Abweichende Titel werden jetzt in den Feldern 930-939 (939 ggf. wiederholt) und Paralleltitel in den Feldern 940-949 (949 ggf. wiederholt) ausgegeben
• Regelsatz ist entprechend angepasst
  • Die Nummerierung wurde nicht in die Label übernommen, also heißen alle „Abweichender Titel“ und nicht „1. Abweichender Titel“ usw.

Bei der Eingabe von Personen bei der Struktur- und Metadatenbearbeitung ist das Feld „Normdaten gnd“ erst nach dem Abspeichern sichtbar.

Updates:

• Das ist leider von Goobi so vorgegeben und nicht konfigurierbar
• Timo hat bei Robert angefragt, ob man da das Feld ergänzen kann (evtl. in der nächsten Goobi Version?)
• 22.12.2016
  • Nochmal bei Robert angefragt
• 4.1.2017
  • Robert: Nicht möglich

Das Validieren liefert zwar korrekte Meldungen, führt aber auch zur einer Goobi Fehlermeldung

Updates:

• Das Problem tritt nicht mehr auf, der Vorgang mind. ein Bild besitzt
• Timo fragt bei Intranda, ob das nicht auch ohne „Goobi Exception“ geht
• 22.12.2016: nochmal bei Robert nachgefragt
• 3.2.2017
  • die Prüfung nach Bildern kann über die Konfigartion ausgestellt werden - alternativ kann das Bildverzeichnis autoamtisch erstellet werden
    • beides ist in der SUB bewusst so eingestellt und darf nicht verändert werden (Rolf)
      • Validerung um sicherzustellen, dass nur Bände mit Bildern exportiert werden
      • keine automatische Generierung des Bildverzecihnisses, da dies Probleme bei einigen Scannern verursachen würde und damit Mehrarbeit in REP
  • ⇒ leider nicht zu ändern, um die Valdierung und das MODS zu prüfen muss also immer das Bildverzeichnis erstellt werden

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

Der Schrifttyp wird im Regelsatz in die Metadaten übernommen, allerdings ist das Mapping nach MODS noch nicht ganz klar. Die HAB verwendet dafür mods:language/mods:scriptTerm - etwas frei interpretiert, aber ok. Leider erlaubt es das MODS Schema nicht, mods:scriptTerm in ein eigenes mods:language (ohne ein mods:languageTerm) zu packen. Das wirft sowohl technische Probleme mit Goobi, als auch inhaltiche Probleme bei der Erfassung auf (Schrifttyp wird nur einmal erfasst und müsste dann für alle Sprachen gelten).

Idee: languageTerm mit Standardcode undefined usw.

<mods:language>
   <mods:languageTerm authority="iso639-2b" type="code">und</mods:languageTerm>
   <mods:scriptTerm type="text">Fraktur</mods:scriptTerm>
</mods:language>

Updates:

• 8.2.2017
  • angelegt Sprachcode „und“ (undetermined) (s.o.)
  • Das Konstrukt, um den Sprachcode zusätzlich einzufügen erlaubt es nicht, den Schrifftyp wiederholbar zu machen - war er noch nie, aber falls wir mal auf die Idee kommen…
• Evtl. gibt es künftigen MODS Versionen eine bessere Möglichkeit

Im mfptr in der logischen structMap ist das xlink:href leer, sowohl beim Band als auch beim Anchor.

Updates:

• 8.2.2017
  • Funktioniert jetzt, hing vermutlich mit den fehlenen METS-Filegruppen in der Projektkonfiguration zusammen

Die sortierfähige Zählung im Feld „Verknüpfung zur mehrteiligen Monografie (Überordnung) : Zählung Sortierform“ ist im MM21 (890$x) nicht immer korrekt. z. B.:

• http://www.eromm.org/cgi-bin/pica2marc.pl?version=1.1&recordSchema=marcxml&recordPacking=xml&operation=searchRetrieve&query=pica.ppn%3D729375013&maximumRecords=2

Updates:

• Die Sortiertzählung kommt aus PICA und wird im MM21 nur so übernommen
• Bisher wurden alle Formen der Bandzählung beim Anlegen des Vorgangs von Hand eingegeben
  • vorliegende Zählung für die Anzeige
  • Sortierzählung für mods:part/@order
  • „Bennung“ für den Vorgangstitel (vierstellig mit führenden Nullen)
• evtl. kann etwas geneniert werden, um die Eingabe zu erleichtern, zu disktieren
• Zählung für die Anzeige wird aus dem GVK übernommen
• 6.12.2016
  • nur die Anzeige übernehmen, die andere Felder werden beim Anlegen von Hand eingetragen
    • Zählungen sind zu heterogen um etwas automatisch aufzubereiten
    • ⇒ erledigt, Sortierzählung wird nicht mehr übernommen
  • Timo spricht mit Jörg über das Label, statt „Band“ z. B. „Zählung“, um Dopplung zu vermeiden
    • ⇒ Es wird einen gemeinsamen Termin mit Jörg zu allen Fragen rund um das neue GDZ Portal geben