[Allegro] Noch ein Vorschlag: Unterfeld $0 ?

[Thomas Berger]

Lieber Herr Lackhoff, liebe Liste,

bevor ich meine Caveats abspule nur kurz der Hinweis, dass ich
dem Vorschlag eigentlich zustimme ;-)


> ich moechte anregen, in allen Feldern, wo dies sinnvoll ist oder sein
> koennte ein Teilfeld $0 zuzulassen, um ID(s) aufzunehmen. Beispiele:
> $0(DE-101c)310008891
> $0http://d-nb.info/gnd/112367267

Hoppla, ich wuerde sagen (DE-588)112367267 und muesste
vielleicht sagen (DE-588a)112367267 : Ohne Kenntnis der
Historie des Datensatzes nicht ganz einfach zu entscheiden...

Und ist 101c nicht inzwischen auch meist DE-588?

[Zeigt nur, dass man selbst dann nicht immer zusammen findet, wenn
man mit derselben Nummer operiert. Umso wichtiger, nicht festgelegt
zu sein und ggfls. mehrere Nummern so notieren zu duerfen]


> $0http://viaf.org/viaf/36978042
> 
> Ich halte es fuer sinnvoll, solche IDs mitfuehren zu koennen, wenn
> vorhanden und zwar zusaetzlich zum Klartextnamen.

Das ist - vermutlich nicht zufaellig - vergleichbar dem Fast-Universal-
Unterfeld $0 in MARC21, das uebrigens beliebig haufig vorkommen kann.

$0 - Authority record control number or standard number


In dem Zusammenhang gibt es noch mehr interessantes, vgl. die "Control
subfields", < http://www.loc.gov/marc/bibliographic/ecbdcntf.html >:

$5 - Institution to which field applies
(falls man verschiedene Sorten "output" produzieren moechte, ganz
nuetzlich)

[$6 eine Feldverknuepfungstechnik fuer originalschriftliche
Parallelerfassung einzelner Felder]

[$8 ein interessanter, aber extrem umstaendlicher Weg, etwa die
Provenienz gewisser Informationen zu dokumentieren]

Ziemlich universell, aber nicht in diesem Anhang sind:

$2 - Source of heading or term
Angabe eines Codes fuer Regelwerk bzw. benutzes Vokabular/Termliste
(manchmal verwirrend, wenn der eigentliche Inhalt des Felds selber
ein Code ist)

$3  - Materials specified
Also Angabe des Teils der Ressource, auf den sich das jeweilige Datenfeld
bezieht, hatten wir erst heute im Kontext von #8e, ist aber ein
allgemeineres Prinzip.


In der Summe bewirken diese "orghogonalen" Unterfelder, dass MARC21
mit recht wenigen eigentlichen Feldern auskommt: Klassifikatorische
Erschliessung oder solche mit Sachschlagworten kommt mit jeweils nur
einem Feld aus - das jeweilige Sacherschliessungssystem kann mittels
$2 angegeben werden (sofern es einen /registrierten/ Code dafuer gibt)



> Und nein, ich rege nicht an, einen Flex zu schreiben, dieses Feld
> ueberall einzufuegen[1] und der Klartextname muss auch nicht in ein
> Subfeld $a. Es geht mir nur darum, dass es erstens eine dokumentierte
> Moeglichkeit ist (*wenn* jemand solche Identifier mitfuehren will, dann
> bitte so) und dass zweitens die Standardparameter moeglichst damit
> umgehen koennen und sei es nur, dass sie die Nummer im Zweifel abschneiden.

Die Indexmaskerade ist ein Praezedenzfall, die PV war es:

Ansaetze zu einem nachgelagerten Filtermechanismus / Universalunterprogramm
fuer Arbeitstexte.

Im Prinzip ist eine pauschale Nachbearbeitung jeglicher Ausgaben
schon ganz lange ein Desiderat in Exporten:

