[Allegro] V34.8 steht vor der Tür. Und dann?

Mi Dez 10 11:47:59 CET 2014

Lieber Herr Stephan, liebe Liste,

ich sehe das in Bezug auf das "Standard-allegro" genauso wie Sie,
allerdings zerfaellt das fuer mich in zwei Stufen:

Fundamental ist das Datenformat $A.CFG: Wer sich hier Extrawuerste
braet ist darauf angewiesen, jegliche Parameterdateien vor dem
Einsatz auf lokale Gegebenheiten umzuarbeiten. Zwischen 1995 und
2005 habe ich viel Zeit damit verbracht, dies in Installationen
zu identifizieren und auf die wirklich noetigen Abweichungen zu
reduzieren und das dann akribisch in den Parameterdateien zu
kennzeichnen.

[Natuerlich gibt es auch innerhalb des gegebenen Datenformats
gewaltige Unterschiede in der Erfassung, seien es die Folgebuchstaben
#402, #403 etc. vs. #40a, #40b etc. oder die internen Trennungen
in Sacherschliessungskategorien ("; ", " ; ", "¶") oder ueberhaupt
differenzierte Sacherschliessung in #31p, #31s, #31k oder undifferenzierte
in #31_, sowie natuerlich ueberhaupt nach welchen Regeln oder welchem
Vokabular angesetzt wird. Und der grosse Bereich des Ob und Wie von
Verknuepfungen. Typischerweise ist das oft nicht einmal innerhalb einer
Datenbank einheitlich, *Standard*-Parameterdateien versuchen allerdings,
mit dieser Bandbreite umzugehen, (bei *Importen* gilt das nur eingeschraenkt,
schliesslich muessen etwa konkrete Trennzeichen eingesetzt werden, das
kann nicht in der Schwebe bleiben)]

Auf einer anderen Ebene dann die konkrete Gestaltung der Datenbank,
hier sind fuer das Standardformat m.W. die Standardparameter dominant.
Gewisse lokale Abweichungen davon sind durchaus angemessen (es gibt
z.B. keine universelle Signatursortierung) oder gar erforderlich
(klassifikatorische Sacherschliessung ist oft sehr individuell),
normalerweise kann das aber recht gut im Rahmen des Standard-Register-
Layouts und der Standard-ISBD-Anzeige auf kleine Bereiche der Parameter-
dateien beschraenkt werden, "Schnittstellen" sind eher weniger betroffen.
Meine Behauptung: Wer sich bei der Datenhaltung am Standard-Format
orientiert kann jederzeit seine individuellen Parameterdateien ueber
Bord werfen und auf die Standardparameter umstellen: Das bedeutet
unter Umstaenden einen gewissen Verlust an Bedienungs- und Recherche-
komfort, die Anwendung bzw. die existierenden Daten werden dadurch
aber nicht komplett unbenutzbar oder unbrauchbar.

Was daher unbedingt not tut, ist zunaechst das Datenformat so zu
entwickeln, dass "RDA"-Beduerfnisse abgedeckt werden koennen. Ich
hatte bereits ausgefuehrt, dass davon nicht nur die betroffen sind,
die ~demnaechst~ die eigene Katalogisierung auf RDA umstellen
wollen, sondern alle die Fremddaten (Titel- oder Normdaten) nutzen,
hoffentlich ist das die Mehrheit aller Anwender! Mein Vorschlag ist,
dass die *Formatpflege* ("aus aktuellem Anlass": sehr bald!) in
die Haende der *gesamten* Anwenderschaft uebergeht, die Verschraenkungen
mit der Evolution der Regelwerke und der Praxis der Katalogisierung
sind m.E. so gross, dass es erstens alle angeht und zweitens bereits
die Diskussionen darum auch fuer "stille Mitleser" einen enormen
Lerneffekt fuer den Zugang zu RDA bedeuten koennen (oder bin ich
da zu optimistisch, weil Regelwerkstechnik und Formattechnik auch
nur "Technik" sind und die meisten abschrecken?)

Als Nebeneffekt der Formatdiskussion stelle ich mir vor, dass dabei
auch konkrete Erwartungen an die Verarbeitung entstehen, so dass
dann anschliessend nicht nur klar ist, welche Felder die Standard-
parameter nun zusaetzlich beruecksichtigen muessen, sondern auch
auf welche Weise. "allegro" wuerde es aushalten, wenn das an
mehreren Orten unterschiedlich implementiert wuerde, meine Hoffnung
ist allerdings, dass die Aenderungen auch in *die* Standardparameter
(aus inst-all.exe) Einzug halten.

