Motivation, Gesamtziel

Wenn alle Lernplattformen, Onlineeditoren, Dateispeicherplätze von Usern ihre OER oder anderen Inhalte in ein Bildungsnetzwerk publizieren, entsteht ein riesiges Meer mit Inhalten. Große und kleine Bibliotheksschiffe fischen ihren Bildungsbereich oder ihr Fach- / Berufsbereich Inhalte, verpacken sie onboard in dort vorhandenen Erschließungs- und Kuratierungsfabriken in verdauliche Dosen. Die blauen Fabrikteile auf den Schiffen sind technische Erschließungs- und Kuratierungssysteme. Die roten Boxen symbolisieren Fachredaktionen - hier fischen, bewerten und sortieren erfahrene Fachleute:

In einem Netzwerk wie die Nationale Bildungsplattform kommt also ein “Meer” an Angeboten, Anbietern, Daten, Materialien, Tools u.a. Inhalten zusammen. Die Metadaten dieser Inhalte werden künftig aus unterschiedlichen Perspektiven angefügt werden. Während bspw. eine juristische Redaktion eine Zuordnung zu Rechtsverordnungen benötigt, wollen Redaktionen im Schulbereich Zuordnungen zu Bildungsplänen und Kompetenzzielen.

Selbst ein Metadatenfeld, wie der "Titel" wird in der Praxis unterschiedlich “ausgefüllt”. Lehrende betiteln bei Verwendung eines Materials innerhalb eines Moodle-Kurs bspw. oft ganz anders, als die Autor*in ihren Inhalt benannte. Verschiedene Fachredaktionen fügen jeweils aus ihrer Sicht einen Titel an, der als Ergebnisanzeige ihrer Fachsuchmaschine wirklich prägnant und aussagekräftig ist. In einer übergreifenden Suchmaschine erwartet jede Partei den Inhalt unter dem für sie hilfreichen oder ihr bekannten Titel zu finden. Dafür müssen Nutzerprofil, der Kontext in dem sich die Nutzer*in befindet und ein sehr flexibles Metadatenmodell zusammengebracht werden. Anderenfalls rauben langwierige, frustrierende Suchvorgänge viel Zeit, die viel besser in didaktische Konzepte oder inhaltliche Pläne fließen sollte.

Veraltet sind daher künftig Systeme, die statische Metadatenmodelle implementieren. Nötig sind flexible Modelle, wo Nutzende in Suchmaschinen ihre Benennung und Verschlagwortung aus ihren Kontexten finden. WLO erprobt dafür ein innovatives Metadatenmodell, in dem Inhalte flexibel Informationen zugewiesen werden können, die erst im Zielsystem entsprechend des jeweiligen Profils zugeordnet werden. 

Da zentrale Akteure mutmaßlich große Teile des Metadatensets bearbeiten, erprobt WLO skalierfähige Technologien zur Metadatenverwaltung, worum es in diesem Bereich 2.x geht. Das Ergebnis wird eine Weiterentwicklung der Redaktions- und Contentverwaltungs-Lösung "edu-sharing", die bisher mit semi-flexiblen Metadaten die Verwaltung von mehreren hundertausend Inhalten ermöglicht. Die Software wird Open Source zur Verfügung gestellt und ist für bspw. WirLernenOnline, Fach- und Berufsgesellschaften und inhalteverwaltende Akteure in Bildungsbereichen (z.B. Pädagogische Landeszentren) einsetzbar.

Ist-Stand der bestehenden edu-sharing basierten Technologielösung

Im Schul- und Hochschulbereich sind solche Contentknoten seit über 10 Jahren im Einsatz. Weit verbreitet ist die edu-sharing Open Source Software, die auch für die Weiterentwicklung aktueller POCs verwendet wurde. Aktuell nutzbar ist eine Open Source Software, die als Cloudspeicher für user-generated Content bspw. landeszentral im Einsatz ist.

In einem Hub, auch Referatory oder Repository genannt, fließen Inhalte aus mehreren Quellen zusammen. Diese Quellen sind oft Lernplattformen des Bundeslandes oder vom jeweiligen Betreiber angeschlossene Erschließungsstellen, wie z.B. Sodis/Sodix.

• Die Landes- oder Bereichsredaktion pflegen im eigenen Contentknoten Inhaltebestände für die eigene Zielgruppe und ordnen Bestände bspw. nach Lehr- und Kompetenzplänen und Kollektionen zum aktuellen Tagesgeschehen.
• Lehrende selbst pflegen für ihre Zielgruppen pädagogische Zusammenstellungen.
  • Entweder sind dafür am Contentknoten eine oder mehrere Lernplattformen oder ein Mahara-E-Portfoliosystem oder ein WebCMS, wie Wordpress angeschlossen, in dem die Suche des Contentknotens das Finden, Einbetten und Zusammenstellen pädagogischer Kollektionen oder Abläufe gestatten
  • Oder es werden direkt im Contentknoten persönliche oder gemeinsame Sammlungen erstellt, z.B. für ein Lehrplanthema, für eine Klasse oder eine Teilgruppe mit spezifischen Lernbedürfnissen.
  • Sammlungen werden von Lehrenden auch für die Interaktion mit Schüler:innen genutzt, bspw. als Abgabeort für Hausarbeiten.

Ein solcher Contentknoten muss also sowohl redaktionelle als auch "pädagogische Nutzungszenarien" für den Bildungsalltag ermöglichen. Entsprechend hoch können die Nutzungslastspitzen werden.

Wie kommen Inhalte in einen Contentknoten ?

Am Beispiel von WirLernenOnline (Bild) kommen Bildungsinhalte auf mehreren Wegen in die Contentverwaltung.

1. Quellen werden (links) über Schnittstellen erschlossen
2. Inhalte werden hochgeladen
3. Inhalte werden in der Redaktions- und Nutzungsumgebung mit einem angeschlossenen Editor oder einer Plattform erstellt.

In der Contentverwaltung wirken maschinelle Erschließungs- und Kuratierungsprozesse. Außerdem gibt es eine Redaktionsumgebung, welche eingehende Inhalteströme anzeigt und filterbar macht. Redaktionsmitglieder schalten erschlossene Inhaltemengen für interne Zielgruppen frei. Interne Zielgruppen mein auch für angeschlossene Lern- u.a. Plattformen, in denen Inhalte genutzt und zusammengestellt werden können.

Optional, falls der Contentknoten eine öffentliche Repräsentation hat, können Redaktionsmitglieder oder von Redaktionen berechtigte Nutzendengruppen Inhalte auf die öffentlich zugängliche Suche und Sammlungen veröffentlichen. Einige Contentknoten haben lediglich eine öffentliche Suche und öffentliche Sammlungen. Bspw. WirLernenOnline, Mebis und ### haben darüber hinaus ein Webportal. Bei WirLernenOnline besteht dies neben der Suche aus Fachportalen und Themenseiten. Diese Portalseiten werden i.d.R. in einem WebCMS wie Wordpress gepflegt. In dem WebCMS gibt es ein edu-sharing Plugin / eine Integration. Dadurch können die Webredakteure Sammlungsinhalte oder Ergebnismengen von dynamischen Suchabfragen als redaktionelle Galerien anbieten.

