[Allegro] V34.8 steht vor der Tür. Und dann?

Thomas Berger ThB at Gymel.com
Di Dez 9 09:53:08 CET 2014


Lieber Herr Eversberg, liebe Liste,

> Größere Neuer- oder Verbesserungen, etwa vom Kaliber HFM oder
> "persistente Variablen", soll es 2015 nicht mehr geben, sondern wir
> werden eine Stabilisierung des Erreichten anstreben, um schließlich
> eine V35 vorlegen zu können, die ein verläßliches und vollständig
> dokumentiertes Leistungsspektrum hat und dann ohne weitere Korrekturen
> Bestand haben kann mindestens bis zum Ende der Windows-Ära auf PC-
> Plattformen und noch länger auf Linux-Systemen.
> Die V35 soll außerdem ein Parameterpaket umfassen, mit dem der bisherige
> Standard (A.CFG) mit UFT-8 intern weitergeführt werden kann. Wahlweise,
> versteht sich, nicht obligatorisch.

...

> Wobei natürlich klar ist, daß bis spätestens 2020 neue Systeme die
> Manege betreten werden, die sich auf RDA und BIBFRAME gründen und im
> Innern gänzlich anders konzip- und programmiert sein werden, nach zeit-
> gemäßen Standards und ohne Ballaste verflossener Dezennien.
> Daneben wird allegro verblassen müssen, da soll man sich nix vormachen,
> aber immerhin wird man's in Ruhe abwarten können und nicht auf den
> ersten besten Zug aufzuspringen gezwungen sein (Hauptsache er heißt
> nicht "allegro"). Dieses Forum wird ja bestehen bleiben und auch dazu
> dienen können, Erfahrungen und Erkenntnisse über neue Systeme und
> Ansätze abzuwägen und Migrationspfade zu erörtern.

Nun, RDA wird in vielen Bibliotheken hierzulande im 4. Quartal 2015
eingefuehrt (genauer: Konzertiert in der DNB und allen Regionalverbuenden),
auch ohne dass es dazu neue Systeme gibt (und auch ohne dass Altdaten durch
eine Gute Fee retrospektiv umkatalogisiert werden). Nicht fuer allegro, aber
fuer das "konsolidierte Format" ($A.CFG) sowie alle anderen Formate sollte
daher 2015 auch genutzt werden, das Datenschema so zu erweitern, dass

1. das durch die RDA-Einfuehrung Neue abgebildet werden kann,

2. die Anzeigeparamter, sowie Import- und Exportschnittstellen das
   beherrschen

3. die Indexierung die Koexistenz von RDA- und RAK-Daten ermoeglicht

Die zu erwartenden Aenderungen sind so gesehen recht sparsam, denn "RDA"
spielt sich auf verschiedenen Ebenen ab:

* RDA ist ganz fundamental auf den FRBR aufgebaut, d.h. es wird nicht
  der Befund einer Vorlage auf kategorische Sachverhalte aufgeteilt
  rapportiert, sondern zunaechst verstanden, was das ist, was da vorliegt,
  welche Entitaeten beteiligt sind, welche Bezuege zwischen diesen Entitaeten
  bestehen, und dann nach Regelwerk die zu erfassendenen Sachverhalte bestimmt,
  anschliessend /Daten/ zu diesen Sachverhalten ermittelt und erfasst.

* Dementsprechend ist der Regelwerkstext (auch im Vergleich zu AACR2)
  voellig anders organisiert, bei Namen etwa werden nicht direkt Ansetzungen
  gebaut, sondern zuerst Name und weitere Daten der Person bzw. Koerperschaft
  ermittelt und abschliessend *daraus* dann eine Ansetzung zusammengesetzt.

* Was dabei herauskommt ist allerdings traditionellen Katalogisaten
  ausserordentlich aehnlich, musste vorher das Impressum lokalisiert und
  aufgeteilt in Verlag, Ort und Publikationsdatum erfasst werden, so
  ist nun zu erkennen, dass es sich um eine publizierte Resource handelt
  mit einem Veroeffentlichungs-Event auf Manifestation Level, zu dem Verlag,
  Ort und Datum gehoeren, die jedes fuer sich zwingend zu ermitteln und zu
  erfassen sind (und zusammen gesehen eine gute Naeherung an die Transkription
  des Impressums ergeben).

* Im Prinzip wird /vorlagentreue/ Transkription durch die RDA sogar gestaerkt,
  das betrifft Einfuehrung von Abkuerzungen oder Aufloesungen derselben,
  eckig geklammerte Ergaenzungen, und groessere Teile der Vorlage duerfen
  als Informationsquelle herangezogen werden (so dass weniger Bedarf an
  eckigen Klammern besteht). Gerade Verlegernamen wurden nach RAK ziemlich
  rabiat gekuerzt, ohne dass eine tatsaechliche Normierung im Sinne einer
  Verleger-Normdatei bestanden haette

* In der Tendenz sind unter RDA entstandene Katalogisate ziemlich nah an
  AACR2, das bedeutet fuer uns allerdings eine groessere Umstellung, denn
  RAK und AACR2 hatten durchaus Abweichungen, etwa auch in Bezug darauf,
  welche ISBD-Auspraegung auf Displays oder Karteikarten erreicht werden
  koennen soll. Auch zwischen RDA und ISBD (in der neuesten, "consolidatet"
  Version) gibt es Abstimmungen, derzeit eher als kontinuierlicher Prozess
  wechselseitiger Beeinflussungen. Die Aenderung, dass weitere Zusaetze
  zum Sachtiteln nun mit " : " statt bislang " ; " zu trennen sind, rechne
  ich diesem Bereich zu (d.h. ich habe jetzt nicht ueberprueft, wie es die
  AACR2 gehandhabt haben, die RDA-Regelung entspricht aber der aktuellen
  ISBD-Regelung).

