Motivation und Überblick

Um Daten aus Inhaltequellen in die eigene Plattform zu überführen, sind sogenannte ETL-Prozesse notwendig. Der ETL (Extract, Transform, Load) Prozess im OpenEduHub-Projekt überführt dabei die Datensätze aus externen Quellen, die in unterschiedlichsten Formaten und Strukturen vorliegen, in ein einheitliches Datenformat, das innerhalb der verschiedenen Services innerhalb des OpenEduHub genutzt wird.

Im ersten Schritt (Extract) wird dabei die jeweilige Quelle abgefragt und eine Liste aller Datensätze (im Format der Quelle) abgerufen. Anschließend werden die Datensätze in ein einheitliches Datenformat (Transform) transferiert. Dies beinhaltet neben der Normierung der einzelnen Texte (Titel, Beschreibung) auch eine Überführung in ein gemeinsames Vokabular, sodass später Inhalte gezielt nach Fach, Bildungsstufe usw. erfasst werden können.
Im letzten Schritt (Load) werden diese Datensätze in ein CMS (im OpenEduHub: Alfresco, edu-sharing) persistiert und zugänglich gemacht.

Momentane Vorgehensweise

Im ETL-Prozess kommen Webcrawler zum Einsatz, die mit Hilfe des quell-offenen Scrapy-Frameworks in Python umgesetzt werden. In der Nomenklatur von „Scrapy“ werden die einzelnen Webcrawler als „Spiders“ bezeichnet. Da jede Webseite als Unikat zu betrachten ist, müssen auch die entsprechenden Crawler an diese individuellen Eigenheiten angepasst werden. Je nach Webseiten- und Datensatz-Struktur der Quelle unterscheidet sich die Komplexität und der Arbeitsaufwand, der für einen Webcrawler nötig ist.

Das Best-Case-Szenario

Im "best-case"-Szenario stellen Webseiten-Anbieter ihre (Meta-)Datensätze geordnet und strukturiert bereit, um etwaigen Webcrawlern beim Auffinden der Inhalte zu helfen.

Geordnet insofern, als relevante Inhalte standardisiert und maschinenlesbar, z. B. in Form einer Sitemap oder einem RSS-Feed (jeweils in Form einer XML-Datei), indexiert werden, um Webcrawlern die Navigation durch die Webseitenstruktur zu erleichtern. Ebenfalls zu bevorzugen ist der Einsatz von (offenen) APIs (= Schnittstellen), mittels derer ein Crawler die relevanten Inhalte indexieren kann und bestenfalls den Metadatensatz direkt als Teil der API-Antwort erhält.

Strukturiert: Im besten Fall stehen die Metadaten in einer standardisierten Struktur zur Verfügung, um die Weiterverarbeitung dieser so reibungsfrei wie möglich zu gestalten. Dafür eignen sich unter anderem der Dublin Core LRMI-Standard sowie der in der Crawler-Projektumgebung verwendete Learning Objects Metadata-Standard. In das DOM eines einzelnen Lerninhalts können diese Metadaten via JSON-LD eingebettet werden, was auch von Google im Hinblick auf Suchmaschinen-Optimierung grundsätzlich empfohlen wird.

(siehe dazu: Hilfestellung zum Bereitstellen von Metadaten in deutscher und englischer Fassung)

Die Realität

Viele Anbieter hochqualitativer Lerninhalte richten ihren Fokus bei der Entwicklung eines Webangebots zunächst primär auf die Lerninhalte selbst und haben oft nur sekundär, wenn überhaupt, die Interoperabilität mit anderen Systemen, wie beispielsweise dem Crawling durch Suchmaschinen, auf dem Radar. Gerade bei „historisch gewachsenen“ Projekten ist der Aufwand, diese auf moderne Web-Paradigmen umzumünzen, oft ein mit ehrenamtlichen Mitteln nicht bewältigbarer Arbeitsaufwand.

