[rak-list] AACR/RAK

[Bernhard Eversberg]

Am 3.1. schrieb Roger Brisson einiges, was nicht unkommentiert stehen bleiben 
sollte:

> 
> Von meiner jahrelangen Erfahrung mit AACR2 und RAK glaube ich nicht,
> dass RAK generell als Vorbild für AACR2 hervortreten könnte. 
In manchen Punkten mag das stimmen. RAK hat aber ein Kapitel 0, das viel besser 
als das AACR glossary geeignet ist, in die Logik des Werkes einzufuehren, und das 
sie Begriffe gruendlicher und sauberer definiert. (Par. 1 und 3 muessen nur 
vertauscht werden, nebenbei gesagt.)

> Der ganze Begriff von
> Authority Control war (und ist immer noch) in RAK schwach entwickelt,
Das ist weniger eine Frage des Regelwerks als der Anwendungspraxis in einem 
Datenbank-Kontext! Das Regelwerk beschreibt, wie Ansetzungs- und 
Verweisungsformen zu bilden ist. Ob man daraus einen Authority-Datensatz macht, 
und wie dieser dann angewendet wird, ist nicht Sache des Regelwerks. 

> die Einzelbandaufführung von 'sets' ist
> problematisch angelegt, 
Aus unserer jahrzehntelangen Erfahrung, und das sollte doch wohl was bedeuten, 
laesst sich das nun gerade nicht bestaetigen, sondern eher das Gegenteil. 
"Einzelbandauffuehrung" ist ein Begriff aus der Zettel- und Listenwelt, in 
Datenbanken braucht man verknuepfte Saetze. Die Auffuehrung von Baenden in einer 
"contents note" ist antiquiert.
Nur die RAK-Methode gewaehrleistet, dass jeder Titel in gleicher Weise behandelt 
wird, und dann auch auffindbar ist, eben als Titel, ob es nun ein Gesamt- oder 
ein Bandtitel ist. Genau das leistet AACR nicht, es werden ja sogar manchmal 
Artikel weggelassen, weil man sonst keine korrekte Indexierung bekommt! Und aus 
den unstrukturierten Contents Notes kriegt man nie korrekte Titeleintraege.
AACR hat keine Entsprechung zu RAK Par.501-527 "Ansetzung von Sachtiteln", und 
fuer Datenbanken ist gerade das noch viel wichtiger als fuer Zettelkataloge.
Ferner haben AACR keine Ordnungsregeln. In RAK sind aber die Ansetzungen exakt 
daraufhin strukturiert, dass man praezise und sinnvoll (!) sortierbare Strings 
erhaelt. Von so etwas ist AACR sehr weit entfernt. (Das liegt an der Tradition, 
dass Zettel nicht von "Catalogers" eingelegt wurden, sondern von "Filers", und
das waren geringer bezahlte Hilfskraefte, fuer die man ein Extra-Regelwerk hatte, 
die "filing rules". Ja, das "filing" uebernimmt nun der Computer, aber er
ordnet nicht, er sortiert nur! Damit die Sortierung sinnvoll, also wirklich eine
Ordnung ist, muss der Sortierstring in durchdachter Weise strukturiert sein.
Hier haben AACR Defizite, die frueher von den "filers" ausgeglichen wurden,
aber die konnten mitdenken - Computer koennen das nicht.)

> Als Kataloging Code ist RAK merklich schwieriger
> zu erlernen und anzuwenden, 
Moment Moment! Eine solche Aussage wuerde denn doch einer Anzahl von Belegen 
beduerfen. RAK ist ganz klar logisch besser strukturiert, daran gibt es nichts zu 
deuten. Zu den Bemerkungen oben koennte man noch einiges hinzufuegen.

MfG B.E.




Bernhard Eversberg
Universitaetsbibliothek, Postf. 3329, 
D-38023 Braunschweig, Germany
Tel.  +49 531 391-5026 , -5011 , FAX  -5836
e-mail  B.Eversberg at tu-bs.de