Die entsprechende Präsentation finden Sie auf dem EDOC-Server der Berlin-Brandenburgische Akademie der Wissenschaften, der Tagungsbericht von Tillmann Tegeler wurde über H-Soz-u-Kult veröffentlicht.

Die Entwicklung des Frameworks für die Fachinformations- und
kommunikationsdienste von H-Soz-u-Kult, Clio-online und weiteren Partnern basiert
auf einem Datenmodell mit standardisierten Schnittstellen und Formaten. Daten
und Beiträge werden in einem JAVA-basierten Framework so aufbereitet, dass sie
in Linked Open Data–Strukturen für Wissenschaft und Öffentlichkeit zur Verfügung stehen werden. Die Implementierung des HFN-Frameworks stützt sich dabei auf ein Datenmodell, welches Aspekte der Bibliothekswelt, der elektronischen Fachinformation- und kommunikation sowie des elektronischen Publizierens vereinigt.

Das Datenmodell des HFN basiert auf fünf Entitätengruppen –
Beiträge, Artikel oder Dokumente (verschiedene Arten von Text-, Bild-,
Videodaten), bibliografische Datensätze, Personen- und Organisationsdaten sowie
Ereignisse. Aus diesen Grundentitäten lassen sich die bisherigen Beitragsformate
zusammensetzen und beliebig um neue Entitäten oder Dokumenttypen erweitern. Die
Implementierung des Datenmodells wurde zu Beginn des Projekts in verschiedenen Repositoriensystemen getestet. Hierbei haben sich Grenzen hinsichtlich Skalierbarkeit und Erweiterbarkeit in unterschiedlichen Systemen gezeigt. [1]

Die Wahl fiel letztlich auf das teils kommerziell vertriebene Open-Source-Dokumentenmanagement System Alfresco, welches auch in einer freien Community-Edition verfügbar ist und mittlerweile viele Content-Management-Funktionen sowie freie Erweiterungen enthält. Alfresco stellt gängige Schnittstellen für den Datenaustausch bereit, die auf eigene Dienste angewendet werden können, zugleich lassen sich sehr flexibel eigene Datenmodelle bzw. Datenstrukturen implementieren. Das Dokumentenmanagementsystem weist umfängliche Anreicherungsfunktionen mittels Metadaten auf, so dass sowohl klassische Dokumententypen aus Text- oder Bildverarbeitung verwaltet und publiziert, gleichermaßen aber auch eigene Typen implementiert werden können. Neben den klassischen  Dokumentenmanagementfunktionen können eigene Renderer für die Ausgabe in HTML, PDF u.a.m. implementiert oder Schnittstellen (REST, CMIS) angebracht bzw. genutzt werden.

Folder, Files und FRBR

Im Kern stellt Alfresco Folder und Files (Content-Typen) für das Dokumentenmanagement bereit, wie es aus der grundsätzlichen Organisation von Dateien
bekannt ist. Dieses Folder-Files-Modell wird vom HFN genutzt, in dem Folder als
Ablagemappen und Content-Typen als eigentliche Objekte für die Speicherung von
Beiträgen eingesetzt werden. Darauf setzt ein FRBR-isiertes Datenmodell [2] auf, in
dem über Vererbung und gemischte Datentypen die jeweiligen Entitäten definiert sind: Dies können bibliografische Einheiten (Beiträge, Publikationen bzw. reine Metadatensätze), Authorities (Personen, Organisationen) sowie Ereignisse
sein, die nicht nur abgebildet, sondern auch miteinander in Bezug gesetzt werden können.

Personen, Organisationen und Werke werden als Folder und mittels verschiedener Ontologien und Vokabularien im Datenmodell abgebildet.

Die Metadaten der Objekte (Types) werden in einer XML-Datei definiert; hierbei wird teilweise das Resource Description Framework RDA [3] genutzt.

Gleichermaßen werden die eigentlichen Content-Objekte abgebildet, die wiederum über Vererbung in eine Objekthierarchie gebracht werden können (manifestation -> book; manifestation -> review). Jeder Beitrag wird ebenfalls als Dokument bzw. als ein Content-Type in der XML-Deklaration des Datenmodells notiert und mit Eigenschaften (Properties) mittels Alfresco-Datentypen (d:text) und weiteren optionalen Parametern von
Alfresco versehen (multiple für Mehrfachwerte).

Als hilfreich erweist sich die Möglichkeit von Alfresco, beliebige Vokabulare für Datentypen gemischt nutzen zu können: So werden für die Modellierung eines Beitrags (Manifestation) unter anderem Teile von RDA sowie des MODS und BIBO-Vokabulars genutzt.

Mittels sogenannter Aspects, die in Alfresco dynamisch zum Anbringen weiterer Eigenschaften an Objekte oder aber auch zur Herstellung von Relationen mittels Associations genutzt werden können, sind die Beziehungen zwischen den einzelnen Entitätentypen definiert – hier die Zugehörigkeit einer Rezension zum rezensierten Werk (reviewOf). Diese Relationen könnten auch direkt in den eigentlichen Datentypen in Alfresco angebracht werden, allerdings lassen sich die Relationen in Alfresco über die CMIS-Schnittstelle einfacher in JAVA ansprechen.

