Mittelfristig wird der OPAC seine Funktion als Einstiegspunkt für die Katalogrecherche verlieren

 ARCHITEKTUR UND PARAMETRISIERUNG VON PRIMO IM ÖSTERREICHISCHEN BIBLIOTHEKENVERBUND:

EIN üBERBLICK von Markus Knitel

Primo – das ist die neue Suchmaschine, welche seit mehreren Monaten im Österreichischen Bibliothekenverbund Anwendung findet. Primo ist, ebenso wie die im Verbund verwendete Bibliothekssoftware Aleph, ein Produkt der Firma Ex Libris, baut auf der Open Source Suchmaschine Lu- cene auf und nimmt für sich in Anspruch, optimales Relevance Ranking für bibliographische Metadaten zu bieten. Die Entscheidung für den Erwerb von Primo fiel nach Analyse durch eine Arbeitsgruppe der Vollversamm- lung des Verbundes (AG eDoc-Erweiterung/AG Primo-Implementierung) im Spätherbst 2008. Nach der Vertragsunterzeichnung, der Anschaffung der Hardware und den ersten Schulungen begann die Parametrisierung durch die Erstimplementierer im Sommer 2009. Bereits im Herbst konnte die Universität Innsbruck Primo als Suchalternative zur Verfügung stellen.

Anfang März 2010 folgte die Universität Wien mit einem Beta-Test und am Ende desselben Monats wurde die neue Suchoberfläche des Verbundes der Öffentlichkeit präsentiert. Dieser Artikel hat weniger die Suchmaschinen- technologie als solches, als vielmehr konkrete Hintergrundinformationen und Implementierungserfahrungen rund um die zentrale Primo-Instanz zum Thema: Wie sieht diese im Detail aus? Welche Datenflüsse gibt es und welche Gestaltungsmöglichkeiten hat man im Bereich des Webauftritts?

Primo

Das schnelle Auffinden von relevanten Dokumenten und der sofortige Zu- gang zu diesen, entweder via Internet oder über die Entlehnung, sind dem Hersteller zufolge die Kernfunktionalitäten dieses Produkts: „Find it, get it“.

Mit Primo stößt Ex Libris in den zukunftsträchtigen Markt des Information Retrieval für Bibliotheken vor und bietet eine von der Bibliothekssoftware Aleph unabhängige Suchoberfläche an. Während der Online Public Access Catalogue (OPAC) noch eng mit Aleph verbunden ist, wurde mit Primo eine Trennung von Erfassungs- und Präsentations-/Recherchesystem voll- zogen. Mittelfristig wird der OPAC seine Funktion als Einstiegspunkt für die Katalogrecherche verlieren.

Primo unterscheidet sich in mehrfacher Hinsicht mehr oder weniger stark von den bisherigen Suchwerkzeugen im Verbund. Zunächst und zu- allererst ist das Relevance Ranking, d.h. die Sortierung der Suchergebnisse nach Relevanz, zu nennen. Relevance Ranking hat keinen geringeren An- spruch, als genau das zu finden was der Benutzer, bewusst oder unbe- wusst, gesucht hat. Schon einmal hat ein Ranking dieser Art im bestehen- den OPAC Verwendung gefunden – wurde jedoch aus diversen Gründen von den meisten Anwendern alsbald wieder fallen gelassen.¹ Relevance Ranking soll die Bibliotheken wieder näher an den Benutzer heranführen, dessen Recherchegewohnheiten sich in den letzten Jahren angeblich radi- kal verändert haben. Der Primo zu Grunde liegende Such- und Rankingal- gorithmus ist, wie nicht anders zu erwarten, geheim, setzt allerdings auf der Open Source Suchmaschine Lucene² auf: „The Primo search engine is based on the Lucene search routines, which have been enhanced to take full advantage of the specific nature of library materials. The indexing and the search process take into account metadata standards, such as MARC, Dublin Core, and MAB; library-oriented classification, such as the various subject headings; and relationships between items, such as various expres- sions of a single work. As a result, Primo offers sophisticated searching and an extremely rapid response time.“³

