Themenbereich | Frage | Antwort | Datum |
---|
Datenlieferungen | Werden bei ZDB-Datenlieferungen über OAI und Batch unterschiedliche Daten ausgeliefert?Hintergrund: ZDB-Datensätze werden über den ZDB-Batch-Änderungsdienst nicht ausgeliefert, wenn | Die Auslieferung kann unterschiedlich sein und hängt ab von - der Art der Änderung
- dem über OAI abgefragten Zeitraum
- der Zeitpunkt, an dem die OAI-Abfrage abgeschickt wurde und
- welcher Set über OAI abgefragt wird.
Art der Änderung | Aktualisierung in den Daten | Interne Kennzeichnung | Auslieferung ZDB-Änderungsdienst | Auslieferung OAI-Harvester |
---|
Eine Bibliothek ergänzt bei einem ZDB-Titel erstmals einen Lokalsatz. | In den bibliografischen Daten wird nur ein internes Feld (Pica+ 001@) aktualisiert |
wurde. In diesem internen Feld erfolgt eine Kennzeichnung wenn zu einer Bibliothek (ILN) erstmals ein Bestandssatz ergänzt wird (, dh. das Änderungsdatum des ZDB-Titels wird nicht aktualisiert | ZDB-Titel: IU = "in-use" (in Verwendung) ZDB-Lokalsatz: MU = "muteren" (Änderung) | ZDB-Titeldaten: Seit Oktober 2012 werden die "in-use"- Änderungen nicht mehr ausgeliefert. | Set zdb:holdings Änderungen an Lokaldaten werden ausgeliefert. Sonstige Sets zdb* Die Änderung wird nicht ausgeliefert, da das Änderungsdatum des Titels nicht aktualisiert wurde. | Eine Bibliothek markiert den letzten Lokalsatz der eigenen Bibliothek mit dem Löschkennzeichen. | - Die aktuelle Änderung wird nur in Feld 7001 des Lokalsatzes ausgeführt.
- Im Rahmen des ZDB-Änderungsdienstes
werden die mit Löschkennzeichen versehenen Lokalsätze physisch entfernt.
| - ZDB-Lokalsatz:
MU = "muteren" (Änderung) - ZDB-Titel
OU = "out-of-use" (nicht mehr verwendet) ZDB-Lokalsatz: DE = "delete" (Löschung)
| ZDB-Titeldaten: Die "out-of-use"- Änderungen werden nicht ausgeliefert. | Set zdb:holdings Änderungen an Lokaldaten (1.) werden im Zeitraum von der Markierung mit Löschkennzeichen bis zum ZDB-Änderungdienst ausgeliefert. Sobald der Lokalsatz physisch gelöscht wurde (i.d.R. montags ab ca. 20:00), kann die Löschung nicht mehr geharvestet werden. Sonstige Sets zdb* Die Änderungen werden nicht ausgeliefert, da das Änderungsdatum des Titels nicht aktualisiert wurde. | | | | | |
| Aktualisierung: 2013-08-03), aber auch wenn der letzte Bestandssatz einer Bibliothek (ILN) entfernt wird ("out-of-use"). Für die Verarbeitung des ZDB-Änderungsdienstes werden diese Datensatzänderungen seit Oktober 2012 ignoriert. Dies führte zur Reduzierung der ausgelieferten ZDB-Titel um ca. 60%, bei einer Testverarbeitung wurden statt ca. 14.000 ZDB-Titeldaten nur noch 5.500 Datensätze ausgeliefert. Über die OAI-Schnittstelle werden on-the-fly Korrekturen in der ILTIS-Datenbank durch die Abfrage unterschiedlicher Sets ausgeliefert (siehe Webseite OAI im Überblick). Damit Änderungen über diese Schnittstelle ausgeliefert werden, müssen im Wesentlichen folgende Voraussetzungen erfüllt sein: - Der OAI-Indexierungsprozess muss einen Hinweis erhalten, dass die Änderung erfolgt ist. Eine Änderung muss somit in der ILTIS/CBS-Protokolldatei enthalten sein. Dies ist bei den oben erwähnten Änderungen der Fall.
- Das Änderungsdatum muss aktualisiert und indexiert worden sein, da ansonsten die aktuelle Änderung bei der Abfrage des Harvesters nicht ermittelt werden kann. Die obengenannten Änderungen führen zwar zur Speicherung des aktuellen Datums in Pica3-Bestandsdatenfeld 7900 (Pica+ 201B), das Änderungsdatum des ZDB-Titeldatensatzes in Pica3-Feld 0210 (Pica+ 001B) wird jedoch nicht aktualisiert. Da jedoch letzteres Feld für die Indexierung beim OAI-Set der ZDB-Titeldaten ausgewertet wird, werden die oben erwähnten Änderungen "in-use" und "out-of-use" über OAI ebenfalls nicht ausgeliefert.
Fazit: Datensatzänderungen, bei denen das interne Feld 001@ geändert wird, werden weder über den ZDB-Änderungsdienst, noch über die OAI-Schnittstelle ausgeliefert. |
Originalschriftliche Katalogisierung | Werden vom MVB gelieferte originalschriftliche Zeichen jetzt schon übernommen? | Bei den Datenimporten nach ILTIS über die unterschiedlichen Schnittstellen finden schon seit ca. Ende 2011 keine Zeichensatzkonversionen mehr statt, sondern alle Zeichen, auch wenn sie im UTF8-Zeichensatz sind, werden so übernommen, wie wir sie erhalten. Das zentrale Bibliografiesystem CBS unseres ILTIS-Systems ist bereits seit einigen Jahren in der Lage alle UTF8-Zeichen intern korrekt abzuspeichern. An den Schnittstellen zum CBS gibt es Anwendungen, die UTF8-fähig sind (z.B. WinIBW3), Anwendungen die niemals UTF8-fähig sein werden (z.B. WinIBW2) und Anwendungen, die erst in zukünftigen Version UTF8-fähig sein werden (z.B. LBS). | 2012-07-19 |
Zeichensatz | Warum wird das Trema in Katalogen nicht immer korrekt angezeigt? | Wenn in der Datenverarbeitung eine Unterscheidung von Umlaut und Trema notwendig ist, empfiehlt ISO/IEC JTC 1/SC 2/WG 2 die unterschiedliche Darstellung des Tremas gegenüber dem Umlaut durch Verwendung des Combining Grapheme Joiner (Unicode Codepos. 034F, UTF-8 dez. \205\143) als Verbindung zwischen dem Grundbuchstaben und den zwei Punkten über dem Buchstaben, genannt Combining Diaeresis (Unicode Codepos. 0308, UTF-8 dez. \204\136).
Beispiel für die Codierung eines Umlautes: Bücher = Bu*\204\136cher Beispiel für die Codierung eines Trema: Joël = Joe\205\143\204\136{*}l
Der Katalogisierungsclient WinIBW unterstützt die Unterscheidung von Umlaut und Trema sowohl bei der Anzeige, als auch bei der Erfassung, d.h. wenn in der Sonderzeichenleiste das Zeichen Trema (rechts neben dem Punkt übergesetzt) ausgewählt wird, so wird der Combining Grapheme Joiner verwendet. Sollte dies nicht der Fall sein, muss die Konfiguration der WinIBW überprüft werden (in Verzeichnis ...\defaults\pref\ die Dateien diacritics.js und diacritics_description_de.js).
Nicht alle Anwendungen, die die Daten des ILTIS-Systems nachnutzen, können die Darstellung mit dem Combining Grapheme Joiner korrekt verarbeiten, sodass die Anzeige nicht immer der Darstellung in ILTIS entspricht (z.B. Online-Katalog der DNB: http://d-nb.info/gnd/1015048684). | 2012-09-12 |
Zeichensatz | Müssen für die Hoch- und Tiefstellung von Zeichen weiterhin Protypen verwendet werden? | Solange DNB weiterhin Daten in Datenformaten ausliefert, die den UTF8-Zeichensatz nicht unterstützen (z.B. MAB2), ist die Erfassung der Protypen "_1tn" und "_1hn" notwendig, wenn die Zeichen korrekt tief bzw. hochgestellt ausgeliefert werden sollen. Ansonsten werden diese Zeichen unterdrückt bzw. als Escape-Sequenz codiert dargestellt. So ist z.B. die Escape-Sequenz für das UTF-8-Zeichen des Bindestrichs (SOFT HYPHEN) die Zeichenfolge "&x00ad;" ACHTUNG: Zur bis Ende 2013 geplanten Abschaffung der Protypen, siehe Protypen.
Wie in den zuvor beantworteten Anfragen bereits dargestellt, ist das zentrale Bibliografiesystem CBS unseres ILTIS-Systems bereits seit einigen Jahren in der Lage alle UTF8-Zeichen intern korrekt abzuspeichern. An den Schnittstellen zum CBS gibt es Anwendungen, die UTF8-fähig sind (z.B. WinIBW3), Anwendungen die niemals UTF8-fähig sein werden (z.B. WinIBW2) und Anwendungen, die erst in zukünftigen Version UTF8-fähig sein werden (z.b. LBS vorauss. in 2013). Die IT der DNB arbeitet daran, dass zukünftig alle in ILTIS erfasste korrekte UTF8-Zeichen unverändert über alle Schnittstellen ausgeliefert werden. Bei Exportformat MARC21 sowie den XML-Austauschformaten ist dies bereits so umgesetzt. | 2012-12-06 Aktualisierung: 2013-07-31 |