AW: [rak-list] Content type / Media type / Carrier type

Thu Sep 10 16:48:02 CEST 2009

Lieber Herr Eversberg,
liebe Liste,

ich moechte gerne auf eine Frage eingehen, die heute frueh hier gestellt
worden ist, immer aus Sicht der Arbeitsstelle Datenformate an der
Deutschen Nationalbibliothek, also mit Schwerpunkt auf MARC 21.

>MARC 336: http://www.loc.gov/marc/changes-rda-336.html
>MARC 337: http://www.loc.gov/marc/changes-rda-337.html
>MARC 338: http://www.loc.gov/marc/changes-rda-338.html
>
>Ein noch nicht ganz gelöstes Problem ist, wie man diese Datenelemente
>dann konkret belegen wird. Die Beispiele in den MARC-Entwürfen sind in
>diesem Punkt noch ganz unverbindlich und LC verwendet sie noch nicht.
>
>Wichtig wäre, und z.B. die grenzüberschreitende Recherche wäre nur dann
>verbesserbar, wenn man für diese Felder nicht nur ein genormtes
>Vokabular hätte, sondern dieses dann mit Codes ausdrücken würde, die
>sprachunabhängig wären.

Der MARBI-Antrag zu diesen Feldern ist Anfang 2009 in Denver
diskutiert worden:
http://www.loc.gov/marc/marbi/2009/2009-01-2.html

Wir haben hier - genau nach dem Kriterium der Internationalitaet
und der Sprachunabhaengigkeit - das Unterfeld $b eingebracht,
in 336 $b "Content type code" zu 336 $a "Content type term",
in 337 $b "Media type code" zu 337 $a "Media type term",
in 338 $b "Carrier type code" zu 338 $a "Carrier type term".

Es ist richtig, dass bisher die offiziellen Codelisten, die ja
von der Library of Congress zur Verfuegung gestellt werden, noch
nicht angelegt oder zumindest noch nicht veroeffentlicht sind,
jedenfalls sehe ich sie auf der Leitseite zu den "MARC Code Lists
for Relators, Sources, Description Conventions"
http://www.loc.gov/marc/relators/
noch nicht.
Aber anhand der Beispiele kann man aber schon erkennen, wie das $b
jeweils funktionieren wird. Auch ist festgehalten:

"Each instance of field [336/337/338] must contain only terms in
$a subfields or only codes in $b subfields" - um Inkonsistenzen
auszuschliessen.