Über das Folder-Files-Modell sowie die Anwendung von FRBR, RDA usw. lassen sich somit innerhalb eines Alfresco-Folder (=Work) unterschiedliche Versionen und Varianten einer Werksumsetzung als Content-Objekt (=Manifestation) umsetzen, mittels Aspects und Relationen entsprechende Beziehungen zwischen den Entitäten implementieren.

Nach diesem Grundmodell wurden alle Beitragsformate von Clio-online und H-Soz-u-Kult im Datenmodell abgebildet und so erweitert, dass beliebige Entitäten miteinander in Beziehung gesetzt werden können.

Für die Rezensionen, die über die Suchmaschine Historische Rezensionen Online (HRO) unter http://hro.clio-online.de recherchierbar sind, wurde das Datenmodell bereits prototypisch implementiert (ein Publikationsdatensatz – im Modell frbr:work/bibo:book – kann dabei jederzeit um weitere neue Rezensionen – rev:review/clio:review – erweitert werden; denkbar ist sogar die Erweiterung durch mehrere Versionen einer Rezension mittels weiterer clio:review-Typen in einem rev:review-Folder). Die Suchoberfläche von HRO besteht aus einem einfachen SOLR-Client [4], der auf einen separaten SOLR-Server des HFN (nicht den Alfresco-SOLR-Server!) zugreift. Die einfache php-Implementation dieses Clients lässt sich wiederum in gängige Content-Management-Systeme auf PHP-Basis integrieren.

Derzeit werden in JAVA verschiedene Module des HFN-Framework entwickelt, welche die Ein- und Ausgabe über die Alfresco-eigene CMIS-Schnittstelle implementieren. Ziel dieser Module ist die vollständige Kapselung der CMIS-Zugriffe bzw.  Schnittstellenkommunikation, so dass die nur noch über Model-View-Controller die Ein- und Ausgabe via Formulare und Webseiten bereitzustellen ist, ohne sich intern um die Kommunikation mit der Datenbank bzw. auf der CMIS-Schnittstellenebene befassen zu müssen. Durch die Entkopplung von Datenbank und Anwendung lässt sich das Modell neben projekteigenen Vorhaben zukünftig in weiteren Projekten mit externen Partnern zur Integration weiterer Datentypen und Anwendungen, so z.B. zur Integration von Forschungsprimärdaten, nutzen: Das Datenmodell muss nur noch in den Alfresco-eigenen XML-Deklarationen um neue Datentypen erweitert werden, in den JAVA-Modulen sind entsprechend die Datentypen zu kapseln. Besonders interessant dürften in diesem Zusammenhang neue Anwendungen werden, die vorhandene Publikationen aus dem Umfeld von Clio-online und H-Soz-u-Kult einerseits und weiteren, digitalen Quellensammlungen und Forschungsprimärdaten andererseits zusammenführen bzw.
verknüpfen.

Anmerkungen:

[1] Zum Vergleich verschiedener Repositorien und no-sql-Datenbanken siehe den zweiteiligen Blog-Beitrag unter <http://www2.hu-berlin.de/historisches-forschungsnetz/2012/03/jcr-repositorien-und-nosql-datenbanken/> (10.07.2013).

[2] Näheres zur FRBR-Spezifikation siehe die Seiten der International Federation of Library Associations and Institutions (IFLA) <http://www.ifla.org/publications/functional-requirements-for-bibliographic-records> (10.07.2013).

[3] Zur Umsetzung von RDA in Deutschland vgl. <http://www.dnb.de/DE/Standardisierung/International/rda.html> (10.07.2013).

[4] Das PHP-Solr-Framework Solarium ist zu finden unter <http://www.solarium-project.org/> (10.07.2013).

]]> https://www2.hu-berlin.de/historisches-forschungsnetz/2013/07/folder-files-und-frbr-datenmodellierung-fur-dokumente-und-metadaten/feed/ 0 https://www2.hu-berlin.de/historisches-forschungsnetz/2012/08/ubersicht-xml-doctypes-fur-historisches-forschungsnetz/ https://www2.hu-berlin.de/historisches-forschungsnetz/2012/08/ubersicht-xml-doctypes-fur-historisches-forschungsnetz/#respond Wed, 29 Aug 2012 15:17:33 +0000 http://www2.hu-berlin.de/historisches-forschungsnetz/?p=110 Weiterlesen →]]> Einführung

„NLM, DocBook, TEI Lite, and DITA are all robust XML standards that can serve as great starting points for a painless conversion of your content to whatever e-book format you need.” http://www.dclab.com/blog/2010/09/future-proofing-your-e-books/

• TEI: The “Let One Thousand Flowers Bloom” DTD
• DocBook: The “Crank It Out” DTD . . .
• NLM: The “Works and PlaysWell Together” DTD . . .
• DTBook: The most important DTDpeople have neverheard of . . .
• DITA: The “Slice & Dice” DTD . . .

