Antwort: Re: [Allegro] Kategoriensuche: #73 Verwendung (insb. beiDrucken vor 1850)

Thomas Berger ThB at Gymel.com
Do Jul 12 00:59:22 CEST 2012


Lieber Herr Wolf, liebe Liste,

> Jenseits der eigentlichen Problemstellung von Herrn Kaut und seiner durchaus
> charmanten Idee von Stammdaten für Erscheinungsorte, stellt sich mal wieder die
> eher grundsätzliche Frage inwieweit man tatsächlich eine 'festgemeißelte'
> Konfiguration in allegro-Datenbanken verwenden sollte oder gar muß. Insbesondere
> da in allegro die Konfiguration (Herr Kaut hat es aufgezeigt) fast beliebig und
> ganz einfach erweitert werden könnte.
> 
> Und aus meiner Sicht machen feste Konfigurationen tatsächlich nur dann Sinn
> wenn die Daten mit einem der Verbundsysteme unbedingt kompatibel sein soll und
> Erweiterungen für ein Lokalsystem allegro nicht gewollt sind. Ansonsten erlaube
> ich zumindest 'meinen' Bibliotheken grundsätzlich und immer Erweiterungen
> beliebiger Art. Dokumentationen sind aber sicherlich hilfreich.
> 
> Ich hätte hier aber doch gerne mal die Einschätzungen meiner KollegInnen gekannt.

Das ist mehr als abendfuellend, man koennte darueber vermutlich einen
ganzen Kongress abhalten (natuerlich nicht nur auf allegro bezogen). Hier nur
ein paar Gedanken dazu:

"Dokumentationen sind ... hilfreich" bzw. Herrn Lehmanns "erkennen, was da
überhaupt sich 'jemand' gedacht hat": Spezialerschliessungen waren und
sind eine erhebliche Investition an Arbeitskraft und schon oft hat
sich herausgestellt, dass eigentlich nur eine einzige Person das
jeweilige System durchblickt hat und die wurde irgendwann verrentet.
Und spaetestens wenn nach 10 oder 20 Jahren einmal eine gruendliche
Ueberarbeitung faellig wird, hoert der Spass auf: Noch jede Systematik
musste irgendwann erweitert werden, jedes auch nur mittelkomplexe
terminologische System hat Bezuege und muss mit irgendetwas anderem
verzahnt werden, wenn man das Schleifen laesst, wird es nicht besser,
sondern im Laufe der Zeit schlechter.

Der vorige Absatz bezog sich auf die Pflege der Terminologie, aber
auch das Schema soll sich schon einmal geaendert haben: Sei es,
dass man fuer seinen Thesaurus irgendwann noch ein Extra-Datum
benoetigt (weil irgendein Referenzwerk nun online ist) oder weil
"der Rest" also "das" allegro-Format sich weiterentwickeln muss
(man bemerke die heimliche Einfuehrung einer neuen Kategorie #89s
vor einigen Wochen). allegro-typisch ist das alles in /einer/
.CFG-Datei festgelegt und in /einer/ .api, aber ich denke auch
in anderen Bibliothekssystemen geht man von "dem" (lokalen)
Datenschema aus (ggfls. pro "Pool" eines) und "der" Indexierung.
Man kann das flexibilisieren (vgl. MARC21 gegen MAB) und weitgehend
ohne zusaetzliche Felder auskommen, der Preis dafuer sind aber ganz
akribisch zu pflegende Codelisten, die auch haeufig aktualisiert
werden (und entweder in Programmcode gegossen sind oder in einer
relationalen Hilfsdatenbank des Bibliothekssystems zu hinterlegen
sind). Auch von Nicht-allegro-Bibliotheken kenne ich Erzaehlungen,
dass fruehere, seinerzeit realisierte Sonderwuensche dann zu
spaeteren Zeitpunkten das Upgrade zur naechsten Version gesoert,
verzoegert und teuer gemacht haben.