(Fuer den Inhalt von $b hatte ich mal ueberlegt, die im "RDA/ONIX
Framework for Resource Categorization"
http://www.rda-jsc.org/docs/5rda-parta-categorization.pdf und
http://www.loc.gov/marc/marbi/2007/5chair10.pdf
moeglichen nummerischen Werte ["1:1:3:3" fuer den Content Type
"text"; "4:6:5" fuer den Carrier Type "audiodisc"] zu verwenden und
via LC in MARC 21 zu standardisieren - aber so weit wollten die
Expertinnen und Experten dann nicht gehen, stattdessen sind in den
Beispielen jetzt eher sprechende/mnemotechnische Werte enthalten.
Das spricht in gar keiner Weise gegen dieses Framework, das ich
immer noch fuer ziemlich vielversprechend halte, eben auch, um
aufkommendes neues "Kuddelmuddel" zu vermeiden. In den RDA ist es
jedenfalls sauber angekommen, und es wird im "Vocabulary Mapping
Framework" gerade aufgebohrt und erweitert, s.
http://www.jisc.ac.uk/whatwedo/projects/vocab-framework.aspx)

((Der Vergleich mit der Arbeitsgruppe Codes hinkt m.E. ein wenig, weil
dort der Ansatz eher ein sammelnder, definierender und sortierender
war, waehrend das Framework eher analysiert und dekonstruiert hat,
um erst in einem zweiten Schritt Beispiele "durchzuspielen".))

Beste Gruesse aus Frankfurt

Reinhold Heuvelmann

--

Reinhold Heuvelmann
Deutsche Nationalbibliothek
Informationstechnik / Datenformate
Adickesallee 1
D-60322 Frankfurt am Main
Telefon: +49-69-1525-1709
Telefax: +49-69-1525-1799
mailto:r.heuvelmann at d-nb.de
http://www.d-nb.de

>-----Ursprüngliche Nachricht-----
>Von: rak-list-bounces at lists.d-nb.de 
>[mailto:rak-list-bounces at lists.d-nb.de] Im Auftrag von 
>Bernhard Eversberg
>Gesendet: Donnerstag, 10. September 2009 09:27
>An: Diskussionsliste zum Regelwerk RAK
>Betreff: [rak-list] Content type / Media type / Carrier type
>
>
>Also nun mal richtig normal und ohne Rundumschläge, damit auch jeder
>alles, was gesagt wird, wirklich verwenden kann.
>
>
>Zu den größeren Neuerungen in den RDA gehört die Ausweitung und
>Neufassung der bisherigen GMD und SMD (Allgemeine Materialbenennung
>und Spezifische Materialbenennung). Diese waren ein Konglomerat gewesen
>aus eigentlich nicht immer logisch zusammenpassenden Begriffen, und es
>wurde auch immer mal was geändert.
>Um dieses Kuddelmuddel zu entzerren, wurden neue Konzepte eingeführt
>und sogar mit neuen MARC-Nummern versehen:
>
>Content type - Inhaltstyp  [neu]
>    antwortet auf: Welche Sinnesorgane werden angesprochen?
>    (Bild, Bewegtbild, Ton, Dreidimensional, Datei, Text, Sprache)
>MARC 336: http://www.loc.gov/marc/changes-rda-336.html
>
>Media type - Medientyp  [früher GMD]
>    antwortet auf: Welches Equipment wird benötigt?
>    (Audio, Mikroform, Computer, Nichts [Buch])
>MARC 337: http://www.loc.gov/marc/changes-rda-337.html
>
>Carrier type - Datenträgertyp  [früher SMD]
>    antwortet auf: was für ein physisches Material liegt vor?
>    (Audiokassette, Filmspule, Mikrofiche, Band)
>MARC 338: http://www.loc.gov/marc/changes-rda-338.html
>
>Ein noch nicht ganz gelöstes Problem ist, wie man diese Datenelemente
>dann konkret belegen wird. Die Beispiele in den MARC-Entwürfen sind in
>diesem Punkt noch ganz unverbindlich und LC verwendet sie noch nicht.
>
>Wichtig wäre, und z.B. die grenzüberschreitende Recherche wäre nur dann
>verbesserbar, wenn man für diese Felder nicht nur ein genormtes
>Vokabular hätte, sondern dieses dann mit Codes ausdrücken würde, die
>sprachunabhängig wären.
>Nebenbei: Soweit war man auch schon, als für RAK2 die Arbeitsgruppe
>"Codes" entsprechende Neuvorschläge machte:
>   http://www.allegro-c.de/formate/codes.htm
>
>Vor einer Weile habe ich eine überblicksartige Darstellung der
>ganzen Problematik und ihres Kontextes und der damit verbundenen Ziele
>versucht:
>   http://www.allegro-c.de/regeln/rda/chap3.htm
>Diese ist jetzt nochmals aktualisiert, z.B. stimmten einige Links
>nicht mehr und es fehlten neuere Fakten. Zum Beispiel:
>
>Auf der andern Seite (der Sache und des Atlantiks) wurde eine Neuerung
>eingeführt, um insgesamt die Thematik der kontrollierten 
>Vokabularien in
>RDA und MARC neu aufzurollen, und zwar erst einmal die Begriffe, inkl.
>der Benennungen aller Datenelemente usw., glasklar zu 
>definieren und ein
>für allemal festzuklopfen, bevor man sich daranmacht, dafür Codes zu
>definieren. Das ist das NSDL Registry:
>    http://metadataregistry.org
>
>Dort findet man sich noch nicht so leicht zurecht. Man liest aber
>und erfuhr auch in dieser Liste vor einer Weile, daß DNB daran
>mitarbeitet:
>  
>http://metadataregistry.org/blog/2009/03/09/multiple-languages-and-rda/
>
>Darin steht u.a.:
>"Christine Frodl and Veronika Leibrecht have been our primary contacts
>at the Deutsche Nationalbibliothek on this work, and they've 
>been a real
>pleasure to work with."
>
>Deshalb nun die Frage: Wie ist der Stand dieser Dinge? Könnte man schon
>Hinweise geben, wie dieses Registry zu verwenden sein wird und welche
>Rolle es künftig spielen soll? Gibt es für dei drei genannten neuen
>Felder schon einen Entwurf von konkreten Codelisten, oder ist es dafür
>immer noch zu früh? Was wird in diesen Feldern in den MARC-Sätzen der
>DNB stehen - oder sollen sie zunächst nicht verwendert werden?
>(Vielleicht wurde das alles auf dem MARC-Symposium gesagt, aber mir
>ist es entgangen, dann sorry.)
>
>MfG B.Eversberg
>_______________________________________________
>rak-list mailing list
>rak-list at lists.d-nb.de
>http://lists.d-nb.de/mailman/listinfo/rak-list
>