200x-Phänomen

[Thomas Berger]

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

Liebe Frau Koczian,

| Genau genommen ist die Anwendung der Restriktionen nicht dasselbe wie
| die normalen logischen Operationen. In den "klassischen"
| Kommandosprachen für bibliographische Datenbanken (lustiger Begriff, ich
| war 1980 zum ersten Kurs bei INKA, heute STN) konnten die
| Einschränkungen (Sprache, Erscheinungsjahr u.ä.) gar nicht vor der
| eigentlichen Suche angewandt werden. Und so etwas wie Expansion kommt da
| sowieso nicht ins Spiel. Das Argument mit der Kommutativität passt also
| auf den ersten Blick nicht so recht.

Das Problem ist, dass die Operation "Restriktion anwenden auf
Ergebnismenge" (bzw. ihre Abwandlung "Restriktion anwenden auf
zukuenftige find-Befehle") mit der Notation "and" versehen ist.
Die Verwechslung mit dem normalen "and" ist natuerlich gewollt,
aber auch irgendwie fatal.


| Nur, _wenn_ beides möglich ist, und dann gibt es verschiedene
| Ergebnisse, das ist dann schon erwartungswidrig. Aber es scheint mir
| völlig unklar, welches der möglichen Ergebnisse eigentlich korrekt wäre:
| Einbeziehen von untergeordneten Aufnahmen, weil die übergeordnete
| Aufnahme das Restriktionskriterium erfüllt, oder hinauswerfen, weil sie
| selber es nicht erfüllen.

"normal" ist das nie ein Problem: So ein Filter funktioniert eigentlich
wirklich wie ein AND und man kann ihn daher auf Teilterme anwenden und
dadurch einen Performancegewinn erhalten.

Schwierig wird es erst im Zusammenhang mit der SR-Expansion, auch
schon bei normalen Verknuepfungen ohne Restriktion:

Implementiert ist nur (A und B Platzhalter fuer eine Kombination
Register + Suchbegriff):

find &A and &B

d.h. es wird immer erst expandiert und dann geschnitten, was fuer
das klassische Schiller-Raeuber-Problem genau das richtige ist.
In anderen Faellen (wie hier bei der Verknuepfung mit Erscheinungs-
Jahren) haette man aber lieber

find A and B ; "dann expandiere"

Problematisch ist nun die Optimierung der Filterwirkung der Restriktion:
Sie wird eben nicht nur auf die Teilergebnisse "&A" und "&B" angewandt,
sondern bereits auf "A" und "B" (sonst waere es mit der Optimierung auch
nicht weit her). Und weil das unaere "&" nun wirklich nicht distributiv
ist, haben wir den Salat.

viele Gruesse
Thomas Berger

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

iD8DBQFBLbqeENVh3bB0lwMRArAWAJ4okxUmelr6rN2UgDNMU2uwyQdw8wCfZH4b
e5AFHQ5z061+lYMSHHp4yGo=
=UerO
-----END PGP SIGNATURE-----