Umstellung der Goobi Vorgänge auf den SUB Regelsatz für Drucke

Auf den folgenden Seiten wird die Umstellung der Vorgänge der alten Regelsätze auf den SUB Regelsatz für Drucke dokumentiert. Die Mappingseiten werden über XSL aus den bisherigen Regelsätzen erzeugt und dann gemapppt.

• Übersicht der Umstellung

Die folgende Seite dokumentiert die Konvertierung auf dem Goobi Server:

• Konvertierung auf dem Goobi Server

• Mapping GDZ

• Mapping VD17 Göttingen

• Mapping VD18 Göttingen

Anmerkungen

• Beinhaltet nur Monographien, Bände (MBW) und Mehrbändige Werke

• Goobi speichert leere Personenelemente
  • ganz leer sind sie nicht, GND Präfix ist vorhanden und der displayName besteht aus einem Komma

Das mods verwendet andere valueURIs für mods:languageTerm, nicht die LOC-URIs.
Das steht so im zvdd MODS AP als Beispiel

• Daten wo möglich besser aus dem A-Satz übernehmen, da unklar ist, welche Informationen beim Erzeugen des O-Satzes kopiert werden
• ZVDD ändern in
  • http://zvdd.gdz-cms.de/
    • wurde z. B. in VD18 Regelsatz verwendet
• Bei Körperschaften wird in mods:name kein mods:displayForm erzeugt

Es wird jetzt aus dem c-Satz übernommen:

• Record Identifier
• Location
• Ausgabebezeichnung und Erscheinungsvermerk

Der Titel wird (inkl. Unterordnungen) aus 036C übernommen.

(Pica+, Pica+ A-Satz, MM21, MODS)

• Paralleltitel fehlt (021F)
• Inhalt von mods:extent sollte wie bei MM21 gebildet werden
  • MODS: 1 Online-Ressource (XII Seiten, 232 Seiten) + Begleitmaterial
  • MM21 XII Seiten, 232 Seiten : Illustrationen, 1 Karte ; 8° + Begleitmaterial
• mods:note Element für die Verantwortlichkeitsangabe verwendet falschen type-Attributwert
  • statementOfResponsibility ⇒ statement of responsibility so muss das mal definiert gewesen sein, das steht bei uns noch so im MODS AP und andere machen das auch (ist also nicht unserer Phantasie entsprungen), sorry - was sollen wir tun?
