[Allegro] Petition fuer die Gleichbehandlung von Standard-Ergebnismengen in a99 mit echten Ergebnismengen [Was: Re: EDT?

[Thomas Berger]

Lieber Herr Eversberg, liebe Liste,

> Über den Tag hinaus, und das jetzt mehr unter uns gesagt, gewinne ich
> den Eindruck, daß Sie zunehmend fasziniert sind vom Eindruck der in
> Bewegung geratenen internationalen Entwicklungen um RDA, MARC und
> BIBFRAME.

Ist es nicht etwas faszinierendes, wenn in Bibliotheken etwas
in Bewegung geraet ?-;


> Das stellen Sie in der BIBFRAME-Liste derzeit unmißverständlich und
> eindrucksvoll unter Beweis. Von daher muß es Ihnen erscheinen, daß
> sich da Züge in Bewegung gesetzt haben, auf die aufzuspringen nottut,
> will man nicht ganz schnell ganz weit zurückbleiben auf dem Gelände
> der bibliothekarisch-bibliographischen Software. Tut man das aber,
> kann einem nur mulmig zumute werden beim Gedanken an alle derzeit
> existierenden Systeme, darunter allegro. Ist man mit so einem
> System aktiv involviert, wird man zwangsläufig über dessen
> abstruse Unzulänglichkeiten zunehmend unduldsam. Nein, die
> neue Ausrichtung, "der Zukunft zugewandt", die muß ganz anders
> aussehen als alles, was wir kennen - so zeichnet sich das ja
> nun überdeutlich ab. Man mag deshalb auch immer weniger Zeit
> aufwenden müssen für scheinbar rapide alternde Produkte.

Eigentlich sind Normdaten und Regelwerke mein Steckenpferd, aus
der Praxis weiss ich natuerlich auch allerhand ueber Datenformate.
Ich halte RDA und Bibframe - jeweils an deren Anspruechen gemessen -
fuer absolut unausgegoren, naiv, durchsetzt mit alten Zoepfen,
und strotzend von der "ueblichen" bibliothekarischen Hybris,
ein Erklaerungsmodell fuer die ganze Welt auszusinnen und das
dann ueberall draufstuelpen zu wollen - das nur unter uns gesagt ;-)

Spannend ist natuerlich auch zu sehen, wie da die verschiedenen
Kraefte am Werk sind, hier denkt man ja "RDA - so viele neue
Regeln, alles wird ganz anders", und am anderen Ende sitzen
Leute die sich freuen "o.k., die allgemeine Materialbenennung
ist nun irgendwie anders, aber sonst ist es genau das AACR2
das wir kennen, dass der Regelwerkstext einmal von innen nach
aussen gestuelpt wurde, hat aufs Ergebnis keine Auswirkung".

Man kann aber nicht behaupten, dass das nun durchgehend eine
Verschlechterung zum frueheren/derzeitigen Zustand darstellt
oder dass das nicht praktikabel ist. Und speziell hierzulande
ist vor 10 Jahren zu recht ein Reformstau (die Welt bewegt
sich schneller als wir) konstatiert worden, den man mit den
vorhandenen Resourcen fuer Gremien etc. nicht mehr in den
Griff zu bekommen glaubte (vermutlich ebenfalls eine korrekte
Analyse). Die gezogene Konsequenz war die "Notbremse", d.h.
das Einstellen jeglicher Weiterarbeit am vorhandenen Regelwerk
(2004) und Datenformat (2006, wenn ich mich nicht irre). Die
"Umstellung auf MARC21" war dabei immer ein extrem langfristiges
Projekt, auch im Ursprungsplan hatte sie nicht vor 2016
abgeschlossen sein sollen.



> Nur: Wo werden sie ankommen, die neuen Züge, und vor allem wann?
> Solange sie nicht angekommen sind irgendwo, wo man aussteigen und
> sich produktiv betätigen kann, als Pionier in unberührten, potentiell
> aber alsbald blühenden Landschaften, da scharrt man in stickigen
> Abteilen ungeduldig mit den Hufen und theoretisiert unermüdlich mit den
> Reisegenossen.

