Open kousu opened 2 years ago
This is a valid concern. However, merging these participants would break the analysis code, so there is a pros/cons here.
I'll fix the analysis code.
Turns out, the hardware field already has a place to go in BIDS: it goes in the .json, not in the filename, and we have this data in the right place already:
And BIDS recommends encoding multiple visits/scans by nesting them a level deeper under ses-<label>/
.
I propose
either not encoding the scanner in the filename at all but adding a session field, or encoding it in the 'session' field: sub-tokyo{scanner}{id}
-> sub-tokyo{id}_ses-{scanner}
So, either:
u108545@joplin:~/data-multi-subject$ mkdir -p sub-tokyo05 && git mv sub-tokyoIngenia05/ sub-tokyo05/ses-01
or
u108545@joplin:~/data-multi-subject$ mkdir -p sub-tokyo05 && git mv sub-tokyoIngenia05/ sub-tokyo05/ses-Ingenia
but repeated for each every subject. For most subjects with only one session, BIDS still wants us to nest a ses-01/
folder:
The extra session layer (at least one /ses-
Merging the tokyo subjects:
either
git mv sub-tokyoSkyra{id} sub-tokyo{id}/ses-02
git mv sub-tokyo750w{id} sub-tokyo{id}/ses-03
or
git mv sub-tokyoSkyra{id} sub-tokyo{id}/ses-Skyra
git mv sub-tokyo750w{id} sub-tokyo{id}/ses-750w
Move the date
, manufacturer
, manufacturers_model_name
from participants.tsv
to per-subject sub-tokyo{id}/sub-tokyo{id}_sessions.tsv
files
Changing the analysis code to parse out the information when it needs it from either the .json
s, or the _session.tsv
files, not the filenames.
thank you @kousu, this seems like a very reasonable plan. In terms of index vs. scanner name in the filename, i do have a slight preference for encoding in the file name, just because it is more human friendly
thank you @kousu, this seems like a very reasonable plan. In terms of index vs. scanner name in the filename, i do have a slight preference for encoding in the file name, just because it is more human friendly
Great. I can do that!
Reviving this thread, given a recent comment https://github.com/spine-generic/data-multi-subject/issues/166 and the demographic-based project from @renelabounek. We should find a reasonable strategy to deal with the same subjects being scanned at multiple sites. The solutions proposed in https://github.com/spine-generic/data-multi-subject/issues/102#issuecomment-969444920 is problematic, in that the logic of the analysis code and results should be drastically different. I'm wondering if simply adding a column in the https://github.com/spine-generic/data-multi-subject/blob/113b258695074b77d40ba987474eddc14f9d9698/participants.tsv with an arbitrary ID for each subject could properly address this? Then, for projects where the demographics of the subject is relevant (eg: @renelabounek project), the specific analysis code could use that information (by, eg., selecting non-duplicate subjects based on their IDs as opposed to based on the participant_id
).
There are 15
sub-tokyo
subjects; however, there's actually only 5 real subjects involved, each scanned on three different MRI scanners. For example:It is safer, and probably more BIDS-compliant, if we represented the "different scanner" field using an
acq-
entity (or possiblyses-
), and put these scans all under a single folder (sub-tokyo01
). Then we only need to record their tabular data once inparticipants.tsv
and repairs like #96 won't be so fraught to perform.Discovered in https://github.com/spine-generic/data-multi-subject/pull/96#issuecomment-930497296