Auf der Ausgabeseite kann der Contentknoten seine Inhalte für andere Contentknoten bereitstellen. Hierfür werden die Metadaten in standardisierter Form bereitgestellt.

Editoren am Repositorium

Im Repositorium sind Editoren verfügbar (z.B. OnlyOffice, H5P, Wordpress, Lernplattformen) verfügbar und weitere integrierbar. Autor*innen erstellen Inhalte und diese gelangen über Schnittstellen in das Repositorium. Dort prüft und erschließt eine Redaktion solche internen Inhalte wie auch externe Quellen. Die Redaktion erstellt Kollektionen / Sammlungen. Die Inhalte sind in der Suchmaschine des Repositoriums in den "Nutzungsumgebungen" verfügbar, z.B. in angeschlossenen Lernplattformen und Editoren. Optional können Autor*innen (falls die Organisation dies auf direktem Wege erlaubt) und Redaktionen Inhalte in Bildungsnetzwerke oder das Internet veröffentlichen.

Quellenerschließung

Über Crawler und Schnittstellenabfragen kommen große Inhaltemengen in den Contentknoten. Jede Quellen (der Anbieter) wird vor der Erschließung von der Redaktion geprüft. Wenn der Anbieter und Inhaltestichproben den Qualitätskriterien entsprechen, wird eine automatische Erschließung der Quelle angestoßen. Die entstehenden Rohdaten (Beschreibungsdatensätze der Einzelinhalte der Quelle) werden von der Redaktion geprüft. Wenn die stichprobenartige Prüfung positiv ausfällt, nutzt die Redaktion Funktionen in der Redaktionsumgebung um alle Inhalte der Quelle freizuschalten. 

Die Freischaltung kann entweder gleich für die Nutzer*innen und die Weböffentlichkeit gemacht werden. Alternativ können Inhaltemengen auch für die Fachredaktionen für das Redaktionsbuffet freigeschaltet werden. Das ist beispielsweise bei sehr großen Mengen sinnvoll, die anderenfalls die Suchergebnisse des Contentknotens dominieren würden. Beispielsweise hat die Deutsche Digitale Bibliothek mehrere Millionen Objekte, die potentiell für Bildung nutzbar sind. Aber die DDB wird bei WirLernenOnline nur für die Redaktionsbuffets freigeschaltet. Die Fachredaktionen können dann die Quelle mit Suchanfragen "durchkämmen" und einzelne Mengen für die Öffentlichkeit oder für ihre redaktionell geprüften Sammlungen freischalten.

Upload-Funktion

Mit der Upload-Funktion können auf der Externen Webseite oder im Repository Inhalte hochgeladen werden. Es können auch Links auf externe Inhalte als Referatorienobjekt angelegt werden.

Download-Funktion

Inhalte im Repositorium sind downloadbar:

Suchmaschine

Die Suchmaschine wurde für die Corona-Nothilfe für große gleichzeitige Nutzendenzahlen skaliert:

Die Inhalte können in "Swimmlanes" nach Inhaltekategorie gebündelt werden. 

Damit wurde der Wunsch von 5 der 10 nutzenden Bundesländer umgesetzt: Eine Suchmaschine soll nur wenige Inhalte des gleichen Typs anzeigen und "Stapel" bilden:

Die Contentknoten haben eine öffentliche Suchmaschine und eine interne Suche. In die öffentliche Suche gelangen nur redaktionell freigeschaltete Inhalte. In OER-Repositorien, in denen die Nutzenden selbst publizieren können, kann der Publikationsweg entweder über eine Redaktion oder direkt konfiguriert werden.

Inhaltenutzung im Lernplattformen, WebCMS u.a. Systemen

Die interne Suchmaschine der Heimat-Contentverwaltung ist in den Lernplattformen der der Organisation oder des Verbunds integrierbar. Der Plattformadministrator, z.B. von Moodle, installiert und konfiguriert dazu ein Plugin. Mit der Suche finden anschließend Lehrende - je nach Konfiguration - auch Studierende Inhalte, welche die Heimatredaktion freigegeben hat. Die Nutzende kann entscheiden, ob sie die gesehene Version oder die aktuellste Version des Objekts einbetten will. Ein Zähler im Heimat-Contentknoten zählt die Verwendungen.

Beim Einbetten werden rechtliche Angaben, wie Lizenzinformationen, automatisch am Objekt angezeigt:

Hier der ganze Ablauf als Film. Übrigens warnt das Moodle-Plugin vor Start von Youtube-Videos zum Absprung auf externe Seiten:

Sammlungen - interne-redaktionelle, persönliche, öffentliche, Lehrplansammlungen

Inzwischen wurden Sammlungen zum redaktionellen Kuratierungswerkzeug.

Bei WirLernenOnline nutzen 30 Fachredaktionen das Werkzeug um ca. 3.000 kuratierte Lehrplanthemen-Sammlungen bereitzustellen.

Wenn eine Fachredaktion startet, entwickelt sie zuerst eine Sammlungsstruktur. Diese Sammlungsstruktur bildet i.d.R. einen gemeinsamen Nenner zwischen den Lehrplänen der Bundesländer. Die Fachredaktionsmitglieder ordnen also Sammlungen so, dass die Zielgruppe der Lehrenden die Inhalte finden können. Anschließend durchstöbern und durchsuchen die Fachredakeur*innen den Contentpool (bei WLO 200.000 maschinell vorkuratierte Inhalte) und füllen ihre "redaktionell geprüften Sammlungen". Dabei werden die Inhalte auf Qualität geprüft, es werden Metadaten ergänzt, damit der Inhalt dann in einem Bildungsnetzwerk besser auffindbar ist.

Die Lehrenden nutzen ihre Sammlungen als eine Art Einsortierregal, in das nur Inhalte guter Qualität kommen. Maschinen (Künstliche Intelligenz u.a. Methoden) lernen vom "Einsortieren"  Redaktionen - die Redaktionen produzieren beim "Einsortieren" und Verschlagworten sogenannte Trainingsdatensätze für die Künstliche Intelligenz.

########

Die redaktionellen Sammlungen werden für die Weböffentlichkeit als Themenseiten unter Fachportalen präsentiert. Fachportale sind Wordpress-Seiten, die manuell gestaltet werden können. Dafür stehen aber auch edu-sharing Widgets bereit, die eine Sammlung als Galerie darstellen oder via Suchabfrage in das Repositorium einen oder mehrere Inhalte zur Anzeige bringen. 

Diese Widgets sind Teil des edu-sharing Wordpress-Plugins. Abschnitt 3 beschreibt, wie Moodle, Wordpress, Ilias und viele andere Systeme mit einem Contentknoten verbunden werden können, um Inhalte zu nutzen oder zu teilen.

Fachportale                                                                                         Themenseiten

 .                                         

Öffentliche Themenseiten bilden die Sammlungen ab