Die augenscheinlichste Neuerung ist die facettierte Suche, die die Einschränkung einer Treffermenge auf unterschiedliche, interessierende Aspekte erlaubt: Darunter fallen so grundlegende Dinge wie Materialart (zeige mir alle Ergebnisse, die eine DVD oder CD Rom sind ...) aber auch die vielleicht weniger genutzte Autoren-Facette. Ein großes Problem in die- sem Zusammenhang ist die Tatsache, dass nicht alle Titel in jeder Facette erfasst werden. Nur ca. 40 % der Datensätze des Verbundkataloges sind z.B. mit Schlagwörtern beziehungsweise RSWK-Ketten versehen. Dement- sprechend problematisch ist eine Einschränkung des Suchergebnisses auf ein bestimmtes Thema – werden doch dadurch 60% des Bestandes völlig ignoriert.

Auf den ersten Blick weniger auffallend sind interne Verarbeitungs- schritte wie Deduplizierung bzw. die Gruppierung von Titeln durch FRBR⁴- Schlüssel. Die Deduplizierung führt identische Datensätze, die eventuell aus zwei unterschiedlichen Quellsystemen stammen, zu einem neuen, ver- schmolzenen Satz zusammen. Nur dieser neue Satz, der idealerweise die jeweils besten Kategorien aller Ursprungsstitel enthalten sollte, wird inde- xiert. Im Gegensatz dazu geht es bei der Zusammenführung gemäß den FRBR-Empfehlungen nicht um eine Verschmelzung sondern lediglich um eine übersichtliche Gruppierung von Titeln, die Ausdruck einer einzigen

geistigen Schöpfung sind. Lange Ergebnislisten mit vielen unterschied- lichen Auflagen ein und desselben Werkes sollen auf diesem Weg vermie- den werden. Ist die Bildung von FRBR Gruppen noch relativ einfach nach- zuvollziehen, basiert die Deduplizierung auf komplexen mathematischen Algorithmen, die nicht weiter Gegenstand dieser Abhandlung sind.

Neben diesen Kern-Funktionen wird Primo noch mit einer ganzen Reihe anderer Features ausgeliefert, die wohl teilweise unter dem Namen Web 2.0 firmieren. Dazu gehören das e-Shelf, eine Art Benutzerkonto, in dem man gefundene Titel ablegen und verwalten kann, die Automatisierung von Suchabfragen sowie das aktive Partizipieren an den Katalogdaten durch das Schreiben von Rezensionen bzw. Tagging. Es ist fraglich, ob dem Web 2.0 im Rahmen einer Retrieval-Software ein so hoher Stellenwert zukommt, wie es das Publikationsaufkommen um dieses Phänomen vermuten lassen könnte.⁵ Erste Erfahrungen zeigen, dass auf rund 4,5 Mio. Metadatensätze um die 250 Tags und Rezensionen kommen.⁶

Man könnte die Liste der neuen Funktionalitäten weiter fortführen.

Did-you-mean (das einerseits die Benutzereingabe korrigiert und ande- rerseits bei zu wenigen Treffern auch alternative Suchbegriffe empfiehlt) oder eingebaute Push-to-Dienste (also das Versenden von gefunden Titeln an Literaturverwaltungsprogramme wie Endnote und Refworks) könnten noch eingehender besprochen werden. Aber eine erschöpfende Darstel- lung all dessen was Primo vermag oder auch nicht vermag, sei zukünftigen Abhandlungen und der offiziellen Dokumentation überlassen.

Die konsortiale Primo-Architektur

Während üblicherweise jede Bibliothek eine eigene Primo-Instanz betreibt oder zumindest parametrisiert, wurden im OBV neue Wege beschritten:

Es gibt nur eine, zentrale Primo-Installation, die von mehreren Anwendern gleichzeitig genutzt wird. Ausschlaggebend für diese Entscheidung dürften, neben Synergien beim Betrieb des Systems, v.a. das bereits sehr homogene Datenmodell des Verbundes und, last but not least, wirtschaftliche Überle- gungen gewesen sein. Für den produktiven Betrieb wurden zwölf leistungs- starke Server angeschafft: zwei Frontend-Server, die die Suchanfragen entgegennehmen, zwei Back Office-Server auf denen die Parametrisierung vorgenommen wird, zwei Datenbank-Server, zwei File-Server sowie vier Such-Server, auf welche die eingetroffenen Suchanfragen verteilt werden.

