: Was Re: [mab-list] MABXML

Mon Sep 15 19:40:11 CEST 2003

Lieber Herr Kett, liebe Liste,

Ich moechte auf Ihre Fussnote 2 bei der Schilderung 2.2.1 der
Design-Richtlinien fuer MARCXML eingehen.

Sie schreiben:
>>>
Leider hat man hierbei nicht berücksichtigt, dass sich in MARC21 (wie
auch in MAB) die Vermischung von Daten und Daten-Präsentation bereits
eingeschlichen hat. So ist es üblich, Subfields mit Kommas und anderen
Interpunktionszeichen abzuschließen, um diese in einer Präsentation
einzusetzen. Solche unglücklichen „Präsentationszeichen" werden in
MARCXML als Dateninhalte übernommen. Siehe beispielsweise auf S. 9 
den Doppelpunkt in Beispiel 5 Field 020, Subfield a. 
<<<

In 6.5.1 sehen Sie ein Problem bei der "strukturellen Abgrenzung
von Ordnungshilfen und anderen Zusaetzen"

Auf der syntaktischen Ebene sind MARC21 und MAB2 Auspraegungen
der ISO 2709-Formatfamilie, genau wie MABXML ein XML-Format ist.
In beiden Faellen wissen wir damit, was ein "Datensatz" ist,
und dass er "Datenfelder" enthaelt, die "Indikatoren" und
"Teilfelder" enthalten, sowie natuerlich "Feldnamen".
Bei einem MARC- oder MAB-Record muss man natuerlich wissen,
dass es ISO 2709 gibt und dass die erwaehnten Dinge von diesem
Standard (an dieser und jener Position im Datensatz) festgelegt 
werden, bei MABXML hingegen steht am Anfang der Datei eine
XML-Deklaration, d.h. man weiss, dass es XML ist, weitergehende
Information (es gibt "Datensatz", "Datenfelder", "Unterfelder")
kann man der DTD entnehmen. In beiden Situationen entstammen
die Konzepte zu "Datensatz", "Datenfeld" erc. einer
Modellbildung, die jenseits der Standards liegt und sich
vermutlich auch sehr schlecht formalisieren laesst.
Man koennte diese Ebene das "Datenmodell" nennen, ich
habe allerdings den Eindruck, dass "Datenmodell" nirgendwo
so recht definiert worden ist.

Auf der naechsten Ebene haben wir das "bibliothekarische
Datenformat", das festlegt: "Es gibt ein Datenfeld mit
Namen 245 (oder 331) und die Bedeutung ist wie folgt: ...".
Diese Ebene ist (oder sollte sein) unabhaengig von XML,
ISO 2709, wasauchimmer, jedenfalls wird hier die Bruecke
zwischen der "realen Welt" und ihrer Abbildung in Datensaetzen
geschlagen. Diese "reale Welt" ist aber leider mitnichten
real, sondern eine Welt "bibliographischer Sachverhalte",
die das Resultat einer Modellbildung ist. Diese Modellbildung
oder Kategorisierung ist in den aktuellen bibliothekarischen 
Regelwerken implizit, man arbeitet daran, sie explizit zu machen
(etwa durch Glossare), die FRBR z.B. sind ein Ansatz, nur das 
(ein) Modell herauszuarbeiten. Im Detail unterscheiden sich
die verschiedenen Modelle, RAK kennt z.B. den "Zusatz zum
Hauptsachtitel", AACR nicht. Dementsprechend gibt es in MAB
ein Feld 335, in MARC21 nur ein wesentlich unspezifischeres
Teilfeld 245$b.

MARC21 hat den Anspruch, Daten zu beliebigen Regelwerken
transportieren zu koennen, MAB2 eher nicht. Ich bezweifle,
dass ein Datenformat einem solchen Anspruch gerecht werden
kann, denn man muesste dafuer beweisen, dass alle theoretisch
moeglichen bibliothekarischen Modellbildungen (oder zumindest
alle existierenden) mit MARC21 kompatibel sind. Der "Zusatz
zum Hauptsachtitel" ist da kein Gegenbeispiel, denn man kann
ihn ja (moeglicherweise verlustbehaftet) zusammen mit vielem
anderen in MARC 245$c versenken. Dieser Weg wird natuerlich
irgendwann absurd, denn das "universelle bibliographische
Format" besteht aus einem einzigen, unspezifischen Sammelfeld, 
in das ich hineinschreiben kann, was ich will und es ist
damit klarerweise kompatibel zu allen denkbaren Modellen...

