Sie zeigen eine alte Version dieser Seite an. Zeigen Sie die aktuelle Version an.

Unterschiede anzeigen Seitenhistorie anzeigen

« Vorherige Version anzeigen Version 8 Nächste Version anzeigen »

 

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 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 ("in-use"), 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:

  1. 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.
  2. 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 OAI-Indexierung 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 vorauss. in 2013).

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;".
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

  • Keine Stichwörter