Ausgestattet sind diese Server mit jeweils zwei Vierkern-Prozessoren und verfügen über 16 bis 36 GB RAM. Die Maschinen sind auf 205 Suchanfra-

gen pro Minute ausgelegt und ausfallsicher arrangiert. Diese Ausfallsicher- heit wird noch nicht in allen Punkten von Primo unterstützt.

Die Tatsache, dass es nur eine Primo-Instanz gibt, bringt Vor- und Nachteile mit sich. Zu den Vorteilen zählen zunächst die hohen Synergie- effekte bei der Parametrisierung und der Wartung des Systems (Hotfixes, Service Packs, Auswertung der Logdateien, Erstellung von Jobs etc.). In Anbetracht der mannigfaltigen Anpassungen, die seit der ersten Testpha- se vorgenommen wurden, ist kaum vorstellbar welche Redundanz von Arbeitsabläufen mehrere Instanzen mit sich gebracht hätten. Man kann getrost davon ausgehen, dass die Kommunikation unter den Teilnehmern durch die geteilte Instanz intensiviert wurde und gemeinsam an der Lösung bestimmter Probleme gearbeitet wird, die andernfalls vielleicht jeder für sich jeweils neu lösen müsste. Als Beispiel für die positiven Auswirkungen kann das sog. „Standardtemplate“ dienen (ein Template regelt die Verar- beitung der Daten in Primo – mehr dazu weiter unten): Durch die intensive Kooperation der Erstimplementierer konnten viele Fehler im ausgelieferten MAB-Template entdeckt und ausgemerzt werden. Daraus entstand be- sagtes Standard-Template, das von neu hinzukommenden Einrichtungen einfach kopiert werden kann. Sollten sich zu einem späteren Zeitpunkt Änderungen im Standard ergeben, können alle Änderungen auf Wunsch automatisch in die Kopien überspielt werden.

Bereits vor Beginn des Projekts war klar, dass eine gemeinsame Instanz auch anspruchsvolle Herausforderungen mit sich bringen wird. Wichtige Einstellungen können nur für alle nutzenden Bibliotheken gleichzeitig er- folgen, alle teilen sich systemrelevante Konfigurationsdateien und nicht zu- letzt haben alle Zugriff auf Parametrisierungen anderer Teilnehmer, was die Gefahr unabsichtlicher Änderungen in sich birgt. Kurz: eine sensible Um- gebung, die noch keine strikte Trennung der einzelnen Anwender erlaubt.

Um diese Mängel auf lange Sicht zu beheben, wurde mit Ex Libris schon bei Vertragsunterzeichnung ein Fahrplan für die Implementierung verbesserter Mandantenfähigkeit vereinbart: Spätestens im Jahr 2011 soll Primo so weit angepasst werden, dass die angeführten Nachteile nicht mehr zu Tage treten. Während die kommende Version 3.0 den Fokus auf die Integration des Aleph-OPAC zum Schwerpunkt hat⁷, wird Version 3.1 sich speziell mit dem Thema „Primo in konsortialer Umgebung“ beschäftigen.

Um Missverständnissen vorzubeugen: Eine einzige Primo-Instanz be- deutet nicht, dass man sich auf ein einheitliches Layout, bestimmte Facet- ten oder einen gemeinsamen Webauftritt zu einigen hätte. Jeder einzelne Primo-Teilnehmer kann beliebig viele Internet-Auftritte (sog. Views = Sich- ten) unterhalten, in welchen seine Daten auf jeweils andere Art präsentiert

werden können. Derzeit besitzt jede aktive Primo-Institution eine einzige View. Denkbar ist aber auch die Erstellung gemeinsamer, bibliotheksüber- greifender Views, z.B. einer Fachrichtung oder einer Region – ebenfalls ein Vorteil einer zentralen Instanz.

Datenquellen & Datenflüsse

Primo arbeitet mit OAI-PMH-kompatiblen XML Dateien. In künftigen Ver- sionen soll es möglich sein, jedes beliebige XML Format zu verarbeiten. Da XML inzwischen als De-facto-Standard im Bereich unterschiedlichster Me- tadaten gelten kann und immer mehr Informationsanbieter XML-basierte Schnittstellen einrichten, ist das sicherlich ein zukunftstaugliches Konzept.

