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 Management 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.

Softwareverfahren- code Schnittstellen standardisieren. Eigene Datenformate aus der Mathematik könnten standardisiert werden. OSCAR, Gap Aachen, Julia und ... mit diesen 4 Communitys hat T1 Kontakt, sie verwenden diese Datenformate.

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, allerdings Zenodo wäre eine gute Möglichkeit.
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, aber exemplarisch werden wir gängige automatisierte checks implementieren.

Frage TC: Wie sieht ihr euch im Portal?

LK: T1-Entwicklung ist nicht direkt mit der Portal Entwicklung in T5 verknüpft. 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.

Anwendungsfälle hauptsächlich von LK und TC:

• Zertifikat einpflegen und an Veröffentlichung koppeln
• Kurierte standardisierte exemplarische Elemente einbauen
• Guidelines in Zukunft einfügen als Referenzen ins Portal

(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.

Fragen JS: Soll JSON als einheitliches Format durchgezogen werden? Wird es file-format-converter geben?

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

TC: Wir werden im Portal nur ausgewählte Datensätze speichern. Standardmäßig werden die Datensätze verlinkt, zum Beispiel auf die Instanzen bei Zenodo.

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).

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 z. B. 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.

- guidelines sollen innerhalb der Projektlaufzeit im wiki definiert werden

Am Ende der Einwand, dass Standardisierung nicht nur Nationale Tragweite hat, sondern eigentlich International sinnvoll ist.

Nächste Termine (5 Min)

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

Mitte Februar mit T1 Kontakt aufnehmen.

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

JS: bitte zu NFDI Chat beitreten. Zugangsdaten folgen.