http://assets.en.oreilly.com/1/event/19/XML%20in%20Practice_%20Formats,
%20Tools,%20and%20Techniques%20Presentation%203.pdf

Vergleich der relevanten Doctypes

TEI (Lite)

http://www.tei-c.org/Guidelines/Customization/Lite/

Dokumentstruktur:

<TEI>
  <teiHeader/>
  <text>
   <front/>
   <body/>
   <back/>
  </text>
 </TEI>

Gliederung: <div type=“chapter“ n=“38″><head>Titel des Abschnitts</head>
<p>…</p></div>

Fußnote: <p>Text mit Fußnote<note place=“foot“>Eine erste Fußnote</note> … </p>

Formatierung: <hi rend=“bold“></hi> (bzw. <emph>bold</emph>) <hi rend=“italic“>kursiv</hi>

Eingebettete Grafik mit Titel und Bildunterschrift:<figure><graphic url=“fessipic.png“/><head>MrFezziwig’s Ball</head><figDesc>A Cruikshank engraving showing MrFezziwig leading a group of revellers.</figDesc></figure>

(Simplified) DocBook

http://www.docbook.org/xml/simple/sdocbook/index.html

Bsp. von http://www.informatik.tu-cottbus.de/~agiurca/tutorials/DocBook/index.htm

Dokumentstruktur:

<article>
 <title>Artikeltitel</title>
 <articleinfo><!—Artikelinfo --></articleinfo>
 <section><title>Titel des Abschnitts</title><para>..</para></section>
</article>

Gliederung: <sectionlabel=“1″><title>Titel des Abschnitts</title><para>..</para></section>

Fußnote: <para>Text mit Fußnote <footnote><para>Eine erste Fußnote</para></footnote></para>

Formatierung: <emphasis role=“strong“>fett</emphasis>, <emphasis>kursiv</emphasis>

Eingebettete Grafik mit Bildunterschrift:
<figure><title>A geometrical figure</title><mediaobject><imageobject><imagedatafileref=“eiffeltower.png“ format=“PNG“/></imageobject>

<caption><para>Designed by Gustave Eiffel in 1889, The Eiffel Tower is one of the most widely recognized buildings in the world.</para></caption></mediaobject></figure>

 NLM

Beispiele unter http://www.ncbi.nlm.nih.gov/pmc/pmcdoc/tagging-guidelines/article/style.html#samples

Dokumentstruktur:

<article>
<front />
<body />
<back />
</article>

Gliederung: <sec id=“sec.id“><title>Abschnitts-Titel</title><p>…</p></sec>

Fußnoten[1]:<body><p>…<xref ref-type=“fn“ rid=“FN1″>1</xref>… </p>…</body>
<back>…<fn-group><fn id=“FN1″><label>1</label><p>ErsteAnmerkungen</p></fn>…</fn-group>…</back>

Formatierung: <bold>fett</bold>, <italic>kursiv</italic>

Eingebettete Grafik mit Bildunterschrift:
<fig id=“id-figure“><label>1</label><caption><title>Bildtitel</title><p>Bildbeschreibung</p></caption>
<graphicxmlns:xlink=“http://www.w3.org/1999/xlink“ xlink:href=“ch4f1″ mime-subtype=“gif“/>
</fig>

DTBook

Dokumentstruktur:

<dtbookxmlns="http://www.daisy.org/z3986/2005/dtbook/" 
  version="2005-3" xml:lang="de-DE">
 <head><!-- Dublin Core Metadaten -></head>
 <book>
 <frontmatter>
 <doctitle>Titel</doctitle>
 <docauthor>Ersteller</docauthor>
 </frontmatter>
 <bodymatter>…
 </bodymatter>
 </book>
 </dtbook>

Gliederung:

<level1><h1>Abschnittstitel</h1>
<p>…</p>
<level2><h2>Untertitel</h2>
<p>..</p>
</level2>
</level1>

Fußnote[2]: <p>und eine Fußnote<noterefidref=“#ftn1″ class=“footnote“>1</noteref>. …</p>
..
<note id=“ftn1″ class=“footnote“><p>ErsteFußnote</p></note>

Formatierung:<strong>fett</strong>, <em>kursiv</em>

Eingebettete Grafik mit Bildunterschrift:<imggroupid=“imggrp_1″><imgid=“img1_1″ src=“pic.png“ alt=“1. Bild: Mit einer Beschreibung“ /><caption><strong>1. Bild</strong> Mit einer Beschreibung</caption></imggroup>

Fazit