Was mögliche Datenquellen für Primo betrifft, sind der Phantasie keine Grenzen gesetzt: Von Daten aus dem eigenen Katalogisierungssystem ange- fangen, bis hin zu selbst programmierten Repositorien oder elektronischen Archiven – alles kann in Primo eingespeist werden, so es nur im erwähnten OAI-PHM XML geliefert wird.

Da die am Verbund teilnehmenden Bibliotheken grundsätzlich in der gemeinsamen Datenbank ACC01 katalogisieren, stellt selbige auch die wichtigste Datenquelle dar. In Aleph steht der sog. Aleph Publishing Me- chanismus (APM) zur Verfügung, der für eine Umwandlung des Aleph-in- ternen Datenformates in XML sorgt. Fast alle Daten aller Views können so durch einen einzigen, einmal zu parametrisierenden Publishingvorgang aus ACC01 erzeugt werden. Theoretisch könnten die mit diesem Mechanis- mus hergestellten Daten sofort von Primo verarbeitet werden. Allerdings sind für die Realisierung gewisser Funktionalitäten weitere Anreicherungs- schritte vorzunehmen. Diese geschehen durch das „Primo Produktionsauf- bereitungssystem“, oder auch „Primo Data Preparation System“ (PPS), – eine von der OBVSG entwickelte Applikation, die a) verifiziert, welche zentralen Datensätze von welcher Institution genutzt werden und b) für die Integration von eDoc⁸ sorgt.

Der erste Schritt, die Feststellung der Nutzung durch die einzelnen In- stitutionen, ist unerlässlich und notwendig für die sogenannte Real Time Availability (RTA). RTA überprüft in Echtzeit die Verfügbarkeit gefundener Titel und zeigt diese übersichtlich und farblich hervorgehoben sofort in der Ergebnisliste an. Der Benutzer kann auf einen Blick erkennen, ob ein Titel verfügbar, eingeschränkt verfügbar oder gar nicht verfügbar ist. Für diese Funktionalität wird die lokale Systemnummer benötigt, mit welcher eine Anfrage an das Quellsystem⁹gesendet wird. Da in der zentralen Ver-

bunddatenbank aber lediglich die zentrale Systemnummer vorhanden ist, muss die lokale durch PPS eruiert und in den zentral gepublishten XML Satz geschrieben werden. Dabei entsteht für jede Institution ein eigener Datensatz.¹⁰

Die zweite Kernfunktion von PPS ist die der Verknüpfung von eDoc mit Primo. Die in eDoc abgelegten Abstracts, Inhaltsverzeichnisse oder Voll- texte werden nach textuellen Anteilen durchsucht und für eine spätere In- dexierung vorbereitet. Dafür muss aus den Objekten in eDoc wiederum Primo-kompatibles XML erstellt werden. Aber PPS macht noch mehr: Von einzelnen Primo-Institutionen bisher nicht genutzte abhängige Katalogi- sate, namentlich alle Artikel-Metadaten des IVScan-Projektes, werden in die Primo-Sichten dieser Institutionen geschickt und dort suchbar ge- macht, so selbige das übergeordnete Werk besitzen. Der Mehrwert beträgt nicht weniger als 650.000 Datensätze¹¹ für die Universitäten Innsbruck und Wien. 650.000 Datensätze, die andernfalls manuell in das jeweilige Lokalsystem kopiert werden hätten müssen.

Nur im übertragenen Sinn kann MetaLib als Datenquelle bezeichnet werden. Datensätze aus MetaLib durchlaufen keinen Normalisierungspro- zess, wie er noch für die Aleph-Daten beschrieben werden wird. Vielmehr stellt Primo einen neuen Sucheinstieg für die Recherche in MetaLib dar und wird auf lange Sicht das jetzige MetaLib-Frontend ersetzen. Der große Abbildung 1: Datenquellen

Vorteil dabei ist die einheitliche Suchoberfläche für die Recherche in Da- tenbanken und im lokalen Katalog. Berichten der Universität Innsbruck zu Folge, hat sich die Nutzung von MetaLib seit der Verwendung von Pri- mo stark erhöht, was angesichts der immensen Kosten für die einzelnen Datenbanken überaus begrüßenswert ist. Die Metadaten zu Datenbanken selbst – nicht die in ihnen gefundenen Treffer – können, wie jede andere Datenquelle auch, normalisiert und in Primo geladen werden. Gleiches gilt für die SFX Knowledge Base. Die aus dem OPAC bekannten SFX-Funktio- nalitäten bleiben auch in Primo erhalten.

