[Allegro] MARC21-XML 700 als EST / bevorzugter Titel eines Werkes

Do Feb 4 20:19:13 CET 2016

Am 04.02.2016 um 18:36 schrieb Anando Eger:
> Hallo Herr Berger,
> 
> ja, MARC 40 $e hatte nicht auf dem Radar.
> 
> Jetzt wird mir aber langsam klar, dass ein vernünftiger Import nur 
> möglich ist, wenn man die Gepflogenheiten aller "Description 
> Conventions" kennt, genaugenommen müssten alle alten Titelaufnahmen 
> aus RAK-Umgebungen mit "rakwb" gekennzeichnet werden, oder?

Naja, welche Aufnahmen moegen das sein? RAK-Musik war immer
eigenstaendig, RAK-UW wurde nie fertig, Retrokonversionen
orientieren sich an Karteikarten, es waere verwegen nur
anhand des Erscheinungsjahrs zwischen PI, Voll-RAK, RAK-OeB,
RAK-WB zu differenzieren, und dann gibt es noch die Fremddaten
aus in- und auslaendischen Quellen, die mal mehr oder weniger
laeppsch umgearbeitet wurden.

Wobei ich heute oder gestern beim Sichten irgendwelcher Aufnahmen
tatsaechlich ab und zu ein "rak-wb" in 040 $e gesehen habe:
Seit es RDA-Katalogisierung und damit verpflichtende Kennzeichnung
gibt, achtet man in den Umgebungen wohl darauf, neu entstehende
oder uebernommene Nicht-RDA-Aufnahmen ebenfalls deutlicher zu
kennzeichnen...

> Die MARC 240 $a + MARC 41 $h scheint mir eine gute Abbildung dafür 
> zu sein, was wir bisher unter EST kannten.

Es ist sogar mehr: Die "Sprache des Originals" wurde bislang
nicht erfasst, die erschliesst sich dem Kundigen ja durch
Kontemplation ueber den angegebenen Originaltitel, die Angabe
eines (MARC- bzw.) ISO-codes ist da wieder so eine neuzeitliche
Verflachung, denn man kann ja schlecht ca. 7.000 Sprachen
ohne Informationsverlust auf gut 500 Codepunkte abbilden.

Es ist also die Sprache der Manifestation 041 $a, die dann
strenggenommen von Code auf Abkuerzung umgesetzt werden muss
(Ich habe da irgendwelche Unterprogramme, denn A.CFG hat ja
#37, andere allegro-Anwendungen erfassen die Sprache der
Publikation aber immer noch fussnotenartig, d.h. als "dt."
etc. abgekuerzt...)

> Aber wer weiß, ob das noch jemand so sieht...
> 
> Fazit: Wir lassen es herankommen und implementieren das, was in 
> "freier Wildbahn" vorkommt.
> 
> Ansonsten wird man einfach nicht fertig.

Oder umgekehrt. Da die PICA-Verbuende gerade ihre
Internformate vereinheitlichen ist zu erwarten, dass
nicht allzuviele Variationen in den MARC-Austauschdaten
vorkommen, zumindest was genuine RDA-Daten aus der D-A-CH-
Umgebung angeht.

< https://lccn.loc.gov/2013048520/marcxml > ist nach RDA
katalogisiert und kommt ganz ohne Originaltitel aus,
vielleicht weil "F" nicht uebersetzt werden muss (Zusaetze
bleiben ja weiterhin unberuecksichtigt)?

AACR-Aufnahme der LoC:

240 10 |a Wer bin ich--und wenn ja, wie viele?  |l English

RDA-Aufnahme der LoC:
< https://lccn.loc.gov/2012042668/marcxml >
<datafield tag="240" ind1="1" ind2="0">
  <subfield code="a">Armée Furieuse.</subfield>
  <subfield code="l">English</subfield>
</datafield>

Da hat die RDA-Einfuehrung also keine Aenderung gebracht (und
fuers Browsing benoetigt man die eindeutige Untergliederung
als ". English", kein Verlass auf 040 $a). [Wie schon haeufig
erwaehnt, kommen viele Irritationen hierzulande daher, dass
man die 2004 beschlossene AACR-Einfuehrung ausgesessen hat
und sofort auf RDA aufgesprungen ist: Die RDA-Abweichungen
sind alle "optimiert" darauf, dass sie moeglichst kompatibel
zu AACR2 sind, und gleichzeitig "RAK-optimiert" geht halt
nicht...]

Ich hatte eigentlich gerade in Bezug auf 419 bei MAB-Daten eine
groessere Erschuetterung erwartet, analog dem "Komplettumstieg"
der DNB von 260 auf 264, RDA hin oder her. Es deckt sich aber mit
der PICA-Beobachtung von Herrn Eversberg, dass - zumindest im GBV
 - in der Standardsituation "ist Verlag" die alten PICA-Felder
weitergenutzt werden (MARC 264 ist ja auch kein genuines RDA-Feld
wie etwa die 33x fuer IMD/CMC, sondern geschaffen fuer die, denen
260 allgemein nicht ausreicht).

> Ich hatte mal (vor ca, 5 Jahren), angeregt von einem Fachartikel in 
> einer Computer-Zeitschrift, die "Costs of ownership" der 
> Bibliotheks-EDV + Arbeitszeitaufwand zur Computer"hütung" der 
> Karteikartenvariante gegenübergestellt: Die letztere war damals 
> schon mit weniger Gesamtaufwand behaftet. Wie wirde das heute 
> aussehen? Es wird wohl erst wieder besser, wenn es nur noch einen 
> eonzigen Zentralcomputer(cluster) auf der Welt gibt, der sich selbst 
> optimiert.

... und programmiert. Lems GOLEM II?

Zu lesen ist auch, dass es jetzt dem Middle Management an den
Kragen geht, Computer koennen Mitarbeiter besser koordinieren
als menschliche Indianerhaeuptlinge, bzw. werden zumindest besser
akzeptiert und ihre Entscheidungen nicht so haeufig infrage
gestellt...

Ich weiss nicht, wie Sie gerechnet haben, es war aber gewiss
falsch ;-) Frueher mussten die Leute um Farbbaender kaempfen,
jetzt um neue Computer. Und Katalogisierung nimmt einen immer
geringeren Anteil der Arbeitszeit der immer weniger werdenden
Fachkraefte ein, vermutlich nutzen sie die Computer auch fuer
etwas anderes. Dass das - ebenfalls ueberlastete und daher
stets wachsende - EDV-Personal Kapazitaet fuer die Huetung
spezieller Bibliotheks-EDV haette, halte ich fuer ein Geruecht,
Eines der wichtigen Merkmale der Software allegro-C ist uebrigens,
dass sie notfalls auch ohne Systembetreuer ein paar Jahrzehnte(!)
durchlaufen kann. Leider aktualisiert sie sich nicht von selbst,
der Nicht-Profi-Markt hat da inzwischen die Nase vorn: Handy
schon wieder ins Klo gefallen - alles kein Problem, bei Google,
One Drive, ... ist *alles* gespeichert und selbst wenn man
sowohl Passwort als auch Benutzernamen vergessen hat, gibt es
immer noch Wege...

viele Gruesse
Thomas Berger