Themenseiten werden dabei automatisch generiert (nachfolgendes Bild). Der Titel und Beschreibungstext der Sammlung wird im oberen Seitenbereich neben einer Inhaltestatistik angezeigt. Die Statistik zeigt, wieviel Inhalte zum Lehrplanthema in der redaktionellen Sammlung sind und wieviel weitere Inhalte zum Thema in der Suchmaschine "nur" maschinell kuratiert vorliegen. Links im Bild sieht man auf der rechten Seitenleiste eine Widget-Konfiguration. Das Widget zeigt den Inhalt einer Sammlung an und filtert zusätzlich nach bestimmten Inhaltetypen.

Redaktionen können sich im Backend der Redaktionsumgebung auf das Verschlagworten und Einsortieren von Inhalten konzentrieren. Dabei werden die öffentlichen Fachportal- und Themenseiten automatisch aktualisiert. Der rechte Teil des Bildes zeigt, wie eine Sammlung in der Redaktionsumgebung aussieht:

Die Sammlungsbaumstruktur wird auf der Fachportal-/Themenseite wird als Navigationsstruktur angeboten:

In Landes-Contentverwaltungen werden solche Sammlungen bspw. als Lehrplansammlungen angeboten und sind nicht immer weböffentlich, sondern sind nur für eingeloggte Nutzende zugänglich. Sammlungen sehen original (also ohne Themenseite) so aus:

Fachredaktionen entwerfen mit ihrer Gründung Themenbäume i.d.R. in einer Tabelle. Bei WirLernenOnline werden dafür Google-Tabellen genutzt. Diese Google-Tabelle wird nach Fertigstellung und Peerreview mit einer anderen Community-Redaktion vom IT-Team eingelesen und zu einer Sammlungsstruktur. Nach diesem Einlesen pflegt die Redaktion den Sammlungsbaum in der edu-sharing Redaktionsumgebung. Maßgebliche Änderung an dem Themenbaum erfordern einen erneuten Peer-Review oder ein anderes "Vier-Augen-Prinzip".

Metadatenverwaltung und Inhalteveröffentlichung

Metadaten entstehen automatisch durch Einsortieren in Ordner oder durch einen Metadateneditor. Außerdem werden beim technischen Erschließen von Quellen Metadaten automatisch generiert. Metadaten können mit dem Editor im Bulk-Verfahren angefügt und verändert werden. 

Redaktionsfunktionen zur Qualitätssicherung

Die Redaktionen haben filterbare Eingangs- und Bestandslisten

Zugriffsrechte, Lizenzprüfung, Auslieferung

Das Rechtesystem des Contentknoten gleicht oft mit dem IDM der Organisation oder des Landes Gruppen, Nutzende und Rechteinformationen aus. Ein Auslieferungsservice für Content prüft zudem, ob Nutzende Rechte auf die Inhalte haben. Diese Prüfung ist für OER nur in einer Produktionsphase wichtig, wo eine Autor*innen-Gruppe vorerst privat arbeiten möchte. Für auch in solchen Knoten zugänglich gemachte Kaufmedien ist vor Auslieferung eine Lizenzprüfung nötig, bspw. ob das jeweilige Kreismedienzentrum die Lizenz dieses Mediums erworben hat.

Renderingservice & Instanziierung

Der Renderingservice spielt Inhalteformate ab, die im Rohformat im Browser nicht angezeigt werden können. Bspw. werden Moodle-Zip-Dateien von einem Moodle-Modul im Renderingservice abgespielt. Für einige Formate können auch für die zugreifende Kursgruppe eine Instanz angelegt werden. So können bspw. ILIAS-Nutzende einen Moodle-Kurs finden und ihn für ihre Kursgruppe im Renderingservice instanzzieren lassen. Dieser Instanzzierungsservice wird im Abschnitt 5 beschrieben und als Contentknoten-unabhängiger Service für Bildungsnetzwerke vorgeschlagen.

Nötige Arbeiten und PoC für einen skalierfähigen Contentknoten mit flexiblen Metadaten

Wie oben beschrieben braucht es für vernetzte Infrastrukturen Redaktionsknoten, die mit massiven Mengen von Metadaten und Inhalten umgehen können. Hierfür sind Contentknoten zu "skalieren". Dafür sind Architekturen so zu ändern, dass sie die Last von vielen Inhalten oder vielen gleichzeitigen Nutzendenzugriffen aushalten.

Hierzu wurden in der Konzeptphase PoCs entwickelt und Technologien untersucht, welche sowohl die Anforderungen an die Skalierung als auch Heterogenität der Metadaten erfüllen können. Eingesetzt wurde u.a. NoSQL-Technologie in Form einer MongoDB. Abzusehen ist, dass keine Einzellösung alle Anforderungen erfüllen kann. Nur durch die gezielte Kombination mehrerer spezialisierter Systeme auf Basis von NoSQL, speziell strukturierte Suchindexe, graph-basierte und ggf. weiterer State-of-the-Art Technologien lassen sich die gewünschten Anforderungen skalierfähig und performant erfüllen.

Um das Funktionieren eines solchen Netzwerkes von (Lern-)Plattformen und Redaktions- knoten zu gewährleisten, wurden zentrale Services konzipiert. Einige Services wurden in Vorgängerprojekten als reife, noch zu kapselnde und zu skalierende, Lösungen entwickelt (s. Tabelle), andere als Prototypen implementiert. Prototypen werden Open Source und Konzepte in Community-Wikis veröffentlicht: Wiki der Open Education Community DE [OEde22], Wiki der DINI-AGs Kompetenzzentrum Interoperable Metadaten [OERAG].

Liste der Grundsysteme

Die edu-sharing Software-Lösung basiert im Kern auf dem CMS-System Alfresco.

Alfresco ist ein Open-Source CMS System auf Java-Basis, welches auch im Enterprisebereich Einsatz findet.
Zur Datenhaltung nutzt Alfresco eine relationale Datenbank, in den Landesinstallationen kommt PostgreSQL zum Einsatz.
Für eine performante Suche von Inhalten überführt Alfresco die Inhalte asynchron in eine spezielle Indexstruktur, welche Solr als Suchengine verwendet.

Für die Bedienung des Systems haben wir für edu-sharing eigene Oberflächen als SPA mit Angular entwickelt, um flexibel die speziellen Anforderungen im pädagogischen Kontext abzudecken und eine einheitliche UX verwenden zu können.

Für die Auslieferung von Inhalten arbeitet innerhalb der edu-sharing Software eine eigenständige Rendering-Service Komponente.
Diese nutzt PHP als Software-Technologie, da insbesondere im Bildungsbereich viele Formate und Systeme bereits mit dieser Sprache und entsprechenden Frameworks arbeiten (z.B. H5P, Moodle).

Technologieskizze einer edu-sharing Installation, verteilt über mehrere Server.

Fachliche Anforderungen an Systeme zur Verwaltung von Bildungsinhalten

Alfresco als klassisches CMS innerhalb der edu-sharing Software bringt bereits viele grundlegende Anforderungen an ein Datei- und Metadatenmanagement System mit, darunter:

• Die Persistierung von Binärdaten
• Die hierarchische Verwaltung von Dokumenten, Ordnern oder anderen Objekten
• Ein granulares Rechte- und Gruppen-Management inkl. komplexer Vererbungsstrategien
• Eine flexible Speicherung von Metadaten pro Objekt, unabhängig vom Objekttyp, inklusive Typisierung der einzelnen Datenelemente
• Die Transformation und Aufbereitung gängiger Medienformate, darunter 
  • Metadaten-Extraktion aus Bildern & Dokumenten (z.B. Titel, Beschreibung)
  • Volltext-Extraktion aus gängigen Office- und PDF-Dateien für die Suche
  • Generierung von Vorschaubildern für Dokumente

