[Allegro] V30 am Zeithorizont

[Thomas Berger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lieber Herr Eversberg, liebe Liste,

> Um nicht am Bedarf vorbeizupreschen, geben wir hiermit Gelegenheit,
> Vorschläge und Wunschvorstellungen zu äußern. Das können auch
> Kleinigkeiten sein, über die man sich lange schon ärgert, es
> können größere Dinge sein - "nein" sagen können wir immer auch noch,
> wenn es sich um Wolkenkuckucksvisionen handelt. (Sollte etwa jemand
> exklamieren "Alles nur noch XML und Unicode!".)

Hm, gerade das wollte ich gerade sagen ;-)

Aber im Ernst: Es hat ja in den letzten Jahren viele interessante
Ansaetze (Unicode-Methoden 1+2, VS-Sequenzen, Janas) und Helferlein
(Z39.50-Client, HTTP-Client, just gestern: rudimentaere Webservices)
gegeben, die fuer meinen Geschmack immer im Stadium eines Demos
geblieben sind. Ausserdem bringt dieses Jahr die Anfaenge der
Umstellung relevanter Fremddaten von MAB2 auf D-MARC als Lieferformat,
es gibt interessante Web-Anwendungen (ZACK, DNB-Datenshop) und
Webservices (etwa die Aktivitaeten von Jakob Voss beim GBV mit
seinen SeeAlso-Services, LibraryThing, ZDB und EZB etc.)

V30 koennte also z.B. folgendes tun: Die Standardanwendung wird
aufgemoebelt, alle Im- und Exporte kommen auf den Pruefstand und
werden auf aktuelle Datenquellen und Lieferformen angepasst.
Dazu dann (in Hilfeseiten) auch entsprechend aktuelle Infos.
Die "Oberflaeche" hierfuer sollte vorzusgweise Janas sein, denn
hier gibt es mehr und praktischere Bedienelemente (naemlich die
von HTML) als in a99, wo es nur Flips und Formulare gibt. Hierbei
werden sich - so hoffe ich - auch Verbesserungen in Janas und
anderen Elementen der Flex-Sprache ergeben, bzw. auch JavaScript-
Fragmente, die sich in echten Web-Anwendungen nutzen lassen
(man koennte z.B. JSON als Basis der Kommunikation zwischen Janas
und dem Kern-a99 waehlen und evtl. einen (single-Threaded) Mini-
HTTP-Server in a99 integrieren, um gewisse "Originalitaeten" der
Kommunikation mit a99 abzuloesen).

D.h. der Ansatz sollte folgender sein: Die vorhandenen Features
zu einer "runden" Nutzbarkeit ausbauen, dabei dann aber nicht
vor einem gruendlichen Redesign zurueckschrecken, wenn es Sinn
macht: Einige dieser Features haben abgesehen von der Standard-
auslieferung in inst-all.exe keine weiteren Anwendungen (evtl. gerade
wegen Designproblemen? zumindest sind meine persoenlichen
Erfahrungen mit Janas so) und man braucht auf Kompatibilitaet mit
Frueher wenig Ruecksicht zu nehmen.

Zudem sollte eine offizioese Migration der Datenbanken zu
Standardzeichensaetzen stattfinden, fuers A-Schema etwa CP850
plus VS-Sequenzen. D.h., Anwender, die nicht wollen, brauchen nicht,
die jedoch, die wollen, duerfen koennen: Zu tun ist ja nicht
viel mehr, als global "&" in "&" umzuaendern, zentral
bereitgestellte VS-Datensaetze zu integrieren (deren Format
sollte dann aber festgeklopft werden, wir hatten hier auf der
Liste bereits einmal eine Ansatzweise Diskussion, diese VS-Saetze
sind i.W. eine allegro-Version der Unicode-Datenbank, hier kann
man also auch ueber Online-Updates nachdenken...) und aktuelle
Parameterdateien einzsetzen. Dafuer dann also ein Mechanismus,
der die Migration der Datenbank auf Anforderung durch den
Benutzer durchfuehrt. [Mittelbar muss man in den Standardparametern
dann aber aufpassen, dass "; " als Trenner mit Vorsicht zu geniessen
ist?]. Denkbar waere auch, dann gleichzeitig Verknuepfungen von
_Id auf _Id_ umzustellen, dann braucht man in Fremddaten nicht
so kraeftig die Pruefziffern zu trimmen und kann die immer
verbreiteteren strukturierten Identnummern nutzen
(oai:d-nb.de/swd/992761743)

