Zweites Community-Treffen

Bericht zum RDMO-Anwendertreffen ULB Darmstadt (07.10.2019)

Programm: [[1]]

Dort auch alle Slides vom Workshop.

11:15 RDMO Stand der Dinge (Jochen Klar)

• Teamvorstellung
• Vorstellung Releases, Ankündigung 1.0
• Details zur Überarbeitung Domänenmodell (maDMP)
• Details zur Mehrsprachigkeit
• Details Programmierbare JSON API
• Details zur eingeschränkten Mandantenfähigkeit
• Community
• Bitte um mehr Dokumentation zur API aus Community
• RDMO bittet um Use Cases

11:30 Status

Gerald Jagusch (ULB Darmstadt): RDMO für andere Einrichtungen durch die ULB Darmstadt

• Pilotimplementierung mit Uni Marburg bis Nov. 2019, bietet den Dienst momentan kostenlos für andere an, bei Interesse bei Gerald Jagusch melden
• Impetus für den Piloten: Forscher wollen nicht gerne Dienste nutzen, die kein Branding der eigenen Institution haben (was bedeutet das für forschungdaten.info-Instanz?)

Johannes Frenzel (Ruhr-Universität Bochum): Anforderungen aus Nutzersicht

• Feedback: fdm.nrw
  • Einstieg scheint sehr komplex
  • mehr Austausch gewünscht in der Community z. B. über Slack
  • Ausfüllen der Fragenkataloge erfolgt eigentlich kaum durch Forschende alleine (embedded data manager und dann auch kurze Fragenkataloge, Mehrfachabfragen)
  • wichtig sind Hilfetexte
• Wichtige Erweiterungswünsche (angelegt als Github issues 152-159):

Frage: Ist RDMO eigentlich so gedacht, dass die Forschenden es selbst ausfüllen oder mit Hilfe von Datenmanager

Strauch / Rathmann: RDMO in der Praxis. DFG-Fragenkataloge in FoDaKo und der Stiftung Universität Hildesheim

• FoDaKo-Fragenkataloge entwickelt nach DFG-Leitlinien und fachspezifischen Empfehlungen, mussten neue (Teil-)fragen erstellt werden und Anpassung an DSGVO und DSG NRW (sind auch super dokumentiert)
• Bereitstellung unter CCO-Lizenz über GitHub
• Feedback aus den Schulungen etc. (mit PIs als Teilnehmer*innen)
  • Bereitstellung Muster für einzelne Datenmanagementpläne
  • Einbindung von Grafiken in RDMO

11:45 Nachhaltigkeit und Zukunft RDMO (Harry Enke)

• Produktreife erreicht für Weiterführung

RDMO-Weiterentwicklung = Lösen von der Projektstruktur

• Ebene 1: Organisation der Anwender in einer AG
• Ebene 2: Organisation des Software-Developments
• Ebene 3: Finden einer passenden Verfasstheit auch für finanzielle Fragen

Ebene 1: Organisation der Anwender in einer AG Aufgabe und Ziel der AG ist die Bewahrung und Weiterführung von RDMO als nützliches Instrument im Datenmanagement Diskussion und Richtungsweisung der RDMO-Entwicklung, Interaktion mit den Software-Developern Ansprechstelle für Anfragen (Vorträge etc.) Organisation von Workshop, Meetings etc. Doppelspitze (aus Projekt und Community)

Ebene 2: Software-Entwicklung notwendig: (gewählter) Leader Maintainer, Contributors aus dem laufenden Projekt und der Community

Ebene 3: Finanzielle Fragen

• Es bleiben DINI, RDA-DE oder - aber erst später, als wir es jetzt benötigen - NFDI
  • DINI erste Gespräche geführt, positiv
  • RDA-DE, unklar, weitere Kontakte notwendig
    • wir als Projekt unparteiisch, beide Möglichkeiten gut
    • wichtig jetzt "RDMO"-Kern erhalten bis NFDI-Perspektiven deutlicher sind

Diskussion: Warum ist Vereinsgründung unrealistisch?

• bürokratischer Aufwand
• NFDI-Entwicklungen abwarten
• Open Source-Produkte leben von Community