• PPN vom A-Satz fehlt mods:identifier[@type=„other“]
• Fingerprint (007P$0) als mods:identifer[@type='fingerprint'] fehlt (nur in mods:note)
• ISBN fehlt (004A$0 und 004A$A)
• ISNM fehlt (004F$0 und 004F$A)
• Reihen und Untereihen fehlen (mods:relatedItem[@type='series'] werden
  • 036E$a und $l
• Bandnummer (Sortierung) mods:part/@order
  • muss bei der Umstellung muss es durch den alten Wert ersetzt werden
  • kann dafür ruhig drin bleiben
• Dokumenttyp (013@$0) fehlt (mods:genre[@authority='din31631-4'])
• 007G$0 kommt momentan als mods:identifier[@type='firstCataloguingId], soll aber als [@type='local'] kommt im Moment 2x, einmal als „other“ einmal als „firstCataloguingId“. Und wenn ich mal MODS selbst dazu zitieren darf, was auch unser AP tut: „There is no controlled list of identifier types. Suggested values include, but are not limited to the following […]“ Wir können überlegen alle die im Moment „other“ heissen in „local“ umzubennen, aber was gewinnen wir davon, für andere ist diese Unterscheidung gleich nutzlos
• DNB-Nummer fehlt (A-Satz 006G$0) in mods:identifier[@type='dnb']

(Pica+, Pica+ A-Satz, MM21, MODS)

• Datum in Vorlageform (011@$n A-Satz) fehlt gehört lt. AP auch nicht unbedingt dahin. Die Vorlageform steht in mods:note[@type=„original“]
  • attributloses dateIssued
• Bibliografische Zitate fehlen (007S$0, A-Satz) enth. jetzt bei RAK-Aufnahmen die Angaben aus dem O-Satz, bei RDA-Aufnahmen die Angaben aus dem O- und dem A-Satz, außer der Indikator ist e
• Untergliederung zur mehrteiligen Monografie fehlt
  • 036C$a+$c
  • /mods:mods/mods:relatedItem[@type='host']/mods:titleInfo/mods:title Die Angaben kommen alle aus 036D, bzw. dem dort verknüpften c-Satz, denn in mods:relatedItem wird halt das andere, das related Item beschrieben
• Inhalt von mods:extent ist unvollständig und enthält fälschlicherweise die 034D aus dem O-Satz
  • 034K aus dem A-Satz ist enthalten
  • 034I, 034M und 034D aus dem A-Satz fehlen
  • Generierung wie MM21 300$9, hier:
    • „Umfangsangabe : Illustrationsangabe ; Format + Begleitmaterial“ s. oben
• EAN fehlt (A-Satz 004L$0) in mods:identifier[@type='ean']
• Amtliche Druckschriftennummer fehlt (A-Satz 007B$0) in mods:identifier[@type='government publication']
• CODEN fehlt (A-Satz 007C$0) in mods:identifier[@type='coden']
• Verlags-, Produktions- u. Bestellnummer fehlt (A-Satz 007D$0) in mods:identifier[@type='order']
• Hochschulschriftennummer fehlt (A-Satz 007E$0) in mods:identifier[@type='thesis']
• Reportnummer fehlt (A-Satz 007F$0) in mods:identifier[@type='report']
• Normnummer fehlt (A-Satz 007H$0) in mods:identifier[@type='standard']
• Kontraktnummer fehlt (A-Satz 007Z$0) in mods:identifier[@type='contract']
• PPN gelöschte Aufnahme fehlt (A-Satz 003D$0) in mods:identifier[@type='GBVKat'][@invalid='yes']
• Beziehungen auf Manifestationsebene fehlt (A-Satz 039D, diverse Unterfelder) in mods:note[@type='additional physical form'] OK, das ist richtig problematisch (hat mich grad an meinem Verstand zweifeln lassen, aber es gibt ja immer für alles eine ganz natürliche Erklärung). Wir hatten mal gesagt, dass außer dem eigentlichen Feld zum Abbilden der Vorlage/Reproduktionsbeziehung (4256, 039I) teilw. 4243, 039D verwendet wurde. Dh. 039D wird verwendet um u.U. den A-Satz zum O-Satz zu finden - und steht deshalb nicht mehr als Feld für die MODS-Konversion zur Verfügung. Letzteres könnte man ändern, problematisch ist allerdings, dass sich dadurch ein gegenseitiger Rückbezug ergeben könnte, was wir ja nicht wollen. – die Konversion ist allerdings noch im Template vorhanden (für A und O), falls wir das noch mal logisch auseinandergedröselt bekommen.
• Ursprüngliches Erscheinungsjahr fehlt (A-Satz 011@$r (Altdaten $e)) in mods:originInfo/mods:dateCreated[@encoding='iso8601'][@point='start'] Das bezieht sich auf Reprints. Wird in mods:note[@type=„original version“] ausgegeben, wenn nicht in 039I ein anderes Jahr steht.

(Pica+, MM21, MODS)

(Pica+, Pica+ A-Satz, MM21, MODS)

• das mods:originInfo für das Digitalisat enthält jeweils den ersten Ort des O-Satzes, hier in dem Beispiel entspricht das aber dem Ort des A-Satzes
  • das kann auch am Testdatensatz liegen, nochmal prüfen
  • benötigt der Anchor überhaupt ein mods:originInfo für das „Digitalisat“? Nochmal grundsätzlich überdenken
  • im MM21 werden alle Orte ausgegeben Hier wäre ein besserer Beispielsatz hilfreich (mit verschiedenen Ortsnamen). Problematisch ist außerdem, dass sich Ort/Verlag und Jahr in MODS nicht mehr eindeutig zuordnen lassen wenn es mehrere gibt
• ZDB-Nummer vom O-Satz (006Z$0) übernommen in mods:identifier[@type='zdb'] - 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']
    • A-ZDB in mods:relatedItem[@type=„original“]/mods:identifier[@type=„zdb“] Das widerspricht dem MODS AP, hier wird das Digitalisat durch das Original beschrieben (Sekundärausgabe) und nicht auf das Original bezogen
      • dafür wäre ein neues Goobi-Feld erforderlich
    • s. a. MM21
    • Alternativen? A-Satz ZDB Nummer weglassen? JA! (steht jetzt in „other“)
• ISSN fehlt (A-Satz 005A$0) in mods:identifier[@type='issn'] Hier das gleiche. Online-Ausgaben haben eigene ISSN, dh. die kann nur as dem O-Satz kommen. Einfache Lösung: A-Satz ISSN und ZDB Id weglassen oder beides jeweils als mods:identifier[@type=„other“] ausgeben. Im Moment lass ich es weg. (steht jetzt in „other“)
• Nochwas zur ISSN: aus PICA kommen ISSN und ISBN jeweils ohne Striche. Setzt Du die bei der Konversion ein? Nein, zu aufwendig

(Pica+, Pica+ A-Satz, MM21, MODS)

• Der Parallelsachtitel wird sowohl in mods:titleInfo/mods:subTitle als auch in mods:titleInfo[@type='translated']/mods:title dort nochmal gedoppelt als mods:subTitle ausgegeben
  • da läuft etwas schief, ggf. durch Katalogisierungsfehler im Testdatensatz verursacht, nochmal prüfen +
  • Zum Zusatz zum PST: Hier wird das Unterfeld in PICA nicht korrekt umgewandelt, weder mit $d noch mit : In RAK muss aber lt. der alten KatRicht : stehen und das wird vom Template auch ausgewertet. Das merkwürdige Phänomen der Doppelung liegt in diesem Fall an der falschen Eingabe im Testdatensatz, was allerdings ein Sonderfall ist. Das gleich Phänomen trat auf, wenn es keinen Zusatz zum PST gab, das ist jetzt repariert
• Datum in Vorlageform (011@$n, vorhanden in O- und A-Satz) fehlt in mods:originInfo/mods:dateIssued s.oben. Bei RAK-Aufnahmen werden außerdem KEINE Daten aus der A-Aufnahme übernommen.
• Abweichende Titel und spätere Haupttitel (4212 | 046C$a + $b) soll laut Datenmapping in die Allgemeine Bemerkung (mods:note), wird aber als Abweichender Titel ausgegeben (hier mods:titleInfo[@type='alternative'])
  • Nochmal prüfen, was gewollt ist , s.a. MM21 das steht so in der Exceltabelle und ist eigentlich gewollt, ist hier auch explizit ein Nebentitel (d.h. in PICA auch als Titel suchbar)
• Besitznachweis des reproduzierten Exemplars (009A O-Satz) fehlt in mods:note[@type='original location'] steht da 1a drin
• Bibliografische Zitate fehlen (007S$0, A-Satz, s.o.) keine Datenübernahme aus A-Aufn. in RAK
• Gesamttitel der fortlaufenden Ressource (036E$a + $l) fehlt in mods:relatedItem[@type='series']/.. Die Daten werden aus 036F erzeugt
  • Es wird aber 036F übernommen und in einem mods:relatedItem[@type='series'] expandiert
    • Wollen wir das oder weglassen? Ja, war eigentlich Absicht
      • Kann nicht von den „036E series“ bei der Konversion unterschieden werden 036E wird überhaupt nicht ausgegeben
    • Zählung ist leer (liegt aber wohl am Testdatensatz?) Ja, das liegt in dem Fall am Testdatensatz, man kann über WinIBW nicht anscheinend nicht mehr nach den RAK Gepflogenheiten neu erfassen. Ich hab's zwar hinbekommen da ein Unterfeld $l reinzuschreiben, aber über UNAPI kommt das nicht (viell. braucht die einen Moment zum aktualisieren?)
  • im MM21 wird nur 036E berücksichtigt ist richtig. Ich denke drüber nach
• PPN A-Satz fehlt in mods:identifier[@type='PPNanalog'] halte ich für irrelevant

(Pica+, Pica+ A-Satz, MM21, MODS)

• PPN gelöschte Aufnahme fehlt (A-Satz 003D$0) in mods:identifier[@type='GBVKat'][@invalid='yes'] (s.o.) keine Datenübernahme aus dem A-Satz in RAK-Aufnahmen
• ISBN (004A$0 & $A) fehlt in mods:identifier[@type='isbn']
• Weiterer Identifier aus 007G (2240, Identnummer der erstkatalogisierenden Institution) fehlt in mods:identifier[@type='other'] der steht echt dreimal in der Aufnahme drin, ich finde das mal grad ausreichend
• CODEN fehlt (A-Satz 007C$0) in mods:identifier[@type='coden'] keine Datenübernahme aus dem A-Satz in RAK-Aufnahmen
• mods:relatedItem[@type='host']/mods:titleInfo/mods:title
  • in mods:relatedItem[@type='host'] werden diverse Informationen expandiert, u.a. der Titel der übernommen wird
  • bitte nochmal prüfen, ob das die 036C sind, da hatten wir eine längere Diskussion zu, s. Abteilungen
  • bitte auch prüfen ob der „Nicht zitierfähiger Bandtitel“ in der MODS Konversion für fehlt in mods:part[@type='host']/mods:detail/mods:title vorhanden ist
    • s. MM21 891$z
    • leider finde ich das Beispiel gerade nicht… :(

[%- IF (r.type == 'f' || r.type == 'F') -%]
<mods:part order="[%- r.subfields('036D','X').item(0).item(0) | xml -%]">
<mods:detail type="volume">
<mods:number>[%- r.subfields('036D','l').item(0).item(0) | xml -%]</mods:number>
[%- IF (r.type == 'f' && (r.subfields('021A','a').item(0).item(0) || r.subfields('021A','d').item(0).item(0))) -%]
<mods:title>[%- r.subfields('021A','a').item(0).item(0) | xml -%][%- IF r.subfields('021A','a').item(0).item(0) -%] : [%- END -%][%- r.subfields('021A','d').item(0).item(0) | xml -%]</mods:title>
[%- END -%]
</mods:detail>
</mods:part>
[%- END -%]

(Pica+, MM21, MODS)

(Pica+, Pica+ A-Satz, MM21, MODS)

• Der Parallelsachtitel mit Zusatz wird korrekt in mods:titleInfo[@type='translated'] ausgegeben, ist aber auch in mods:titleInfo/mods:subTitle vorhanden s. oben
  • in MM21 wird er richtig nur in 249 ausgegeben
• Abweichende Titel und spätere Haupttitel (4212 | 046C$a + $b) soll laut Datenmapping in die Allgemeine Bemerkung (mods:note), wird aber als Abweichender Titel ausgegeben (hier mods:titleInfo[@type='alterantive'])
  • Nochmal prüfen, was gewollt ist , s.a. MM21 das ist in RAK ein Nebentitel nicht ein späterer Haupttitel, dafür gab es früher ein anderes Feld
  • s.a. RAK Mono Beispiel
• OCLC-Identifikationsnummer fehlt (A-Satz 003O$a) in mods:identifier[@type='oclc'] keine Datenübernahme aus dem A-Satz in RAK-Aufnahmen
• Swets-Nummer fehlt (A-Satz 006N$0) in mods:identifier[@type='swets'] keine Datenübernahme aus dem A-Satz in RAK-Aufnahmen
• ZDB-Nummer fehlt (A-Satz 006Z$0) in mods:identifier[@type='zdb'] keine Datenübernahme aus dem A-Satz in RAK-Aufnahmen
• ISSN fehlt (A-Satz 005A$0) in mods:identifier[@type='issn'] keine Datenübernahme aus dem A-Satz in RAK-Aufnahmen

• 884600157 (RAK, Mono
  • mods:relatedItem[@type='series']
    • mods:part/mods:detail/mods:number steht doch beidemale was drin ??
    • mods:note das Problem an sich ist gefixt, gleichzeitig habe ich aber die Anzeige der Daten zur Serie reduziert, analog zur Anzeige der c-Stufe in mods:relatedItem
• 881967319 (RAK, MBW
  • mods:relatedItem[@type='series']
    • mods:part/mods:detail/mods:number das ist/war ein Katalogisierungsfehler, mglw. weil die alten Steuerzeichen aus RAK-Zeiten nicht mehr erkannt werden
    • mods:originInfo/mods:dateIssued steht doch überall was drin ??
    • mods:note steht doch überall was drin ??
  • mods:originInfo
    • mods:publisher steht doch überall was drin ??
• 88195411X (RAK, Zeitschrift
  • mods:relatedItem[@type='series']
    • mods:part/mods:detail/mods:number das ist viel komplizierter als es aussieht, hier handelt es sich um Beilagen, die werden von nun an als mods:relatedItem[@otherType='supplement of'] ausgegeben.
    • mods:originInfo/mods:dateIssued da finde ich kein leeres Element
    • mods:note da finde ich kein leeres Element
  • mods:originInfo
    • mods:publisher
• 88193884X (RDA, Zeitschrift
  • mods:relatedItem[@type='series']
    • mods:part/mods:detail/mods:number s. oben
    • mods:originInfo/mods:dateIssued s. oben
    • mods:note s. oben
  • mods:originInfo s. oben
    • mods:publisher s. oben

• „Externe“ Daten müssen noch ergänzt werden (Wo?)
  • Schrifftyp (als Parameter „Schrifttyp“)
  • Digitale Kollektion
  • TSL/ATS
  • Bandnummer (Sortierung)
  • Sponsor (nicht in VD18 Regelsatz enthalten)
  • MODS Elemente
    • extension
    • recordInfo (nur PPN)
    • part
    • relatedItem[@type='host']
• Normierter Erscheinungsort fehlt in der XSL
  • wahrcheinlich auch im MODS?
• mods:relatedItem fehlt in der XSL
• mods:part muss noch angepasst werden XSL
• mods:subject/mods:name in XSL auskommentiert
  • oder kommt da doch etwas?
  • erldigt
• Bei allen Titeln muss der „vollständige“ Titel („title_full“) generiert werden
• bei mods:subject aufpassen
  • enthält mods:name die aus dem „Komplex“ für Goobi herausgelöst werden müssen, um sie im entsprechenden Goobi Element zu speichern.
  • alle anderen Elemente in die „subject“ Gruppe
• Wiederholgruppen werden alle auf die „_x“ Felder gemappt
  • z. B. relatedItem_series_x

• Externer Zugriff auf Goobi
  • Valdierung anstoßen
    • Wie sieht die Antwort aus?
      • Bei Java-Exception
      • nicht bestandener Validierung?
    • ⇒ Momentan nicht möglich, wäre ein Entwicklungsauftrag für eine Erweiterung der REST-API. Laut Robert aber nicht aufwending und könnte „mal zwischengeschoben werden“, Aufwand wenige Stunden
    • ⇒ Alternative „halbmanuelle“ Lösung wäre einen Export der Metadaten ins Homeverzeichnis vor und nach der Konversion „per Hand“ (natürlich in Masse) anzustoßen, das hat den gleichen Effekt
      • richtig gut aber erst mit Goobi 3, da bei unsererer Version das nicht im Hintergrund läuft und man daher evtl. einen Timeout bekommt
      • welche Mengen sinnvoll sind ist fraglich
• Sicherungsdateien nach der Umstellung
  • Alle sicherheitshalber löschen? Funktionieren nicht mehr mit dem neuen Regelsatz
  • Ein Backup zusätzlich schon anlegen?
  • stört sich Goobi wenn wir da rumlöschen?
  • ⇒ Ist laut Robert egal, wenn Metadaten fehlen ist meist alles weg, auch die Sicherheitskopien
• Nur Metadaten in Masse exportieren ohne Bilder - Wie geht das?
  • ⇒ Möglich über Goobiscript
• Müsen wir noch irgendetwas anderes beachten?
  • ⇒ Robert hatte keine weiteren Ideen
• Suche nach Vorgängen mit einem bestimmten Regelsatz
  • Nicht über die Oberfläche möglich, nur direkt über die Datenbank
    • ⇒ Robert könnte eine Tabelle mit allen Infos zur Verfügung stellen (über Supportstunden)
    • ⇒ ggf. könnten wir auch selber gucken