Beschreibung Aleph-MAB-XML-Daten (Format + Inhalte)

Diese Version ist eine leicht veränderte Kopie der von Günter Hupfer 2012 im hbz-internen Wiki erstellten Seite.

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

  • 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 ...

Konfiguration in Aleph

An diversen Stellen sind Konfigurationsmöglichkeiten vorhanden:

  • Umfang der zu expandierenden Felder
  • Feldbezeichnungen, ...

Bestandsdaten

Allgemeines

In der hbz-Verbunddatenbank sind Bestandsdaten in diversen Datenbankbereichen vorhanden. Dies hat historische bzw. technische Gründe.

Die Grundregel lautet:

  • ein Bestandsnachweis wird grundsätzlich in Form eines Lokalsatzes physikalisch gespeichert (HBZ60, Z00)
  • der Lokalsatz enthält mindestens im sogen. OWN-Feld eine fünfstellige Aleph-interne Bezeichnung der besitzenden Bibliothek
  • der Lokalsatz kann entweder primär im hbz gespeichert werden oder er wird aus einem Aleph- oder Nicht-Aleph-Lokasystem (SunRise oder Libero) in die hbz-Verbunddatenbank repliziert

Exemplardaten werden - abhängig von Ihrer Entstehung und Herkunft - in unterschiedlicher Form gespeichert:

  • HBZ60, Z00, sogen. MEX-Felder (Mehrfach-Exemplar):
    • für Verbundbibliotheken, die Exemplardaten primär im hbz erfassen (nicht angebunden an eine Online-Schnittstelle)
    • für Nicht-Aleph-Lokalsysteme, die Exemplardaten (SunRise: Buchdaten) über die Versorgungsschnittstelle in die hbz-Verbunddatenbank hochladen (SunRise, Libero)
  • HBZ01, Z300
    • für Aleph-Lokalsysteme, die Exemplardaten über die Aleph-Replikation in die hbz-Verbunddatenbannk hochladen (Quelle im Aleph-Lokalsystem: Tabelle Z30 in der lokalen ADM-Library)

Zusätzlich existieren im Titelsatz für Bibliotheken, die die Versorgungsschnittstelle nutzen (SunRise und Libero), sogen. LOW-Felder (Local Owner):

  • LOW-Felder steuern die Versorgung der Titel an die Lokalsysteme
  • LOW-Felder ohne parallel vorhandenen Lokalsatz deuten i.d.R. auf einen Titel hin, der ins Lokalsystem repliziert wurde, zu dem aber noch keine Exemplardaten vorhanden sind (in Bestellung, ...)

Expansion von Bestandsdaten (Feld 088) in HBZ01-Datensatz

Die verteilt vorliegenden Bestandsinformationen werden über ein expand-Programm in den HBZ01-Satz als virtuelle Felder expandiert.

Zweck: Indexierung von Sigeln, Anzeige und Weiterverwendung von Bestandsinformationen für die Ausleihe und Fernleihe

Realisierung/Spezifikation

  • Identische Realisierung wie aktuelles Fernleihfeld 088 für die Z39.50-Recherche (Dokumentation s. dort)
  • Quellen von Bestandsinformationen für das expand-Programm bzw. die expand-Programme
    • HBZ01-Datensatz (Z00), LOW-Feld: enthält Owner-Angabe
    • HBZ60-Datensatz (Z00)
      • OWN-Feld: enthält Owner-Angabe
      • enthält (i.d.R. replizierte) Exemplarinformationen (in wiederholbaren MEX-Feldern) von Verbundbibliotheken mit Nicht-Aleph-Lokalsystemen
      • enthält ZDB-Bestandsangaben
    • HBZ01, Oracle-Tabelle Z300: enthält ausschließlich replizierte Exemplardaten aus Verbundbibliotheken mit Aleph-Lokalsystemen
  • grundsätzliche Funktionsweise des expand-Programms
    • Aufbau eines Feldes 088 pro Bestandsinformation
    • eine Bestandsinformation besteht aus
      • nur besitzender Bibliothek (ohne weitere Exemplarinformationen)
      • besitzender Bibliothek und weiteren Exemplarinformationen)
    • parallele (redundante) Felder 088 mit nur besitzender Bibliothek und identischer Bibliothek mit Exemplarinformationen werden vom Programm dabei vermieden
  • Feldstruktur Feld 088: Unterfelder
    • Unterfeld a: Sigel
    • Unterfeld b: Standort
    • Unterfeld c: Signatur
    • Unterfeld d: ZDB-Bestandsangaben
    • Unterfeld e: Exemplarstatus
  • Feldinhalte Feld 088
    • Übersetzung von Aleph-Owner in offizielles Fernleihsigel
    • Übersetzung von Standort-Codes in textuelle Formen (wenn Konkordanz im hbz vorhanden/gültig)
    • Übersetzung von Exemplarstatus-Codes in textuelle Formen (wenn Konkordanz im hbz vorhanden/gültig)

URLs aus Lokalsätzen ("lokale URLs")

In den HBZ60-Datensätzen, die aus den Lokalsystemen repliziert bzw. im hbz primär erfasst werden, sind auch Felder 655# vorhanden, in denen sogenannte lokale URLs geführt werden (spezifische, auf die betreffende Bibliohtek bezogene URLs.
Diese Felder - und nur diese - werden aus dem Lokalsatz in den Titelsatz expandiert:

  • Feld 655, 2. Indikator 9, diverse Unterfelder
  • Unterfeld 2 zu Feld 655 enthält den Aleph-Owner des Lokalsatzes, aus dem das Feld 655 expandiert wurde
    • Hinweis: eine Übersetzung Owner - Sigel ist an dieser Stelle leider nicht durch eine Standard-Programm möglich