Haben Sie mit der DFG gesprochen über Übergangsfinanzierung (wg. starken Interesse von NFDI-Konsortien)?

• Noch nicht wirklich. Dazu kommt, dass unabhängig von Zwischenfinanzierung, die Nutzergemeinde sich organisieren muss, damit sie weiterhin Einfluss nehmen kann, unabhängig vom Projekt und von Institutionen.

12:15 Aufteilung in Arbeitsgruppen - für die Thementische beim World Cafe (90 min. 2x45 min)

Vorschläge:

• Governance (Harry Enke)

• Organisation Softwareentwicklung (Jochen Klar)

• Metadaten, APIs & Repositorien (Ulrike Wuttke & Olaf Michaelis)

• Nutzerperspektiven (Kerstin Wedlich-Zachodin)

Ergebnisdokumentation Governance

Kurzprotokoll Thementisch Governance

Runde 1)

Mit der Eingangsfrage: wurden Weiter- oder Zwischen-Fördermöglichkeiten erwogen, ist die Diskussion schnell auf den Kernpunkt gekommen:

RDMO ist als Open-Source-Produkt bei sehr vielen Anwendern mittlerweile im Einsatz oder getestet, sodass sich eine einfache Projektförderung als nicht geeigneter Rahmen erweist. Es muss klar als eigenständige Community konstituiert werden, mit einer etablierten Organisation (Governance, Org. Struktur für die richtungsbestimmende Einflussnahme der Nutzer auf Software Maintenance und Entwicklung) und einem Software-Team mit aus der OpenSource-Community bekannten Prozessen. Nur dann kann es Bezug für neue Nutzer, Projekte oder auch für die NFDI (Konsortien) relevanter Ansprechpartner sein. Es gibt bereits Anwender, die gemeinsam mit dem Projekt diesen Prozess weiterbringen wollen und dafür auch Ressourcen bereitstellen.

Verschiedene Modelle wurden für die Verfasstheit einer solchen Weiterführung erörtert. (Kitodo, Re3Data, DSpace, FuD, ORCID, Beluga, Samvera). Keines der Modelle kann ein ‘fertiges’ Modell für RDMO hergeben.

Runde 2)

Einige weitere Modelle aus der obigen Aufzählung kamen hinzu. Einige Details aus der Software-Gruppe wurden noch hinzugefügt. Jedoch wurde die gleiche Schlussfolgerung wie in Runde 1 bekräftigt. RDMO ist kein Projekt mehr, und muss aus diesem Rahmen heraustreten.

Ergebnisdokumentaion Softwareentwicklung

Kurzprotokoll Thementisch Softwareentwicklung

Zusammenfassung Ergebnisse

Für die technische Koordination und Weiterentwicklung soll eine “Maintenance Group” (Name TBD) gebildet werden. Diese besteht aus Individuen die sich in der Softwareentwicklung von RDMO weiterhin engagieren wollen und können.

Aufgabe dieser Gruppe sind die Bearbeitung von Issues und Feedback, die Analyse und Schätzung von vorgeschlagenen Weiterentwicklungen, die Priorisierung von Arbeiten und die Beratung der übergeordneten Governance Struktur in technischen Fragen. Die Beteiligung in dieser Gruppe wird sich in zwei Gruppen gliedern, einen Kern, der sich Langfristig engagiert und auch relativ sicher einen Teil der Arbeitszeit entsprechend dedizieren kann und eine größere Gruppe von Entwicklerinnen und Entwicklern die möglichst niederschwellig eingebunden wird.Im Prinzip müsste auch eine ähnliche Gruppe für die Fragenkataloge, Domäne, etc. gebildet werden.

Die Arbeit erfolgt in Zusammenarbeit und Abstimmung mit der zentralen Governance-Struktur und den Projekten bzw. Auftragnehmerinnen und Auftragnehmern die RDMO weiterentwickeln. Eine wichtige Aufgabe ist hierbei zu entscheiden welche Erweiterungen in den Kern RDMOs übernommen werden. Die Möglichkeit des Aufbaus eines Anbieters für Dienste um RDMO wurde besprochen, und für realistisch gehalten. Die konkrete Gründung kann aber nur außerhalb der Nachhaltigkeitsaktivitäten erfolgen. In technischen Fragen würde das “Maintenance board” auch mit einem solchen Anbieter kollegial interagieren.

