Dataset-specific question about subdatasets and BIDS

[adswa]

Origin: private email

I got the following German email:

Liebe Adina,
ich erinnere mich noch immer gern an Deinen RDM Workshop, den Du noch in Covid-Zeit bei uns online in Hamburg gehalten hast. Das war wirklich informativ und in vielen Aspekten eine Eye Opener.
Ich habe aber jetzt eine konkrete Frage zu Organisation eines umfangreichen Datensatzes und mir würde sehr an Deiner Meinung liegen.
Wir haben einen großen EEG Hyperscanning Datensatz, in dem die Probanden eine single agent und jeweils eine von 2 multi-agent tasks über mehrere Runs gemacht haben. D.h. jeder Probanden hat Daten von 2 tasks (single und kooperativ/kompetitiv). Normalerweise würde (gemäß BIDS) alle Tasks in einem dataset zusammenfassen, aber nun sieht es eher so aus, dass wir zunächst nur die Single agent Daten allein analysieren und publizieren werden, und dass sich das preprocessing bei den unterschiedlichen Tasks auch etwas voneinander unterscheiden wird. Daher folgende Fragen:

1. Macht es aus Deiner Erfahrung eher Sinn, verschiedene subdatasets zu definieren und diese dann getrennt zu bearbeiten?
2. Wenn ja, müssen die unterschiedlichen Datensätzen in distinktiv Ordner organisiert sein (also z.B. single/sub-101/eeg, coop/sub-101/eeg, comp/sub-101/eeg etc.), damit datalad mit diese gut umgehen kann, oder können diese verschiedenen Files eines subdatasets auch im selben Ordner liegen (also z.B. sub-101/eeg/sub-101_task-single_run-01_eeg.bdf, sub-101/eeg/sub-101_task-coop_run-01_eeg.bdf, sub-101/eeg/sub-101_task-comp_run-01_eeg.bdf)? Letzteres würde ja eher die Provenienz der Daten reflektieren (alles aus einem Subject), zumal es auch noch MRIs für die Quellenlokalisation für jeden Subject gibt und diese dann in der ersten Variante in alles subdatasets kopiert werden müsste, oder?
   Bin gespannt auf Deine Meinung.
   Viele Grüße,

TODO (not necessarily to be performed in this order)

• Inform OP/Add reference to this issue at origin
• Clarifying Qs asked or not needed
• Nature of the issue is understood
• Inform OP about resolution

[adswa]

Here is my response (sorry, again in German). It would be nice if others could read it and chime in about what I might have missed, their personal opinions, or anything else that comes to mind.

Ich freue mich, dass der Workshop gut angekommen ist!
Bzgl. deiner Frage:
Technisch gesehen sollte es bei keiner Organisation für DataLad Probleme geben, außer euer Datensatz besteht aus mehreren 100.000 Dateien. Falls doch, macht es Sinn, subdatasets so zu teilen, dass nicht mehr als 300k files in einem Dataset sind (sonst kommt Git langsam an seine Grenzen).

BIDS-konform zu organisieren ist immer eine gute Idee. Die distinkte Organisation, die du in 2. am Anfang ansprichst, würde ich nicht machen, denn sie ist meines Wissens nach nicht BIDS konform, und dann macht ihr euch und anderen Nutzern unnötige Arbeit wenn BIDS-Validierungen bei BIDS Apps oder Datenpublikation fehlschlagen. Deinem Vorschlag BIDS konform zu bleiben ('sub-101/eeg/sub-101_task-single_run-01_eeg.bdf', 'sub-101/eeg/sub-101_task-coop_run-01_eeg.bdf', 'sub-101/eeg/sub-101_task-comp_run-01_eeg.bdf') würde ich zustimmen, und das ist auch kein Problem für DataLad. Die MRT Daten perspektivisch BIDS-konform hinzuzufügen (sub-101/mri/...) ist ebenso sinnvoll und technisch kein Problem.

Ob ihr mehrere individuelle BIDS-konforme datasets (zB eines pro task) oder ein Gesamtdataset ist technisch für DataLad egal. Eure Pläne für die weitere Nutzung sind da die beste Entscheidungshilfe. Ich kann zwei reale Beispiele geben, die mit einem ähnlichen Problem unterschiedlich umgehen:

• Variante A: Es gibt ein Gesamt-Dataset mit allen Daten. Aus diesem Dataset werden kleinere Datasets mit einem subset von Daten erstellt, die dann individuell veröffentlicht oder analysiert werden können, aber bei Änderungen im Gesamt-Dataset einfach geupdated werden können. Reales Beispiel: So haben wir das mit dem Human Connectome Dataset gemacht[1]. Das Gesamtdataset hat alle Daten aller Probanden. Damit spezifische Analysen einfacher werden, haben wir daraus kleinere Datasets gemacht. Zb https://github.com/datalad-datasets/hcp_wm_preprocessed, das nur die Daten für die working memory task enthält. Dieses Dataset haben wir aus dem großen heraus erstellt (https://handbook.datalad.org/en/latest/beyond_basics/101-149-copyfile.html beschreibt wie genau). Beide datasets holen sich file content via datalad get vom gleichen Ort, d.h. die Daten, die in beiden Datasets sind, müssen nicht zwangsläufig an zwei verschiedenen Stellen gespeichert werden.
  Auf euren Datensatz angewandt würde das bedeuten: Es gibt ein Datenset mit allen tasks, nennen wir es 'hyperscanning'. Für die single agent task macht ihr ein weiteres Dataset ('single-agent'), verlinkt das 'hyperscanning' dataset als subdataset, und copy-file'd die single agent Dateien daraus in 'single-agent'. Das single-agent dataset könnt ihr dann stand-alone weiterverarbeiten und/oder veröffentlichen, ohne das Nutzer etwas von den anderen tasks in 'hyperscanning' bemerken, aber updates aus 'hyperscanning' könnten leicht integriert werden.

• Variante B: Es gibt einzelne datasets pro task. Sobald es relevant ist, werden sie unter einem gemeinsamen superdataset zusammen verlinkt.
  Reales Beispiel: Der Studyforrest Datensatz. Der wurde über Jahre hinweg mit weiteren Messungen der selben Teilnehmer erweitert und in distinken Datasets publiziert, zb https://github.com/psychoinformatics-de/studyforrest-data-phase2 für task-fmri mit einen Filmstimulus und https://github.com/psychoinformatics-de/studyforrest-data-retinotopy mit retinotopic mapping. Die Subject IDs sind zwischen datasets gleich. Die Gesamtheit aller datasets, die im Laufe der Jahre publiziert wurden, haben wir dann in einem superdataset zusammengefasst: https://github.com/psychoinformatics-de/studyforrest-data. Das ist nicht BIDS-konform, ist aber quasi "entry-point" für alle verfügbaren Daten.
  Auf euren Datasatz angewant würde das bedeuten: Ihr macht ein BIDS dataset, zb pro task, und publiziert die standalone. Ein große Superdataset kann dann ein einfacher entrypoint sein, um alle Daten auf einmal leicht finden zu können.

Beide Varianten haben unterschiedliche Vorteile und Konsequenzen. Zum Beispiel beim Thema Maintenance: In Variante A ist das 'hyperscanning' dataset der Ort für maintenance. Dh wenn ihr einen Fehler bei einer Erhebung bemerkt und ihn korrigieren wollt, dann würde das in 'hyperscannig' passieren. Das kleinere 'single-agent' dataset, das (reproduzierbar) aus 'hyperscanning' erstellt wurde, kann dann automatisch geupdated werden. In Variante B ist es andersherum, die individuellen task-spezifischen Datasets kriegen maintenance. Wenn es files gibt, die in mehreren Datasets existieren (zb MRIs für Quellenlokalisation) kann das Mehraufwand bedeuten. Variante A macht es euch leichter, Daten von verschiedenen Tasks zu kombinieren, da es ein einzelnes BIDS dataset gibt; in Variante B könnte es schwieriger sein. Individuell veröffentlichen ist dafür B einfacher.

Und es geht natürlich auch ein Mittelding: Ein großer BIDS-konformer Rohdatensatz mit allen Daten, und kleinere Datasets die ihn als input dataset benutzen, um subsets der Daten auf spezifische Arten und Weisen zu präpreozessieren. Die subsets kann man individuell publizieren, aber gleichzeitig ist es immer noch leicht möglich, mit dem Rohdatensatz verschiedene tasks o.ä. zu kombinieren.

[loj]

I think you covered the options well! My personal recommendation would be variant A or the "Mittelding" option.

The important point that I would stress (which you mention at the beginning) is that the number of files matters. Otherwise, nothing else comes to mind.

[loj]

I think there's some wisdom in here that could be turned into a KBI. I will see if I can craft something.