Ich will Herrn Kaut nicht zu nahe treten, aber #7er-Normsaetze fuer
"angesetzte" Orte oder Verleger habe ich schon haeufiger in allegro-
Datenbanken gesehen, aber m.W. wurde die Idee fuer die RAK vehement
abgelehnt: Verlagsorte anzusetzen scheint so viele Detailprobleme
mit sich zu ziehen (all die Eingemeindungen, all die pommerschen
Doerfer in denen jemand im Selbstverlag etwas heimatkundliches
herausgegeben hat, oder die grossen Verlage mit vielen Niederlassungen,
wo dann ohnehin nur ein willkuerlicher "erster" Ort verzeichnet wird),
dass man das auch kollektiv nicht stemmen zu koennen glaubte. Natuerlich
gehen die derzeit aktuellen Regelwerke noch davon aus, dass Katalogisierung
durch einen Einzelkaempfer mit Schreibmaschine und einem Keller voller
Nachschlagewerke erfolgt und heutzutage gibt es durchaus Moeglichkeiten
zur Kooperation. Bei Orten wird man sich im Zweifel aber auf die
Angabe der Koordinaten und des Zeitpunkts einigen und Ueberlegungen zur
korrekten "Ansetzung" und der diversen zu beruecksichtigenden
Hierarchisierungen den Historikern ueberlassen...

Manche Bibliotheksverbuende betreiben regelrechte FUD-Kampagnen:
Wer mehr als das in der Verbunddatenbank X realisierte betreibt wird bei
den zukuenftigen Verbund-, Format- und Regelwerksaenderungen ganz allein
da stehen, alles in die Tonne kloppen muessen und sich wuenschen, er haette
sich diese Extras nie einfallen lassen.

Gegenthese: Eine Bibliothek, die sich keine Extras bei der Erschliessung
leistet (weit gefasst, dazu gehoeren auch ganz niederschwellige Sachen
wie geschickte Abrufzeichen fuer Literaturlisten etc., Hinweis auf die
Sammlung von Schutzumschlaegen, ...) kann sich bald "Buechertheke von
WorldCat" nennen. Oder etwas ernster gesagt: Ich finde, dass sich das
Profil einer Bibliothek, ihr gezielter Bestandsaufbau im Hinblick auf
bestimmte Benutzergruppen oder Nutzungsszenarien im Katalog niederschlagen
/sollte/.

Die derzeitigen Umbrueche im Bibliothekswesen wurzeln tief in den 1990er-
Jahren und spiegeln die Idee, dass man nur Regeln und Formate international
genuegend vereinheitlichen muss, um zu gigantischen Synergiegewinnen durch
"Datentausch" zu kommen (sie reflektieren aber auch das Bekenntnis der
2000er-Jahre, dass man sich auch im nicht gerade kleinen "Deutschen
Sprachraum" eine Regelwerks- und Formatpflege im gebotenen Masse nicht
mehr leisten kann).

Gleichzeitig bedeuten aber FRBR, RDA und jede moegliche Variante eines MARC21-
Nachfolgeformats die radikale Dekonstruktion des Einheitskatalogisats, und zwar
in Bezug auf die Idee einheitlicher Ansetzungen (Originalsprachlichkeit
war so lange eine nette Idee, bis die Originalschriftlichkeit eine
konkrete Option wurde: Šostakovič ist harter Tobak fuer uns, die wir uns
an Shostakovich-Platten von Schostakowitsch gewoehnt haben, aber
Шостакович "funktioniert" hoechstens dann, wenn wir uns von jegliche
Form sortierter Listen verabschieden), der Fiktion eines "Datensatzes" als in
sich abgeschlossene und vollstaendige Erzaehlung (WEMI!), Homogenisierung
durch verbindliche Schranken (nicht mehr als einen Herausgeber, nicht mehr
als 10 Sacherschliessungen) etc. Man will nun dem Katalogisierer
viel mehr Freiheiten zur Erschliessung nach seinen Erfordernissen
("Hausregeln") lassen und ist gleichzeitig auf der Suche nach den
"Daten" in den Katalogisaten (die man bislang als "Katalogdaten" aufgefasst
hat), die dann eher atomisiert als RDF formuliert werden koennten.

