[Allegro] Persistent Storage

[Thomas Berger]

Liebe Liste,

unter PS (Persistent Storage) waren ja mit Version 34.0 die
"Persistenten Variablen" eingefuehrt worden, also in einem
Index (und damit Sitzungs- und Benutzeruebergreifend) abgelegte
Daten. Im Prinzip ist das (wie die Indizes ueberhaupt) ein
klassischer "Key-Value-Store", d.h. ueber einen Key kann
man zugreifen und bekommt dann irgendwelche Daten.

Syntaktisch geht dies ueber

&foo=blabla  (Zuweisung)
var "blabla"\ins &foo
var "&foo=blabla"\ins

bzw.

var &foo      (Auslesen)
var "&foo"\var


Diese Zugriffe sind nur in der Flex/Job-Sprache moeglich,
kennt man allerdings die interne Bezeichnung des Index, in
dem die Werte abgelegt sind, kommt man auch per Parameterdatei
dran (Default: "~z1", also Register 1 der optionalen
Indexdatei dbname.cZx).

Will man beispielsweise ISBNs korrekt mit Bindestrichen
versehen, benoetigt man Informationen zu etwa 1.100
individuellen "Ranges" die die Internationale ISBN-Agentur
unter < https://www.isbn-international.org/range_file_generation >
bereitstellt: Fuer jede der etwa 220 Sprach- oder Laender-
gruppen (Registration Group Prefixes, Bsp. 978-3) ist individuell
festgelegt, wieviele Stellen das naechste Strukturelement
(Registrant Range) in Abhaengigkeit seiner Anfangsziffern hat
(etwa 978-3-031-... ein Range der Laenge 3, 978-5-03-... ein
Range der Laenge 2 etc.).

Fuer korrekte Strichsetzungen muss man also entweder ein Programm
schreiben, das 1100 explizite Fallunterscheidungen hat oder eines,
das auf die benoetigten Daten als Daten zugreifen kann, etwa durch
eine Nachschlageoperation in einem Index... (Benoetigt werden
"unscharfe" Nachschlageoperationen, d.h. Schluessel, die
am naechsten vor bzw. nach einem Suchbegriff gelegen sind,
das qrix-Kommando der Flex-Sprache ist dafuer recht gut geeignet)

 %--

"Klassisch" muesste man sich fuer die 1100 Datenelemente eine
Satzart ausdenken mit zugehoerigen Kategorienummern, diese
in der jeweiligen .CFG hinterlegen und anschliessend in den
Indexparametern dafuer sorgen, dass die geeignet indexiert
wird. Dann muss eine Importroutine die Rohdaten in diese
Satzstruktur wandeln und das Resultat der Umwandlung ist
in die Datenbank zu laden.

Mit den Persistenten Variablen geht das einfacher:
1. Wandle die XML-Daten in Textdaten mit einem Datenpunkt pro Zeile um,
   hier etwa in der Form

### Prefix: 978-91 (Sweden)
97891=>978-91-(2)
978-91-0-000000=0000000-1999999(1)
978-91-20-00000=2000000-4999999(2)
978-91-500-0000=5000000-6499999(3)
978-91-6500000-=6500000-6999999(range not defined for use)
978-91-7000-000=7000000-7999999(4)
978-91-8000000-=8000000-8499999(range not defined for use)
978-91-85000-00=8500000-9499999(5)
978-91-9500000-=9500000-9699999(range not defined for use)
978-91-970000-0=9700000-9999999(6)
...

(dahinter steckt keine tiefere Wahrheit, der Beispiel-Algorithmus
braucht das halt so oder so aehnlich und der PS-Mechanismus fuegt
ohnehin irgendwo ein "=" ein wenn er keins findet)


2. Lade (fast) jede Zeile $line als
var "&" $line
ins
   in den PS-Index.


 %--

Der (eine) Persistenz-Index ist damit natuerlich ziemlich zugemuellt,
ausserdem aendert sich die ISBN-Datenbank mehrmals im Monat (die
wenigsten Aenderungen schlagen sich zwar in geaenderten Ranges
nieder, aber ab und zu durchaus), d.h. man will diese Daten
auch bei Bedarf en bloc neu laden und muss davor alle alten
Daten entfernen. Aber natuerlich nur die zu ISBN-Ranges, nicht
die sonstigen Notizen...

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. (Beispiele waren die ISO-Codes
fuer Staaten und Sprachen, die bei der Library of Congress
vorgehalten werden. Unter < http://id.loc.gov/ > gibt es
noch allerhand weitere "Datasets", da muss man genau hinsehen,
welche fuer MARC21 gedacht sind und welche fuer RDA, falls
das in der Praxis einen Unterschied macht...
Fuer die D-A-CH Anwendungsschicht der RDA sind entsprechende
Listen in den letzten Wochen teilweise unter der Adresse
< https://wiki.dnb.de/display/RDAINFO/Regelwerk >
veroeffentlicht worden, leider stets nur als PDF, nicht in Form
von Daten: Da werden wir um eine Verteilungsinfrastruktur also
nicht herumkommen, zumindest uebergangsweise)

