[Allegro] Persistent Storage

[Thomas Berger]

Lieber Herr Eversberg, liebe Liste,


>> Wir hatten vor einigen Monaten eine aehnliche Diskussion, wie man
>> die (unklar) vielen Code- und/oder Termlisten, deren Nutzung unter
>> RDA viel staerker als bislang eingefordert wird, "hinterlegen"
>> kann, ohne Indexparameter aendern zu muessen und auch ohne eine
>> Verteilungsinfrasturktur fuer die aufbereiteten Tabellen
>> einrichten zu muessen - auch hier das Desiderat, die fuer eine
>> allegro-Anwendung benoetigte Aufbereitung (hier: View-Listen)
>> bei Bedarf durch direkten Zugriff auf offizielle Bereitstellungen
>> vor Ort generieren zu koennen.
> Allerdings haben wir weder einen offiziellen Status als Bereitsteller
> irgendwelcher für die Katalogisierung relevanten Materialien,
> und weniger noch maßen wir uns eine normsetzende Berufung an.

Das was wir jetzt als (sekundaere? auxiliare?) Daten sehen war
frueher Bestandteil des Regelwerks und/oder des Datenformats,
jedenfalls waren Ersteller von EDV-Anwendungen in der Pflicht,
ihre Programme so zu gestalten, dass regelgerechtes Arbeiten
moeglich war. Soweit die Theorie, aber daran hat sich eigentlich
nicht viel geaendert. Mit der MARC21-Kultur erfahren wir gerade
die Veraenderung, dass weniger Sachverhalte ueber dedizierte
Unterfelder und mehr ueber als solche gepflegte Code- oder Termlisten
geregelt werden. Geo- und Sprachcodes griffen allerdings immer
auf offizielle Standards zurueck (Hm. - "XA-DE" war fuer den
offiziellen Standard stets ein privater Code ohne Bezug zu "DE"),
hier bringt RDA eine Verpflichtung ins Regelwerk, die bislang nur
in den Systemen bzw. Katalogisierungsumgebungen definiert war


> Unsere Anwender waren vielfach keine nibelungentreue RAK-Gefolgschaft
> und werden wohl auch zu RDA etc. mehr oder weniger Distanz halten. Zu
> einem nicht geringen Teil auch deshalb, weil man dafür weder Zeit hat
> noch Bedarf empfindet. Zu einem geringeren Teil auch, weil einem das
> offiziöse Getöse um "neue internationale Standards" auf den Geist geht.

Aber niemand wird "gegen" RDA katalogisieren wollen, etwa in dem
eine ganz besonders regelgerechte RAK- oder PI-Anwendung perpetuiert
wird. Und niemand (auch D-A-CH-Land als ganzes nicht - so kam es ja
zu den Umstiegsbeschluessen) hat die Kapazitaet, alle Normierungen fuer
sich alleine zu redaktionieren. Natuerlich sind die ISO-Geocodes, die
stets aktuelle politische Gebilde normieren fuer unsere Zwecke noch
nie die beste Wahl gewesen (mit Jugoslawien sind ja nicht alle jemals
dort gedruckten Buecher einfach verschwunden), aber dass es
international nichts geeigneteres gibt nehme ich eher als Indiz dafuer,
dass man als Einzelkaempfer auch nicht versuchen sollte, etwas
besseres zu erfinden.

MARC hat in seinen Feldbenennungskonventionen Mechanismen, verschiedene
Ebenen von Privatheit zu trennen, das RDA-Toolkit bietet an,
individuelle "Workflows" einzustellen. Das wird fuer D-A-CH genutzt,
um die getroffene Auswahl der in RDA formulierten Optionen zu
fixieren und Ergaenzungsdokumente (Praxisregeln) anzubinden, m.W.
koennen darauf aufbauend auch noch zusaetzliche individuelle
Einstellungen oder Annotationen hinterlegt werden (etwa fuer alle
Katalogisierer einer gewissen Bibliothek). Das geht (derzeit?) leider
nicht so weit, dass man aus dem Toolkit heraus eine Liste etwa von
Relationenbezeichnungen und/oder -Codes unter Beruecksichtigung von
Sprache und individuellen Erweiterungen zum Download generieren
lassen kann...

