[Allegro] phpac: kleines problem bei mehrfachtreffern

[Thomas Berger]

Lieber Herr Eversberg, liebe Liste,

> Es hängt somit einzig an den Indexparametern, speziell an dem Abschnitt
> zur Umcodierung für das betr. Register und den zugehörigen p- oder q-Befehlen.

Und da gibt es bei der Standard-cat.api diverse Ungereimtheiten:

- Der Kommentar erwaehnt etwas von ▼o, m.W. enthaelt aber nur #89o
  Werkverzeichnisnummern

- Fuers Register wird "Op" ohne Leerzeichen vor die Nummer gesetzt,
  wenn der Arbeitstext nur aus einem Wort besteht. Das reflektiert
  zwar die unselige Anweisung im allegro-Format, "op." nicht hinzuschreiben,
  fuehrt aber zu sehr putzigen Effekten, wenn man etwa das im
  Kommentar genannte "BWV432" als Inhalt von #89o ausprobiert.

- Es wird ohnehin nicht beruecksichtigt, dass in diesem Bereich
  die Kuerzel fuer das Werkverzeichnis (oder "Op.") recht
  uneinheitlich mal mit und mal ohne Spatien vor der eigentlichen
  Nummer stehen.

- Die Heuristik bei #-3 fuehrt dazu, dass stets ein ueberfluessiges
  "|3" vor den Suchbegriff gesetzt wird

- Die Heuristik bei #-3 untersucht, ob das erste Zeichen der Eingabe
  ein Grossbuchstabe ist und in den ersten 7 Zeichen eine Ziffer
  ungleich 0 vorkommt, das hat der Autobahn "A30" schon viel Freude
  gemacht (die wuerde bei "op" gesucht, wenn es nicht durch den
  Fehler im vorigen Punkt vor "a" landet)

Ein Teil der Probleme sind von dem Kaliber, wie wir es letztes Jahr
mit den Zugangsnummern im Unterregister 9Z durchdekliniert haben.
Verschaerft wird das aber dadurch, dass die Werknummern in das
recht allgemeines Register 3 (Mix aus Stichworten und Phrasen
aus Schlagworten) indexiert werden soll, und eben die wenigsten
Werkverzeichnisnummern mit "Op." beginnen (und gar keine nur
aus einer Zahl bestehen): So sehr ein (insbesondere "vernuenftig"
sortierter) Werknummernindex ein Desiderat sein mag, ist es doch
aussichtslos den in einem Stichwortregister zu verstecken, auch
- bzw. gerade - wenn man bedenkt, dass diese Werknummern in oft
uneinheitlicher Schreibweise bereits im Sachtitel vorkommen und
in eben dieses Register indexiert werden: Es kommt dann zwangslaeufig
zu Eintraegen "bwv432" "bwv 432" und "bwv  432" und keine Umcodierungs-
logik kann Ihnen die retrospektiv zusammenfuehren. Vor allem aber
kann keine Umcodierungslogik zweifelsfrei erraten, ob die Eingabe
ein Stichwort oder eine Werknummer sein soll, insbesondere wenn
sie nur aus dem Anfang "bwv" eines Suchbegriffs besteht.

Zudem - wie Herr Lehmann zu Telemann bemerkte - gehoert zu einem
Werkverzeichnisregister nicht nur die korrekte Sortierung, sondern
auch dass ein Benutzer die fuer das jeweilige Werkverzeichnis
typische Interpunktion wiedererkennen kann: Ein ziemlicher Widerspruch
zu den fuer Stichwortregister ueblichen Normierungen.

Und um der Sache den Todesstoss zu versetzen: #89o als
"Standardnummer" ist ein merkwuerdiges Konstrukt: Normiert wird
ja normalerweise ueber den Einheitssachtitel, der auch vermerken
kann, ob es sich um Auszuege, Arrangements, Stimmen etc. handelt
(und die dann noch zu erfassende Standardnummer bei Musikdrucken
ist die Plattennummer), nur ist da wiederum die Werknummer
zwar normiert, aber nicht von den sonstigen Informationen abgetrennt
in den Titel hineinformuliert. Bei Tontraegern duerfte es aehnlich
sein, nur dass man sich seltener die Muehe der EST-Bildung macht und
oft diverse Werknummern zusammenkommen.
Und bei Literatur ueber ein Werk werden EST-artig mehrgliedrige
Person/Werktitel-Ansetzungen gebildet. #89o ist also nicht Standardnummer,
sondern eine normierte Inhaltsbeschreibung im Sinne eines - je nach dem -
zusaetzlichen Titelstichworts oder Schlagworts.

Fazit: Ein Datenfeld mit unscharfer Bedeutung, fuer den Index behandelt
auf eine Weise, die ganz abstrakt schon nicht funktionieren kann,
aufgehuebscht durch mehrere Programmierfehler: Ab in die Tonne damit!

viele Gruesse
Thomas Berger