[rak-list] Fragen im Zusammenahng mit MAB 451

Thomas Berger ThB at Gymel.com
Mon Aug 24 17:34:20 CEST 2009


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lieber Herr Eversberg, liebe RAK-List,


>> Nachdem ich nun auch noch die MAB1-Dokumentation konsultiert habe und
>> bei 010
>> bzw. 451ff keine wesentlichen Abweichungen zu MAB2 feststellen konnte,
>> ziehe
>> ich fuer mich folgenden Schluss: Das von mir unterstellte allgemeine
>> "bibliographische Modell", das sich auf die Auspraegung von MAB oder
>> allgemein
>> der Datenformate ausgewirkt haben soll, scheint es nie gegeben zu
>> haben und
>> ist insbesondere nicht von den RAK abgeleitet.
> 
> Es handelt sich wohl um ein ungeschriebenes Denkmodell, das aber mit nur
> geringen Abweichungen praktisch ausgeformt wurde.

das "ungeschrieben" stand stets ausser Frage (und die Datenformate wie
MAB und MARC21 betonen seit jeher ihre "Neutralitaet" gegenueber Regelwerken,
darunter ist aber wohl zu verstehen, dass das Magnetband keinen Riss
bekommt, wenn ein abweichend angesetzter Personenname transportiert wird).

Und ob es "ein" Denkmodell war, wage ich inzwischen zu bezweifeln: Die
unterschiedlichen PICA-Loesungen deuten darauf hin, dass hier ein reichlich
naives Grundformat (Aufnahmen sollen Datensaetzen entsprechen, und fuer
Absaetze der bibliographischen Beschreibung gibt es je ein Datenfeld) immer
weiter entwickelt worden ist.
["Naiv" ist dabei nicht abwertend zu verstehen, "Text mit Markup" ist meiner
Meinung nach fuer Bibliotheksdaten tragfaehiger als die Atomisierung in
kleinste Datenfelder]

Dummerweise scheint das Denkmodell von MAB [und zwar nicht in seiner real
zu beobachtenden HBZ-Ausformung, sondern eher das, das bei der Definition
Pate stand] nicht so naiv, dennoch ungeschrieben und auch nicht einfach
aus RAK ableitbar.



>> ... Vielmehr scheint jede Anwendung
>> fuer sich einen individuellen Weg gefunden zu haben, zu einer
>> RAK-gerechten
>> Auffuehrung der Baende unterhalb einer Gesamtaufnahme zu gelangen und
>> hat davon
>> ausgehend dann noch einen meist zufriedenstellenden Weg gefunden,
>> Stuecktitel
>> zu praesentieren, sofern sie sich nicht vermeiden liessen. Und vom
>> Resultat
>> her gesehen sind die Abweichungen trotz unterschiedlichster Wege dann
>> doch
>> erstaunlich gering...
>>
> 
> Wenn's aber zum Austausch kommt, können die Disparitäten schon mehr
> Ärger machen. "Bandaufführung" und "Stücktitel", das sind eben
> Zettelbegriffe, von denen zu lösen dem Denkmodell noch nicht
> recht gelungen ist, weshalb es dann Konstrukte wie "Abteilungssätze" als
> Abbilder von Zwischenzetteln als Konstrukt gibt.

... wobei dann "Zwischenzettel" wieder ein Konzept aus der Vor-RAK-Aera
ist bzw. eine niedersaechsische Spezialitaet?

Mein Eindruck ist uebrigens eher das Gegenteil: Wenn man die RAK-
Begrifflichkeiten besser in die Datenformate umgesetzt haette, waere man
manchen Umstaendlichkeiten gar nicht begegnet. Zugegeben machen die RAK
es einem auch nicht leicht: In den einstelligen Paragraphen wird ein
furchtbarer Gegensatz etwa zwischen begrenzt und fortlaufend aufgebaut,
nur um im Rest des Regelswerks sich daran abzuarbeiten, dass eigentlich
doch alles gleich ist... Und wie immer: Ein eigentlich sekundaeres Ziel
wie die Reduktion von Karten in §110 und §111 fuehrt zu einer Akzent-
verschiebung weg von den Hierarchien hin zu einer Fixierung auf die
Bestandteile, an denen man "durchlaufende" Zaehlungen festmachen kann
bzw. mit dem Kunstgriff der "hierarchischen Zaehlungen" auch erzwingen
kann)