Konfiguration in Aleph

Feld 088

Für das aktuell eingesetzte expand-Programm "expand_doc_bib_088_hbz" gibt es keine Konfigurationsmöglichkeiten.

Es existieren neue expand-Programme für die diversen Quellen der Daten (LOW, HBZ60, Z300)

  • damit können virtuelle Felder aufgrund der Herkunft der Daten getrennt und - wenn gewünscht - auch unterscheidbar voneinander aufgebaut werden
  • Konfiguration des Zielfeldes möglich (z.B. offizielles Fernleih-Feld 077 anstelle 088)
  • weitere Konfigurationsmöglichkeiten vorhanden
  • Programme sind vom hbz noch nicht getestet / eingesetzt worden

Vermeidung der Expansion von Bestandsdaten aus der Überordnung in die Unterordnung (Kopplung Expansion Überordnungen mit LOW-Feld)

  • Problem: Die Expansion von Feldern aus der Überordnung in die Unterordnung (s.o.) führt auch dazu, dass LOW-Felder der Überordnung in die Unterordnung werden und diese dann als Feld 088 aufgebaut würden
  • Konsequenz: suggeriert, die Bibliothek würde alle Bände besitzen (auch wenn u-Satz ansonsten keinen eigenen Bestandsnachweis hat)
  • Damit keine Felder 088 für einen u-Satz aufgebaut werden, wenn das LOW-Feld nur in der Überordnung vorhanden ist, wird das LOW-Feld einer Überordnung gelöscht, bevor es in einen u-Satz expandiert werden könnte.
  • Hinweis: LOW-Felder der Überordnung werden als Bestandteil des Satzes der Überordnung weiterhin als Felder 088 expandiert
Lokale URLs

Hier wird das Programm "expand_doc_bib_hol_mab" angeschlossen. Eine zusätzliche fix-Routine sorgt dafür, dass nur die Felder 655 aus Lokalsätzen in die Titeldaten expandiert werden. Sollten zu einem späteren Zeitpunkt auch andere lokale Felder als relevant eingestuft werden, so könnten diese ebenfalls in die Titeldaten eingezogen werden.

URLs/Links zu DigiTool-Objekten

Expansion von DigiTool-Links in HBZ01-Datensatz

Eine expand-Funktion sorgt dafür, dass ein in der Aleph-Datenbank vorhandener Link auf ein DigiTool-Objekt als MAB2-Feld 655e, Unterfeld u expandiert wird. Abhängig davon, aus welcher Quelle (Sacn-Bibliotheken, DNB, ...) und zu welchem Zeitpunkt ein DigiTool-Objekt entstanden ist, findet sich dieser Link auch als physikalisches Feld 655ep in den Titeldaten.

Weitere Anforderungen

  • Interne Sytemnr./Katalogschlüssel der Titeldaten aus den jeweiligen Lokalsystemen der Bibliohteken werden benötigt für DigiBib Intro (Nachfolger von HILFD):
    • Aleph-Lokalsysteme: technische Realisierung durch Ex Libris (getestet vom OBV) liegt vor
    • SISIS-SunRise-Lokalsysteme: interner Katalogschlüssel aus SISIS-SunRisen (vorhanden als Teilinhalt von Feld 001 der Lokaldaten) ggf. nachnutzbar?

Dokumentation Feldinhalte - Verbundkonventionen

"Feldhilfen"

Es existieren Aleph-Konfigurationsdateien aller Feldbezeichnungen (Anzeige und Sortierung von Feldnummern + Feldnamen: Tabelle tab01.ger ) sowie einzelne html-Dateien zu den MAB2-Feldern, die im Aleph-Client als Feldhilfe verwendet werden:
Die Dateien sind mit Stand vom 3.11.2010 (inkl. einer readme.txt) hier abgelegt:
M:\alle\verbund\Aleph500\Setup\HBZ01-Datenformat-fuer-Suchraum-2010-11-03

Zulässige Feldwerte (Codierungen und Selektionskennzeichen)

Es existieren Aleph-Konfigurationsdateien für die Definition und die Prüfung von zulässigen Codierungen (z.B. Länder- und Sprachencodes) bzw. Feldwerten (z.B. Selektionskennzeichen für bestimmte Ressourcen).
Die Dateien check_doc_tag_text und tag_text.dat sind mit Stand vom 3.11.2010 (inkl. einer readme.txt) abgelegt.

Hinweis: Nachnutzung inhaltlicher Vorarbeiten/Analysen für Konverion Aleph-MAB2 zu Suchmaschinen-Format

Im Rahmen der Spezifikationen für die Publishing Plattform (PPL) von Ex Libris (Teil von PRIMO) ist eine [Konkordanztabelle MAB2 (gemäß hbz-Aleph-Datenbank) zum sogenannten Primo Normalized XML Format (PNX)|090 - XMU - Beschreibung XML-Daten (Format + Inhalte)^05-MAB - mapping to NR-hbz.doc|\||] erstellt worden. Diese Konkordanz kann auch ggf. für die Spezifikation und Abnahme der jetzigen XML-Daten für den hbz-Suchraum verwendet werden.

Stichwörter

beschreibung beschreibung Löschen
format format Löschen
opendata opendata Löschen
Geben Sie Stichwörter ein, die dieser Seite hinzugefügt werden sollen:
Please wait 
Sie suchen ein Stichwort? Beginnen Sie einfach zu schreiben.