* Im Zuge der langjaehrigen RDA-Entwicklungen wurden des oefteren dafuer
  benoetigte Felder in MARC21 eingefuehrt, am prominentesten die fuer
  Content, Media & Carrier (336-338), die die allgemeine Materialbenennung
  (245$h) abloesen. Fuer uns von "ausserhalb" ist es sehr schwer, am
  aktuellen MARC-Standard oder durch Studium der Aenderungen anlaesslich
  der halbjaehrlichen MARC-Updates zu ermittlen, was denn nun auf Daten-
  ebene anders wird, zudem gibt es auch Unterschiede zwischen MAB und
  MARC, die ganz individuelle Hinweise geben (MAB 333 hat kein Pendant
  in MARC21, das geht auch in Ordnung, weil es das RAK-Konzept des zu
  ergaenzenden Urhebers umsetzt, das es in den AACR2 nicht gab und in den
  RDA weiterhin nicht gibt)

* Fuer den Weiterbetrieb der MAB-basierenden "Versorgungsschnittstellen"
  der Nicht-PICA-Verbuende vom Zentralsystem zu den Lokalsystemen haben
  diese Verbuende sich auf einen gemeinsamen Satz von "privaten" MAB-
  Erweiterungen geeinigt, um die fuer die D-A-CH-Anwendungsebene getroffenen
  RDA-Festlegungen und -Konzepte transportieren zu koennen. Im Prinzip
  ist diese Liste ein Kondensat aller Aenderungen, die *in beliebigen,
  bislang an RAK-Katalogisierung orientierten* Systemen tatsaechlich
  auf Datenfelder durchschlagen (das Gros der Aenderungen hingegen wie
  oben beschrieben ist eine geaenderte Herangehensweise und Details zu
  Ansetzungen und Binnensyntax von Feldern). Leider wurde die Arbeit an
  MAB 2004 eingefroren, die DNB betont, dass sie selber MAB seit Juli
  2014 ueberhaupt nicht mehr einsetzen und die Verbuende betonen, dass
  es sich nur um "verbundinterne" Festlegungen handelt, die zufaellig
  mit anderen Verbuenden abgestimmt sind: Insofern hat dieses Format
  nicht einmal einen Namen und niemand sieht sich in der Pflicht, das
  einmal zusammenzustellen. Notfalls kann man es sich aber aus den
  Folien bei < https://wiki.dnb.de/pages/viewpage.action?pageId=99090660 >
  zusammenklauben.

Fazit: Entlang der Aenderungen in den MAB-Diensten werden wir "RDA-Felder"
in $A.CFG ergaenzen muessen, und MAB- und MARC-Schnittstellen sind
entsprechend zu ueberarbeiten. Es wird notwendig sein, in Datensaetzen
zu vermerken, dass es "echte" RDA-Aufnahmen sind (es genuegt also nicht,
auf "Schluesselfelder" wie CMC zu testen, die fuer sich auch aus maschineller
Umsetzung der GMD in Altdaten stammen koennen bzw. sollten). Ich sehe auch die
Notwendigkeit, zwei Saetze von Formularen fuer "Katalogisierung nach den RDA"
und "Legacy-Katalogisierung" im Standardsystem vorzuhalten.

Ab Oktober 2015 werden Fremddaten teilweise "genuin RDA" sein und teilweise
"irgendwie alt" (seit der Einfuehrung der Gemeinsamen Normdatei im April
2012 und spaetestens seit der bereits im Oktober 2014 erfolgten Umstellung
der GND auf RDA-Ansetzungsregeln ist ja alles, was beim Import ueber
im Fremdsystem vorliegende verknuepfte Personen und Koerperschaften ja
laengst nicht mehr RAK-WB! und aus Altbestandskonversionen gibt es jetzt und
auch weiterhin in allen Verbuenden Daten, die aus Vor-RAK-WB-Zeiten stammen,
Voll-RAK, PI, Hausregeln, ...). Sie treffen dabei auf zu frueheren Zeitpunkten
importierte Katalogisate sowie auf selbst angelegte nach (mehr oder weniger?)
RAK-WB. Bibliotheken, die nicht direkt in Bibliotheksverbuende katalogisieren,
werden den Regelwerksumstieg in eigener Regie vornehmen muessen, was von
vielen Faktoren abhaengen wird: Verfuegbarkeit von Schulungen, Vorliegen
von Sonder- bzw. Praxisregeln der RDA fuer in diesen Bibliotheken besonders
interessantes oder haeufiges Material, konzertiertes Vorgehen im Rahmen
von Arbeitsgemeinschaften und Fachgesellschaften, lokale Gegebenheiten der
Personalplanung etc...

Fuer allegro-Systeme sehe ich daher die Anforderung, dass Anwender ab etwa
dem 4. Quartal 2015 die /Moeglichkeit/ brauchen, /kontrolliert/ auf RDA-
Katalogisierung umzusteigen, *alle* Systeme aber mit einem Mix aus Alt-
und Neudaten zurecht kommen muessen, wobei viele Jahre vergehen werden,
bis RDA-Aufnahmen in den einzelnen Katalogen die Mehrheit ausmachen werden.

viele Gruesse
Thomas Berger



Mehr Informationen über die Mailingliste Allegro