[Allegro] avanti-x->FLEX: find ( CLA 27.3.2 ) geht nicht, warum?

[Thomas Berger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lieber Herr Jahnke, lieber Herr Jakobza,


> mein erster Verdacht ist, dass es sich um ein Problem der Zeichenersetzung handelt, 
> denn die Suche mit dem Punkt ist - vorausgesetzt, Sie benutzen die die $A-
> Kofiguration, so wie sie standardmäßig ausgeliefert wird - auch mit a99 in Register 7 
> nicht möglich (Probieren Sie mal "f CLA &17.82?" in der Demo-Datenbank, eigentlich 
> sollten 19 Treffer kommen)

korrekt. Allerdings gibt es "." im Register ueberhaupt nur fuer Inhalte
aus #30k, fuer alle anderen werden sie vernichtet ("." ist jedoch eines
der Lieblingszeichen aus Notationssystemen, also ist in/mit den
Standard-Parametern alles ausser #30l, #30g, #30h, #30k sowieso kaum
nutzbar).


> Der Hund liegt in der cat.api begraben:
> 
> #-7
> #u1 +# y0 i4,G
> #u1 +# y0 i4,H
> #u1 +# y0 i4,S
> !u1
> #+#
> 
> sorgt dafür, dass die Eingabe des Benutzers vor der Suche umkodiert wird und zwar  
> nach der q-Tabelle (durch "!u1"). Eingaben, die mit G,H oder S anfangen werden nicht 
> umkodiert (wg. "y0", stünde y0 nicht da, würden sie nach der p-Tabelle umgesetzt). 
> Die Tabellen finden Sie in der Datei i.apt. Dort heisst es
> 
> q !// =1    delete all codes from ! to /
> q & +       but reactivate a few:
> 
> q + +
> q , , 
> q - -  
> q / 47
> 
> was bewirkt dass alle Zeichen von 0x21 bis 0x2F ersatzlos gestichen werden, wobei 
> &,+,# und / dann doch wieder aktiviert werden. Der Punkt (0x2E) kommt also gar nicht 
> beim Avanti-Server an, steht aber im Index (Zeile 478 in der cat.api: !u1 f"?" y0 p"|7", 
> sorgt dafür, dass Kategorie #30k ohne Umkodierung in den Index geschrieben wird ). 

alles voellig korrekt analysiert.

> Dh entfernen Sie aus der cat.api in Zeile 478 das "y0" (dann neu indexieren) oder 

fuehrt zu Notationen ohne "."

> fügen Sie in i.apt eine Zeile q . 46 ein (ich weiß allerdings nicht, ob das dann 
> anderswo zu unerwünschten Effekten führen kann).

Schwer zu sagen. Punkte aus Initialen von Vornamen geraten dann in den
Index, auch Punkte aus Sachtiteln. Viele davon werden aber sofort wieder
vernichtet, denn der Parameter i3 sorgt dafuer, dass Punkte am Ende
von Schluesseln beseitigt/bereinigt werden.

Eine vernuenftigere Loesung waere m.E., in den Indexparametern bei
(fast) allen Inhalten fuer Register 7 auf Umcodierung bei der
Indexierung zu verzichten. Das ist eine maechtigere Ueberarbeitung,
als der halbwegs einfach zu verstehende Code bei #-M vermuten laesst,
denn Suche nach "|7" in den Indexparametern offenbart, dass x Sorten
Stammsaetze ihre eigenen Notationen ebenfalls ins Register 7 setzen.


> Das wäre meine Idee zu Ihrer Frage, allerdings kommt es mir merkwürdig vor, dass 
> bislang noch niemand sonst das Problem bemerkt hat, will sagen: möglicherweise 
> befinde ich mich hier auf dem Holzweg, dann würde ich mich auch über ein Bisschen 
> Nachhilfe aus der Liste freuen.

Ich denke der Grund ist, dass "nackte" Notationensuche kaum brauchbar
ist, zum mindesten muesste man pro Notationssystem eine Seite vorhalten,
die die systematische Ordnung zeigt und auf die Treffer "verlinkt". Das
geht in Web-Anwendungen relativ simpel, unter a99 knn man einen
View dafuer vorhalten (wirklich empfehlenswert: Wenn Sie ein
Textdokument mit Ihrer Systematik haben, koennen Sie mittels
Textverarbeitung und Makros in wenigen Sekunden daraus eine View-
Datei erstellen, die die gesamte Systematik auflistet und zu jeder
Systemstelle die zugehoerigen Titelrecherche ausloest).
Interessant wird es dann, wenn man vorhandene Klassifikations-
Stammsaetze zur Generierung dieser HTML-Seiten oder Views heranziehen
moechte...

viele Gruesse
Thomas Berger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDccIzENVh3bB0lwMRAm+QAKDGxxDKshXDSz86RFQm4b5mezwldACgzLe7
KtSte0I7TDnVUJxtcYwG7o0=
=YhEl
-----END PGP SIGNATURE-----