[Rda-info-liste] (ThB) Beziehungskennzeichnung

[rda-info-liste at lists.dnb.de]

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

Am 13.06.2015 um 12:05 schrieb Frau Wiesenmueller:

> Das Problem ist allerdings - wie so oft - das Austauschformat MARC. Dort gibt 
es
> leider keine eigenen Felder für die unterschiedlichen Elemente. Für Personen
> gibt es nur zwei Felder: 100 und 700. 
[...]
>                  Wenn man also auf die Beziehungskennzeichnungen verzichtet,
> hat man keine Chance, bei den Beziehungen zu Personen (und entsprechend
> Körperschaften) die FRBR-Ebenen maschinell auseinanderzuhalten. Deshalb sollte
n
> wir m.E. schon versuchen, durchgängig 18.5 zu erfassen, auch wenn es nicht
> obligatorisch ist.

Das ist m.E. ein ganz zentrale Argument: Auch die Art wie wir Daten speichern
oder austauschen muss sich an den RDA messen lassen: Wenn da die FRBRisierung
gestoert wird, laeuft auch aus Sicht des Regelwerks etwas schief.

Vor diesem Hintergrund sind m.E. auch die Diskussionen um "eindeutige" (und
damit stellenweise ziemlich krampfige) Beziehungskennzeichnungen zu sehen:
Ein "Librettist" etwa kann (fuer ein und dasselbe Libretto) auf ganz
unterschiedlichen FRBR-Ebenen in Beziehung zur Ressource stehen, je nachdem
ob es sich um eine Textausgabe (da ist er Autor), eine Partitur (wenn ich mich
recht entsinne ist er da als Verfasser einer in das musikalische Werk
inkorporierten Expression auf Ebene E angesiedelt, es gibt aber auch Faelle
wie die Dreigroschenoper, wo man eher von einem gemeinschaftlichen Werk von
Urhebern mit trennbaren Bestandteilen ausgehen sollte, insofern dann definitiv
ein Bezug ein Werk) oder eine Tonaufzeichnung handelt.

Wenn man davon ausgeht, dass das Regelwerk hier zuerst die Sachverhalte im
Sinne einer strikten Festlegung des Kontexts trennt, dann kann man sich
mit stellenweise uneindeutigen, aber der natuerlichen Sprache nahekommenden
Bezeichnungen ausdruecken. Muss man andererseits davon augehen, dass die
FRBR-Ebene so wie in MARC21 gerade nicht explizit vermerkt wird, muss die
Kennzeichnung der Beziehung diese Aufgabe mit uebernehmen.

[An dieser Stelle ist mein "Librettist"-Beispiel nicht ganz tragfaehig,
wir werden nie eine Entitaet "Librettist" fuer Werke kennen, da wir
fuer Schriftwerke (wie ein Libretto-an-sich oder ein Gedicht) immer nur
den "Autor" kennen und ihn nicht vermoege der literarischen Gattung als
"Dichter", "Romancier", "Slam Poet" etc. differenzieren. Das macht m.E.
auch viel Sinn, weil sonst eine Verwechslungsgefahr mit Berufs- oder
Taetigkeitsbezeichnungen der Person uns die Entitaeten noch mehr verunklaren
wuerde]

Genau wie beim Gendering setze ich allerdings darauf, dass die fuer D-A-CH
verbindlichen Codes (von denen wir hier dieser Tage gelernt haben, dass es sie
noch gar nicht gibt?) die notwendige Schaerfe haben, die die Ablage von RDA-
Katalogisaten in MARC21 erlaubt, fuer ein OPAC-Display das aber abgemildert
werden kann.


> Wegen des beschriebenen Problems glaube ich übrigens auch nicht, dass wir in
> unseren Katalogen in näherer Zukunft solche Anzeigen sehen werden:
> 
> Geistiger Schöpfer: X (VerfasserIn)
> Geistiger Schöpfer: Y (VerfasserIn)
> Mitwirkender: Z (ÜbersetzerIn)
> 
> Das ginge ja nur, wenn a) durchgängig Beziehungskennzeichnungen verwendet würd
en
> und b) ein maschinelles Verfahren eingesetzt würde, um über eine Auswertung
> dieser Beziehungskennzeichnungen die Personen bei den richtigen Labels anzuzei
gen.

Ich /erwarte/ solche Displays eigentlich, denn
a) haben wir (evtl. je nach Verbund verschieden) in der /Praxis/ der RAK/MAB-
   Anwendungen schon fast durchgaengig "Funktionsbezeichnungen", also durchaus
   eine gewisse Tradition, uns diese Muehe zu machen
b) handelt es sich um eine statische Konkordanz, die Beziehungscodes (ggfls.
   dekliniert mit Geschlechtsinformation aus Normsaetzen und/oder aus CMC-Codes
   abgeleitetem "Publikationsgenre") irgendwelche vergroebernden "Labels"
   zuweist, die dann den Vorteil haben, dass der eigentliche Beziehungscode
   fuer die Anzeige auf etwas gefaelligeres eingedampft werden kann.

> Geistiger Schöpfer: X [(Komponist)]
> Mitwirkender: R (Arrangement)
> Mitwirkender: Z (Librettist)
> Interpret: Y (Dirgent)
> Interpret: V [(Klangkörper)]
> Solist: U (Sopran)


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

iJwEAQECAAYFAlV8GDYACgkQYhMlmJ6W47OzfQP/RAZIhAt6b6MKSr79rvx0sKbV
2N5bS8pqg2s+3l5VtRgq7y3eipWsWNT8j6NtYBsWGiEM4cXYCFVDNLEqDZ0pEjcT
XrqmAAY6EdBw7SwJ+CqHhZEH/nboTkNP5DhCq1YqQh/M5Fsji0mRj8C5gpyD3u97
Xd0tLC/QQNUx7Fx3m4Y=
=uLmv
-----END PGP SIGNATURE-----