Dieses von mir gerade spasseshalber eingefuehrte "universelle
bibliographische Format" ist mitnichten zu verwechseln mit
einer Karteikarte. Das Wort "Markup" ist recht neu, aelter
als XML oder ISO 2709 ist z.B. ISBD, eine Vorschrift, der
ebenfalls eine bibliographische Modellbildung zugrunde liegt,
sowie eine Vorschrift, in welcher Reihenfolge diese Sachverhalte
in Fliesstext niederzuschreiben sind, und welche Interpunktion 
(Markup!) zur Abgrenzung benutzt wird. Teil 1 der AACR
gibt sehr viele Hinweise auf das den ISBD implizite Modell,
es ist eine ziemlich komplexe Baumstruktur, wenn man sich
z.B. die Stellen, an denen "statements of responsibility" vorkommen
koennen (hinter jedem Titel, Parallelsachtitel, Edition,
named revision of an edition) genauer ansieht. MARC und
MAB streichen hier die Segel und degenerieren in diesen
Situationen zu komplizierten Schreibmaschinen.

In MARC21 wird ISBD-Interpunktion generell miterfasst, ob
aus historischen Gruenden oder wegen der "Abbildbarkeit
jeglicher bibliographischen Daten" sei dahingestellt, 
ein schoener Nebeneffekt, den man besonders einfach
bei den MARCXML-Beispielen sieht, ist, dass das Weglassen
jeglichen MARC-Markups (ISO 2709 oder XML) eine Folge von
Buchstaben und Zeichen ergibt, die dem ISBD-Einheitszettel
sehr sehr nahe kommt. MAB "kann" dies nicht, das liegt
uebrigens nicht nur an der ausgelassenen, da rekonstruierbaren,
Interpunktion, sondern auch daran, dass die Reihenfolge der
Felder vom System und nicht vom Katalogisierer vergeben wird.
Sie nennen das "Praesentationszeichen", es ist aus meiner
Sicht jedoch ein zweites Markup-System, das durch MARC und
MAB traditionell moeglichst verlustfrei "durchgeschleust"
werden soll.

Sowohl bei MARC21 als auch bei MAB gibt es genuegend viele
Situationen, wo die ISBD-induzierte Gliederung der Daten
feiner ist als das Feldrepertoire des Datenformats, hier
wird dann die Interpunktion beibehalten, etwa in vielen
Faellen im MAB-Segement 3xx. In manchen Faellen wird hier
gleichartiges durch " ; " abgetrennt, etwa in MAB 335 und
man kann sich hier tatsaechlich fragen, warum keine
Wiederholbarkeit zugelassen wird, wo es doch ein dediziertes
Feld fuer den Sachverhalt gibt. In anderen Faellen wird
verschiedenes (etwa durch " / " aber auch - MAB 407 - 
durchaus auch durch " ; ") abgetrennt, hier ist das 
Format nicht fein genug, die Sachverhalte auf Feldebene
zu trennen. MAB und MARC wuerden aber zu noch entsetzlicheren
Monstern mutieren, wenn man wirklich alles, was sich
begrifflich auftrennen laesst, auch in Felder und Unterfelder
des Formats auftrennen wuerde, ich unterstelle einmal,
dass man hier bei der Definition der Formate abzuschaetzen
versucht hat, ob sich noch feiner differenzierte Felder
irgendeine potenzielle maschinelle Nutzung in sich tragen
und es im Zweifel bei einem, durch "normale" Interpunktion
strukturierten, Feld belassen.

Auf einer Ebene innerhalb des jeweils den Daten zugrundeliegenden
Regelwerks befinden sich nun Eintragungsregeln einerseits sowie
Ansetzungs-, Ordnungs- und Sortierregeln andererseits.
Betrachtet man MAB 100ff, so kann hier ein ziemlicher
Zeichensalat entstehen, bei den Funktionsbezeichnungen (in 
NSZ eckige Klammer) wird m.E. ein bibliographischer Sachverhalt
beschrieben und es ist nicht unbedingt einzusehen, warum
dieser nicht in ein anderes Felder derselben Periodengruppe
ausgelagert wurde. "zur Ordnungsgruppe des Vornamens" zugeordnete
Namenspraefixe und die zusaetzliche Deklaration als "nicht 
sortierrelevant" sind pleonastische Regelungen in RAK, vermutlich
von PI geerbt, klarerweise ist es wichtig, diese Information
zu transportieren (denn rekonstruieren kann man sie nicht).
Ansetzungsregeln sind ein fundamentaler Bestandteil eines jeden
Regelwerks (im Bibliotheksbereich), ich moechte jedoch behaupten,
kein "integraler": Man koennte - ein sauber strukturiertes
Regelwerk vorausgesetzt - durchaus die Ansetzungsregeln gegen
ganz andere austauschen. Ich bin daher eigentlich ganz
zufrieden damit, dass die bibliothekarischen Datenformate
die bibliographische Modellbildung in Datenfelder umwandeln,
"Ansetzungen" aber intakt lassen, auch wenn es denkbar waere,
die den Ansetzungsregeln zugrunde liegende, ansonsten 
unabhaengige, Modellbildung in "Vorname", "Initiale", "Nachname",
"strukturierte Ordnungshilfe" im Datenformat nachzubilden.
[Wir reden hier von Titeldaten, fuer Normdaten-Austauschformate
gelten natuerlich andere Bedingungen].

