So erstellen und pflegen Sie mit DataLad einen multimodalen Tierversuchsdatensatz

Jul 08, 2023

Scientific Data Band 10, Artikelnummer: 357 (2023) Diesen Artikel zitieren

1 Altmetrisch

Details zu den Metriken

Für die gemeinsame Nutzung von Daten, Verarbeitungstools und Arbeitsabläufen sind offene Datenhostingdienste und Verwaltungstools erforderlich. Trotz der FAIR-Richtlinien und der steigenden Nachfrage von Förderagenturen und Verlagen teilen nur wenige Tierstudien alle experimentellen Daten und Verarbeitungswerkzeuge. Wir präsentieren ein Schritt-für-Schritt-Protokoll zur Durchführung der Versionskontrolle und Remote-Zusammenarbeit für große multimodale Datensätze. Um neben einer homogenen Datei- und Ordnerstruktur auch die Datensicherheit zu gewährleisten, wurde ein Datenmanagementplan eingeführt. Änderungen an den Daten wurden mithilfe von DataLad automatisch verfolgt und alle Daten wurden auf der Forschungsdatenplattform GIN geteilt. Dieser einfache und kostengünstige Workflow erleichtert die Einführung von FAIR-Datenlogistik- und -verarbeitungsworkflows, indem die Roh- und verarbeiteten Daten verfügbar gemacht und die technische Infrastruktur bereitgestellt werden, um die Datenverarbeitungsschritte unabhängig zu reproduzieren. Es ermöglicht der Community, heterogen erfasste und gespeicherte Datensätze zu sammeln, die nicht auf eine bestimmte Datenkategorie beschränkt sind, und dient als technischer Infrastrukturentwurf mit großem Potenzial zur Verbesserung der Datenverarbeitung an anderen Standorten und zur Ausweitung auf andere Forschungsbereiche.

Für die Datenverwaltung und -freigabe sind Best Practices erforderlich, wie sie kürzlich für die menschliche MRT eingeführt wurden1,2. Unserer Erfahrung nach sind die meisten Labore auf eine nicht standardisierte Datenspeicherung auf lokalen Festplatten oder Netzlaufwerken mit unzureichender Benutzerverwaltung und Backup-Kapazität angewiesen. Trotz der Tatsache, dass nur eine Minderheit der MRT-Studien kleine Tiere verwendet, ist es alarmierend, dass auf OpenNeuro, einer weit verbreiteten Plattform für den Datenaustausch in der Neurobildgebung3, nur 3 % der Datensätze Daten von Mäusen oder Ratten enthalten. Auch auf einer anderen beliebten Datenaustauschplattform, die nicht spezifisch für Neuroimaging ist, Zenodo4, stammen nur etwa 30 % der MRT-Datensätze von Mäusen oder Ratten. Darüber hinaus ist es überraschend und widerspricht den FAIR-Prinzipien5, wenn in den meisten dieser Neuroimaging-Datensätze nur die Bilddaten bereitgestellt werden. Dies schließt einen großen Teil der Begleitdaten aus, z. B. die Mikroskopiedateien, die für die In-vivo-Kreuzvalidierung verwendet werden. Wir haben außerdem einen deutlichen Mangel an Schritt-für-Schritt-Anleitungen oder automatisierten Routinen festgestellt, die zur Reproduktion der verarbeiteten Daten erforderlich sind. Diese Beispiele unterstreichen frühere Berichte6, dass der Austausch von Kleintierdaten alles andere als üblich ist und dass es keine Standardisierung in Bezug auf die Datenerfassung, -speicherung und -weitergabe gibt. Wenn Daten nicht geteilt werden und somit nicht zur Weiterverwendung zur Verfügung stehen, wie dies bei 93 % der biomedizinischen Open-Access-Publikationen der Fall ist7, steht dies auch in starkem Widerspruch zum 3-R-Prinzip der Minimierung der Anzahl von Tierversuchen8. Daher bleibt es sehr schwierig, Studien zwischen verschiedenen Labors zu vergleichen, was zur Reproduzierbarkeitskrise beiträgt9, und Kleintierstudien (Neuroimaging) bilden da keine Ausnahme10.

Wir stellen uns einen Wandel hin zu den Bedingungen guter wissenschaftlicher Praxis und den Prinzipien von FAIR – Findable, Accessible, Interoperable, Reusable5 und Open Science2 vor, um die Zuverlässigkeit und Anerkennung von Tierversuchen zu verbessern. Unser Ziel war es, einen einfach anwendbaren Ansatz zum Aufbau eines multimodalen Datensatzes zu schaffen, der Zugriff auf Roh- und verarbeitete Daten, Methoden, Ergebnisse und deren Herkunft bietet. Ein ordnungsgemäßes Forschungsdatenmanagement (RDM), wie es zunehmend auch von Förderagenturen und Verlagen gefordert wird, ist der Schlüssel zur Erfüllung dieser Standards2,11,12.