Ich stelle mir das so vor, dass die Darstellung von "Beziehungen"
(zwischen Ausgaben, Personen, Werken, Teilen etc.) gegenueber
den sich selbst genuegenden "Beschreibungen" (von Objekten)
in den Vordergrund ruecken wird. In gewisser Hinsicht ist das
noch nicht einmal etwas neues, man denke an die traditionelle
Dopplung von "angesetzten" Elementen und solchen "in Vorlageform"
in den existierenden Katalogisaten: Fast alles angesetzte wird
traditionell dem Benutzer dann gar nicht gezeigt (denkt man an ISBD),
sondern etwa in Fussnoten ohne datentechnischen Bezug noch einmal
erzaehlt. Hier muss einfach etwas passieren, damit die enorme
Identifikationsarbeit, die sich in "angesetzten" oder "verknuepften"
Elementen der traditionellen Datensaetze niederschlaegt, viel
staerker genutzt werden kann als bislang vorgesehen.


Leitlinien fuer die Zukunft der Extrawurst koennten folgende sein:

1. Extra-Erschliessungen (oder besondere Schwerpunkte, Tiefen-
Erschliessungen etc.) sind legitim und sogar erwuenscht, die
Bibliothek muss das natuerlich oekonomisch verantworten koennen
und die langfristige Perspektive sehen. Weil damit meist ein
"System" mit "Regeln" verbunden ist, sollte man fruehzeitig
einplanen, das nicht alleine sondern kooperativ zu machen.

2. Attraktiv ist Zusatzerschliessung im Sinne von Vernetzung mit
nichtbibliothekarischen Aktivitaeten (man denke an die wissen-
schaftlichen Nutzer mit ihren fachlichen Praeferenzen oder was
die Zielgruppe sonst noch so treibt: Auch wenn mache Bibliotheken
inzwischen 24h geoeffnet haben ist Literaturbeschaffung fuer die
Benutzer doch nur ein Mittel zum Zweck und nicht ihr Lebensziel)

3. Gerade in hochgradig vernetzten und kooperativen Umgebungen (wo
man Kataloganreicherungen von X schaetzt, Verschlagwortungen von Y,
Titelaufnahmen von Z und selber auch ein kleines bisschen verbessern
und vertiefen will, sind traditionelle bibliothekarische "Datensaetze"
(auch in der "frei konfigurierbaren" Form) kaum noch handhabbar:
Wenn ein Update von Y kommt, muss ich im Prinzip alle Schlagworte
austauschen. d.h. fuer meine Aktivitaeten sind dann alle betroffenen
Felder tabu, es sei denn, ich vermerke bei jedem Feld und Unterfeld
Provenienz und Datum des letzten Updates...

4. Es gibt enorme Reibungsverluste, wenn ich originaer nicht-
bibliothekarische Daten (wie einen Geothesaurus) in Katalogdatensaetze
verwandeln muss, um damit umzugehen. Auch wenn Bibliothekssysteme
"integriert" heissen und uralt sind, sind sie nicht die Mutter aller
Computerprogramme. Egal wie gruendlich ich fremde Daten in meinen
Katalog physisch hineinziehe, ich muss davon ausgehen, dass sie
an ihrem Entstehungsort oder durch eine dem Entstehungszusammenhang
angepasstere Software deutlich angemessener praesentiert werden,
und zudem operabler und aktueller sind. Daher sollte man moeglichst nur
das Minimum in die "Katalogdatenbank" integrieren und ansonsten
den Schwerpunkt auf Web-basierende Online-Kommunikation mit Fremdsystemen
setzen.

Fazit fuer den Moment: Auch wenn allegro durchaus weniger starr ist
als anderes, und tatsaechlich "frei konfigurierbar", ist es doch ganz
deutlich den traditionellen, wenig "modularen" und hoechstens fuer
Top-Down-Szenarien der "Kooperation" brauchbaren Datenmodellen des
letzten Jahrtausends verhaftet. Das ist nicht besonders tragisch,
schliesslich kennen wir alle die Datenmodelle der Zukunft nicht,
aber laestig, weil wir nicht alle Daten "einfach" verarbeiten
koennen, die es seit einigen Jahren zu finden gibt und auch die
Erschliessungs-Extras im Katalog nicht so funktionieren wie ein
Browser-Plugin: Einmal konfiguriert und dann "ueberlebt" es ohne
eigenes Zutun jedes kommende Softwareupdate: Das waere doch noch
was!

viele Gruesse
Thomas Berger



Mehr Informationen über die Mailingliste Allegro