[Allegro] MARC21-XML 700 als EST / bevorzugter Titel eines Werkes
Thomas Berger
ThB at Gymel.com
Fr Feb 5 16:47:24 CET 2016
Am 05.02.2016 um 12:03 schrieb Bernhard Eversberg:
> [...] Rigorismus gepaart mit
> Perfektionsanspruch führt zu keiner real erreichbaren Lösung. Sehen Sie denn
> eine andere Baustelle neben Bibframe? Und hat nicht LC MARC für obsolet erklärt
[k]eine? Die Regelwerke sind doch eher die groessere Baustelle.
> und BF zum Ausweg aus der Misere? Es sieht noch nicht danach aus, wohl wahr,
> aber warten Sie mal 5 Jahre. Auch MARC hatte am Beginn massive Skepsis gegen
> sich. Den Fehler mach ich nicht nochmal. In unserem Universum gilt, was LC sagt
Weiss nicht, 1966 war ich noch nicht dabei. Und Sie, glaube ich, auch
noch nicht...
> und tut, dem hat sich ja auch DNB gefügt. MARC muß weg weils außerhalb
> Libraryland keiner versteht, BF ist Mainstream und nichts anderes kann Erfolg
> haben. Gefallen muß es einem deswegen noch nicht und tut mir MARC noch heute nicht.
MARC (und alle unsere traditionellen Formate) haben Grenzen in der
Ausdrucksfaehigkeit. RDF (und damit auch Bibframe) noch viel mehr.
Das ist der Preis den man bei der Abbildung (noch fast) natuerlicher
Sprache in ein formales System bezahlt; fuer das was uebrig bleibt,
gewinnt man dafuer an Verarbeitbarkeit. Ich moechte das mal als
Erfassung der "bibliographischen Eckdaten" bezeichnen und die
"bibliographische Beschreibung" dagegen setzen: Fuer diese haben
wir noch nie eine adaequate Ausdrucksform gefunden, zu viele Erkenntisse
befinden sich nur im Kurzzeitgedaechnis des Katalogisierers und
finden keinen Niederschlag in Aufzeichnungen seiner Taetigkeit,
vulgo Katalogisaten oder Datensaetzen.
In 98% der Faelle kann man auch mit Bibframe-Beschreibungen gut leben,
da ist kein Verlust gegenueber MARC (plus die Vorteile, die RDF hat).
Und von den restlichen 2% duerfte ein Grossteil auch in MARC nicht
adaequat beschreibbar sein. Das eine setzt den Fokus auf "Daten",
das andere auf "Text", unsere Beschreibungen sind nach meiner
Ueberzeugung aber vielschichtig, nicht nur weil sie die Bruecke zwischen
Darstellung und "Ansetzung" schlagen, sondern weil der Katalogisierer
das Ganze noch annotiert, um ansonsten zu ueberraschende Ergebnisse
zu belegen oder erlaeutern.
Die Regelwerke haben weiterhin den Anspruch, "alles" regeln zu koennen
(eher theoretische Texte wie FRBR sind da vorsichtiger, sie modellieren
eingestandenermassen eine "bibliothekstypische" Weltsicht ohne sich
dazu zu aeussern, wie vollstaendig oder wie real die sein mag). Die
Regelwerke sind aber auch formatunabhaengig (wobei die RDA immerhin
das erste Regelwerk sind das behauptet, dass man nur mit Schreib-
maschine und Papier keine regelgerechten Beschreibungen produzieren
kann, denn "Normdaten" sind latent eingebaut).
Formate beanspruchen weiterhin fuer sich, regelwerksagnostisch zu
sein. Bibframe kennt etwa die Klassen Work und Instance (und evtl.
Item), wie man die vier Gruppe-1-Entitaeten der FRBR darauf
abbildet, um RDA-Daten mit Bibframe zu codieren, soll anderswo
geregelt werden.
Ich sehe da nun in erster Linie einen Zielkonflikt: RDA entfaltet
bekanntlich sein Potential erst, wenn MARC ueberwunden ist. Und
die geplante Ueberwindung durch Bibframe ist vom Ansatz ziemlich
radikal, Dinge wie sie die LC derzeit produziert, etwa
bf:extent "289 p. :"
zaehle ich da nicht zu, das ist immer noch die gute alte
Schreibmaschine, wie wir sie von
<datafield tag="300" ind1=" " ind2=" ">
<subfield code="a">289 p. :</subfield>
...
</datafield>
kennen. Setzt man aber konsequent auf "Daten", verzichtet dementspre-
chend weitgehend auf jegliche Binnensyntax, dann verlieren wir die
Ebenen der Beschreibung, die bislang einigen Menschen, aber nicht den
Maschinen zugaenglich war, und die die MARC-Records noch enthalten.
Man mag die eckig geklammerten Zusaetze so verabscheuen wie MARC,
und sie sind gewiss nicht mehr zeitgemaess, aber sie *haben*
Information transportiert, und diese Information zu transportieren
wurde vom Regelwerk auch verlangt (die Form natuerlich nicht unbedingt).
(Konsequent "Text" ist der MARC-Weg, die Unterfelder sind ja keine
Unterfelder, sondern in Wirklichkeit nur eingestreute Tags: Damit
kann man viel machen, aber auch da sind die Grenzen klar)
Man hat nun viele Moeglichkeiten, z.B. syntaktische Ungetueme bauen,
die MARC-records "treuer" abbilden koennen (wird derzeit wohl nicht
befolgt, der Bibframe 2.0 Entwurf ist eher noch schlanker), die
Anforderungen auf Regelwerksebene reduzieren (hierzulande waren
die Verbuende ueberhaupt nicht amused, als die DNB ihre Plaene
fuer die nationalbibliographische Verzeichnung offenbarte, bislang
dachte man, das sei mehr als das "Normale", beabsichtigt war aber
weniger...) oder eben - und das ist mein Standpunkt als Variante
des "if all you have is a hammer ..." - /eine/ Beschreibungssprache
eben nicht doch /alle/ Anforderungen abdecken kann und daher
Vorkehrungen getroffen werden muessen, mit dem einen Prozent
umzugehen, die das offenbaren - nicht dass wir da in ein Loch
fallen. Wobei das in einer konkreten Bibliothek evtl. 0% sind
und nebenan 20%, gerade die RDA ermoeglichen es ja, von der
Einheitserschliessung abzuruecken und naeher an den Beduerfnissen
der eigenen Clientel zu agieren...
viele Gruesse
Thomas Berger
Mehr Informationen über die Mailingliste Allegro