[Allegro] RDA: Inhaltstyp und Datenträgertyp

Mi Apr 1 10:32:59 CEST 2015

Am 01.04.2015 um 07:08 schrieb Bernhard Eversberg:
> Am 31.03.2015 um 14:44 schrieb Thomas Berger:
>>> Wir schlagen einfach mal vor: (unvermeidliche Proteste antizipierend,
>>> aber bessere, konkrete Vorschläge sind natürlich willkommen)
>>>
>>> #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). Damit das alles RDA-kompatibel bzw. FRBR-konform
funktionieren kann, muss auf Feld- bzw. Terminologieebene jeweils
klar sein, welche Entitaet gerade beschrieben wird. (Auf der
Autocat-Liste laeuft gerade eine erster-April-maessige Diskussion,
warum jemand keinesfalls ein "author of foreword" sein kann, weil
"author" eine Unterklasse von "creator" ist, was wiederum eine
Funktionsbezeichnung ist, die fuer Level-1-Entitaeten reserviert
ist. Hingegen ist "writer of foreword" eine erlaubte Benennung,
da ein "writer" (wohl doch kein "scribe", wie es eine der
Beteiligten empfand) ein Unterfall von "contributor" ist, und damit
auf Level-2-Entitaeten passt. (Wird das fragliche Vorwort ausserdem
als solches katalogisiert, wandelt sich die Funktionsbezeichnung
natuerlich von "writer of ..." zu "author")

Aber so sehe ich das auch bei den CMC (Content-Media-Carrier)-Codes
bzw. Termen (dt. IMD Inhaltstyp/Medientyp/Datentraegertyp): Es mag
da gegenseitige Abhaengigkeiten geben, aber beim Versuch, ein
Katalogisat (jetzt also: Manifestation-Level-Record mit notwendigen
Anreicherungen um Inhalte aus hoeheren Stufen, fuer die es keine
Datensaetze gibt) auf seine Anteile bezueglich der einen oder anderen
isolierten RDA-Entitaet zu betrachten, will man nicht ploetzlich
mit Luft dastehen.
]

>> Ich schlage dringend vor, fuer diese drei zentralen Inhalte eigene
>> Felder einzufuehren, die exakt den MARC21-Feldern 336-338 entsprechen,
>> d.h. insbesondere sowohl Codes als auch Texte tragen koennen:
> 
> Ihren Vorschlag, und das war mein zentrales Anliegen, könnte man
> demnach z.B. so umsetzen:
> 
> #77i   Inhaltstyp
> #77m   Medientyp
> #77d   Datenträgertyp
> 
> 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.

Fuer allegro stellt sich die Frage, ob Codes (fuer die Anzeige
per Tabelle umgesetzt) oder Texte das Primaere sein sollen,
bzw. ob das jeder Anwender fuer sich aussuchen darf.

> Oder lieber #7i, #7m, #7d damit's zwanglos wiederholbar wird?

Die Sachen sind wiederholbar, und wohl auch staerker als bisher,
wo man bei Beilagen oft verzichtete. Typisch ist ja beispielsweise
eine CD mit einem fetten Booklet, leider weiss ich nicht, wie
das behandelt wird.

> Während man dagegen auch dies machen könnte:
> 
> #77i prm
> #77d sd
> 
> und das wäre datentechnisch äquivalent, d.h. in die exakte MARC-Form wandelbar
> per Export oder FLEX, und umgekehrt.

allegro hat traditionell keine starke Trennung zwischen der Form
des Datensatzes, die dem Bearbeiter gezeigt wird und der Form, die
intern gespeichert ist (am anderen Extrem PICA mit sehr verschiedenen
Formaten fuer beide Zwecke). Dennoch sollte man stets darueber
nachdenken, ob eine "praktische Abkuerzung" bei der Erfassung auch
wirklich genau so in den Daten landen soll - der uebernaechste
Benutzer mag die Codes nicht und traegt Klartext in #77d ein (oder
der ueberuebernaechste Benutzer findet die Felder schick und nutzt sie
auch bereits irgendwie selbstgestrickt fuer seine noch-nicht-
RDA-Katalogisierung), beim Export ist dann schnell nicht mehr klar, ob
der nicht gekennzeichnete Inhalt fuer $a oder $b oder irgendetwas
komplexeres steht...

> Wir haben das mal zwecks Demo umgesetzt und ein a35-Formular
> gemacht, weil das am schnellsten geht:
> 
>   http://www.allegro-c.de/db/demo2/a35-pc.php
> 
> Irgendeinen Titel aufblättern, dann
>   Bearbeiten / Eigene Formulare / Normales Buch
> 
> Inhaltstyp und Datenträgertyp sind als select-Listen angelegt.
> Mit Klick auf "Test" und dann F5 sieht man, wie die Eingabe ankommt.
> (Nur im Internformat, in der Normalanzeige noch nicht, das wäre ja
> kein Problem)
> 
> Der BIBFRAME-Editor, nebenbei:
> 
>   http://bibframe.org/tools/editor/
> 
> hat die Typdaten ansatzweise inkludiert, soweit ich sehe, ohne aber
> dafür Auswahllisten anzubieten. Vielmehr entsteht dann, wenn eine
> Eingabe gelingt, statt dessen eine URI. Das ist natürlich viel sauberer.
> "Work content category" ist wohl gedacht für den Inhaltstyp (unter "New
> Work") bzw. "Media category" und "Carrier category" (unter "New
> Instance") für den Medien- bzw. Datenträgertyp. Nun gut, alles Beta,
> aber man sieht, daß da ganz andersartige Schematismen im Werden sind.

Meinen Sie? Bibframe will Sachverhalte modellieren koennen, /beispielsweise/
aus in einer RDA-Anwendung. Und ob dort (uebersetzte) Texte oder Codes zum
Einsatz kommen, ist durch die RDA nicht einmal festgelegt. Die /Konzepte/
hingegen sind Bestandteil dieses Regelwerks, insofern also eine Abstraktion
von wahlweise Codes oder Labels. Das kann elegant durch die Angabe einer
IRI oder URI fuer das Konzept notiert werden.
Und damit das ganze mit "Linked Data" zu tun hat, ist das ohnehin die
Methode der Wahl.

viele Gruesse
Thomas Berger