Insgesamt sind die Unterschiede für die grundlegenden Dokument- und Textauszeichnungen zwischen den vier hier betrachteten Doctypes recht marginal. Für eine reine Zeitschriftenplattform wie Ambra[3] bietet sich NLM durch die optimal auf wissenschaftliche Aufsätze abgestimmte Dokumentstruktur an. Da im Rahmen des Forschungsnetzes neben Aufsätzen insbesondere im Rahmen der Themenportale aber auch historische Quellen mit besonderen Anforderungen an Texttranskriptionen zu erwarten sind und in den historisch arbeitenden Geisteswissenschaften TEI immer noch die mit Abstand größte Verbreitung hat, scheint TEI für uns im Moment aber die die sicherere Wahl zu sein. Sollte sich in der Zukunft beispielsweise durch bessere Unterstützung von Browser-basierten Editoren mit NLM oder gegebenenfalls auch Docbook-Unterstützung Veränderungen ergeben oder Verlagsplattformen für Ihre Angebote NLM oder DTBook-basierte E-Book-Formate bevorzugen, sollten entsprechende Transformationen durch Stylesheets wie etwatei_to_nlm.xsloder tei-to-epub3.xsl ohne allzu große Schwierigkeiten umzusetzen zu sein.

Anhang

beispiel-teilite.xml

<?xmlversion="1.0" encoding="UTF-8"?>
<TEI>
     <teiHeader>
          <fileDesc>
                <titleStmt>
                     <title>Beispiel: TEI (Lite)</title>
                </titleStmt>
                <publicationStmt>
                     <publisher/>
                </publicationStmt>
                <sourceDesc><p/></sourceDesc>
          </fileDesc>
     </teiHeader>
     <text>
          <front/>
          <body>
              <div type="article"><head>Titel des Beitrages</head>
              <p>Etwas <hi rend="bold">fetter</hi> bzw. 
              <hi rend="italic">kursiver</hi> Text mit 
              Fußnote<noteplace="foot">Eine erste Fußnote</note>.</p>
              <div type="section"><head>Anhang</head>
              <figure><graphic url="pic.png"/><head>1. Bild</head>
              <figDesc>Mit einer Beschreibung</figDesc></figure>
              </div>
              </div>
          </body>
          <back/>
     </text>
</TEI>

beispiel-simplified-docbook.xml

<?xmlversion="1.0" encoding="UTF-8"?>
<article lang="de">
     <title>Beispiel: Simplified Docbook</title>

     <para>Etwas<emphasis role="strong">fetter</emphasis>
     bzw. <emphasis>kursiver</emphasis> Text mit Fußnote<footnote>
     <para>Eine ersteFußnote</para></footnote>.</para>
     <section><title>Anhang</title>
     <figure><title>1. Bild</title>
          <mediaobject>
              <imageobject><imagedatafileref="pic.png" format="PNG"/></imageobject>
              <caption><para>MiteinerBeschreibung</para></caption>
          </mediaobject>
     </figure>
   </section>
</article>

beispiel-nlm-article.xml

<?xml version="1.0" encoding="UTF-8"?>
<article xmlns:xlink="http://www.w3.org/1999/xlink" 
         article-type="research-article">
<front>
     <journal-meta>
          <journal-id>HSK</journal-id>
          <issn pub-type="epub"><!--1234-5678--></issn>
     </journal-meta>
     <article-meta>
          <article-id>hsk:1234</article-id>
          <title-group>
                <article-title>Beispiel: NLM Article</article-title>
          </title-group>
          <pub-date pub-type="epub">
                <day>5</day>
                <month>5</month>
                <year>2012</year>
          </pub-date>
     </article-meta>
</front>
<body>
     <p>Etwas<bold>fetter</bold>bzw. <italic>kursiver</italic> 
     Text mit Fußnote<xref ref-type="fn" rid="FN1">1</xref>.</p>
     <sec><title>Anhang</title>
     <fig id="id-figure"><label>Abbildung 1</label><caption><title>1. Bild</title><p>Mit einer Beschreibung</p></caption>
          <graphicxmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="pic.png" mime-subtype="png"/>
     </fig>
     </sec>
</body>
<back>
     <fn-group>
          <fnid="FN1"><label>1</label><p>Eine erste Fußnote</p></fn>
     </fn-group>
</back>
</article>

beispiel-dtbook.xml

<?xmlversion="1.0" encoding="UTF-8"?>
<dtbookxmlns="http://www.daisy.org/z3986/2005/dtbook/" version="2005-2" xml:lang="de-DE">
<head>
<meta name="dc:Language" content="de-DE"/>
<meta name="dc:Title" content="Beispiel: dtbook"/>
</head>
<book>
<frontmatter>
  <doctitle>Beispiel: dtbook</doctitle>
</frontmatter>
<bodymatter>
<level1>
<p>Etwas <strong>fetter</strong> bzw.<em>kursiver</em> Text mitFußnote<noterefidref="#ftn1" class="footnote">1</noteref></p>
<level2>
                     <h2>Anhang</h2>
                     <imggroup id="imggrp_1">
                          <imgid="img1_1" src="pic.png" alt="1. Bild: Mit einer Beschreibung" />
                          <caption><strong>1. Bild</strong> Mit einer Beschreibung</caption>
                     </imggroup>
</level2>
                <note id="ftn1">
                     <p>Eine erste Fußnote</p>
</note>
</level1>
</bodymatter>
</book>
</dtbook>

Bericht Teil 2: Fedora Commons, Nuxeo und Alfresco.

Fedora Commons

