[Rda-info-liste] Beziehungskennzeichnung

rda-info-liste at lists.dnb.de rda-info-liste at lists.dnb.de
Die Jun 9 16:32:27 CEST 2015


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

Liebe Frau von Rueden,

Am 09.06.2015 um 15:23 schrieb rda-info-liste at lists.dnb.de:
> Liebe Frau Prof. Wiesenmüller,
> 
> m. E. kann man das generische Maskulinum im Deutschen nicht auf
> Funktionsbezeichnungen für eine konkrete Person anwenden. Der Satz "Annegret
> Müller ist Herausgeber der Zeitschrift ..." ist für meine Ohren einfach falsch
.
> Eindeutig falsch ist der Satz "Annegret Müller ist Herausgeber/in ... ", da
> Annegret Müller nicht beides sein kann. Es muss heißen: "Annegret Müller ist
> Herausgeberin ...". Gleiches gilt für Funktionsbezeichnungen von Personen in
> Titelaufnahmen. Denkbar wäre für mich, hier einfach Abkürzungen zu benutzen,
> also z.B. "Hrsg." statt "Herausgeber".

aber Frau Wiesenmueller hatte doch schon dargelegt, dass auch die D-A-CH-
Festlegungen "den Verbuenden" hier Freiheiten lassen, die auch genutzt werden.
"Generisches Maskulinum" und "Binnen-I" wurden als reale Beispiele genannt,
Abkuerzungen sind ebenso denkbar, allerdings ist es eine der Maximen des
Regelwerks, auf Abkuerzungen und Latein zu verzichten (zumindest bei der
Erfassung[*]). Mit Normdaten ist Gendering auch keine Hexerei und ohne koennte
man einen Vornamensthesaurus hinterlegen. Gibt es nur abgekuerzte Vornamen,
und ist mehr nicht zu ermitteln, braucht man in Ausnahmefaellen natuerlich
immer noch eine der generischen Formen als Fallback. Zu erwarten ist, dass
Bibliotheken, die nicht nur gender- sondern auch LGBTIQH-aware sind, evtl.
auch lieber generisch mit "Herausgeber_in", "Herausgeber*in" oder
"HerausgebX" operieren werden: Die sich in einer "korrekten" geschlechts-
spezifischen Bezeichnung aeussernde Fremdbestimmung kann ja durchaus
als respektlose und diskriminierende Anmassung verstanden werden und
es gibt durchaus Bibliotheken und Archive die da sehr hellhoerig sein
muessen.

D.h. fuer Ihre Argumente oben sind "die RDA" der falsche Adressat, das
muessen Sie mit ihrem Bibliothekssystem (dessen Betreiber, Hersteller,
Entwickler, ...) diskutieren. (Und fuer die Beurteilung von "richtig"
und "falsch" sind meiner festen Ueberzeugung nach die Benutzer zustaendig,
wir sind ja nicht mehr in Preussen...)

Auf der (weitestgehend amerikanischen) Autocat-Diskussionsliste gibt es
seit ich mich erinnern kann ein endloses Lamento, dass die Bibliothekssysteme
sich nicht an die Regeln halten, bzw. wenn neue Felder zur besseren Handhabung
eines Sachverhalts eingefuehrt wurden, diese von den Systemen nicht
"unterstuetzt" werden, so dass Anwender faktisch gezwungen sind, auf dem
als defizitaer erkannten Weg weiterzuwursteln.

Ich denke, bei der RDA-Entwicklung ist die Erfahrung mit eingeflossen, dass
es aussichtslos ist, durch besonders avancierte Regeln Sachzwaenge zu
schaffen, denen die Systemanbieter dann automatisch folgen muessen um
"im Geschaeft" zu bleiben. Den dafuer erforderlichen Druck muessen die
Anwender schon selber aufbringen.


viele Gruesse
Thomas Berger

[*] In den RAK ging es ja eigentlich ausschliesslich um die Praesentation auf
Karten, in Kartenkoepfen oder in Listen. Bei der Auseinandersetzung mit
den RDA muss man m.E. stets aktiv gegenwaertig halten, dass es da haupt-
saechlich um Erfassung geht, und gerade nicht um "Anzeige".
"Verzicht auf Abkuerzungen" ist da z.B. eine Regel, wenn es um die Uebernahme
von Zeichenketten aus der Vorlage geht und dort bedeutet es auch gerade nicht,
bereits in der Vorlage abgekuerztes nun expandieren zu muessen. Fuer
Beziehungskennzeichen ist ja sogar das Erfassen von Codes eine Option! An den
ueblichen Stellen mit Doppelfunktion, also z.B. dem Erscheinungsvermerk, fallen
m.E. Erfassung und Darstellung im Regelwerk dann doch wieder zusammen, mit den
bekannten Komplikationen.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iJwEAQECAAYFAlV2+PYACgkQYhMlmJ6W47M1QgQArRLvSf3SBLzRlbcH4yGHi536
aXKYdIK1Fyiql0UH2fvS8a/m39cMs3KSI8vdFb0fq65MZm2wcBgnbGx5bto+fXQZ
nrftXDleIVMCWSmOHAefiWZoHDgy+E75elh5Mr2uMNMHdf0xuWGYaHAFLs6UMIFl
gujX8+F7q01aNME8NOM=
=UQ10
-----END PGP SIGNATURE-----