[Allegro] Proposal: Transport neutraler = formatuebergreifender Sachverhalte

Mi Jan 28 10:20:30 CET 2015

Lieber Herr Eversberg, liebe Liste,

vielleicht sollte man nicht mit der GND beginnen, obwohl
bei einem derart komplexen Gebilde der zu erwartende Gewinn
durch Nachnutzung von Loesungen jeweils anderer allegro-
Formate vielleicht am groessten ist.

Wie schon einmal erwaehnt, wird fuer einige Sachverhalte (z.B.
Funktionsbezeichnungen) die Nutzung von Codes in der RDA-
Katalogisierung der D-A-CH-Anwendungsschicht zwingend sein,
wobei die Codes selbst ebenfalls vorgegeben sind.

[RDA erlaubt auch Text, MARC21 ist da neutral, in den betreffenden
Feldern gibt es Unterfelder sowohl fuer Text als auch fuer Codes,
sowie - wichtig! - Unterfelder fuer die Angabe des zugrundeliegenden
Regelwerks bzw. Codesystems/Vokabulars. Die RDA erlauben aber auch
in der generischen Form mitnichten Wildwuchs, dass (und welche)
Bezuege zwischen Personen und Werken durch die Katalogisierung
zu verzeichnen sind, ist Bestandteil des Regelwerks, nur das
wie (also konkrete Benennungen) haengt unter anderem von der
Sprache des Katalogs ab. http://www.rdaregistry.info/Elements/w/#P10065
ist daher ein Thesaurus von zugehoerigen Konzepten, die "creator"
zugeordnet sind. Amerikanische Katalogisierer begruessen die
Chance, das durch die textliche Benennungen fallweise zu verfeinern,
nach striktem D-A-CH-Regelwerk werden evtl. nur die Codes
Gueltigkeit haben (geplant sind wohl die "Standard"-MARC21-Codes,
die in Richtung RDA adaptiert wurden, <
http://www.loc.gov/marc/annmarcrdarelators.html >), d.h. zusaetzlich erfasste
textuelle Benennungen werden als redundant erachtet.
Die "GND Ontologie" < http://d-nb.info/standards/elementset/gnd >
liefert Bezuege zum RDA-Vokabular sowie deutsche und englische
Labels, scheint aber nicht vollstaendig. Moeglicherweise aber
ist im RDA-Toolkit (mir nicht zugaenglich) eine verbindliche
Liste von deutschen Bezeichnungen fuer die den MARC-Codes entsprechenden
RDA-Konzepte aus Anhang RDA-I hinterlegt.]

Angenommen nun (ich dachte nicht, dass das so schwierig ist), es gibt
eine Liste von Codes mit hierarchischen Bezuegen und deutschen
Benennungen, sowie moeglichst noch den Identifiern der RDA Registry,
dann ist die relevant fuer jede Anwendung, die im D-A-CH-
Umfeld Daten erzeugt bzw. konsumiert, und fuer einige Anwendungen
moeglicherweise absolut verbindlich. Diese Liste sollte in Form von
Daten vorhanden sein (im Gegensatz zu: als Text irgendwo abgespeichert
bzw. in alle moeglichen Parameterdateien fest einprogrammiert) und
kann dann von den Anwendungen genutzt werden, um Codes aufzuloesen
(bei Anzeige, Indexierung, Export bzw. vielleicht auch beim Import
von Daten) und geeignete Menues und View-Dateien (Code -> Text und
Text -> Code) zu generieren.

M.E. lohnt es sich hier, ein Universalfeld fuer "RDA-Codes" einzufuehren,
mittels dessen so eine Liste dann im ADT-Format bereitgestellt werden
kann: Die Anwendung "kennt" das Feld dann entweder, oder sie hat
einen Flex, der die Daten offline liest, in ein anderes Feld umsetzt
oder per ixadd die benoetigte Information direkt in Indizes injiziert
und View-Dateien etc. generiert - fuer die waere das dann eben ein
"virtuelles" Datenfeld...

Unterfelder waeren wie erwaehnt solche fuer
- den Code
- ein deutsches "Label"
- ggfls. eine Synopse
- Verweis auf uebergeordneten Code
- URI
- Identifier fuer die Codeliste (es sollen ja nicht nur Funktionsbezeichnungen
  so kommuniziert werden, sondern das Feld soll alle im (RDA)-Kontext
  benoetigten Codelisten so abgebildet werden koennen, ohne dass die
  als ein Brei ankommen.
- geeignete Metadaten zur Versionierung (zweimal im Jahr gibt es ein
  "MARC-Update", Codelisten werden auch oefters erweitert, das ist
  aber stets ein kontrollierter Prozess. Jedenfalls sind "Daten zum
  Regelwerk" nicht in Erz gegossen - genauso wenig wie das Regelwerk
  selber uebrigens...)

Ein Datenfeld sollte dabei unbedingt nur die Informationen zu einem
Code abbilden, mittels HFM-Technik koennen dabei dann die Informationen
zu recht vielen (im Funktionscode/-bezeichnungen- Beispiel wohl durchaus
allen) Codes in einen Datensatz zusammengefasst werden, denkbar ist dann,
die Saetze zu allen Codesystemen in einer einzigen Datei "rdacodes.adt"
zu buendeln. [.adt ist dann vielleicht der falsche Name, Bereitstellung
sollte m.E. UTF-8- oder meinetwegen ISO-5859-1-codiert erfolgen]

Die Struktur sollte die einer "flachen Tabelle" sein, natuerlich sind
die Unterfelder "Identifier fuer die Codeliste" und "geeignete Metadaten"
fuer jeden einzelnen Code so einer Liste identisch, die Information sollte
aber nicht aus anderen Feldern oder gar anderen Datensaetzen herbeigesucht
werden, wenn die Anwendung es benoetigt.

*********************
Ein zweites Beispiel:
vs.alg in der Standard-Installation von allegro ist im Prinzip eine
"als allegro" aufbereitete Version der Unicode-Datenbank, so wie man
sie fuer die VS-Methodik benoetigt. D.h. wenn im Datensatz steht
"Ố" dann kann damit ueber geeignete Indexschluessel die benoetigte
Form  fuer Index, a99-RTF-Darstellung, UTF8-codierten Text etc.
abgeleitet werden (allegro ist notorisch schlecht im Rechnen, daher muss
das Ergebnis der Umrechnung von 7888 zu U+1ED0 bzw. 225 187 144 hinterlegt
werden).

vs.alg ist 2008 irgendwie zustandegekommen, seitdem hat es mehrere neue
Unicode-Versionen gegeben, manchmal werden Codepunkte in einem Feld
zusammengefasst, manchmal nicht, und was in diese Felder #9A (eigentlich:
ORDER-Systemsaetze) hineincodiert ist, ist schwer zu ermitteln.

Ich hatte etwa um dieselbe Zeit fuer eine Anwendung einen eigene Satzart "VS"
implementiert, dort ist dann (zu Ố) gespeichert:

#02 vs7888
#VS 1ED0
#VS0225 187 144
  ▼bá»
#VS1LATIN CAPITAL LETTER O WITH CIRCUMFLEX AND ACUTE
#VS2Lu
  ▼c0
  ▼bL
  ▼mN
#VSD7888
#VSK00D4 0301
#VSM
  ▼l1ED1
#VSpO
#VSr\u7888\'4f

Was das im einzelnen bedeutet, muesste ich auch erst nachsehen, jedenfalls
enthaelt dies skriptgeneriert wesentlich mehr Informationen aus der
Unicode-Database (4.x oder was seinerzeit aktuell war, etwa die Benennung
in #VS1, diverse Properties wie "Lu - Letter uppercase" in #VS2 und die
kanonische Dekomposition in #VSK) plus eben noch einiges errechnetes
(RTF-Darstellung in #VSr, ASCII in #VSp, UTF-8 in #VS0$b etc.):
Das sind dann die im Index zu hinterlegenden Umsetzungen fuer die VS-Methode
in diversen Szenarien (eines davon war Editieren mit Notepad).

Das liesse sich mit geeigneten Unterfeldern auch in einem Feld #vs
unterbringen, wobei per HFM-Technik dann allerhand solcher Codepunkt-
Beschreibungen in einen Datensatz passen koennten (am besten mit einer
gewissen Regelmaessigkeit, vielleicht passen sogar 256 Beschreibungen
in einen Datensatz?). Neuere Erkenntnis ist, dass wohl auch besser
die zugehoerige Unicode-Version haette hinterlegt werden sollen...

Auch hier bestuende dann die Moeglichkeit fuer die Anwendungen, die
Saetze mit den #vs-Feldern zu "koennen", oder aber vereinfacht so
eine bereitgestellte Datei durchzuhaspeln und nur die geeigneten
VS-Schluessel in die Register zu setzen (als "Persistente Variable"
in eigener Indexdatei geht es wohl nicht, da VS-Ersetzungen an den
Hauptindex .c*D*X gebunden sind?)

Anlaesslich neuer Versionen der Unicode-Datebank kann dann eine
Person daraus per Skript eine neue Version der "vs-unicode.adt"
erzeugen und fuer alle allegro-Anwendungen bereitstellen.
(die Datei enthaelt im Zweifel UTF-8-Zeichen und Ostwest-Codes,
sie kann also nur als "Bytes" bereitgestellt werden und nicht
in einem fixierten Zeichensatz. Ich ueberblicke leider nicht, ob
das ein Problem fuer Anwendungen darstellt, die intern mit UTF-8
arbeiten)

Jedenfalls: Auch hier ein Beispiel, wo das Generieren der Daten mit
einiger Muehe verbunden ist (bzw. v.a. *nachhaltig* zu geschehen
hat, die Hauptarbeit geschieht extern und hat "Releases", das muss
regelmaessig nachvollzogen werden), die allegro-Anwendungen hingegen
benoetigen keine besonders grossen Eingriffe (pro Feld gezielt
gewisse Schluessel Key->Value in irgendeinen Index setzen) und kann
sogar - je nach Gestaltung des Import-Flex dazu - ausserhalb der
klassichen Parametrierung auf "virtuellen" Feldern arbeiten.

viele Gruesse
Thomas Berger