Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Section
Panel
title*Inhalt*
Table of Contents
Panel
Section

Aleph Publishing Mechanismus (PM) - XML-Schnittstelle

Entscheidungen 2009/2010

Nutzung für hbz-Suchraum

  • Nutzung des Aleph Publishin Mechanismus für die Bereitstellung von Metadaten aus der hbz-Verbuddatenbank für den hbz-Suchraum
  • Primäres Ziel: Bereitstellung eines "aggregierten" HBZ01-Titeldatensatzes (XML-Struktur)
    -> d.h. mit zugehörigen "verlinkten" Informationen (Überordnungen, Normdaten, Bestandsdaten)
  • Fernleihfeld 088 soll so wie über Z39.50 zur Verfügung gestellt werden
  • Keine Konvertierung oder Normalisierung der Daten
    • Datenfelder werden i.d.R. 1:1 zur Verfügung gestellt
  • Strukturelle und inhaltliche Modifikationen finden nicht in Aleph sondern zwischen Abzug dem Abzug der HBZ01-XML-Daten und dem Import der Daten in den hbz-Suchraum statt

Nutzung für Linked Open Data (LOD)

  • Aufgrund der LOD-Initiative wird die Aleph-XML-Schnittstelle inzwischen auch für dieses Projekt verwendet
  • Nutzung der identischen Daten durch LOD wie durch den hbz-Suchraum
  • keine eigene Metadaten-Aufbereitung durch Aleph für LOD

Verfahren Aleph PM

Der Aleph Publishing Mechanismus (PM) dient dazu, Metadatensätze aus dem Aleph-System für diverse externe Anwendungen in einem aggregierten und normierten Format zur Verfügung zu stellen. Die Metadaten werden dabei aus den Aleph-Datenbanktabellen (i.d.R. aus Oracle-Tabelle Z00 = Metadaten) extrahiert, ggf. normiert und um weitere Informationen angereichert.

Die Daten werden in einer Oracle-Tabelle gespeichert (Z00P) und können von hier über diverse Mechanismen "abgerufen" werden (z.B. über OAI, SQL).

Die Tabelle Z00P kann einmalig aufgebaut werden. Es existiert auch ein Update-Verfahren, damit laufende Updates aus den verschiedenen Aleph-Libraries zu aktualisierten Sätzen in der Tabelle Z00P führen. Das Update-Verfahren ist z.Zt.noch nicht für den hbz-Suchraum in Produktion.

Der Aleph PM wird derzeit für DigiTool und für die Bereitstellung der Daten für den hbz-Suchraum und für LOD verwendet. In die Tabelle Z00P fließen daher HBZ01-Sätze in mehrfacher und unterschiedlicher "Ausführung", abhängig davon für welchen Zweck diese verwendet werden. Die Datensätze sind für ihren Einsatzbereich entsprechend gekennzeichnet ("Set-Name").

Format-Beschreibung

Struktur, Format, Zeichensatz, ...

  • Allgemeines Format: XML-Datensätze
  • Set-Name der XML-Daten für den hbz-Suchraum und für LOD: "ALEPHFASTMAB"
  • Formatstruktur: MARC-XML
  • Feldbezeichnungen: MAB2 (+ spezifische hbz-/Aleph-Felder, s.u.)
  • Feldinhalte: RAK, RSWK (+ Verbundvereinbarungen, s.u.)
  • Zeichensatz: UTF8

Umfang der Daten

Pro Datensatz in der Aleph-Library HBZ01 (Titeldaten) existiert ein XML-Datensatz. Der XML-Datensatz besitzt folgende Informationen:

  • Alle physikalisch existierenden Datenfelder aus dem Titelsatz selbst (Oracle-Tabelle Z00)

Zusätzlich wird dieser Titeldatensatz um "virtuelle Felder" aus anderen Aleph-Quellen angereichert:

  • Informationen aus Überordnungen (HBZ01, Quelle Z00-Satz)
  • Informationen aus Normdaten (HBZ18 = GND, Quelle: Z00-Satz)
  • Informationen zu Bestandsdaten aus diversen Aleph-Quellen (HBZ01: LOW-Feld aus Z00-Satz, Z300-Tabelle; HBZ60: Z00-Satz)

