[Allegro] Umgang mit Mehrfachkennung (Mehrfachkategorien)

[Thomas Berger]

Lieber Herr Eversberg,

>> 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.
> Aber ist es denn sinnvoll, in JEDEM Fall, wo ein Satz angezeigt wird,
> ALLE damit verknüpften auch sofort anzuzeigen? Ist das effizient und
> schnell?
> Gibt es keine Alternativen, etwa auf Abruf eine ViewListe oder aresqa-
> Liste?
> Was Sie da anscheinend für unverzichtbar halten, kann man auch als
> Overkill sehen. Und beim Web-Katalog spielen die #uZ. usw. eh keine
> Rolle.

Wenn Sie fragen, ob a99 ein Auslaufmodell ist, das moeglichst
schnell abgeschafft werden sollte, ist meine Antwort "ja".

Von "unverzichtbar" hatte ich uebrigens nicht gesprochen. Sie
hatten unterstellt, dass kein Anwender jemals Probleme mit
den gegebenen Grenzen gehabt oder zumindest artikuliert haette
und ich habe dem meine Erfahrungen entgegengestellt.

Alternativen gibt es viele denkbare, man koennte z.B. allegro
in allegro neu erfinden:
Unspezifische Felder #0000 - #ZZZZ enthalten jeweils am
Feldanfang als !abc die Nummern der Fremdfelder: Import.exe
macht das auch selbst bei ISO-Saetzen (Befehl "F"`?) und
anderswo ist das eine Zeitlang als MARC-Park-Feld auch sehr
beliebt gewesen. Aber darum sollte es ja hier eigentlich
nicht gehen.


>>> 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,
> Nein, das meine ich nicht, sondern für ein vielfach vorkommendes
> Element nicht eine, sondern mehrere gleichwertige Feldnummern
> vorzusehen.

Ich meine, Sie versuchen den Anwendern "kognitiven Ballast" aufzubuerden,
dabei sollte das gerade bei der Arbeit mit Computern nicht so sein.


>>> -- 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
> 
> Nein, das Standarschema ist dafür kein Maßstab, in einem eigenen
> können Sie so strikt sein wie Sie wollen, das ist davon unabhängig.

dann scheidet das als Alternative aus (auch wenn ich meine Daten zehnmal
so strikt erfasse hilft das ja keinem anderen $A-Anwender mit seinen
Daten).


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

ist nicht besonders exotisch:

852 	##$3v. 1-6$a [location identifier] $bScience Library$t1

[generell sind Unterfelder ja ohnehin ein irrefuehrender Begriff:
Man kann sich nicht oft genug in Erinnerung rufen, dass in MARC21
die Datenfelder durch eingestreute $<irgendwas> "getaggt" im
Sinne von phrasiert sind, die Felder aber generell so erfasst
werden, dass sie beim Weglassen exakt dieser zusaetzlichen
Zeichen einem Menschen einen halbwegs sinnvollem Eindruck vermittelnt.
Und der kann das recht universelle $3 dann recht gut verstehen,
auch wenn "$" und "3" nicht gezeigt werden, wenn der Inhalt als
eine Art einleitende Wendung dem Rest vorangestellt ist...]

viele Gruesse
Thomas Berger