Essentiell für die Wartbarkeit von RDMO sind eine ausreichende Abdeckung mit Tests und die Nutzung von Continuous Integration.

In Zukunft könnte RDMO auch durch eine Nutzung in der Lehre, z.B. durch Abschlussarbeiten, weiterentwickelt werden.

Kurzprotokoll Thementisch Nutzerperspektiven

Ergebnisdokumentation Nutzerperspektiven

Runde 1) RDMO - unterschiedliche Nutzer: Wissenschaftler, Forschungsmanager, Datenmanager. Wie kann RDMO für die Nutzer attraktiver werden?

Frage nach der Entstehung/Hintergrund der verschiedenen Fragenkataloge: RDMO, DFG und speziell von der RWTH entwickelte. RDMO-Einstiegsseite wird als zu schwierig und nicht selbst erklärend genug empfunden, insbesondere fehlen Informationen zu den auswählbaren Fragenkatalogen. Hier wäre ein Hinweis zu den Förderern und dem passenden Katalog hilfreich - noch besser: bei Fördererangabe gleich ausgewählt.

Frage nach der Motivation: RDMO wird nur bei erkennbaren Mehrwert genutzt. Gut wären Ergänzungen durch Beispiele/Empfehlungen.

Wie ließe sich das umsetzen? Vorschlag: CMS bisherige Erfahrungen: RDMO-Nutzung meist mit Hilfe eines FDM-Referenten. Arbeiten die Forscher schon in einem Katalog, wird RDMO besser angenommen.

Erwartung der Forscher: vorformulierte Textbausteine. Beispiel DSGVO text generierte Vorlagen. Sonst steht WORD-Nutzung in Form eines Templates gegen RDMO: WORD VS RDMO Usability muss erhöht werden, aber wie? vielleicht eine Art RDMO light mit weniger Fragen in den Katalogen und mehr Hilfen - evtl. mit FAQ-Liste, die woanders wiederum gepflegt wird? Ein anderer Einstieg wäre gut und ohne Ansichten (sehr verwirrend und frustrierend). Ein Auto refresh button und ein anderer Fortschrittsbalken. Man sieht nicht wie viele Fragen schon beantwortet sind und wie viele noch fehlen.

RDMO Endnutzerwerkzeug oder Expertenwerkzeug? Im Moment eher Expertenwerkzeug, Forschende haben keine Erfahrung im FDM. Beratungen/Workshops von Nöten. Soll es ein Endnutzerwerkzeug werden?

FD-Manager: wie pflegen - zu komplex. RDMO ist nicht CMS-mäßig gemacht. Gibt institutsspezifische Ergänzungen/Bearbeitungen. Nur Grundfunktionalitäten? Pflege kostet viel Zeit - möglich durch ein einfaches Attribut? Hilfetexte: geht nur bei eigener Instanz. In Wordpress/im Wiki erstellen und auf der Instanz verlinken. Gemeinsames CMS?

Runde 2) RDMO verschiedene Nutzerrollen - Positive/negative Erfahrungen

Positiv: im SFB beispielsweise gibt das Institut vor, einen DMP zu erstellen und zu pflegen. Bei Zuschneidung des Fragenkatalogs auf den SFB empfanden die Forscher RDMO als nützlich. Verbesserungsfähig: mögliche Prozessabbildungen (Flussdiagram), Workflow ist bei der Zusammenarbeit bisher schwierig.

Negativ/Verbesserungsfähig: Oberfläche zu textlastig, mehr buttons gewünscht, zu viel durchklicken. FDM-Services vor Ort auswählbar, möglichst editierbare Bausteine, zentrales Repo für Fragenkataloge mit Update-Erkennung. Gut wäre eine Art Vorfragenkatalog. GWP fordert Dokumentation von Forschungsdaten - wie sieht es mit der kontinuierlichen Dokumentation in RDMO aus? Problem Bearbeitung von fremden Fragenkatalogen: Veränderungen werden bei neuem Update überschrieben? Vehicle: Ein Element um FDM Forschenden nahe zu bringen - um untereinander ins Gespräch zu kommen.

