[Allegro] Welche Prioritäten beim RDA-Import?

Thomas Berger ThB at Gymel.com
Mi Apr 29 18:10:01 CEST 2015


Lieber Herr Eversberg,

> D.h. wir erhoffen uns nun Rückmeldungen, welche Elemente unsere
> Anwender für besonders wichtig und welche Änderungen sie für
> vordringlich halten würden. Nicht nur für die Datenelemente selbst,
> sondern dann auch für Indexierung und Anzeige.
> Wie ist es etwa mit dem neuen Unterfeld $B bei den Personennamen,
> wie man es z.B: hier sieht:
> 
> 3000    !PPN!Heuss-Knapp, Elly*1881-1952*$BVerfasserIn$4aut
> 3010    !PPN!Heuss, Theodor*1884-1963*$BIllustratorIn$4ill
> 
> Dazu ist auch zu bemerken, daß die für's a-Format typische Aufteilung
> der Personentypen auf knapp 20 verschiedene Felder sicher schon
> längst nicht mehr zeitgemäß ist; und wenn der Personentyp in einem
> Unterfeld steckt, würde es natürlich reichen, alle Personen etwa
> in #42 (Mitwirkende) zu versammeln. Dieses Thema, d.h.
> Funktionsbezeichnungen ja oder nein, und wie damit umgehen, war
> schon lange vor den RAK2-Bemühungen virulent. Damals wurde nach
> engagierten Diskursen gegen solche Differenzierungen entschieden.
> Das war mit ein Grund gewesen für den Ansatz im a-Format. Nun will
> sich das Blatt also wenden - und wir uns mit?

Mir scheint, irgendwie zaeumen Sie das Pferd von hinten auf:

Die letzte Frage, naemlich ob die vorhandenen Felder (in den vorhandenen
Bedeutungen) RDA- bzw. insbesondere RDA-D-A-CH-kompatibel sind, waere ja
zuerst zu beantworten.