Diese Funktionalitäten stellen die Grundlage der edu-sharing Software dar.

Innerhalb des pädagogischen Kontextes gibt es jedoch eine Reihe von zusätzlichen Anforderungen, welche ein CMS alleine nicht abbilden kann.

Im folgenden ist ein Teilausschnitt dieser Funktionen gelistet und wie diese bereits in der edu-sharing Software gelöst worden sind.

Pädagogische Metadaten

Im pädagogischen Kontext gibt es, neben den klassischen Metadaten einer Datei wie Name, Dateigröße oder Mimetyp, eine Vielzahl von Metadaten & Wertebereichen, die sich z.T. inhaltlich unterscheiden.

Da je nach Kontext auch unterschiedliche Eingabeformate notwendig sind, haben wir einen frei konfigurierbaren Metadaten-Editor implementiert.
Dieser wird via XML-Konfigurationen befüllt und kann eine Vielzahl von einfachen Eingabemechanismen, z.B. Textfelder, Auswahlfelder oder Checkboxen abbilden.
Zusätzlich sind auch Feldfunktionen für komplexere Wertbereiche, z.B. hierarchische Baumstrukturen oder Autocomplete-Felder für Schlagworte möglich. Falls die Wertebereiche in mehreren Sprachen vorliegen, werden diese ebenfalls je nach Nutzerkontext korrekt abgebildet.

Beispiel eines Metadatendialogs in der edu-sharing UI

Auch Abhängigkeiten zwischen Feldern, z.B. die Sichtbarkeit gewisser Felder in Abhängigkeit einer Nutzerrolle oder des Auswahlstatus anderer Felder, ist abbildbar.

Für die Definition der Wertebereiche ist das System ebenfalls flexibel gestaltet: Während lokale Wertebereiche (ebenfalls via XML-Dateien) hinterlegt werden können, können auch Wertebereiche aus anderen Systemen zur Laufzeit abgeholt werden.
Aktuell wird dabei der SKOS- und CASE (OpenSALT)-Standard unterstützt, wobei dieses System modular erweiterbar konzeptioniert wurde.

Rechtemanagement & Berechtigungsmanagement

Alfresco liefert bereits ein sehr durchdachtes und umfangreiches Rechtekonzept mit. Außerdem bietet es die Möglichkeit, eigene Rechte-Typen zu definieren. Dies wurde im Rahmen der Software auch verwendet, um spezielle Rechte-Konstellationen (z.B. Materialien, wo nur deren Metadaten öffentlich sichtbar sein dürfen) abzubilden.

Zusätzlich zu den Rechten auf Dateiebenen wurde im Rahmen der edu-sharing Software eine globale Rechtekonfiguration eingeführt, worüber die Berechtigungen auf einzelne Systemfunktionen (z.B. Freigeben, Lizenzen festlegen, Nutzer suchen, bestimmte Tools verwenden) sowohl auf Gruppen als auch auf Nutzerebene spezifisch festgelegt werden können. Dies ist sowohl über eine Management-UI als auch automatisiert über die API möglich.

Auffindbarkeit von Dateien, Suchfunktion

Als ein wichtiges Element zum auffinden von Materialien stellt die Suchengine einen wesentlichen Teil des Systems dar.
Auf technischer Ebene sind Suchanfragen über klassische Datenbanken aufgrund der darunterliegenden Struktur i.d.R. keine sinnvolle Option.
Alfresco bietet mit der mitgelieferten Solr-Suchengine bereits eine umfangreiche Lösung. Die Daten der Datenbank werden regelmäßig in den Suchindex überführt.

Hierbei werden bei Dokumenten auf Wunsch auch Volltexte extrahiert. Außerdem sind die Sichtbarkeitsrechte im Suchindex bekannt, sodass sichergestellt wird, dass der jeweils Nutzende nur genau die Inhalte aus dem Index geliefert bekommt, für welche er entsprechende Sichtbarkeitsrechte hat.

Im Rahmen des WLO-Projekts haben wir ab 2020 damit begonnen, die Suchengine durch eine eigene Implementierung auf Basis der Elasticsearch-Engine abzulösen.

Der Alfresco-Suchindex in Solr ist sehr generisch gehalten. Dies ermöglicht zwar eine hohe Anpassbarkeit für neue Metadaten, hat sich aber insbesondere bei vielen Suchzugriffen als Flaschenhals bei der Performance herausgestellt. Zusätzlich wird für jedes im Suchindex gefundenes Objekt eine Abfrage in die relationale Datenbank durchgeführt, da nicht alle Daten innerhalb des Solr-Index verfügbar sind.

Die entwickelte Erweiterung um die Integration der Elasticsearch als Suchkomponente besteht im wesentlichen aus zwei Komponenten:

• Den Suchdienst, welcher die Anfragen aus der edu-sharing Suchumgebung an die Elasticsearch weiterleitet, und alle Daten aus der Elasticsearch zurückgibt, ohne zusätzlich die relationale Datenbank anzufragen sowie
• einem Tracker, welcher im regelmäßigen Intervall über die Transaktionsliste geänderter Medien innerhalb des Alfresco-CMS prüft (ähnlich der Standard-Implementierung für Solr) und diese in eine spezielle und vollständige Elasticsearch-Struktur überführt.

Diese Struktur beinhaltet alle notwendigen Metadaten und Nutzer-Rechte, sodass keine zusätzliche Anfrage an die relationale Datenbank notwendig ist. Außerdem werden Informationen aus den Metadaten-Wertebereichen (s. oben) berücksichtigt und mit in den Suchindex aufgenommen.

Als weitere Dateninformation werden seit einiger Zeit auch Nutzungsstatistiken der jeweiligen Medien eines wählbaren Zeitraums mit in den Index aufgenommen, sodass entsprechend eine Optimierung der Suchergebnisse in Abhängigkeit der Mediennutzung (Boosting) vorgenommen werden kann.

Aktuell wird bereits die Erweiterung um Materialbewertungen bzw. "Likes" umgesetzt, sodass auch diese Informationen effizient aus dem Suchindex abgerufen und für Ranking verwendet werden können.

Binärspeicherung von Inhalten (Lehrer Upload)

Für die Persistierung hochgeladender Inhalte verwenden wir die Technologien des Alfresco CMS.

Alfresco bietet auch die Definition eines Hart-Quota (maximale Menge an Speicher, die ein Nutzer mit seinen Dateien belegen darf) an, welches innerhalb der edu-sharing Software auf Wunsch ebenfalls auf Nutzer-Basis aktiviert und konfiguriert werden kann.

Ebenfalls ist eine Versionierung der einzelnen Dateien (bei Änderungen des Dateinhalts) vorgesehen, sodass diese bei Bedarf wiederhergestellt werden kann oder auch explizit auf eine spezifische Version referenziert werden kann.

Organisation und Strukturierung von Inhalten (Sammlungen)

