[Allegro] RDA: Inhaltstyp und Datenträgertyp

[Bernhard Eversberg]

Am 01.04.2015 um 10:32 schrieb Thomas Berger:
>
>>>>
>>>> #0c  = Inhaltstyp        [gehört zu Werk und Expression]
>>>> #770 = Datenträgertyp    [gehört zur Manifestation]
>>>
>>> wohingegen der Medientyp zur Expression gehoert...
>>>
>> Sicher, aber es werden keine Expressions-Datensätze gemacht werden.
>
> Es werden auch keine Werk-Saetze gemacht werden, bzw. konkret
> keine bibliographischen (Mehr GND-Saetze fuer Werke sind allerdings
> zu erwarten).
Die bisher existierenden GND-Werksätze entstammen fast alle aus dem
Musikbereich. Die "bevorzugten" Titel folgen den strikten Formalien
von RAK-Musik. Ob man mit den GND-Daten einen RDA-konformen
Werksatz hinkriegen kann, so man das will, überblicke ich noch nicht,
ein kompatibler Inhaltstyp existiert da jedenfalls nicht.
BSZ hat übrigens gerade ein umfassendes GND-Handbuch aufgelegt:
   http://verbund-swop.bsz-bw.de/volltexte/2013/340/pdf/kathb_gnd.pdf

>> Und ein konkreter Inhalt sähe so aus, ein wenig vereinfacht:
>>
>> #77i $a aufgeführte Musik $b prm $2 rdacontent
>> #77m $a audio $b s $2 rdamedia
>> #77d $a Audiodisk $b sd $2 rdacarrier
>
> $2 ist wichtig, zumindest wenn nicht "rdacontent" drin steht
> (wir haben uns noch nicht ueber ein Globalfeld unterhalten,
> das festlegt, dass die Aufnahme als Ganzes unter RDA zustande
> gekommen ist - es wird ja oft genug darauf hingewiesen, dass
> es nicht ausreicht, nur die drei CMC-Sachverhalte auszufuellen)
>
> $a erwarte ich als typischen Inhalt von Nicht-D-A-CH-Daten (dann
> eher auf Englisch oder Suaheli), in D-A-CH wird es stets belegt
> sein, allerdings wohl meist "beim Export" aus den Codes $b
> abgeleitet.
>
Die Kernfrage ist doch, ob man die Daten der MARC-Felder 336, 337 und
338, wenn sie aus verschiedenen Quellen stammen, dann überhaupt wird
logisch zusammenführen können. Die Begriffe und/oder die Semantik von
Codes können nach aller Erfahrung stark divergieren.
Hinzu kommt natürlich das Problem mit den Altdaten, die zum großen
Teil weniges enthalten, womit man die neuen Felder beschicken könnte.
Die von LC für MARC21 definierten Codes stammen alle aus ein paar
festen Bytes, vorwiegend aus dem Header und aus der 007, die es
schon länger gibt. Aber wir haben in MAB2 dafür nichts adäquates
und in Pica auch nicht.
Und was, frage ich, nützt einem dann der ganze Aufwand, wenn
die Daten nicht komplett damit ausgestattet sind und in nicht
konsistenter Weise?

Mal Hand hoch, wer sich von diesen neuen Elementen was verspricht!
Und wer würde gerne die Elemente in der gezeigten ausführlichen
Fassung eingeben wollen?

B.E.