Der Umcodierungen gibt es viele, und in 99,9% aller Faelle ist eine
Zeichenkette auf dem  Weg von Datensatz zur Ausgabedatei exakt
keinmal oder exakt einmal umzucodieren. Muss man kleinschrittiger
vorgehen, Inhalte zerlegen, speichern, zusammenfuehren, entsteht
viel Aufwand beim Sicherstellen, dass das genau so funktioniert,
also nicht etwa doppelt. Manche Manipulationsbefehle (wie "=")
heben von sich aus die automatische Umcodierung auf, andere
wiederum (alles mit "Laengen" oder die y-Befehle) erzwingen sie,
allerdings wird u.U. nur ein Teil der benoetigten Ersetzungen
ausgefuehrt. Bei UTF-8-Exporten ist es ausserdem ganz nett, wenn
man noch haufenweise lokaler Ersetzungen ausfuehrt, die Zeichen
kombinieren, die in OSTWEST nur dekomponiert speicherbar sind.

Ein nachgelagerter Ausgabefilter, dessen Existenz dazu fuehrt,
dass Umcodierungen anlaesslich der Verarbeitung in der Kategorie-
liste gaenzlich unterbleiben, bzw. genauer auf den definierten
Zeitpunkt der tatsaechlichen Ausgabe verschoben werden, haette
den Vorteil, das eigentliche Programm in der Parameterdatei
deutlich schlanker zur machen und vermeidet, dass Zwischenergebnisse
der Verarbeitung in irgendwie undefinierten und schwer kontrollierbaren
"Zwischencodierungen" vorliegen.

Im Rahmen so einer Nachbearbeitung koennte dann selbst wieder mit
Exportbefehlen gearbeitet werden, z.B. e$? zum Abschneiden beim
ersten Unterfeldzeichen.

Zu einer weiteren Anwendungsmoeglichkeit siehe weiter unten.


> Der Vorschlag bezieht sich natuerlich auf eine Anfrage, die ich vor
> einiger Zeit gestellt hatte, mit dem Fazit, dass mit den bisherigen
> Moeglichkeiten (V14-Verknuepfungen) nur ID oder Klartextname moeglich
> ist, nicht beides. Daneben haben V14-Verknuepfungen (neben manchen
> Vorteilen) noch ein paar weitere Besonderheiten, die sie als Alternative
> zu meinem Vorschlag wenig geeignet erscheinen lassen.

Ich will Ihnen da nicht unbedingt widersprechen, moechte aber die
seit langem existierenden Teilloesungen aufzeigen:

I.
"V23"- statt v14-Verknuepfungen:
Ich habe eine Anwendung von $A.CFG, die statt
i5=_
mit
i5=^^
operiert ("_" kommt in URLs, leider auch Sachtiteln, und etwa auch
Identifiern oder lokalen Umformulierungen zur Leerzeichenvermeidung
doch eher haeufig vor, daher wurde anlaesslich der Umstellung auf
"V23-Verknuepfungen" geleichzeitig ein momentan unbedenklicheres
Verknuepfungszeichen gewaehlt.

Sieht dann so aus:

#20 Nachtrag zu meinem Aufsatz : "Zur Funktion und Bedeutung katholischer
Kirchenbibliotheken
#31 Kirchenbibliotheken; Buchkultur; Katholische Kirche
#37 ger
#40 ^(DE-588)129666165^
#70 ^zdb2096669^
#70412, 2012
#70835-45
#76 2013

("zdb" und nicht "(DE-600)" weil das alte Verknuepfungen sind, denen
z.B. aus v14-Gruenden die Pruefziffer genommen wurde)

Die notwendigen Anpassungen an den Standardparametern hielten
sich fuer die Umstellung von Verknuepfungsmodus und -zeichen
durchaus noch in vernuenftigen Grenzen.
(-> < http://svn.gymel.com/acxt/produkt/vv23dir/ > )

II.
Fuer Titelverknuepfungen wie in #70 war es schon bei v15 misslich,
dass einem der Verknuepfungsmechanismus die Tatsache kaschiert, dass
eine Verknuepfung ueberhaupt vorliegt. Dabei wuerde man ja gerne
einen Flip oder Link zur Titelaufnahme anbieten. Man kann nun
die Parameterdatei generell auf i4=5 umstellen, das ist dann
aber auch wieder ein Fall, wo jedes Feld, in dem Verknuepfungen
auftauchen koennen (bei allegro dank des flexiblen Mechnismus
also: ALLE) nicht mehr einfach so ausgegeben werden kann, sondern
zu bereinigen ist: Laestig. Bzw. man koennte in einer universellen
Nacharbeitungsroutine nicht nur bereinigen, sondern gleichzeitig
per Zusatzformatierung dafuer sorgen, dass jede Verknuepfung dann
als Flip auf den verlinkten Datensatz aufbereitet wird: Schick!

Der Ersetzungsschluessel fuer Zeitschriften sieht eigentlich in
allen meinen Anwendungen (leicht vereinfacht) so aus:

   1  ^zdb2096669^=|5►zdb2096669-6►Analecta Coloniensia◄

D.h. auch mit i4=1 bekomme ich etwas durch Steuerzeichen
strukturiertes, das die (eine, die derzeit "beste")
Verknuepfungsnummer enthaelt und dann noch die Ansetzung:
Mit u►► kann ich das auch im vorhandenen Umfang der Parameter-
sprache gut bereinigen (muss das aber auch), komme bei
Bedarf aber jederzeit an den Stammsatz heran, etwa um ISSN's,
Zusaetze zum Sachtitel oder Bestandsangaben abzugreifen.
Das "◄" am Ende des Ersetzungsschluessels ist dann eine Markierung
die Anzeigt, bis wohin (sollte die Verknuepfung *eingebettet*
in eine Kateogorie sein - etwa bei Stuecktiteln in #85) der
Anzeigetext fuer den verlinkten Inhalt geht, der dann als Flip
o.ae. aufbereitet wird. Das funktioniert leider nicht, wenn die
Indexlaenge den Ersetzungstext trunkiert. (Urspruenglich eingefuehrt
hatte ich das glaube ich, um genau auf dieses fehlende Abschluss-
zeichen zu testen: In dem Fall wird der Satz explizit nachgeladen,
damit stets der /volle/ Sachtitel gezeigt werden kann)

Aehnliche Mechanismen nutze ich (nicht in dieser Anwendung), um
ueber die Identnummer und die Ansetzung hinaus noch weitere
Inhalte vom Norm- in den Titelsatz zu transportieren. In allegro-
HANS etwa sind Funktionsbezeichnungen gegendert, die Codes werden
aber geschlechtsneutral erfasst. Das funktioniert, weil der
Normsatz den Code fuer das Geschlecht ueber den v14-Mechanismus
in die Titelaufnahme drueckt, dort kann dann anhand des erfassten
Codes fuer die Funktion und dem Code fuer das Geschlecht der
verknuepften Person die entsprechende Aufloesung aus dem Register
herbeipraktiziert werden. (die d-wrtf.hpr ist schon laengst auf
i4=5
umgestellt, und jede Verknuepfung wird als Flip angezeigt. Das
bot sich an, weil jegliche Ausgabe ohnehin durch einen Satz
von Standard-Unterprogrammen gefuehrt wird, die Interpunktion
einfuegen muessen, da kann dann auch gleichzeitig bereinigt und
aufbereitet werden)


III.
< http://svn.gymel.com/acxt/produkt/enhancementsdir/dw-alt.apt >
ist ein Beispiel fuer eine verbesserte a99-Internanzeige (F5):
Hat man viele Verknuepfungen, sieht man entweder nur Nummern
(seit letztem Jahr) oder nur Texte (und wuesste gern, ob die
aus Verknuepfungen stammen und wenn ja, aus welchen). Diese
Alternative Alternativanzeige mit #u01/#u02 und einem kleinen
Unterprogramm eine viel ueberschauberere Aufgabe als allgemeine
Parameterdateien, kennzeichnet alle Verknuepfungen und ermoeglicht
das Aufsuchen der Zielsaetze


Aaaaber: Auch in MARC21 ist $0 nicht ganz unproblematisch:

MARC 700 (Nebeneintragung unter Person oder Person/Titel) erlaubt
viele Unterfelder, dabei sind $a (Ansetzung) und $d (Lebensdaten)
eigentlich immer vorhanden und sollten identisch mit den gleich
benannten Unterfeldern aus MARC 100 des zugehoerigen Normsatzes
sein. $i hingegen (eher exotisches Feld bei Bearbeitungen etwa
kann man damit angeben, dass dieses Name/Titel-700er-Feld die
Vorlage ist) macht nur Sinn im Kontext der Vorlage und bei
$e/$4 fuer Funktionsbezeichnungen bzw. -codes haengt es davon
ab, ob 700 fuer eine Person steht (dann ist es die Funktion
der Person in Bezug auf die vorliegende Ressource) oder ein
Name/Titel-Eintrag fuer ein Werk ist - dann stehen sie fuer
die bereits im Normsatz bestehende Relation.

Bei $0 ist es nun auch nicht klar: Ist das (die Nummer, des
Normsatzes) nun eigentlich etwas, das ebenfalls aus dem
Normsatz kommt (ist ja eine ganz zentrale und invariante
Eigenschaft), analog den Verknuepfungsbeispielen oben, wo
die Verknuepufngsnummer zusammen mit der Ansetzung "injiziert"
wird? Oder ist es eine parallel notierte Information (MARC
hat kein Verknuepfungs- oder Schluesselersetzungsparadigma,
man wird aber davon ausgehen koennen, dass "Das Ansetzungs-
feld" in den referenzierenden Satz gespiegelt wird, - da
steht die Nummer ja nie drin).

In MARC 773 (bibliographische "Aufwaerts"-Verknuepfung fuer
Baende oder Aufsaetze) gibt es kein $0, weil dort mit $w
schon aeltere Vorkehrungen fuer den Transport von Verknuepfungs-
informationen getroffen wurden. Die Unterfelder fuer
bibliographische Information sind auch eher spaerlich
($a - Main Entry Heading + $g - related parts) daher weiss
ich gar nicht, wie man Unterreihen oder Themenhefte abbilden
kann. Hier sehe ich jedenfalls ein Problem analog komplexen
MAB-45x, dass "die" Quellenangabe durch eine Hierarchie
von Datensaetzen im eigenen Katalog abdeckbar waere:

Dieser Aufsatz << ein bestimmter Band << ein bestimmter
Stuecktitel << in zeitschriftenartiger Reihe

und die Verknuepfung eigentlich sehr differenziert aussagen
muesste, auf welche Kombination der anderen Unterfelder
sie sich bezieht...

IV.
Die GND wird in MARC21 ausgedrueckt, d.h. "die Ansetzung"
ist in Wirklichkeit nun eine MARC21-100 mit Unterfeldern.
Haette man nun eine GND-Nutzung in U.CFG, also MARC21-
Daten, benoetigte man diese Unterfeldcodes ebenfalls und
haette nun zwei Moeglichkeiten:
1. Ersetzungsschluessel reflektiert Ansetzungsfeld, d.h.
   $a, $d etc. werden einfach 1:1 in den Schluessel
   uebernommen.
2. Das, was aus dem Normdatensatz hereintransportiert wird,
   soll unbedingt noch eine Einheit sein, der engere
   Bezug zwischen den Unterfeldern des Ersetzungstexts
   untereinander im Gegensatz zu sonstigen Unterfeldern
   der Titelkategorie wird so ausgedrueckt, dass der
   Ersetzungsschluessel andere Steuerzeichen (Unter-Unter-
   Felder) enthaelt.

Will man die (allegro-Alleinstellungsmerkmal) Moeglichkeit
erhalten, in einem Datenfeld mehr als eine Verknuepfung
zu haben, kommt 1. eigentlich nicht in Frage (und auch
der $0-Vorschlag kommt an seine Grenzen, denn fuer welchen
Teilinhalt soll die konkrete $0 nun die Verknuepfungsummer
darstellen?)

Ich bin ueberzeugt davon, dass die ganzen bibliothekarischen
"Verknuepfungsmechanismen", die aus irgendwie neben die
"eigentlichen" Inhalte getopften Verknuepfungsnummern bestehen,
nicht wirklich etwas taugen, wenn man sie mit Hypertext
vergleicht: Also den aus HTML und XML bekannten Mechanismen,
einerseits Text zu notieren, aber andererseits durch spezielles
Markup (in allgemeinster Syntax!) ganz zielgerichtet durch
Attribute oder Unterelemente diesem Text eine zusaetzliche
Ebene als Sub- oder Meta-Text zu spendieren. Insofern halte
ich allegro-Verknuepfungen trotz aller Probleme durchaus
fuer attraktiver als die vorgeschlagene $0-Loesung, die
allerdings den Vorteil hat auch dann zu funktionieren, wenn
es in der lokalen Datenbank keinen Normsatz gibt...

Aber egal ob V23-Verknuepfungen mit i4=5 oder $0-Loesungen
mit oder ohne weitere, "orthogonale" Unterfelder: Mit dem
von mir eingangs skizzierten Universellen Nachformatierungsfilter
wuerde beides (auch simultan) zu einem maechtigen und auch
wieder einfach zu implementierenden Werkzeug!

Schoenes Wochenende
Thomas Berger