[Allegro] Wie ist der Bedarf für ein Expertentreffen 2012?

[Thomas Berger]

Lieber Herr Eger, liebe Liste,

> Wäre vieleicht ein wichtiger TOP:
> - was genau macht das "allegro" aus
> - was daran _muss_ stabil/kompatibel gehalten werden
> 
> Wenn das für alle verbindlich festgelgt ist, sollte es keine Probleme
> hinsichtlich der Kompatibilität geben.
> 
> Die Trennung von stabilen, gemeinsam genutzten und verbindlichen 
> Kernfunktionen auf der einen und den verschiedenen Parametrierungen auf 
> der anderen Seite muss schon gewährleistet bleiben.

Ich hatte - obwohl abstrakt formuliert - eigentlich eher konkrete
Entscheidungen im Sinn gehabt, die jeder fuer sich aufgrund (wahrgenommener
oder deklarierter) Weichenstellungen fuer die Zukunft trifft.

Ein Beispiel waere z.B. das Thema "allegro und Unicode", wo ja eigentlich
unabhaengig vom konkreten Kategorienschema ueberall dasselbe zu tun ist
und die diversen ~Moeglichkeiten~ von allegro v23 (VB 163/164) eben nur
Moeglichkeiten sind, wo man sich "die Standardanwendung" wuenschen wuerde.
Hier wuerden wahrscheinlich alle gerne moeglichst frueh wissen, wohin die
Reise geht (insbesondere welche Unicode-Unterstuetzung die Kernprogramme
irgendwann einmal haben werden, die bislang nicht Zeichen-, sondern
byteorientiert sind), um eigene Entwicklungsanstrengungen daran auszurichten.

