[mab-list] MABXML

Thu Sep 18 15:22:43 CEST 2003

Lieber Herr Stephan, liebe Liste,

> > dass man sich nun eine bessere Vorstellung machen kann, wie denn MAB
> > in XML konkret aussehen und was es fuer Vorzuege haben koennte.
> >
> 
> Genau Letzteres ist mir als Laien noch nicht gelungen. Waere es
> zuviel verlangt, hier um etwas Nachhilfe zu bitten.

[Die Antwort von Herrn Kett auf der MAB-Liste ist mir bekannt,
ich will aber auf die berechtigten Fragen "direkt" antworten,
ohne jeweils Stellung zur bereits erfolgten Antwort nehmen
zu muessen]

> Man kennt das ja von der HTML-Programmierung, dass es moeglich
> ist, Tabellenstrukturen in Tag-Strukturen umzusetzen. (Tag-Strukturen
> sind uralt. Mir sind sie zum ersten Mal Mitte der 80er begegnet, als es
> noch kein WORD gab, sondern WordStar.

Ich erinnere mich dunkel: Der Text wurde geschrieben und
Steuerzeichen davorgesetzt. Weil die Bildschirme nicht
graphisch waren (und es keine Maeuse gab), musste die
Formatierung symbolisch dargestellt werden, praktischerweise
dann so wie eingegeben. 

> Textverarbeitungsprogramme haben sich immer mehr von der
> Sichtbarkeit dieser Strukturierungshilfen verabschiedet. Etwas
> verbluefft war ich, diese simple Struktur mit dem Aufkommen des
> Internets in HTML-Codes wiederzuerkennen.)