XML und Namespaces bieten natuerlich die Moeglichkeit, 
Namensansetzungen subzustrukturieren, etwa fiktiv als
<feld nr="100" ind=" ">
  <pnd:person xmlns:pnd="http://www.ddb.de/pnd" pnd:namenstyp="modern">
     <nachname>Mueller</nachname>, <vorname>Peter</vorname>
  </pnd:person>
</feld>

[nein Herr Eversberg, das will niemand so speichern, wozu
haben wir denn - noch - Verknuepfungen]

Dieses Beispiel illustriert uebrigens noch ein anderes
Problem mit dem Weglassen von Interpunktion: Die von mir
konstruierte Ausdifferenzierung der Person ist ja nicht
Bestandteil von MABXML (und sollte es ja nicht sein, wie
ich hoffentlich ueberzeugend dargelegt habe). Wenn jetzt
eine Anwendung zwar MABXML spricht, aber nicht ein
hypothetisches PNDXML, wozu sie auch niemand verpflichtet, 
wird durch Auswerten der reinen Textinformation in Feld 100
ja wieder das bekannte:

<feld nr="100" ind=" ">Mueller, Peter</feld>

d.h. das ", " darf nicht implizit sein, sondern muss (das
ist eine Anforderung an "PNDXML") als Text vorliegen. Wir
haetten nun die Wahl zwischen vier Moeglichkeiten beim Design
von PNDXML:

1.) "Mixed Content" 
   <nachname>Mueller</nachname>, <vorname>Peter</vorname>
   unsere "traditionellen" Formate "koennen" soetwas nicht,
   in Ihrem Papier haben Sie aber auch darauf hingewiesen,
   dass Mixed Content und starke Kontrolle durch Schema bzw.
   DTD einander ausschliessen

2.) "Postfix"
   <nachname>Mueller, </nachname><vorname>Peter</vorname>
   Das waere der MARC21-Weg, der uns dort so stoert, hier
   allerdings abgemildert: Ich muss nicht am Ende von 
   "Nachname" nachsehen, um anhand des ", " erkennen zu koennen,
   was in "vorname" wirklich drinsteckt. 

3.) "Praefix"
   <nachname>Mueller</nachname><vorname>, Peter</vorname>
   irgendwie sauberer, sieht aber komisch aus: Nach unseren
   Orthographieregeln "klebt" ein Komma aber am vorangehenden 
   Text, man muss bei dieser XML-Formulierung also furchtbar
   aufpassen, hier nicht zusaetzlichen Leeraum an der falschen
   Stelle einzufuegen.

4.) "Infix"
  <nachname>Mueller</nachname><in9on>, </i9on><vorname>Peter</vorname>
   maximal kompliziert, aber ziemlich sauber.

Das Beispiel des hypothetischen PNDXML zeigt, dass man bei
allen Verfeinerungen von MABXML ueber Ihre Stufe 2 und MAB hinaus
 - und das betrifft m.E. alle von Ihnen so formulierten 
"strukturellen Abgrenzungen" - sich fuer einen von zwei
Wegen entscheiden muss: 
- Entweder es ist eine eXtension von MABXML Stufe 1, dann
  muss man zu Stufe 1 gelangen, indem man unbekannte Elemente
  ignoriert und durch ihren textuellen Inhalt ersetzt. In 
  diesem Fall muessen die "Strukturzeichen" jedoch mitgeschleppt
  werden, d.h. die Erweiterung transportiert das urspruengliche
  Strukturzeichen plus die Differenzierung durch Zusatzelemente
- Oder man gelangt "zurueck" zu Stufe 1 nur durch eine
  Transformation, Stufe-2-Daten koennen von Stufe-1-Software
  nur nach Vorbehandlung (durch ein Stylesheet natuerlich)
  verarbeitet werden.

viele Gruesse
Thomas Berger

----------------------------------------------------------------------
Zum Austragen aus dieser Liste senden Sie bitte eine Mail an
majordomo at ddb.de mit unsubscribe mab-list im Textfeld.