Fahrplan zur Vufind-Nachnutzung
Was ist zu tun, wenn eine Bibliothek selbst vufind ausprobieren möchte? Zu diesem Thema lässt sich viel schreiben. Daher haben wir uns entschieden, eine kleine Serie zu starten und die einzelnen Schritte zur Nachnutzung von Vufind zu dokumentieren und zu beschreiben. Gewisse Grundkenntnisse in der Administration und Konfiguration von Webservern werden vorausgesetzt; Programmierkenntnisse werden jedoch nicht verlangt.
Zum Betrieb einer Vufind-Installation benötigen Sie lediglich einen Webserver mit PHP-Unterstützung. Unser „Howto“ bezieht sich dabei nur auf einen Linux-Server. Am einfachsten geht das z.B. mit Ubuntu (dafür steht sogar ein Debian-Paket für Vufind zur Verfügung). Vufind sollte sich allerdings auch auf einem Windows-Server mit IIS o.ä. nutzen lassen.
Read more…
Hilfreiche vufind-Scripte
Im Nachklang zur Verbundkonferenz, wo ich beschrieb, dass es gar nicht so schwer ist, vufind selbst einzusetzen, wollen wir noch versuchen, mit ein paar Tipps zur Installation weiterzuhelfen.
Die Scripte können in einem gesammelten Archiv vufind-tub-scripts heruntergeladen werden.
Wie im Vortrag nachgelesen werden kann, ist es möglich, eigene Daten aus dem CBS per Z39.50 zu extrahieren und im MARC-Format zu speichern. Wir haben dafür ein Script vorbereitet, das dabei helfen kann. Es findet sich in der zip-Datei als z3950fetch.php. Im Quelltext müssen drei Parameter angepasst werden:
$user=“999″; // Ihr Z39.50-Username
$passwd=“abc“; // Ihr Z39.50-Passwort
$host=“z3950.gbv.de:20012/harb_opc“; // host port database
Wichtig: Das Script benötigt PHP mit YAZ-Unterstützung. Diese sollte sich eigentlich mit dem Kommando
# pecl install yaz
installieren lassen.
Bei uns wird dieses Script einmal täglich mit den Parametern vom Vortag ausgeführt. Dazu haben wir ein kleines Bash-Script gebastelt, das einmal täglich per Cron ausgeführt wird (CBS-cron.sh). CBS-cron muss ins gleiche Verzeichnis gelegt werden wie z3950fetch.php. Außerdem wird ein Unterverzeichnis namens archiv benötigt.
Um die BKL in den Index zu integrieren, muss der Index zunächst um drei Felder erweitert werden. Das geht in der solr/biblio/conf/schema.xml:
<field name=“bkl“ type=“string“ indexed=“true“ stored=“true“ multiValued=“true“/>
<field name=“bklnumber“ type=“string“ indexed=“true“ stored=“true“ multiValued=“true“/>
<field name=“bklname“ type=“string“ indexed=“true“ stored=“true“ multiValued=“true“/>
Diese Zeilen können direkt unter der Zeile
<field name=“recordtype“ type=“string“ indexed=“false“ stored=“true“/>
eingefügt werden.
Um die BKL-Klassen aus dem MARC-Input zu extrahieren, benutzen wir ein Mapping-Script (bcl.bsh), das genau das macht, was im Vortrag auf der Folie 11 „Implementierung: Import – Einbindung der BKL“ beschrieben ist. Das Script muss ins Verzeichnis import/index_scripts kopiert werden.
Die Einbindung dieses Mappingscripts erfolgt in der import/marc_local.properties mit folgenden drei Zeilen:
bkl = script(bcl.bsh), getBkl
bklnumber = script(bcl.bsh), getBklNumber
bklname = script(bcl.bsh), getBklName
Das ist auch erstmal alles; demnächst mehr Scripte und Anpassungen.
TUBfind-Vortrag auf der Verbundkonferenz
TUBfind wurde heute auf der Verbundkonferenz im Rahmen des Workshops der FAG TI vorgestellt.
Zum Nachlesen hier die Folien zum Herunterladen.
UPDATE: Jetzt gibts die Folien auch als PDF.
Große Änderung, (erstmal) kleine Auswirkung
Im Hintergrund von TUBfind hat sich was getan, was nach außen nur in einer kleinen Änderung sichtbar ist. Die Suche über Webseiten- und Weblog-Inhalte läuft ab sofort über verteilte Indizes. Vorher hatten wir alle Inhalte in einen Index geschmissen, was keine Probleme verursachte und funktionierte. Aber die Einschränkung auf bestimmte Inhalte war nur über die Facettierung möglich. Nach der Änderung kann die Einschränkung schon vor der Suche vorgenommen werden. Dies hat nun auch zur Folge, dass (im Gegensatz zu vorher) nicht mehr bei der Standardsuche alles, sondern nur noch die ausgewählten Indizes durchsucht werden. Hakt man also nicht explizit an, dass auch die Website in den Ergebnissen berücksichtigt sein soll, dann bekommt man auch keine Ergebnisse von unserer Website.
Zudem sind wir auf diese Weise gut für die Zukunft aufgestellt: wenn ein gemeinsamer Index für den GBV zur Verfügung steht, können wir diesen über die Verteilte Suchtechnologie sehr einfach einbinden.
Umlaute und Trunkierung
Trunkierung und Umlaute stellten bislang ein Problem in TUBfind dar. Das Problem resultierte aus dem komplexen Zusammenspiel verschiedener Suchmaschinen-Technologien im Hintergrund. Für die einfache Suche in vufind ist Dismax zuständig, die erweiterte Suche wird aber über Lucene abgewickelt. Dismax unterstützt allerdings nicht die Suche mit Wildcards. Daher schaltet vufind trunkierte Anfragen auf Lucene um.
Dies zu vermeiden bringt allerdings keine Abhilfe. Die Suchanfrage wird bei Benutzung von Wildcards auf Seiten von Lucene keiner Analyse unterzogen und so unmodifiziert an den Index geschickt. Beim Indizieren werden die Felder jedoch analysiert und normalisiert, und dabei verschwinden die Umlaute in vielen Fällen. Wird nun eine Suchanfrage mit einem Umlaut an den Index geschickt und diese Suchanfrage wird nicht modifiziert, ist klar, dass nichts gefunden wird.
Wir dachten uns nun: wenn Lucene es nicht tut, dann tun wir es und unterziehen die Suchanfrage einer Umwandlung. Alle Umlaute werden in normale Zeichen umgewandelt und der gesamte Suchbegriff wird zu Kleinbuchstaben gemacht.
Da boolesche Operatoren nur in Großbuchstaben anerkannt werden (zumindest bei unserer Solr-Konfiguration), müssen die soeben umgewandelten Operatoren AND, OR und NOT wieder in Großbuchstaben umgeschaltet werden. Und damit das alles nur passiert, wenn es auch notwendig ist, fragen wir noch ab, ob die Suchanfrage Trunkierungszeichen enthält.
Eine weniger quick-and-dirty-Lösung ist in Aussicht, sobald Solr 1.5 rauskommt. Ab dieser Version soll Dismax auch mit der Trunkierung umgehen können. Ob damit auch die Problematik mit den Umlauten behoben ist, bleibt aber abzuwarten.
Suchbeispiele:
Kälte OR Wärme
Komplexitätstheo*