Apropos Format: Unterstriche sind inzwischen endemisch, zuerst
tauchten sie massenweise in URLs auf (wo man sie - meist -
als %5F escapen kann, wenn man sie erkennt, denn auch ausserhalb
von #8e, etwa in Fussnoten tauchen wie auf, dann meist lax
zitiert ohne http:// etc.), nun aber gibt es auch immer mehr
Titel, wo "_" vorkommt: Weil es so modern und internetmaessig
aussieht (alles Moden natuerlich, vor ein paar Jahren gab es
oft "@" in Titeln, glaube ich mich zu erinnern), jedenfalls sind
sie nun da. Man muesste einmal darueber nachdenken, ob Zeichen
mit Steuerfunktion (¬, ▼, _, @) in den Daten auf allgemeine
Weise als solche erfasst werden koennen.

Das A-Format sollte gleichzeitig behutsam umgekrempelt werden,
viele Festlegungen stammen aus Zeiten von vor MAB2 (insbesondere
das Format fuer Personennormsaetze ist aelter als die PND, wie
wir sie heute kennen), die zu beruecksichtigen Regelwerke sind
natuerlich noch aelter, aber auch hier gibt es Normen fuer
Geo- und Sprachcodes etc., die sich im Gegensatz zu anderen
durchgesetzt haben. Und typisch gewordene Datenfelder (DOI?
NBN-URN?, Verbunduebergreifende Identnummer, ...), die im
Standardformat noch nicht behandelt sind.

Speziell bei Normdaten waere zu ueberlegen (vgl. die VS-
Datensaetze mit der Information aus der Unicode-Datenbank oben),
ob man es nicht schafft, diese weitestgehend konfigurations-
unabhaengig zu definieren: Fuer "selbstgemachte" Normsaetze
reichen die vorhandenen Strukturen, wer aber nennenswert Daten
aus der echten PND bezieht und einsetzt (z.B. die HANS-Anwender
in HANS.CFG, Kunst- und Museumsbibliotheken mit $A.CFG) spiegelt
eine konkrete Anwendung/Datenbank (naemlich die PND) und will
(auf den Datensatz bezogen) eigentlich keine Umstrukturierung
der Information und moeglichst sogar die Original-Feldnummern
behalten. Andersherum: Koennte es moeglich werden, mit einer
"Hybriden" Konfiguration zu arbeiten, naemlich alles in
A.CFG plus Normdaten im MARC21-basierten GND-Format? So direkt
gewiss nicht, das ist mir klar, aber evtl. gibt es ja Methoden,
die Formate ineinander zu konvertieren, die weitgehend mechanisch
funktionieren und Original-Feldnummern irgendwie erhalten:
Das MARC-Format der DNB sieht momentan auch so aus, dass in
einem endlos wiederholten MARC-Feld 999 dann die MAB-Feldnummern
als Herkunftszeichen kommen nebst ihren Inhalten. Vielleicht
sollte man also Normdaten einfach Feld fuer Feld nach #GNff.
importieren und braucht dann nur eine Erweiterung der ak-Syntax
auf funktional
ak=GN."\=800"
(holt mir Fremd-Feld 800), wobei es allerdings "eingebaut" sein
sollte, damit ich auch weiterhin mit etwa "\▼a" feiner navigieren
kann. In Anzeigeparametern wird es etwas kniffliger, mit den
s-Befehlen kann ich zwar den Startpunkt auf "wie original"
setzen, es fehlt aber ein effizienter Weg fuer das benoetigte
"nehme die Wiederholung von #GN, die mit "800" beginnt".



> Man muß, wie immer im Leben, die Bodenhaftung wahren, die Füße normal
> auf dem Teppich, und das ist kein fliegender.

... aber bewegen tut er sich schon ...

viele Gruesse
Thomas Berger

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBSaZpU2ITJZieluOzAQL3UAP/flmejuYsc1I0GEnL9iLNNKC+AMBkT4ri
7sWvMb/OZqk2qNw38PPBsE3zjJkBnVC3MlqlZ4TMLO91CfwxHhQdZMl56zGx9Yu8
yr118UjMJsCc1ph6soKJvBoJiWfOqiN2iWreplkfJUm3ytEP1E0seto2VxDpsMTp
KWrIIOY//BE=
=JQr9
-----END PGP SIGNATURE-----