Archive for December, 2011

Digital Library Framework: Installation und Konfiguration, Teil 2

Backend Plugins des DLF

Im nächsten Schritt müssen wir die Backend Plugins, die das DLF mitbringt, installieren. Dafür wird zuallererst im Typo3-Seitenbaum unserer Instanz ein neues Element vom Typ “Folder” (in früheren Typo3-Versionen “Sysfolder” genannt) angelegt. Hier hat der Folder zweckmäßigerweise den Namen “DLF configurations” erhalten:

Der “Folder” für die Backend Plugins

Nach einem Klick auf “Create new record” sehen wir die verfügbaren Backend Plugins des DLF: “Documents”, “Structures”, “Metadata”, “Collections” und “Libraries”, alle unter “Goobi.Presentation” zu finden.

Die Backend Plugins stehen als Seiteninhaltselemente zur Verfügung

Zunächst benötigen wir nur zwei der angebotenen Seiteninhaltselemente: “Structures” und “Metadata”. Wenn wir mit unserer Konfiguration wie hier beschrieben fertig sind, wird unser Folder “DLF configurations” folgendermaßen aussehen:

So sieht die fertige Konfiguration aus, mit der wir später indizieren können

Nun müssen wir zunächst für jeden Strukturtyp, der in unseren Digitalisaten vorkommen kann, jeweils ein Inhaltselement vom Typ “Structures” anlegen. Dazu ist die Kenntnis dessen notwendig, welche Strukturtypen in unserer jeweiligen Institution vorkommen können. Wurde die Erfassung der bibliographischen Strukturdaten beispielsweise mit Hilfe von Goobi.Production vorgenommen, so existiert dafür ein sogenannter Regelsatz (ruleset). In diesem ist detailliert beschrieben, welche Strukturtypen und welche bibliographischen Metadaten in den Digitalisaten erlaubt sind, die mit Goobi.Production bearbeitet werden.

Einen wichtigen Anhaltspunkt dafür, was an Strukturtypen überhaupt vorkommen kann, liefert aber auch die Strukturdatenliste des DFG-Viewers. Weil Digitalisierungsprojekte in deutschen Bibliotheken häufig (wenn nicht sogar stets) von der Deutschen Forschungsgemeinschaft (DFG) unterstützt werden, wird man meist von einer Kompatibilität zu den vom DFG-Viewer unterstützten Strukturtypen ausgehen können.

Sicherlich wird es etliche weiterere Strukturtypen als nur die Monografie geben, aber aus Gründen der Übersichtlichkeit beschränken wir uns an dieser Stelle auf nur diese. Das Inhaltselement vom Typ “Structures” ist einfach zu konfigurieren; vorerst werden nur die Felder “Display Label” und “Index Name” ausgefüllt. Ersteres ist die Bezeichnung dieses Strukturtyps, wie sie später im Frontend für den Benutzer sichtbar wird; zweiteres der Bezeichner innerhalb der METS-Struktur, der als XPath ausgedrückt folgendermaßen lautete:

/mets:structMap[@TYPE="LOGICAL"]/mets:div[@TYPE]

Hier muß aber nur der Bezeichner angegeben werden und nicht der komplette XPath.

Konfiguration von “Structures”

Weiter geht es mit der Konfiguration der Inhaltselemente vom Typ “Metadata”. Hier benötigen wir für jedes Metadatum, das indiziert und auch später im Frontend angezeigt werden soll, ein eigenes Inhaltselement. Siehe oben – zur Veranschaulichung habe ich jeweils eines für die bibliographischen Metadaten “Titel”, “Autor”, “Erscheinungsjahr”, “Erscheinungsort”, “Kategorie” und “Signatur” angelegt.

