Re: Satzübergreifende Suche

[Roland Henkel]

Hallo Herr Berger, liebe Liste

ich habe Frau Miericke folgenden Vorschlag gemacht, leichtfertigerweise
freilich ohne das vorher auszuprobieren.

1. Man nehme in den Ersatzungsschlüssel alle Kategorien des Stammsatzes
(also z.B.
Berufe) auf, die später einen Schlüssel mit dem verknüpften Titelsatz bilden
sollen.

Etwa so
123=|Aname<trennteichen>beruf<trennzeichen>...

Bei der Bildung des Schlüssels im Titelsatz verfährt man dann etwa so (#u1
soll die Kategorie des Titelsatzes sein, in dem die Identnummer des
Stammsatzes steht)

#u1 e"<trennzeichen>" p"|i"                                 #für name
.... weitere Anweisungen zur Schlüsselbildung :::


#u1 b"<trennzeichen>"  e"<trennzeichen>" p"|k"     #für beruf
.... weitere Anweisungen zur Schlüsselbildung :::


usw.

Natürlich sollte man bei Bedarf auch zusammengesetzte Schlüssel aus
irgendwelchen Kategorien des Titelsatzes und der Verknüpfungskategorie
bilden können.

Ganz komfortabel wäre es, wenn man als <trennzeichen>
$a, $b usw. verwenden könnte, wobei $ das Teilfeldtrennzeihen sein soll.

Dann könnte man die obigen Anweisungen nämlich so formulieren

#u1 $a p"|i"
#u1 $b p"|k"

usw.

Die Pseudoschlüsselbildung  müßten freilich dieses Verfahren irgendwie
berücksichtigen.

Ich habe mit einer kleinen Testdatenbank erste, allerdings eher zwiespältige
Resultate erzielt, was aber auch an der mit fortschreitender Stunde sich
häufenden Tipfehlerhäufigkeit liegen mag.

Deshalb meine Frage, ob aus Ihrer Sicht etwas grundsätzliches gegen dieses
Verfahren spricht? Seit meinen letzten Krämpfen mit Stammsatzverknüpfungen
neige ich etwas zur Skepsis.


Gruß und Schönes Wochenende
R. Henkel

----- Original Message -----
From: "Thomas Berger" <ThB at gymel.com>
To: "Diskussionsliste Allegro-C" <allegro at buch.biblio.etc.tu-bs.de>
Sent: Thursday, August 09, 2001 3:47 PM
Subject: Re: Satzübergreifende Suche


> Liebe Frau Miericke,
>
> > kann ich die satzübergreifende Suche auch bei Verwendung von Stammsätzen
> > benutzen, um eine kombinierte Suche durchzuführen? Ich komme dabei mit
> > meinen Versuchen nicht weiter. Oder kann man das Problem auf eine andere
> > Weise lösen?
> > Beispiel:
> > Im Personenstammsatz steht der Beruf, im anderen Datensätzen (die die
> > Identnummer des Personenstammsatzes in einer Kategorie haben) ist die
> > Beschreibung zu einem Porträt. Ich möchte nun alle Porträts einer
> > bestimmten Berufsgruppe finden.
>
> Im Prinzip ist der v14-Ersetzungsmechanismus "zu gut":
> Titelsaetze bekommen ueberhaupt nicht mit, ob verknuepft
> ist oder nicht. Die Identnummerninformation, die man
> fuer die Bildung von S/R-Schluesseln benoetigt, ist also
> eliminiert.
>
> Ich behelfe mich in der Praxis mit einem Mix aus folgenden
> Mechanismen:
>
> 1. Wird der OPAC durch einen Export der Datenbank realisiert,
>    so erzeuge ich eine Zusatzkategorie, in der alle Identnummern
>    von verknuepften Stammsaetzen stehen (mit #u01/#u02-Schleife
>    beim Export ermittelt). Die Indexparameter erzeugen dann
>    zu jedem Eintrag in dieser Spezialkategorie einen
>    Verknuepfungsschluessel.
>
> 2. Die wichtigsten Ersetzungsschluessel (von denen kontrollierbar
>    ist, in welchen Kategorien sie benutzt werden) enthalten
>    jeweils noch einmal die Identnummer, von Spezialzeichen
>    umgeben. Die Abschnitte der Indexparameterdatei, die
>    mit solchen Kategorien umgeben, erzeugen einerseits mit
>    u-Manipulationsbefehlen den ausgabefaehigen Schluessel
>    und andererseits noch einen SR-Schluessel.
>
> 3. (Extremfall von 2). Die .cPI mit i4=5 betreiben.
>
> Eine aehnliche Fragestellung ergibt sich ja auch, wenn
> man bei der a99-Anzeige aus jedem verknuepften Feld
> einen Hyperlink basteln moechte.
>
> Ich hatte des oefteren angeregt, fuer .cPR's und .cPI's
> einen parametrierbaren Abschnitt "globale Nachbearbeitung"
> einzufuehren (aehnlich dem Abschnitt beim Pauschalimport
> beim Import oder der neuen Registermaskerade fuer Indexausgaben):
> Jede Ausgabe wuerde noch einmal in solch einen Sonderabschnitt
> geleitet und koennte dort nachverarbeitet werden. Die Anregung
> wurde aber leider nie aufgegriffen :-(
>
> viele Gruesse
> Thomas Berger
>