[Allegro] Das Neutralmodell - Eine Projektidee

[Bernhard Eversberg]

Das Neutralmodell - Ein Projekt für V26!?
-----------------------------------------

Hier werden Überlegungen mitgeteilt, die schon seit einiger Zeit
intern bewegt wurden und sich ganz allmählich zu Formulierungen
verdichtet haben.
Diese Mitteilung soll erst einmal nur ein Meinungsbild erbringen!
Gibt es tatsächlich Bedarf für das, was hier beschrieben wird?
Äußerungen jeder Art sind dazu ausdrücklich erwünscht.

allegro-C ist kein auf Bibliotheksanwendungen festgelegtes System,
sondern ein konfigurierbares Datenbanksystem. Das bedeutet: man hat
die Freiheit, neue Datenmodelle zu konfigurieren und damit dann neue,
eigene Anwendungen zu parametrieren. Die Möglichkeiten sind jedoch
so vielfältig, daß solche Unternehmungen zwangsläufig schwierig werden.

Das meistverwendete Datenmodell unter allegro ist das sog. A-Schema.
In der Konfigurationsdatei $A.CFG stehen die Definitionen der Daten-
felder, die man verwenden kann. Die Parameterdateien der Typen .APR,
.API und .APT beziehen sich alle auf dieses Schema.
Solange man mit allegro "nur" Bibliotheksanwendungen der gängigen
Art realisieren will, bleibt das A-Schema die erste Wahl, weil die
dafür entwickelten Parameter sehr differenziert und ausgereift sind,
bis hin zu den Geschäftsgängen Ausleihe und Erwerbung.

Wer nun aber andersartige Projekte realisieren möchte, muß immer erst
ein neues Schema dafür erfinden (eine CFG-Datei) und dann die zugehöri-
gen Parameter und sonstigen Zusatzdateien erstellen. Das ist sehr viel
komplizierte Arbeit und nicht jedermanns Sache. Bisher kann man zwei
Wege beschreiten, wenn man nicht komplett alles selber machen will:

1. Eins der Minimalmodelle hernehmen und ausbauen
    (Im Schreibfeld eingeben:  h mini )
    Nachteil: Viel Arbeit mit den Parametern, weil man sie zum großen
              Teil selber schreiben muß.

2. Das Standardschema hernehmen, oder ein anderes schon existierendes
    Schema, z.B. das für "bolero" oder "HANS") und dann modifizieren.
    (Im Schreibfeld eingeben:  h newdb )
    Nachteil: Standardparameter modifizieren ist schwierig, weil sie
              sehr umfangreich und komplex sind. Und eine Menge Ballast,
              wenn man nur ein viel einfacheres Schema braucht!

In beiden Fällen sind leider eingehende Kenntnisse der Exportsprache
unverzichtbar.

Bedarf besteht daher wohl für eine Lösung, die zwar schon möglichst
vieles bereitstellt, aber sich immer noch leicht durchschauen und
modifizieren läßt. Ein Paket wäre zu entwickeln, mit dem man
erheblich schneller zu einer neuen, eigenen Anwendung gelangen
kann. Dieses Paket könnte man "Neutralmodell" nennen.


Zielvorstellungen
-----------------
Das Neutralmodell muß man sich folgendermaßen vorstellen:

1. Die Konfiguration N.CFG definiert eine Reihe von Datenfeldtypen,
    die regelmäßig in Datensystemen auftreten: Titel, Personennamen,
    Datumsfelder, Schlagwort- und Klassifikationsfelder, Nummern,
    Anmerkungen, Codes usw.
    Als Grundlage eignen sich die DCMI Metadata Terms, denn die Dublin
    Core-Initiative hat damit einen Grundbestand von Datenelementen
    definiert, an dem sich viele Metadaten-Produzenten orientieren.
    Zahllose Expertisen und Erfahrungen sind hier eingeflossen.
    Siehe:  http://dublincore.org/documents/dcmi-terms
    [Anm.: DC ist kein Kategorienschema! Sondern nur eine Liste
           von Datenelement-Definitionen.]

2. Die Indexparameter  BANK.NPI  sorgen für eine sachgerechte
    Indexierung aller dieser Datentypen. Einbau weiterer Felder
    in die Indexierung sowie das Verändern der Zuordnung zu
    den einzelnen Registern erfordert dann nur noch minimale
    Exportsprachen-Kenntnisse: normalerweise nur das Einfügen
    eines neuen ak-Befehls nach einem vorgegebenen Muster.

3. Musterhafte Exportparameter (*.NPR, *.APT) leisten eine brauchbare
    Anzeige bzw. Ausdruck und Export der Daten. Auch hierbei sorgt
    eine Modularisierung dafür, daß erweiternde und modifizierende
    Eingriffe nur noch wenige Kenntnisse erfordern. Ein Beispiel für
    so etwas sieht man bereits in den Musterparametern für die
    Anzeige: d-s.apt (für DOS, Windows, HTML geeignet).