Nachdem in den Tests der JCR-Repositories sich Performanzprobleme bei mehreren tausend Dokumenten pro Ordnerebene einstellten, wurde die Verwendung von Fedora Commons geprüft. Fedora Commons hat im akademischen Umfeld in den USA, in Großbritannien und Deutschland derzeit eine relativ weite Verbreitung gefunden. In der Fedora-Umgebung stehen bisher einfache APIs und Werkzeuge für das Einfügen und Auslesen von Objekten zur Verfügung, die nach den Prinzipien von RESTful-Services arbeiten[i]. Mit den eSciDoc-Umgebungen der MPIs und des FIZ Karlsruhe stehen grundlegende Anwendungen für die Verwaltung bibliographischer Metadaten, Bilder und Volltexte zur Verfügung, allerdings werden keinerlei Workflowkomponenten oder übergreifende Schnittstellenstandards wie CMIS, die die Integration beliebiger CMS ermöglichen, angeboten.

Für den Test wurde der gleiche Datenbestand aus der Suchmaschine Historische Rezensionen Online für Fedora Commons aufbereitet: Die bisherigen Datenstrukturen wurden anhand des im ersten Projekthalbjahr entwickelten Datenmodells entsprechend in FOXML-Objekte umgewandelt und mit den Fedora Commons-eigenen Schnittstellen und Einfügewerkzeugen in ein Fedora-Repositorium eingespielt. Kleinere Datenmengen (bis ca. 20.000 Publikationsdatensätze sowie bis zu ca. 35.000 Rezensionsdatensätze) konnten ohne weitere Performanzverluste übernommen werden. Größere Datenmengen ab mehr als 50.000 Volltext-Objekten jedoch brachten auch bei Fedora Commons ähnliche Performanzprobleme zutage: Sowohl Einfügeoperationen, als auch Änderungen und Löschungen von Objekten in größerem Umfang führten zu auffälligen Performanzeinbußen. Auch die Adaption von Leistungsparametern (z.B. Einstellung von Speicherverfügbarkeit für die Programmumgebung / JAVA-OPTs) führten zu keiner signifikanten Verbesserung der Performanz.

Weitere Performanzverbesserungen sollten durch die Trennung von Datenbank und Anwendung erreicht werden: In einer weiteren Installation von Fedora Commons wurde die zugrundeliegende Datenbank in eine externe Postgresql-Datenbank ausgelagert. Die Einfügetests bzw. Migration der aufbereiteten Rezensionsdaten in diese Installationen erwiesen sich im Vergleich zu den vorangegangenen Tests (auf einer Fedora Commons-Standardinstallation mit integrierter Derby-Datenbank) als noch weniger performant: Von den insgesamt 80.000 Rezensionen incl. Publikationsdatensätzen waren nach 12 Stunden Testlauf gerade einmal 25% der Daten eingefügt. Die in den Tests des FIZ-Karlsruhe nachgewiesenen Performanzwerte konnten mit den Beitragsformaten von Clio-online und H-Soz-Kult und Fedora-eigenen Einfügetools leider nicht erreicht werden.[ii]

Aufgrund des nicht überschaubaren Risikos von Performanzproblemen wurden im Anschluss an die Tests von Fedora Commons die in die Auswahl einbezogenen Systeme Nuxeo und  Alfresco auf ihre Eigenschaften hinsichtlich der Projektanforderungen und teils auf ihre Performanz bei der Einfügung von Massendaten getestet.

Nuxeo

Das Dokumenten-Management-System Nuxeo stellt die als Voraussetzung für das Projektvorhaben gestellten Anforderungen bzw. Funktionalitäten zur Verfügung (siehe Tabelle im Anhang), insbesondere verfügt es über eine CMIS-Schnittstelle für die Vernetzung mit weiteren Datenspeichern und Umgebungen.[iii] Allerdings handelt es sich hierbei um ein System aus Frankreich, das fast ausschließlich dort und bisher kaum im deutschsprachigen Raum eingesetzt wird. Auch die internationale Verbreitung von Nuxeo ist stark auf die USA beschränkt. Wegen zu erwartender Supportprobleme (Dependancen ausschließlich in Frankreich und den USA) und einiger technischer Einschränkungen wurde vom Test bzw. Einsatz von Nuxeo abgesehen.

Alfresco

Bereits vor dem Projektstart wurden am Bereich Historische Fachinformatik in einer internen Evaluierung zwei der führenden CMS-Systeme, Sharepoint und Alfresco, hinsichtlich ihrer Einsatzmöglichkeiten in den Fachinformationsdiensten und darüber hinaus in den Institutsdiensten des IfG anhand einfacher Testinstallationen evaluiert. In internen Projekten wurde Sharepoint am Bereich Historische Fachinformatik bereits seit 2007 gelegentlich eingesetzt. Sharepoint ist als proprietäres Produkt von Microsoft allerdings eng an die Produkte und Technologien von Microsoft (Datenbankserver MS-SQL, Betriebssystem Windows Server) gebunden und somit nicht plattformübergreifend nutzbar. Alfresco dagegen wird als quelloffene, frei verfügbare Community-Edition vertrieben, die datenbank- und plattformunabhängig ein Repository für Metadaten und Inhalte bereitstellt, einschließlich generischer Funktionalitäten und standardisierter Schnittstellen (neben einer kostenpflichtigen Version).

