[Allegro] Anmerkungen zu i5=__

Di Mai 7 14:41:34 CEST 2013

Lieber Herr Eversberg, liebe Liste,

ich wuerde das gerne weiter diskutieren,

Am 06.05.2013 16:11, schrieb Bernhard Eversberg:
> Aber wir sind nun mal nicht die Institution, die Normen setzen sollte oder
> könnte. Unsere Standardparameter waren und sind als Beispiele zu verstehen, die,
> zugegeben, aktuellen Vorstellungen und Ansprüchen immer weniger gerecht zu
> werden vermögen. Es steht Anwendern und Supportern frei, mit den gegebenen und
> oftmals von ihnen selbst angestoßenen Verbesserungen auf den Ebenen der
> Parametrierung und FLEX-Sprache eine Parametrierung zu erarbeiten, die unter
> heutigen Ansprüchen konsensfähig ist.

denn ich denke, dass "konsensfaehig" der entscheidende Ansatz ist.

Einerseits ist es ja so, dass die "deutsche" Regelwerks- und Formatentwicklung
nicht zuletzt deshalb eingestellt worden ist, weil die Community von einigen
zehntausend Bibliotheken das nicht mehr stemmen konnte. Bzw. die Handvoll
"normsetzender" Verbundzentralen (mit den ueblichen Beobachtern von der
EKZ und weiteren) wollte oder konnte das nicht mehr - leisten oder
verantworten.

Die "Internationalisierung" ist uns damals stellenweise als "internationale
Einheitlichkeit" mit dem Versprechen groesserer Interoperabilitaet
praesentiert worden, ich habe das damals fuer eine dreiste Luege gehalten,
inzwischen sehe ich das differenzierter: Ein solches Mass von Einheitlichkeit,
wie wir aus der RAK/MAB-Welt gewoehnt waren, ist der AACR/MARC-Welt
eher fremd, wie auch die englische Sprache nur ein Wort fuer "Uebersetzung"
und "Uebertragung" hat.

Wir sind jetzt bereits mitten in einer "vielschichtigen" Welt angekommen,
die MARC21-Community hat Standards, die LCRI wird es weiterhin geben,
die D-A-CH-Anwendungsschicht hat Standards, die Verbuende fuer ihre
Klienten sowieso (ab der Stelle fliesst dann auch ganz stark das "Vertaendnis"
der Software-Hersteller fuer Katalogisierung ein) und so weiter bis zur
kleinsten Untersammlung. Bzw. eigentlich hat sich da wenig geaendert,
diese Diversitaet wird aber nun als solche wahrgenommen und ist nicht
mehr etwas zu ueberwindendes. Diese Diversitaet muss aber irgendwie
gemanagt werden, alle diese ergaenzenden, aendernden, erweiternden Standards
muessen Bezug aufeinander nehmen, monolithische Unternehmungen wie RAK/AACR2
oder MAB/MARC, alle eigentlich mit dem zusaetzlichen unausgesprochenen
Anspruch, die ganze Welt regeln zu koennen und zu muessen, sind in
rapider Aufloesung begriffen, Konsens ist eigentlich, dass diese Ansaetze
keine Chance mehr haben zur Realitaet zurueckzufinden, auch bei groesster
Anstrengung nicht.

Das heisst aber nun gerade nicht, dass die Welt oder unsere Werkzeuge nun
weniger komplex als frueher sind oder dass jetzt die Stunde der Einzelkaempfer
schlaegt, die in der Mittagspause ein Weltmodell entwickeln und am Nachmittag
ihr Bibliotheskssystem darauf einrichten (eines der falsch verstandenen
Heilsversprechen von "XML", wenn ich mich recht entsinne).

"allegro" war immer dreierlei (mindestens);

1. Die Executables als "Schweizer Taschenmesser des Bibliothekswesens", also
  die Moeglichkeit, leistungsstarke Umwandlungen und Zwischen-Datenhaltung
  beliebiger Formate durchzufuehren

2. Die Konfigurations- und Parameterdateien zu einem gegebenen Format, die
  es ermoeglichen, eine Anwendung dieses Formats zu erweitern und
  abzuwandlen

3. "Standardanwendungen" gewisser Formate mit dem Anspruch, damit sofort
  loslegen zu koennen (o.k., auf neueren Rechnern ist ein Administrator-
  password zur Installation erforderlich, auch "sofort" ist nicht mehr
  was es frueher einmal war)

Der Anspruch dabei war, dass viele mit 3. auskommen und nicht sofort
auf die fuer 2. benoetigten esoterischen Faehigkeiten angewiesen sind.
Und dass es bei 2. allerhand vorbereitetes gibt, damit nicht jeder,
der etwas anpassen will, die umfassenden Kenntnisse fuer 1. benoetigt
(ich meine nicht Herumschrauben an den Quelltexten der allegro-Module,
sondern eher die Entwicklung vielstufiger Workflows mit voellig neuen
Parameterdateien)