Man koennte nun die Rohdaten ebenfalls zunaechst in den
Persistenten Speicher laden (dort koennte man sie mit
lokalen Ergaenzungen zusammenfuehren) und in einem zweiten
Schritt aus den im Index vorgehaltenen Daten die Viewlisten
produzieren: In diesem Fall haette man die Chance, etwa Codes
nicht nur eingebbar zu machen, sondern koennte in den
Daten vorhandene Codes auch datenbankgestuetzt wieder aufloesen...

Vermutlich kommt man mit den ca. 250 verschiedenen Indizes
(1-11 jeweils in xxx.aDx ... xxx.aZx) aus, d.h. selbst ich
behaupte nicht, dass eine "Normalanwendung" auch unter RDA-
Bedingungen mehr als 250 Mini-Thesauri und Vokabularlisten
benoetigen koennen sollte. Ich sehe aber Konflikte, wenn
demnaechst staendig fuer neu hinzukommende Mini-Listen ein
eigener Index requiriert werden muss, der /ueberall/
noch frei ist (und danach /ueberall/ tabu sein soll ausser
fuer diesen Zweck). Eine praktikablere Loesung sieht daher
fuer mich so aus, dass *ein* (oder wenige) Indizes genutzt
werden, um die Daten aus mehreren Datasets aufzunehmen,
dazu muessen nur fuer das Dataset spezifische Praefixe
gewaehlt werden, etwa als ISIL/MARC-Organisationscodes
oder als Namespace-URLs (vgl. etwa, wie auf Windows-Rechnern
das Starmenue, der Progamm-Ordner oder die Registry
organisiert sind: Jeder, der schreiben will, tut dies in
einem Bereich, der mit "seinem" Namen beginnt und organisiert
den entsprechend seinen Beduerfnissen.


 %--

Ich habe einen Flex (datasets.flx) entworfen, der eine Art
API fuer das Management von Datasets im Persistenten Speicher
mit Praefixen darstellt, sowie eine Beispielanwendung (.xslt-
Datei zur Aufbereitung, und isbndata.flx) mit Doppelfunktion:
Einerseits das Management der ISBN-Range-Information mittels
der Funktionen von datasets.flx, andererseits konkrete
Utilities zum Aufruf durch Anwender oder Einbinden in andere
Flexe: Strichsetzungen und - dazu braucht man die Datenpunkte
natuerlich nicht - Pruefziffernberechnung -oder -Test fuer
ISBN-10 und ISBN-13

Das mag als Utility nuetzlich genug sein, um einige dafuer
zu interessieren, insofern kommen da evtl. ein paar interessante
Use-Cases zusammen (wann und wie wird man so etwas anwenden
wollen: Zum Automatischen Ergaenzen von ISBN-13's, wenn nur
ISBN-10s im Datensatz vorliegt bzw. umgekehrt? Fuer Strich-
Setzungen im Einzelfall oder fuer ganze Ergebnismengen?
Routinemaessig bei jeder Eingabe? Zum Konsultieren oder zum
tatsaechlichen Hinterlegen?).

Ich bin aber eher an den Designfragen fuer die Organisation
der "kooperativen" Nutzung des einen Persistenzspeichers
interessiert (kann/sollte man Vorverarbeitungen hier
integrieren, genuegen "load", "unload" und "inspect" als
Verwaltungsfunktionen fuer datasets, welche Metadaten
benoetigt man wirklich (Timestamp der Daten, Timestamp
der Verarbeitung, Dateiname/URL der Rohdaten, ...), muss
man andere Zeichensaetze ausser UTF-8 verarbeiten koennen
etc.

Auch Usability ist ein Thema, einerseits will man Routinen
einfach als Unterprogramme aufrufen koennen, anderseits
die "Verwaltungsfunktionen" eher interaktiv im a99-
Schreibfeld ausloesen.

Mein Vorschlag ist daher, dass ich meinen Stand im Lauf
der naechsten Woche bei GitHub einstelle, damit Interessierte
sich daran bedienen und damit experimentieren koennen:
Download geht m.W. anonym, Kommentarfunktionen evtl. nur
nach Anmeldung, git als Software hingegen braucht man
eher nicht (bzw. gewiss nicht: Ich gehe nicht davon aus,
dass das Projektdesign endgueltig ist und werde in diesem
fruehen Alpha-Stadium auch bestimmt keine automatisierten
merge requests verarbeiten ;-)
Falls es andere Vorschlaege gibt, wie ich Test- bzw.
Diskussionsversionen zugaenglich machen sollte, bin ich
gerne bereit, die zu beruecksichtigen (deswegen schreibe
ich diese Mail, /bevor/ ich die Sachen irgendwo eingestellt
habe).

viele Gruesse
Thomas Berger