Aufgrund der vielfältigen Performanzprobleme beim Massendatenimport und nachträglichen Änderungen von Daten in Jackrabbit, ModeShape, Fedora und den möglichen Risiken des Einsatzes von MongoDB und Nuxeo einerseits und der fortgeschrittenen Projektentwicklung andererseits wurden die Daten von Clio-online und H-Soz-Kult mit Hilfe der bereits entwickelten Programmbibliotheken in ein Alfresco-System migriert. Die damit verbundenen Tests des Massendatenimports waren erfolgreich, innerhalb von drei Stunden konnten z.B. mehr als 50.000 Rezensionen einschließlich der Publikationsdatensätze der Suchmaschine Historische Rezension Online übertragen werden. Diese Tests wurden zur Absicherung der Ergebnisse mehrfach wiederholt. In einem umfassenden Testlauf wurden nahezu sämtliche Daten der Projekte Clio-online und H-Soz-Kult in eine Alfresco-Standard-Installation migriert.

Zusätzlich wurden detaillierte Lasttests der im Alfresco-CMS bereits vorhandenen generischen Bearbeitungs- und Rechercheformulare und der integrierten Schnittstellen (interne Alfresco-API, CMIS-REST-API) durchgeführt, um die Performanz nicht nur der Datenimporte, sondern auch des Betriebs an sich zur untersuchen. Dazu wurden erste Workflows und Bearbeitungsfunktionalitäten für Redaktion und zukünftige Nutzer der Beitragen-Bereiche im System implementiert und ebenfalls in die Tests eingeschlossen. Diese Implementationen und Tests konnten so gestaltet werden, dass sowohl bereits entwickelte Datenmodelle, als auch bereits ausprogrammierte Schnittstellen und Programmbibliotheken integriert werden können.

Exkurs: Projekt Bamboo

Weitere internationale Projekte im Umfeld der „Virtuellen Forschungsumgebungen“ befassen sich mit den gleichen Fragen und Problemen, wie das vorliegende Projekt, insbesondere mit den Möglichkeiten der Vernetzung unterschiedlicher Repositories über Standardschnittstellen wie CMIS und die Integration von Fedora Commons als eines der zentralen Repositoriensysteme im akademischen Umfeld. So entwickelt das Project Bamboo[iv] seit mehreren Jahren Basisdienste und Werkzeuge für Virtuelle Forschungsumgebungen.

Während der ersten Projektphase stellte Bamboo Forschungsumgebungen auf Basis von Alfresco und HUBzero.[v] HUBzero ist eine Webplattform, über die Websites und Materialien aus/für Lehre und Forschung an amerikanischen Universitäten entwickelt und publiziert werden können.[vi] Des Weiteren wurden im Projekt Möglichkeiten diskutiert, wie Alfresco, Fedora Commons und die projekteigenen Entwicklungen miteinander vernetzt werden können. Die Entscheidung zur technologischen Unterstützung einer solchen Vernetzung wurde im vergangenen Jahr getroffen und wird derzeit umgesetzt: Auf Basis des CMIS-Protokolls werden Server- und Client-Komponenten für die Integration der genannten Systeme entwickelt. Im Rahmen dieser Entwicklung sind bereits Datenmodelle entstanden, die das Mapping von Objekten der genannten Content Repositories ermöglichen[vii]. Derzeit steht die Unterstützung von Authentifizierung und Autorisierung im Mittelpunkt der Programmentwicklung[viii]. Darüber hinaus entwickelt das Projekt „Social Communities“ bzw. kollaborative Arbeitsgruppenplattformen auf Basis von Open Social, die in die Gesamtumgebung des Projekts integriert werden.[ix]

Fazit

Der Vergleich der Systeme Jackrabbit, Fedora Commons, Alfresco sowie zweier weiterer derzeit am Markt befindliche Repository-basierter Content-Management-Systeme zeigte eklatante Unterschiede zwischen den Systemen beim Massendatenimport, darüber hinaus auch bei normalen Operationen wie Einfügen neuer oder Änderungen vorhandener Dokumente. Das System Alfresco konnte in einer Standardinstallation ohne weitere administrative Anpassungen mit den zu bewältigenden Datenmengen weitaus performanter umgehen, als Jackrabbit und Fedora Commons.

Das System Alfresco bietet neben seiner Performanz bereits die standardisierten Schnittstellen (REST, CMIS), über die z.B. externe Arbeitsgruppen und deren Redaktionsumgebungen angebunden werden können. Zudem verfügt Alfresco über die Anbindung gängiger Authentifizierungsmechanismen, über generische Bearbeitungs-, Veröffentlichungs- und Recherchefunktionen, die ad hoc auf den importierten Datenbeständen genutzt werden können. Die Programmierung eigener Funktionalitäten innerhalb Alfrescos ist in gängigen plattformunabhängigen Sprachen (JAVA, JavaScript) in modularen Architekturen (MVC, Spring Beans) möglich.

