Project:Treffen-T1-20220114: Difference between revisions
No edit summary |
Added category |
||
(11 intermediate revisions by 3 users not shown) | |||
Line 14: | Line 14: | ||
== Vorstellung MaRDI Portal (15 Min, MS) == | == Vorstellung MaRDI Portal (15 Min, MS) == | ||
https://portal.mardi4nfdi.de | https://portal.mardi4nfdi.de | ||
* Daten werden in Wikibase DB gespeichert, modelliert nach Vorbild von Wikibase. | * Daten werden in Wikibase DB gespeichert, modelliert nach Vorbild von Wikibase. Wikibase ist das Content Management System | ||
* Wiki-Anfragen wurden anhand von Beispielsdaten aus DLMF und | * 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. | * Geplant: Änderungen aus dem DLMF werden automatisch im Portal gezogen. | ||
* Perspektivisch: Software und Publikationsdaten im Portal speichern | * Perspektivisch: Software und Publikationsdaten im Portal speichern | ||
* SPARQL Suchfunktion vorgeführt (https://query.portal.mardi4nfdi.de/) | * 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. | * MS ist selber an der Entwicklung von Wikidata Mathematik-Erweiterungen beteiligt. | ||
Line 25: | Line 25: | ||
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. | 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. | 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''' | '''Measures''' | ||
Line 31: | Line 31: | ||
Diese Measures werden von T1 empfohlen: | 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. | # 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. | # 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. | ||
# Verfahren zur Publikation von Daten standardisieren um Probleme mit der Reproducibility entgegen zu wirken | # 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. | # Predefined Software Environments sollen mithilfe von Docker zur Verfügung gestellt werden. | ||
# Mathematische Community sensibilisieren: Tutorials, Workshops | # Mathematische Community sensibilisieren: Tutorials, Workshops | ||
Line 41: | Line 41: | ||
''Frage JS: Ist es geplant, automatisiertes Checks für die Formatierung einzuführen? '' | ''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. | 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?'' | ''Frage TC: Wie sieht ihr euch im Portal?'' | ||
LK: T1-Entwicklung | 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. | |||
</blockquote> | </blockquote> | ||
'''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) | (Folgende Requirements wurden von T1 in Portal eingetragen) | ||
Line 58: | Line 64: | ||
: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> | ||
'' | ''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. | 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 | 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. | ||
</blockquote> | </blockquote> | ||
Line 70: | Line 76: | ||
;M1.4 Submit Dockerfiles and other formats of specifying software environments | ;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). | :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)== | ==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 | ||
MS: GitHub Repo für MaRDI kann benutzt werden, um | 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 | LK: Publikationsstandard von swMATH wird von T1 angewandt | ||
LK: Geplant: Teilnahme an Workshop für Workflows. Veröffentlichung in OSCAR-Buch. | 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)== | ==Nächste Termine (5 Min)== | ||
LK: Nächstes Treffen in 1.5-2 Monate. | 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. | 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. | ||
[[Category:Task Area Meeting Notes]] |
Latest revision as of 12:03, 24 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. 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:
- 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, allerdings Zenodo wäre eine gute Möglichkeit.
- 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, 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.