Was bleibt von ONE.UP?
Verstetigungsangebot des Dashboards und der dazugehörigen Infrastruktur
Die technische Infrastruktur zum Dashboard besteht aus zwei Komponenten: der Server und das Dashboard. Beide Komponenten können getrennt voneinander weiterentwickelt und bereitgestellt werden. Das Dashboard bezieht die Daten für die Visualisierungen vom Server, hingegen ist keine physische Nähe beider Systeme nötig. Dies führt zu einem flexiblen Betrieb des Systems.
Das Dashboard hat verschiedene Optionen in weitere technische Entwicklungen an der Universität Potsdam integriert zu werden. Durch die Simulation von Daten kann dieses Dashboard als Plattform für weitere Untersuchungen oder anders strukturierte Forschungsfragen genutzt werden. Es können noch andere Aspekte der Wissenschaftskommunikation untersucht werden, wie beispielsweise die Motivation von Einzelpersonen über ihre eigene Arbeit zu kommunizieren. In diesem Fall könnte simuliert werden, dass sich ein Interesse an Forschungsthemen in den Medien erhöht (oder verringert). Dies könnte Auswirkungen auf die Motivation der Wissenschaftler:in haben und Personen entwickeln dadurch ein Interesse, um über das eigene Thema zu kommunizieren. Eine unterstützende Eigenschaft des Systems ist, dass Nutzungsprofile im Dashboard erstellt werden können und Nutzende so zu ihrem persönlichen Dashboard zurückkehren können. Für weitere Untersuchungen wird auch gespeichert, welche Komponenten genutzt werden und wie lange ungefähr die Nutzenden im System aktiv sind. Diese Identifikationsnummer der Nutzenden kann in einer begleitenden Umfrage festgehalten werden, sodass die Antwort aus dem Fragebogen mit dem tatsächlichen Nutzungsverhalten verglichen werden kann.
Für den Einsatz in Produktivsystemen wurde eine Möglichkeit geschaffen, um die Komponenten des Dashboards in die Plattform Campus.UP zu integrieren. Es gab leider keine Option dies automatisch umzusetzen, hingegen wurde ein Umwandlungsprozess manuell erprobt und dokumentiert. Darüber hinaus kann das Dashboard aber auch in andere Plattformen integriert werden oder auf Webseiten eingebunden werden.
Wie schon oben erwähnt, sind der Server und das Dashboard voneinander getrennt. Das heißt, die Visualisierungen beziehen ihre Daten aus einer Schnittstelle des Servers. Diese Schnittstelle ist offen konzipiert worden und lädt somit ein, weitere Anwendungen oder Visualisierungen zu entwickeln.
Im Sinne der Sicherung guter wissenschaftlicher Praxis wurde der Quellcode öffentlich zugänglich gemacht, dokumentiert, alle Beteiligten Personen damit verknüpft und Entscheidung nachvollziehbar erläutert.
Weiterverwendung der erhobenen Daten
Alle Daten, die im Projekt erhoben wurden, wurden unter einer freien Lizenz zur Verfügung gestellt. Darunter zählen die Daten, die zur Evaluation erhoben wurden sowie die Ergebnisse des Workshops zur Ermittlung von Applikationen für das Dashboard.
Hackathon als Kollaborationsformat im Transfer
Der Hackathon „Open Data – Open University“ konnte zwei Mal erfolgreich durchgeführt werden. Das Ziel des Hackathons war es, offene Datenquelle der Universität Potsdam zu finden und diese in einem zeitlich verknappten Format mit Studierenden zu nutzen. Dem liegt die Annahme zu Grunde, dass offene Daten von verschiedenen Akteuren aus der Gesellschaft genutzt werden können. Dabei ist es wichtig, nicht nur Daten offen zur Verfügung zu stellen, sondern auch den Kontext in den die Daten entstanden sind zu erläutern und zu beschreiben, was in der Datenmenge alles enthalten ist.
Folglich hat der konzipierte Hackathon zwei Perspektiven: die Perspektive der Institution und Forschung, welche die Daten verarbeitbar präsentieren müssen und die Perspektive der Datenkonsumenten, welche in diesem Format die Studierenden mit Kenntnissen zur Datenverarbeitung und -visualisierung sind.
Der Zuspruch zum Format war ausschließlich positiv. Von den Forschungsprojekten, Lehrstühlen und Institutionen der Universität Potsdam gab es ein großes Engagement in der Zusammenarbeit. Daraus entstanden über 20 Challenges, die jeweils ein Vorschlag für ein mögliches Anwendungsszenario in der Domäne darstellt. Durch die Zusammenarbeit in der Erstellung der Challenges festigte sich der schon beschriebenen Eindruck, dass offene Daten für eine nicht domänespezifische Nutzerschaft keine Selbstverständlichkeit ist.
Die Veranstaltungen konnten leider nicht den gleichen Partizipationswillen bei den Studierenden erzeugen und führte zu einer mäßigen Teilnehmerzahl. Trotzdem haben sich zu zwei Terminen jeweils ein Team gefunden, die mit großer Begeisterung an einer Lösung gearbeitet haben und diese am Ende der drei Tage auch präsentieren konnten.
Als Veranstaltungsformat hat der Hackathon „Open Data – Open University“ keinen Raum für Verstetigung gefunden, aber das Event hat dafür gesorgt, dass sich Forschungsprojekte oder zentrale Einrichtungen weitere Gedanken über die Öffnung ihrer erhobenen Daten machen. Zusätzlich wurden auch Abschlussarbeiten angestoßen.
Lessons Learned: Digitalisierung im Transfer bedarf digitale und automatisch auswertbare Datenquelle
Es ist ersichtlich geworden, dass es eine zentral organisierte, digitale Infrastruktur mit administrativen Daten bedarf, welche aus allen Bereichen der Hochschule dezentral eingepflegt werden, um Anwendungen zu schaffen, die den Forschungsbereich in den Aufgaben über Forschung und Lehre hinaus unterstützen. Dabei kann ein Hochschulinformationssystem (HIS) ein guter Ausgangspunkt sein.
Alle in den Publikationen vorgestellten Anwendungen brauchen diese Daten als Basis. Wenn die Daten lediglich dezentral erhoben werden und nicht in eine zentrale Datenstruktur überführt werden, müssten bei einer Applikation, welche täglich, wöchentlich oder monatlich aktuelle Daten benötigt, bei jeder Datenaktualisierung manuelle Arbeitsschritte durchgeführt werden. Dies erhöht die Fehleranfälligkeit einer Applikation.
Um Misstrauen gegen die zentral gepflegten Daten vorzubeugen, sollte sowohl transparent dargestellt werden, wozu diese Daten benötigt werden und welchen Mehrwert es für die einzelnen Akteure gibt. Ansonsten läuft die Neueinführung dieses Systems sofort Gefahr, nicht ausreichend genutzt zu werden. Dadurch wird die Datenqualität verschlechtert und Anwendungen, welche darauf aufbauend, verlieren dadurch auch an Glaubwürdigkeit und Nutzen.