[Allegro] Autoren u.ae. mit ID

[Thomas Berger]

Lieber Herr Eversberg, liebe Liste,

> 2. Das Datenformat ist schlecht designt, wenn ein Feld keine
>    Unterfelder hat, dann koennte es dennoch welche haben
>    (sowohl MAB als auch MARC haben Felder, die entweder keine
>    Unterfelder erlauben oder nur Unterfelder haben, d.h. keinen
>    Text jenseits von Unterfeldern erlauben)
> 
> 
> Typischer Einwand eines Puristen. In allegro ist es doch so, daß der Feldinhalt
> stets mit $$ oder Doppeldreieck so angesprochen werden kann, als wäre es
> ein Unterfeld. Wozu also dann noch betulich ein $a davorsetzen, wie es
> MARC routinemäßig macht und gar nicht anders kann?
> Wir sehen es so, und haben das im "Neutralformat" noch konsequenter umgesetzt,
> daß ein Feld einen Hauptinhalt hat, der kein Unterfeldkennzeichen braucht,
> und es können Zusatzinhalte hinzutreten, die dann als Unterfelder in
> Erscheinung treten. Was wäre daran schlecht?

Dass die Zusatzinhalte z.B. einleitende Wendungen sind, die eigentlich
*vor* dem Hauptinhalt stehen sollten. Und falls interne Wiederholungen
vorliegen, weiss man noch weniger als sonst, ob nun der Gesamt-Inhalt
wiederholt ist (mit fehlenden Unterfeldern) oder der Haupt-Inhalt
(und Unterfelder beziehen sich irgendwie auf alles).

Der Code '$' fuer das fuer den Zugriff auf das Pseudo-Unterfeld "Hauptinhalt"
ist ausserdem verbraten, d.h. man darf ihn nicht fuer echte Unterfelder
benutzen. Das sagt einem aber niemand und ausserdem ist es wie erwaehnt
weniger flexibel als bei einer expliziten Loesung.

Letztendlich sind das aber alles nachtraegliche Rationalisierungen: Wir
alle haben ja jahrzehntelang "Teilfelder" und "Teilfelddreieck" gesagt,
weil wir lange Zeit die MAB-Hybris verinnerlicht hatten, dass Unterfelder
ohnehin voelliger Quatsch sind und nur alles unnoetig kompliziert machen...

Nun leben wir inzwischen in einer Welt, wo MARC-Paradigmen schwer am
Werk sind, d.h. alles ist irgendwie in Unterfeldern (bis auf die subtilen
Ausnahmen). Aber auch in dieser Welt war die Einsicht jahrzehntelang
verschuettet, dass es sich nicht um eigentliche Unter-Datenfelder handelt,
sondern um "Tagging" eines Datenfelds: Leider ein sehr unvollstaendiges,
weil man "vergessen" hat, eine Syntax fuer End-Tags vorzusehen (das wuerde
alles natuerlich noch komplexer und auch komplizierter machen).

Um zum Thema zurueckzukommen: Wie so etwas wie Schluesselersetzungen
in MARC aussehen koennten, ist im Standard eigentlich gar nicht regelbar:
So etwas wie Feld 100 darf zwar (wiederholbar) Identnummernreferenzen
in $0 tragen, man muss dann aber genau das (angeblich transparent)
transportierte Regelwerk kennen um zu wissen, welche Unterfelder aus
MARC-100 redundant zum Normsatz sind (Name, Lebensdaten, ...) und
welche originaer zum Titeldatensatz gehoeren (Funktionsbezeichnung,
Funktionscode, ...) und kann dann nur hoffen, dass die Reihenfolge
des einzukopierenden derjenigen im Titelsatz entspricht und dort
auch nicht durch anderes unterbrochen ist...

Wenn so etwas wie ein v14-Mechanismus Text in oder mit Unterfeld-Markup
einfuegt, stellt sich auch sofort die Frage, wie das in einer Intern-
darstellung zu Taggen ist, damit auch die Parameterdatei "sehen" kann,
wo der Ersetzungstext endet und der als solcher erfasste Inhalt des
Feldes weitergeht. Fuer HANS habe ich seinerzeit dafuer Unter-Unterfeld-
Zeichen ▲ erfunden, d.h. fuer die Ersetzungsschluessel werden die
Unterfeldzeichen ▼ einer strukturierten "Ansetzung" in ▲ gewandelt
und beim Verarbeiten im Objektsatz dann je nach Bedarf ausgeblendet
oder in ▼ zurueckgewandelt: Ganz schoen kompliziert alles...

viele Gruesse
Thomas Berger