[Edit]Technischer Leitfaden - Fedora, Islandora, Drupal

Der Leitfaden zum Einsatz von Fedora für linguistische Forschungsdatenrepositorien wurde durch das Institut für Deutsche Sprache Mannheim (IDS) (http://www.ids-mannheim.de/), das Hamburger Zentrum für Sprachkorpora (HZSK) (http://www.corpora.uni-hamburg.de/) und das Institut für deutsche Sprache und Linguistik (http://www.linguistik.hu-berlin.de/institut/professuren/korpuslinguistik/) sowie den Computer- und Medienservice (http://www.cms.hu-berlin.de/) der HU Berlin initiiert. Hier werden Erkenntnisse über Installation, Erweiterungen und Lösungen zu typischen Problemen zu Fedora und darauf aufbauenden Oberflächen wie Islandora gebündelt und fortgeschrieben.

[Edit]Darstellung der einzelnen Projekte

1. IDS-Mannheim
   1. Projektdefinition
   2. Projektpartner
   3. Objektmodell
   4. Ziele

1. HZSK-Hamburg
   1. Projektdefinition
   2. Projektpartner
   3. Objektmodell
   4. Ziele

1. IDSL und CMS HU-Berlin @LAUDATIO-Projekt
   1. Projektdefinition
   2. Projektpartner
   3. Objektmodell
   4. Evaluierung verschiedener möglicher Softwareanwendungen
      1. Fedora + eSciDoc + PubMan
   5. Ziele

[Edit]Fedora als Back End

[Edit]Grundlagen

Um mit Fedora arbeiten zu können, ist es also notwendig die genannten Abstraktionen, die den Umgang mit Informationen betreffen, zu verstehen. Fedoras Datenverständnis lässt sich auf die folgenden drei Punkte zusammenfassen:

1. Ein Repositorium besteht aus Objekten
2. Objekte haben Beziehungen zueinander
3. Objekte sind Container für verschiedene Arten von zusammengehörenden Daten (“Datastreams”)
   1. die “eigentlichen” Daten (“Content”) (z.B. Bilder, Audiofiles, PDFs, etc.)
   2. die dazugehörigen Metadaten (Autor, Erstellungsdatum, Dateityp, etc.)
   3. die semantischen Beziehungen des Objekts (“ist eine Transkription von”, “gehört zur Sammlung” etc.) zu anderen innerhalb des Repositoriums.

Die Zahl der Objekte im Repositorium, der Datastreams im Objekt und der Beziehungen zwischen den Objekten ist unbegrenzt. Daten können sowohl in den Objekten gespeichert und verwaltet werden, als auch extern verlinkt.

Ein Objekt ist eine XML-Datei (basierend auf dem Systemeigenen FOXML), wird vom System verwaltet und beinhaltet die Information darüber, wo die einzelnen Datastreams zu finden sind.

Fedora ermöglicht es außerdem, Services zu definieren, die durch ein Zusammenspiel von Dataobjects und verschiedener Spezialobjekte die auf dem Server generierte Verarbeitung der Daten zu bestimmten Ausgaben ermöglichen, so kann etwa ein DataObject das eine Transkription im exb-Format enthält via XSL zur Partituransicht gerendert werden. Ausführlicher wird dieser Punkt unter Services definieren erklärt.

Neben dem “einfachen” Objekt, das einen oder mehrere Datensätze enthält gibt es noch verschiedene Typen von Spezialobjekten, die Aufgaben im Repositorium übernehmen. Dies äußert sich in der Regel durch spezielle Datastreams die in den jeweiligen Objekten enthalten sind. Die Objekte und auch die besonderen Datastreams werden im folgenden näher beschrieben.

[Edit]Objekte

Der Aufbau eines Objekts ist im wesentlichen auf drei Basisbausteine zurückzuführen:

1. 1. Einen eindeutigen Identifizierer (Persistent Identifier = PID)
2. 2. Die vom System zur Verwaltung benötigten Object Properties
3. 3. Die Datastreams.

Wie beschrieben gibt es einige spezielle Datastreams, die Aufgaben im Repositorium haben. Ihre Namen sind vom System reserviert. Sie werden ausführlicher im Abschnitt Reservierte Datastreams beschrieben.

Um ein Objekt (etwa im Fedora-Admin Client) anzulegen, sind die folgenden Informationen anzugeben bzw werden automatisch vergeben:

1. Datastream Identifier: Eine PID
2. State: Active, Inactive oder Deleted
3. Created Date: Datum/Zeit (wird zugewiesen, kann später zur Identifikation einer Version an die PID gehängt werden)
4. Modified Date: Datum/Zeit (wird zugewiesen, kann später zur Identifikation einer Version an die PID gehängt werden)
5. Versionable: true oder false, ob das Objekt versioniert wird (Standardmäßig ja)
6. Label: Natürlichsprachliche Beschreibung
7. MIME Type: Datentyp (benötigt!)
8. Control Group: Objekte enthalten (in der Regel) keine Daten sondern nur Datastreams die angeben, wo die Daten zu finden sind. Die Daten können dabei auf viererlei Weise gespeichert werden:
   1. Inline XML (X) - XML direkt in das Objekt eingebettet
   2. Managed Data (M) - Datei wird vom System gespeichert
   3. External Reference (E) - Objekt# wird durch Fedora gestreamt
   4. Redirect (R) - Wie E, Objekt wird aber direkt geöffnet

[Edit]Objekttypen

[Edit]Data Object (DO)

Das DataObject enthält die eigentlichen Daten (“Content”).

[Edit]Content Model Object (CModel)

Das CModel dient als eine Art Blaupause für eine bestimmte Art von DataObjects. So kann über das CModel z.B. festgelegt werden, dass Objekte der Klasse “Recording” mindestens einen Datastream der Klasse WAV oder MPG haben müssen. Die Daten befindet sich im DS-COMPOSITE-MODEL Datastream. Man beachte auch, dass Islandora eigene bzw. zusätzliche Vorstellungen von Content Models hat:

Um ein Content Model zu definieren, geht man wie folgt vor:

1. 1. Create object "namespace:contentmodel"
2. 2. Create object "namespace:objectxyz"
3. 3. Open "namespace:objectxyz"
4. 4. Add the relation "namespace:objectxyz" "hasModel" "genre:contentmodel"
5. 5. Open "namespace:contentmodel"
6. 6. Open datastream "DS-COMPOSITE-MODEL"

[Edit]Service Definition Object (SDef)

Im SDef Objekt werden die Operationen eines Service definiert, ohne jedoch Aussagen über die Umsetzung dieser Operationen zu treffen. Die Operationen werden im Datastream OPERATIONMAP gespeichert. Service Deployment Object (SDep)

Hier wird im Detail festgehalten, wie die in einem SDef beschriebenen Operationen ausgeführt werden. Dazu werden die Datastreams WSDL, SERVICE-PROFILE, DSINPUTSPEC und OPERATIONMAP benötigt.

[Edit] Installation

[Edit]Fedora

[Edit]Voraussetzungen

Download Java JDK 6

http://www.oracle.com/technetwork/java/javase/downloads/jdk-6u27-download-440405.html

Installing Java JDK 6

Changing Enviroment Variables

FEDORA_HOME - C:\fedora

PATH - %FEDORA_HOME%\server\bin;%FEDORA_HOME%\client\bin;%JAVA_HOME%\bin

[Edit]Quick Installation

Quick Installation bedeutet, dass alle Sicherheitsrelevanten Einstellungen (XACML, SSL) deaktiviert sind. Außerdem werden standardmäßig das inkludierte Tomcat sowie eine Derby-Datenbank verwendet (was zumindest auf die Datenbank bezogen für dauerhaften Betrieb nicht zu empfehlen ist).

Installer starten

java -jar fcrepo-installer-3.4.2.jar

Quick Install wählen

[Edit]Nach Quick Installation: Demo Objekte installieren

Entweder via Custom Install oder via Kommandozeilenbefehl:

fedora-ingest-demos.bat [hostname] [port] [username] [password] [protocol]

e.g. fedora-ingest-demos.bat localhost 8080 fedoraAdmin mystupidpassword http

Mit den Demoobjekten lässt sich herumspielen um bestimmte Eigenschaften von Fedora auszutesten, unter anderem, wie Collections oder Methoden funktionieren. Die Collections sind allerdings anders als bei Islandora aufgebaut und wenn geplant ist, Islandora als Front-End zu verwenden, sollte man sich nicht zu lange mit den Fedora Demo Collections beschäftigen.

[Edit]Nach Quick Installation: ResourceIndex aktivieren

Entweder via Custom Install oder via folgendem:

Tomcat runterfahren fedora/tomcat/bin/shutdown.bat

fedora.fcfg öffnen

Supports the ResourceIndex.

value="1" enables ResourceIndex

Rebuild starten

Option “Rebuild ResourceIndex” wählen

Custom Installation

[Edit]Beispiel einer funktionierenden Installation

(Aus dem Installationsprotokoll des HZSK im Feb 2012)

Installation type
Enter a value ==> custom

Fedora home directory
Enter a value [default is /srv/fedora] ⇒ default

Fedora administrator password
Enter a value ⇒ ...

Fedora server host
Enter a value [default is localhost] ⇒ 123.456.78.9

Fedora application server context
Enter a value [default is fedora] ⇒ default

Authentication requirement for API-A
Enter a value [default is false] ⇒ false

SSL availability
Enter a value [default is true] ⇒ false

Servlet engine
Enter a value [default is included] ⇒ included

Tomcat home directory
Enter a value [default is /srv/fedora/tomcat] ⇒ default

Tomcat HTTP port
Enter a value [default is 8080] ⇒ default

Tomcat shutdown port
Enter a value [default is 8005] ⇒ default

Database
Enter a value ==> mysql

MySQL JDBC driver
Enter a value [default is included] ⇒ default

Database username
Enter a value ==> fedoraAdmin

Database password
Enter a value ==> ...

JDBC URL
Enter a value [default is jdbc:mysql://localhost/fedora3?useUnicode=true&characterEncoding=UTF-8&autoReconnect=true] ⇒ default

MySQL JDBC driver
Enter a value [default is included] ⇒ default

Database username
Enter a value ==> fedoraAdmin

Database password
Enter a value ==> ...

JDBC URL
Enter a value [default is jdbc:mysql://localhost/fedora3?useUnicode=true&characterEncoding=UTF-8&autoReconnect=true] ⇒ default

JDBC DriverClass
Enter a value [default is com.mysql.jdbc.Driver] ⇒ default

Enable FeSL AuthN
Enter a value [default is true] ==> true

Enable FeSL AuthZ (Experimental Feature)
Enter a value [default is false] ==> false

Policy enforcement enabled
Enter a value [default is true] ==> true

Low Level Storage
Enter a value [default is akubra-fs] ⇒ default

Enable Resource Index
Enter a value [default is false] ==> true

Enable Messaging
Enter a value [default is false] ==> false

Deploy local services and demos
Enter a value [default is true] ⇒ true

[Edit]Fedora Client installieren

Um Fedora von einem anderen Rechner aus anzusteuern.

Installer starten

java -jar fcrepo-installer-3.4.2.jar

Client auswählen

Umgebungsvariablen anpassen nicht vergessen!

[Edit]Fedora erneut installieren

Wenn ein unerklärlicher Fehler auftritt oder das System ins Abseits konfiguriert wurde, kann eine erneute Installation über die vorige Version hilfreich sein. Fedora kann nach Belieben neu installiert werden, da es die bereits ingestierten Daten nicht betrifft. Bei einer Neuinstallation wird allerdings der Fedora-Ordner komplett überschrieben, d.h. die beiden Dateien die zur Installation von Islandora nötig sind, müssen erneut an die entsprechende Stelle kopiert werden.

fcrepo-drupalauthfilter-3.4.2.jar -> $FEDORA_HOME/tomcat/webapps/fedora/WEB-INF/lib# jaas.conf -> $FEDORA_HOME/server/config/

(eigentlich wie die vorhandene jaas.conf, nur um Islandora ergänzt)

Die Custom-Installation umfasst vor allem die folgenden Punkte (in Klammern die gegenwärtigen Einstellungen):

1. Speicherort
- Standard, internes Tomcat
2. Datenbank
- MySQL, fedoraAdmin, EXMARaLDA
3. Sicherheit
- FeSL, kein SSL, XACML wird grad getestet
4. Sonstige Einstellungen
- ResourceIndex ja, Demos ja

[Edit]Fedora deinstallieren

Im Verlaufe einer Installation kann es bei allen Komponenten immer mal notwendig sein, sie wieder zu deinstallieren um bei einem erneuten Versuch irgendetwas besser zu machen.

Um Fedora zu deinstallieren reichen bei Verwendung vom interen Tomcat und externem MySQL die folgenden Schritte (alle Angaben für OpenSuse):

Löschen von Fedora aus //srv/

und

Löschen der fedora3-Datenbank aus //srv/mysql/tables

Bei der Neuinstallation muss zunächst in MySQL erneut eine Datenbank fedora3 angelegt werden, wie, steht in der Fedora-Dokumentation, die ich nun zitiere (zu beachten ist, dass die Backslashes Windowscode sind und durch eine Pipe | ersetzt werden müssen):

[Edit]MySQL

Please note that the MySQL JDBC driver provided by the installer requires MySQL v3.23.x or higher.

The MySQL commands listed below can be run within the mysql program, which may be invoked as follows:

mysql -u root -p

Create the database. For example, to create a database named "fedora3", enter:

CREATE DATABASE fedora3;

Set username, password and permissions for the database. For example, to set the permissions for user fedoraAdmin with password fedoraAdmin on database "fedora3", enter:

GRANT ALL ON fedora3.\* TO fedoraAdmin@localhost IDENTIFIED BY 'fedoraAdmin'; GRANT ALL ON fedora3.\* TO fedoraAdmin@'%' IDENTIFIED BY 'fedoraAdmin';

Da hier fedoraAdmin als Name und PW angegeben ist zur Sicherheit: Das hinter dem "by" ist das Passwort. Es kann allerdings sein, dass danach die Weboberfläche von Drupal nicht mehr aufrufbar ist.

1. Drupal

1. islandora-Module

[Edit] Erweiterungen / Funktionalitäten

1. Fedora
   1. GSearch
   2. FOXML

1. Islandora
   1. Nutzerverwaltung
   2. Formularerweiterung
   3. Suche mit Solr

[Edit]Nutzung von XSLT2.0 zur Dissemination von Datastreams

Standardmäßig wird von Islandora die PHP-Bibliothek libxslt als Prozessor für XSLT-Transformationen verwendet. Daher sind in Datastreams (z.B. “COLLECTION_VIEW”) zunächst nur XSLT1.0-Stylesheets einsetzbar. Mit Hilfe des mitgelieferten XSLT2.0-Prozessors Saxon, der in Form eines Servlet zur Verfügung steht (http://localhost:8080/saxon/SaxonServlet), ist es allerdings möglich, Islandora so zu erweitern, dass XSLT2.0-Stylesheets in Datastreams verwendet werden können. Hierzu kann der PHP-Code in der Datei CollectionClass.inc (welche in unserem Fall im Drupal-Verzeichnis unter sites/all/modules/islandora liegt) ca. ab Zeile 635 wie folgt angepasst werden:

$xslContent = $this->getXslContent($pid, $path);    
$xslDom = new DOMDocument();
$xslDom->loadXML($xslContent);
$stylesheetElems = $xslDom->getElementsByTagName('stylesheet');   
$xslVersion;
foreach( $stylesheetElems as $stylesheetElem ){
 $xslVersion = $stylesheetElem->getAttribute('version');
}
//get collection list and display using xslt------------------------
$objectList = "\n\n";
if (isset($content) && $content != FALSE) {
 $input = new DomDocument();
 $input->loadXML(trim($content));
 $results = $input->getElementsByTagName('result');
    if ($results->length > 0) {
       try {
         if($xslVersion == "2.0"){   
          //this is the custom method (XSLT 2.0)
          //registerPHPFunctions() NOT available in stylesheets   
          $xslAsString = str_replace('$collectionPid', "'$collection_pid'", $xslContent);
          $xslAsString = str_replace('$collectionTitle', "'$collectionName'", $xslAsString);
          $xslAsString = str_replace('$baseUrl', "'$base_url'", $xslAsString);
          $xslAsString = str_replace('$path', "'$base_url/$path'", $xslAsString);
          $xslAsString = str_replace('$hitPage', $pageNumber, $xslAsString);       
          file_put_contents("/srv/fedora/tomcat/webapps/ROOT/temp.xsl", $xslAsString);
          file_put_contents("/srv/fedora/tomcat/webapps/ROOT/temp.xml", $input->saveXML());                 
           $objectList .= file_get_contents("http://134.100.126.18:8080/saxon/SaxonServlet?
source=http://134.100.126.18:8080/temp.xml&style=http://134.100.126.18:8080/temp.xsl&clear-stylesheet-cache=yes");         
          } else{   
          //this is the standard method (XSLT 1.0)
          //registerPHPFunctions() IS available in stylesheets
          $proc = new XsltProcessor();
          $proc->setParameter(, 'collectionPid', $collection_pid);

          $proc->setParameter(, 'collectionTitle', $collectionName);

          $proc->setParameter(, 'baseUrl', $base_url);

          $proc->setParameter(, 'path', $base_url . '/' . $path);

          $proc->setParameter(, 'hitPage', $pageNumber);

          $proc->registerPHPFunctions();
          $xsl = new DomDocument();
          $xsl->loadXML($xslContent);
          $xsl = $proc->importStylesheet($xsl);
          $newdom = $proc->transformToDoc($input);
          $objectList .= $newdom->saveXML(); //is the xml transformed to html as defined in the xslt associated with the collection object
          if (!$objectList) {
               throw new Exception("Invalid XML.");
          }
           }
        } catch (Exception $e) {
          drupal_set_message(t('@e', array('@e' => check_plain($e->getMessage()))), 'error');
          return ;

        }
     }
  }
else {
drupal_set_message(t("No Objects in this collection or bad query."));
}

[Edit]Reservierte Datastreams

RELS-EXT und RELS-INT

Relations werden abhängig davon, ob sie sich auf zwei Datastreams innerhalb des gleichen Objekts beziehen (RELS-INT) oder nicht (RELS-EXT) gespeichert. Es handelt sich um RDF-Relations, d.h. sie folgen einer Subjekt-Prädikat-Objekt-Struktur. Relations können in der Regel frei definiert werden um semantische Beziehungen zwischen Objekten/Daten deutlich zu machen, etwa Datei A ist eine Transkritption von Datei B etc., vgl. diese von Fedora bereitgestellte und beliebig erweiterbare Fedora Relationship Ontology (http://www.fedora.info/definitions/1/0/fedora-relsext-ontology.rdfs). Es gibt jedoch auch einige Relations die besondere Aufgaben innerhalb des Repositoriums übernehmen. Diese Special Relations sind:

1. hasModel (für ein DataObject zu seinem ContentModel)
2. hasService (für ein Content Model, das einen Service in der Service Definition definiert hat)
3. isDeploymentOf (für ein ServiceDeployment Objekt, das ein Deployment einer ServiceDefinition ist)
4. isContractorOf (für ein ServiceDeployment Objekt, das ein Contractor eines Contend Models ist

Wichtig: Das Objekt muss genau wie das Subjekt info:fedora/ vor die eigene PID vorangestellt bekommen, vgl. Fedora Info URIs.

[Edit]Policy

Hierin ist die XACML Policy gespeichert, die den Zugang zu dem jeweiligen Objekt (also tatsächlich auf Objektebene) regelt. Siehe Autorisierung mit XACML Policies

[Edit]DC

Als Minimalmetadatenangabe ist dieser Dublin Core Datastream Pflicht. Von dem (extrem begrenzten Set) der DC Metadaten sind auch nur die beiden Datensätze und obligatorisch, die Werte werden vom Objektnamen (“Label”) und der PID abgeleitet, der Title kann auch im Nachhinein geändert werden. Weitere Metadaten sollten hierin nicht gespeichert werden, da der Datastream nur für die interne Suche verwendet werden soll. Des Weiteren wird er über den Fedora beigelegten OAI PMH Provider geharvested. Für weitere Informationen dazu, auch bzgl. unseren Repositoriums, siehe 7. Metadaten

[Edit]Clients

[Edit]Web-Based

Soll die Oberfläche von späteren Versionen sein, hat aber noch nicht alle Funktionen des Java-Clienten (Stand: Version 3.5).

Aufruf (http://134.100.126:8080/fedora/admin)

Webadmin Dokumentation (http://fedora-commons.org/confluence/display/FCR30/Fedora+Web+Administrator)

[Edit]Java-Based

Erlaubt die manuelle Erstellung, Kontrolle, Bearbeitung und Löschung von Objekten. Soll durch die Web-basierte Oberfläche abgelöst werden, die aber noch nicht komplett fertiggestellt ist. Einige Besonderheiten: Anstatt durch die Objekte scrollen zu können, muss in regelmäßigen Abständen auf “Show more” geklickt werden woraufhin ein neues Fenster geöffnet wird. Sollte dies nicht geschehen, werden im Terminal üblicherweise auch Fehler angezeigt. Bei diesem Problem hat sich ein Rebuild des Repositoriums als nützlich erwiesen (siehe Nützliche Befehle).

1. Aufruf:
2. Windows: %FEDORA_HOME%\client\bin\fedora-admin.bat
3. Linux: $FEDORA_HOME/client/bin/fedora-admin.sh

[Edit]Suchen

[Edit]Basic Search

Indiziert (nur) die obligatorischen DC-Datastreams. Diese sollten daher auch nicht zu groß sein, sondern nur die beiden Elemente Title und Identifier enthalten, vgl. 8. Metadaten und Metadata Harvesting. Es handelt sich hierbei auch um die Suchfunktion innerhalb der Clients.

Aufruf (http://134.100.126.18:8080/fedora/search)

Dokumentation Basic search (http://fedora-commons.org/confluence/display/FCR30/Basic+Search)

[Edit]PrOAI

PrOAI lets you selectively expose your repository under the Open Archives Initiative (OAI) scheme.

Für mehr Details zu Metadata Harvesting siehe 8. Metadaten und Metadata Harvesting. Arbeitet sowohl mit normalen als auch mit virtuellen Datastreams (vgl. Services definieren) Solr

Resource Index: Hier speichert Fedora die semantischen Informationen, die es aus den RELS-EXT und RELS-INT Datastreams ausliest und der demzufolge RDF-basiert ist. Resource Index (http://fedora-commons.org/confluence/display/FCR30/Resource+Index)

[Edit]Services

[Edit]Services definieren

Um einen Fedora Web-Service zu definieren muss die folgenden Beziehung zwischen Objekten modelliert werden:

Data Object: -> has Model -> Content Model

Content Model: -> has Service -> Service Definition

Service Deployment: -> deploys Service -> Service Definition

Service Deployment: ->

Die einzelnen Objekttypen wurden weiter oben beschrieben. Hier folgt nun die konkrete Definition des Services anhand der Bedingungen, die die einzelnen Objekte erfüllen müssen.

[Edit]DataObjects

Eine Klasse Dataobject (also alle Objects die dazu geören) hat die Relation “hasModel” zu dem dazugehörigen ContentModel.

[Edit]ContentModel

Das ContentModel hat eine Relation “hasService” zu einer Service Definition.

[Edit]ServiceDefinition

Die Service Definition (SDef) enthält einen Datastream “METHODMAP” in dem die zu Verfügung stehenden Services aufgelistet werden (sonst nichts). Fedora bietet eine Beispielmethodmap (http://fedora-commons.org/definitions/1/0/fedoraSDefMethodMap.xsd).

Die Methodmap im Objekt tra:sdef kann man auf dieser (https://wiki.duraspace.org/display/FEDORA34/Creating+a+Service+Definition) Seite nachlesen.

Von SDef gehen keine Relationen aus, aber es ist das Ziel der Relation von ContentModel und ServiceDeployment.

[Edit]ServiceDeployment

Das ServiceDeployment (SDep) ist das komplexe Kernelement der Services. Es beschreibt, wie die in einer ServiceDefinition beschriebenen Services umgesetzt werden. Dazu sind die Datastreams Methodmap, DSINPUTSPEC und WSDL nötig. SDep hat die Relation isDeploymentOf zu sDef und die Relation isContractorOf zum ContentModel.

Die Methodmap ist der in der ServiceDefinition ähnlich, geht aber darüber hinaus. Ziel ist es, neben den bloßen Service-Namen auch die zu verwendenen Datastreams anzugeben (Fedora bietet dieses Format-Beispiel (http://fedora-commons.org/definitions/1/0/fedoraSDepMethodMap-1.1.xsd)).

Die Methodmap im Objekt tra:sdep kann man auf diesen (https://wiki.duraspace.org/display/FEDORA34/Creating+a+Service+Definition) Seiten Nachlesen.

In DSINPUTSPEC werden im Fedora Datastream Input Specification format (http://fedora-commons.org/definitions/1/0/fedoraBindingSpec-1.1.xsd) alle Datastreams die in der Methodmap angegeben sind näher spezifiziert.

DSINPUTSPEC im Objekt tra:sdep kann man auf diesen (https://wiki.duraspace.org/display/FEDORA34/Creating+a+Service+Definition) Seiten nachlesen.

Der Datastream WSDL führt die verschiedenen Fäden zusammen, indem er Fedora sagt, was genau mit den Services und Datastreams geschehen soll - Fedora wird letztlich eine URL erstellen mit der es die Anfrage beantworten kann. Da Fedora ein spezielles WSDL fordert und nur mit HTTP GET arbeitet, ist es sinnvoll, das Template (https://wiki.duraspace.org/display/FEDORA35/Creating+a+Service+Deployment#CreatingaServiceDeployment-METHODMAPDatastream) als Grundlage für eigene WSDLs zu verwenden.

[Edit]Islandora als Front-End

Islandora bringt mit Fedora, Drupal und Solr drei Technologien zusammen und ermöglicht auf diesem Wege eine ganze Reihe an Funktionen für das Repositorium:

1. Islandora ist ein Front-End für Fedora, d.h. es bietet eine Weboberfläche auf der ein User die im Repositorium angelegten Daten abrufen und durchsehen kann. Um Islandora zu nutzen, müssen Collections etwas anders begriffen werden, als es nur bei Fedora der Fall wäre: Collections sind das bestimmende Organisationsmuster in Islandora, da sie auf dieser Basis die Möglichkeiten bieten, die Daten einfach durchzubrowsen. Ein Ergebnis dieser Umstellungen ist etwa, dass ein Sprecher sowohl als Collection für die Kommunikationen dient, an denen er teilgenommen hat als auch gleichzeitigTeil der jeweiligen Kommunikationen ist, die ihrerseits Collections sind.
2. Islandora macht dies, indem es der ContentManagement Software Drupal als Modul dient, mittels dessen die Fedora-Daten in einer Drupal-Webumgebung angezeigt werden können.
3. Islandora bietet SolutionPacks für verschiedene Datentypen. Diese beinhalten Workflows, Metadatenformulare und Programme zur optimalen Anzeige der Daten.
4. Islandora kombiniert die von Fedora kommenden XACML Policies mit dem feinabstimmbaren und leicht zu verwaltenden User-Management von Drupal, was es erleichtert, Usern Zugang zu bestimmten Informationen/Collections zu verschaffen.
5. Dieses Feature erlaubt es, Islandora unter anderem auch als kollaboratives Tool zu nutzen.

[Edit]Objekttypen in Islandora

[Edit]Content Model Object

Islandora erweitert das Content-Model Object von Fedora, indem es ein Islandoraspezifisches ContentModel einführt, das über den Datastream ISLANDORACM verfügt. Das Content Model ist dafür verantwortlich, wie ein Objekt aufgebaut sein darf, wie es ingested und wie es angezeigt wird.

[Edit]Collection Object

Objekte, die Teil einer Sammlung sind, drücken dies durch eine “isMemberOf” Beziehung zum dazugehörigen Collection Object aus. Eine Islandora-Instanz verfügt über eine Root-Collection die den Startpunkt der Weboberfläche des Repositoriums darstellt. Ein Collection Object seinerseits muss mit einem Collection-Content Model assoziiert sein. Das Collection Model definiert, was für Data Objects Teil der Collection sein dürfen und wie diese Ingestiert werden können. Diese Informationen werden innerhalb des Collection Objects im Datastream COLLECTION_POLICY gespeichert.

[Edit]Wichtige Datastreams

Es gibt auch einige neue Objekte, die in der Islandoradokumentation beschrieben sind und Beachtung finden müssen:

[Edit]IslandoraCM

Dieser Datastream wird an die Contentmodels für die anzuzeigenden Objekte gefügt. Darin wird definiert, wie ein Objekt dieser Art zukünftig mit Islandora ingested werden soll. Darin wird auch definiert, wie diese Objekte angezeigt werden

[Edit]CollectionView

Dieser Datastream wird an die Contentmodels für Collectionsobjects gefügt, wenn man das Standarderscheinungsbild einer Islandora-Collection verändern möchte. Dies wird dann innerhalb dieses Datastreams anhand von etwa XSL gemacht. Im Ordner srv/www/htdocs/drupal-6.22/sites/all/modules/islandora/example_collection_views befinden sich verschiedene zum Teil sehr taugliche Beispiele.

[Edit]Collections im Islandora’schen Sinne

Eine Collection muss als solche ausgewiesen werden - sie wird damit vom reinen DataObject zum Collection Object.

[Edit]Drupal als Weboberfläche und Nutzermanagement

In Drupal können User angelegt werden, mit denen man sich auch in das Fedora-Backend einloggen kann. Dazu muss jedoch der Hashwert des dort vergebenen Passwortes aus der MySQL Datenbank ausgelesen werden.

Hiermit lässt sich einfach testen, ob die Verbindung von Fedora und Drupal, die durch Islandora eingeleitet wurde, erfolgt ist.

Wenn man Drupal gestartet hat, muss es über die oa URL geöffnet und aufgesetzt werden.

[Edit]Metadaten und Metadata Harvesting

[Edit]DC

Jedes Objekt hat einen obligatorischen DC-Datastream in dem sich zwei obligatorische Einträge, Titel und Identifier, finden. Da aber aus Performance-Gründen davon abgeraten wird, deutlich mehr als diese Informationen in den DC-Datastream einzufügen, kann es sinnwoll sein, zusätzlich einen separaten DublinCore Datastream anzulegen. Die Metadaten werden dann als Managed Content (M) eingefügt. Um die Metadaten dann zu indizieren, verwenden kann GSearch verwendet werden.

[Edit]Metadata Harvesting

Für die Bereitstellung der Metadaten via OAI-PMH bieten sowohl Fedora, als auch Drupal und Islandora Möglichkeiten. Gegenwärtig besteht allerdings die Einschränkung, dass nur DublinCore Metadaten zum Harvesting angeboten werden können. Um andere Metadatenformate auszuliefern müssen die Dateien separat angepasst werden. Dazu kann PrOAI verwendet werden:

PrOAI: ein für Fedora geschriebener Metadatenharvester: PrOAI (http://proai.sourceforge.net/)

[Edit]Sicherheit

Zur Sicherheit des Repositoriums gehören bei Fedora die Aspekte Authentifizierung, Autorisierung und SSL, die im folgenden beschrieben werden. Kurz zusammengefasst umfasst ein Anmeldevorgang in einem IT-System immer die beiden Vorgänge Authentifizierung und Autorisierung. Zunächst authentifiziert sich der User vor dem System und bekommt dann auf dieser Basis vom System per Autorisierung seine jeweiligen Rechte zugewiesen.

[Edit]Zum Zusammenspiel von Fedora und Drupal (via Islandora)

Fedora und Drupal werden durch das Drupal-Modul “Islandora” miteinander verbunden. Einer der wichtigsten Vorteile, die diese Synthese hat, ist, dass das Drupal-User-Management (d.h. die Verwaltung von Usern und User-Rollen) in Fedora verwendet werden kann.

[Edit]Autorisierung mit XACML Policies

1. Die Autorisierung via FeSL basiert auf XACML Policies.
2. XACML Policies sind grob gesagt XML Dokumente, in denen einige Sachverhalte beschrieben werden die darüber entscheiden, wer worauf welchen Zugang hat.

[Edit]Objektbezogene und Repositoryweite XACML-Policies

1. Policies können repositoryweit gelten, müssen dann allerdings im Ordner //src/fedora/data/fedora-xacml-policies/repository-policies/default gespeichert werden (der Ordner kann in fedora.fcfg geändert werden. Die dort bereits vorhandenen Policies sind die Fedora-Standardsicherheitseinstellungen die Api-M streng reglementieren und Api-A weitgehend öffentlich zugänglich lassen. Diese Einstellungen können sowohl gelöscht oder in den Policies editiert als auch durch weitere ergänzt werden).
2. Objektbezogene Policies werden an die jeweiligen DataObjects angehängt. Der Datastream muss in jedem Fall POLICY heißen.

[Edit] Lösungen zu typischen Problemen

[Edit]Troubleshooting

[Edit]Policy Blocked Datastream

Sollte beim Ingest dieser Fehler auftreten, so liegt es mutmaßlich an der Policy deny-unallowed-file-resolution.xml die angepasst werden muss. Anpassen heißt: Die kommentierte Permit-Stelle entkommentieren und das Wort Deny in Permit ändern. Um keine unnötige Sicherheitslücke entstehen zu lassen kann man die Policy nun entweder anpassen oder wieder zurück auf Deny setzen.

Fedora Dokumentation (http://fedora-commons.org/documentation/3.3/17301537.html)

[Edit]Drupal Whitescreen of Death

Um Drupal wieder zum Laufen zu kriegen (Fehler = Whitescreen of Death WSOD!), wurde zunächst die Fehleranzeige eingeschaltet. Dazu wird in die Datei //srv/www/htdocs/drupal-6.22/index.php folgendes in Zeile 2 kopiert (später muss es auch wieder gelöscht werden!):

error_reporting(E_ALL); ini_set('display_errors', TRUE); ini_set('display_startup_errors', TRUE); // $Id: index.php,v 1.94 2007/12/26...

Ab jetzt zeigt der WSOD die entsprechenden Fehler an. Sollte das nicht klappen, auch sonst, ist ein Blick in die Logs in //var/logs/apache2 ratsam. Letztlich hat in dem Fall nur eine Neuinstallation von Drupal geholfen (also nicht von scratch, sondern über die Weboberfläche). Danach waren tatsächlich alle Fehlermeldungen weg, was leider der Funktionalität nicht geholfen hat.

Wie man aus MySQL die gehashten Passwörter bekommt:

> mysql -u root -p > Standardpasswort > use fedora3; > select * from users;

Last changed: 29.11.2012 16:11 (CID: 1166) by Daniel Stein -