Möglichkeiten zur Nutzung optionaler Komponenten
Die Zusammenarbeit mit anderen DocPortal-Installationen
Das MyCoRe-System ist so konzipiert, dass hinsichtlich der Metadaten gleichartige Installationen miteinander arbeiten und von einer gemeinsamen Oberfläche (Frontend) abgefragt werden können. Hierzu müssen die Remote-Instanzen definiert werden. Auch die eigene Installation kann über diesen Weg abgefragt werden. Das ist in der Beispielinstallation auch schon vorgesehen. Die Remote-Suche nutzt dabei die WebServices Komponenten von MyCoRe. Das installiert DocPortal-Sample gestattet grundsätzlich auch eine Suche über den WebService-Dienst gegen den localhost.
Die Konfiguration ist denkbar einfach, es sind alle Hosts, für die eine Remote-Abfrage angeboten werden soll, in die Datei $DOCPORTAL_HOME/config/hosts.xml einzutragen. Nach einem ant webapps sind die Hosts dann mittels der Suchmasken durchsuchbar.
<?xml version="1.0" encoding="UTF-8"?>
<hosts xmlns="http://www.mycore.org/">
<host alias="remote"
url=" <a title="" href="http://localhost:8291/">http://localhost:8291/</a></code><code>"
class="org.mycore.services.fieldquery.MCRQueryClientWebService"
access="webservice"
servicepath="services/MCRWebService"
staticpath="receive/">
<label xml:lang="de">Lokal via WebService</label>
<label xml:lang="en">Local via WebService</label>
</host>
<host alias="Demo"
url="http://www.mycore.de:8291/"
class="org.mycore.services.fieldquery.MCRQueryClientWebService"
access="webservice"
servicepath="services/MCRWebService"
staticpath="receive/">
<label xml:lang="de">Demo-Version</label>
<label xml:lang="en">Demo Version</label>
</host>
</hosts>
Von den Entwicklern des MyCoRe-Projektes wird exemplarisch eine DocPortal-Installation bereitgehalten. Diese ist im Konfigurationsfile hosts.xml notiert und sollten in der Regel verfügbar sein. Die Attribute für einen Host bedeuten im Einzelnen:
- alias – der im MyCoRe-System zu verwendende Alias für einen externen Host
- url – die Basis-URL eines externen Hosts
- class – die MyCoRe-Java-Klasse, die den externen Zugriff realisiert
- access – einen Typ-String für die Zugriffsform
- servicepath – die URL-Erweiterung als Pfad auf dem externen Systembibliotheken
- staticpath – die URL-Erweiterung für die Darstellung der statischen URL des Objektes auf dem entfernten Rechner
| Alias | URL | Port | Standort |
|---|---|---|---|
| remote | http://localhost:8291/ | 8291 | lokale Installation |
| demo | http://www.mycore.de:8291/ | 8291 | Demo-Version |
Tabelle 7.1: Feste Test-Instanzen für das MyCoRe-Beispiel
Die Integration des Bildbetrachter-Modules
MyCoRe bietet einen komfortablen Bildbetrachter, um Dateien verschiedener Formate anzuzeigen. Dazu wird die Komponente iview2 aus dem MyCoRe-Kern verwendet. Diese Komponente ist im DocPortal standardmässig integriert. Um sie zu deaktivieren muss in mycore.properties.private das Property MCR.Components.Exclude um diese Komponente erweitert werden.
Eine Übersicht der verfügbaren Kommandos finden Sie im Abschnitt Kommandos zur Arbeit mit dem ImageViewer.
Der Bildbetrachter ist in DocPortal bereits in die Detailansicht des MyCoRe-Objekttyps document integriert. Ist der Bildbetrachter deaktiviert oder sind keine Kacheln vorhanden, wird dieser einfach nicht dargestellt. Für die Darstellung in der document.xsl sind die folgenden Code-Zeilen verantwortlich:
<!-- MCR-IView ..start --> <xsl:call-template name="derivateView"> <xsl:with-param name="derivateID" select="@xlink:href" /> </xsl:call-template> <!-- MCR - IView ..end -->
Das Repository als OAI-Data-Provider
Im folgenden soll die Konfiguration der OAI-Schnittstelle beschrieben werden. Zum Austausch von Metadaten unterstützt MyCoRe das Open Archives Initiative Protocol for Metadata Harvesting (OAI-PMH). Die Beschreibung des Standards finden Sie unter http://www.openarchives.org/pmh/. Machen Sie sich zunächst grob mit diesem Standard vertraut. In die Implementierung sind auch Anforderungen aus dem DINI-Zertifikat 2010 (http://www.dini.de/dini-zertifikat/) eingeflossen.
Die OAI-Schnittstelle ist auch im DocPortal bereits integriert und kann dort getestet werden:
Mapping der Klassifikationen
Für einen DINI-konformen Betrieb der OAI-Schnittstelle müssen verschiedene Sets unterstützt werden. Sets werden im OAI-PMH Standard verwendet, um Dokumente zu gruppieren. Sie ermöglichen selektives Harvesting und entsprechen konzeptionell den Klassifikationen in MyCoRe. Deshalb wurden zunächst Klassifikationen für die Sets erstellt, die für das DINI-Zertifikat zu implementieren sind. Sie stehen im DocPortal als class_ddc_sg.xml, class_diniPublType.xml und class_diniVersion.xml zur Verfügung und müssen in die eigene Anwendung übernommen werden.
Sollen Dokumente im XmetaDissPlus-Format ausgeliefert werden, sind weitere Klassifikationen zu verwenden: class_dctermsDCMIType.xml und class_XMetaDissPlusThesisLevel.xml
Im einfachsten Fall lassen sich diese Klassifikationen direkt in einem MyCoRe-Datenmodell verwenden. Allerdings werden die meisten MyCoRe-Anwendungen eigene Klassifikationen besitzen, z.B eine detaillierte DDC oder detailliertere Klassifikation für Dokumententypen. Für diese Fälle wurde in MyCoRe ein Mapping-Verfahren implementiert.
Das Datenmodell muss dafür zunächst um ein Datenfeld mappings/mapping ergänzt werden. Dieses Feld wird dann beim Einfügen oder Aktualisieren der Dokumente automatisch befüllt.
<element name="mappings" minOccurs='0' maxOccurs='1'>
<mcrmetaclassification name="mapping"
class="MCRMetaClassification" minOccurs='1' maxOccurs='unbounded' />
</element>
Die eigenen Klassifikationen werden um ein Label mit dem künstlichen Sprach-Attribut „x-mapping“ erweitert. Als Wert wird Klassifikations-ID und Kategorie-ID getrennt durch einen Doppelpunkt dort eingetragen. Mehre Werte können durch Leerzeichen getrennt eingetragen werden. z.B.:
<category ID="TYPE0003.006"> <label xml:lang="de" text="Dissertation" /> <label xml:lang="en" text="dissertation" /> <label xml:lang="x-mapping" text="diniPublType:doctoralThesis dctermsDCMIType:Text XmetaDissPlusThesisLevel:thesis.doctoral diniVersion:publishedVersion" /> </category>
Das Mapping wird per EventHandler aktiviert und sollte möglichst früh aufgerufen werden, zumindest noch vor dem Start der Indexierung.
MCR.EventHandler.MCRObject.1a.Class
=org.mycore.oai.classmapping.MCRClassificationMappingEventHandler
Konfiguration des OAI-Providers
Mehrfache Verwendung
Es ist möglich mehrere OAI-Provider parallel zu betreiben. So kann man beispielsweise einen OAIProvider für das Melden der Dissertationen an die Deutsche Nationalbibliothek verwenden und mit einem zweiten OAIProvider den gesamten Dokumentenbestand für OpenAccess-Portale wie OAIster oder BASE bereit stellen.
Als Unterscheidungskriterium gilt der Servletname, wie er in der web.xml verwendet wird. Er ist auch Bestandteil der Propertynamen in den Konfigurationsdateien. Die Verwendung derselben Servletklasse ist möglich.
Aktivierung des Servlets
Das OAI2 Servlet muss in der web.xml aktiviert werden:
<servlet id="OAI2Provider">
<servlet-name>OAI2</servlet-name>
<servlet-class>org.mycore.oai.MCROAIDataProvider</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>OAI2</servlet-name>
<url-pattern>/oai2</url-pattern>
</servlet-mapping>
Properties
Für die Konfiguration der Schnittstelle sind eine Reihe von Properties notwendig. Viele können in der Defaulteinstellung verwendet werden, einige sind jedoch in der eigenen Anwendung zu überschreiben.
Property für die Ausgabeformatierung
Für die Visualisierung der OAI-Requests im Webbrowser wird das OAI2 to HTML XSLT Style Sheet von Eprints verwendet.
Folgendes Property gibt den Pfad zu diesem Stylesheet in der eigenen Anwendung an:
MCR.OAIDataProvider.OAI2.ResponseStylesheet=oai/oai2.xsl
Properties für den Identify-Request
Für die genaue Bedeutung der Properties und ihre möglichen Werte sei ein Blick in den OAI-Standard empfohlen:
# Properties for OAI Identify Request:
MCR.OAIDataProvider.OAI2.RepositoryName=MyCoRe Sample Repository
MCR.OAIDataProvider.OAI2.RepositoryIdentifier=www.mycore.de
MCR.OAIDataProvider.OAI2.AdminEmail=info@mycore.de
MCR.OAIDataProvider.OAI2.EarliestDatestamp=1970-01-01
MCR.OAIDataProvider.OAI2.RecordSampleID=DocPortal_document_07910403
MCR.OAIDataProvider.OAI2.DeletedRecord=transient
MCR.OAIDataProvider.OAI2.Friends.DuEPublico=http://duepublico.uni-duisburg-essen.de/servlets/OAIDataProvider
MCR.OAIDataProvider.OAI2.Friends.DBThueringen=http://www.db-thueringen.de/servlets/OAIDataProvider
Properties für Resumption Tokens
Mittels Resumption Tokens kann die Rückgabe großer Mengen an Dokumenten partitioniert werden. Genauere Angaben entnehmen Sie der OAI-Spezifikation.
Für die Konfiguration werden folgende Properties verwendet:
MCR.OAIDataProvider.ResumptionTokens.PartitionSize=100
MCR.OAIDataProvider.ResumptionTokens.MaxAge=1440
Properties für den OAIAdapter
Mit dem OAIAdapter wird der einheitliche, protokoll-spezifische Teil der OAImplementierung von den konkreten Anforderungen der Anwendung (MyCoRe oder MILESS) getrennt. Für MyCoRe-Anwendungen steht die Klasse MCROAIAdapter zur Verfügung. In wenigen Ausnahmefällen kann es notwendig sein, diese Klasse neu zu implementieren oder zu erweitern.
MCR.OAIDataProvider.OAI2.Adapter=org.mycore.oai.MCROAIAdapter
Die Erzeugung des Header- und des Metadatenteils eines OAI-Responses erfolgt über Stylesheets, die über den URI-Resolver aufgerufen werden. Im DocPortal befinden sich eine beispielhafte Umsetzung für document2header.xsl. Für jedes Metadatenformat muss ebenfalls ein Stylesheet erzeugt werden (siehe Properties für Metadatenformate).
MCR.OAIDataProvider.OAI2.Adapter.HeaderURIPattern=xslStyle:document2header:mcrobject:{id}
MCR.OAIDataProvider.OAI2.Adapter.RecordURIPattern=xslStyle:document2{format}:mcrobject:{id}
Properties für die Suche
Mit den folgenden Properties lässt sich die Menge der Dokumente, die über die OAI-Schnittstelle ausgeliefert werden, einschränken und sortieren.
MCR.OAIDataProvider.OAI2.Search.Restriction=objectType = document
MCR.OAIDataProvider.OAI2.Search.SortBy=modified descending, id descending
MCR.OAIDataProvider.OAI2.Search.FromUntil=modified
Properties für Sets
Das Konzept der Sets im OAI-Standard lässt sich mit dem Klassifikationskonzept von MyCoRe vergleichen.
Mit dem Property FilterEmptySets kann bestimmt werden, ob auch leere Sets bei einem List-Sets-Request zurückgegeben werden.
MCR.OAIDataProvider.OAI2.FilterEmptySets=true
Mit dem folgenden Property werden zunächst alle Sets definiert, die in der Anwendung verwendet werden sollen:
MCR.OAIDataProvider.OAI2.Sets=open_access,doc-type
Mit einem XSLT-Stylesheet und unter Verwendung des URI-Resolvers kann aus einer MyCoRe-Klassifikation die entsprechende Ausgabe für einen OAI-List-Sets-Request generiert werden:
MCR.OAIDataProvider.OAI2.Set.doc-type= xslStyle:classification2sets:classification:metadata:10:noEmptyLeaves:children:diniPublType
Für die Suche nach Dokumenten, die als Inhalt eines Sets zurückgegeben werden sollen, kann einem Setnamen ein Klassifikationsname zugeordnet werden:
MCR.OAIDataProvider.OAI2.MapSetToClassification.doc-type=diniPublType
Alternativ besteht auch die Möglichkeit, per URI-Resolver direkt eine XML-Datei mit der Set-Konfiguration anzugeben:
MCR.OAIDataProvider.OAI2.Set.open_access=webapp:oai/set_open_access.xml
Beispiel für eine statische Sets Datei im XML Format:
<?xml version="1.0" encoding="UTF-8"?> <ListSets xmlns="http://www.openarchives.org/OAI/2.0/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/ http://www.openarchives.org/OAI/2.0/OAI-PMH.xsd"> <set> <setSpec>open_access</setSpec> <setName>Open Access publications</setName> </set> </ListSets>
Zu Beachten ist hierbei die Verwendung des OAI Namensraumes.
Bei statisch definierte Sets muss für jeden Eintrag ein Property gesetzt werden, welches eine Suchanfrage auf die Dokumente innerhalb des Sets zurückliefert:
MCR.OAIDataProvider.OAI2.MapSetToQuery.open_access=(objectType = *)
Properties für Metadatenformate
Zunächst sind die unterstützten Metadatenformate aufzulisten und dann jeweils Namensraum und URL der XMLSchema-Definition anzugeben:
MCR.OAIDataProvider.OAI2.MetadataFormats=oai_dc,epicur MCR.OAIDataProvider.MetadataFormat.oai_dc.Schema=http://www.openarchives.org/OAI/2.0/oai_dc.xsd MCR.OAIDataProvider.MetadataFormat.oai_dc.Namespace=http://www.openarchives.org/OAI/2.0/oai_dc/ MCR.OAIDataProvider.MetadataFormat.epicur.Schema=http://www.persistent-identifier.de/xepicur/version1.0/xepicur.xsd MCR.OAIDataProvider.MetadataFormat.epicur.Namespace=urn:nbn:de:1111-2004033116
Für jedes Metadatenformat ist außerdem ein XSL-Stylesheet zu erstellen, welches aus dem MyCoRe-Datenmodell das entsprechende Ausgabeformat erzeugt. Im DocPortal befinden sich beispielhafte Implementierungen für document2oai_dc.xsl und document2epicur.xsl. Diese sind jedoch in der Regel an das eigene Datenmodell anzupassen.
Nutzung der URN-Vergabe
Die URN-Vergabe für Dokumente und deren Derivate ist in DocPortal standardmässig
aktiviert. Möchte man dies deaktivieren, so findet man die folgende, dann zu
löschende Zeile unter docportal/modules/common/config/mycore.properties:
MCR.URN.Enabled.Objects = document
Soll für mehrere Objekttypen die URN-Vergabe ermöglicht werden, so
müssen alle Typen durch Komma getrennt an dieser Stelle angegeben werden:
MCR.URN.Enabled.Objects = document,file,certificate
Es erscheint daraufhin im DocPortal in der Bearbeitungsleiste unterhalb des
Derivates und unterhalb des Dokumentes eine Schaltfläche für das automatische
Erzeugen einer URN.
In der Basisimplementierung sorgt der MCRURNProvider für die Erzeugung
der URN. Dieser generiert die URN nach dem gleichen Schema, wie auch sonst
URNs für die Metadatensätze erzeugt werden.
MCR.URN.Provider.Class=org.mycore.services.urn.MCRURNProvider
Eine Anpassung kann in den mycore.properties.private im Abschnitt
# The MyCoRe properties URN file for the DocPortal # vorgenommen werden.
Reichen die Optionen über die Properties nicht aus und die URNs sollen mit einem anderen Aufbau generiert werden, so muss dafür eine eigene Klasse geschrieben werden, die das org.mycore.services.urn.IURNProvider-Interface implementiert oder einfacher gleich von org.mycore.services.urn.AbstractURNProvider abgeleitet wird. Die neue Klasse muss dann mit dem vollen Klassenpfad als Wert für das Property MCR.URN.Provider.Class gesetzt werden.
Die erzeugten URNs werden zum einen in der Datenbank in der Tabelle MCRURN als auch im Derivate selber abgelegt.
Erzeugen einer Google Sitemap
In MyCoRe gibt es im Indexing-Module ein kleines Servlet, welches eine Datei erzeugt, die den Konventionen des Sitemap-Protokolls von Google entspricht. Der Zugriff vom Internet aus erfolgt mit der URL http://myhost/sitemap_google.xml. Für die Konfiguration dieser XML-Ausgabe stehen in den Property-Dateien zwei Werte zur Verfügung.
- MCR.GoogleSitemap.Types
- Liste von mit Komma getrennten MyCoRe-Objekttypen – Standard ist document
- MCR.GoogleSitemap.Freq
- Zugriffsfrequenz von Google – Standard ist monthly – weiter möglich sind: allways / hourly / daily / weekly / monthly / yearly / never
- MCR.GoogleSitemap.ObjectPath
- Pfad (Teil nach Anwendungs URL) unter dem die Detailansicht der Objekte abgerufen werden kann. - Standard ist: receive/
- MCR.GoogleSitemap.NumberOfURLs
- Maximale Anzahl der Einträge pro Sitemap Datei. - Standard ist: 5000
Um den Zugriff von Google gezielt anzufordern, sollten folgende Schritte durchgeführt werden:
- Auf http://www.google.de/sitemaps gehen.
- Ein Google – Konto einrichten.
- Die URL der Anwendung eintragen.
- Die URL der zugehörigen sitemap eintragen.
Nun sollte Google die geladenen Datenobjekte gezielt indizieren und so eine gute Verfügbarkeit in den Suchmaschienen erreichen.
Einbindung virtueller Host-Namen mit Hilfe des Apache-Web-Servers
Standardmäßig ist der Apache2 in den Installations-CDs aller gängigen Linux-Distributionen und in MacOS enthalten. Für Windows muss ein gesonderter Download erfolgen (Kapitel 2). Der Quellcode des Apache2 liegt auf http://httpd.apache.org für ein Download bereit. Die folgende Beschreibung bezieht sich auf die Apache-version 2.0.x. Die weitere Beschreibung bezieht sich hinsichtlich der Pfade auf ein UNIX/MacOS-System, für Windows sind die dazu korrespondierenden Pfade zu nutzen.
Einbindung des Proxy-Modules
Die Einbindung des Proxy-modules ist relativ einfach zu bewerkstelligen. In der Datei /etc/sysconfig/apache2 sind in der Zeile der Variable APACHE_MODULES die Module proxy,proxy_http,proxy_connect hinzuzufügen. Nach der Änderung ist der Neustart des Apache-Servers erforderlich.
Die Verbindung von einer Servlet-Engine und Apache2
Die Verbindung zwischen dem Apache2 und der Servlet-Engine wird in den Konfigurationsfiles /etc/apache2/httpd.conf und /etc/apache2/http-vhosts.conf konfiguriert.
In der Datei /etc/apache2/httpd.conf ist die Include-Anweisung für das Lesen der Zusatzkonfiguration http-vhosts.conf zu aktivieren. Anschließend wird der eigentliche virtuelle Host in dieser Datei definiert. Dabei sind natürlich die Pfade zu den einzelnen Verzeichnissen entsprechend den aktuellen Gegebenheiten anzupassen.
<VirtualHost mycoresample.dl.uni-leipzig.de:80> ProxyPass / http://mycoresamplelinux.dl.uni-leipzig.de:8291/ ProxyPassReverse / http://mycoresamplelinux.dl.uni-leipzig.de:8291/ ServerAdmin mcradmin@mycoresamplelinux.dl.uni-leipzig.de DocumentRoot /home/mcradmin/docportal/webapps ServerName mycoresamplelinux.dl.uni-leipzig.de ErrorLog /var/log/apache2/mycoresample-error_log CustomLog /var/log/apache2/mycoresample-access_log common Alias /mycoresamplelinux "/home/mcradmin/docportal/webapps" <Directory "/home/mcradmin/docportal/webapps/" > Options Indexes FollowSymLinks DirectoryIndex AddHandler jakarta-servlet2 .jsp Order deny,allow Deny from all Allow from all </Directory> <Directory "/mycoresamplelinux" > Options Indexes FollowSymLinks DirectoryIndex AddHandler jakarta-servlet2 .jsp Order deny,allow Deny from all Allow from all </Directory> </VirtualHost>
Nach dieser Änderung ist zuerst die Servlet-Engine zu starten. Anschließend kann der Apache-Server mit /usr/sbin/rcapache2 neu gestartet werden.
Sicherung der Daten
Backup
Natürlich muss ein Dokumenten-Server im Produktionseinsatz auch ein Datensicherungskonzept haben. Je nach Einsatz der gewählten Datenbank ist der erste Schritt natürlich eine Sicherung der selben nach Backup-Vorgaben des Herstellers. Dazu kommt auch eine regelmäßige Backup-Strategie für das Server-System.
Ein weiterer Schritt ist das komplette Auslesen des Datenbestandes und die Speicherung auf einem externen (ggf. Netzwerk-) Filesystem. Mit dieser Methode lassen sich auch Migrationen durchführen. Die Distribution enthält im Verzeichnis bin Scripts für Windows und Linux, die diese Aufgabe realisieren. Gestartet wird jeweils das Save.cmd bzw. Save.sh Script. Diese Kommandodateien rufen dann weitere Scripts, welche mit Save... beginnen auf. Im Ergebnis des Kommandos werden alle Daten in das $DOCPORTAL_HOME/save -Verzeichnis exportiert.
Recovery
Die mittels des Save-Kommandos exportierten Daten können im Bedarfsfall wieder in ein ggf. neu erstelltes System eingespielt werden. Sollte es nötig sein, einzelne Benutzer mit Ihren gesicherten Passworten neu zu laden, so ist vorher das im bin-Verzeichnis befindliche Script SelectUserFromSave.sh zu starten. Nach erfolgreichem Lauf befinden sich für jeden Benutzer / jede Gruppe Dateien im Verzeichnis $DOCPORTAL_HOME/config/user. Diese Daten können dann im MyCoRe-Kommandozeilen-Tool mit den Kommandos 'delete user ...' und 'import user from file ...' geladen werden.
Sollte nur der Metadaten-Index (z. B. Lucene) defekt sein, so hilft das Script RepairFromXMLStore.sh diesen Index neu zu erstellen.
Sind die XML-Daten bzw. die Derivate defekt bzw. weg so könne die gesicherten Daten aus dem save-Verzeichnis in die Workflow-Directories kopiert werden. Mit dem Kommandozeile-Tool bzw. speziellen Scripts unter unixtools können diese Objekte nun wieder in das System eingebracht werden.
WCMS
Um die Webseiten rund um die generischen Inhalte pflegen zu können, bringt MyCoRe ein eigenes propriäteres WCMS mit. ToDo: Screenshot, kurze Beschreibung