Konkrete Ratschläge für nachhaltigere wissenschaftliche Softwareprojekte

The English version of this article can be read on genr.eu.

 

Neben der Umsetzung der FAIR-Data-Prinzipien für Forschungsdaten beschäftigen wir uns an der TIB auch mit der nachhaltigen (Weiter-)Entwicklung, Nutzung und Publikation von Forschungssoftware. Dieser Blogpost stellt einen Zwischenstand des Aufbaus dieser Kompetenzen dar.

Außerdem soll er eine Serie einleiten, die ähnlich den schon erklärten FAIR-Prinzipien für Forschungsdaten (Kraft 2017), konkrete Beispiele und Handlungsempfehlungen für wissenschaftliche Softwareprojekte aufzeigt, Fachliteratur zusammenfasst (siehe die Literaturverzeichnisse) und auch uns selbst Ziele für eigene und von der TIB unterstützte Softwareprojekte setzt.

Die Empfehlungen sind in den verschiedenen thematischen Abschnitten teilweise an Wissenschaftler/-innen und ihre Institutionen getrennt adressiert, aber in jedem Fall etwa der Reihenfolge

  1. kurzfristig umsetzbare Verbesserung, über den
  2. nächsten erreichbaren Schritt, und
  3. die solide 80%-Lösung, bis zur
  4. wirklich guten Umsetzung

sortiert und mit ebenjenen Konnotationen versehen. Natürlich sollen sie auch als Diskussionsgrundlage verstanden werden, weswegen wir uns über Kommentare, Fragen, Anregungen, Kritik, Erfahrungsberichte usw. sehr freuen.

Zum Auftakt orientieren wir uns am FAIR-Prinzip der:

Auffindbarkeit (to be Findable)

Analog zu den Forschungsdaten können wir sagen, dass Software sowohl von Menschen als auch von Computersystemen leicht zu finden sein soll. Grundlegende maschinenlesbare beschreibende Metadaten ermöglichen die Entdeckung interessanter Softwareprogramme und -dienstleistungen. Mit Blick auf dieses erste Prinzip müssen in der Tat kaum Unterschiede zwischen Daten und Software gemacht werden.

F1. Einer Software wird ein global eindeutiger und dauerhaft persistenter Identifier zugewiesen

Was bedeutet das?

Jedes Softwareprojekt soll im Internet unter einem global eindeutigen und persistenten Identifier (PID) repräsentiert werden. Dies kann z.B. ein Uniform Resource Locator (URL) oder ein Digital Object Identifier (DOI) sein, damit Software und Metadaten auffindbar und zitierbar sind. Das Prinzip F1 kann mit als das wichtigste eingestuft werden, da es ohne “global eindeutige und persistente Identifier” schwierig ist, die anderen FAIR-Prinzipien zu erfüllen.

FAIRe Software – Die Rolle der Wissenschaftler/-innen

  1. Wenn ein Softwareprojekt nicht schon eine eigene Webseite hat, kann eine rudimentäre mittels (Konto und) Repository auf einer Quellcode-Hosting-Plattform angelegt werden. Da das meistgenutzte Quellcodeverwaltungsprogramm Git ist, erscheint dessen Nutzung in Kombination mit GitHub als populärster Plattform am anschlussfähigsten. Dies erzeugt eine global eindeutige URL unter der das Projekt gefunden werden kann.
  2. Da ein GitHub-Repo (Abkürzung für “Repository”) an Zenodo anbindbar ist, wird durch Befolgen dieser Anleitung eine DOI erzeugt, sowie eine von den Software Citation Principles favorisierte “Landing Page” (Smith, Katz, and Niemeyer 2016). Somit wird das Projekt global eindeutig zitierbar. Bonus: Zenodo zieht im gleichen Atemzug eine Sicherungskopie, sowie automatisch für jede folgende Release-Version). Ähnliches bietet das Open Science Framework, sowie das Projekt “Code as a Research Object” des Mozilla Science Labs. Letzteres nutzt primär FigShare, gegenüber dem wegen inadäquater Langzeitarchivierung leider einige Bedenken bestehen. Selbst wenn ein Datensatz gelöscht wurde, sollten seine Metadaten weiterhin angezeigt werden (“Grabstein”-Seite). FigShare tut dies leider momentan nicht, und lässt sozusagen das Datengrab namenlos. Sicherungskopien von Git-Repos können natürlich auch manuell heruntergeladen, und in generischen Forschungsdatenrepositorien wie RADAR zitierbar archiviert werden.
  3. Da DOIs erst vergeben werden sollten, wenn das zu identifizierende Objekt eine langfristige digitale Bleibe gefunden hat, kann für Entwürfe, Vorabversionen etc. auch ein Archival Resource Key (ARK) genutzt werden. Hier die Liste der ARK-vergebenden Institutionen.
  4. Schritt 2 könnte mit dem Startschuss für SoftwareHeritage.org sogar wegfallen! Diese “ehrgeizige Initiative zur Sammlung, Bewahrung und gemeinsamen Nutzung des gesamten Korpus an öffentlich zugänglichem Software-Quellcode” (Di Cosmo and Zacchiroli 2017), könnte laut Katz (2017) das Zitieren von Software einfachst-möglich machen: Software-Heritage erstellt automatisch persistente IDs (PIDs), sodass ein Quellcode-Repo zitierbar wird, sobald es veröffentlicht wird.