HTML ist eine SGML-Ausformung, die syntaktischen Konstrukte
stammen also ebenfalls aus den 80ern. Zu beachten ist aber
m.E., dass es eben *nicht* der Ansatz ist, irgendwelche
Steuerzeichen (Escape-Sequenzen) in den Text einzubetten,
sondern ganz bewusst zwei Ebenen in den Textfluss zu codieren,
und zwar 1) mit minimalem Steuerzeichenaufwand und 2) "transparent":
2. bedeutet, dass auf der Textebene alle Zeichen erlaubt sind
(solche, die mit Steuerzeichen verwechselt werden koennen, 
muessen allerdings einheitlich escaped werden) und 1.) bedeutet,
dass eigentlich nur "<" das Steuerzeichen ist (und "&" kommt
dann schnell hinzu, wegen der Einfuehrung von Attributen dann
auch noch " und ', wegen der Symmetrie auch noch >.

Fuer die Maschine ist das ein ziemlicher Aufwand, weil sie
nicht nur nach Schluesselzeichen suchen muss (und evtl. einem
bis zwei Zeichen dahinter), sondern "echt" parsen muss.
Man kann allerdings, durch die nun erlaubten echten Schachtelungen
(und nicht nur "Fett an" ... "Fett aus") wesentlich komplexere
Sachverhalte codieren.

> Die Lesbarkeit der Tabelle fuer das meschliche Auge leidet drastisch.

Tabellen sind zweidimensional, Text ist eindimensional.
Eine lesbare Tabelle ist Text (Inhalte) plus Strukturinformation
plus Visualisierung. Menschen moegen es, wenn die Struktur
offen-sichtlich ist, d.h. aus der Visualisierung erschlossen
werden kann. Maschinen moegen das nicht so sehr, obwohl
OCR-Software inzwischen halbwegs gut im rekonstruieren solcher
Information geworden ist.

> Herrn Ketts Behauptung, es sei gerade anders herum, kann ich nur
> unter der Voraussetzung nachvollziehen, dass die Tabelle nur als
> String dargestellt wird (wie z.B. im Allegro-Rohformat).
> 
> Aber geht es hier um Verbesserung der Lesbarkeit fuers menschliche
> Auge? Wohl kaum. Es geht doch wohl eher um bessere maschinelle
> Verarbeitbarkeit bibliographischer Datensaetze.

Die beiden Positionen sind etwas miteinander verzahnt:

MAB ist sehr wenig menschenlesbar. Weil niemand mit
Roentgenblick auf Baender und Festplatten schaut, ist
das schon ein Lesbarkeitsbegriff, der "die ueblichen
Lesehilfen" miteinbeziehen muss, also die Bordwerkzeuge,
die jeder hat (Texteditor). MAB-Daten sind wegen der
nur Spezialanwendungen bekannten Zeichencodierung und
wegen des Verzichts auf Zeilenumbrueche in einem
normalen Editor fast unlesbar (MARC-Daten wegen des
ISO-Directories ueberhaupt nicht). Um eine Aussage
ueber MAB-Daten machen zu koennen, muss man sie entweder
in ein Bibliothekssystem seiner Wahl einspeisen (was
oft keine Routineangelegenheit ist), oder sich "ein
kleines Tool" schreiben, das irgendeine Umsetzung 
veranstaltet. Schon im "Bibliothekswesen" ist dieser
Umstand ernsthaft behindernd (es gibt weniger Daten-
austauschspezialisten als Datenaustaeusche, staendig
gibt es Rueckfragen, und wenn etwas schief laeuft,
muss man immer in Tabellen nachsehen, ob Zeichen richtig
codiert sind, weil man das ja nicht "sehen" kann.
Kommunikation von MAB-Daten "aus dem Bibliothekswesen
hinaus" ist kaum moeglich, schliesslich sind die
Standards nicht komplett online, nicht im Buchhandel
erhaeltlich, nicht in Standardsoftware beruecksichtigt
etc. 

MAB-Diskette war da viel angenehmer, heutzutage haben
aber die meisten Bordwerkzeuge auch mit dem dabei
eingesezten DOS-Zeichensatz Probleme (nicht Notepad,
sonder Wordpad nehmen, nicht oeffnen, sondern oeffnen
als, Option xy in Word'97 umstellen, dann gehts),
immerhin wird cp850 von allen Microsoft-Betriebssystemen
noch aktiv unterstuetzt, Konkordanzen sind auch in
nichtbibliothekarische Werkzeuge eingebaut. MAB-Diskette
hat aber den Nachteil, einen nicht-bibliothekarischen
Zeichensatz zu nutzen, hier ist Informationsverlust
eingebaut. Dasselbe gilt fuer das nie spezifizierte
MAB der DB-CD-ROM-Anwendungen, dort gibt es MAB-Felder,
der Zeichensatz ist Latin 1, also ein Windows-Zeichensatz.
Dieses MAB ist am besten "lesbar", nur das Teileldzeichen
ist ein unspezifisches "Kloetzchen", aber auch nicht
bibliothekarisch.

MAB in Unicode-Codierung (also UTF-8) ist mit notepad
unter Windows XP gut lesbar (bis auf die Steuerzeichen
halt, die man teils nicht sehen kann und andernfalls
erklaert bekommen muss)

Die "bessere maschinelle Verarbeitbarkeit" ist etwas
schwammig formuliert: XML ist fuer eine Maschine nicht 
besonders effizient: Nicht nur der Speicherplatzbedarf,
auf den Herr Eversberg unermuedlich hinweist, den
man ja durch Kompression weitestgehend neutralisieren
kann, sondern vor allem das Parsen von Daten ist sehr
aufwendig, wenn man es z.B. mit CSV-Tabellen vergleicht
(die sind aber auch ganz schoen widerlich zu parsen).
Weil aber XML als Geruest so viele unterschiedliche
Situationen abdecken kann, lohnt sich immerhin der Aufwand,
Programme zu schreiben, die XML universell verarbeiten 
koennen (und fuer MAB-Daten lohnt sich der Aufwand
nicht, hier bastelt jeder seine Tools gerade so weit,
dass die konkreten Anforderungen abgedeckt werden).
Heutzutage ist es so, dass man staendig irgendwelche
Daten erstmalig oder einmalig verarbeiten will, zumindest
ausserhalb der Bibliothekswelt ist das Paradigma, dass
man eine Anwendung mit in Erz gegossenen Standards hat
und auf dieser Grundlage jahrzehntelang "Daten tauscht",
nicht sehr realistisch. Fuer die Programmierung von
Import- und Exportfiltern, gerade fuer adhoc-Konversionen,
ist es nun ungemein hilfreich, a) die Daten "unbearbeitet"
"sehen" zu koennen und b) ein "Swiss army knife" zu haben,
also ein universelles Werkzeug, das man auf die konkrete
Situation leicht einstellen kann. Perl und andere
Skriptsprachen sind deshalb so populaer, weil die Verarbeitung
zwar die Maschine mehr belastet, die Programmierer aber
schneller arbeiten (codieren und vor allem testen) koennen.
Die Vorteile von Markup-Sprachen zur Datenbeschreibung sehe 
ich genauso.

Im Zeitalter des Outsourcing erreichen mich immer haeufiger
solche Anfragen (leicht ueberzeichnet):
Q: Koennen Sie die Daten als Tabelle exportieren?
A: Nein, das sind bibliothekarische Daten, es gibt 1000
   Datenfelder, die sind fast nie belegt, aber alle
   auch noch wiederholbar, die Saetze sind untereinander
   verknuepft, es gibt Normsaetze und Verknuepfungen, 
   schwierig schwierig...
Q: Das sehen wir ein. Geht dann ein Export als XML?
A: Leider noch nicht. Aber die Daten sind eigentlich ganz
   einfach strukturierter Text, es gibt vier Steuerzeichen
   und ich kann Ihnen eine Liste der Feldnummern und der
   Bedeutungen schicken
Q: o.k.
Wochen spaeter dann
Q: Wir koennen die Daten nicht lesen, sind die Umlaute
   kaputt? Wo fangen eigentlich die Datenfelder an, wo
   hoeren sie auf?
A: Tja, das ist ein bibliothekarischer Zeichensatz, von
   der ISO normiert, online gibt es das natuerlich nicht,
   das muss man kaufen, so finanziert die ISO sich. Ich
   koennte Ihnen unter der Hand eine Fotokopie schicken.
Q: am besten, wir drucken die Sache aus der Anwendung
   heraus aus und scannen es dann ein. Alles andere kostet
   zu viel Zeit, schliesslich hat die Datenbank-Anwendung,
   in die es geht, sowieso nur vier Felder.

Eine XML-Repraesentation bibliothekarischer Daten loest
meiner Meinung nach mindestens folgende Probleme:

- Lesbarkeitsprobleme wegen traditioneller Zeichencodierung
  und "origineller" Steuerzeichen
- Transportprobleme (beim Einbetten in e-Mail weiss man
  nie so recht, wer wo welche Ersetzungen vornimmt oder
  Leerraum spendiert / wegnimmt, Zeilen abschneidet etc.,
  d.h. man zip't es am besten und schickt es als Attachment)
- Trennung von Struktur und Daten (MARC benutzt ja wirklich
  nur Control-Codes, MAB als Epigone nutzt Textzeichen als
  zusaetzliche Steuerzeichen)
- Verarbeitungsmoeglichkeiten ausserhalb der Bibliothekswelt

viele Gruesse
Thomas Berger

The computer should be doing the hard work. That's what it's paid
to do, after all. -- Larry Wall in 199709012312.QAA08121 at wall.org
----------------------------------------------------------------------
Zum Austragen aus dieser Liste senden Sie bitte eine Mail an
majordomo at ddb.de mit unsubscribe mab-list im Textfeld.