Es mussten (und muessen) Jahrzehnte an Theoriedefizit aufgearbeitet
werden, und es ist auch sonst enorm viel zu lernen. Ganz fundamental ist
die Fortschreibung der "Paris Principles" durch das IFLA Statement of
International Cataloguing Principles (ICP) 2003ff
(< http://www.ifla.org/files/assets/cataloguing/icp/icp_2009-de.pdf >),
und natuerlich FRBR (als Buch veroeffentlicht zuerst 1998).
Wie immer bei konzeptionellen Modellen kann man zwar irgendwie
abschaetzen, ob sie in sich halbwegs widerspruchsfrei sind, ob
es aber tatsaechlich etwas taugt, stellt sich erst spaeter heraus,
wenn man versucht die Modelle umzusetzen, hier etwa in den RDA als
Regelwerk. Und bezueglich des Regelwerks stellen sich dann erneut
die Fragen der inneren Kohaerenz (speziell RDA als Copy&Paste-Job
aus den AACR2 - wenn man einzelne Paragraphen betrachtet, die
innere Logik hingegen ist stellenweise fast komplett invertiert)
und wiederum der Tauglichkeit. Frau Wiesenmueller aus Stuttgart
ist nicht genug zu loben, unermuedlich thematisiert sie Beispiel-
faelle und auch Beispiel-Erschliessungen, die nach Regelwerk
nicht eindeutig oder ganz anders behandelt werden muessten -
den AACR2-sozialisierten Anwendern ist das nie aufgefallen, erst
die Aussensicht offenbart die Problemstellen. Mein Eindruck ist,
dass sich an der Stelle nicht nur die RDA, sondern auch FRBR
als wenig belastbar zeigen.

Inwieweit die Regelwerke einen direkten Einfluss auf die Praxis
haben, ist (mir) inzwischen weniger klar: Immerhin sind die
Katalogisierer 2004 nicht alle nach Hause gegangen und sie
haben weiterhin mit den Ihnen zur Verfuegung stehenden Mitteln
(also konkrete Bibliothekssysteme und die von denen gebotenen
Feldern und Indexierungen) alles das bearbeitet, was ihnen
zur Tuer hineinkam (also auch eBooks, Online-Zeitschriften,
Digitalisate, verbesserte Normdaten, ...). Aber obwohl man
auch ohne Regelwerk (oder mit Hausregeln) erwiesenermassen
jahrzehntelang weiter wursteln kann, ist es wichtig, dass
es irgendwo ein Regelwerk gibt: Schliesslich enthebt einem
die Anwendung von Regeln von der Pflicht, staendig selbst
denkend die Theorie in die Praxis umsetzen zu muessen (sofern
man eine Theorie hat).

Bei den Datenformaten ist es aehnlich: MAB hat einige Design-
Probleme, die MARC21 nicht hat, umgekehrt manchmal auch.
Fundamental ist aber die Verflechtung mit den Regelwerken,
was wir fuer "Daten" halten, ist fuer andere eher Volltext
mit Lepra (das ist kein Zitat, ich behaupte das einfach mal
so). Man kann das nun leicht verbessern, indem man den
Abkuerzungszwang abschafft, und die Interdependenzen zwischen
transkribierten deskriptiven Elementen und "reinen" Daten
in unseren Beschreibugen bieten sich auch fuer einen
"linked data"-Ansatz an. Wie Bibframe in die Richtung von
RDF-Beschreibungen zu denken, die ueberhaupt keinen Text
sondern nur Daten "koennen", und sich fundamental schwer
darin tun, denselben Sachverhalt redundant auszudruecken
(was in unseren Daten die Regel ist unter mindestens
stillschweigender Ermutigung durch die Regelwerke), ist
allerhand - naiv, vermessen, ein Quantensprung, ein
glorioser Untergang - niemand kann das absehen.



> Uns hier bleibt aber nichts anderes, als an unserem Produkt die noch
> bestehenden Unzulänglichkeiten zu beheben. Es noch hineinzuhieven in
> einen der schon abgefahrenen Züge, die Option besteht nicht. Man wird,
> wo immer man ankommt, neu beginnen müssen, auf neuem Boden mit neuem
> Werkzeug und neuem Saatgut. Dazu schicken Sie sich offenkundig an,
> werter Herr Berger, das ist mutig, und dazu Glück auf!

Bei allegro-NRW (also das verschnarchteste aller allegro-Formate,
es sollte nie anderes als "Schreibmaschine" sein), beginnen die
Rest-Anwender sich interessanterweise fuer Normdaten zu interessieren.
Die importiere ich dann anhand der RDF-Darstellung im DNB-Portal
nach a99: Etwas XSLT und ansonsten keine Hexerei. Aber das meinten
Sie vermutlich nicht?

Ich bin ja nicht nur Bibliotheken, sondern auch den "nachlasshaltenden
Institutionen" verhaftet, allegro-HANS orientiert sich nach den
dort vorherrschenden Regeln und Standards. Dort (in der Bibliotheks-
Ecke dieser Kreise, also ueberwiegend den Handschriftenabteilungen
groesserer Bibliotheken) verlaesst Kalliope als zentrales
Nachweisinstrument soeben MAB-Diskette als grundlegendes Austausch-
format und migriert - nicht zu MARC21 sondern zu EAD, es erfolgt
also eine Annaeherung an andere Archive. Aber auch dort ist einiges
in Bewegung - EAD kann man als strukurierte und redundanzreduzierte
Beschreibung von Einzelobjekten sehen, in seinen Wurzeln ist es aber
die Transkription eines Findbuchs, also /ein/ umfangreiches Dokument
pro Bestand.
Damit hat man nun komplementaere Probleme im Vergleich zu Bibliotheks-
daten: Archivare wollen die vorgegebene starre Ordnung verlassen und
andere Ordnungen zulassen (kontextuebergreifende, oder von der
Recherchesituation bedingte) und im Zusammenhang mit Digitalisaten,
Web-Prasentationen, Suchmaschinentreffern stellt sich das Problem,
aus dem Findbuch gezielt die Beschreibung eines Dokuments zu
isolieren, mangels Identnummern und wegen der aus Gruenden der
Redundanzvermeidung stark aus den Objekten ausgelagerten Datenhaltung
ist das nicht trivial. Insofern gibt es auch dort Tendenzen, das
"Korsett" EAD irgendwie zu ueberwinden. Und man schaut dafuer z.B.
auch auf Bibframe, bzw. allgemeiner was aus dem Bereich "Linked
Data" an Konzepten und Loesungen erwaechst: Wir Gedaechtnis-
Institutionen sind ja nur ein winziger Teil der vielfaeltigen Szene
und nutzen ueberwiegend bereits existierendes (wie XML oder RDF)
nach - das meinte ich eingangs mit dem Lernbedarf - zumindest
fuer das /Design/ von RDF-basierenden Formaten muss man RDF
*verstehen*, und die einschlaegigen Standards sind anders als
manche IETF-RFCs nun wirklich nicht zur Bettlektuere geeignet
sondern angewandte Praedikatenlogik, also mathematische Texte
auf mindestens dem Niveau des Informatik-Grundstudiums (ich erinnere
mich an ein Proseminar in dem ich fast gar nichts verstand, dabei
war ich doch eigentlich Mathematikstudent...).


[...]

> Wer also gegenwärtig mit allegro arbeitet, muß keinesfalls befürchten,
> binnen kurzem im Regen zu stehen oder in der Wüste. Wieviele Dekaden
> noch, das steht in den Sternen, jedenfalls arbeiten wir dran.

Vielleicht nur wegen meiner Auseinandersetzung mit nichtbibliothekarischen
Beschreibungsmethoden bin ich auch einer derjenigen, die offen fuer
ISBD-Darstellungen Partei ergreifen. Die Vorstellung eines von links
oben nach rechts unten les- oder ueberfliegbaren /Texts/, der mir
etwas erzaehlt und dessen auf einer anderen Ebene durchaus verfuegbare
Granulierung diskret im Hintergrund bleibt, bis ich mich dafuer
interessieren sollte, ist mir aeusserst angenehm: Sowohl als
Katalogbenutzer als auch bei der Katalogpflege.

Mein Standpunkt ist, dass die Vorlage als logische Einheit, wie
sie von einer ISBD-Beschreibung repraesentiert wird, fuer Menschen,
die mit den Daten interagieren muessen, eine durchaus geeignete
Sicht ist. D.h. der "bibliothekarische Datensatz" ist ein
Paradigma, an dem wir fuer unsere Benutzeroberflaechen durchaus
festhalten sollten, was dann auch unsere "normalen" Bearbeitungs-
werkzeuge einschliesst. Verknuepft gespeicherte mehrbaendige
Werke z.B. in allegro zeigen m.E., dass die Anzeigeeinheit
durchaus nur eine Fiktion ist, die dem Benutzer gegenueber
erzeugt wird, gespeichert sind mehrere Einheiten. Dafuer hat
aber auch der Benutzer selber die Moeglichkeit, durch "schalten"
von Band zu Hauptaufnahme etc. den seinen Fokus zu veraendern,
also auf Grundlage derselben Daten verschiedene Varianten einer
solchen "Einheit" anzufordern. Denkt man in den FRBR-Konzepten
W-E-M-I, also zusaetzlichen logischen statt physischen Hierarchien,
die absolut isoliert betrachtet wenig Sinn machen, ist so ein
Ansatz wie bei allegro durchaus noch ausbaufaehig.

Denkt man an Datenstroeme in einer vernetzten Umwelt (allegro-
Anwender sind davon leider weitgehend abgeschnitten), wo es
dann darum gehen mag, gezielt Kataloganreicherungen einer
bestimmten Sorte in einer groesseren Menge von Datensaetzen
auszutauschen oder auch auf "ausgelagerte" Daten halbwegs
effizient und praezise zuzugreifen, sieht man die Notwendigkeit
des Transports von Daten in wesentlich kleineren Einheiten als
"bibliothekarische Datensaetze" (oder W-E-M-I-Fragmenten davon).
Dabei entstehen Probleme der Selektion und der Adressierung
(beim "Update"), serialisiertes RDF mag da ein gutes Transport-
medium sein, loest fuer sich genommen aber auch nicht alle
diesbezueglichen Probleme.

Fuer eine Anwendung wie allegro sehe ich durchaus die
Notwendigkeit, mit der Entwicklung Schritt zu halten, aber
was bedeutet das konkret? Ob man intern im Format XY
arbeitet, sehe ich als Implementierungsdetail, wichtig
ist vielmehr, Reibungsverluste zu vermeiden. Und zwar
sowohl an der Schnittstelle Anwender <-> Anwendung als
auch zwischen diesem System und anderen, denn die Daten
werden haeufiger, kleinteiliger, spontaner hin- und
herfliessen, das ist ziemlich klar. "Unicode" ist ein
riesiger Schritt in Richtung des Abbaus von Reibungs-
verlusten, auch das ist klar. Import- und Exportsprache
sind fuer gewisse Formate und Anwendungsfaelle optimiert,
mit anderen, in letzter Zeit hinzugekommenen, tun sie sich
schwer. Man kann XML im- und Exportieren, insbesondere
wenn man kleine Vor- und Nachbearbeitungen mit nicht-allegro-
Methoden einsetzt, das gilt aber gerade beim Import nur
fuer gewisse XML-Formate (MABXML, MARCXML, MODS, EAD, ...).
Man wird aber mittelfristig auch einmal JSON-LD oder Turtle
beherrschen wollen, dafuer muss mehr getan werden, als "nur"
eine Parameterdatei zu schreiben.


viele Gruesse
Thomas Berger