Bloss eine Idee

[Thomas Berger]

Lieber Herr Henkel, lieber Herr Hoeppner,

> XML als internes Datenbankformat hat div. Nachteile:
> 
> Start-Tags und End-Tags nehmen unnötig Platz weg. In dieser
> Hinsicht sind wir sehr eigen ;-) Sie bringen für die automatische
> Verarbeitung nichts, wenn man das Format kennt.

Naja: Immerhin ermoeglichen sie gewissen Sachverhalten
angemessene Schachtelungen bzw. Gruppierung von Information.
allegro hingegen Krampft mit hierarchischen Saetzen,
wiederholbaren Feldern, Teilfeldern, wiederholbaren
Teilfeldern und einem Zoo von Wiederholungszeichen
(" ; ", " * ", "¶" etc. je nach Anwendung) von denen
einem ganz schlecht wird, wenn man darueber nachdenkt,
ob in einer Kategorie mit Unterfeldern jetzt die
Trennzeichen eine Wiederholung auf Kategorielevel oder
auf Teilfeldlevel bedeuten. Darueber hinaus werden
ja gerne indexierungsrelevante Teile mit "{...}" ein-
oder mit Nichtsortierzeichen ausgeklammert, und die
Tatsache, dass man sich bei v14-Verknuepfungen dafuer
Entscheiden muss, entweder die Identnummer oder den
Text zu sehen, bzw. sich mit "_..._..._" ganz besonders
abscheulich geklammerte Sub-Inhalte einzufangen, ist
auch vom feinsten.
Jedenfalls sind die Kategorieanfangszeichen mit den
Nummern sowie die Teilfeldzeichen mit den Teilfeldkuerzeln
und darueber hinaus die diversen Strukturierungs- und
Klammerungszeichen oeffnende "Tags" fuer die jeweiligen
Elemente des Datensatzes, die schliessenden Tags der
Elemente sind normalerweise implizit, was dann bei
komplizierter Schachtelung schnell in Unsinn, Chaos oder 
beides fuehrt.

 
> Ein Datenbank als XML-Datei ist von der Struktur her ein _sehr_
> flacher Baum. XML-Programme, insbesondere Validatoren müssen
> sich die ganze XML-Datei reinziehen, damit sie die Syntax
> überprüfen können. Z.Zt. ist das jedenfalls so. Bei kleinen
> Datenbanken keine Problem, wenn Sie es mit 2,6 Mio. oder so
> Datensätzen zu tun haben, schon. Für einen PC ist das nix mehr.

Vorteil von XML (im Gegensatz zu SGML) ist ja unter anderem
auch, dass man eine Datenbank hat, in der die einzelnen
Records XML-Records sind, ohne dass nun alles eine 
formal spezifizierte, uebergreifende Struktur hat. Insofern
ist man also nicht darauf angewiesen, DTDs fuer Indexlisten
und Gesamtzusammenhaenge zu entwickeln. Ausserdem kann
man einzelne Records bearbeiten, ohne die ganze Datenbank
als "Dokument" betrachten zu muessen.
Bezuege zwischen Datensaetzen sind in XML nach meinem
Verstaendnis genauso explizit zu verstehen, wie in 
allegro-Datensaetzen: Man traegt eine Identnummer oder
einen Link ein und hofft auf die Software, die eine
geeignete Navigations- oder Nachlade/Zusammenanzeige-
Funktionalitaet bereitzustellen hat.

 
...
> nichts, Das Problem, aus den Grunddaten eine formatierte ISBD-Anzeige
> beispielsweise mit korrekter(!) Zeichensetzung hinzubekommen, bleibt.
> Wem da ein Bibliothekar im Nacken sitzt  und wer selbst nichts von RAK
> etc versteht, dem nützt XML auch nichts. Der größte Teil der Arbeit
> steht ihm oder ihr noch bevor. Da ist das Lernen der allegro-Struktur
> ein Klacks.

Man hofft dabei immer auf den uebernaechsten Standard der
Style-Sprachen. Am Rande waere es natuerlich nett, die
Exportsprache von allegro ueber Bord zu werfen ,vorausgesetzt
es gibt etwas allgemeingueltigeres, was dasselbe kann...


> > M.E. müßte sich gar nicht so viel ändern :-). Auf den Index wollen
> > wir wohl alle nicht verzichten. "Nur" der Teil, der in irgendeiner
> > Weise das interne Satzformat betrifft, sähe anders aus.
> 
> D'accord. Nur vom kompakten Satzformat gehen wir nicht ab.

und XML kommt diesem ziemlich nahe.
Jedenfalls sind bibliothekarische Daten mit Kategorienummern
genau wie einzelne XML-Records kurze bis mittellange Texte,
die fuer sich gespeichert und zugreifbar gehalten werden sollten.
Ob jetzt pro Satz 100 Bytes mehr fuer Schliessende Tags 
benutzt werden oder nicht, ist m.E. voellig egal. Der 
Unterschied liegt fast nur darin (wie oben angesprochen),
dass bibliothekarische Kategorienschemata eben doch nur
eine vielleicht drei- oder vierdimensionale Tabelle 
(mit Speichertechnik von sog. duennen Matrizen), XML-Records
aber in sich baumartig sind.