Dies mindert natürlich keinesfalls die Attraktivität oder Qualität der einzelnen Lerninhalte, macht die maschinelle Quellenerschließung jedoch zu einem deutlich zeitaufwändigeren Unterfangen, denn für jede Problemstellung des Webcrawlers müssen nun individuelle Lösungen implementiert werden, die zudem stark von der Stabilität des DOM einer Webseite abhängig sind.

Kurz zusammengefasst – zu den ETL-Problemstellungen und den daraus resultierenden Arbeitsschritten eines Webcrawlers gehören:

• Wie ist die Webseite zu navigieren? (Stichwort: Schnittstellen / Crawler-Navigation)
  • Wo finde ich die einzelnen Inhalte?
• Wo und in welcher Qualität finde ich die passenden Metadaten? (Stichwort: Extract / Metadaten-Standards)
  • Müssen diese vor der Transformation noch manuell aufbereitet oder „gesäubert“ werden?
  • Passen die Wertebereiche einer Quelle zu dem Datenmodell des Crawlers?
    • Falls nein: Mapping notwendig
• Datentransformation (Transform)
• Speichern der (Meta-)Datensätze im Backend (Load)

Extract

Dem Extract-Teilprozess ist auch der Algorithmus für die Webseiten-Navigation des Crawlers zuzuordnen. Im besten Fall bietet die zu crawlende Quelle eine offen zugängliche Schnittstelle, die sowohl Verlinkungen zu den einzelnen Lerninhalten sowie deren Metadaten bereithält. Sollten in der Schnittstelle nicht alle gewünschten Metadaten aufgeführt sein, extrahiert der Crawler diese, sofern vorhanden, aus den einzelnen Unterseiten eines Lerninhalts, indem diese abgerufen und das DOM ausgewertet wird.

Ist keine dedizierte Metadaten-Schnittstelle vorhanden, so ist trotzdem jede Hilfe willkommen, die sich für die Navigation über alle Seiteninhalte anbietet: Sitemaps oder RSS-Feeds dienen dem Crawler beispielsweise als „Wegbeschreibung“ für die zu crawlende Webseite.

Ist weder eine Schnittstelle noch ein anderes Hilfsmittel vorhanden, dem sich der Crawler bedienen kann, muss der Webcrawler „manuell“ über die Webseite navigieren. Ein Entwickler muss demnach die Webseitenstruktur der Quelle analysieren und für die zu crawlenden Inhalte eine Liste der geeigneten Navigationselemente (via CSS- oder XPath-Selektoren) erstellen, anhand dieser Selektoren den „Navigations-Algorithmus“ individuell implementieren und testen. Unerwünschte Inhalte (z. B. nicht-relevante Blog-Einträge, Hilfeseiten, Kontaktformulare) müssen hierbei erst mit manuell gepflegten Filterlisten exkludiert werden, damit diese URLs nicht aus Versehen ebenfalls erfasst werden.

Arbeitet der „Navigations-Algorithmus“ zufriedenstellend und indexiert alle gewünschten URLs, so werden nun die einzelnen URLs der Lerninhalte durch den Crawler aufgerufen, um alle relevanten Metadaten zu extrahieren. Metadaten, die der Crawler bereits aus vorhandenen Schnittstellen bezieht, können hierbei um weitere Daten ergänzt werden, sollten diese beispielsweise nur im „Head“-Bereich eines HTML-Dokuments vorkommen. Im „Worstcase“ muss der Crawler sich bestimmte Daten aus dem dem HTML-Body (Fließtext) holen, was auf lange Sicht wartungsintensiv und fehleranfälliger ist als bei „strukturiert“ eingepflegten Metadatensätzen.

Transform

Das reine Vorhandensein von Metadaten erleichtert zwar die Erschließung von Inhalten, garantiert aber nicht automatisch, dass diese Daten auch wohlgeformt sind. Bevor Metadaten dauerhaft gespeichert werden können, müssen diese entsprechend bereinigt, aufbereitet und gegebenenfalls auf die intern verwendeten Wertebereiche gemapped werden.