Feldelemente (MARC-XML)

  • dreistellige Feldbezeichnungen
  • Standardfelder
    • 1. Indikator
    • 2. Indikator
    • Unterfeldkennzeichen
  • sogen. "Kontrollfelder" (Controlfield)
    • besitzen keine Indikatoren und keine Unterfelder
    • haben i.d.R. eine feste Länge
    • der Feldinhalt wird durch die Position von Werten definiert

MAB2-Konformität

Grundsätzlich haben in Aleph die MAB2-Felder die Bezeichnung und die Bedeutung wie in MAB2.

Abweichend zur offiziellen MAB2-Dokumentation werden in Aleph die MAB2-Felder nach folgenden Konventionen gespeichert:

  • Ein Feld hat - abweichend zu MAB2 - immer einen 2. Indikator, der i.d.R. nicht verwendet wird
  • Felder, die keine Kontrollfelder sind (Felder mit fixer Länge und Codes), besitzen i.d.R. immer das Standard-Unterfeld a
  • Strukturelemente von MAB2 wie Teilfeldtrennzeichen oder feste Längen bei Standardfeldern werden in Aleph über eine Unterfeldstruktur dargestellt
  • bestimmte Felder besitzen daher auch weitere Unterfelder (UF), wenn dies aus strukturellen Aspekten sinnvoll ist
    • Beispiel: Feld 100, UF a = Text (Name), UF b = Funktion, UF 9 = ID Normsatz (anstelle Feld 102)
  • wenn für MAB2-Felder eine offizielle Unterfeldstruktur definiert ist, so nutzt diese auch Aleph intern

Hintergrund: Abbildung MAB2 offiziell auf Aleph-MAB2

Standardverarbeitung für ein Feld ist:

  • Bilde UF a beim Import (Ausnahmen siehe Sonderroutinen) / Lösche beim Export
  • Bilde 2. Indikator blank beim Import / Lösche beim Export

Sonderbehandlungen von Feldern beim Import/Export von MAB2-Daten (Austauschformat) werden über eine Konfigurationstabelle definiert
Diese Konfigurationstabelle ist nicht für die XML-Schnittstelle eingebunden. Für die XML-Schnittstelle wird das Aleph-interne-MAB2-Format in XML-Struktur genutzt (s.u.)

Konfigurationstabelle tab_fix_mab (MAB2-Austauschformat <-> Aleph-MAB2 - arbeitet in beide Richtungen)

  • Felder, die nach der Stanardverarbeitung konvertiert werden, sind nicht in der Tabelle tab_fix_mab aufgeführt
  • 1. Spalte: Feld, das konvertiert werden soll
  • 2. Spalte: Name der fix-doc-mab-Routine
    (Hinweis: Die Feldnamen innerhalb der Routinenbezeichnung definieren ein Feld als "Muster", bei dem die Routine angewandt wird. Die Routine kann auch bei anderen Feldern, die diesem Muster entsprechen, eingesetzt werden - s. 1. Spalte)
  • Erläuterungen zu den eingebundenen Routinen

hbz-/Aleph-spezifische Felder (abweichend bzw. zusätzlich zu MAB2)

Zusätzlich zu den u.g. Feldern, die für die XML-Daten als "virtuelle Felder" aufgebaut werden, sinf folgende Felder physikalisch in den Daten vorhanden:

  • anwenderspezifische MAB2-Felder aus dem Bereich 076 - 079 und 081 - 087:
    • ... werden für hbz-spezifische Belange genutzt und sind entsprechend ihrer Felddefinition und ihrer Feldinhalte dokumentiert (s.u.)
  • Alpha-nummerische Feldbezeichnungen (Ann, Bnn, Cnn, ...):
  • rein alphabetische Feldbezeichnungen (LDR, FMT, CAT, ...):
    • für i.d.R. Aleph-/hbz-interne Funktionen
    • Kurz-Dokumentation dazu kann - wenn benötigt - zur Verfügung gestellt werden

Beschreibung Inhalte