Erstens ist dafuer die FRBR-Unterscheidung abzuklopfen (in D-A-CH
ist das in die Wortwahl hineincodiert, bzw. man muss im Kopf
behalten, im Kontext welchen RDA-Kapitels die Beziehungen definiert
werden. Betroffen sind eigentlich stets nur die Werk- bzw. Expression-
ebene, Beteiligungen auf Manifestations- (Coverillustratoren, Verlage)
oder Itemebene (Vorbesitzer) werden ja traditionell und auch nach RDA
allerhoechstens optional behandelt.

Ich sehe da z.B. einen moeglichen /Bruch/ bei #50 fuer den "Illustrator",
der ist aber m.E. im Regelwerk: Ein Kuenstler ist der Urheber der
in einem Bildband ueber ihn abgebildeten Werke, d.h. der Druck ist nicht
anonym und ueber ihn, sondern enhtaelt (papierne, reproduzierte) Expressions
seiner Werke, ist also vergleichbar einer Lyriksammlung, die wird auch
traditionell unter dem Autor angesetzt... Es gibt aber auch klassische
Illustratoren, die fuer eine konkrete Ausgabe ein paar nette Illustrationen
hergestellt haben, die sind dann natuerlich keine Urheber (des Drucks,
nur der netten Illustrationen, die werden aber nicht einzeln verzeichnet).
Die Konsequenz des Bruchs ist nach meiner Meinung, dass wir in Zukunft
auch in #40 mit Funktionsbezeichnungen rechnen muessen, wobei immer noch
die Frage ist, ob man das fuer die /Darstellung/ ("Kopf") unterdrueckt,
*wenn* es um die Urheberschaft geht (zumindest bislang gab es in AACR2/MARC
die Funktionsbezeichnung "Komponist" nur dann, wenn der Komponist in
sekundaerer Funktion stand, d.h. er ein Lied vertont hat und diese Noten
im Zusammenhang mit dem Lied abgedruckt wurden. Umgekehrt gab es
"Textverfasser" oder "Librettist" nur dann, wenn das Werk als Komposition
behandelt wurde, d.h. der Komponist ist Verfasser (und wird eben nicht
als Komponist gekennzeichnet), der Librettist ist in dem Fall sekundaer
und wurde daher Librettist genannt. Alles klar?) Jedenfalls gehe ich
davon aus, dass fuer Musikdrucke auch in allegro der Komponist nie
nach #52 gegangen ist, sondern nach #40. Bei Auffuehrungswerken bin
ich mir da nicht so sicher, aber nach RAK wurden Klassik-CDs unter
dem Komponisten /angesetzt/, es bleiben die mit mehreren Komponisten
als Sammelwerk, wo ja Dirigent, Orchester und Solisten auch noch
untergebracht werden mussten. Ist Bolero da nah genug an A.CFG um
die Loesungen dort zur Kenntnis zu nehmen?

Leider ist mir unklar, worum es insgesamt geht, d.h. die Gesamtschau der
Beziehungen bzw. Benennungen und Codes fuer diese Beziehungen (Appendix
I der RDA) als D-A-CH-verbindliche Tabelle. Ich erwarte eigentlich, dass
da irgendwann einmal unter < https://wiki.dnb.de/display/RDAINFO/Regelwerk >
ein entsprechendes Dokument auftaucht. Derzeit behelfe ich mir mit den fuer die
GND festgelegten Beziehungscodes, vgl. den Download bei <
http://www.dnb.de/SharedDocs/Downloads/DE/DNB/standardisierung/inhaltserschliessung/gndCode.pdf
>

Den D-A-CH-Anwendungsregeln zu RDA I.3.1 entnehme ich, dass in Zukunft
kein Unterschied mehr zwischen #57a, #43 und #41 gemacht wird, wobei
"Redakteur" in der allegro-Praxis vermutlich ohnehin meist in #41 oder #43
erfasst worden sein duerfte (erfasst wurde ja die "Herausgeberschaft" als
Prinzip und die Formulierung der Vorlage, die ja u.U. sogar fremdsprachig
ist, diente dabei als wichtiges Indiz, aber auch nicht mehr)

Ein Teil der #41er und #42er wird hingegen nach #40 abwandern.

#47 sowie die meisten #5er sind eindeutig nur an der Expression beteiligt
(jemanden, der zum eigenen Werk das Vorwort schreibt, haette man nie
zusaetzlich als Vorredner verzeichnet).

#42 ist schoen unspezifisch, in der Praxis wird es hier allerdings einen
Bruch geben, denn bislang hat man eher nicht unterschieden, ob die Mitarbeiter
einzeln unterscheidbare Anteile hatten, in dem Fall waere #57 evtl.
einschlaegiger gewesen. Nun ist es wichtig geworden, ob sie einen Beitrag
zum Werk oder zur Expression leisten (die Logik dabei: Wenn sie Schoepfer
eines identifizierbaren Teils sind, dann ist das ein eigenstaendiges
Werk, das in einer bestimmten Expression Teil der vorliegenden Expression
ist. Auf das vorliegende angewandt werden sie also wegen der Teil-Ganzes-
Beziehung im Werk-Expression-Manifestation-Item-Gefuege oft um eins
herabgestuft. Das eher so als Faustregel, es gibt durchaus Werke, wo diverse
Verfasser aufeinander aufbauende Kapitel beisteuern, da sind sie natuerlich
gemeinschaftliche Schoepfer, auch wenn sich ihre Anteile identifizieren lassen.
Solch ein isoliertes Kapitel ist fuer sich genommen auch nicht unbedingt ein
eigenstaendiges Werk, genaueres klaert aber vermutlich erst die FRBR-Revision
von 2017...)

Also, fuer mich ist nicht klar, wie was geloest werden kann, man muss wohl
noch gruendlicher hinschauen: Es scheint nichts fundamentales dagegen zu
sprechen, die vorhandenen Felder auch unter RDA-Bedingungen weiter zu nutzen,
man wird sie natuerlich in vielen Faellen anders oder auch bewusster nutzen,
falls man einen sehr einfachen Fall hat oder eine sehr ausfuehrliche #39
kann man evtl. auch ohne Autopsie nach RDA umkatalogisieren (intellektuell,
nicht maschinell). Umgekehrt hat die allegro-Methode der differenzierten
Personenfelder schon lange keinen Vorteil mehr:
1. nachdem man schleichend angefangen hatte, bei Bedarf mehr als eine Person
   bzw. drei Verfasser) zu erfassen, insbesondere wenn sie verschiedene
   Rollen hatten, wurde
2. Reihenfolge und Formulierung der Vorlage wichtig, d.h. Belegen von #39 ist
   eigentlich schon laengst wieder selbstverstaendliche Pflicht.