Mein Verdacht ist nun, dass diese "Ebenen" der allegro-Nutzung inzwischen
schraeg zu den oben beschriebenen Schichten des Bibliothekswesens liegen,
dass also fuer neuere Formen von "Standardsituationen" keine Standard-
werkzeuge existieren und daher schnell alles extrem muehselig wird.
Extremes Beispiel: Wenn mir Regelwerke und Datenformat demnaechst
Nutzung und Transport von Thesauri in SKOS oder einem anderen spezialisierten
(aber genuin nichtbibliothekarischen) Thesaurus-Format gestatten, dann
will ich das auch in "meinem" allegro nutzen, und zwar moeglichst auf
Ebene 3 oder 2 von oben, und zwar ganz "generisch", also ohne mich
auf einen bestimmten Thesaurus oder eine bestimmte Menge von Thesauri
festzulegen und ohne dafuer mehr als punktuelle Eingriffe in mein
Kategorienschema und meine existierenden Parameterdateien vornehmen
zu muessen. D.h. wir muessen abruecken von einer Sichtweise wie
"Im A-Format 'macht' man Thesauri mit Kategorie #3t und hat folgende
Im- und Exportparameterdeien ins SKOS-Format zur Verfuegung" und gelangen
zu einer Sicht "SKOS-Thesauri kann man so im- und exportieren und
wie folgt bearbeiten".

Wir hatten neulich eine Diskussion ueber die Abbildung von Werkverzeichnissen
(#89o) im Index und es hat sich niemand als Nutzer der Kategorie geoutet.
Oder allegro-HANS hatte (und hat noch immer) differenzierte Kategorien
fuer Wasserzeichen, als jemand das fuer ein Projekt /systematisch/
einsetzen wollte und dafuer einen Wasserzeichenforscher konsultierte, hat
der sich ueber die Naivitaet des Ansatzes kaputt gelacht (oder so: Ich
war nicht dabei) und sowieso davon abgeraten auch nur daran zu denken, das
bei der Katalogisierung irgendwie "nebenbei" erledigen zu wollen. Nach
RAK-Denke machen entweder alle alles richtig (Ansetzungen) oder niemand
darf es machen (2. Herausgeber). [Oder wir ziehen den Joker "Alte Drucke"
und duerfen dann machen was wir wollen]. "allegro" war immer ziemlich
erfolgreich dabei, alle machen zu lassen was sie wollten, aber dahinter
steckte dann doch immer der Ansatz, dass es fuer so etwas wie #89o
das "Richtige" gibt und dass das dann bei Gelegenheit implementiert
wird und in die Standardparameter wandert. Ich denke inzwischen, fuer
#89o (also Opuszahlen als dediziertes Datenelement) gibt es nicht
"das Richtige", also wird das auch in Zukunft in den Standardparametern
nicht "korrekt" und universell abgehandelt werden koennen. Aber
natuerlich gibt es Bibliotheken, die Opus-Nummern erfassen koennen muessen,
durchaus auch systematisch und massenhaft und geeignet indexiert, nur
halt nicht "universell".

Und dennoch denke ich, dass "konsensfaehig" der entscheidende Ansatz
ist: Die allegro-Anwender, oder beispielsweise die Untergruppe der
Anwender des A-Schemas, muss einen Konsens darueber entwickeln, was a)
"Katalogisierung" im konkreten Umfeld heute noch ist und b) welche Aufgaben
dabei und darueber hinaus dem "Bibliothekssystem" zukommen (ich unterstelle
einmal, dass der Bibliothekswelt ein solcher Konsens seit etwa 1990
allmaehlich abhanden gekommen ist und die allegro-Anwender da keine
Ausnahme darstellen, sonst tut es mir leid).

Das - so stelle ich mir vor - kann man dann in Paradigmen ummuenzen,
denen die Software "allegro" im Zusammenhang mit einem konkreten
Format/Schema/Anwendungsfeld genuegen soll: Hoffentlich entsteht
auch da Konsens (etwa in dem Sinn, dass die Beteiligten den Eindruck
bekommen, ein Paradigma "Erwerbungsfuktionalitaet" in seiner konkreten
"allegro"-Auspraegung bei Bedarf hinreichend schnell verinnerlichen zu
koennen)

Dann muss man (wahrscheinlich) "allegro" etwas umbauen und (gewiss)
an allen Datenformaten arbeiten, bei keinem der mir gelaeufigen
Format (nicht nur den allegro-internen) hat es in den letzten
20 Jahren nennenswerte Entwicklungen gegeben.

Und zum Schluss waere man dann in der Lage, (endlich wieder, nur)
punktuell einzelne Funktionalitaeten zu verbessern, auszubauen, zu
ergaenzen usw: Da kann dann m.E. recht schnell "Konsens" hergestellt
werden, ob das eine Verbesserung oder Verschlechterung des bisherigen
darstellt, und daher "fuer die naechste Version" uebernommen werden
kann oder nicht: Bei den meisten punktuellen Verbesserungen gehe
ich davon aus, dass die Mehrheit der Anwender sich so wenig dafuer
interessiert, dass sie nicht einmal damit behelligt werden will,
sich ein Urteil darueber bilden zu sollen.

viele Gruesse
Thomas Berger