FAIRe Software – Die Rolle der Institutionen

  1. Wissenschaftliche Institutionen sollten ihren Mitgliedern Alternativen zu populären, zentralisierten Plattform bieten, indem sie moderne Quellcode-Hosting zur Verfügung stellen (wie bspw. git.TIB.eu), und ihre Langzeitverfügbarkeit garantieren.
  2. Um solch dezentrale Quellcode-Plattformen attraktiver für ihre Mitglieder zu machen, sollten Institutionen die funktionale Vollständigkeit (Pages, CI, etc.) und Aktualität sicherstellen. Dies betrifft auch ihre öffentliche Erreichbarkeit (wie bswp. beim Universitätskolleg Hamburg) oder im Fachbereich Informatik der Uni Bremen), sodass die Projekt-URLs als persistente, öffentliche Identifier genutzt werden können. Dankenswerterweise unterstützt GitLab die Persistenz, indem es im Falle einer Nutzer-, Gruppen- oder Repo-Namensänderungen fast alle nötigen URL-Umleitungen automatisch einrichtet. Auch wenn solche URL-Redirects nicht das gleiche Persistenzlevel erreichen, wie durch URNs oder PURLs, möglich ist, tragen auch sie ihren Teil zur dauerhaften Auffindbarkeit digitaler Objekte durch Menschen und Suchmaschinen-Crawler bei.
  3. Ähnlich wie die Zenodo-ver-DOI-ung von GitHub-Repos sollten auch institutionelle Plattformen DOI-Registrierungsdienste anbieten. Notfalls durch Eigenentwicklung oder Sponsoring entsprechender Freier-SoftwareModule.
  4. Institutionen, die Code-Hosting selbst betreiben, sollten deren Anbindung an SoftwareHeritage vorbereiten und ermöglichen, um die Zitierbarkeit der Arbeit ihrer Nutzerinnen und Nutzer zu vereinfachen.
  5. Auch für den Fall, dass die Softwareprojekte einer Institution über verschiedene Hosting-Plattformen verstreut sind, gibt es Abhilfe. Mittels eines Services wie DOE Code (Quellcode) kann den Entwickler*innen zentrale Archivierung angeboten werden, und Suchenden eine zentrale Anlaufstelle.

Soweit einige einleitende Ratschläge für nachhaltigere wissenschaftliche Softwareprojekte und speziell deren Auffindbarkeit mittels persistenten Identifiern (PIDs). Wie gesagt freuen wir uns über Kommentare, Fragen, Anregungen, Kritik, Erfahrungsberichte usw. Bald geht es in dieser Serie weiter mit konkreten Ratschlägen für FAIRere wissenschaftliche Software.

Literaturverzeichnis

Di Cosmo, Roberto, and Stefano Zacchiroli. 2017. “Software Heritage: Why and How to Preserve Software Source Code.” In iPRES 2017: 14th International Conference on Digital Preservation. Kyoto, Japan. https://hal.archives-ouvertes.fr/hal-01590958.

Katz, Daniel S. 2017. “Software Heritage and Repository Metadata: A Software Citation Solution.” Daniel S. Katz’s Blog. September 25, 2017. https://danielskatzblog.wordpress.com/2017/09/25/software-heritage-and-repository-metadata-a-software-citation-solution/.

Kraft, Angelina. 2017. “Die FAIR Data Prinzipien Für Forschungsdaten.” TIB-Blog. September 12, 2017. https://blogs.tib.eu/wp/tib/2017/09/12/die-fair-data-prinzipien-fuer-forschungsdaten/.

Smith, Arfon M., Daniel S. Katz, and Kyle E. Niemeyer. 2016. “Software Citation Principles.” PeerJ Computer Science 2 (September):e86. https://doi.org/10.7717/peerj-cs.86.

The following two tabs change content below.

Katrin Leinweber

...unterstützt im Team Forschungsdaten und wissenschaftliche Software interne und externe Projekte dieser Themenbereiche.

Neueste Artikel von Katrin Leinweber (alle ansehen)

5 Gedanken zu „Konkrete Ratschläge für nachhaltigere wissenschaftliche Softwareprojekte

    1. Hi Daniel! Sure, EN fine. A translation of this is planned, but as a cross post in order to support a colleague’s blog’s launch soon. I, A & R are supposed to be featured here in follow-ups, and I’ll be sure to include your SCIWG work then. Cheers 🙂

      1. Hi – my concern is not the software citation work specifically; that’s just one example of credit. It’s more that credit and attribution is not clearly part of FAIR, so while you didn’t touch on it in F, I’m concerned it doesn’t better fit in A, I, or R either.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.