juckel
commented
2 years ago consolidated reply:
Hallo Uwe,
Hallo,
danke für den Entwurf, den ich mir eben mal angeschaut habe. Ich finde das Papier gut und auch gut, dass Ihr es gemeinsam mit den Kollegen geschrieben habt.
Vielen Dank für deine Mühen mit dem Paper und das lange Feedback!
Ein paar Fragen habe ich:
Es geht ja u.a. um die Brücke zwischen Invenio und GitLab, an dem Thema ist Tobias Huste ja auch schon eine ganze Weile dran und die RODARE-Invenio Brücke ist auch genannt. Aber Tobias kommt nicht vor, nicht als Mitautor und nicht als Referenz, das wundert mich etwas?
Wir haben das Repository entsprechend referenziert (https://gitlab.hzdr.de/rodare/invenio-gitlab). Der eigentliche Beitrag (der Gitlab-Invenio Connector) ist aus unserer Sicht nicht groß genug für eine Mitautorschaft auf diesem Konzeptpapier. Wir versuchen noch, die Brücke mit namentlicher Nennung so sauber wie möglich zitieren und nicht nur einen Link anzugeben.
Generell zeigt sich anhand dieses Repositories aber auch, warum es HERMES braucht, damit man hier entsprechend korrekt zitieren kann, da in dem Repository die im Konzeptpapier herausgearbeiteten notwendigen Metadaten nicht oder sogar widersprüchlich vorhanden sind. Zusätzlich gibt es kein Release (auf GitLab) und keine Veröffentlichung, z.B. als Zenodo/Dataverse-Publikation. Wir haben dafür ein Issue im Repository erstellt.
Bei den Metadatentypen fehlt mir das Thema Reference-/Test Data ein wenig, aber das ist vielleicht bei anderen Typen versteckt? Ich fände das rel. wichtig.
Hier denken wir, dass zu unterscheiden wäre zwischen einem Testdatensatz, der in automatisierten Tests (Unit/Integration) verwendet wird - hierbei würde es sich schlicht um einen Teil der Software handeln, der über die Softwaremetadaten mit abgehandelt wird - und einem Beispieldatensatz, der Benutzer*innen deutlich macht, wie die Software zu verwenden wäre, etc. Bei letzterem handelt es sich um ein eigenständiges Produkt, in den Softwaremetadaten als "relational metadata" referenziert werden kann. In beiden Fällen handelt es sich bei solchen Datensätzen nicht um eigentliche Metadaten der Software. Beim Verarbeiten von Repositories, die sowohl Software als auch Daten beinhalten behandeln wir diese - wie explizit im Paper beschrieben - als eigenständige Entitäten. Wir verstehen dieses Vorgehen als Teil guter Praxis. Abweichende Verwendung davon, bspw. Anwendung von HERMES-Tooling auf gemischte Repos ohne Unterscheidung der Entitäten, wäre somit fehlerhafte Verwendung.
Zum Thema Quality Metrics: versteckt sich hier die vom DLR verwendete Kategorisierung der Software, die die Qualitäts-Anforderungen definiert (siehe Echtzeit Steuerung versus einfaches quick Doktoranden-Script)?
Ja, aber nur als ein Beispiel generischerer Metriken, deren tatsächlich Verwendung von Einzelprojekten gesteuert sein kann, aber auch von Außenstehenden berechnet werden kann (z.B. in der SE-Forschung). Ein konkretes Beispiel sind Ergebnisse von Codeanalysen, sprachen- und toolunabhängig, bspw: Code Coverage, Complexity Metrics, CHAOSS Metrics, etc.
In Tabelle 1 hätte ich die Data Cite Attribute mit aufgenommen, auch wenn mir klar ist, dass die sich nicht decken. Aber es gibt den Zusammenhang nun mal und ich weiß nicht ob das quasi mit Zenodo abgebildet ist (wenn ja dann darauf hinweisen).
DataCite ist im Fließtext ja unter State of the art > Standards erwähnt, ist aber ansonsten zu generisch, als dass es hier explizit noch einmal als "Softwaremetadatenformat" diskutiert werden sollte.
Was im ganzen Dokument nicht vorkommt ist das Thema Berechtigungen. Wenn eine Software nicht oder nicht sofort open source sein kann, wie geht man damit um? Diese gibt es definitiv und sie sollte nicht unter den Tisch fallen! D.h. Berechtigungen (ggf. sogar auf einzelne Metadaten) und Embargo-Zeiten kann man ggf. nicht vernachlässigen?
Auch closed Software kann FAIR sein, solange die Metadaten zugänglich sind. Für Daten ist es übrigens ebenso. Wir haben dies im Paper noch etwas klarer dargestellt - danke für den Hinweis.
Eine Sache hätte ich mir als Ziel gewünscht: Wir wollen ja ein Helmholtz Software Verzeichnis aufbauen, das wäre ein sehr schönes „Abfallprodukt“ des Projektes. Wenn die Toolunterstützung einmal da ist wäre das mit vertretbarem Aufwand möglich. So hat man die Brücke gebildet und alle Metadaten verarbeitet, sie aber nicht Helmholtz-zentral such- und darstellbar gesammelt.
Das ist eine tolle Initiative. Wir möchten aber gleich darauf hinweisen, dass HERMES keinen eigentlichen Dienst anbietet, sondern nur eine Infrastruktur für den Transport von Metadaten. Diese Arbeiten sind aber im Future Work auch erwähnt. Wir sehen hier auch große Synergieeffekte zu HIFIS und auch MT-DMA.
Schöne Grüße. Uwe
Viele Grüße vom HERMES Team, Guido
Hallo,
danke für den Entwurf, den ich mir eben mal angeschaut habe. Ich finde das Papier gut und auch gut, dass Ihr es gemeinsam mit den Kollegen geschrieben habt.
Ein paar Fragen habe ich:
Es geht ja u.a. um die Brücke zwischen Invenio und GitLab, an dem Thema ist Tobias Huste ja auch schon eine ganze Weile dran und die RODARE-Invenio Brücke ist auch genannt. Aber Tobias kommt nicht vor, nicht als Mitautor und nicht als Referenz, das wundert mich etwas?
Bei den Metadatentypen fehlt mir das Thema Reference-/Test Data ein wenig, aber das ist vielleicht bei anderen Typen versteckt? Ich fände das rel. wichtig.
Zum Thema Quality Metrics: versteckt sich hier die vom DLR verwendete Kategorisierung der Software, die die Qualitäts-Anforderungen definiert (siehe Echtzeit Steuerung versus einfaches quick Doktoranden-Script)?
In Tabelle 1 hätte ich die Data Cite Attribute mit aufgenommen, auch wenn mir klar ist, dass die sich nicht decken. Aber es gibt den Zusammenhang nun mal und ich weiß nicht ob das quasi mit Zenodo abgebildet ist (wenn ja dann darauf hinweisen).
Was im ganzen Dokument nicht vorkommt ist das Thema Berechtigungen. Wenn eine Software nicht oder nicht sofort open source sein kann, wie geht man damit um? Diese gibt es definitiv und sie sollte nicht unter den Tisch fallen! D.h. Berechtigungen (ggf. sogar auf einzelne Metadaten) und Embargo-Zeiten kann man ggf. nicht vernachlässigen?
Eine Sache hätte ich mir als Ziel gewünscht: Wir wollen ja ein Helmholtz Software Verzeichnis aufbauen, das wäre ein sehr schönes „Abfallprodukt“ des Projektes. Wenn die Toolunterstützung einmal da ist wäre das mit vertretbarem Aufwand möglich. So hat man die Brücke gebildet und alle Metadaten verarbeitet, sie aber nicht Helmholtz-zentral such- und darstellbar gesammelt.
Schöne Grüße. Uwe