Da der HBZ01-Datensatz um zusätzliche Informationen aus "anderen" Aleph-Datenbereichen angereichert wird, sind Konventionen notwendig, um diese Felder von den Standard-HBZ01-Feldern zu unterscheiden:

  • spezifische Feldbezeichnung, die sonst nicht in HBZ01-Daten vorkommt
  • spezielle Kennzeichnung von Feldern, woher diese kommen

Titeldaten

Allgemeines

Alle Titeldatenfelder aus dem HBZ01.Z00-Satz werden in die XML-Struktur überführt (MAB2-Standardfelder, MAB2-Kontrollfelder, hbz- und Aleph-spezifische Felder)

Konfiguration

HBZ01-Felder können für den XML-Datensatz über verschiedene sogen. fix-Programme modifiziert/konvertiert werden

  • z.Zt. ist keine Konvertierung konfiguriert

Expand von Überordnungen

Mit Anschluss eines expand-Programms werden bei einem sogen. MAB2-Untersatz Felder aus dem direkt übergeordneten Datensatz in den Satz selbst eingezogen ("expandiert")

Zweck:
Indexierungs- und Anzeigemöglichkeit von Überordnungs-Informationen bei der Unterordnung, da diese ansonsten keine identifizierenden Merkmale besitzt.

Damit bei dieser expansion die Zugehörigkeit der Felder (Quelle Untersatz oder Quelle Überordnung) erkannt werden kann, werden diese Felder mit einem speziellen Wert als 2. Indikator gekennzeichnet. Hinweis: Da der 2. Indikator im Standard-MAB2-Kontext nicht verwendet wird, treten keine Konflike auf.

Realisierung/Spezifikation:

  • Expand-Programm generiert grundsätzlich - für alle HBZ01-Daten - einen Wert für den 2. Indikator
    • Felder aus dem HBZ01-Satz selbst: 2. Indikator mit Wert "1"
    • Felder aus Überordnungen bei MAB2-Untersätzten: 2. Indikator mit Wert "2"
  • Regel für Expansion von Überordnungen
    • HBZ01-Satz ist ein MAB2-Untersatz (FMT-Feld mit Wert "MU" bzw. LDR mit Wert "u" an letzter Position)
    • über die Verknüpfungs-ID in MAB2-Feld 010 werden die Felder der Überordnung in die Unterordnung expandiert
    • es werden Felder der Formal- und Sacherschließung expandiert
    • die expand-Routine arbeitet nur für die Verknüpfungen aus dem Feld 010 in den übergeordneten Satz
    • die expand-Routine berücksichtigt nicht die anderen Verknüpfungsfelder (453ff, ...)

Konfigurationsmöglichkeiten: nicht vorhanden

Erklärung zur Anreicherung von Titeldaten nur bei MAB2-u-Sätzen und nicht bei h-h-Beziehungen (Feld 453ff)

  • das Konzept ist hier, dass nur der Satz angereichert wird, der ohne seinen Vater "keine" Informationen hätte (=u-Satz)
  • ggf. Anreicherungen bei h-h-Verknüpfungen im Bereich der Titelangaben sinnvoll, damit zusätzliche "Namen"/Titel der Schriftenreihe in das Stück für die Recherche gezogen werden
  • der fehlende expand für diese Fälle kann jedoch sicher vernachlässigt werden; ist bei Ex Libris auch nicht beauftragt worden
  • für Sacherschließungsinhalte ist ein expand bei h-h-Verknüpfungen grundsätzlich nicht sinnvoll, da in der Überordnung eher nur sehr allgemeine Schlagworte/Notationen stehen, die für alle Stücke dann berücksichtigt würden (nur sehr allgemeine Schlagwörter)

Hinweis zu Verknüpfungen über mehrere Hierarchie-Ebenen:

  • per Arbeitsvereinbarung werden im hbz-Verbund nur u-h-Verknüpfungen für _eine_ Hierarchiestufe verwendet
  • lt. MAB2 sind u-y-h-Verknüpfungen möglich (y = Zwischenstufe/Abteilung), wir nutzen _keine_ y-Sätze. (u-u-Verknüpfungen sind grundsätzlich nicht erlaubt)
  • im hbz-Verbund sind Zwischenstufen textueller Bestandteil des u-Satzes (in wiederholb. Unterfeldern a von Feld 089)
  • falls doch einmal im hbz eine y-Satz oder ein u-Satz (=falsch) als Verknüpfungsziel verwendet wird (und nicht der h-Satz), dann gäbe es auch die Indikatoren mit den Werten >2 (2 für den direkt übergordneten Satz, 3 für den nächsthöheren, ...)

