Project:Treffen-T1-20220114: Difference between revisions
No edit summary |
No edit summary |
||
Line 47: | Line 47: | ||
LK: T1-Entwicklung orthogonal zum Portal. Es soll ein Zertifikat für Papers nach der im Portal beschribenene Methoden erstellt werden. | 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. | |||
</blockquote> | </blockquote> | ||
Line 58: | Line 58: | ||
:Format wahrscheinlich JSON. Detaillierte Spezifikation auf weitere Wiki-Seiten. Community-Aspekt mitnehmen. | :Format wahrscheinlich JSON. Detaillierte Spezifikation auf weitere Wiki-Seiten. Community-Aspekt mitnehmen. | ||
<blockquote> | <blockquote> | ||
''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. | LK: Es wird mehrere Formate geben: XML etc. aber hauptsächlich JSON. Aber Community soll bei der Entscheidung mitbezogen werden. | ||
TC | TC: Wir speichern keine Daten. | ||
</blockquote> | </blockquote> | ||
Line 73: | Line 73: | ||
==Diskussion (15 Min)== | ==Diskussion (15 Min)== | ||
MS: Nachhaltigkeit: Workflows etc. können im Portal bearbeitet werden, aber sollen als nachhaltige Lösung perspektivisch publiziert werden. | 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 | 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 | LK: Dokumentation, Ideen werden im Portal dokumentiert | ||
Line 86: | Line 86: | ||
LK: Nächstes Treffen in 1.5-2 Monate. | LK: Nächstes Treffen in 1.5-2 Monate. | ||
TC: Mitte April als Ziel: Beispiel im Portal aufbauen. Kopplung T1/T5 verstärken. | TC: Mitte April als Ziel: Beispiel im Portal aufbauen. Kopplung T1/T5 verstärken. | ||
JS: bitte zu NFDI Chat beitreten. Zugangsdaten folgen. | JS: bitte zu NFDI Chat beitreten. Zugangsdaten folgen. |
Revision as of 14:52, 14 January 2022
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)
- Daten werden in Wikibase DB gespeichert, modelliert nach Vorbild von Wikibase.
- 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 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:
- 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.
- Autoren können nicht immer frei auswählen, wo sie ihre Daten speichern. T1 empfiehlt von daher keinen spezifischen Datenrepository.
- Verfahren zur Publikation von Daten standardisieren um Probleme mit der Reproducibility entgegen zu wirken
- Predefined Software Environments sollen mithilfe von Docker zur Verfügung gestellt werden.
- 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).
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.