> Leider ist von RDA wenig zu erwarten auf dem Gebiet,
> weil die Verknüpfung zwischem dem Teil und dem Ganzen kaum thematisiert
> wird und weil Darstellungsfragen an der Nutzungsoberfläche in der
> AACR/MARC-Tradition weitgehend den Programmierern überlassen werden.
> Schauen Sie sich die "RDA Element Analysis" an:
>   http://www.rda-jsc.org/docs/5rda-elementanalysisrev3.pdf
> Kein Wort über mehrteilige Publikationen, und unter "Series statement"
> nur die altbekannten Elemente, keine Verknüpfungsnummer. Und das
> famose Entity-Relationship-Diagramm
>   http://rdaonline.org/Manifestation_6_1_09-1.pdf
> für die Manifestation läßt nicht erkennen, daß man die Teile einer
> mehrteiligen Veröffentlichung irgendwie verknüpfen wollte, falls man
> sie denn als solche mit eigenen Datensätzen bedenken würde, was daraus
> ebenfalls nicht hervorgeht, oder ins Gesamtbild gar nicht recht paßt.

Da lobe ich mir doch die ISBD. Hier kommt man mit wesentlich weniger
Begriffen aus, die (fuer mich zumindest) besser verstaendlich sind und
doch recht flexibel und tragfaehig erscheinen:
"Items without collective title" einerseits und Falle mit "common
title" sowie "dependant title" (fuer jegliche Untergliederung)
andererseits. Damit geht fast alles, was auch die RAK koennen (insbesondere
also viel mehr als MAB), und was nicht geht, kommt in eine Fussnote.
(Der Verzicht auf Ansetzungstitel schmerzt natuerlich, ist aber auch in
Deutschland ausser bei Zeitschriften ebenfalls schon laengst Praxis).

Wie man guenstig verknuepft (und welche Texte / Felder so eine
Verknuepfung dann repraesentiert oder ersetzt) ist natuerlich von den
ISBD ausgehend genauso wenig klar oder kanonisch wie von RAK oder
AACR2.



> Im GBV-Land hat man immerhin vor Jahren schon begriffen, daß es keiner
> mehrstufigen Hierarchien bedarf, um eine plausible Sortierfolge der
> Teile eines Ganzen zu erreichen, sondern nur geschickter
> Sortierzählungen. Konsequent wurden die vormals bis zu 6stufigen

Mit kohaerenten Zaehlungen kann man sogar einen uebergeordneten
Datensatz "treffen", obwohl man "nur" mit einer gemeinsamen Ueberordnung
verknuepft hat (Besitz einer Zusatzinformation, naemlich ob es einen
treffbaren Datensatz gibt, ist dabei allerdings hilfreich)


> Hierarchien rigoros eingeebnet. So mag denn zwar eine Gesamtanzeige
> beim GBV derjenigen von Hebis (Abteilungssätze!) recht ähnlich sehen,
> aber die Daten dahinter sind es weniger, der Austausch also überraschend
> schwierig.

Das Ungemach lag m.E. nicht in den Abteilungssaetzen selbst, sondern
im Zwang, mit der "unmittelbar uebergeordneten Einheit" zu verknuepfen.
Die dafuer erforderliche Rekursion, um bis zur Gesamtaufnahme zu gelangen,
ist kein unueberwindliches Problem (nur etwas laestig), es entsteht damit
aber ein (scheinbarer?) Zwang, Information auf mehrere Datensaetze zu
verteilen (Stichwort "hierarchische Zaehlung"), die auch nach RAK
besser beim untergeordneten Element verblieben waere. Resultat ist
mehr redundante Erfassung fuer den Katalogisierer und die Maschine hampelt
ziemlich sinnfrei durch die Rekursionsstufen. Beim Versuch, das wiederum
zu optimieren, entstehen dann so fragwuerdige Beispiele wie in der
HEBIS-Anweisung (die man fuer ihren Mut zum wunden Punkt nicht genug
preisen kann), wo naemlich alles einen eigenen Datensatz bekommt, bis
auf die Hauptaufnahme des untergeordneten, eigentlich "ganz normalen"
zweibaendigen Werks. Arme Erwerbungskatalogisierer...


viele Gruesse
Thomas Berger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBSpKy/GITJZieluOzAQLOnAQAhP6VYsRylcO+EnchVMe4TF3QGdgqM5+/
pydjiJZ3b5fCnEK/aWIYGP9j5hDbXwPUJ09pmOZ0T7FpZ57rEy3voHM927vvmEVr
iFJsunHnuiixSI1hoDdkxhOxjOrfxoa5AyVGAZnvDbsSKfCz8JuBo7u1U5YmG2mQ
k3WCsp/Udg8=
=MmY8
-----END PGP SIGNATURE-----


More information about the rak-list mailing list