[Allegro] In the dawn's early light

[Thomas Berger]

Lieber Herr Eversberg, liebe Liste,

> neue, ganz andersartige Datendarstellungen. Die taugen dann
> viel besser zum Verlinken quer durch's Netz und rund um den Globus,
> und es sollen sich damit die zu einer Anfrage passenden Aussagen
> über "Ressourcen" eigendynamisch zu einem jeweils passenden Gesamtbild fügen,
> statt wie bisher den Nutzer mit einheitlichen, festgefügten
> Textblöcken abzuspeisen, wie es Datensätze nun mal sind. Anders
> gesagt, nicht den MARC-Nummern ist der Garaus angesagt, sondern
> dem altvertrauten Konzept des bibliographischen Datensatzes als Surrogat
> für die Ressource, sozusagen eines elektrifizierten Katalogzettels,
> der ja noch kaum aus dem Schatten des langen 19. Jahrhunderts
> heraustritt.

So wie ich das mitbekommen habe, gilt die "Kampfansage" weder
dem einen noch dem anderen. Nur gibt es halt viele Probleme
mit MARC21 (einfach nach "MARC must die" googlen) und die
koennen eher nicht durch eine "Verbesserung" des Formats
geloest werden.

Das Konzept des "Datensatzes" steht insofern auf dem Pruefstand,
als dass durch FRBR und RDA mittlerweile geklaert ist, dass
der ohnehin aus verschiedenen logischen Schichten oder Ebenen
besteht, die man sauberer als frueher voneinander trennen
sollte, damit Records zu verschiedenen Ressourcen, die aber
(in einem durchaus spezifizierten Sinn) ~irgendwie~ miteinander
zu tun haben, einerseits sauber auseinander gehalten werden
koennen, andererseits aber zueinander finden koennen.

Man muss auch immer wieder darauf hinweisen, dass alle diese
Unternehmungen von der Situation in MARC21/AACR2-Land ausgehen,
insbesondere von der Praxis der MARC21-Anwendung und nicht
dem Potential. D.h. /Verknuepfungen/ gibt es nur in seltenen
Faellen, z.B. von Aufsaetzen zum enthaltenden Werk oder
u.U. von Stuecken zum Reihentitel. Bandauffuehrungen gibt
es nicht (nur Fussnoten mit den Bandbenennungen in der
Hauptaufnahme). Umgekehrt - und das geht weit ueber unseren
Erfahrungshintergrund hinaus - ist das Format so flexibel,
dass in einem Record Erschliessungen nach unbeschraenkt
vielen offiziellen oder lokalen Regelwerken hinterlegt werden
koennen, ohne sich in die Quere zu kommen. Das heisst fuer
den Anwender einerseits, dass er - anders als hierzulande -
seine Privaterschliessungen im Verbund hinterlegen kann,
andererseits aber auch, dass normalerweise nicht "der"
Datensatz genutzt (indexiert, angezeigt, ...) wird, sondern
eine fuer das Zielsystem gefilterte Sicht.

Abgesehen von der Beschraenkung auf 99999 Bytes pro Datensatz
laesst sich damit bequemer leben als mit MAB2 (und alle
"unsere" Internformate haben MAB2 und seine Vorgaenger als
geistige Eltern, d.h. wenn ich "MAB2" sage, dann meine ich
alle allegro-Formate und auch PICA und was auch immer: Alle
sind urspruenglich unter der Annahme entstanden, dass ein
"Datensatz" eine - mehr oder weniger kohaerente - Sicht
auf das aussagbare zur Ressource enthaelt, Pluralismus kommt
eher ueber damit verknuepfte Lokalsaetze etc. ins Spiel,
fuer Normsaetze aber haben wir so ein Konzept gar nicht).