Hier werden die Felder “Display Label” und “Index Name” analog zum Inhaltselement vom Typ “Structures” angelegt. Außerdem sollte unter “Encoding” stets das richtige Format ausgewählt werden – in unserem Fall “MODS” – weil die Extension bei der Indexierung prüft, welches Format die deskriptiven Metadaten in der METS-Datei haben und dann nur diejenigen Metadaten-Konfigurationen darauf anwendet, die genau diese oder keine konkrete Kodierung angegeben haben. Somit können also mehrere Metadatenformate innerhalb derselben METS-Dateien verwendet werden, selbst wenn dabei manche “Index Names” mehrfach vorkommen.

Außerdem können hier XPaths für die Metadaten festgelegt werden. Doch vorsicht: Dadurch werden die oberhalb davon festgelegten Einstellungen überschrieben! Im Beispiel fände – bei leergelassenem XPath – im Hintergrund eine sogenannte Formatklasse mit der Kodierung “MODS” und deren Elementen “title” und “nonSort” den korrekten Wert für den Titel. Der hier zusätzlich angegebene XPath überschreibt dies jedoch, so daß tatsächlich der Titel ohne “nonSort” zum Zuge käme.

Konfiguration von “Metadata”

Vergleichshalber hier die XPaths, die ich für die in diesem Setup verwendeten “Metadata” konfiguriert habe:

Display Label Index Name XPath
Titel title /mods:titleInfo/mods:title
Autor author /mods:name[@type='personal'][mods:role/mods:roleTerm='aut'[@authority='marcrelator'][@type='code']]
Erscheinungsjahr year /mods:originInfo[1]/mods:dateIssued[@encoding='w3cdtf'][@keyDate='yes']
Erscheinungsort place /mods:originInfo[1]/mods:place/mods:placeTerm[@type='text']
Kategorie type /mods:classification[@authority='ZVDD']
Signatur shelfmarksource /mods:location/mods:shelfLocator

Indizieren im Backend

Damit sind wir bereit dafür, eine erste METS-Datei zu indizieren. Das Indizieren kann auf zwei verschiedene Arten geschehen: Entweder im Backend “von Hand”, oder skriptgesteuert automatisiert.

Das System kann in beiden Fällen für jede METS-Datei sowohl eine http-URL als auch eine file-URL als auch einen absoluten Pfad im Dateisystem verarbeiten. Demzufolge wären folgende drei Eingaben gleichermaßen möglich:

Außerdem muß unbedingt darauf geachtet werden, daß die zu indizierende METS-Datei auch tatsächlich von einem der Strukturtypen ist, die wir bereits als Inhaltselement vom Typ “Structures” angelegt haben. Im hier beschriebenen Fall muß also der Strukturtyp, der in der METS-Datei unter /mets:structMap[@TYPE="LOGICAL"]/mets:div[@TYPE] steht, “monograph” sein. Anderenfalls bricht das Indizieren mit einer Fehlermeldung ab!

Wir sehen uns zunächst die erstere Methode an. Seit der Installation des DLF gibt es ein neues Modul in der Werkzeugleiste links im Typo3-Backend: “Digital Library Framework / Indexing”. Ein Klick darauf bringt uns zu folgendem Dialog, in dem wir die URL einer METS-Datei eingeben können. Möglicherweise bekommen wir im ersten Moment auch eine Meldung “You are not allowed to access this page or have not selected a page, yet” zu Gesicht. Das soll uns aber nicht schrecken, ein Klick auf den Folder “DLF configurations” beseitigt diese Meldung.

Das Indizieren im Backend …

Nach der Eingabe der URL im Feld “METS-Datei” und dem Klick auf “Start indexing” teilt das System uns – wenn alles glattging – mit, daß der Vorgang erfolgreich war und daß zusätzlich ein neues Inhaltselement vom Typ “Library” angelegt wurde.

… war erfolgreich!

Ein Klick auf das Modul “Web / List” zeigt uns nun, daß der Vorgang tatsächlich erfolgreich war: Es ist ein neues Inhaltselement vom Typ “Documents” entstanden. Jedes weitere Digitalisat wird ebenfalls durch ein solches repräsentiert werden. Das Digitalisat ist nun in den DLF-Datenbanktabellen bekannt und ebenso im Solr-Index, wovon wir uns wiederum durch folgende Abfrage überzeugen können: http://solrhost:8080/solr/dlfCore0/select?q=*:*&indent=on&wt=php.