Die klassische Ordnerstruktur hat sich in der praktischen Nutzung durch Lehrende als Organisationsmöglichkeit für ihre Inhalte als unzureichend herausgestellt.

Insbesondere die Problematik, dass ein Medium in einer klassischen Dateiverwaltung immer nur genau einem Speicherort zugeordnet sein kann, ist in der Praxis ungeeignet. 
Die Anforderung, dass man Medien - sowohl selbst angelegt als auch von anderen Nutzern oder öffentlich verfügbar - an beliebiger Stelle erneut einsortieren kann, ist daher relativ schnell aufgetaucht.

Für diesen Fall haben wir innerhalb der edu-sharing Software das Konzept der Sammlungen eingeführt.

Nutzende können sowohl private als auch mit anderen geteilte Sammlungen anlegen. Die Sammlungen können mit beliebigen Medien (Berechtigungen vorausgesetzt) befüllt werden. Auch mehrere Personen können gemeinsam eine Sammlung befüllen. Die Sortierung der Medien innerhalb der Sammlung kann auf Wunsch ebenfalls vorgegeben werden.

Im Rahmen des WLO-Projekts haben wir die Sammlungen um spezielle, redaktionelle Sammlungen erweitert. Diese ergänzen das bestehende Konzept dahingehend, dass Sammlungen nun pädagogische Metadaten erhalten und diese Metadaten auf Wunsch an die darin befindlichen Medien "vererben" bzw. die Medien besser auffindbar machen.

Zusätzlich wurden spezielle Widgets (kleine Bausteine) für eine Wordpress-Umgebung entwickelt. Diese können auf beliebigen Seiten im Wordpress eingebettet werden und dynamisch aktuelle Daten aus den Sammlungen laden. Hierdurch können die kurartierten Daten an zentraler Stelle organisiert werden und an mehreren, inhaltlich geeigneten Stellen, ausgeliefert und angezeigt werden.

Rendering & Auslieferung interaktiver Inhalte

Im Bildungsumfeld existiert eine hohe heterogenität von Inhalteformaten. Klassische CMS-Systeme wie Alfresco sind meistens für typische Dokumentformate wie Office oder PDF optimiert, können jedoch spezielle Inhaltetypen nicht darstellen.

Insbesondere in den letzten Jahren hat sich gezeigt, dass Lehrende die interaktiven Möglichkeiten der Online-Medien mehr in ihre Materialien einbeziehen möchten. Dahingehend hat sich eine Vielzahl verschiedener, oft auch kleinerer, Standards bzw. Tools entwickelt.

Die hohe Diversität dieser einzelnen Inhaltetypen sind jedoch für die Auslieferung eine Herausforderung.
Konkretes Praxis-Beispiel: Für die Darstellung von H5P-Inhalten müssen die einzelnen Abhängigkeiten der Inhalte im Backend-System ebenfalls in den korrekten Versionen vorliegen und über eine relationelle Datenbank organisiert werden.

Daher war es bei der Vielzahl der Formate nicht zielführend, im jeweiligen Zielsystem die Auslieferung durchzuführen, da in diesem Fall die Logik und Unterstützung der einzelnen Formate pro System aufwendig implementiert werden muss und der Nutzer in Abhängigkeit des Systems einzelne Formate ggf. nicht verwenden kann.

Aus diesem Grund existiert in der edu-sharing Software die Rendering-Komponente.

Neben der Unterstützung für "klassische" Dateien wie Bilder, Videos oder PDF-Dokumente, welche in den meisten Fällen ohnehin durch die modernen Webbrowser angezeigt werden können, unterstützt der Service die Aufbereitung und Auslieferung eine Vielzahl von im E-Learning-Kontext verbreiteten Formate, u.a.

• H5P
• Exportierte Moodle-Kurse (mbz)
• QTI-Tests
• HTML-Dokumente (z.B. Exporte aus Praezi, iSpring)
• WebGL (z.B. 3D-Anwendungen aus Unity)
• Externe Quellen als Frame-Einbettung (sofern technisch verfügbar, z.B. LearningApps, Youtube)

Für Videos wird zusätzlich eine automatische Konvertierung auf für das Web optimierte Dateigrößen in verschiedenen Videoauflösungen durchgeführt.

Anbindung förderierte Dienste

Für einige Daten-Quellen, z.B. die Deutsche Digitale Bibliothek, Pixabay, Youtube oder andere große Datendienste ist eine Überführung aller Daten in den eigenen Suchindex nicht praktikabel und teilweise nicht zulässig.

Daher sind für einige dieser Dienste förderierte Suchanbindungen in edu-sharing verfügbar. Eine Föderation von edu-sharing Instanzen ist ebenfalls möglich

Bei Förderationen von mehreren Instanzen von edu-sharing werden globale Gruppen unterstützt. Wenn beide Systeme diese Gruppen-Id's verwenden, werden Nutzer automatisch in die entsprechende Gruppe im Remote-System eingefügt. Hierdurch können Objektrechte auch über Systemgrenzen hinweg abgebildet und umgesetzt werden.

Die Suchergebnisse der Dienste können dann in Oberfläche von edu-sharing durchsucht werden, Auch erweiterte spezifische Suchmetadaten, sofern von der Quellen-API unterstützt, sind möglich und werden intern gemappt.  

Nutzende können auch Ergebnisse dieser Quellen in ihren Sammlungen (s. oben) verwenden. In diesem Fall wird ein lokales "Schattenobjekt" mit Informationen zum Quellobjekt persistiert, welches die Daten beim erneuten Abruf auch (sofern von der Quelle unterstützt) automatisch mit den aktuellen Stand der Quelle abgleicht.

Sofern von Quellen unterstützt, sind auch zusätzliche Funktionen wie ein automatischer Import der Quelldaten (z.B. Pixabay) nach edu-sharing möglich.

Freigabe/geteilte Arbeitsbereiche

Bei einigen Aufgaben ist die "klassische" Arbeitsstruktur mit einem gemeinsamen Ablageordner für geteilte Dokumente durchaus verbreitet.

Hierfür wird in edu-sharing pro Schule ein Dateiordner (auf Wunsch mit Templating der Ordner- und Rechtestruktur) angelegt und dieser virtuell in die Arbeitsumgebung des Nutzers "gemountet". In diesem Bereich können Dokumente zentral verwaltet werden.

Nutzende können andere Nutzer natürlich auch per Einzel-Freigabe an ein Material oder Ordner einladen. Diese Einladung erscheinen dann in einer speziellen Freigabeliste.

Metadaten-Extraktion & Volltextsuche

Wie bei der Beschreibung von Alfresco bereits zuvor erwähnt extrahiert Alfresco (Tika Framework ) bereits Metadaten, Vorschaubilder und Volltexte für gängige Formate.

Die edu-sharing Software erweitert diese Transformationsprozesse um die Erkennung von speziellen Bildungsinhalten (z.B. Moodle Kurse, H5P-Dateien, QTI) und extrahiert, sofern je nach Format technisch möglich, weitere Metadaten, Volltext oder Vorschaubilder.

Kooperation (Only Office etc.)

