# Implementierungsansatz
Die Implementierung besteht entsprechend der Trennung von Darstellung und Daten aus zwei Komponenten: Ersteres ist die Datenbasis und kann als “lebendes Objekt” betrachtet werden, die zweite Komponente stellt die Darstellungsschicht dar. 
## Ein Repository für Definitionen
Ein gemeinsames Vokabular in einem Repository anzulegen und zu pflegen bringt viele Vorteile mit sich, die in der Software-Entwicklung schon lange zum Standard gehören. Git ist etabliertes, verteiltes, Open-Source Versionskontrollsystem. Einen zentralen Aspekt stellt hier sicher die inhärente Versionierung dar, die Weiterentwicklungen und Fortschritte sichtbar macht, aber auch den Zugriff auf vergangene Versionen ermöglicht. So könnte, im Sinne und als Erweiterung der Idee der Trusted Learning Analytics eine Extension im Statement den Commit enthalten, auf den sich das Verb bezieht, so dass Meta-Information auch deutlich später zuverlässig und unverändert zugreifbar ist, aber dennoch Weiterentwicklungen stattfinden können, durch den beibehaltenen Identifier die Bijektion und damit problemlose Auswertbarkeit in aggregierten Datensätzen nicht gefährdet ist.
Ein ausgeklügeltes Rechtemanagement, wie es alle fortgeschrittenen Implementationen von git mitbringen, stellt darüber hinaus eine sichere und zuverlässige Arbeit mit dem System sicher und ermöglicht dennoch die Verteilung der Verantwortung für den Erfolg auf viele Schultern. Aktive Entwickler, die zur kontinuierlichen Weiterentwicklung des Projektes beitragen wollen, können neue semantische Kontexte in Branches entwickeln und diese nach Fertigstellung in den Master-Branch mergen, One-Time-Stakeholder, die einen speziellen Kontext z.B. für ein Forschungsprojekt oder die Entwicklung eines neuen Produktes benötigen, können das Repository forken und im Anschluss über einen Pull-Request die Aufnahme ins Repository anstoßen. Bei vielen Mitwirkenden kann so schnell und unkompliziert eine Erweiterung stattfinden.
Natürlich kommt ein solches System nicht ohne Regeln aus. Diese sollten von der Community getragen und entwickelt werden, als Diskussionsgrundlage wird folgendes vorgeschlagen:
Kontexte werden dem Sinn nach in Ordnern angelegt. Jeder Ordner enthält eine weitere Ebene von Unterordnern entsprechend der Funktionalität des Vokabulars in xAPI: verbs, activities, extensions
Kontexte sollen semantische Eindeutigkeit herbeiführen, aber auch nicht übermäßig spezifisch werden 
Definitionen werden als Dateien im JSON-Format abgelegt
Es wird dringend angeraten, die Objekte mit Meta-Informationen anzureichern. Auch wenn die Spezifikation die Attribute gegebenenfalls nicht vorsieht, soll diese Meta-Information in der Darstellungsschicht gerendert werden können
Laut Spezifikation erforderliche Attribute müssen implementiert werden
Die Nutzung von LanguageMaps zur Implementation von Mehrsprachigkeit wird ausdrücklich begrüßt. Als gemeinsamer Nenner und generischer Fall-Back sind englischen Bezeichner obligatorisch
Um die künftige Aggregation auch mit bereits erfassten Daten zu vereinfachen, ist erstrebenswert, entsprechend der in der xAPI-Profile-Definition vorgeschlagenen Syntax bereits vorhandene, ähnliche oder gleiche Definitionen an anderer Stelle zu referenzieren
Das Repository soll neben den Definitionsdateien Informationen enthalten, die über den Sinn und Zweck des Repositories aufklären, den Mitwirkungsprozess mehrsprachig transparent darlegen und die o.g. Regeln zum Umgang mit dem Repository erläutern, jeweils im Markdown-Format. Einzige weitere Datei ist eine Konfigurationsdatei, die für das Zusammenspiel mit den übrigen Komponenten erforderlich ist.
## Die Darstellungsschicht
Die Darstellungsschicht ist im Gegensatz zum Datenrepository kein essentieller Bestandteil dieses Vorschlags. An der Darstellungsschicht wird ebenfalls aktiv gearbeitet, ebenfalls in einem Git-Repository und Mitwirkung ist gerne gesehen, allerdings handelt es sich hier nicht um einen kontinuierlichen Prozess mit Rolling-Release-Strategie, sondern verfolgt den Plan nach Fertigstellung als Referenzimplementation zu dienen und allenfalls bei Bedarf nach neuen Features noch einmal weiterentwickelt zu werden.
Die Darstellungsschicht soll der angenehmen Handhabung der Daten aus dem o.g. Repository dienen. Sie wird aktuell im Frontend als Single-Page-Application (SPA) auf React-Basis arbeiten. Im Backend stellt sie eine Rest-API zur Verfügung. Stellt ein Browser eine gewöhnliche HTTP-Anfrage, wird die SPA ausgeliefert, fordert die SPA Objekte an, erhält sie den vollen Umfang aus der Registry mit allen Meta-Daten, auf andere Requests antwortet der Server mit JSON-Objekten nach Spezifikation. So wird zum einen sichergestellt, dass eine maschinelle Auswertbarkeit möglich ist, dennoch jeder Interessierte, der sich mit einem Datensatz auseinandersetzt, vollen Zugriff auf die Metadaten erhält. Zudem kann diese Schnittstelle genutzt werden, um eine unmittelbare Anbindung an das Repository zu erhalten: Durch Continuous Integration werden Änderungen am Master-Branch im Repository unmittelbar an das Frontend weitergegeben.
Die Darstellungsschicht soll Nutzern zunächst ermöglichen den Definitionsbestand zu durchsuchen, zu filtern und zu sortieren, darüber hinaus werden im Laufe der Zeit Komfortfunktionalitäten wie Lesezeichen, die Drag-and-Drop-Zusammenstellung eigener “Wunschlisten” und variable Ansichten für verschiedene Zielgruppen folgen. Zudem soll es möglich sein, Veränderungen der Definitionen über das Interface nachzuvollziehen und gegebenenfalls auf spezifische Versionen zuzugreifen.
## Zusammenspiel, Erweiterbarkeit, Prozesse
Durch den geplanten Ansatz der Continuous Integration ist eine saubere Trennung von Daten und Anwendung umsetzbar und ohne Gefährdung der Integrität eigener Server möglich. Es ermöglicht die Entwicklung weiterer Anwendung mit unmittelbarem Zugriff auf die Definitionen ohne Exposition von Datenbankschnittstellen und kann, hinreichende Akzeptanz in der Community vorausgesetzt, aktiv das Open Data-Prinzip vorantreiben.
Gegenwärtig ist geplant, allen Mitgliedern der Forschungscommunity, die nachweislich an einer öffentlichen Forschungseinrichtung mit Bezug zur E-Learning- oder Learning-Analytics-Forschung arbeiten, die gleichen Maintainer-Rechte im Daten-Repository zu gewähren wie den Autoren dieses Beitrags. Es soll explizit keine zentrale Governance erfolgen, so dass diese ebenfalls weitere Maintainer hinzufügen können. Einzelentwickler oder Stakeholder mit kommerziellem Interesse erhalten auf Anfrage von den Maintainern Developer-Rechte. Damit können sie ihre Erweiterungen in eigenen Branches einpflegen, die dann nach Abschluss von den Maintainern in den Master-Branch integriert werden.
## Profile
Die Arbeit mit xAPI-Profilen wurde in diesem Beitrag nur am Rande behandelt und geht über die Grundlagenarbeit der Definition der Semantik einzelner Elemente deutlich hinaus. Profile erfordern klare Definitionen und stellen konkrete Anwendungszwecke dar, die nicht deckungsgleich mit den hier vorgestellten Kontexten sind. So könnte ein Profil “Serious Games on Multitouch-Tabletops” auf Definitionen aus den Bereichen Serious Games, Touchinteraktion und Kollaboration zurückgreifen, ohne sie vollständig abzubilden. Zudem definieren Profile Regeln, z.B. für Kombinationen aus Verben und Extensions in Statements oder geben Interaktionsschemata zur Validierung vor.
Derzeit ist ein “xAPI Profile Server” im Auftrag der ADL nach Spezifikationen des DoD in Entwicklung durch zwei amerikanische Consulting-Unternehmen, MakingBetter und Veracity Technology Consultants, der für September 2020 angekündigt ist. Gemäß dem technischen Bericht, der das Anforderungsprofil darstellt, sollte das hier vorgestellte Projekt in keinem Widerspruch dazu stehen. Die angekündigte Lösung wird nach Veröffentlichung einer gründlichen Prüfung unterzogen und die Darstellungsschicht dieses Projektes um eine Profile-Konfigurationskomponente erweitert. Gesetzt dem Fall der Vereinbarkeit mit dem Open Science-Gedanken können diese Profile dann entweder im ADL-Server abgelegt oder ggf. in einem dritten, noch zu planenden Repository abgelegt werden.