Ein erstes Dokument ist im DLF!

Hier geht es zum dritten Teil, in dem wir skriptgesteuert indizieren und dieses ein wenig erweitern und automatisieren werden.

Digital Library Framework: Installation und Konfiguration, Teil 1

Was ist das Digital Library Framework (DLF)?

Das DLF, auch bekannt als Goobi.Presentation, ist eine Software für die Darstellung der Bestände digitalisierter Sammlungen von Bibliotheken im World Wide Web und wurde von der Sächsischen Landes-und Universitätsbibliothek Dresden (SLUB) entwickelt. Es ist Teil eines größeren Softwareprojektes, das den Namen “Goobi Community Edition” trägt und das vor allem auch Software enthält, die es bei Digitalisierungsvorgängen in Bibliotheken ermöglicht, auf komfortable Weise die zu Digitalisaten gehörigen Strukturdaten und bibliographischen Daten im METS-Format zu erfassen und mit den gescannten Seiten des jeweiligen Werkes zu verknüpfen.

Der Kern des DLF ist eine Typo3-Extension. Da eine Reihe der bedeutendsten Bibliotheken auf deutschem Boden das WebCMS Typo3 als Basissystem für ihre Webauftritte einsetzen und das DLF wie auch die anderen Teile des Goobi-Projektes unter der GNU General Public License veröffentlicht wurden, ist das DLF mittlerweile in stetiger Verbreitung begriffen. Ich selber führe derzeit eine Installation und Anpassung des DLF für die Staatsbibliothek zu Berlin (SBB) durch.

Bei der Installation und Konfiguration des DLF gibt es natürlich – wie bei allen komplexen Webanwendungen, bei denen zahlreiche Komponenten zusammenwirken – einige kleine Besonderheiten zu beachten. Dieses Tutorial möge nun dazu dienen, anderen Interessenten den Einstieg etwas zu erleichtern.

Zum Download des DLF

Voraussetzungen für die Installation

Eine saubere Installation einer Typo3-Instanz auf einem gängigen Linux-System mit Apache und PHP ist natürlich Voraussetzung, ebenso die prinzipielle Kenntnis dessen, wie Typo3-Extensions installiert werden. Ich bitte um Verständnis darum, daß ich darauf hier nicht weiter eingehe. Beachtet werden muß jedoch, daß PHP mindestens die Version 5.3.0 hat und Typo3 mindestens die Version 4.3.0, ansonsten läßt sich DLF nicht installieren:

Die Versionsnummern stimmen nicht

Ich habe für das System der SBB außerdem noch die Typo3-Extensions “Typo3 Quixplorer (t3quixplorer)”, “Developer Log (devlog)” sowie das von DLF vorgeschlagene “RealURL: speaking paths for TYPO3 (realurl)” installiert.

Außerdem benötigt das DLF als Suchmaschine eine Solr-Instanz, die von dem Host aus, auf dem unsere Typo3-Instanz zu Hause ist, per http erreichbar sein muß. Das kann natürlich auch derselbe Host sein, aber wir müssen davon ausgehen, daß bei fortschreitender Massendigitalisierung unsere Datenmengen und damit auch die Größe unserer Suchindizes beträchtlich anwachsen werden. Zwar reden wir in dem Zusammenhang noch nicht von Big Data-Technologien, doch im Sinne besserer Skalierbarkeit sollten wir Solr lieber einen eigenen Host spendieren. Auch über das prinzipielle Tomcat- und Solr-Setup möchte ich an dieser Stelle keine weiteren Worte verlieren.

Konfiguration von Solr