Neben der Anzeige und den Upload von Daten ist auch die interaktive Erstellung und Bearbeitung direkt im System, idealerweise auch kollaborativ, ein wichtiger Bestandteil der Software.

Für die Anbindung von Bearbeitungs-Tools bieten wir eine eigenständige Software-Komponente "Connector" innerhalb der edu-sharing Softwarelandschaft an.

Diese verwaltet die Anbindung diverser Editor-Werkzeuge, darunter:

• TinyMCE (Simpler HTML-Editor, keine zusätzlichen Server-Abhängigkeiten)
• OnlyOffice (mit Kollaboration)
• H5P
• Onyx

Durch die Trennung des Connectors vom restlichen System ist eine modulare Erweiterbarkeit um neue Editoren und Tools relativ einfach möglich.

Standard-Interoperabilität (LOM, LRMI)

Bestehende Systeme im Bildungssegment nutzen bereits etablierte Standards zum Datenaustausch der pädagogischen Metadaten.

Zwei weit verbreitete Standards bilden LOM (bzw. LOM-DE im deutschsprachigen Raum) sowie das noch jüngere LRMI.

LOM wird häufig als Austauschformat bei der Weitergabe von Metadaten über die XML-Basierte Service-Definition "OAI" (Open Archives Initiative) angewendet, während LRMI per JSON-LD in die Header der Seite als Datenobjekt eingebunden wird, sodass z.B. Suchmaschinen die zusätzlichen Meta-Informationen abrufen können.

Innerhalb der edu-sharing Software unterstützten wir für LOM-DE den Im- und Export via OAI-Service-Standard und stellen LRMI-Metadaten auf den einzelnen Inhalteseiten bereit.

Dabei kann auf Wunsch das "Mapping", also die Datenabbildung der intern gespeicherten Werte von und nach LOM oder LRMI individuell konfiguriert werden. Ebenfalls werden mehrere Ausgabeformate, z.B. XML oder JSON, unterstützt.

Einbindung von Materialien, zentrale Datenhaltung (Integrations)

Wie bereits im Punkt "Rendering" angedeutet erscheint es nicht zielführend, in den einzelnen Systemen (LMS, CMS usw.) die Anzeige und Auslieferung von speziellen Dateitypen pro System zu entwickeln.

Daher bieten wir für viele Systeme eine  Integration an. Diese jeweilige Integration ermöglicht es, im entsprechenden Zielsystem ein Material, welches im edu-sharing vorgehalten wird, einzubinden.

Diese Einbindung umfasst folgende Funktionalitäten

• Konvertierung & Auslieferung des jeweiligen Formats über den Rendering-Service
• Automatische Attributierung der Lizenz / Metadaten des Objektes
• Zentrale Aktualisierung des Mediums über edu-sharing (sofern bei der Einbindung gewünscht)
• Rechte-Management bei lizenzierten Inhalten
• Erfassung der Contexte bei der Einbindung (Metadaten Erzeugung)
• Statistik-Tracking der Abrufe und Einbindungen in den einzelnen Systemen / Usage / Übersicht der Verwendung 

Es werden nur Links auf Objekte innerhalb der Anwendungen gespeichert. Zur Laufzeit werden diese in die echten Objekte umgewandelt. Dadurch ist es möglich immer auf aktuelle Versionen zuzugreifen.

Diese "Integrationen" bieten wir bereits für etliche etablierte Systeme an und stellen auch Bibliotheken und Anleitungen bereit, sodass auch externe Dienstleister diese Integrationen für ihr System innerhalb kürzester Zeit entwickeln können.

Aktuell sind solche Integrationen für folgende Systeme verfügbar:

• Moodle
• Ilias
• OpenOlat
• Opal
• Mahara
• Mediawiki
• Wordpress
• Typo3
• OnlyOffice

Zusätzlich bieten wir für Systeme, welche den oEmbed-Standard unterstützten, eine Integration an. Die Einschränkung bei oEmbed besteht lediglich prinzipbedingt darin, dass kein zusätzliches Rechte-Management möglich ist und die Einbettung nur für öffentliche Inhalte möglich ist.

Aktuell in der Entwicklung ist bereits eine Integration von edu-sharing Inhalten in andere Systeme nach dem "LTI" Standard.

Workflows von Materialien, Veröffentlichungsprozesse

Um den redaktionellen Ablauf von Materialien zu vereinfachen, bietet die edu-sharing Software bereits jetzt ein einfaches Workflow-System.

Hierbei können Materialien in definierte Zustände an Personen oder redaktionelle Gruppen übergeben werden. Über eine Workflow-Historie können die Redakteure den bisherigen Verlauf der Änderungen und Weitergaben jederzeit nachvollziehen.

Für die Veröffentlichung von Materialien ist ebenfalls ein spezifischer Ablauf in der edu-sharing Software vorgesehen.

Das Problem einer "klassischen" Dokumentfreigabe besteht darin, dass der Ersteller weiterhin Rechte zum (weiter)-bearbeiten und löschen des Dokuments besitzt. Diese Rechte sind auch erwünscht, führen jedoch zu Problemen, sollte ein Autor das Dokument ungeplant verändern oder löschen.

Daher werden beim versionierten Veröffentlichen automatisch Kopien erzeugt, welche an die Redaktion übergeben werden und unveränderlich sind.

Zusätzlich können für diese veröffentlichen Kopien auch PIDs erzeugt werden, aktuell unterstützt edu-sharing hierfür bereits den Dienst von "handle.net".

Verzeichnisdienste und SSO / SLO / Provisionierung

Die Anbindung des edu-sharing Systems an bestehende Nutzerverwaltungssysteme unterschiedlicher Art ist mit mehreren Technologien möglich.

Über Alfresco ist bereits ein automatischer Abgleich mit Verzeichnisdiesenten wie LDAP oder AD möglich.

SSO-Lösungen wie Shibboleth sind ebenfalls bereits integriert und lassen sich flexibel an die Bedürfnisse und Anforderungen der jeweiligen Systeme anpassen.

Darüber hinaus gibt es bereits mehrere IDM Lösungen (Mebis-Bayern, RLP, NRW, Hamburg), welche über die edu-sharing API-Schnittstellen komplette Schulen mit Benutzern, Gruppen und Berechtigungen provisionieren,

Redaktionsumgebung & Kuratierung

Im Rahmen des WLO-Projektes entsteht aktuell eine weitere Komponente innerhalb der edu-sharing Software, welche sich an die Redakteure richtet.

Im Fokus steht hierbei insbesondere

• die Organisation und Sortierung von Medien, welche durch verschiedene Kanäle (Nutzer-Uploads, Crawling, Redaktionsempfehlungen) ins System gelangt sind
• eine Qualitätsprüfung nach definierten Kriterien und Bestätigung dieser
• eine schnelle Überprüfung und Aussortierungsmöglichkeit ungeeigneter Inhalte
• eine Metadaten-Überprüfung inkl. automatischer Vorschläge durch KI bzw. Seitenüberprüfung
• die schnelle Einsortierung in ausgewählte bzw. passende Sammlungen sowie
• umfangreiche Such-, Filter- und Sortierfunktionen nach pädagogischen Kriterien

DSGVO 