Teil 1: JCR-Repositorien und NoSQL-Datenbanken.

Die langfristig wichtigste Entscheidung für den Aufbau eines Redaktionssystems, wie auch sonst bei jeder datenbankbasierten Software, ist die Frage nach der Datenhaltung. Im Projekt Historisches Forschungsnetz wurden verschiedene Möglichkeiten der Datenhaltung in relationalen Datenbank und sogenannten Content Repositories evaluiert. Grundsätzlich kommen beide Datenspeicher in Kombinationen mit einem Dateisystem für das Ablegen von Binärdaten (Bild, Ton, Film) in Frage. Aber auch dokumentorientierte NoSQL-Datenbanken können in Betracht gezogen werden.[1]

Die bisherigen Lösungen für die Fachinformationsdienste Clio-online und H-Soz-u-Kult basieren auf relationalen Datenbanken. Diese haben bis heute eine sehr breite Verbreitung gefunden, auch auf einfachen shared Web-Host Accounts kommerzieller Hostingprovider; zudem existieren zahlreiche Konnektoren zwischen Datenbanken und Programmiersprachen. Hauptnachteil ist die ad-hoc Modellierung von Dateisystemstruktur sowie Funktionen zur Versionierung der Datenbankinhalte, für die sich keine allgemeinen Konventionen etablieren konnten. Damit wird jede Implementation in einem gewissen Sinn zu einer Insellösung.[2]

Relationale Datenbankmanagementsysteme

Hier stehen die bekannten proprietären (Microsoft SQL, Oracle) bzw. Open Source Datenbanken (MySQL, Postgresql) im Vordergrund. Alle diese Systeme haben sich über die letzten beiden Jahrzehnte in vielen Anwendungsbereichen mit großen Datenbeständen und einer hohen Zahl paralleler Anfragen bewährt. Alle Produkte unterstützen sowohl Replikation als auch Hot-Backups und bieten Treiber für alle gängigen Programmiersprachen, so dass die Entscheidung primär gemäß den Lizenzbedingungen sowie individuellen Präferenzen und weniger aufgrund der spezifischen Eignung für die konkreten Projektanforderungen gefällt werden kann. Hauptnachteil von SQL-Datenbanken sind die Funktionen zur Modellierung und Versionierung der Datenbankinhalte, für die sich bislang keine allgemeinen Konventionen etablieren konnten.[3] Damit wird jede konkrete Implementation unabhängig von der Wahl des konkreten RDMS in einem gewissen Sinn zu einer Insellösung.

Content Repository

Die Definition eines Content Repository ist unschärfer.[4] Zusätzlich zur Speicherung und Abfrage von strukturierten und unstrukturierten Dokumenten bieten viele Content Repositories ein Zugriffsmanagement (Access Control) sowie zur Versionierung der Inhalte; Funktionen, die beim Einsatz eines RDMS typischerweise im Data Access Layer erfolgen.

Bei den Content Repository haben neben der einzig in Python-Umgebungen verbreiteten Zope Object Database[5] vor allem Java-Lösungen Verbreitung gefunden. Einerseits gibt es eine Reihe von Systemen, die die Content Repository API for Java (JCR) umsetzen.[6] Der Anwendungsbereich wird in der Einleitung zum JSR-283[7] folgendermaßen beschrieben:

The JCR specification defines an abstract model and a Java API for data storage and related services commonly used by content-oriented applications. The target domain encompasses not only traditional content management systems but, more broadly, any application that must handle both unstructured digital assets and structured or semi-structured information.

The repository model enables efficient access to both large binary objects and finely-structured hierarchical data through a simple, generic API and a robust and extensible object typing system. Additionally, many features that are traditionally custom-built on top of RDBMSs and file systems have been incorporated into the repository itself. These include support for query, access control, versioning, locking and observation. Standardized support for these services further enables applications that might not normally have access to such advanced features to take advantage of them, since they are built-in at the infrastructure level.

In den letzten beiden Jahren sind eine Reihe von System dazugekommen, die entweder in Ergänzung zu JCR oder als primäre Schnittstelle als CMIS-Server fungieren.[8] Aufgrund der quelloffenen Community Edition stand für uns das Alfresco 4.x CMIS Content Repository im Vordergrund; kommerzielle Implementierungen umfassen u.a. Microsoft Sharepoint sowie EMC Opentext. Neben den JCR bzw. CMIS-basierten Systemen hat im akademischen Bereich Fedora Commons in verschiedenen e-Library und e-Science Projekten wie Ambra[9] und eSciDoc[10] Verbreitung gefunden.

Im Projekt Historisches Forschungnetz wurde ein Teil der genannten Datenbanken und Repositorien hinsichtlich verschiedener Eigenschaften evaluiert und getestet. Zu Beginn der Evaluation sprachen eine Reihe von Argumenten für den Zugriff über die JCR-Schnittstelle gegenüber einer direkten Anbindung von Fedora Commons, da parallel zu den JCR-Repositories Jackrabbit und ModeShape getestet wurde:

• Standardisierte Schnittstelle: JCR ist durch zwei im Rahmen des Java Community Prozess entstandene Spezifikationen festgelegt.[11] Fedora Repository bietet Web-Service Schnittstellen, die sich aber zwischen den verschiedenen Versionen ändern können.[12]
• Mehrere frei verfügbare und kommerzielle Implementationen.[13] Dadurch schien die dauerhafte Pflege und Weiterentwicklung von JCR Repository besser abgesichert, als bei Fedora Commons, dessen Weiterentwicklung im Rahmen der Duraspace Foundation primär von Projektförderungen abhängig ist und sich auf eine relativ kleine Kerngruppe von Programmierern stützt.[14]
• Über das im Rahmen des Apache Chemistry Projektes entwickelte OpenCMIS JCR Repository[15] sollte demnächst jedes JCR-kompatible-Repository den CMIS-Standard unterstützen.[16]

Bei der ersten Umsetzung einer Migration der Clio-online Suchmaschine Historische Rezensionen Online mit mehr als 87.000 Rezensionen zu knapp 70.000 Publikationen zeigte sich, dass weder Jackrabbit (in der Version 2.3.x) noch ModeShape (in der Version 2.6.x) mit einer großen Zahl flach strukturierter Knoten umgehen können. Ab ungefähr 1000 Knoten auf einer Hierarchie-Stufe werden die schreibenden Zugriffe sehr langsam. Diese Beschränkungen beim Einfügen lassen sich durch eine „Pseudo-Hierarchie“ (z.B. Gruppierung von Publikationen gemäß ihres ISBN-Prefixes oder einem Hash-Key) zwar teilweise umgehen.[17] Aber auch dann haben einfache Abfragen wie „Gib mir die Zahl der gespeicherten Publikationen“ mit Antwortzeiten im Minutenbereich bei über 50.000 Publikationen die Systemwahl grundsätzlich in Frage gestellt. Bei der Suche nach passenden Lösungen für diese Probleme zeigte sich, dass auch andere Projekte daran letztendlich gescheitert sind.[18] So wurde für das Content Management System Nuxeo unter anderem der Wechsel von einem Content Repository zurück zu einer relationalen Datenbank vorgenommen.[19]

Dass die schlechte Performance bei flachen Strukturen keine inhärente Beschränkung des JCR-Standards, sondern der konkreten Implementierungen ist, will die nächste Version von ModeShape zeigen.[20] Diese liegt zur Zeit aber erst als alpha-Version vor, so dass das Risiko, ob die stabile Release mit diesen Änderungen rechtzeitig erscheint und sowohl bei Speicheropration als auch Abfragen schnell genug für unsere Anforderung ist, sehr hoch ist.

Dokumentorientierte NoSQL-Datenbanken

Eine Zwischenstufe zwischen RDMS und Content Repository bieten Dokument-orientierte Datenbanken  wie MongoDB oder CouchDB. Diese unterstützen teilweise ähnliche Funktionen wie die beiden erwähnten Content-Repositories:

Quelle: http://contentcurmudgeon.wordpress.com/2010/07/12/nosql-and-cms-comparing-nosql-with-cps-requirements/

Einem System wie MongoDB fehlt in der aktuellen Version eingebaute Versionierung und hierarchische Zugriffsrechte. Es bietet aber eine Schema-freie Datenhaltung, d.h. zusätzliche Felder können zu einem Dokumenttyp hinzugefügt werden, ohne dass das Datenbankschema angepasst werden muss bzw. alle Zusatz-Attribute über eine Relation in eine separate Tabelle ausgelagert werden müssen, was zu komplizierten, entsprechend fehlerträchtigen und unter Umständen Performance-kritischen Abfragen führt. Da einzelne Felder nicht wie in einem RDMS skalar sein müssen, sondern wiederum hierarchische Inhalte haben können, kann auch die Versionierung über das Hinzufügen aller früherer Versionen zum aktuellen Datensatz relativ einfach abgebildet werden.[21]

Ob eine NoSQL-Datenbank wie MongoDB überhaupt für die dauerhafte Datenhaltung oder bloß als schneller Cache für die temporäre Datenhaltung geeignet ist, war bis zu den jüngsten Versionen auf Grund der offen eingeräumten Möglichkeit von Datenverlusten bei nicht-replizierten Installationen stark umstritten.[22] Zusammenfassend scheint der Einsatz eines Systems wie MongoDB als Datenspeicher für das historische Forschungsnetz zwar technisch möglich, aufgrund der relativ jungen Architektur aber recht riskant.

Weiter zur Dokumentation von .hist2011

Die Veranstaltungsreihe Digitale Bibliothek dient dem Erfahrungsaustausch, der Koordination und Kooperation zwischen Kultur- und Wissenschaftsseinrichtungen in dem Bereich digitale Bibliotheken.

http://conference.ait.co.at/digbib/index.php/digbib2011/metavok/schedConf/program