Normdaten (GND)

Allgemeines

Im HBZ01-Titelsatz sind physikalisch in den Feldern 100ff, 200ff, 800ff und 902ff die Ansetzungsform und die Identifikationsnummer eines Normdatensatzes (seit GND auch weitere Informationen wie z.B. Lebensdaten) angegeben. Verweisungsformen zu GND-Daten sind in einer eigenen Aleph-Library HBZ18 (GND) gespeichert.

Mit GND-Start besitzt die Aleph-Umgebung der Verbunddatenbank keine hbz-spezifschen (regionalen) Normdatensätze mehr. Die in der Vergangenheit geführten regionalen Normdatensätze sind im Rahmen der GND-Migration auf überregionale GND-Sätze zusammengeführt worden. Eine kleine Restmenge von "alten" regionalen Normdaten-IDs ist noch in einzelnen Titeldaten referenziert, obwohl es zu diesen IDs keinen Normsatz (mehr) gibt. Eine Bereinigung dieser IDs muss noch geplant/durchgeführt werden.

Expansion von Normdaten (GND) in HBZ01-Datensatz

Zusätzliche Normdateninformationen aus HBZ18 (GND) werden über ein expand-Programm in den HBZ01-Satz als virtuelle Felder expandiert.

Zweck: Indexierung von Normdatenverweisungen für Titeldaten, damit Titel auch mit alternativen Namensvarianten von Autoren, Körperschaften und Schlagwörtern gefunden werden können. Die in den Titel expandierten Verweisen enthalten z.T. auch weitere identifizierende Merkmale zu GND-Normsätzen (z.B. Lebensdaten bei Personen)

Realisierung/Spezifikation allgemein

  • Expand-Programm sucht über die ID in den Feldern 100ff, 200ff, 800ff und 902ff (jeweils in Unterfeld 9) den zugehörigen Normdatensatz
  • Wenn die ID in HBZ18 gefunden wird, wird der Feldinhalt der Ansetzungsform in den Feldern 100ff, 200ff, 800ff und 902ff mit der Ansetzungform aus dem Normdatensatz ersetzt; die ID bleibt erhalten bzw. wird durch die GND-ID ersetzt (falls abweichend)
  • Verweisungsformen aus dem Normdatensatz werden in die offiziellen MAB2- bzw. nicht-dokumentierten Verweisungsfelder des Titelsatzes expandiert

...

Realisierung für Felder Personen

...

  • Feld 100
    • verschiedene Unterfelder (außer b, 9; mandatory): enthalten Ansetzungsform -> Dokumentation dazu im externen Wiki
    • Unterfeld 9 (optional, i.d.R. vorh.): GND-ID bzw. in seltenen Fällen hbz-spezifsche ID (Datenfehler, Normsatz fehlt, Bereinigung noch offen)
    • Quellfeld der Ansetzungsform in HBZ18: virtuelles Feld APER
    • Unterfeld b: Funktionsbezeichnung (Rolle) -> optional
  • Feld 101 (offizielles MAB2-Verweisungsfeld)
    • wiederholbare Felder 101: 0 - n Verweisungsformen
    • Struktur analog Feld 100 (jedoch kein Unterfeld b und 9)
    • Quellfelder der Verweisungsformen in HBZ18: virtuelles Feld VPER
  • Feld 102ff: nicht verwendet
  • identische Regeln für Felder 104, 108 ... 196 (25x insgesamt) und Felder 800, 806 ... 824 (5x insgesamt)

...

Realisierung für Felder Körperschaften