Für die Einhaltung der Datenschutzanforderungen in Deutschland & Europa, insbesondere beim Umgang mit personenbezogenen Daten, besitzt edu-sharing mehrere Funktionalitäten.

Eine der wichtigsten Funktionen umfasst die Löschung/Deprovisionierung der Nutzer. Neben der Konfiguration des Vorgehens über die UI (was erfolgt mit erstellten Inhalten, Kommentaren, etc.) ist auch eine spezielle Implementierung möglich, sofern das jeweilige Konzept eine spezielle Anforderung vorgibt.

Der Administrator des Systems kann über eine Export-Funktion alle erstellen Elemente eines Nutzers einfach als CSV-Exportieren, um Auskunft über hinterlegte Objekte zu ermöglichen.

Löschkonzepte / autom. Auskunft (Hessen Projekt)

Barrierefreiheit

Das Thema Accessibility und Barrierefreiheit ist insbesondere bei Angeboten von öffentlichen Plattformen, aber auch allgemein ein immer wichtig werdender Punkt von Online-Anwendungen.

In den letzten Jahren wurden in den Angular-Oberflächen der edu-sharing Software daher viele Verbesserungen und Anpassungen vorgenommen. U.a. arbeiten wir mit optimierten Frameworks (z.B. Angular Material) und achten bereits bei der Gestaltung der Komponenten auf eine gute Accessibility.

Neben einfacher Bedienbarkeit sind auch Anforderungen an Schriftgröße, Kontrast, Screenreader-Kompatibilität usw. teil dieses Arbeitspakets. Wir prüfen dahingehend die edu-sharing Oberflächen regelmäßig, ob die notwendigen Kriterien erfüllt sind.

Lizenzanbindung / Medienzentren / Schulen

In den Ländern werden auch Kaufmedien in edu-sharing verwaltet. Die Einbeziehung der Daten und Lizenzen wird über Konnektoren und Jobs gesteuert. Aktuell wird die Verfügbarkeit der Medien sowohl über interne Rechte als auch über extern angebundene Services gesteuert.

Die Rechte-Struktur von edu-sharing & Alfresco sieht dabei auch granulare Rechte vor, z.B. können Rechte nur auf Metadaten und Vorschaubild, aber nicht den eigentlichen Inhalt vergeben werden.

Als Weiterentwicklung sind hier insb. die häufig aufgetretene Anforderung, die Erlaubnis zum Download von Medien, eine mögliche Option.

Domain-Kontexte & Theming/Customizing

Die individuelle Gestaltung der Oberflächen mit kundenspezifischen Logos, Farben oder Texten (Branding) ist ein wichtiger Bestandteil. Unsere Oberflächen bieten dahingehend weitreichende Anpassungs- und Plugin-Möglichkeiten, um individuelle Aspekte des Layouts anzupassen.

Neben globalen Farbtabellen zur Anpassung der Farbschema können auch Banner, Texte & Dialoge, Menü-Buttons und weitere Funktionalitäten individuell angepasst werden.

Um eine edu-sharing Instanz für mehrere Umgebungen zu gestalten, bietet edu-sharing die Möglichkeit, in Abhängigkeit der Domain (ähnlich einer ServerName Konfiguration in Apache/Nginx Webservern) individuelle Konfigurationen für diese Ansicht bereitzustellen.
Dies kann andere Logos & Texte umfassen, aber auch andere Metadaten oder Suchergebnisse.

Modularität, Anpassbarkeit, Erweiterbarkeit

Die unterschiedlichen Anforderungen der bisherigen edu-sharing Installationen haben dazu geführt, dass die Software an vielen Stellen eine hohe Modularität und Konfigurierbarkeit aufweist.
Dadurch können unterschiedlichste Anforderungen in der Regel in kurzer Zeit adaptiert werden und das System bei Bedarf für einzelne Kunden erweitert werden, ohne die Komplexität der Grundkomponenten zu erhöhen.

Der Quellcode der edu-sharing Software wird unter GPL3 Lizenz auf Github zur Verfügung gestellt und andere Partner und Entwickler können per Pull-Requests Bugfixes und neue Funktionen beisteuern.

Skalierfähigkeit bestehender Software-Lösungen

• Bereits erfolgte Schritte für die edu-sharing Softwarelösung
• Identifizierte Engpässe bei der aktuellen Softwarelösung
• Geplante Anpassungen und Entwicklungen

Beschreibung der Soll-Architektur.

Ziel ist die Entwicklung, Konzeptionierung und Verwendung von gut skalierbarer, frei verfügbaren, Open Source unterstützenden Technologien und Infrastrukturen, in punkto Software sowie Hardware.

Da zu erwarten ist, dass die Anzahl der Nutzer stark steigen wird, die gleichzeitig auf die verfügbaren Ressourcen zugreifen, muss dafür gesorgt werden, dass diese gut skalierbar sind. Dies kann unter anderem durch die Verteilung der Last auf mehrere Instanzen erreicht werden. Die Skalierbarkeit der Anwendung soll also horizontal ausgeprägt werden. Gegenüber der vertikalen Skalierung, welches nur durch bessere Hardware und höhere Taktraten verbessert werden kann, kann die horizontale Skalierbarkeit durch die Hinzunahme weiterer Knoten und Ressourcen fast grenzenlos gesteigert werden. Praktisch werden die Dienste auf mehrere Server bzw. Knoten im Cluster aufgeteilt oder mehrfach zur Verfügung gestellt. Dieser Prozess muss natürlich von der Infrastruktur sowie von der Software selber unterstützt werden.   

Die aktuelle Softwarearchitektur von edu-sharing, ist bereits in vielen Bestandteilen horizontal skalierbar. So wurde bereits der Suchindex auf das stark horizontal skalierbare elasticsearch erweitert. Auch der Renderingservice, der die vielen verschiedenen Medienformate vorverarbeitet und dem Nutzer zur Verfügung stellt, kann bereits auf beliebig viele Knoten verteilt werden. Jedoch gibt es noch einige Bestandteile der Software die aufgrund ihrer Architektur in der Skalierbarkeit eingeschränkt sind und sich dadurch ein Flaschenhals (Bottleneck) für diverse System der Software bildet.

Ein solches Bottleneck ist die aktuell verwendete Datenbankstruktur zu nennen. Die stärken der relationale PostgreSQL Datenbank liegen in der Verknüpfung von verschiedenen Datensätzen innerhalb der Datenbank, also in der Abfrage von relationalen Daten. Mit ihr lassen sich hervorragend kleinere Datenmengen, welche in einer bestimmten Beziehung zueinander stehen, auslesen und verwalten. Kommen jedoch zunehmend mehr Daten und mehr Beziehungen zwischen den Daten zustande, so vergrößert sicher die Dauer des Lese- und Schreibvorgangs. Zusätzlich kommt der Fakt hinzu, dass beim Schreiben von Daten große Teile der Datenbank geblockt werden müssen, wodurch sich der Zugriff und die parallele Bearbeitung der Daten zunehmend verschlechtert. Es entsteht ein Flaschenhals der letztlich die gesamte Software stark beeinträchtigt. Zwar gibt es eine Clusterlösung für die PostgreSQL Datenbank, welche das Problem über den sogenannten Master/Slave Mechanismus versucht zu entschärfen, aber auch dieser ist nur beschränkt einsetzbar und skalierfähig.        