Weitere Datenquellen sind denkbar und bereits projektiert: Die Öster- reichische Nationalbibliothek, die noch in diesem Jahr mit der Einführung von Primo beginnen möchte, wird aller Voraussicht nach DigiTool und die Bilddatenbank Gideon einspeisen, während die Universität Innsbruck schon jetzt lokale, nicht in der ACC01 nachgewiesene Daten über Primo suchbar macht.

Erhöhte Freiheit in der Wahl der Quellen ist jedoch nur die eine Seite der Medaille. Die andere Seite ist die daraus resultierende zeitweise Asyn- chronität zwischen Aleph und Primo. Es mussten daher Mittel und Wege gefunden werden, Primo möglichst zeitnah mit den Daten aus Aleph zu versorgen. Auch das erledigt PPS. Alle Änderungen in Aleph werden re- gistriert, am Abend (werktags) abgearbeitet und für Primo bereitgestellt.

Trotz dieses, gegenüber dem OPAC erhöhten Arbeitsaufwandes ist es ge- rade die Trennung von Erfassungs- und Recherchesystem, die die Inte- gration von heterogenem Material unterschiedlicher Herkunft in einem einzigen, übersichtlichen System erlaubt. Letztendlich war genau das eine der Hauptanforderungen, die von der AG eDoc-Erweiterung/AG Primo- Implementierung an eine neue Suchoberfläche gestellt wurden.¹²

Die Normalisierung

Welchem System auch immer die Daten entstammen und wie auch immer sie vorher ausgesehen haben – für die spätere Indexierung werden sie auf einen einheitlichen Standard gebracht: Primo normalized XML (PNX). Die teilweise durch PPS angereicherten XML Dateien werden von Primo abge- holt (harvesting) und nach ganz bestimmten Regeln, die durch den Biblio- thekar zu definieren sind, in PNX konvertiert. Ein solcher XML Satz ist in mehrere Sektionen unterteilt: control section, display section, link section, search section, frbr section, etc. Die Namen dieser Sektionen lassen bereits auf deren Inhalt und Funktion schließen: Während in der control section

wichtige systeminterne Angaben abgelegt sind, finden sich in der display section anzeigerelevante Felder wieder; alles was in der search section ge- speichert ist, wird für die Suche herangezogen und die frbr section beinhal- tet Schlüssel für die Bildung von FRBR Gruppen.

Abbildung 2: Primo-interner Datenfluss

Die Normalisierung erfolgt anhand von Normalisierungstemplates, die für jede Datenquelle eigens konfiguriert werden können und gestattet dem Nicht-Programmierkundigen über eine mehr oder weniger benutzerfreund- liche Webapplikation XPATH-Ausdrücke und XML-Transformationen zu formulieren.¹³ Jede MAB Kategorie, jeder Indikator und jedes Subfeld kann direkt angesprochen und einer Sektion im PNX zugeordnet werden.

Zahlreiche String-basierte Transformationen stehen zur Auswahl. Eine Zu- sammenführung unterschiedlicher Werte auf gemeinsame Codes lässt sich mittels Mapping-Tabellen realisieren. Wer möchte kann auf diesem Weg umfangreiche, nachträgliche Katalogbereinigungen durchführen.

Der Facettierung kam im Laufe der Parametrisierung erhöhte Aufmerk- samkeit zu. Auch sie wird größtenteils über die Normalisierung gesteuert.

Neben den Standard-Facetten (Erscheinungszeitraum, Autor, Thema, be- sitzende Bibliotheken etc.) stehen jedem Teilnehmer weitere 50 Facetten zur freien Verwendung zur Verfügung. Von allen Einrichtungen werden da-

von derzeit zwei für die Facetten „Basisklassifikation“ und „Regensburger Verbundklassifikation“ genutzt. Die beiden bestehenden Facetten „Genre“

