Project:Treffen-T1-20220114

Anwesend: Lars Kastner (TU-Berlin), Moritz Schubolz (BU Wuppertal), Johannes Stegmüller (FIZ), Alvaro Ortiz (FIZ), Olaf Teschke (FIZ), Tim Conrad (ZIB), Jeroen Haselman (TU Kaiserslautern)

Moderation: JS

Begrüßung und Vorstellung (5 Min, JS)

TC: ZIB hat 3 Leute eingestellt, ab Mitte Februar

LK wird an der TU-Berlin ab April eingestellt in T1

JH: seit Dezember an der TU Kaiserslauten (T1) - Interessen: Reproducibility, Peer-Review- Process, Scalability

Vorstellung MaRDI Portal (15 Min, MS)

https://portal.mardi4nfdi.de

• Daten werden in Wikibase DB gespeichert, modelliert nach Vorbild von Wikibase. Wikibase ist das Content managment system
• Wikidata items haben Formel, DLMF information, Mathematischer Knowledge Graph soll aufgebaut werden. Wiki-Anfragen wurden anhand von Beispielsdaten aus DLMF und swMath vorgestellt
• Geplant: Änderungen aus dem DLMF werden automatisch im Portal gezogen.
• Perspektivisch: Software und Publikationsdaten im Portal speichern
• SPARQL Suchfunktion für Anfragen auf den Knowledge Graph vorgeführt (https://query.portal.mardi4nfdi.de/)
• MS ist selber an der Entwicklung von Wikidata Mathematik-Erweiterungen beteiligt.

Vorstellung Requirements + Anwendungen (15 Min, T1)

LK: Bei vielen Papers ist die Anwendung von Software XY und/oder Daten oft nicht nachvollziehbar. Verfahren und Workflows sollten besser standardisiert werden. Journals sollten nur Papers annehmen, wo die Software genügend dokumentiert ist, um das Experiment reproduzieren zu können. Idealerweise soll ein Reviewer maximal 30% seiner Zeit mit Software am laufen zu bringen verbringen. Oft fehlen Name des Software, Tests, clean Code etc.

Eigene Datenformate aus der Mathematik könnten standardisiert werden. Über einbeziehen entsprechender Communities (um OSCAR, GAP etc.) könnten standardisierte Datenformate Anwendung finden.

Measures

Diese Measures werden von T1 empfohlen:

1. TA1 empfiehlt die Anwendung von Jupyter Notebooks, weil Metadaten zu Software (Version etc.) automatisch dokumentiert werden. Darüber hinaus sind Workflows einfach in Jupyter Notebooks zu dokumentieren.
2. Autoren können nicht immer frei auswählen, wo sie ihre Daten speichern. T1 empfiehlt von daher keinen spezifischen Datenrepository.
3. Verfahren zur Publikation von Daten standardisieren um Probleme mit der Reproducibility entgegen zu wirken
4. Predefined Software Environments sollen mithilfe von Docker zur Verfügung gestellt werden.
5. Mathematische Community sensibilisieren: Tutorials, Workshops

Diese letzten 2 Measures werden in 1 Person kombiniert.

Frage JS: Ist es geplant, automatisiertes Checks für die Formatierung einzuführen?

LK: Geplant sind Beispiele oder Jupyter Notebooks. Automatisierte Checks sind nicht möglich für jedes Setup.

Frage TC: Wie sieht ihr euch im Portal?

LK: T1-Entwicklung orthogonal zum Portal. Es soll ein Zertifikat für Papers nach der im Portal beschribenene Methoden erstellt werden.

TC: Engere Zusammenarbeit mit T1 als im Antrag steht wäre nötig, sobald Personal bei T1 eingestellt ist.

(Folgende Requirements wurden von T1 in Portal eingetragen)

M1.1 Submit workflow guidelines, example usage, and related material

Es wird verschiedene Guidelines geben, es soll relativ einfach sein

M1.2 Submit database and -format specifications, examples, and related material

Format wahrscheinlich JSON. Detaillierte Spezifikation auf weitere Wiki-Seiten. Community-Aspekt mitnehmen.

Frage JS: Soll JSON als einheitliches Format durchgezogen werden?

LK: Es wird mehrere Formate geben: XML etc. aber hauptsächlich JSON. Aber Community soll bei der Entscheidung mitbezogen werden.

TC: Wir speichern keine Daten.

M1.3 Rating system for confirmability in cooperation with M1.1, database of annotated references

JH wird mit Journals kooperieren als Technical Editor.

M1.4 Submit Dockerfiles and other formats of specifying software environments

Docker, CI und Git. Tutorials und Dokumentation wird von T1 geschrieben (und nicht von T6).

(Anmerkung AO: M1.5 Submit tutorials and documentation based on the above wurde nicht besprochen)

Diskussion (15 Min)

MS: Nachhaltigkeit: Workflows etc. können im Portal bearbeitet werden, aber sollen als nachhaltige Lösung perspektivisch publiziert werden. Services etc. leben innerhalb einer Software Life Cycle. Das Portal ist nicht geeignet für nachhaltige Verfügbarkeit von Dokumentation. Das gute ist, wir können Items in WB Knowledge-Base hochladen. Neue Datentypen (z.B. Polynome) nur mit Vorsicht anwenden, damit es mit Wikipedia funktioniert, denn die Einführung neuer Datentypen in Wikipedia ist mit großer Aufwand verbunden, weil die Wikibase Community mitgezogen werden soll.

LK: Dokumentation, Ideen werden im Portal dokumentiert

MS: GitHub Repo für MaRDI kann benutzt werden, um zB. Templates für Projekte, Dockerfiles etc. zur Verfügung zu stellen (Dockerfiles, Actions).

LK: Publikationsstandard von swMath wird von T1 angewandt

LK: Geplant: Teilnahme an Workshop für Workflows. Veröffentlichung in OSCAR-Buch.

Nächste Termine (5 Min)

LK: Nächstes Treffen in 1.5-2 Monate.

TC: Mitte April als Ziel: Beispiel im Portal aufbauen. Kopplung T1/T5 verstärken.

JS: bitte zu NFDI Chat beitreten. Zugangsdaten folgen.