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)

Dokumentation überprüfen und ergänzen

Von	Status
Timo	in Arbeit (Timo)

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

METS Dateien prüfen

Von	Status
Timo	geplant (Stephan, Steffi, Timo)

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

ATS / TSL generiert nicht richtig

Von	Status
Cordula	alles nicht zu fixen (Timo, s. Updates)

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

Zeitschriften - Datenübernahme: Daten aus dem A-Satz in MM21

Von	Status
Karste, Cordula	Prüfung (Alex, Timo)

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

Strukturdaten testen

Von	Status
Timo	zur Erinnerung (Cordula, Karsten, Timo)

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

Normierte Ortsnamen übernehmen?

Von	Status
Timo	Prüfung (Cordula, Karsten, Alex, Steffi, Timo)

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>

Testen der MM21 und MODS Konversion

Von	Status
Timo	in Arbeit (Cordula, Karsten, Alex, Timo)

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

Testdatensätze

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

Updates

14.3.2017

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

Ergebnisse aus dem BETA-Test

Von	Status
Cordula, Karsten	in Arbeit (Alex, Timo)

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

Alex

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)

Dasselbe Unterfeld kann nicht einmal den Titel und einmal den Verfasser beinhalten !!! Das muss sich die VZG nochmal anschauen, das ist mit Sicherheit ein Fehler

* 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

Timo

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

Direkt geklärt

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

Produktiver BETA-Test

Von	Status
Cordula	in Vorbereitung (Timo)

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

Goobi SRU und HTTPS

Von	Status
Timo	Lösungen in Sicht… (Timo)

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

Fehler aus Tests

Von	Status
Timo	in Arbeit (Timo, Alex)

Alex

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 fehlt im MM21 (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 anhand PPN 88193884X (Pica+, Pica+ A-Satz, MM21, MODS)

Updates

x