Im Rahmen des Open Edu-Hub-Projektes und Wir lernen Online  hat sich gezeigt, dass die gewünschten Metadatenkonzepte von LOM (Learning Object Metadata) und LRMI (Learning Ressource Metadata Initiative) nicht ausreichen, um die Anforderungen der Benutzer und Redakteure zu erfüllen. So haben die verschiedenen Nutzergruppen der einzelnen Bundesländer unterschiedliche Qualitätsmerkmale, welche Sie an Ihre Inhalte stellen. Auch durch die Hinzunahme von KI-Diensten, zum Sammeln und Verarbeiten von Metadaten, werden weitere Datenstrukturen benötigt. Dadurch vergrößert sich sukzessive die zu speichernde Datenmenge je Inhalt. Die OER Welt verfügt demnach über eine Vielzahl an Metadaten, die verwaltet werden müssen. Erfahrungsgemäß hat sich gezeigt, dass auch zukünftig die Menge an Daten je Inhalt weiter steigen wird und geeignete Strukturen für die Datenhaltung benötigt werden.

Aufgrund der Architektur von relationalen Datenbanken wie der PostgreSQL Datenbank, ist die Abfrage von beziehungsbehafteten Daten zwar schnell, jedoch beschränkt auf die Leistung der physischen Maschine auf dem der Dienst läuft. Im rahmen eines Proof of Concept wurden bereits  verschiedene Lösungswege untersucht. Unter anderem wurden bereits Bestandteile der Metadaten aus der relationalen Datenbank herausgelöst und in eine sogenannte No-SQL Datenbank gespeichert. Es zeigte sich, dass dies in Sachen Datenmenge, Lese- und Schreibgeschwindigkeit ein erheblichen Performancevorteil gegenüber der bisherigen PostgreSQL Datenbank entstanden ist. Jedoch haben unsere Versuche auch gezeigt, dass sich damit nicht jedes Problem zu unseren vollen Zufriedenheit lösen lassen kann.

Wir kamen zum Ergebnis, dass keine Technologie als Einzellösung alle Anforderungen erfüllen kann. Sondern nur durch die geschickte Kombination der einzelnen Technologien untereinander und miteinander. So lassen sich die Stärken der einzelnen Systeme hervorheben und die  Schwächen der jeweiligen anderen kompensieren. In dieser Kombination können so alle gestellten Anforderungen erfüllt werden.

Zielstellung / Konzept - Ausbau & Skalierung der Komponenten

Elasticsearch

MongoDB

PostgreSQL

Alfresco

Ist eine freie Software zur Dokumentenverwaltung elektronisch gespeicherter Dokumente. Neben einem komplexen Rechte-, Freigabe- und Versionierungssystem bietet Alfresco dem Anwender die Möglichkeit Dokumente von LibreOffice, Apache OpenOffice, Collabora Online, ONLYOFFICE und Microsoft Office in gewohnten Verzeichnissen zu verwalten und gemeinsam zu bearbeiten. LDAP und MS Active Directory kann zur Benutzeridentifikation integriert werden. Durch ausgeprägte Plugin-Mechanismen und eine Umfangreiche API lässt sich die Software beliebig erweitern. So kann auch das Metadatenmodel kann über eine einfache XML-Definitionsdatei einfach erweitert werden und an die Anforderungen der Nutzergruppen angepasst werden. Auch verfügt die Alfresco Software über ein Clustermodus wodurch der Dienst einfach auf mehrere Instanzen verteilt werden kann. Somit ist dieser auch gut horizontal skalierbar. Da die Software jedoch die PostgreSQL Datenbank zur Verwaltung der Daten nutzt und diese wie oben beschrieben nicht gut skalieren kann ist auch der Alfresco davon betroffen. Gerade die flexible Metadatenstruktur ist hier ein Knackpunkt. Da die relationale Datenbank festdefinierte Tabellen besitzt, kann eine solche flexible Datenstruktur, wie wir Sie bei den Metadaten benötigen, nur auf Kosten von komplexen Datenhaltung und Abfragen bewerkstelligt werden.  Was das ohnehin bestehnde Bottleneck der Postgresql Datenbank noch verschlechtert. Genauer gesagt bedeutet das, dass je mehr Metadaten gespeichert werden, desto mehr abfragen werden benötigt um diese abzurufen und desto langsamer wird das gesamt System reagieren. 

Pro:

• Komplexes Rechtesystem bereits vorhanden
• Datenspeichersystem bereits vorhanden
• Plugin-Mechanismen
• Erweiterbares Basissystems
• Metadatenmodel frei konfigurierbar
• Clusterfähig

Cons:

• Bestehende Strukturen nur schwer oder gar nicht veränderbar
• Speicherung komplexe Metadatenmodele verlangsamen das System erheblich → eingeschränkte Skalierbarkeit 

Infrastruktur  

Als Infrastruktur-Lösung sehen wir die Kapselung der einzelnen Komponenten als Docker-Container sowie die Ausführung auf einem Kubernetes-Cluster als wegweisend. Insb. durch automatische Skalierfähigkeit können somit auch hohe Lastspitzen performant verarbeitet werden.

Zukünftige Anforderungen

Wir rechnen mit einem hohen Zuwachs an Metadaten- und Wertebereichen, insb. durch das Aufkommen weiterer Inhaltetypen neben klassischen Lerninhalten, welche wiederum ein eigenes Metadatenschema und -Wertebereiche benötigen.

Beschreibung einer optimalen Zielarchitektur

Um die oben beschriebenen Einschränkungen der Skalierbarkeit zu lösen, ist eine Umstrukturierung der Datenhaltung notwendig. Dabei soll auf die bestehenden Funktionen der Alfresco Software zurückgegriffen werden. Eine komplette Neuimplementierung wäre nicht wirtschaftlich und auch nicht zu empfehlen, da es nicht das eine System gibt, was alle Probleme lösen kann.

Ziel ist es den Großteil der Metadatenhaltung aus der PostgreSQL herauszulösen und in die MongoDB zu verlagern. Dadurch wird eine flexiblere Datenhaltung bei besserer Skalierung erreicht. Die PostgreSQL Datenbank wird weiterhin benötigt um Ordner- und Datenstrukturen sowie die Rechte an diesen zu verwalten.  So wird gewährleistet, dass die bestehenden Funktionen im Alfresco weitestgehend bestehen bleiben um A) nah am Originalsystem zu bleiben damit der Wartungs- und Migrationsaufwand für Sicherheits- und Funktionsupdates gering gehalten werden und B) die stärken der relationalen Datenbanken zu nutzen. Dabei wird das Datenaufkommen in der PostgreSQL Datenbank verringert und die Abfragegeschwindigkeit erhöht. Über Caching-Mechanismen können die sich selten verändernden aber häufig abgefragten Daten aus der PostgresSQL auch in die MongoDB gegeben werden. So können die Vorteile beider Systeme optimal ausgenutzt werden. Die Elasticsearch unterstützt die MongoDB und PostgreSQL Datenbanken bei der Volltextsuche.