Mit steigender Anzahl der Aufzeichnungen in Opencast steigt auch die Anzahl der administrativen Aufgaben. Um als Admin von der schieren Menge nicht erdrückt zu werden ist es wichtig, wiederkehrende Aufgaben möglichst zu automatisieren. Hier kommt das Lifecycle Management („Lebenszyklusmanagement“) ins Spiel, ein sich noch in der Entwicklung befindendes, neues Feature für Opencast. Es soll Admins erlauben, vordefinierte Aktionen zu vordefinierten Zeitpunkten auf einer vordefinierten Menge von Aufzeichnungen auszuführen, ganz automatisch. Der Fokus liegt hierbei zu Beginn auf dem Lebenszyklus einer Aufzeichnung, sprich auf der Publikation, Depublikation und dem schlussendlichen Löschen.
„Publikation“ beschreibt den Vorgang, eine hochgeladene Aufzeichnung seinem angedachten Publikum verfügbar zu machen. Für gewöhnlich werden in Opencast hochgeladene Aufzeichnungen auch alsbald publiziert (nach einer kurzen, automatischen Nachbearbeitung). Dies passt aber nicht zu jedem Lehrkonzept eines jeden Dozenten an jeder Hochschulen, oft werden ganz unterschiedliche Publikationszeitpunkte benötigt. Zum Beispiel sollen Aufzeichnungen einer bestimmten Vorlesung erst eine Woche danach verfügbar werden. Dahingehend ist es in Opencast bereits möglich, hochgeladene Aufzeichnungen nicht direkt zu publizieren, sondern erst später indem ein entsprechender Knopf gedrückt wird. Etwas was gerne Vergessen wird und so für Frust sorgt.
Das Gegenstück zur Publikation ist die Depublikation, also den Zugang zu einer verfügbaren Aufzeichnungen wieder zu verwehren. So könnte eine Anforderung an Aufzeichnungen in Opencast beispielsweise lauten:
Wir wollen am Ende des Wintersemesters 2024 automatisch alle Vorlesungsaufzeichnungen depublizieren, welche während des Semesters hochgeladen wurden. Vorlesungsaufzeichnungen gehören immer zu einer Serie. Konferenzen sollen hiervon ausgenommen sein, wie auch alle Vorlesungen des VIP Albert Einstein.
Wenn nun gegen Ende des Semesters mehrere solcher Anforderungen vorliegen kann auch erfahrenen Admins mal ein Fehler unterlaufen. Hier kann Lifecycle Management helfen Fehlern vorzubeugen und den Stress am Ende eines Semesters zu reduzieren.
Auch wenn Opencast mit über 100.000 Aufzeichnungen umgehen kann, ist es nicht immer sinnvoll alle jemals hochgeladenen Aufzeichnungen bis in alle Ewigkeit aufzubewahren. So fällt es Opencast Admins zu, in regelmäßigen Abständen Aufzeichnungen zu löschen welche vermutlich nicht mehr gebraucht werden. Eine mögliche Devise könnte zum Beispiel so aussehen:
Alle Aufzeichnungen, die älter als zwei Jahre sind, sollten täglich automatisch gelöscht werden. Konferenzen sollen hiervon ausgenommen sein, wie auch alle Vorlesungen des VIP Albert Einstein. Außerdem sind Videos ausgeschlossen, die zur Serie „Archiv“ gehören.
Hier ist nicht nur das manuelle Heraussuchen der entsprechenden Aufzeichnungen umständlich und zeitaufwendig. Es muss auch darauf geachtet werden ausgewählte Aufzeichnungen (wie etwa die des VIP Albert Einstein) nicht zu löschen. Außerdem gilt es, die Besitzer von zu löschenden Aufzeichnungen zu informieren, sodass diese Berufung gegen die Löschung einlegen oder zumindest ihnen wichtige Aufzeichnungen lokal sichern können. Dieser Prozess ließe sich mit Lifecycle Management automatisieren und würde eine ungemeine Arbeitserleichterung darstellen.
Zusammenfassend lässt sich sagen, dass Lifecycle Management zwar für das ein Videomanagementsystem nicht zwingend notwendig ist, aber für viele Nutzer eine so bedeutende Vereinfachung ihres Arbeitsalltags darstellt, dass man es nicht missen möchte. Lehrende sparen sich Erinnerungen in ihren Terminkalendern, da sie ihre Aufzeichnungen besser planen können. Und Admins sparen sich manuellen Arbeitsaufwand und damit bares Geld. Deswegen ist es wichtig, das Lifecyle Management besser früher als später in Opencast kommt.
Hier soll darauf eingegangen werden, wie Lifecycle Management in Opencast strukturiert werden soll. Den Kern bilden sogenannte Lifecycle Policy Objekte, die beschreiben was passieren sollte (action), wann es passieren sollte (time) und welchen Entitäten es passieren sollte (target). Im wesentlichen bestehe eine Lifecycle Policy aus den folgenden Eigenschaften.
Definiert, was Opencast tun soll. Für den Anfang gibt es nur die Aktion „Workflow starten“, mit der sich ein Opencast Workflow starten lässt. Mit Workflows lassen sich wiederum eine Vielzahl von Aktionen realisieren. Um beispielsweise Aufzeichnungen zu depublizieren, würden der Workflow „retract” ausgeführt werden. Was genau der Workflow „retract” tut, liegt dann im Ermessen der Administratoren der einzelnen Institutionen, d. h. er kann von jeder Institution nach eigenem Ermessen angepasst werden.
Legt fest, auf welche Entität in Opencast die Policy angewendet werden soll. Die beiden Entitäten, die wir in Opencast haben, sind Events (Aufzeichnungen) oder Serien. Zu Beginn werden nur Events unterstützt.
Kriterien, die weiter eingrenzen, auf welche Entitäten die Policy angewendet werden soll. Filter nutzen die Metadaten einer Entität. Eine Policy kann keinen, einen oder mehrere Filter haben. Wenn die Policy beispielsweise nur für eine bestimmte Serie gelten soll, kann sie den Filter „Serienkennung entspricht ID-av-portal“ haben. Damit die Policy für alle Videos eines Semesters gilt, kann sie die beiden Filter „Startdatum > 2023-12-20“ und „Startdatum < 2024-02 30“ enthalten, um alle Videos vom 20. Dezember 2023 bis zum 30. Februar 2024 zu löschen.
Der Zeitpunkt, zu dem eine Aktion ausgeführt werden soll. Es gibt drei Arten von Aktionsdaten.
Wurde nun eine Policy angelegt, prüft Opencast in regelmäßigen Abständen anhand des Timings ob es Zeit ist, die Policy auszuführen. Sobald es Zeit ist, werden anhand des Target Type und der Filter bestimmt, auf welche Entitäten die Policy angewandt wird. Hierbei wird auch geprüft, ob die Policy bereits auf entsprechende Entitäten angewandt wurde, um ein mehrfaches Ausführen zu verhindern. Zuletzt wird für jede Entität ein sogennanter Lifecycle Task erstellt, der sich um die Ausführung der in der Policy definierten Action kümmert.