3. Mehrere Rollen /einer/ Person (in RDA explizit als Aufzaehlung von
   Funktionen vorgesehen) kann das A-Schema nicht gut behandeln
Drittens aber scheint mir die Moeglichkeit, alles in zwei Felder zu packen, so
wie es die PICA-Systeme anscheinend tun werden (Hm. vielleicht im SWB, ILTIS
hat m.W. ein paar mehr) sehr un-RDA-haft. Mindestens die Unterscheidung in
"geistiger Schoepfer", "sonstig werkbezogene Rolle", "expressionbezogene
Rolle" sollte sich m.E. im Datenformat niederschlagen, sonst wird die
Aufspaltungsmoeglichkeit der Manifestation-Level-Records in ihren Werk- bzw.
Expressionsanteil fuer Matching oder Linking mit vergleichbaren Saetzen
in der Praxis doch sehr schwer. Andererseits packen MARC und MAB es
insgesamt nur in i.W. ein einziges wiederholbares Feld und das geht
auch. Andererseits ist das gewiss einer der Stellen, wo die "RDA ihr
Potential nicht entfalten koennen", solange mit den alten Formaten
transportiert (und katalogisiert) wird.

Nachdem wir das also nicht haben klaeren koennen, geht es weiter mit
den Einzelfeldern: D-A-CH wird also die Codes fuer verbindlich erklaeren,
bzw. deklariert, dass fuer den Datentausch die textliche Benennung der
Funktion redundant ist. Was das fuer allegro bedeutet bzw. fuer eine
einzelne Allegro-Installation, muesste ausgelotet werden. Nettes Feature
waere, wenn man nicht-D-A-CH-Fremddaten mit nicht codierten, fremdsprachigen!
oder abweichend codierten Kennungen erst einmal importieren koennte um
sie dann in allegro auf den eigenen Standard umzuarbeiten. Das setzt
m.E. voraus, dass das Standardformat nicht zum D-A-CH-Buettel werden darf
und etwa nur Codes vorsieht, weil die Labels dazu errechnet werden koennen.
Umgekehrt nur Labels und keine Codes vorzusehen, ist manchen evtl. nicht
strikt genug: Es ist ja in jedem Fall ein kontrolliertes Vokabular,
Anwender sollten ihr allegro zumindest so einstellen koennen, dass Frei-
Schnauze-Eingabe von Funktionsbezeichnungen weitgehend unterbunden wird
und daher garantiert ist, dass spaetere Exporte tatsaechlich zu jedem
Eintrag anhand des Klartexts den D-A-CH-Code generieren koennen.
Erlaubt man sowohl Codes als auch Klartext, muss man mit den zwangslaeufig
entstehenden Divergenzen umgehen koennen: Manche sind evtl. echte
Inkonsistenzen, andere Verfeinerungen der Codes bzw. reflektieren die
Wortwahl eines anderen Regelwerksstands. Manche sind echter Mehrwert
und daher heilig, andere duerfen jederzeit ueberschrieben oder neu
errechnet werden: Alles ist moeglich und ich befuerchte, da wird sich
allerhand Unordnung in den Datensaetzen ansammeln und zum Schluss werden
da einige Datensaetze sein, von denen niemand mehr weiss, was angesichts
in sich widerspruechlicher Erfassung denn nun tatsaechlich Sache war...

Was /technisch/ passiert, kann man etwa an <
https://wiki.dnb.de/pages/viewpage.action?pageId=106039253 > erkennen:
* MARC 21 kennt $4 und $e, die D-A-CH-Festlegung ist, dass $4 "gilt"
  und $e eine Servicefunktion hat
* PICA nennt das MARC-$e fuer sich $B
* ASEQ hingegen kennt nur $4
* MAB-erweitert faehrt weiter rein mit Funktionskennzeichen, die sind
  nun aber nicht mehr abgekuerzt und auch wiederholbar und verbindlich
  in ¬[...]¬ eingeschlossen.

D.h. eigentlich kann das in allegro auch so gehalten werden: Weiterhin
¬[...]¬ am Ende der #4er- und #5er-Kategorien, zumindest wenn die
Beziehungskennzeichnung vom zu definierenden "Standard" fuer das
Feld abweicht, und optional angehaengte $4 fuer die Funktionscodes...


viele Gruesse
Thomas Berger







Mehr Informationen über die Mailingliste Allegro