Ich denke, Anwender wuerden sehr gerne fuer alle unter RDA normierten
Sachverhalte die (D-A-CH-)verbindlichen Term- und Codelisten kennen,
auch wenn sie nicht strikt nach RDA katalogisieren wollen: In jede
dieser Listen ist allerhand Fachverstand eingeflossen, sie sind
einfach die Basis zur eigenen Auseinandersetzung mit der Materie
(etwa der "Materie" Funktionsbezeichnungen) und zur Diskussion mit
anderen. Darueber hinaus soll natuerlich ganz allegro-gemaess auch
die Moeglichkeit bestehen, es fuer sich differenzierter bzw. dem
eigenen Material angemessener zu handhaben, das ist eigentlich immer
noch "RDA", aber evtl. nicht mehr der D-A-CH-Standard der Verbuende.
Das ob und wie ist dabei knifflig, auch eine Altbestandsbibliothek
wird nicht die ISO-Geocodes so "erweitern", dass die Deutsche
Staatenlandschaft des 18. Jahrhunderts korrekt abgebildet wird,
aber ein paar zusaetzliche Terme fuer Funktionsbezeichnungen bei
historischen kuenstlerischen Techniken koennten ganz angemessen
sein...

Technisch gesehen muessen wir beruecksichtigen, dass die offiziellen
Listen sich regelmaessig aendern, insbesondere wenn sie auf externen
(also nicht von bibliothekarischen Communities kontrollierten)
Standards beruhen. Und dass Anwender diese Listen fuer ihre lokalen
Beduerfnisse annotieren, veraendern oder erweitern wollen. Das geht
m.E. am besten ueber getrennte Datenhaltung, z.B. ueber (etwa in
PS-Indizes) hinterlegte "Originallisten", zusaetzliche Daten(saetze?)
mit "lokalen Abweichungen", aus deren Kombination dann etwa die
fuer Eingabe benoetigten Viewlisten generiert werden koennen. Bis
dahin ist natuerlich noch einiges zu tun...

Im Fruehjahr war eine ueberraschende Erfahrung, dass es gar nicht
so einfach ist, ueberhaupt die offiziellen Listen zu entdecken,
bzw. wenn man sie entdeckt hat, gibt es oft mehrere Varianten und
man weiss nicht unbedingt, welche nun wirklich verbindlich ist
(die fuer MARC oder die fuer RDA?). Gerade im Fall von id.loc.gov
ist es aber so, dass sie recht einheitlich verarbeitet werden koennen
(SKOS und MADS sei Dank). Seit Juni/Juli gibt es nun auch einige
offizielle D-A-CH-Listen, die sind aber PDF-Dokumente mit Tabellen
und insofern nicht direkt verarbeitbar - hier ist dann eine
Vorverarbeitung erforderlich. Aber ich denke, dass auch unter
der Beruecksichtigung der Umstaende
1. Anwender wollen evtl. von offiziellen Listen abweichen
2. Die offizielle Liste liegt zwar zum Download vor, ist aber nicht
   maschinell verarbeitbar (Textextraktion aus dem PDF mal beiseite)
der Bedarf besteht, diese Liste in beliebige allegro-Anwendungen
zu integrieren. Und zwar indem Anwender eine Funktion anwenden,
die diese Integration durchfuehrt, also ohne dass sie nach den
Daten suchen und dann genuegend viel Parametrierung lernen, um
ihre Anwendung adhoc umzudesignen. Die verlangten Fertigkeiten
sollen also tendenziell deutlich unterhalb derer eines typischen
Systembibliothekars liegen, nicht meilenweit darueber.

viele Gruesse
Thomas Berger