Drittens werden Vorstellungen entwickelt werden, wo sich eine
Umsetzung vorhandener Daten lohnen koennte (sie werden dadurch
wie erwaehnt zwar nicht zu RDA-Katalogisiaten, im eigenen
Katalog kann dadurch aber punktuell die Einheitlichkeit verbessert
werden), evtl. kann so etwas in das angekuendigte Prozedere fuer
die Umstellung von Datenbanken auf "intern UTF-8" integriert werden.

Viertens ein Punkt, den ich noch nicht angesprochen habe, und der
ehemaligen Teilnehmern der AG Codes eigentlich gefallen sollte:
Es gibt viele Stellen, wo RDA (insbesondere in der D-A-CH-Auspraegung)
in der MARC21-Tradition mit verbindlichen Listen von Begriffen
und Codes arbeitet, z.B. bei Funktionsbezeichnungen oder auch
bei den Benennungen, die der Ersatz fuer die RSWK-Formschlagworte
werden (die werden komplett von der Sacherschliessung abgezogen
und der Formalerschliessung zugeordnet). Diese Vokabulare werden im
Rahmen des Regelwerks gepflegt und weiterentwickelt, die Anwendung
ist verbindlich, sie liegen aber als separate Datensammlungen vor.
Bislang gab es das nur spaerlich und im Zweifelsfall wurden die
Sachverhalte in die Paramterdateien eincodiert. Fuer "RDA" wird es
m.E. notwendig werden, diese Vokabularlisten *als Daten* zu
betrachten, d.h. (vgl. die Standarddaten fuer die VS-Seuqenzen)
aufbereitet zur Verfuegung zu stellen, so dass (in Systemen mit
"Standard"-parametern) Download und Uebernahme durch die
Anwender moeglich wird, auch ohne die eigentliche Software zu
aktualisieren. *Innerhalb* der Installation stelle ich mir das
so aehnlich vor wie bei den Kontingenten etc. fuer ORDER: Einerseits
als "Systemsaetze" vorliegend, um Validierungen und Exporte zu
ermoeglichen, andererseits werden View-Dateien zur Unterstuetzung
der Eingabe generiert. /Das/ sind dann Design- und Implementierungs-
fragen, die wirklich technisch sind und von denen die Mehrheit
dann nur erwartet, dass zum Schluss alles nahtlos funktioniert...

viele Gruesse
Thomas Berger

Am 10.12.2014 um 10:08 schrieb Armin Stephan:
> Lieber Herr Eversberg,
> 
> natürlich weiß ich, dass wir hier von der Parametrisierung reden und nicht von
> den Programmen.
> 
> Und klar könnten grundsätzlich auch andere diese Parametrierungsarbeit leisten.
> 
> Die Erfolgsgeschichte von Allegro, zu deren Fortsetzung ich gerne beitragen
> würde, hängt nach meiner Einschätzung ganz wesentlich damit zusammen, dass es
> auch immer ein anwendungsfertiges Allegro gab. In sehr, sehr vielen Bibliotheken
> wird Allegro als solches eingesetzt und nicht als frei parametrierbares,
> geniales System zur Verarbeitung bibliographischer Daten.
> 
> Alle diese Anwender wären mit den Parametrierarbeiten im Zusammenhang mit einer
> Anpassung an RDA überfordert oder zumindest nicht daran interessiert- was dann
> (leider!) doch dazu führen würde, dass Allegro sehr viel schneller aus der
> Praxis verschwindet als es seine technischen Fähigkeiten eigentlich nötig machen
> würden.
> 
> Das zeitliche Ineinanderfallen der RDA-Umstellung und Ihres Ruhestandes ist ein
> ganz und gar unglückliches Timing.
> 
> Allegro braucht meines Erachtens tatsächlich eine Art "Plan RDA", um den
> AnwenderInnen noch lange Freude zu machenund um zu vermeiden, dass man Allegro
> das Etikett "nicht RDA-kompatibel" anheften kann.
> 
> 
> Dass Sie persönlich sich da nicht mehr angesprochen fühlen, verstehe ich gut.
> Sie habendie Bedeutung des "Standard-Allegros" immer schon deutlich niedriger
> eingeschätzt als ich. Und Sie haben allen Grund, nicht gerade ein Fan von RDA zu
> sein.
> 
> Auch wenn Sie es immer wieder bestritten haben, hat aber "Braunschweig" immer
> die entscheidenden und eben auch allseits akzeptierten Standards gesetztfür
> dasanwendungsfertige Allegro. Es hatte einfach die natürliche Autorität dafür.
> Hier entsteht in Zukunft eine große Lücke. Und ich sehe noch nicht, wie diese
> Lücke geschlossen werden kann/soll.