Die Bereinigung von Datensätzen umfasst beispielsweise die Erkennung von "Filler"-Keywords, die zwar SEO-relevant in einer Quelle eingebettet wurden, aber die Suchfunktion von Lerninhalten verwässern würden. Unter der Aufbereitung von Datensätzen ist in diesem Kontext die Einsortierung der Metadatenwerte in die entsprechenden LOM-Metadatenfelder zu verstehen. (Siehe auch: Illustration des Crawler-Datenmodells)

Die Umwandlung der „rohen“ Daten hin zu einem Datenmodell, mit dem das Backend weiterarbeiten kann, ist die namensgebende Transformation im ETL-Prozess. Teil dieser Transformation ist auch das Mapping auf valide Wertebereiche, welches mittels SKOS in Form diverser SkoHub-Vokabulare erfolgt. Diese quell-offenen Metadaten-Vokabulare sind die Grundlage für einen Wertebereich-stabilen Metadaten-Bestand.

Load

Im letzten Schritt des ETL-Prozesses wird ein Datensatz zu einem Lerninhalt gebündelt an das Backend übergeben. Hierbei durchläuft der Datensatz mehrere Scrapy Item Pipelines, bei denen unter anderem überprüft wird, ob der zu speichernde Lerninhalt bereits vorhanden ist. Sowohl durch Versionierung der Crawler selbst als auch unter Bezugnahme des "lastModified"-Datums eines Inhalts (sofern Quellen-seitig vorhanden) können so Dubletten verhindert und neue oder veränderte Lerninhalte erkannt werden.

Weiterentwicklungsbedarf

Eine große Herausforderung besteht aktuell bei der Normierung der Extract + Transform-Prozesse.
Aufgrund der hohen Diversität der einzelnen Quellen – teilweise mit oder ohne API-Schnittstellen – muss für jede Quelle ein Großteil dieser Schritte individuell implementiert werden.
Dies führt zu immer höheren Wartungsaufwand bei Updates und Verbesserungen der Crawling-Frameworks, als auch bei Änderungen seitens der einzelnen Quellen.
Ebenfalls ist der ETL-Prozess aktuell noch ohne Verwaltungsansicht und die einzelnen Prozesse laufen lediglich im Hintergrund ohne aktive Benachrichtigung bei Fehlern oder Problemen.

Zum einen ist für die Weiterentwicklung die Anbindung eines "Dashboards" vorgesehen - eine Übersicht, welche Quellen wann zuletzt abgefragt wurden, wie viele Inhalte dabei übermittelt wurden und ggf. ob Probleme aufgetreten sind.
Außerdem sollen in Zukunft die Extract + Transform-Prozesse vereinfacht, generischer und "robuster" werden, sodass möglichst viele Quellen denselben Prozess durchlaufen, um zukünftige Wartungsarbeiten effizienter zu gestalten und redundante Aufwände zu reduzieren.

Durch die enge Zusammenarbeit mit der Redaktion ist ebenfalls aufgefallen, dass die bisherigen Metadaten, insbesondere für die Materialart ("learning resource type"), für viele Materialien nicht differenziert genug sind und eine genauere Zuordnung wünschenswert ist.
Hierfür hat das Redaktionsteam in mehreren Iterationsschritten einen neuen Wertebereich ausgeprägt. Dieser wurde bereits maschinell umgesetzt und in Beziehung zu dem bisherigen Wertebereich gesetzt.
Um die erfassten Datensätze genauer zu klassifizieren, müssen einige der Crawler angepasst werden, sodass dieser neue Wertebereich ausgefüllt werden kann.

Zusätzlich ist geplant, noch nicht erschlossene Quellen in der folgenden Projektzeit mit anzubinden und einen passenden Prozess für diese bereitzustellen.