Zusammenfassung Ergebnisse

Drei verschiedenen Nutzergruppen, Wissenschaftler, Forschungsmanager und Datenmanager, ziehen unterschiedliche Anforderungen nach sich. Wissenschaftler/in: Es fehlt ihnen meistens der Hintergrund zum FDM, wodurch die Beantwortung der Fragenkataloge schwer fällt. Ohne entsprechende Beratung eines FDM-Experten oder einer fachspezifischen Anpassung des Fragenkatalogs wird RDMO nur selten genutzt. Bei entsprechender Einführung/Anpassung wird RDMO als nützlich angesehen (Bsp. SFB).

Forschungsdatenmanager: Die Pflege von RDMO wird als zu komplex und zu zeitintensiv empfunden. Oberfläche von RDMO sollte vereinfacht und mit Erklärungen/Hilfetexten/FAQs ergänzt werden, möglichst mit Verlinkung an ein Wiki, wo diese Texte gepflegt werden können. In Frage käme auch ein Content Management System. Fragenkataloge sollten in einem Repo gesammelt werden mit einer Update-Erkennungs-Funktion. Fragenkataloge müssen verbessert und vereinfacht werden, Textbausteine generiert werden.

Gewünschte Features: Auto-refresh button, Fortschrittsbalken mit Fragennummerangabe, Prozessabbildungen (Flussdiagram), Workflows zur besseren Zusammenarbeit

Kurzprotokoll Thementisch Metadaten, APIs & Repositorien

Runde 1) Thema Interoperabilität RDMO maDMP-Standard maDMP abgelegt hier: https://github.com/RDA-DMP-Common/RDA-DMP-Common-Standard DataCite RDMO: ist im Groben und Ganzen möglich, aber Einzelfälle sind teilweise schwierig, z.B. Feld Creator Bestimmte Attribute müssten sicherlich noch zugefügt werden (z.B. Name des DMP) Interesse an Vorschlagslisten bekundet (Drop-Down)

Bericht: Forschende müssen momentan oftmals die Information mehrmals bereitstellen, da wäre eine Standardisierung sinnvoll, damit Daten schon von woanders geholt werden, um DMPs für Forschende interessant zu machen, ist unbedingt redundante Dateneingabe zu vermeiden, von daher sind solche Informationen zu begrüßen (weniger Redundanz auch gut für Datenmanager*innen)

• Frage, wo ist RDMO-Medadatenmodell dokumentiert
  • es gibt noch keine textliche Information zum Metadatenmodell, aber man kann es auf GitHub runterladen

• Frage, wo ist die Dokumentation zur API?
  • Read the Docs, kann gerne erweitert werden
  • Thema: Momentan ist Dokumentation und Read the Docs und FAQs etwas verwirrend, weil an verschiedenen Stellen und vielleicht auch nicht immer ganz aktuell

• Diskussion Tokens: hier wäre es besser verschiedene Rechte für die Tokens (nur Get, nur Post, ... ) zu spezifizieren

-Verknüpfung mit bestimmten Bedingungen wie zum Beispiel, das Projekt ist an der Uni angesiedelt und damit ist der Datenschutzbeauftragte der Uni verantwortlich wären gut

Frage: Was passiert eigentlich mit den Datenmanagementplänen? Werden sie veröffentlicht, z.B. mit der Datenpublikation? Werden sie weiter bearbeitet? Kommentar: ist nicht unbedingt vorgesehen, aber die Forschenden scheinen dafür offen zu sein. Problem ist aber durchaus Datenschutz, z.B. Namen von Projektmitarbeitern. Ist aber noch Zukunftsmusik, da es erst in Richtung 2020 um Publikationen geht. Inwieweit sollte RDMO Publikationstool für Datenmanagementpläne sein? Ist der PDF-Export ausreichend zur Veröffentlichung?

Frage: Was ist der Zweck der Veröffentlichung von FDM-Plänen?

• Anforderung der Förder: FDMP ist z.B. Anforderung in H2020-Projekten.
• Als Dokumentation der Daten, wenn es auch nur ein Anfang ist
• Best Case Szenario (Didaktisch), für Projektplanung (könnte bei kleineren Communities sogar Sinn machen als machine actionable, weil es sowieso immer die gleichen Leute sind)