und „Materialtyp“ wurden zu „Medium“ und „Form“ umgearbeitet, die grob als Facetten für das Trägermaterial und die Art der Publikation be- trachtet werden können. Unter „Medium“ fallen Kategorien wie DVD/CD, Mikrofilm oder Tonmaterial, während unter die Facette „Form“ Kategorien wie Festschrift oder Aufsatzsammlung subsumiert werden. Für viele Wer- te beider Facetten werden sowohl Sach- als auch Formalerschließungse- lemente herangezogen. Es ist davon auszugehen, dass weitere Facettie- rungsprojekte dieser Art die Katalogisierungsgewohnheiten im Verbund nachhaltig beeinflussen werden – gewinnen doch die für den Benutzer un- sichtbaren MAB Kategorien ganz entscheidend an Bedeutung (050, 051, 052 etc.). Entgegen anders lautender Gerüchte macht eine Suchmaschine wie Primo kontrollierte Metadaten keinesfalls obsolet.

Nach der Normalisierung folgt die „Enrichment“-Phase. Wie der Name schon vermuten lässt, werden die erstellten PNX-Sätze über eine JAVA- Schnittstelle angereichert. Diese Anreicherungen können/müssen vom Kunden selbst programmiert werden. Bei allen produktiven Primo-Insti- tutionen finden derzeit zwei, wiederum von der OBVSG entwickelte, Pro- gramme Verwendung: 1) Ein Programm, welches textuellen Anteil aus Ab- stracts, die in eDoc abgelegt sind, extrahiert und direkt in die PNX-Sektion

„display“ schreibt. Dem Benutzer bleibt somit ein weiterer Klick auf einen Abstract-Link erspart, denn dieses wird direkt in der Detailansicht eines Titels angezeigt. 2) Das zweite und wichtigere Programm erlaubt die Inde- xierung aller durch PPS für die Volltextindexierung vorbereiteten XML-Sätze Abbildung 3: Eine von einem Dutzend Normalisierungsregeln für die MAB Kategorie 655.

(s.o.). Derzeit sind das an die 300.000 Objekte. Die Entwicklung dieser Plugins kostete nicht unerheblich Arbeitszeit; Programmmängel und Bugs verzögerten immer wieder ein Vorankommen. Mehr als einmal musste der gesamte Arbeitsablauf überdacht und abgeändert werden. Trotz aller Wid- rigkeiten konnte aber schlussendlich eine Applikation geschaffen werden, die weltweit vermutlich ihresgleichen sucht. Dem intensiven Kontakt mit dem Ex Libris Entwicklerteam und Produktmanagement nach zu schließen, dürfte noch keine andere Primo-Installation, und derer gibt es inzwischen mehr als 200, über eine derartige Menge von Volltextindexaten verfügen.

Die eigene View

Nach diesem skizzenhaften Blick hinter die Bühne darf die Bühne selbst, die Benutzeroberfläche (Frontend) nicht unerwähnt bleiben. Das Konzept von Primo sieht vor, dass jede Institution beliebig viele Views unterhalten kann. Facetten, durchsuchte Datenbestände, Tabs sowie das gesamte Lay- out können für jede View getrennt gestaltet werden.

Abbildung 4: Eine Institution kann mehrere Views unterhalten. In jeder View können unterschiedliche Ausschnitte der Datenbank (Scopes) in unterschiedlichen Reitern angeboten werden.

Der Aufwand für eine selbständige, ansehnliche Gestaltung des Fron- tends ist hoch, weshalb jede Institution derzeit über nicht mehr als eine View verfügt. Dabei wird es auf absehbare Zeit wohl auch bleiben. Die Nachteile der konsortialen Primo-Installation bzw. die Tatsache, dass Ex Libris offen- bar bisher weniger Programmieraufwand auf diese Art der Architektur ver- wendet hat, hat sich am stärksten im Bereich der Frontend-Parametrisie- rung bemerkbar gemacht. Die einzelnen Sichten wurden inzwischen teilweise sign ifikant verändert und den eigenen Bedürfnissen angepasst. Während die Sicht der Universität Innsbruck noch weitgehend dem Auslieferungszustand entspricht, wurden in der Sicht der Universität Wien und der des Verbundes vielfältige Änderungen in Design und Layout vorgenommen, gewisse Bereiche sind weggefallen und neue hinzugekommen. So ist in der Verbundsicht z.B.

