24.11.05 / 1.12.05 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 ----------------- 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. Exportparameter e-neut.apr wandeln A-Daten in N-Daten um. Dies ist schon in der ersten Phase nötig, damit man die Brauchbarkeit des neuen Formats im Vergleich zu einem bewährten Schema beurteilen kann: die "alten" Daten sollten sich ohne inhaltlichen Verlust im neuen Schema wiederfinden. 3. 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. 4. Musterhafte Exportparameter (*.NPR, *.NPT) 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.npt (für DOS, Windows, HTML geeignet). 5. 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. Und was ist mit UNIMARC? Es ist zwar viel besser logisch gegliedert als MARC21 oder auch MAB. Doch es hat erstens zu viele Nummern für gleichartige Inhalte (z.B. Titel, Fußnoten, ...), zweitens aber (wie auch bei MARC und MAB) gibt es mehr als ein UNIMARC: z.B. eines für Titeldaten und eines für Namens-Normdaten. Für ein Austauschformat ist das in Ordnung, für ein Arbeitsformat ist es jedoch wenig praktisch. Und drittens hat jedes Feld, auch wenn sein Inhalt weiter nicht gegliedert ist, vorn immer den Subfield-Code $a (wie MARC21). Das ist nutzlose Redundanz. Und was ist mit FRBR? Dessen Grundgedanken werden aufgegriffen und umgesetzt! Man wird die darin angedachten "Entitäten" abbilden und die Vorstellungen über Work - Expression - Manifestation - Item realisieren können. Wir übersetzen das jetzt übrigens so: Werk - Fassung - Version - Exemplar Für die erste Bereitstellung werden auch einige Daten erstellt, und zwar aus der DemoBank, aus "bolero" und aus "CoOL", um dabei schon gleich die Anwendbarkeit zu testen. Es wird ja auch sofort alles viel klarer, wenn man Beispiele sieht! Und wir erreichen ein besseres Gefühl, ob denn der Entwurf tragfähig ist. Folgende Grundsätze haben sich in der Diskussion herausgebildet: 1. Dreistellige Feldnummern (t3/k5). Die Feldgruppen 0 bis 9 haben jeweils einen übergeordneten Sinn. Feldnummern haben überwiegend eine 0 an dritter Stelle, um Erweiterungen zu erleichtern, es kommen aber auch Buchstaben an Position 3 vor, wenn dort die Ziffern voraussichtlich zu knapp sein könnten. Die Buchstaben sind dann mnemonisch gewählt. Jedes Feld erhält einen deutschen und einen englischen Kurznamen, der nur aus Buchstaben besteht. Dies ist zwar nicht funktional notwendig, aber nützlich. 2. Feldwiederholung: Jedes Feld ist wiederholbar, wenngleich dies nicht bei jedem Feld sinnvoll ist. Empfehlung: Ziffern 0 ... 9 verwenden. Statt mit Wiederholzeichen hinter der Feldnummer auch möglich mit Hilfe von | oder ; als Trennzeichen innerhalb des Feldes. Unterfelder können jedoch nicht auf diese Weise mehrfach besetzt werden, nur komplette Feldinhalte! Wer Unterfelder strukturieren will, muß sich dazu andere Steuerzeichen ausdenken. 3. Unterfelder: Nur wo unabweisbar zur Strukturierung eines Inhalts nötig. Insbes. kein generelles $a am Feldanfang, wie bei MARC üblich. Der Hauptinhalt hat folglich generell keine Unterfeldkennung. Unterfelder werden mit dem bekannten Dreieck (Code 31 unter DOS, 178 unter Windows) eingeleitet, wie schon in A.CFG. Eingabe in DOS mit Strg+-, in Windows mit AltGr+2 4. Der Unterstrich bleibt V14-Ersetzungscode, was allerdings problematisch ist, weil er auch in URLs vorkommt. Dort muß er dann durch %5F ersetzt werden. 5. Als Nichtsortierzeichen dient ` (Code 96) 6. Erweiterbarkeit: In jeder Feldgruppe bleibt die Ziffer 9 frei für Erweiterungen des Anwenders: #09x, #19x, #29x ... #99x 7. Nur Kleinbuchstaben werden für Wiederholung und Unterfeldkennungen definiert, Ziffern noch nicht. Großbuchstaben sind aber möglich, sie bleiben frei für den Anwender. 8. Der Umfang des Standardformats A.CFG soll möglichst vollständig abbildbar sein. Dazu werden dann auch Exportparameter bereit- gestellt, womit man sich größere Mengen von Testdaten leicht präparieren kann. Die Datei E-NEUT.APR konvertiert "normale" A-Daten, aber auch bolero- und CoOL-Daten. 9. Normdaten erhalten eigene Kategorienummern, die mit dem Buchstaben n beginnen: #n00, #n10, ..., #n90. Anwender haben damit ganz klar erkennbare Möglichkeiten: a) Standardkonfiguration soll völlig unverändert bleiben, man muß nichts herausnehmen oder umdefinieren. (Was man nicht verwendet, braucht weder Platz noch Leistung!) b) Eigene Erweiterungen bleiben klar erkennbar. Eigene Felder müssen sich nicht an 1. und 2. halten! Es sind auch Feldbezeichnungen mit Ziffer + Buchstabe möglich, die im Standard auch in Zukunft vermieden werden sollen (außer Gruppe #9) Übrigens: In der CFG müssen die Felddefinitionen nicht in numerisch aufsteigender Reihenfolge stehen! Will man in der Internanzeige eine bestimmte Reihenfolge der Felder sehen, braucht man nur in der CFG die Felddefinitionszeilen in dieser Reihenfolge anzuordnen. Das kann jederzeit, auch im laufenden Betrieb, geschehen. Ab dem nächsten Start zeigen die Programme die Datenelemente in der eingestellten Reihenfolge.