[Allegro] RDA: Inhaltstyp und Datenträgertyp

[Thomas Berger]

Lieber Herr Eversberg, liebe Liste,

>>>> 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,

Man koennte. Es ist aber nicht geplant, die Werk bzw. Person-Werk-
Saetze aus der GND (also MARC Authorities) herauszunehmen und
in etwas bibliographisches umzuwandeln. Im Gegenteil: In VIAF
kann man besichtigen, dass die LoC seit laengerer Zeit auch
Expression-Saetze als Normdatensaetze produziert.

Datentechnische /Trennung/ der Katalogisate in die verschiedenen
Entitaeten Werk-Expression-Manifestation ist nach RDA zwar
moeglich, wird m.W. aber derzeit von keiner der involvierten
Parteien angestrebt, es ist eher als eine Option zu verstehen,
die zukuenftige Datenformate nutzen koennten (derzeit sind die
aber eher RDF-basiert, d.h. "records" gibt es eher gar 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

Schoen. Dann liegen ja alle genau im Plan (zum 31.3. die gemeinsamen
Schulungsunterlagen der Verbuende fertigzustellen)


>>> 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.

/Wenn/ da dann aber $rdacontent steht, ist die Semantik festgezurrt
und man hat "nur" noch Uebersetzungs- oder Code-umsetzungsprobleme
oder solche die aus Vergroeberungen bzw. Verfeinerungen /kompatibler/
Konzepte resultieren ;-)

Aber es hat doch sowieso nie jemand die offizielle Begruendung ernst
genommen, dass durch "Internationalisierung" der beruehmte "Datentausch"
einfacher wird.


> 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?

Nun, bekanntermassen ist es eben nicht moeglich, Altkatalogisate
automatisch nach RDA umzusetzen. Man koennte sich sonst auch
fragen, wozu ein neues Regelwerk gut sein soll, wenn es dann doch
nur Daten produziert, die man auch durch Umsetzung von Alt-Daten
aus Alt-Regelwerken erreichen kann.

Die Argumentation ist ansonsten nicht neu, aber dennoch haben
alle fleissig ihre PI-Kataloge retrokonvertiert und in die
Verbunddatenbanken eingespielt, auch wenn die dadurch nicht mehr
"reine" RAK-Umgebungen waren.

viele Gruesse
Thomas Berger