...

  • Feld 200
    • verschiedene Unterfelder (außer 9; mandatory): enthalten Ansetzungsform -> Dokumentation dazu im externen Wiki
    • Unterfeld 9 (optional, i.d.R. vorh.): GND-ID bzw. in seltenen Fällen hbz-spezifsche ID (Datenfehler, Normsatz fehlt, Bereinigung noch offen)
    • Quellfeld der Ansetzungsform in HBZ18: virtuelles Feld AKOR, AKON, AGEO
      • pro Vorkommen 200ff jeweils eines der Felder, abhängig vom Entitätentyp
  • Feld 201 (offizielles MAB2-Verweisungsfeld)
    • weitere, wiederholbare Felder 201: 0 - n Verweisungsformen
    • Struktur analog Feld 200 (jedoch kein Unterfeld 9)
    • Quellfelder der Verweisungsformen in HBZ18: virtuelle Felder VKOR, VKON, VGEO
  • Feld 202ff: nicht verwendet
  • identische Regeln für Felder 204, 208 ... 296 (25x insgesamt) und Felder 802, 808 ... 826 (5x insgesamt)

...

Realisierung für Felder Schlagwörter

...

  • Feld 902 (Kettenglied der 1. Schlagwortkette)
    • verschiedene Unterfelder (außer 9): enthalten Ansetzungsform -> Dokumentation dazu im externen Wiki
    • Unterfeld 9 (optional, i.d.R. vorh.): GND-ID bzw. in seltenen Fällen hbz-spezifsche ID (Datenfehler, Normsatz fehlt, Bereinigung noch offen)
    • Feld 902 ist wiederholbar (1 - n Schlagwörter für die 1. Schlagwortkette)
    • Quellfelder der Ansetzungsform in HBZ18: siehe Personen + Körperschaften, zusätzlich virtuelles Feld ASSW, ATIT
      • pro Vorkommen 902ff jeweils eines der Felder, abhängig vom Entitätentyp)
  • Feld 952 ("hbz-Feld")
    • weitere, wiederholbare Felder 952: 0 - n Verweisungsformen
    • Struktur analog Feld 902 (jedoch kein Unterfeld 9)
    • Quellfelder der Verweisungsformen in HBZ18: siehe Personen + Körperschaften, zusätzlich ASSW, ATIT
    • Hinweis 1: Feld 952 ist kein offizielles MAB2-Feld! Da in MAB2 für Schlagwörtern in den Titeldaten leider keine Verweisungsfelder definiert sind (so wie bei Personen und Schlagwörtern), wurde vom hbz das Feld 952 als Verweisungsfeld zu dem entspr. Ansetzungsfeld 902 definiert
    • Hinweis 2: Die "inhaltliche" Zuordnung der wiederholbaren Verweisungsfelder 952 zu den wiederholbaren Feldern 902 ist nicht sichergestellt, da beide Felder wiederholbar sind (keine "Klammer" vorhanden).
  • identische Regeln für die Felder 907, 912 ... 947 (10 Schlagwortketten insgesamt) und die Felder 957, 962 ... 997

Fazit GND-Änderungen

Panel
  • Ansetzungsform - Struktur
    • Ansetzungsform (ASF) in Feldern 100/200/800ff ist nun - wie schon immer bei 902ff - auf n Unterfelder aufgeteilt
    • Unterfeld a (alleine) kommt nur noch in bestimmten Fällen vor (keine Normdaten-Verknüpfung, Datenfehler)
  • Ansetzungsform - Inhalte
    • ASF hat sich z.T. aufgrund der GND-Regeln "inhaltlich" geändert
  • Ansetzungsform - Generierung
    • nur durch Aneinandersetzen der Unterfeld-Inhalte kann (wieder) eine ASF gebaut werden
    • Regeln zum Montieren der Felder (für Display, Indexierung, ...)
      • Reihenfolge der Inhalte wie im Satz = korrekt, sollte nicht geändert werden!
      • Trennzeichen: im Prinzip beliebig
        • Variante "DNB-Regeln": wie Anzeige/Lieferung ASF in MAB2-Titeln
        • Variante "Aleph-intern": Aleph-intern werden die Unterfelder "sehr einfach" mit Komma, blank für das Display und die Indexierung aufbereitet (kein "Nachbau" der alten ASF nach RAK-Regeln)
        • andere Varianten ...
Panel

Konfiguration in Aleph

An diversen Stellen sind Konfigurationsmöglichkeiten vorhanden:

...