Dies stoesst aber /organisatorisch/ an seine Grenzen, wenn
es nicht um die klassischen Top-Down-Modelle des "Datentauschs"
geht (aktuelle "Vision": Alles ist in der OCLC-Cloud oder
der Exlibris-Cloud als "Master record" und diffundiert von
dort aus "nach unten"), sondern um das, was derzeit durch
das Wort "Anreicherungen" etwas diffamiert wird: Wenn ich
/regelmaessige/ Aktualisierungen erhalte und die nicht
aus /exakt einer Quelle/ stammen (etwa weil ich lokale
Aenderungen vornehme, die nicht im "Verbund" hinterlegt
sind), dann muss ich nach jedem Update alles kontrollieren
und im Zweifelsfall neu machen. Eine Strategie dafuer ist
wie gesagt, "eigene" Aenderungen immer nur "moeglichst weit
oben" vorzunehmen und dann das Top-Down-Update abzuwarten.
Abgesehen von der dadurch entstehenden Bremse im
Geschaeftsgang ist das aber ein ungut biblothekarischer
Ansatz, denn er funktioniert nur, wenn alles, was ich
fuer erwaehnenswert halte, "in der Cloud" bereits mit
den entsprechenden Datenfeldern und -strukturen vorbereitet
ist und auf meine Eingaben harrt.

Wenn man andererseits akzeptiert, dass meine Verzeichnungswuensche
von morgen eventuell nicht rein bibliothekarisch motiviert
sind, sondern die Beduerfnisse der speziellen Nutzerschaft
der konkreten Bibliothek realisieren (Verlinkung auf andere -
nichtbibliothekarische Bestaende - im Haus, Verlinkung
auf eine Fachdatenbank oder selbst erstellte / digtialisierte
und erschlossene historische Fachinformation, ...), dann
ist es a) so, dass das heute u.U. noch nicht bekannt ist
und b) die Top-Down-Speicherung an ihre Grenzen stoesst (ich
muss es dort manuell eintragen, ich muss evtl. Codes registrieren,
ich kann nur Text eintragen und nicht andere Datentypen, kann
also die Eingaben nicht validieren etc. pp. Kurz: Ohne den
Anbietern der grossen Bibliothekssysteme auf den Schlips treten
zu wollen glaube ich einfach nicht, dass diese Systeme auf
absehbare Zeit eine Loesung fuer allgemeine Datenverarbeitungs-
oder auch nur Datenbankaufgaben darstellen werden - sonst
waeren die Aktienkurse von Microsoft und Oracle und anderen schon
laengst abgestuerzt...). Wenn ich nun aber weiss, dass Quelle X
einen fuer mich interessanten Datenbestand bereits erschlossen
hat, aber nicht in der Cloud hinterlegt hat, dann habe ich
u.U. das Beduerfnis, diesen Bestand bei mir ebenfalls nutzbar
zu machen: Schwupps habe ich /regelmaessigen/ Datenimport aus
mehr als einer Quelle und das funktioniert nur (in heutiger
Sprache), wenn ich Aenderungen auf "Feldebene" nachvollziehen
kann, was ganz schwierig wird, wenn manche Eintraege entfallen
(man denke an die URL von Projekt X im "Record": Dort ist es nur
eine unter vielen, bei einem Update muesste sie gezielt veraendert
oder sogar "auf einen anderen Record uebertragen", d.h. hier
geloescht werden). In aktuellen Diskussionen wird dieser Aspekt
meist "metadata provenance" genannt.

In solchen Szenarien ist es immer noch so, dass ich den "Datensatz"
als Container fuer alle Aussagen zu einer Ressource kenne, aber
im Prinzip jede Einzelaussage zwar nicht unbedingt individuell
adressieren koennen will, jedoch anhand gewisser, "feldspezifischer"
Verwaltungsdaten einen Zugriff vorbehalten moechte. RDF gibt da
einen Ansatz (Einzelaussagen werden als abstrakte Graphen
aufgefasst) und nach meinem Verstaendnis versucht Bibframe,
solche Ansaetze auf die bibliothekarisch-bibliographische
Situation umzusetzen: D.h. Es gibt Entitaeten, die den von
FRBR/RDA modellierten entsprechen, beschrieben werden diese
aber durch Einzelaussagen a la RDF und die Hoffnung ist, dass
so etwas dann einerseits quasi adhoc von jedermann lokal
um beliebige nichtbibliothekarische Aussagen angereichert werden
kann und andererseits alles so auf die Reise geschickt werden
kann, dass das Aufeinanderprallen von Beschreibungen aus
verschiedenen Quellen in meinem Lokalsystem eben nicht mehr
die Entscheidung zwischen Verlust, unbrauchbarem Mischmasch
und/oder extensiver Nachbearbeitung erfordert.


viele Gruesse
Thomas Berger