kein Tagging möglich. Rezensionen können ebenfalls nicht verfasst werden.

Ähnlich wie bei den Normalisierungsregeln gibt es auch für die Gestal- tung des Frontends eine benutzerfreundliche Oberfläche, mit deren Hilfe man die einzelnen Frontendelemente den eigenen Vorstellungen entspre- chend anordnen kann. Neben den wichtigen Bereichen¹⁴ Suchbox, Facet- ten, Login und Menü können noch beliebig viele andere, selbst definierte HTML- oder JSP-Seiten in das Layout integriert werden. Wer den Schritt wagt und sich eingehend mit dem Webdesign des eigenen Auftritts aus- einandersetzen möchte, hat viele Möglichkeiten der Anpassung. In der Sicht des Verbundes verdienen folgende Features besondere Beachtung:

Erstmals werden die Metadaten des Verbundkataloges mit Wikipedia verknüpft. Dies geschieht einerseits über die PND-Nummer eines Autors und andererseits über die ISBN eines Titels. Wird zu einer PND-Nummer ein Eintrag gefunden¹⁵, werden die ersten Zeilen des Artikels direkt in der Vollanzeige eingeblendet. Zum Weiterlesen wird auf Wikipedia verlinkt.

Gegenüber vielen anderen Arten der Wikipedia-Integration in Bibliotheks- katalogen entstehen auf diesem Weg keine broken links.¹⁶ Mit Hilfe der ISBN wir zusätzlich überprüft, ob der gefundene Titel eventuell in einem Wikipedia-Artikel zitiert wird. Ebenfalls mit der ISBN/ISSN arbeitet die Google-Buchvorschau, welche direkt in der Vollanzeige eines Titels geöff- net werden kann – wiederum nur, wenn Google tatsächlich eine Vorschau anbietet. Weiters wird, wie schon aus dem OPAC gewohnt, ein eBooks on Demand¹⁷-Button eingeblendet, so das Werk älter als 70 Jahre ist und min- destens eine besitzende Bibliothek am EOD-Projekt teilnimmt. Jeder Titel kann darüber hinaus an eine ganze Reihe von Social Bookmarking Dien- sten gesendet werden und außerdem steht die Suche in der Verbundsuch- maschine als Toolbar-Add-on zur Verfügung. Zahlreiche weitere Pläne lie- gen bereits in den Schubladen und scheitern derzeit nur am Zeitaufwand.

Was hier vorgestellt wurde, markiert nur den Anfang einer wohl noch länger dauernden Auseinandersetzung mit Primo und Suchmaschinen- technologie insgesamt, hat aber hoffentlich dazu beigetragen Architektur, Datenflüsse und Parametrisierung der zentralen Primo-Instanz in groben Zügen besser zu verstehen. Viele angerissene Themen würden eine einge- hendere Behandlung verdienen. Im laufenden Jahr werden mindestens fünf Einrichtungen des OBV der konsortialen Primo-Installation beitreten, mit der Parametrisierung beginnen und u.U. ihre Primo-Sicht der Öffentlichkeit zugänglich machen. Auch wenn die bisher erzielten Ergebnisse zufrieden- stellend sind, gibt es viele offene Fragen und noch mehr anzugehende Pro- jekte. Die Beschäftigung mit der Normalisierung bzw. der Programmierung der Benutzeroberfläche hat eine intensive Auseinandersetzung mit dem Ranking- und Suchalgorithmus bis jetzt nicht zugelassen: Did-you-mean, Feldgewichtung und Synonymsuche müssen eingehender untersucht, ver- standen und ggf. verbessert werden.

Es ist wohl kaum übertrieben zu sagen, dass die Einführung von Primo ein ähnlich großes Projekt ist, wie es einst die Umstellung der Kata- logisierung auf Aleph war. Dementsprechend lange wird es dauern, bis alle Tiefen und Untiefen dieses Programms ausgelotet sind.

Mag. Markus Knitel Österreichische Bibliothekenverbund und Service GmbH (OBVSG)

Brünnlbadgasse 17/2a, A-1090 Wien; markus.knitel@obvsg.at