> Unsere Datenbank wird im normalen Dateisystem gespeichert und
> da ist eine kompakte Speicherung fast gleichbedeutend mit
> schnellem Zugriff, weil kein Platz verschwendet wird. Wer jetzt
> einwendet, dass die großen Datenbankhersteller ja auch alle XML
> als Datenbankformat einsetzen wollen, dem sein gesagt, dass es
> imme noch so ist, dass Datenbanken, die einen hohen Durchsatz
> erfordern auf sog. Raw-Devices angelegt werden. Das sind Platten, die
> _nicht _ formatiert sind. Die Ablage der Daten organisiert dann das
> Datenbankmodul komplett selbst. An diese Daten kommt man mit normalen
> Programmen nicht ohne weiteres ran, weil das Betriebssystem sich
> meistens sperrt, wenn es um den Zugriff auf eine unformatierte Platte
> geht. Ich bezweifele auch, dass dort XML- gespeichert wird, wegen der
> Platzverschwendung. Vielmehr bieten die eine Schnittstelle, die aus
> den Daten XML als ein Exportformat machen. Aber genau das geht mit
> allegro jetzt auch schon.

Nicht jedes XML-Format, s.o. Andersherum natuerlich: Jedes
allegro-Format und jeder "Record" aus einer relationalen 
Struktur laesst sich natuerlich in XML abbilden und 
(auch extern) bearbeiten.
 
> > Auch vom Umfang her, würde nicht viel dazu kommen, zumal man ggf.
> > beim Schreiben komprimieren und beim Lesen dekomprinieren könnte -
> > XML sind ja reine Texte.
> 
> Gut, aber dann haben Sie sich gerade fast widersprochen, denn
> dann haben Sie ein internes unsesbares Format, das man nur mit
> geeigneten Programmen lesbar machen kann. Wer die Codierung
> nicht kennt und die Programme nicht hat, ist aufgeschmissen. XML macht
> ja gerade jeder, weil die Daten dann noch für einen Menschen lesbar
> sind. Da ist das allegro-Internformat mindestens genau so gut.

... weil fast dasselbe. 

 
> > Probleme, die absehbar sind: Z.B. Durch was wird die jetzige
> > Satznummer ersetzt, das heißt, das Bindeglied zwischen TBL und
> > Index?
> 
> Im Index steht hinter einem Eintrag die logische Satznummer. In der
> TBL steht dazu der physikalische Offset in einer Datei und damit
> positioniert dann das Programm in der Datendatei. Mit der XML- Datei
> kann man sich die TBL vielleicht sparen, wenn jeder Datensatz seine
> eigene Nummer hat. Die XML-Parser bisher müssen allerdings bei der
> Suche nach einem bestimmten Element mit einer bestimmten Id den Baum
> von Anfang an durchsuchen - jedenfalls, soweit ich informiert bin.
> Vielleicht gibt es ja bessere Möglichkeiten.

Die allegro-Speichertechnik ist fuer XML-Records hervorragend
geeignet. Es gaebe interne Satznummern fuer den Zugriff durch
das System und logische Primaerschluessel, um Saetze aus
dem System ein- und austragen zu koennen und Verknuepfungen
zwischen Saetzen zu realisieren.
Nicht so einfach loesbar ist mal wieder das Problem (auch bei a99),
in einem gewissen Sinne zusammengehoerende Saetze (Titel + Normsatz,
Titel + Baende, Titel + Gesamttitel, Titel + Satz zum spaeteren
Titel etc.) vernuenftig zu praesentieren, insbesondere im
Zusammenhang mit der Dateneingabe :-(

 
> Wie könnten allegro-Daten in XML aussehen? Weiß ich noch nicht
> genau. Ein Vorgeschmack bietet aber MARC SGML. Die DTDs
> kann man sich von www.loc.gov/marc/ herunterziehen. Und wenn
> ich an das PICA-Format oder HANS in diesem Zusammenhang
> denke, wird mir ganz anders.

Im Rahmen von MALVINE (http://www.malvine.org/) wurde
ein bibliothekarisches Datenformat als XML fast "neu" entwickelt.
Fuer das Projekt gibt es dann Konversionsskripte, die 
HANS-Daten, SGML-Daten (TEI?), MARC-Daten etc. der
verschiedenen Teilnehmer umwandeln.
Es scheint (wie auch bei den Ueberlegungen zu RDF), dass XML 
hier wesentlich "natuerlicher" geeignet ist, die vorliegenden
Sachverhalte abzubilden, als es etwa ein Aufbohren von MAB
oder USMARC dargestellt haette.

viele Gruesse
Thomas Berger