Verknüpfung RDMO mit Fachrepositorium Lebenswissenschaften (oder Radar) = Schnittstelle

• Welche der Felder brauchen wir eigentlich unbedingt? Radar hat z.B. 10 Pflichtfelder
• Gab/Gibt es Bestrebungen, das RDMO Repositorien empfiehlt? Nein.

Runde 2)

• Anforderung Standardisierung / machine actionable
• Export von Metadaten in elektronischen Laborbüchern in RDMO um nicht doppelt auszufüllen und hinterher zusammen mit den Forschungsdaten zusammen ins Repositorium
• ist geplant Datalinker in MaMoDar
• wir brauchen konkrete Anwendungsfälle (gerne per E-Mail an RDMO-Team)
• Frage ScieboRDM Cloud-Lösung und RDMO
• NextCloud und RDMO-API sollten miteinander kommunizieren können bzw. die Forschungsdaten und der Datenmanagementplan automatisch miteinander verknüpft sind
• Frage: Ist geplant, dass aus RDMO ein Export in ein DataCite fähiges Format möglich ist
• Austausch ist hier sehr gewünscht (Interesse angemeldet Birte Cordes für Marburg für ihr Repository, dass auf DSpace basiert)
• Verknüpfung RDMO und FIS ist erwünscht, aber auch ein Problem, da sehr große Heterogenität und viele FIS Systeme nicht offen (EuroCRIS, SAP), da werden wir priorisieren müssen (HIS, Pure)
• Wenn RDMO ein Stand alone Modul bleibt, wird die Akzeptanz sinken (oder zumindest nicht steigen)
• Zustimmung für Priorisierung DataCite-Export > Interessenbekundung aus Community (hier anzuliefern, welche Felder sie als absolut wichtig finden

Zusammenfassung Ergebnisse: Im Mittelpunkt des Thementischs stand die Diskussion um die Möglichkeiten der Verknüpfung von RDMO mit anderen Systemen, d. h. um die Möglichkeiten der Übernahme von Metadaten und somit der Vermeidung redundanter Dateneingaben, da die Akzeptanz von RDMO davon abhängen wird, dass es kein Stand-Alone-Tool bleibt. Hier gilt es zum einen Systeme zu identifizieren für die Schnittstellen gewünscht sind, zum anderen Interoperabilität durch die Programmierung entsprechender APIs und Mappingverfahren bzw. Anpassungen am RDMO-Metadatenschema herzustellen.

Als Zielrichtungen wurden besonders intensiv diskutiert die Interoperabilität von RDMO mit DataCite, die wichtig für die Verknüpfung mit Repositorien ist, sowie die Interoperabilität mit dem neuentwickelten maDMP-Standard (https://github.com/RDA-DMP-Common/RDA-DMP-Common-Standard) und Verknüpfungsmöglichkeiten mit Forschungsinformationssystemen oder elektronischen Laborbüchern. Die Gruppe favorisierte die Fokussierung auf DataCite, da hier ein unmittelbarer Mehrwert entsteht und DataCite relativ weit verbreitet ist. Es ist ein enger Kontakt abgesprochen zwischen dem RDMO-Team und Teilnehmer*innen, die mit Repositorien/DataCite Erfahrungen haben. An zweiter Stelle der Bestrebungen sollte Interoperabilität mit maDMP stehen um international anschlussfähig zu bleiben. Bzgl. elektr. Laborbücher ist im Projekt MaMoDar ein Pilot (Datalinker) geplant, dessen Ergebnisse abgewartet werden sollten, bzgl. der FIS besteht momentan sehr große Vielfalt, daher sollte das Thema sollte hintenangestellt werden. Außerdem haben wir den Aufruf, Fragenkataloge über RDMO-GitHub bzw. Olaf Michaelis zu teilen wiederholt.

Zusätzlich wurden folgende Nutzeranforderungen an das Team geäußert:

• textliche Dokumentation zum RDMO-Metadatenschema (zusätzlich zur Bereitstellung auf GitHub)
• umfangreichere Dokumentation zur RDMO-API
• übersichtlichere Bereitstellung und Aktualisierung der existierenden RDMO-Dokumentation, Read-the-Docs und FAQs etc.
• Entwicklung verschiedener Rechte-Rollen für Tokens
• Vorschlagslisten als Drop-Down
• schauen, wie ist es mit Input, z.B. über ORCiD

15:30 Zusammenfassung der Thementische und Abschlussdiskussion

Governance

• Diskussion von Vorbildern (Open Source) wie DSpace, ORCID, etc.
• Diskussion von Möglichkeiten zum Andocken, DINI war Favorit
• RDMO braucht eigenen Governance
• Gemeinnützigkeit muss bleiben (ist auch Voraussetzung für NFDI)
• zweite Runde Schwerpunkt auf Finanzierung, wenn RDMO kein Projekt ist, muss die gesichert sein, aber nicht wie RADAR, Geldbeiträge oder Entwicklerpower? Geld wäre einfacher, z.B. Abwicklung über DINI
• Gremien wie BOARD werden gebraucht, Nutzerbeirat, Problem, momentan nur zwei Entwickler Gruppe (siehe Foto) hat sich gebildet, die Governance ausarbeiten will (basierend auf heutigen Ergebnissen), wie Memorandum of Understanding, dass Institutionen unterzeichnen sollen können
• wer dazu kommen will, soll Mail an Harry Enke schicken
• nur die, die auch über Projektlaufzeit sich committen wollen

Nutzerperspektive

• Vorschläge zur Verbesserung (z.B. Einstiegsseite)
• Diskussion über warum zu DMPs, warum RDMO (Mehrwerte besser herausarbeiten für Nutzer*innen)
• Diskussion, dass RDMO besonders gut aufgeht, wenn es auch an andere Tools, Dienste angekoppelt wird, wie es auch schon geschieht
• Nutzer: Wissenschaftler, Forschungsmanager, Datenmanager
• Diskussion: Eignet sich RDMO als Endnutzerwerkzeug? Momentan: Für Forschende sehr viel Beratung/Unterstützung notwendig. Ziel war aber Endnutzerwerkzeug, momentan ist es Expertenwerkzeug. Aber es war auch immer so gedacht, dass sich verschiedene Personen beteiligen
• Problem ist u.a. "Design der Fragenkataloge"? > z. B. kontextsensible Antwortoptionen (welche Datenschutzleitlinien kommen denn überhaupt in Frage)

Softwareentwicklung

• "Maintenance Group"
• Wartungsverträge/Support Verträge (müsste eigenständig aufgesetzt werden, aber in Kooperation mit anderen RDMO-Gremien)
• Community Management / Fragenkataloge > Content > anderer Prozess, der auch gesteuert werden muss
• RDMO soll Open Source bleiben, wichtig ist aber Kommunikation und Tests
• Festen Kern erhalten und niedrigschwellige Beteiligung
• Was haben Institutionen davon, dass sie sich beteiligen?
• Aufruf, sich zu beteiligen, vor allem an diejenigen, die schon mehr Erfahrungen haben
• Diskussion: noch ganz viele Entwicklungsanforderungen, aber wer soll das bezahlen, Tenor scheint zu sein, dass RDMO schon ein Infrastrukturservice ist, den es schon gibt .

Metadaten, APIs, Repositorien

• Schwerpunkt lag auf DataCite und maDMP Interoperabilität, wichtig Vermeidung redundante Dateneingabe
• Aufruf zum Teilen von Fragenkatalogen (per Mail an Olaf Michaelis, oder über GitHub)

Zusatz: schauen, wie ist es mit Input, z.B. über ORCiD

Zusammenfassung

Ziel des Workshops neben Nutzeranforderungen, Test-the-Waters für Beteiligung und Outline Governance Harry Enke will mit der Gruppe MoU formulieren, wie Institutionen sich beteiligen können, damit die Organisation beim nächsten Treffen gründen kann. An diesem Treffen sind bereits Organisationen/Institutionen dabei, die bereit sind, sich längerfristig zu engagieren.

Das ist kein juristisch belastbares Dokument, sondern es sind Gesprächsnotizen. Ergänzungen etc. willkommen.