[rak-list] Personennamen: von RAK zu RDA

[Thomas Berger]

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

Lieber Herr Croissant, liebe Liste,

>> - - (22.19) die "distinguishing Terms" je nachdem, ob sie fuer einen Namen
>> mit
>>   - salopp gesagt - Komma oder ohne Komma gelten, entweder mit einem
>>    weiteren Komma oder in runden Klammern angehaengt werden.
>>   [Erfassung in MARC 21 wohl stets in $j]
>>
>>
> Zu $j ein Wort der Vorsicht: $j wird in MARC 21 Authorities Format als
> "Attribution qualifier" definiert, und man könnte meinen, dass $j gerade in
> den hier besprochenen Fällen anwendbar sei. In der Praxis sieht es aber
> anders aus:
> 
> $j wurde im Jahre 2000 geschaffen für die speziellen Bedürfnisse von
> Katalogisierern aus dem Bereich der Kunstgeschichte; sie wollten in ihren
> bibliographischen Datensätzen Zugriffspunkte für sonst anonyme Künstler
> haben, von denen man nur wusste, dass sie im Atelier eines bekannten
> Künstlers tätig waren, oder ansonsten eine Beziehung zu einem bekannten
> Künstler hatten. Ansetzungen, die ein $j enthalten, werden unter
> Bestimmungen gebildet, die nicht zu AACR2 bzw. RDA gehören. Bisher werden
> auch meines Wissens keine Normdatensätze für solche Personen angelegt.

o.k. X00 $j ist also nicht in Bezug zu AACR 22.19 zu denken bzw.
umgekehrt, zur Abbildung von AACR2 genuegen die traditionellen
$a $b $c $d (und $q)


> - - offen bleibt, wieso nach AACR2 die Form
>>
>> $a Chopin, Frédéric, $d 1810-1849 $c (Spirit)
>>
>> ist und nicht
>>
>> $a Chopin, Frédéric, $c (Spirit)
>> oder meinetwegen mit Datum
>> $a Chopin, Frédéric, $c (Spirit), $d 1810-1849
>>
> 
> ich erkläre das so: $d 1810-1849 gehört zu der Identifizierung eines
> bestimmten Frédéric Chopins und folgt deswegen direkt auf den Namen. Der
> "Geist" in diesem Fall behauptet, der Geist von eben diesem Frédéric Chopin
> zu sein; folglich setzt man den Zusatz (Spirit) hinter die Lebensdaten und
> nicht davor.
> 
> Jedenfalls erliess Library of Congress gerade in den letzten Tagen eine
> Anweisung über die Reihenfolge der Unterfelder, die auch zu der Stellung
> des Zusatzes (Spirit) spricht:

...

Es bleibt schwierig:
1. Es gibt AACR2-Regeln zur Montage einer Zeichenkette fuer die Ansetzung
   anhand einer bestimmten Abfolge von Teilueberlegungen
2. Es gibt NACO-Regeln fuer das Taggen solcher Ansetzungen in MARC21
Das ist bereits miteinander verzahnt, nicht jedes Komma wird durch einen
Subfield-Delimiter begleitet. Im Prinzip muss man also waehrend der
Abfolge der Einzelschritte bei der Bestimmung der Ansetzung bei
bestimmten, in AACR2 klar definierten Zaesuren ein MARC-Subfield-Tag
einfuegen. Das ist effizient und macht Sinn.

[Es gibt moeglicherweise auch "neutrale" NACO-Regeln fuer die
Erfassung von Namen nach beliebigen Regelwerken. Wenn das mit dem
Ergebnis der /Vorgehensweise/ nach AACR uebereinstimmt, kann man das
ebenfalls als AACR kennzeichnen, auch wenn es ggfls. anders
zustande gekommen ist. Die meisten modernen Namen machen ja
ueberhaupt keine Probleme und weil fast alle "Additions" als $c
codiert sind sieht man dem Resultat auch dort nicht unbedingt
an, ob genau entsprechend der Kategorien und Reihenfolge von AACR
22.X gearbeitet wurde]

Im RDA-Kontext sind die Regeln abstrakter, die alten AACR-Regeln sind
so transformiert, dass zunaechst einmal Datenelemente (das erste
davon der bevorugte Name) 1. bestimmt, 2. nach Regeln erfasst
und 3. beiseite gelegt werden. Ganz zum Schluss werden diese
Datenelemente (unter Beruecksichtigung dessen, was gesammelt werden
konnte) dann a) in eine bestimmte Reihenfolge gebracht (9.19) und
b) mit einer gewissen Syntax zur Ansetzung montiert (Appendix E).

Offensichtlich ist dabei schon der Bedarf fuer eine Ausnahmeregel:
Obwohl die Lebensdaten Prioritaet vor dem vollstaendigen Namen haben,
wird die Reihenfolge getauscht, wenn man unter den Optionalen
Regeln beides zu erfassen wuenscht (Besser so eine Ausnahme als
fuer die Priorisierung und die Montage zwei verschiedene Reihenfolgen
festzulegen. Die von Ihnen zitierte Handreichung tut im Prinzip
aber genau das: Beim Umsetzen einer RDA Ansetzung in MARC-Felder
nach NACO kann man gewisse Abkuerzungen nehmen "$d immer am
Ende, nur $c (Sprit) noch weiter nach hinten ziehen" und daher
strenggenommen auch komplett auf die Anwendung von 9.19 verzichten).

Fuer die RDA heikel wird es bei "Geist", das im /gleichen/ Datenelement
wie "Heiliger" landet, die RDA haben da m.E. gar nicht die Moeglichkeit,
dies fuer die Montage der Ansetzung an unterschiedliche Stellen zu
bringen...

Auch bei den Mitgliedern adliger Familien wird es m.E. schwieriger,
weil die AACR2 sozusagen algorithmisch auf die in vorangehenden
Schritten bereits erarbeitete unfertige /Ansetzung/ zurueckgreifen
koennen, die RDA hingegen, gerade weil sie sauberer zwischen dem
Namen und der erfassten Form unterscheiden und waehrend der Ermittlungs-
phase auch modernerweise die Montage der "Ansetzung" noch gar nicht
begonnen wurde, kommen da ins stolpern: Durch die Kompartimentierung
ist nicht mehr unbedingt klar, ob es sich ueberhaupt vermeiden
laesst, dass ein Adelstitel sowohl ueber den gebildeten Namen als
auch ueber das Zusatz-Element Titel quasi doppelt in die Ansetzungs-
zeichenkette einfliesst.

viele Gruesse
Thomas Berger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iJwEAQECAAYFAlEnoN0ACgkQYhMlmJ6W47NYbgQAjQ0xFD/wgX1FbHoSXHHCFxSz
As6JverOlQX1eQZOKM00W6dpMakk7bnDrYEX2yKmxShh9hLczz4/KUsVRSNbF9zX
h6zpZm1EMDj/ADQxVQR5sUML4dEuCrlG1ixIBSm0JfgAiD0Vm+dnwZxnK6n+Hjhl
CdtIkvVAgSq8xgVASjI=
=Ejl0
-----END PGP SIGNATURE-----