Das DLF benötigt einen Solr mit Multicore-Setup. Der Grund dafür ist der, daß die SLUB Präsentationen anderer sächsischer Bibliotheken in einer gemeinsamen Typo3-Instanz hostet und daher mandantenfähig sein muß. Im Moment des Schreibens dieser Zeilen ist die stabile DLF-Version 1.0.4 und eine entsprechende Solr-Konfiguration noch nicht Teil davon. Deshalb steht hier eine Beispielkonfiguration zum Download bereit.

Dazu noch ein paar Hinweise. Zunächst muß der in der Beispielkonfiguration beiliegende Patch web.xml.patch ausgeführt werden. Angenommen, das Installationsverzeichnis von Tomcat sei /usr/local/tomcat und solr.war sei dementsprechend in /usr/local/tomcat/webapps installiert worden, dann bezöge sich der Patch auf /usr/local/tomcat/webapps/solr/WEB-INF/web.xml und müßte folgendermaßen angewendet werden:

cp web.xml.patch /usr/local/tomcat/webapps/solr/WEB-INF
cd /usr/local/tomcat/webapps/solr/WEB-INF
patch <web.xml.patch

Weiterhin angenommen, die Tomcat-Konfiguration, die diesen unsere Solr-Instanz finden läßt, sei dann in /usr/local/tomcat/conf/Catalina/localhost/solr.xml abgelegt und habe etwa folgenden Inhalt:

<?xml version="1.0" encoding="UTF-8"?>
<Context docBase="/usr/local/apache-solr-1.4.1/dist/apache-solr-1.4.1.war" debug="0" crossContext="true">
        <Environment name="solr/home" type="java.lang.String" value="/storage/digital-library-framework/solr" override="true" />
</Context>

Dann müssen die in der Beispielkonfiguration beiliegende Datei solr.xml und das Verzeichnis conf nach solr/home kopiert werden:

cp solr.xml /storage/digital-library-framework/solr
cp -r conf /storage/digital-library-framework/solr

Und schließlich müssen, so der Tomcat unter dem user tomcat läuft, noch zwei roles für diesen angelegt werden:

cd /usr/local/tomcat/conf
vi tomcat-users.xml
    <role rolename="dlfSolrUpdate"/>
    <role rolename="dlfSolrAdmin"/>
    <user username="tomcat" password="password" roles="manager,tomcat,dlfSolrUpdate,dlfSolrAdmin"/>

Nach einem Tomcat-Neustart sollte jetzt unter der URL http://solrhost:8080/solr/dlfCore0/admin/ der Solr Admin zu erreichen und dabei paßwortgeschützt sein (“http://solrhost” ist natürlich nur symbolisch gemeint). Eine Abfrage an Solr sollte jetzt ebenfalls ein, wenn auch leeres, Ergebnis liefern: http://solrhost:8080/solr/dlfCore0/select?q=*:*&indent=on&wt=php.

Grundkonfiguration von DLF

Zurück ins Typo3-Backend. Nun muß dem DLF gesagt werden, wo es seinen Solr findet. Das geschieht unter “Admin Tools / Extension Manager / Frontend” und dann einem Klick auf “Goobi.Presentation”.

Im Extension Manager

In der folgenden Ansicht wird unter “Configuration: / Category” der Eintrag “SOLR (6)” ausgewählt und anschließend werden die Eingabefelder “Solr Server Host” bis “Solr Server Password” ausgefüllt. Die Werte für “Solr Server User” und “Solr Server Password” sind eben jene, die wir oben in tomcat-users.xml vergeben hatten.

Die Verbindung zu Solr steht

Sofern Solr korrekt konfiguriert wurde und auch von unserer Typo3-Instanz aus per http zu erreichen ist, bekommen wir nun den grünen Kasten mit der Aufschrift “Connection established!” zu sehen.

Weiter geht es im zweiten Teil mit der Einrichtung der Backend-Plugins des DLF, mit denen wir METS-Metadatendateien indizieren wollen, um diese für unser System verfügbar zu machen.