* Ich danke Viktor Babitchev, Wolfgang Hamedinger, Ulrike Krabo, Ul- rich Leodolter und Otto Oberhauser für die kritische Durchsicht.

1 Siehe dazu: Oberhauser, Otto; Labner, Josef (2003). Relevance Ranking in Online-Katalogen: Informationsstand und Perspektiven. Mitteilungen der Vereinigung Österreichischer Bibliothekarinnen & Bibliothekare 3,4/2003, 49–63.

2 http://lucene.apache.org/java/docs (aufgerufen am 18.04.2010).

3 Ex Libris (2009). Primo White Paper, URL: http://www.exlibrisgroup.

com/files/Products/Primo/PrimoSearchWhitePaperDec2009.pdf, 7 (auf- gerufen am 18.04.2010).

4 http://www.ifla.org/en/publications/functional-requirements-for-bib- liographic-records (aufgerufen am 19.04.2010).

5 Kritisch: Tam, Winnie; Cox, Andrew M.; Bussey, Andy. Student user preferences for features of next-generation OPACs. Program: Electronic library and information systems 4/2009, 349–374.

6 Stand: April 2010. 1,5 Mio. Sätze stehen seit November 2009 zur Verfügung,

die restlichen 3 Mio. seit Anfang März 2010. Es handelt sich um die Da- ten der produktiven Primo-Installationen Universität Innsbruck und Wien – zwei große Benutzerbibliotheken mit wohl überwiegend junger Klien tel – jener Benutzergruppe also, der man eigentlich eine große Affinität zu allen Neuerungen des WWW nachsagt. Eine Vielzahl der Rezensionen und Tags wird offenbar durch nur wenige, sehr engagierte Benutzer verfasst.

7 Dabei geht es um die Integration der gesamten Entlehn- und Konto- funktionalität in Primo.

8 eDoc ist das Kataloganreicherungsverfahren des OBV. Näheres zu eDoc:

http://www.obvsg.at/services/edoc/ (aufgerufen am 18.04.2010).

9 RTA steht nur für Datensätze zur Verfügung, die aus Aleph kommen.

10 Dies führt klarerweise zu Redundanzen. Ein und derselbe Satz in ACC01, der von mehreren Institutionen genutzt wird, muss mehrfach angepasst und erstellt werden. Statt der 7,5 Mio. Sätze der zentralen ACC01-Da- tenbank wird Primo mit derzeit rund 12 Mio. Sätzen versorgt: ca. 3 für die Universität Wien, 1,5 für die Universität Innsbruck und 7,5 für die zentrale Sicht.

11 Stand: Februar 2010.

12 In einem Bericht der Arbeitsgruppe an die Vollversammlung des Verbundes vom 03.09.2008 heißt es: „Bei allen Überlegungen muss von den Erwar- tungen des Durchschnittsbenützers ausgegangen werden. Diskussionen über die Vorteile vieler getrennter, auf hohe Effizienz optimierter Suchein- stiege (deren Effizienz oft gar nicht wirklich erwiesen ist) sind inzwischen akademischer Natur. Google und Konsorten haben das Suchverhalten komplett verändert; dem müssen sich die Bibliotheken (und Universi- täten) anpassen, damit ihr Angebot gerne und nicht nur gezwungener- massen (sic!) genutzt wird. Dazu muss es möglich werden, an einer Stelle möglichst umfassend und einfach zu suchen (und zu finden). Zusätzliche Suchmöglichkeiten an anderer Stelle werden trotz umfangreicheren In- halts nur von einer Minderheit genutzt.“ (Hervorhebung im Original).

13 XPATH ist eine Sprache, die den Zugriff auf Elemente und Strings einer XML Datei erlaubt.

14 Mit „Bereich“ ist jeweils ein eigener HTML div-Container gemeint.

15 Das Matching zwischen PND Nummer und Wikipedia Artikel erledigt ein Tool des GBV: https://www.gbv.de/wikis/cls/SeeAlso#PND2Wikipedia (aufgerufen am 19.04.2010).

16 Eine häufige Variante der Integration von Wikipedia ist die ungeprüfte Übergabe des Inhaltes des Autorenfeldes an Wikipedia. Die Trefferquote ist dementsprechend gering und broken links dementsprechend häufig.

17 http://books2ebooks.eu (aufgerufen am 19.04.2010).