4. Hilfetexte werden zu jedem einzelnen Element erstellt und können
    jeweils bei der Eingabe mit F1 abgerufen werden (H-Dateien).

Als Zeichensatz sollte man wahlweise OstWest oder Windows-ANSI
einsetzen können. [Vielleicht von vornherein nur letzteres? Unicode
wäre unpraktisch: es würde das Katalogisieren nur mit der
Web-Oberfläche gestatten!]

Die hier angedachten Parameter erledigen also schon viele Aufgaben in
sachgerechter Weise. Das Modifizieren wäre dank der Strukturierung
und Kommentierung dieser Dateien erheblich leichter als bei den
Standardparametern bzw. beim Erstellen ganz neuer Parameter:
Zuerst sucht sich der Anwender die für sein Projekt geeigneten
Elemente heraus. Ergänzen und modifizieren muß man nur, wenn es
dann noch untypische Elemente gibt, die sich im Standard nicht
zuordnen lassen.
Die Arbeit würde sich oft darauf reduzieren, die Feldbezeichnungen
zu modifizieren! Die Verarbeitung der Felder für die Indexierung
und Anzeige etc. würde durch die Parameterdateien schon abgedeckt,
auch die Skripte und Parameter für die Web-Anbindung mit der
PHP-RuckZuck-Methode wären schon vorhanden.
Die Konfiguration sollte in plausible Abschnitte gegliedert sein
und in jedem Abschnitt Erweiterungsmöglichkeiten bieten sowie
natürlich Hinweise zur möglichen Verwendung der einzelnen Feldtypen.

Summa summarum soll der Anwender insbesondere dann so gut wie
keine Arbeit haben, wenn ein Modell auf dem Niveau des
Dublin Core gebraucht wird. Dieser gilt ja, etwa im Kontext
der Open Archives Initiative, als so etwas wie ein gemeinsamer
Nenner vieler unterschiedlicher Datensysteme! Aber auch, wer mehr
braucht, wird eine Abwärts-Kompatibilität zu DC gern in Kauf nehmen.
Jedes DC-Element sollte folglich genau einer Kategorienummer
im neu zu erstellenden Format entsprechen. Weitere Kategorien
ergänzen das DC-Minimalmodell. Die DC-Dokumentation nennt jetzt
selber schon etliche weitere Elemente:
    http://dublincore.org/documents/dcmi-terms/


Nebenbemerkungen und Ausblick
-----------------------------
Zuerst müßte der Punkt 1 erledigt werden, also die Aufstellung
eines vielseitigen und ausbaufähigen, logisch stimmigen und
ökonomisch gut durchdachten Kategorienschemas. Dessen Struktur
muß z.B. bereits mit dem Blick auf die Erfordernisse und
Möglichkeiten der Indexierung und Präsentation gestaltet werden.
Keine ganz leichte Aufgabe also, aber es liegen ja vielfältige
Erfahrungen und theoretische Grundlagen vor.
Am oberen Ende könnte evtl., wenn die Sache gut gelingt, das
A-Schema eines nicht so fernen Tages abgelöst werden durch ein
entsprechend weit ausgebautes Neutralformat! Einen Export
von A nach N müßte die Entw.Abt. in jedem Fall unterstützen.
Gut bedient wären dann auch diejenigen, die zwar den Umfang
von A brauchen, aber an seiner Komplexität verzweifeln.
Dies jedoch ist nicht das Hauptziel des Projekts, es wäre ein
nützliches Nebenergebnis!

Denkbar wäre natürlich auch, am A-Schema ein paar Begradigungen
vorzunehmen, historisch gewachsene Knorrigkeiten auszumerzen
und dergl. Ein paar Ergänzungen, um die Vielseitigkeit zu
erhöhen. Dann aber neue, modulare und übersichtliche Index-
und Anzeigeparameter, und man hätte fast dasselbe wie ein
neues Neutralmodell. Oder doch nicht? Immerhin war das
A-Schema bereits zur Version 13 einmal gründlich bearbeitet
und aufgewertet worden und erhielt dann die Bezeichnung
"Konsolidiertes Format":
   http://www.allegro-c.de/news/acn931.htm

Oder man wird fragen: Warum nicht MARC21, das ist doch sowieso
im Kommen? Nun, MARC ist sehr tief in der Struktur der alten ISBD-
Katalogzettel verwurzelt. Dies zu perpetuieren und dann auch
noch als Grundstruktur für möglicherweise ganz andere, nicht-
bibliographische Datensysteme hinzubiegen (und das ist ja hier
das Thema!), das wäre ein zu wenig innovativer, viel zu stark
am Überkommenen klebender Ansatz.
In den USA sind alle Bibliothekare mit MARC aufgewachsen und jeder
ist damit vertraut, jede Software ist darauf geeicht - das sind
andere Gegebenheiten! Dennoch entstand DC, welches sich bewußt
von MARC abgrenzte und keine Ähnlichkeit damit hat, obwohl auch
Bibliotheksleute daran mitgewirkt haben.