[Allegro] Umgang mit Mehrfachkennung (Mehrfachkategorien)

[Thomas Berger]

Lieber Herr Eversberg,


> Das letztere ist aber, soweit ich sehe, das *einzige* Kriterium und
> Monitum, das diese Diskussion ausgelöst hat! Mit allem anderen kann
> man anscheinend also ganz gut leben.

In HANS gab es schon vor 10 Jahren, also bei der Einfuehrung
von a99 Probleme: Wenn Sie erst einmal (Stammbuecher, Skizzenhefte,
aber warum eigentlich nicht auch bei Aufsaetzen in Zeitschriften-
baenden?) hunderte verknuepfter Unteraufnahmen haben, entgleisen
die Flips, weil die #uZ- und #uY-Variablen dafuer nicht genuegend
Folgebuchstaben bieten.

Und an Beispiele wie von Herrn Allers kann ich mich auch schon
aus PRESTO-Zeiten erinnern: Wenn ein bedeutender Katalog hunderte
von Kuenstlern auf je einer Seite auflistet, ueber die es sonst
nix zu finden gibt, dann gibt es Institutionen die zaehneknirschend
(da es niemand anders fuer sie tut) hunderte von Kuenstlern zu
einer Publikation erfassen. (Und da Personeneintraege dieser
Natur tendenziell einelementige Schlagwortfolgen sind, also
einige der Eintraege um Unterfelder angereichert werden koennten,
ist interne Wiederholung keine gute Option)


> Wäre es da nicht besser, erst einmal die Alternativen auszuloten:
> -- Nicht eine, sondern mehrere Grundkategorien verwenden, und jede
>    davon nur mit Buchstaben weiter differenzieren, nicht mit
>    Sonderzeichen

Ah, Sie meinen in der CFG zwei Folgebuchstaben reservieren, und
dann von AA bis zz hochmultiplizieren? Mir persoenlich ist das
Dezimalsystem fuer Zaehlungen sympatischer, aber wenn Sie meinen,
dass das hilft kann ich auch trainieren versuchen, BASE64-codiertes
fluessig zu lesen.

> -- Die interne Feldwiederholung wahlweise oder zusätzlich nutzen

Interne Feldwiederholung ist im Standardschema ziemlich rudimentaer
und unheilich: mal ";" mal "; " oder " ; " mal "¶" mal "[¶;]":
Da muesste also das Datenformat strikter werden und alle Datenbanken
waeren retrospektiv komplett umzuarbeiten, damit das nicht nur als
Inselloesung funktioniert.


> -- Pseudo-RDF-Tripel als verknüpfte Datensätze mal genauer ventilieren!
>    Damit wären keine internen Änderungen verbunden!

Wir wuerden dafuer aber eine Art umgekehrte SR benoetigen:

"Raueber" (aus dem Titelsatz) plus "Schiller" (eine der 500
lose angehaengten Personen) sollte dann den "uebergeordneten"
Record treffen...

Alternative (und auch das hatte ich einmal als Desiderat in den
Ring geworfen:) Datensaetze koennen bei der Indexierung Schluessel
fuer andere Saetze produzieren.

Das Hauptproblem ist aber m.E., das durch diesen Weg das urspruengliche
Problem verschaerft wird: Der Benutzer soll ja durchaus mit der
Fiktion eines "Records" arbeiten, und bei ORDER klappt das auch
ganz gut, es werden Abfragemasken praesentiert und die Eingaben
im Hintergrund auf Titelsatz, Bestell- und Exemplarsaetze
verteilt. Oder unter ALFA kann man auf eine Signatur klicken und
die Angaben zur Ausleihe werden im korrekten Unterband eingetragen:
Habe ich nun viele ausgelagerte Einzeldaten, die mir a99 irgendwie
als zum Datensatz gehoerig gemeinsam praesentiert und zur Bearbeitung
anbietet, habe ich entweder ein Navigationsproblem oder ein Zwischen-
speicherproblem, jedenfalls wird man als erstes gerade wieder bei
den Folgezeichen an Grenzen stossen.


>> In MARC-artigen Formaten (zumindest bei den
>> data fields, nicht bei control fields und leader) ist das gegeben:
>> Diese haben keinerlei Content jenseits von Unterfeldern...
>>
> Mit ... wollen Sie ja nur diese *Möglickeit* bei allegro als Mißgriff
> diskreditieren. Dabei ist es ein zusätzliches Feature, das niemand
> nutzen *muß*. Vielleicht bin ich aber der einzige, der in dem
> stumpfsinnigen $a, mit dem jedes MARC-Feld zu beginnen hat, keine
> Eleganz, sondern nur Betulichkeit erblicken kann.

Aufregend wird es in den Faellen, wo ein Feld zwar $a hat, aber
nicht damit beginnt...

viele Gruesse
Thomas Berger