Ein anderes Beispiel ist die von mir letztes Jahr angeschnittene GND-
Problematik (vgl. das leider nur kurz andiskutierte
< http://sun250.biblio.etc.tu-bs.de/pipermail/allegro/2011-June/033626.html >):
* Alle existierenden Normdatenschnittstellen werden ab dem 19. April 2012
  Makulatur sein. Punkt.
* Alle PICA- und Aleph-Verbundsysteme haben ihre lokalen (genauer also: die
  regionalen) Normdateien bereits abgeschafft (2011 wurden einige Millionen
  Normsaetze offline in die PND migriert) und arbeiten ab dem Stichtag mit
  einem neuen Internformat fuer Normdaten, das auf den Feldnummern fuer
  MARC-Authority beruht (fuer andere Satzarten nutzen diese Systeme weiterhin
  die bisherigen "PICA3"- bzw. "MAB"-Feldnummern), diese Systeme *muessen* (wg.
  Online-Normschnittstelle) die GND ja absolut treu nachbilden koennen
* Fuer Lokalsysteme in Verbuenden ist in puncto "Versorgung" (d.h. Fluss
  von Normdaten aus dem Verbund in die Lokalsysteme, keine Unterstuetzung
  fuer im Verbund nicht nachgewiesene "lokale" Normdaten) folgendes
  geplant (siehe auch
< http://www.bib-bvb.de/sisis/tips/papers/GND-Szenario_11-2010.pdf >:
  - Aleph-Lokalsysteme haben sowieso keine Normdaten
  - Sisis-Lokalsysteme: Es bleibt kurzfristig bei drei getrennten "Normdateien"
    und es gibt MARC21-Importschnittstellen, die aus einem Normsatz der
    GND dann "PND"+"SWD" bzw. "GKD"+"SWD" etc. simultan bedienen
    (inwieweit die internen Felder fuer die GND-Einfuehrung erweitert wurden,
    ist mir nicht bekannt).
  - aDIS|BMS-Lokalsysteme (BW): ???
  - PICA-Lokalsysteme: (m.W. betrifft das nicht die "LBS", sondern CBS-
    Installationen "unterhalb" des Verbundsystems). Von der Regionalbiblio-
    graphie M-V weiss ich z.B., dass sie "lokale Normdaten" hat, die in der
    Verbunddatenbank vorgehalten werden. Ob der GBV letztes Jahr diese auch
    oder nur irgendwelche "ueberregionalen verbund-lokalen" Normsaetze in
    die PND ueberfuehrt hat, weiss ich nicht)

Fuer allegro sind diese Verbundszenarien nur beschraenkt uebernehmbar:
Weder haben "die" allegro-Anwender alle ihre Normdaten letztes Jahr in
die PND ueberfuehrt, noch ist gewaehrleistet, dass die in den letzten
Jahrzehnten lokal angelegten Normdatensaetze redundant sind (*Erschliessung*
findet im Verbund-Szenario im Verbund statt, die dortigen Lokalsysteme
spiegeln nur im Verbund vorhandene Titelaufnahmen und davon abgeleitet
spiegeln sie dafuer benoetigte Normsaetze, Anreicherungen und zusaetzliche
Datensaetze kommen in so einem Anwendungszenario ueberhaupt nicht vor).

Weil die Zeit so weit fortgeschritten ist, werden uebergangsweise gewiss
MARC21-Importschnittstellen fuer die vorhandenen, getrennten Normsatz-
internstrukturen in den diversen Allegro-Kategorievarianten benoetigt
(plus moderate Erweiterungen, die GND-Nummer muss z.B. irgendwo hinterlegt
werden...). Das volle Potential der GND wird man so aber nicht nutzen
koennen (es gibt ja Gruende, warum fuer die Normdaten die MARC21-Einfuehrung
vorgezogen wurde und warum es keine GND-Bereitstellungen in MAB mehr
gibt) und fuer alle allegro-Anwendungen stellt sich isoliert die Frage,
wie mittelfristig die bisherigen Normdatenstrukturen umzustellen und auch
zusammenzufassen sind, um die GND besser nutzbar zu machen.
Dem Weg der Verbuende zu folgen und intern eine eigene Satzart "GND"
mit MARC-artigen Feldnummern einzufuehren (und zu hoffen, die alten
Satzarten langfristig irgendwie "auszuschleichen") ist dabei recht
attraktiv:
* Im- und Exportschnittstellen zum GND-MARC21 werden ziemlich einfach
* Redaktionsanleitungen und Handreichungen zur GND koennen nachgenutzt
  werden
* Der Reichtum der GND-Daten kann lokal abgebildet werden, ohne sich
  /vorher/ intensiv damit auseinander zu setzen, lokale Felder zu
  definieren und Importe daraufhin aufzubohren.

Fuer allegro kann man nun zusaetzlich ueberlegen (und da schliesst sich
der Bogen zum Unicode-Beispiel wenn man bedenkt, dass es da auch
Ansaetze gibt, die Unicode-Datenbank mit allen Attributen aller Zeichen
in Form von allegro-Datensaetzen abzubilden), ob es moeglich ist oder was
zu tun waere, wenn man (weitestgehend) konfigurationsunabhaengige Daten
erlaubt, in $A.CFG (t2,k4) also etwas hybrides ermoeglicht, konkret
MARC-artige Feldnummern t3,k-irgendwas (Indikatoren kann man ja
in Unterfelder packen, dreistellig benummerte /und/ wiederholbare
Felder sind aber essentiell). Im Bereich der Parameterdateien gibt
es durch "@" als Platzhalter schon Ansaetze in diese Richtung.

Wenn so eine Erweiterung in Zukunft kommt (bzw. als technisch niemals
moeglich ausgeschlossen werden kann und daher nicht kommt), hat das
ziemliche Auswirkungen auf die Entwicklung der einzelnen Datenformate
($A.CFG, HANS, ...) und in Bezug auf zu schaffende Im- und Export-
Schnittstellen bzw. den dafuer zu leistenden Aufwand fure alle
bestehenden und zukuenftigen allegro-Anwendungen.

viele Gruesse
Thomas Berger