Hier beschreiben wir unsere Strategie für die Datenorganisation, Metadatenerfassung und Daten-/Analyseverfolgung mithilfe von drei etablierten Tools: unserer relationalen Datenbank13, der Datenplattform GIN (G-Node Infrastructure Services, https://gin.g-node.org) und die Forschungsdatenmanagement-Software DataLad14. Die Datenbank wird verwendet, um alle experimentellen Metadaten über den gesamten Verlauf longitudinaler und multimodaler Tierversuche zu sammeln, einschließlich MRT, Histologie, Elektrophysiologie und Verhalten. GIN und DataLad basieren beide auf Git, einem beliebten Versionskontrollsystem, und git-annex, das die Fähigkeiten von Git erweitert, insbesondere im Hinblick auf die Verwaltung großer Dateien. GIN ist ein webbasierter Open-Source-Datenverwaltungsdienst mit verschiedenen Funktionen für die kollaborative Datenverarbeitung, z. B. integrierte Versionierung, sicherer Zugriff, persistente Datenidentifikatoren für die Veröffentlichung (DOI), automatische Indizierung und Datenvalidierung. DataLad ist eine Datenverwaltungssoftware, die die verschiedenen Phasen der Entwicklung digitaler Objekte unterstützen soll. Wichtig ist, dass DataLad als Overlay über bestehende Datenstrukturen und Dienste betrachtet werden kann: Durch die Verfolgung von Dateien werden die Dateien selbst oder der Speicherort, von dem sie durch Datenverarbeitungstools abgerufen werden können, nicht verändert.

In den letzten 5 Jahren haben wir eine Strategie für 1) Projektplanung, 2) Dokumentation, 3) Datenerfassung und -speicherung und 4) Datenaustausch entwickelt (Abb. 1). Projektplanung und experimentelle Details werden in einer firmeninternen relationalen cloudbasierten Datenbank13 aufgezeichnet. Ein Schlüsselelement sowohl für die Datenbank als auch für die Datenspeicherung ist die Kennung, die Studien-ID für jedes Tier, die in einer standardisierten Dateinamenstruktur verwendet wird, um die Daten auffindbar zu machen. Die Verzeichnisstruktur für die Rohdaten richtet sich nach der Genehmigung zur Durchführung von Tierversuchen. Die Daten für ein bestimmtes Projekt werden nach den YODA-Prinzipien (https://handbook.datalad.org/en/latest/basics/101-127-yoda.html) organisiert, die mit bestehenden Standards, z. B. der BIDS-Struktur15, kompatibel sind (Abb. 2A). Es wurde eine automatische inkrementelle Backup-Routine installiert, die die Daten von einer externen Diskstation, die mit dem Hauptanalysearbeitsplatz verbunden ist, auf ein zentral verwaltetes Netzwerklaufwerk überträgt. Zur Vorbereitung der Veröffentlichung und zur Erleichterung der Datenreproduzierbarkeit werden die experimentellen Roh- und verarbeiteten Daten auf GIN öffentlich zugänglich gemacht und Nachbearbeitungsdetails und Pipelines angegeben – entweder in der Veröffentlichung oder auf einer GitHub-Seite (https://github.com). /aswendtlab/Project_C3a_peri-infarct).

Grüne Pfeile: Workflow für Projektplanung, Datenerfassung, -verarbeitung, -speicherung; graue Pfeile: Backup-Plan auf lokalen und Netzwerkspeichern; orangefarbene Pfeile: Integration von DataLad zur Versionskontrolle; Blaue Pfeile: Veröffentlichungsprozess mit GIN als Online-Hosting-Dienst. Figur erstellt mit Biorender.com.

(A) YODA-Verzeichnisstruktur und Integration von DataLad. Das Stammverzeichnis des Betriebssystems (OS), die Liste der Projekte und projektbezogene Inhalte (Ordner + Dateitypen). Die gestrichelten und durch „//“ getrennten Verbindungen weisen darauf hin, dass es weitere Ebenen geben kann, z. B. den Zeitpunkt der Messungen. Bei der Konvertierung des Projekt1-Ordners in einen DataLad-Datensatz werden die entsprechenden DataLad-Dateien (graue Kästchen) als zusätzliche Informationen im Ordner erstellt, ohne dass sich dies auf die restlichen Daten auswirkt. „raw_data“-Ordner und alle Ordner in „code“ sind unabhängige Unterdatensätze im Kontext der Verschachtelung und Etablierung der Dezentralisierung, wobei sich „code“ in Github statt in GIN befindet. (B) Die Schritt-für-Schritt-Anleitung zur Erstellung des DataLad-Datensatzes besteht aus 4 obligatorischen Folgephasen und wird von einer ersten Vorbereitungsphase und einem optionalen Drittanbieter-Nutzungsszenario umrahmt (rote Kreise markieren wiederkehrende Phasen). (C) Ordnerstruktur basierend auf der Genehmigung zur Durchführung von Tierversuchen ohne DataLad (TVA = Tierversuchsantrag). Dies ist die alte Struktur vor der Implementierung der YODA-Struktur, die gesamte Verarbeitung erfolgte ebenfalls innerhalb dieser Struktur unter Verwendung der Pipelines parallel aus einem anderen, von dieser Struktur getrennten Speicher. Die ursprünglichen Rohdaten werden weiterhin in dieser Struktur als Archiv der Rohdaten aufbewahrt, der Rest wird jedoch abgeschafft.

DataLad dient als zentrales Datenmanagement-Tool (Abb. 1) und zur Versionskontrolle: Es verfolgt, welche Dateien wann und von wem geändert wurden und bietet die Möglichkeit, frühere Zustände wiederherzustellen. Zu diesem Zweck ist DataLad unabhängig vom Datentyp und bietet eine einheitliche Schnittstelle für die Verwaltung von Code und Datendateien (normalerweise verwaltet von Git bzw. Git-Annex).

Innerhalb von DataLad-Datensätzen ist es möglich, (eine unbegrenzte Anzahl) anderer DataLad-Datensätze zu verschachteln, wobei jeder Unterdatensatz eine eigenständige Komponente mit seinem eigenen Verlauf und seinen eigenen Geschwistern bleibt. Um diese Struktur zu erreichen, können die folgenden Schritte 1 bis 4 unabhängig voneinander innerhalb eines etablierten Datensatzes durchgeführt werden. Auf diese Weise kann der Benutzer das Projekt beispielsweise nach Veröffentlichung, Datentyp oder Speicherort unterteilen. Um dies zu verdeutlichen, besteht die Möglichkeit, einen Top-Level-Datensatz zusammen mit den Unterdatensätzen im Online-Repository-Dienst zu platzieren. Dabei werden die von einem Datensatz direkt erfassten Daten wie gewohnt gespeichert, die Teildatensätze sind jedoch nur als Links zu einem eigenen Repository verfügbar, das beim gleichen Online-Repository-Anbieter gehostet werden kann, aber nicht muss. In unserem Fall wird der gesamte Projektcode in GitHub-Repositorys (https://github.com) gespeichert und verwaltet und als mehrere Unterdatensätze im Hauptdatensatz der obersten Ebene Project1 auf GIN installiert (Abb. 2A). Die durch die Yoda-Prinzipien eingeführte Struktur macht das gesamte Projekt in sich geschlossen. Es ist kein weiteres Element außerhalb des Projekts erforderlich, um von den Eingaben zu Ergebnissen zu gelangen. Im Gegensatz dazu ist für die Struktur in Abb. 2C keine Eigenständigkeit möglich.

INFO: Wenn ein Datensatz oder ein Subdatensatz für einen Ordner implementiert werden soll, der nur Codierungsskripte enthält, sollten die Stufen 1 bis 4 leicht optimiert werden. Kurz gesagt, Git eignet sich viel besser für die Versionskontrolle von Skripten, die Code enthalten. Wenn Schritt 1.2 ausgeführt wird, wird standardmäßig alles von git-annex verwaltet. Die Alternative besteht darin, datalad create --force -c text2git zu verwenden. Durch die zusätzliche Konfiguration ist Git für den Inhalt der Datensätze verantwortlich.

Basierend auf unserer Workflow-Entwicklung (Abb. 1) bietet diese Anwendungsfallbeschreibung eine Schritt-für-Schritt-Anleitung für nicht-fachkundige Benutzer zum Verwalten großer experimenteller Datensätze mit komplexen, multimodalen Dateien, d. h. den Roh- und verarbeiteten Daten sowie den Code und die Ausgabedateien.

Informationen zu den Hard- und Softwareanforderungen und Installationsroutinen finden Sie im Abschnitt „Methoden“ und im ergänzenden Material. Der Arbeitsablauf besteht aus 4 obligatorischen Phasen (Abb. 2B): 1. Initialisieren eines DataLad-Datensatzes, 2. Versionskontrolle, 3. Initialisieren des Remote-(Online-)Repositorys und 4. Hochladen in das Remote-Repository. Wir beschreiben auch ein optionales Anwendungsszenario für die Nutzung durch Dritte, d. h. die Zusammenarbeit am gleichen Datensatz mit anderen Forschern und die Veröffentlichung des Datensatzes.

Um die Datenstruktur zu erstellen, beginnen Sie mit dem Hauptprojektordner und sortieren Sie die Rohdaten im zugehörigen Eingabeordner (Abb. 2A).

Beim Konvertieren des Projektordners in einen DataLad-Datensatz werden die entsprechenden DataLad-Dateien automatisch erstellt, ohne dass Dateien und Struktur geändert werden. DataLad-Dateien enthalten die Version und den Verlauf aller Dateien im Projektordner. Projekt1 dient als Superdatensatz mit den zugehörigen Ordnern „raw_data“ und „proc_data“ als Unterdatensätze mit eigenen Repositorys auf den Repository-Diensten GIN bzw. GitHub. Mit dieser Struktur kann DataLad Aktionen wie die Verarbeitung von Rohdaten aus einer bestimmten Pipeline im Code registrieren und die Ausgabe der Pipeline in proc_data speichern. Diese Aktionen werden in den Verlaufsinformationen des Super-Datasets Project1 gespeichert.

In unserem Fall werden die Daten aus mehreren Tierprotokollordnern in den Projektordner kopiert und die ursprünglichen Rohdaten (im Archiv) bleiben unberührt. Dieser Vorgang kann nachverfolgt werden, wenn Datalad bereits für alle Speicher wirksam ist. Bei anderen Datenstrukturen, z. B. bei Verwendung eines PACS-Servers, wäre die Übertragung der Daten in den Hauptprojektordner ähnlich. Die Idee besteht darin, alle projektrelevanten Daten zur Analyse und späteren Weitergabe verfügbar zu haben. Jeder Eingabeunterordner ist nach der Methodik benannt (z. B. MRT, Verhalten, Histologie usw.) und kann verschiedene Dateitypen enthalten (Tabelle 2). Die anderen Ordner enthalten den Code, die Ergebnisse und die Dokumente. In diesem Beispiel enthält der Code die Atlas-basierten Bilddatenanalysetools AIDAqc und AIDAmri16 für die automatisierte Qualitätskontrolle, die Verarbeitung multimodaler MRT16 und die Registrierung beim Allen Mouse Brain Atlas17. Der Ordner „docs“ enthält alle notwendigen (Metadaten-)Informationen und Dokumentationen zur Reproduktion des MRT-Datensatzes (z. B. welche Studien-ID zu welcher Versuchsgruppe gehört, Zeitpunkte, MRT-Scan-Typ usw.).

Die folgenden Schritte werden ausgeführt, um die Konvertierung des Ordners „Project1“ in einen DataLad-Datensatz zu starten (Abb. 2B). Eine Videoanleitung ist verfügbar (https://gin.g-node.org/Aswendt_Lab/Example_Dataset_Kalantari_Paper/src/master/doc).

1.1 Öffnen Sie zunächst das Terminal und ändern Sie das Verzeichnis in den Zielordner. In diesem Beispiel ist es Projekt1.

»cd Projekt1

1.2 Sobald Sie sich im Zielordner befinden, führen Sie den folgenden Befehl aus, um die DataLad-Dataset-spezifischen Ordner und Dateien im Ordner „Project1“ zu erstellen (Abb. 2A).

» datalad create–force

INFO: DataLad bietet zahlreiche Befehle und jeder Befehl hat unterschiedliche Optionen. Sie können einen leeren DataLad-Datensatzordner erstellen, indem Sie datalad Ordnername erstellen. Hier wurde in Schritt 2 der Befehl „create“ verwendet, um einen DataLad-Datensatz im aktuellen Arbeitsverzeichnis zu initialisieren, und die Option „--force“ ermöglichte die Erstellung eines Datensatzes in einem Ordner, der bereits Daten enthält. Weitere Informationen zu anderen Optionen, die Sie verwenden können, finden Sie in der Hilfe.

2.1 Fahren Sie nach der Initialisierungsstufe 1 mit dem folgenden Schritt fort. Beachten Sie, dass dieser Schritt je nach Hardware1 einige Zeit in Anspruch nehmen kann.

(1Bezieht sich auf Funktionen wie intern oder extern angeschlossene Speicherlaufwerke, Netzwerklaufwerke, Speichertypen wie Festplattenlaufwerke (HDD) oder Solid-State-Laufwerke (SSD)).

» Datalad-Status »Datalad save -m "Benutzernachricht"

Sobald der Datensatz erstellt wurde, werden Schritte, die seinen Inhalt ändern, durch Ausführen des Befehls „datalad save“ aufgezeichnet. Stufe 2 zeigt den ersten praktischen Einsatz von DataLad-Datensätzen: das Aufzeichnen von Änderungen. In unserem Fall enthält der Ordner raw_data beispielsweise MRT-Rohdaten. Nach der Verarbeitung mit AIDAmri16 werden die Ergebnisse im Ordner proc_data gespeichert (Abb. 2A).

INFO: Der Befehl datalad status kann als Inspektionstool betrachtet werden, das den aktuellen Status jeder Datei ausgibt, unabhängig davon, ob sie von DataLad verfolgt oder nicht verfolgt, gelöscht oder geändert wird. Nach der Initialisierung in Schritt 2.1 würden alle Statusausdrucke „untracked“ anzeigen. Alle neu hinzugefügten Dateien werden erst nachverfolgt, wenn datalad save explizit ausgeführt wird. Nachdem eine Datei gespeichert und der Inhalt anschließend geändert wurde, wird der Status anders ausgedruckt. Im Allgemeinen dient der Datalad-Status nur zu Informationszwecken und kann bei der Identifizierung aktueller (nicht gespeicherter) Änderungen hilfreich sein.

Der Befehl „datalad save“ hingegen zeichnet neue Änderungen im Ordner „.git“ auf. Der Befehl save verfügt außerdem über mehrere Optionen, wobei -m das Speichern mit einer Benutzernachricht verknüpft, die den Zweck der Änderung beschreiben kann. Diese Meldungen können für den Benutzer hilfreich sein, um eine bestimmte Version zu finden oder sich Änderungen im Datensatz leichter abzurufen. Wenn Sie an weiteren Optionen für einen Befehl interessiert sind, verwenden Sie die Option --help. Beispielsweise zeigt datalad save --help alle verfügbaren Optionen für den Befehl save an.

2.2 (Optional) Wenn Änderungen programmgesteuert vorgenommen werden (z. B. durch Ausführen eines benutzerdefinierten Skripts), kann dies mit einem Befehl wie dem folgenden erfolgen:

» datalad run -m "user message" -–input … python < code.py >

Der Ausführungsbefehl registriert Informationen über die Eingabe- und Ausgabedaten des ausgeführten Codes (hier ein Python-Skript) und trägt diese in den Verlaufsinformationen des Datensatzes ein. Der Befehl „datalad save“ wird automatisch ausgeführt, wenn „datalad run“ verwendet wird. Zusätzlich zur vom Benutzer bereitgestellten Meldung wird jedoch auch ein erneut ausführbarer Ausführungsdatensatz gespeichert, um die Herkunft zu erfassen.

Es ist wichtig zu betonen, dass Stufe 2 eine sich wiederholende Stufe ist (Abb. 2B), das heißt, sie kann wiederholt werden, um aufeinanderfolgende Änderungen oder neue Zustände aufzuzeichnen. Im Laufe der Zeit entsteht durch diesen Prozess ein Logbuch, in dem alle Aktionen aufgezeichnet werden, die ein Benutzer im Laufe der Zeit am Projekt durchgeführt hat. Wie Sie auf dieses Logbuch zugreifen und es verwenden, wird im folgenden Schritt erläutert.

2.3 Auf alle registrierten Informationen zu den aufgezeichneten Änderungen kann zugegriffen werden durch:

» Git-Protokoll

Dadurch werden alle Änderungen angezeigt, die seit Beginn der Versionskontrolle vorgenommen wurden. Optional durch Eingabe von:

» git log -2

Es werden nur die letzten beiden Änderungen oder Commits gedruckt (Abb. 3).

Beispiel-Git-Log-Ausgabe eines Datensatzes mit Informationen zum Autor, Datum, Änderungen und der entsprechenden Commit-ID, auch „sha“ genannt.

INFO: Ein Commit ist eine Momentaufnahme des aktuellen Status des Projekts. Der Unterschied zwischen zwei Commits in einem Datalad-Datensatz bedeutet die Änderungen, die zwischen diesen beiden Status des Projekts stattgefunden haben. Einige Daten können erstellt, geändert, verschoben oder gelöscht werden. Es gibt andere Möglichkeiten, auf den Verlauf zuzugreifen, wie zum Beispiel tig (https://jonas.github.io/tig/) oder einige mit ihrer eigenen grafischen Benutzeroberfläche (GUI) wie gitgui, gitk usw. (https://git-scm .com/downloads/guis).

In diesem Szenario verwenden wir die Datenplattform GIN (andere Optionen sind verfügbar, siehe Tabelle 1). Voraussetzung für die folgenden Schritte ist ein funktionsfähiges GIN-Konto (https://gin.g-node.org/user/sign_up) mit einem zugehörigen SSH-Schlüsselpaar (http://handbook.datalad.org/en/latest/basics /101-139-gin.html) zwischen dem GIN-Konto und dem Konto auf dem lokalen Computer. Hinweis: Dieser Schritt kann je nach Netzwerkgeschwindigkeit einige Zeit dauern.

Erstellen Sie unter dem GIN-Konto ein Repository mit einem projektspezifischen Datensatznamen und kopieren Sie den von GIN generierten projektspezifischen SSH-Link.

Führen Sie den folgenden Befehl mit Ihren eigenen Anmeldeinformationen im Ordner „Projekt1“ aus.

datalad-Geschwister add–dataset.–name gin–url [email protected]:/username/dataset-name.git

INFO: datalad siblings wird für alle Aktionen verwendet, die sich auf andere Kopien des Datensatzes auswirken. Hier wird die Option „Hinzufügen“ verwendet, um den Datensatz mit einem neuen Speicherort zu verknüpfen, an dem die Geschwister oder die Kopie des Datensatzes abgelegt werden sollen. Als nächstes definiert --dataset den Pfad des zu konfigurierenden Datensatzes, hier wird er durch das „.“ definiert, was den aktuellen Ordnerspeicherort bedeutet. --name ist der Name des Geschwisters, der vom Benutzer definiert werden kann. Es ist jedoch logisch, es nach dem Online-Repository-Dienst zu benennen, um die Verwendung zu vereinfachen und Verwirrung zu vermeiden. Hier verwenden wir Gin. Die Option --url gilt für den auf der in Schritt 3.1 erworbenen Projektseite verfügbaren Link, der explizit für das dort erstellte Projekt generiert wird. Für einige Repositories wie GIN werden dedizierte Befehle bereitgestellt, die die Erstellung und Registrierung von Remote-Geschwistern in einem einzigen Schritt automatisieren. Für GIN lautet dieser Befehl create-sibling-gin.

Nachdem das Remote-Repository eingerichtet und eine Verbindung zwischen beiden hergestellt wurde, kann das Projekt auf GIN hochgeladen (gepusht) werden.

4.1. Geben Sie zunächst den folgenden Befehl in das Terminal ein:

datalad push --to gin

Genau wie Stufe 2 kann dieser Schritt wiederholt werden (Abb. 2B). Während ein Datensatz und seine Verlaufsinformationen weiterentwickelt werden, werden neue Commits hinzugefügt und Aktualisierungen können per Push an das Remote-Repository übertragen werden. Dies geschieht effizient, d. h. es werden nur geänderte Dateien übertragen. Durch die Versionierung ist der Status des hochgeladenen Datensatzes eindeutig. Darüber hinaus ist GIN vollständig kompatibel mit Git und Git-Annex und seine Weboberfläche kann beispielsweise den Änderungsverlauf und zugehörige Commit-Nachrichten anzeigen.

Abhängig von der Größe des Projekts und der Qualität der Internetverbindung kann die Ausführung dieses Schritts einige Zeit in Anspruch nehmen. Daher kann es sinnvoll sein, nicht zu versuchen, alle Daten in einem Stapel zu übertragen, d. h. sie aufzuteilen und den Push-Vorgang in mehreren Stapeln durchzuführen. Dies ist möglich, indem Sie dem Befehl den Pfad eines angegebenen kleineren Teils des Projekts hinzufügen:

4.2 (Optional) datalad push --to gin

Jeder, der sich für das Projekt interessiert, kann nun nicht nur auf die Daten zugreifen und diese herunterladen, sondern auch auf die Geschichte des Projekts, wie es sich im Laufe der Zeit entwickelt hat, durch das sogenannte „Klonen“. Aus Drittsicht ist der erste Schritt der Besuch des jeweiligen Repositorys auf der GIN-Website, wo sich jeweils der SSH-Link bzw. der HTTPS-Link befindet, je nachdem, ob der Datensatz geändert oder nur heruntergeladen werden soll.

INFO: Auf der Projektseite eines GIN-Kontos gibt es drei Links für den Zugriff auf das Repository: SSH, HTTPS und GIN. Vereinfacht ausgedrückt sind SSH und HTTPS verschiedene Arten der Kommunikation zwischen dem Betriebssystem des Benutzers und dem Online-Repository-Dienst. Der Hauptunterschied in unserem Anwendungsfall besteht darin, dass eine SSH-Verbindung erforderlich ist, wenn wir die Daten in das Remote-Repository hochladen oder „pushen“ möchten. Zum Herunterladen bzw. „Klonen“ der Daten reicht eine HTTPS-Verbindung aus. Wie in Stufe 3 kurz erwähnt, erfordert die Einrichtung eines SSH-Links zusätzliche Schritte, HTTPS-Links können jedoch ohne weitere Bedenken verwendet werden.

Kopieren Sie den SSH/HTTPS-Link von der GIN-Projekt-Webseite.

Öffnen Sie das Terminal, navigieren Sie zu einem Ordner, in dem sich der Projektinhalt befinden soll, und führen Sie den folgenden Befehl aus. Ersetzen Sie dabei die Beispiel-URL durch den kopierten Link.

Für SSH-Links:

Datensatzklon [email protected] :/username/dataset-name.git

Für HTTPS-Links:

Datensatzklon https://gin.g-node.org/username/dataset-name

Wenn der HTTPS-Link ausgewählt wird, beachten Sie, dass der Link keine.git-Erweiterung hat.

INFO: Eine nützliche Funktion des Befehls „datalad clone“ besteht darin, dass nicht der gesamte Datensatz auf einmal heruntergeladen wird. Es lädt nur die Ordnerstruktur, die kleinen Dateien und die Dateinamen großer Dateien herunter, also Dateien, die von git-annex verarbeitet werden. Mit dem Befehl „datalad get“ können dann die Inhalte großer Dateien selektiv heruntergeladen werden, sodass der gesamte Inhalt lokal verfügbar wird. Dies kann aus zwei Gesichtspunkten nützlich sein: Erstens, wenn der gesamte Datensatz sehr groß ist und nur einige Teile von Interesse sind, können nur diese Teile selektiv heruntergeladen werden. Zweitens: Wenn nur die Projektstruktur und der Dateiname von Interesse sind, würde datalad get in diesem Fall überhaupt nicht aufgerufen.

Wenn Sie das gesamte Projekt herunterladen möchten, fahren Sie mit dem folgenden Befehl im DataLad-Dataset-Ordner fort, der nach dem letzten Schritt erstellt wurde.

Geben Sie Folgendes ein:

computerisierte Ziege

Der Befehl kann auf einen bestimmten Pfad (Verzeichnis oder Datei) beschränkt werden, um den Inhalt gezielt abzurufen.

Wie im vorherigen Abschnitt vorgestellt, kann die Verschachtelung von Datensätzen aus der Sicht Dritter sehr nützlich sein. In unserem Beispiel enthält der Datensatz der obersten Ebene Project1 mehrere Datensätze für die Ordner „raw_data“ und verschiedene Code-Pipelines (Abb. 2A). Die Absicht dieses Setups bestand erstens darin, die Rohdaten und Codes separat für Dritte verfügbar zu machen, ohne dass alle peripheren Projektstrukturen heruntergeladen werden müssen, und zweitens darin, die Aktualisierbarkeit der verschiedenen Pipelines im Codeordner, d. h. as, zu wahren Die Pipelines werden im Laufe der Zeit aktualisiert. Durch das Klonen des Datensatzes der obersten Ebene werden ihm automatisch die aktuellsten Pipelines zugeordnet.

Da unser Datensatz zur Veröffentlichung und Wiederverwendung bestimmt ist, ist es wichtig, ihn mit relevanten Informationen zu kommentieren. Bei der Erstellung sind GIN-Repositories standardmäßig privat, d. h. der Zugriff ist eingeschränkt, sie können jedoch über ein Kontrollkästchen im Einstellungsmenü auf öffentlich eingestellt werden. Öffentliche Datensätze auf GIN können einen eindeutigen persistenten Digital Object Identifier (DOI) erhalten, der sie zitierfähig macht. Neben den Publikationsmetadaten umfassen wir Dokumentationen zum Datensatz, wie z. B. Versuchsgruppen und Zeitpunkte, sowie modalitätsspezifische Informationen, z. B. zu MRT-Sequenzen, die aus unserer relationalen Datenbank abgerufen werden.

Hier bieten wir eine Schritt-für-Schritt-Anleitung für nicht fachkundige Benutzer zur Implementierung eines FAIR-Daten-Workflows für Kleintierdaten. In diesem Workflow verwenden wir ein einfaches, aber effizientes lokales Backup-Schema und eine standardisierte Datenstruktur in Kombination mit GIN als Lösung für die öffentliche Datenverfügbarkeit. DataLad wurde als Datenverwaltungstool verwendet, um eine Grundlage für eine transparente und zuverlässige Zusammenarbeit zwischen Forschern zu schaffen, mit der Absicht, alle Elemente eines Projekts, wie Eingabedaten, Codes und Ergebnisse, zusammen mit Informationen darüber, wie sie miteinander verbunden sind, zu kapseln18.

Unsere Motivation für die Implementierung dieses Workflows bestand darin, die Datenerhaltung, eine effiziente Zusammenarbeit, den Datenaustausch und eine erhöhte Reproduzierbarkeit sicherzustellen. Solche praktischen Anforderungen im Zusammenhang mit dem Forschungsdatenmanagement sind in diesem Bereich weit verbreitet und bisher wurden nur einzelne Lösungen vorgeschlagen (Kuhn Cuellar et al.19). Eine kürzlich durchgeführte Umfrage zur Datenverwaltung und -freigabe in der (menschlichen) Neurobildgebung zeigt die erheblichen Herausforderungen, die mit der ordnungsgemäßen Verwaltung und Weitergabe von Neurobildgebungsdaten verbunden sind, wobei die größten Einschränkungen Zeit und fehlende Best Practices sind20. Forscher halten sich beim Datenaustausch für weniger ausgereift als bei Datenanalyse- und Erhebungspraktiken. Um diese Einschränkung zu überwinden, lag unser Fokus auf einem einfach zu implementierenden Workflow, der ausschließlich frei verfügbare Software nutzt und keine besonderen Vorkenntnisse erfordert.

Eine standardisierte Subjektkennung und Datei-/Ordnerstruktur (siehe Abschnitt Methoden) sind die Grundlage für ein effizientes Forschungsdatenmanagement. Die erstellte Kennung für jedes Tier und die standardisierte Dateibenennung tragen dazu bei, dass die Daten auch ohne andere Metadaten nachvollziehbar sind. In unserem Fall bestimmt das Tierprotokoll, welche Methode wie oft angewendet werden kann. Um eine vollständige Transparenz gemäß den Richtlinien guter wissenschaftlicher Praxis mit Tieren21 zu gewährleisten und die Dokumentation für die Audits durch die örtlichen Behörden zu vereinfachen, sammeln wir alle Versuchsdaten in einer elektronischen relationalen Datenbank13 und speichern die Rohdaten in der vom Tier vorgegebenen Struktur Protokoll. Dieses Rohdatenverzeichnis dient später als Archiv, das unangetastet bleibt. Für die projekt-/veröffentlichungsbezogene Verarbeitung werden alle Rohdaten, die aus unterschiedlichen Tierlizenzen stammen können, in den Eingabeordner kopiert, um die Rohdaten aus Sicherheitsgründen unangetastet zu lassen und gleichzeitig eine maximale Flexibilität bei der Arbeit mit den Daten zu gewährleisten. Die YODA-Struktur enthält nicht nur den Eingabeordner, sondern auch Ausgabe, Dokumente und Code. Hier unterscheidet sich unser Ansatz von bisher vorgeschlagenen Ordnerstrukturen mit einer 3-stufigen Hierarchie, nämlich Laborebene (Organisation mit mehreren Projekten), Projektebene und anschließender Experimentalebene22. Zur Veröffentlichung oder Zusammenarbeit wird die gesamte YODA-Struktur auf den Online-Datenhosting-Dienst, in unserem Fall GIN, hochgeladen. Wichtig ist, dass DataLad flexibel ist, wo die Daten gespeichert werden. Wenn Benutzer ihre vollständigen Daten in alternativen Speicherlösungen haben, beispielsweise auf einem XNAT- oder PACS-Server für radiologische Daten23 oder OMERO24 für Mikroskopiedaten, gibt es spezielle DataLad-Erweiterungen (https://docs.datalad.org/), oder es können zusätzliche Erweiterungen sein mit minimalem Aufwand entwickelt, um zusätzliche Dienste zu unterstützen. Unser Workflow schließt andere Software- und Datenhosting-Dienste nicht aus, zum Beispiel CKAN (https://ckan.org), Harvard Dataverse (https://dataverse.harvard.edu) und Barcelonaβeta Brain25, die ihre eigene Strategie verfolgen komplexe multimodale Forschungsdaten. Im Gegensatz dazu bietet es ein vielseitiges und interoperables RDM mit der notwendigen Flexibilität und Einfachheit, um an lokale experimentelle Paradigmen und bestehende IT-Infrastrukturen in kleinen Labors bis hin zu großen Konsortien mit mehreren Standorten angepasst zu werden12,18.

Metadaten sind ein sehr wichtiger Bestandteil aktueller Forschungspraktiken, insbesondere wenn es um eine transparente Zusammenarbeit zwischen Forschern gemäß FAIR und den Community-spezifischen Richtlinien für Neuroimaging geht5,26. Für MRTs, die als DICOM- oder NiFTI-Dateiformate gespeichert sind, gab es mehrere Versuche, dies zu erreichen Header-Datei enthält mehr Metadaten, wobei der BIDS-Standard die fortschrittlichste und am weitesten verbreitete Option für die Strukturierung von Dateien nach MRT-Sequenzen und die Einbeziehung standardisierter Metadaten ist15. Unser Workflow ist vollständig mit dem BIDS-Format kompatibel (siehe Beispiel in https://doi.org/10.12751/g-node.3yl5qi27), wir haben uns jedoch entschieden, BIDS nicht zur Verwendung des Workflows zu verpflichten, wie dies beispielsweise bei den Daten der Fall ist Plattform OpenNeuro, um die Flexibilität für Forscher zu maximieren, die mit verschiedenen Dateiformaten arbeiten. Obwohl wir die Bemühungen zur Maximierung der Standardisierung auf der Ebene der Metadaten voll und ganz unterstützen, ist es aufgrund unserer eigenen Erfahrung bei der Arbeit mit multimodalen Daten (aus MRT, Verhalten, Elektrophysiologie und Mikroskopie) als Zwischenschritt notwendig, der Existenz dieser Daten Priorität einzuräumen Metadaten möglichst in maschinenlesbaren Dateien (txt, csv, json), die nicht unbedingt der aktuellen Community-basierten Struktur entsprechen müssen. Wir empfehlen daher, den Workflow in Kombination mit einer relationalen Datenbank wie unserer eigenen Entwicklung13, REDcap28 oder anderen zu verwenden, die die Generierung solcher maschinenlesbaren Dateien ermöglicht. Mit grundlegenden Programmierkenntnissen wird es für Drittbenutzer einfach sein, die freigegebenen Daten basierend auf diesen Dateien zu durchsuchen und zu filtern.

Wenn die Verarbeitung mehrere Schritte oder Verarbeitungswerkzeuge erfordert, empfehlen wir außerdem, eine detailliertere Schritt-für-Schritt-Anleitung beizufügen (z. B. https://github.com/aswendtlab/ Project_C3a_peri-infarct), die über die Anforderungen der Metadatenberichterstattung hinausgeht bestehende Standards, also BIDS. Solche Schritt-für-Schritt-Anleitungen können für die Datenreplikation erforderlich sein, falls automatisierte Routinen, z. B. Datalad-Lauf, nicht verwendet werden können.

Es sollte erwähnt werden, dass DataLad eine gewisse Vorabinvestition an Zeit und Ressourcen erfordert, aber die Effizienz-, Qualitäts- und Zuverlässigkeitsgewinne auf der ganzen Linie machen diese Investitionen unserer Erfahrung nach lohnenswert.

Die Unfähigkeit, die Ergebnisse einer bestimmten Studie zu reproduzieren, ist nicht nur bei der Neurobildgebung bei Kleintieren zu beobachten. Dies liegt vor allem an der fehlenden Transparenz und methodischen Details, etwa einem Schritt-für-Schritt-Protokoll in wissenschaftlichen Arbeiten. Für die Reproduktion einer Studie ist der Zugriff auf eine Vielzahl weiterer Dokumente erforderlich, beispielsweise auf Scanparameter, Vor- und Nachbearbeitungsverfahren sowie individuelle Probandenmerkmale. Dazu verfolgen wir zusätzlich zum hier vorgestellten Workflow einen pragmatischen Ansatz, d. h. wir stellen die Roh- und verarbeiteten Daten öffentlich auf GIN zur Verfügung und spezifizieren die Nachbearbeitungsdetails auf einer projektspezifischen GitHub-Seite.

Die Konvertierung der Datenordner in einen DataLad-Datensatz bietet nicht nur die oben beschriebenen Vorteile, z. B. Nachverfolgung von Änderungen, einfache gemeinsame Nutzung von Datensätzen durch Veröffentlichung unter Geschwistern und effiziente Verwaltung großer Dateien durch Reduzierung des Transport- und Speicherbedarfs. Wie bereits erwähnt, öffnet DataLad Ihre Datensätze für eine viel breitere Nutzung und ermöglicht über den DataLad-Subdataset-Mechanismus eine einfache Wiederverwendung veröffentlichter Datensätze in anderen DataLad-Datensätzen. DataLad bietet außerdem Provenienzverfolgung (wiederausführbare Annotation von Änderungen) und Metadatenverwaltung. Zusammen mit den Befehlen „run-command“ und „rerun-command“ von DataLad, die eine „verfolgte Ausführung“ von Vorgängen an einem Datensatz ermöglichen, ermöglicht DataLad eine wirklich reproduzierbare Forschung29.

Der offene Datenaustausch, der in ein ordnungsgemäßes RDM-Protokoll eingebettet ist, wird keine Mängel im Studiendesign oder in der Analysestrategie beheben, aber vor allem ermöglicht er anderen Forschern, potenzielle Mängel zu erkennen und diese in künftigen Arbeiten zu beheben, wodurch die Wiederholung von Fehlern verhindert wird20. Unsere Bemühungen dienen als Blaupause für andere Bereiche der präklinischen Bildgebung und haben große Auswirkungen auf die Forschungspraxis in der Tier-Neuroimaging-Community und darüber hinaus. Im Einklang mit dem 3R-Prinzip zur Reduzierung der Tierzahl ermöglicht dieser Arbeitsablauf der Community, heterogen erfasste und gespeicherte Datensätze zu sammeln, um Mausgehirnsimulationsexperimente zu fördern und einen speziesübergreifenden Modellierungsansatz zu implementieren. Darüber hinaus wird die enge Zusammenarbeit mit Bemühungen zur Standardisierung von Daten und Metadaten, zur Herkunftsverfolgung und zum Workflow-Management, zur Integration in ein interoperables Forschungsdatenplattform-Ökosystem und zur Spezifikation des Rechenmodells mithilfe standardisierter Mittel dazu beitragen, die Interaktion aller Beteiligten zu stärken und die Ergebnisse zu verbessern aktuelle translationale Kluft zwischen Grundlagenforschern und klinischen Forschern.

In diesem Abschnitt beschreiben wir die Details des Materials, das zur Reproduktion des Arbeitsablaufs erforderlich ist.

Der hier beschriebene Arbeitsablauf (Abb. 1A) wurde mit einem Mac Pro (Ende 2013) als Hauptarbeitsstation im Servermodus entwickelt. Auf diese Weise können mehrere Benutzer über den integrierten Bildschirm oder die Dateifreigabe (VNC/SMB-Protokolle) auf den Mac zugreifen und parallel Daten abrufen und Programme ausführen. Eine ähnliche Arbeitsweise ist bei Workstations mit Linux- oder Windows 10/11-Installationen über Remotedesktopverbindungen möglich. Die Datenspeicherstrategie wurde nach Best Practices30 entwickelt, einschließlich eines Backup-Plans, verschiedener Backup-Speicherorte, Backup-Gültigkeitsprüfungen und der Möglichkeit, die Datenspeicherung zu erweitern. Der wichtigste lokale Speicher – direkt mit der Workstation verbunden – ist ein 20 TB großes LaCie Thunderbolt-Laufwerk, das im Raid-5-Modus betrieben wird (eine Festplatte kann beschädigt werden, während das Dateisystem intakt bleibt). Alle Daten werden vom verantwortlichen Experimentator zunächst manuell in diesen lokalen Speicher kopiert. Der Weg zu den Rohdaten wird in der elektronischen Datenbank13 dokumentiert. Mit Carbon Copy Cloner (Bombich Software, Inc., USA) werden wöchentlich automatisierte und inkrementelle Sicherungen vom lokalen Speicher zum Netzwerkspeicher (verwaltet von der IT-Abteilung des Universitätsklinikums) durchgeführt.

Der Workflow (Abb. 1A) basiert auf freier und Open-Source-Software: Python (https://www.python.org/, RRID:SCR_008394), GIN (https://gin.g-node.org, RRID: SCR_015864) und DataLad (https://www.datalad.org, RRID:SCR_003931). Es gibt weitere Datenhosting-Optionen (Tabelle 1), die problemlos in den bereitgestellten Workflow integriert werden können. Repräsentative Installationsanleitungen finden Sie im Zusatzmaterial. Die aktuellsten Installationsanweisungen finden Sie auf den entsprechenden Websites.

DataLad wird für die verteilte Versionskontrolle verwendet: Erstellung, Synchronisierung und Verfolgung verknüpfter Datensatzkopien (sogenannte Geschwister). Ein DataLad-Datensatz kann einen oder mehrere Geschwister haben, die entweder lokal (Sicherungslaufwerke, lokale Server, verschiedene Workstations) oder online (z. B. GIN) gespeichert sind. An einer Datensatzkopie vorgenommene Änderungen können mit anderen Kopien synchronisiert werden, und die Synchronisierung erfolgt immer explizit (es ist leicht zu erkennen, ob Versionen voneinander abweichen oder nicht). Die Verfügbarkeit von Dateiinhalten wird verfolgt und remote verfügbare Inhalte können bei Bedarf abgerufen werden, um lokal Speicherplatz zu sparen. Dies bedeutet auch, dass Dateiaustausch, Backup und Veröffentlichung über dieselbe Softwareschnittstelle erfolgen, auch wenn die Speicherorte unterschiedlich sind.

Repository: Ordner mit Dateien und Unterordnern als Struktureinheit für die Code- oder Datenverwaltung; kann ein beliebiger Satz oder eine beliebige Kombination von Dateien mit unterschiedlichen Ordnerstrukturen und unterschiedlichen Datentypen sein, manchmal kann es sogar leer sein und keine Dateien enthalten.

DataLad-Datensatz: Repository, auf dem DataLad ausgeführt wird und die Versionskontrolle ausgeführt wird.

Initialisieren eines DataLad-Datensatzes: um einen leeren Datensatz zu erstellen, der der Versionskontrolle von DataLad unterliegt. Wenn diesem Datensatz danach Dateien hinzugefügt werden, werden sie von DataLad verfolgt.

Initialisieren von DataLad in einem bereits vorhandenen Repository: der Übergang eines Datensatzes in einer Datei-/Ordnerstruktur zu einem von DataLad verwalteten Datensatz.

Nachverfolgung/Versionskontrolle: Wenn sich eine Datei ändert, weil sie von einem Benutzer ersetzt oder bearbeitet wurde, protokolliert DataLad diese Änderungen im Laufe der Zeit entsprechend.

Ein DataLad-Geschwister/Klon: kann als Kopie des Datensatzes definiert werden. Dies bedeutet nicht unbedingt, dass es sich um eine exakte Kopie handelt oder dass alle Daten vollständig verfügbar sind. Ein Platzhalter ist eine Datei mit demselben Namen wie die Originaldatei, jedoch ohne Inhalt.

Git: ein kostenloses und quelloffenes Versionskontrollsystem zur effizienten Abwicklung kleiner bis sehr großer Projekte

Git-Annex: Git-Annex ist ein verteiltes Dateisynchronisierungssystem, das darauf abzielt, das Problem der gemeinsamen Nutzung und Synchronisierung großer Dateisammlungen zu lösen.

Verschachtelung von Datensätzen: Datensätze können andere Datensätze (Subdataset) enthalten, die wiederum Subdatasets usw. enthalten können. Jeder Datensatz, der einen anderen Subdataset enthält, kann als Superdataset bezeichnet werden. Der Datensatz der obersten Ebene ist der Superdatensatz mit der höchsten Ebene in der Hierarchie der Datensätze.

Online-Datenhosting-Anbieter bieten Forschern die Infrastruktur, um ihre Daten hochzuladen und mit anderen zu teilen. Diese Dienste unterscheiden sich in ihrem Hauptschwerpunkt: Cloud-Speicher (Dateispeicherung und eingeschränkte gemeinsame Nutzung, keine Metadaten-Indizierung), einfache Daten-Hosting-Dienste (langfristiges Hosting, automatisierte Metadaten-Indizierung) und Forschungsdatenplattformen (langfristiges Hosting, gemeinsame Nutzung, Zusammenarbeit und Daten). Management) (Tabelle 1).

Dienste und Plattformen, die persistente Identifikatoren (DOI) bereitstellen, sind der Schlüssel zur Einführung von FAIR- und Open-Science-Praktiken im Einklang mit Aspekten der Reproduzierbarkeit und Datenwiederverwendung. Allerdings gibt nur eine Minderheit der Studien ihre Daten weiter, was sich mit der steigenden Nachfrage von Verlagen und Förderinstitutionen ändern könnte. Wir haben uns für die von der Bundesregierung (BMBF Grant 01GQ1302) und der LMU München geförderte Forschungsdatenplattform GIN (https://gin.g-node.org/G-Node/Info/wiki/) entschieden und offen entwickelt -Quelle des Deutschen Neuroinformatik-Knotens (G-Node). GIN ist eine registrierte Ressource (https://doi.org/10.17616/R3SX9N) und erfüllt die vom INCF31 empfohlenen Kriterien für Repositorien und wissenschaftliche Gateways.

Um einen Datensatz für den GIN-DOI-Dienst geeignet zu machen, müssen bestimmte Metadaten, einschließlich einer GIN-spezifischen Datei namens „datacite.yml“, erstellt werden, die Informationen zu den Autoren, Titel, Beschreibung, Schlüsselwörtern und Lizenz gemäß enthält Das DataCite-Schema (https://schema.datacite.org/) muss bereitgestellt werden. Bei GIN müssen sich diese Metadaten in einer Datei namens „datacite.yml“ im Stammverzeichnis des Repositorys befinden. Es sollte eine Lizenz ausgewählt werden (z. B. https://creativecommons.org/choose/), um Namensnennungs-, Ableitungs- und Weitergabeanforderungen festzulegen, wobei der Lizenztext in eine Textdatei namens LIZENZ eingefügt werden soll. Der GIN DOI-Dienst gewährleistet den dauerhaften Zugriff auf den Datensatz mithilfe einer dauerhaften Kennung (https://gin.g-node.org/G-Node/Info/wiki/DOI).

INFO: Die Auswahl eines Datenhosting-Dienstes sollte sorgfältig getroffen werden, da verschiedene Faktoren eine Rolle spielen, z. B. die Verfügbarkeit, die Anonymitätsverschlüsselung, die allgemeine Zielgruppe externer oder interner Benutzer, der Umfang der Daten, die Häufigkeit der Nutzung usw. Wichtig ist, dass DataLad mit allen aufgeführten Diensten funktioniert. Die DataLad-Versionskontrolle wird unabhängig davon angewendet, wo sich die Daten befinden, also lokal oder in einem Online-Datenspeicher. Dennoch ist ein ausreichendes Backup notwendig, um den Zugriff auf die Daten, die DataLad-Datensätze und die dazugehörige Historie nicht zu verlieren. Daher ist es üblich, eine Replik des Datensatzes und seines versionierten Verlaufs an einem anderen Ort mit ausreichend Speicherplatz zu speichern.

Wir arbeiten mit zwei Datenstrukturen, einer, in der die (Roh-)Daten gemäß den im genehmigten Tierprotokoll beschriebenen Experimenten gespeichert werden (Abb. 2C), und der zweiten, in der die projektspezifischen Daten gespeichert werden (Abb. 2A). Zunächst sammeln wir alle Rohdaten in einer einheitlichen Ordnerstruktur entsprechend den Hauptprojekten und Teilprojekten in unseren Tierversuchslizenzen und wie von den lokalen Behörden genehmigt. Ein typischer Rohdatenordner (MRI/raw_data/P1/SPs1c4m1_1_1_20180105_094610) spezifiziert das Experiment ( MRT), die Art der Daten (Rohdaten), den Zeitpunkt (P1, d. h. Tag 1 nach Schlaganfall), die Studien-ID (SPs1c4m1) und einen MRT-Hardware-spezifischen Code (Bruker) (d. h. Studiennummer, Rekonstruktionsnummer). , Datum als JJJJ-MM-TT und Uhrzeit als hh-mm-ss). Wir empfehlen, die Rohdaten in der Ordnerstruktur des Tierprotokolls zu speichern, was die Dokumentation für die Behörden vereinfacht. In einem zweiten Schritt werden vor der Initialisierung von DataLad für jedes Projekt/jede Veröffentlichung die Rohdaten aus einem oder mehreren Rohdatenordnern in der YODA-Struktur kopiert. Die YODA-Struktur fasst Dateneingabe, -ausgabe, Dokumente und Code in einer projektspezifischen Struktur zusammen (Abb. 2A).

Um den Überblick über die große Anzahl von Experimenten zu behalten, haben wir für jede Maus/jeden Scan eindeutige Kennungen erstellt (Abb. 1). Die Kennung (Studien-ID) kombiniert Elemente des Tierprotokolls, des (Teil-)Projekts, des Käfigs und der Tieranzahl pro Käfig. Beispielsweise bezieht sich SPs1c4m1 auf das Projekt SPasticity, Teilprojekt 1, Käfig 4, Maus 1. Grundsätzlich können weitere Informationen wie Geschlecht und Genotyp gemäß der gängigen Nomenklatur hinzugefügt werden, z. B. SPs1c4m1mRbp4, bezogen auf einen männlichen (m) Tg( Rbp4-cre)KL100Gsat (kurz Rbp4) Maus. Wichtig für translationale Studien ist, dass die Studien-IDs nicht geändert werden sollten, um die Versuchsgruppe dem Benutzer preiszugeben, d. h. der Benutzer bleibt während der Datenerfassung und -analyse blind. In jedem Fall sollten die Hauptfunktionen des Identifikators erhalten bleiben, nämlich die Anonymisierung des Subjekts (im Hinblick auf experimentelle Details) und die Identifizierbarkeit durch Such-/Sortierbegriffe im Schlüsselwortstil.

INFO: Die IDs beziehen sich auf das Tierprotokoll und werden in einer festen Ordnerstruktur ähnlich der im BIDS-Format gespeichert. Unsere Dateikonvention für die Benennung und Strukturierung von Dateien wurde festgelegt, bevor BIDS für Tier-MRT-Daten populär wurde. Daher haben wir Datensätze mit Unterstrichen und Bindestrichen als Trennzeichen, z. B. TP_T1_4_1. Wenn Benutzer das BIDS-Format verwenden möchten, kann der Workflow dennoch angewendet werden, da DataLad BIDS-kompatibel ist. Da BIDS jedoch auf bestimmte Zeichen, z. B. Bindestriche und Unterstriche, reagiert, sollten die IDs nur Zahlen und Buchstaben enthalten. Eine mögliche Alternative für SP_T1_4_1 wäre SPsT1c4m1, das die Unterstriche durch die Anfangsbuchstaben von Teilprojekt (s), Käfig (c) und Maus (m) ersetzt. Hinweis: Wenn in der Vergangenheit Sonderzeichen in den Studien-IDs enthalten waren, erfordert die BIDS-Kompatibilität der Dateien viel mehr Aufmerksamkeit, z. B. das Schreiben der korrekten Informationen auch in den NIfTy-Header und in alle zugehörigen Metadatendateien.

Wann immer möglich, werden die Elemente der Dateinamen entweder automatisch generiert oder sollten nach einem standardisierten Schema zugewiesen werden, das die StudyID, den Test/das Experiment und den Zeitpunkt (falls zutreffend) umfasst. Auf diese Weise ist der Dateiname eindeutig und enthält bereits wesentliche Metadaten. Beispielsweise würde sich SPs1c4m1CytD4 auf den Zylindertest (Cyt) beziehen, einen Mausverhaltenstest, der am Tag 4 (D4) mit der Studien-ID SPs1c4m1 durchgeführt wurde. Die Datei-/Ordnerpfade werden zusammen mit wichtigen Metadateninformationen zum Experiment in der elektronischen Datenbank13 gespeichert. Im Falle einer MRT umfasst dies das Anästhesieprotokoll (einschließlich des genauen Zeitpunkts und der Dosierung), Konfigurationsdetails (z. B. Spule, Gradient) und die Liste der MRT-Scans.

Gemäß den Grundregeln der Datenspeicherung30 werden nach Möglichkeit offene Datenformate verwendet. Unsere Datensätze umfassen ein breites Spektrum an Dateien, das von kleinen Textdateien bis hin zu größeren MRT-Dateien und Videoaufzeichnungen reicht. Es gibt keine generelle Einschränkung hinsichtlich der Kompatibilität des Dateiformats mit dem Workflow (Tabelle 2).

INFO: Für jedes Textdateiformat (z. B. TXT, CSV, JSON) verfolgt DataLad die Änderungen in der Datei Zeile für Zeile (ganzheitlich). Dadurch kann jede Zeile beispielsweise in Python-Code einem Commit (und Autor) zugeordnet werden, der sie zuletzt geändert hat (mithilfe der Git-Funktionalität). Bei allen anderen Datenformaten verfolgt DataLad mithilfe von Dateiprüfsummen den Unterschied pro Datei. Das heißt, es werden Informationen darüber gespeichert, wann und wer das Dokument geändert hat, nicht jedoch, welcher Teil der Datei geändert wurde. Im Hinblick auf Open Science und langfristige Nutzbarkeit wird empfohlen, wann immer möglich, zeilenweise Dateitypen (maschinenlesbar, z. B. csv) zu verwenden.

Wir empfehlen die Verwendung des Testdatensatzes27 (https://doi.org/10.12751/g-node.3yl5qi). Es enthält eine grundlegende Yoda-Struktur (Abb. 2A) und ist ausreichend klein, um eine schnelle Verarbeitung zu ermöglichen.

DataLad und GIN sind frei verfügbar. Das Manuskript enthält den gesamten Code zur Reproduktion des Arbeitsablaufs.

Nichols, TE et al. Best Practices bei der Datenanalyse und dem Datenaustausch in der Neurobildgebung mittels MRT. Nature Neuroscience 20(3), 299–303 (2017).

Artikel CAS PubMed PubMed Central Google Scholar

Niso, G. et al. Offene und reproduzierbare Neurobildgebung: Vom Beginn der Studie bis zur Veröffentlichung. https://doi.org/10.31219/osf.io/pu5vb (2022).

Markiewicz, CJ et al. Die OpenNeuro-Ressource für den Austausch neurowissenschaftlicher Daten. eLife 10 (Oktober). https://doi.org/10.7554/eLife.71774 (2021).

Europäische Organisation für Kernforschung und OpenAIRE. Zenodo. CERN. https://doi.org/10.25495/7GXK-RD71 (2013).

Wilkinson, MD et al. Die FAIR-Leitprinzipien für wissenschaftliches Datenmanagement und -verwaltung. Scientific Data 3(März), 160018 (2016).

Artikel PubMed PubMed Central Google Scholar

Mandino, F. et al. Funktionelle Magnetresonanztomographie bei Tieren: Trends und Weg zur Standardisierung. Frontiers in Neuroinformatics 13, 78 (2019).

Artikel PubMed Google Scholar

Gabelica, M., Bojčić, R. & Puljak, L. Viele Forscher hielten sich nicht an ihre veröffentlichte Erklärung zum Datenaustausch: Eine Studie mit gemischten Methoden. Journal of Clinical Epidemiology 150 (Oktober), 33–41 (2022).

Artikel PubMed Google Scholar

Die Prinzipien einer humanen experimentellen Technik. The Medical Journal of Australia 1(13), 500–500 (1960).

Begley, CG & Ioannidis, JPA Reproduzierbarkeit in der Wissenschaft: Verbesserung des Standards für Grundlagenforschung und präklinische Forschung. Zirkulationsforschung 116(1), 116–26 (2015).

Artikel CAS PubMed Google Scholar

Poldrack, RA et al. Den Horizont scannen: Auf dem Weg zu transparenter und reproduzierbarer Neuroimaging-Forschung Nature Reviews. Neurowissenschaften 18(2), 115–26. (2017).

Artikel CAS PubMed PubMed Central Google Scholar

Couture, JL, Blake, RE, McDonald, G. & Ward, CL Eine von Geldgebern auferlegte Datenveröffentlichungspflicht inspirierte selten zum Datenaustausch. PloS One 13(7), e0199789 (2018).

Artikel PubMed PubMed Central Google Scholar

Hanke, M. et al. Zur Verteidigung des dezentralen Forschungsdatenmanagements. Neuroforum 0 (0). https://doi.org/10.1515/nf-2020-0037 (2021).

Pallast, N., Wieters, F., Nill, M., Fink, GR & Aswendt, M. 2018. Cloudbasierte relationale Datenbank für multimodale Tierdaten. Datenbank: The Journal of Biological Databases and Curation https://doi.org/10.1093/database/bay124 (Januar 2018).

Halchenko, Y. et al. DataLad: Verteiltes System zur gemeinsamen Verwaltung von Code, Daten und deren Beziehungen. Journal of Open Source Software 6(63), 3262 (2021).

Artikel ADS Google Scholar

Gorgolewski, KJ et al. Die Datenstruktur der Bildgebung des Gehirns, ein Format zum Organisieren und Beschreiben der Ergebnisse von Neuroimaging-Experimenten. Scientific Data 3(Juni), 160044 (2016).

Artikel PubMed PubMed Central Google Scholar

Pallast, N. et al. Verarbeitungspipeline für die atlasbasierte Bilddatenanalyse der strukturellen und funktionellen Mausgehirn-MRT (AIDAmri). Frontiers in Neuroinformatics 13(Juni), 42 (2019).

Artikel PubMed PubMed Central Google Scholar

Wang, Q. et al. Das Allen Mouse Brain Common Coordinate Framework: Ein 3D-Referenzatlas. Zelle 181(4), 936–53.e20 (2020).

Artikel CAS PubMed PubMed Central Google Scholar

Wachtler, T. et al. NFDI-Neuro: Aufbau einer Community für neurowissenschaftliches Forschungsdatenmanagement in Deutschland. Neuroforum 0 (0). https://doi.org/10.1515/nf-2020-0036 (2021).

Kuhn, L. et al. Eine Datenmanagement-Infrastruktur für die Integration von Bildgebungs- und Omics-Daten in den Biowissenschaften. BMC Bioinformatics 23(1), 61 (2022).

Artikel Google Scholar

Borghi, JA & Van Gulick, AE-Datenmanagement und -austausch in der Neurobildgebung: Praktiken und Wahrnehmungen von MRT-Forschern. PloS One 13(7), e0200562 (2018).

Artikel PubMed PubMed Central Google Scholar

Percie du Sert, N. et al. Die ARRIVE-Richtlinien 2.0: Aktualisierte Richtlinien für die Meldung von Tierversuchen. Journal of Cerebral Blood Flow and Metabolism: Amtsblatt der International Society of Cerebral Blood Flow and Metabolism 40(9), 1769–77. (2020).

Artikel PubMed Google Scholar

Colomb, J., Arendt, T. & Sehara, K. Das Gin-Tonic-Team. Auf dem Weg zu einer standardisierten Forschungsordnerstruktur. https://doi.org/10.25815/WCY6-M233 (2021).

Artikel Google Scholar

Marcus, DS et al. Das Extensible Neuroimaging Archive Toolkit: Eine Informatikplattform zum Verwalten, Erkunden und Teilen von Neuroimaging-Daten. Neuroinformatik 5(1), 11–34 (2007).

Artikel PubMed Google Scholar

Swedlow, JR 2007. Die offene Mikroskopieumgebung: Ein kollaboratives Datenmodellierungs- und Softwareentwicklungsprojekt für die biologische Bildinformatik. In Imaging Cellular and Molecular Biological Functions, 71–92. Berlin, Heidelberg: Springer Berlin Heidelberg.

Huguet, J. et al. Management und Qualitätskontrolle großer Neuroimaging-Datensätze: Entwicklungen des Barcelonaβeta Brain Research Center. Frontiers in Neuroscience 15 (April), 633438 (2021).

Artikel PubMed PubMed Central Google Scholar

Poline, JB et al. Datenaustausch in der Neuroimaging-Forschung. Grenzen der Neuroinformatik 6 (April), 9 (2012).

PubMed PubMed Central Google Scholar

Aswendt, M. & Kalantari, A. Ein DataLad-Datensatz für eine beispielhafte Struktur eines multimodalen Tierdaten-Repositorys, G-Node, https://doi.org/10.12751/g-node.3yl5qi (2023).

Harris, PA et al. Research Electronic Data Capture (REDCap) – eine metadatengesteuerte Methodik und ein Workflow-Prozess zur Bereitstellung translationaler Forschungsinformatikunterstützung. Journal of Biomedical Informatics 42(2), 377–81 (2009).

Artikel PubMed Google Scholar

Wagner, AS et al. Ziemlich groß: Ein Framework für die rechnerisch reproduzierbare Verarbeitung großer Datenmengen. Wissenschaftliche Daten 9(1), 80 (2022).

Artikel PubMed PubMed Central Google Scholar

Hart, EM et al. Zehn einfache Regeln für die digitale Datenspeicherung. PLoS Computational Biology 12(10), e1005097 (2016).

Artikel PubMed PubMed Central Google Scholar

Sandström, M. et al. Empfehlungen für Repositorien und wissenschaftliche Gateways aus neurowissenschaftlicher Sicht. Wissenschaftliche Daten 9(1), 212 (2022).

Artikel PubMed PubMed Central Google Scholar

Referenzen herunterladen

Diese Arbeit wurde von der Friebe-Stiftung (T0498/28960/16) und der Deutschen Forschungsgemeinschaft (DFG) gefördert – Projekt-ID 431549029 – SFB 1451. Wir danken der DFG (Deutsche Forschungsgemeinschaft) für die Unterstützung der Artikelbearbeitungsgebühr , 491454339).

Open-Access-Förderung ermöglicht und organisiert durch Projekt DEAL.

Universität zu Köln, Medizinische Fakultät und Universitätsklinikum Köln, Klinik für Neurologie, Köln, Deutschland

Aref Kalantari & Markus Aswendt

Psychoinformatik-Labor, Institut für Neurowissenschaften und Medizin, Gehirn und Verhalten (INM-7), Forschungszentrum Jülich, Jülich, Deutschland

Michał Szczepanik, Stephan Heunis, Christian Mönch & Michael Hanke

Institut für Systemneurowissenschaften, Medizinische Fakultät, Heinrich-Heine-Universität, Düsseldorf, Deutschland

Michael Hanke

Faculty of Biology, Ludwig-Maximilians-Universität München, Planegg-Martinsried, München, Germany

Thomas Wachtler

Kognitive Neurowissenschaften, Institut für Neurowissenschaften und Medizin (INM-3), Forschungszentrum Jülich, Jülich, Deutschland

Markus Aswendt

Sie können diesen Autor auch in PubMed Google Scholar suchen

Sie können diesen Autor auch in PubMed Google Scholar suchen

Sie können diesen Autor auch in PubMed Google Scholar suchen

Sie können diesen Autor auch in PubMed Google Scholar suchen

Sie können diesen Autor auch in PubMed Google Scholar suchen

Sie können diesen Autor auch in PubMed Google Scholar suchen

Sie können diesen Autor auch in PubMed Google Scholar suchen

Konzeptualisierung: AK, MA, MS, Datenkuration: AK, Formale Analyse: AK, MA, Finanzierungseinwerbung: MA, MH, Untersuchung: AK, MA, Methodik: AK, MS, TW, MH, MA, Projektverwaltung: MA, Ressourcen: MA, Software: AK, MA, Betreuung: MA, MH, Visualisierung: MA, AK, Schreiben – Originalentwurf: MA, AK, MS, SH, TW, Schreiben – Überprüfung und Bearbeitung: MA, AK, CM, SH , MH, TW,Alle Autoren haben das endgültige Manuskript gelesen, bearbeitet und genehmigt.

Korrespondenz mit Markus Aswendt.

MS, SH, CM und MH sind Entwickler der kostenlosen Open-Source-Software DataLad. TW ist an der Entwicklung der freien und Open-Source-Software GIN und der Bereitstellung der GIN-Plattform beteiligt. Die anderen Autoren berichten von keinen konkurrierenden Interessen.

Anmerkung des Herausgebers Springer Nature bleibt hinsichtlich der Zuständigkeitsansprüche in veröffentlichten Karten und institutionellen Zugehörigkeiten neutral.

Open Access Dieser Artikel ist unter einer Creative Commons Attribution 4.0 International License lizenziert, die die Nutzung, Weitergabe, Anpassung, Verbreitung und Reproduktion in jedem Medium oder Format erlaubt, sofern Sie den/die ursprünglichen Autor(en) und die Quelle angemessen angeben. Geben Sie einen Link zur Creative Commons-Lizenz an und geben Sie an, ob Änderungen vorgenommen wurden. Die Bilder oder anderes Material Dritter in diesem Artikel sind in der Creative Commons-Lizenz des Artikels enthalten, sofern in der Quellenangabe für das Material nichts anderes angegeben ist. Wenn Material nicht in der Creative-Commons-Lizenz des Artikels enthalten ist und Ihre beabsichtigte Nutzung nicht durch gesetzliche Vorschriften zulässig ist oder über die zulässige Nutzung hinausgeht, müssen Sie die Genehmigung direkt vom Urheberrechtsinhaber einholen. Um eine Kopie dieser Lizenz anzuzeigen, besuchen Sie http://creativecommons.org/licenses/by/4.0/.

Nachdrucke und Genehmigungen

Kalantari, A., Szczepanik, M., Heunis, S. et al. So erstellen und pflegen Sie mit DataLad einen multimodalen Tierversuchsdatensatz. Sci Data 10, 357 (2023). https://doi.org/10.1038/s41597-023-02242-8

Zitat herunterladen

Eingegangen: 19. Dezember 2022

Angenommen: 15. Mai 2023

Veröffentlicht: 05. Juni 2023

DOI: https://doi.org/10.1038/s41597-023-02242-8

Jeder, mit dem Sie den folgenden Link teilen, kann diesen Inhalt lesen:

Leider ist für diesen Artikel derzeit kein gemeinsam nutzbarer Link verfügbar.

Bereitgestellt von der Content-Sharing-Initiative Springer Nature SharedIt