(Fwd) Re: [rak-list] (Fwd) Standard XML schema for MARC 21

[Thomas Berger]

Lieber Herr Eversberg,

> Nochmal:
> Wo das alte MARC dieses hat:
> 
> 260   $aNew York$bH. Holt$cc1988

Hm. Das ist aber doch schon bereits eine "Sicht" der
Dinge, naemlich fuer den Katalogisierer? Im Gegensatz
zu MAB ist MARC ja stets ein ISO-Format mit Directory
geblieben, d.h. den Bezug zwischen Feldern und Feldinhalten
kann man nur durch maschinelle Vorverarbeitung 
sichtbar machen.

> da sieht es mit XML so aus:
> 
> <datafield tag="260" ind1="" ind2="">
> <subfield code="a">New York :</subfield>
> <subfield code="b">H. Holt,</subfield>
> <subfield code="c">c1988.</subfield>
> </datafield>
> 
> K. Skalweit schreibt:
> > Und wieder stehe ich ratlos da und kann nicht
> > erkennen, was eine derartige XML-Struktur fuer
> > Vorteile bringen soll.
> Der Vorteil ist, dass Leute, die XML koennen, damit was machen koennen bzw. Daten
> in diese Form bringen koennen. Das alte MARC ist im Vergleich hoechst esoterisch.

Offensichtliche Vorteile sind:

- Man kann die Daten ohne Vorverarbeitung lesen
- Man kann die Daten uebermitteln (etwa per e-mail) ohne sich
  ueber Leitungsverluste wie Veraenderung von Spatien oder 
  Steuerzeichen Sorgen zu machen [nicht ganz: Es gibt einige
  Stellen in den AACR, die die Eingabe von Doppel- bzw.
  Dreifachspatien erfordern, bezeichnenderweise sind in den AACR 
  selbst (2nd Edition 1998) die Beispiele hierzu bis zur
  Unkenntlichkeit entgleist]
- Uebermittelt man die Daten komprimiert, wie man es bislang
  meistens tun musste, ist die Redundanz kein Problem
- Systemadministratoren werden mit Standardwerkzeugen einfache
  Standardanfragen beantworten koennen (etwa: "Gib mir alle
  Datensaetze mit 'New York' in field 260")
- Daten koennen auch offline erfasst und auf Konformitaet
  geprueft werden (eine MARC DTD gibt es ja auch seit
  laengerem, die Ankuendigung der LC bezog sich auf
  das MARC Schema)
- Man kann auch ein "$" aus der Vorlage katalogisieren
- Man kann sie (durch Einrueckungen und Umbrueche) noch
  lesbarer gestalten, ohne die Bedeutung oder Verarbeitbarkeit
  zu beeintraechtigen
- Durch geeignete Forformatierung bekommt man alleine durch
  weglassen der Tags (was ein HTML-Browser bei unbekannten
  Elementen sowieso tut) fast eine ISBD-Anzeige
- Durch jeweils (weltweit!) ein Stylesheet wird man solche Records
  in Kurzdarstellungen, ISBD-Darstellungen und was auch immer
  umwandeln koennen, und das ohne Bibliothekssystem: In nicht
  allzu ferner Zukunft denkbar ist also, einen recherchierenden
  Benutzer aus dem OPAC mit XML-Records zu versorgen, sein
  Webbrowser uebernimmt dann das Sortieren, Filtern und Anzeigen

> Der Verlust an verarbeitungstechnischer Effizienz ist zwar gewaltig, wird jedoch
> sehr vermutlich ignoriert oder in Kauf genommen werden. Bis jedoch alle die

Ich sehe nicht, wieso hoehere Redundanz (= Verlust an Entropie)
einen Verlust an "verarbeitungstechnischer Effizienz" bedeuten
sollte. XML ist "verarbeitungstechnisch" effizienter, weil
in groesserem Umfang Standardwerkzeuge zur Verarbeitung eingesetzt 
werden koennen und weil auf Veraenderungen eher auf der Ebene
des "Umschreibens eines Beschreibungstexts" reagiert werden kann
als durch "Umprogrammierung" (schlimmstenfalls durch den 
Softwarelieferanten). "Effizienz" ist zudem heutzutage eher
etwas, das in Ersparnis von Mitarbeiterstunden gemessen wird 
und nicht in Festplattenplatz.


> Verfahren und Programme, die jetzt mit MARC21 umgehen, auf XML umgestellt sind,
> wird noch viel Zeit vergehen, denn eine Umstellung laufender Dinge auf XML ist
> nichts anderes als eine Neuprogrammierung, und keine ganz einfache.

Zunaechst einmal ist es fuer real existierende Programme nur 
die Erstellung von Import- und Exportfiltern (die auch als
externe Programme zur Vor- bzw. Nachbearbeitung realisiert
werden koennen). Denn auch fuer XML gilt das, was fuer MAB und
MARC gesagt wurde: Es ist vornehmlich ein Austauschformat
fuer Daten (etwa auch zwischen Anwendungen auf einem Rechner)
und kein Internformat.

viele Gruesse
Thomas Berger