Check that phys2bids is BIDS 1.3.0 compliant.

[smoia]

Detailed Description

At the moment, the latest stable BIDS is v.1.3.0.
BIDS has detailed specifications on many things, starting with how the files should be named, how they should be organised internally (see #184), how information should be reported (see #127).
I'm not totally sure that phys2bids complies to that specification - although we definitely have to!

Possible Implementation

1. Read BIDS 1.3.0, especially the section relative to physiological files, functional MRI files, units of measure.
2. Check that our output is compliant to that specification
3. If not, open bug issues to have it fixed
4. Add in the documentation and in the readme that we are bids 1.3.0 compliant (a sentence? a nice badge?)

[smoia]

@RayStick @rmarkello , do you think this could be a good first issue?

[smoia]

@vinferrer at what point is this issue? Do you need any help?

[vinferrer]

I didn't had time to go through it. Help is always welcome, specially since i am no expert in BIDS and I am bad at details. Which is important for standards

[vinferrer]

In theory #222 should close the units of measure part. Although mmHg is a cranky issue since is not bids standard but is necessary in some channels.

[vinferrer]

I don't understand in which way specifically functional MRI files standard affects us. I suppose it is in an indirect manner

[vinferrer]

I tried the tutorial file with the heuristic and the names and structure seem to check with bids standard

[vinferrer]

However in this case there is not stimuli file, don't think we have those

[vinferrer]

Lastly, regarding the JSON file, all seems good to me. However, I was wondering what happens with the sampling frequency when you have multifrequency files. Does that generate different tsv and JSON files for each frequency?

[smoia]

Lastly, regarding the JSON file, all seems good to me. However, I was wondering what happens with the sampling frequency when you have multifrequency files. Does that generate different tsv and JSON files for each frequency?

Indeed, as it's the expected output to have BIDS compliant physiological files (from what I understood from the BIDS specs).

However in this case there is not stimuli file, don't think we have those

We don't for the moment. I don't know if we want to support Respiract files, in which case we might have stimuli files? @RayStick @BrightMG what do you think about this?

I don't understand in which way specifically functional MRI files standard affects us. I suppose it is in an indirect manner

They affect the physiological files since the name of the files should be deriving from the fMRI (/EEG/MEG?) file relative to the same scan. In fact, once #219 is in place, it would be nice to see if we can automate this process in general and get the filenames from BIDS structures (rather than from heuristics or yamls).

Thank you @vinferrer for the check. I think that, once you are positive about how things work, we can close this issue with a PR that specifies in the main readme and in the documentation first page (index.rst) that we are 1.3.0 compliant!

[RayStick]

I don't know if we want to support Respiract files, in which case we might have stimuli files? @RayStick @BrightMG what do you think about this?

In the context of physiological data, what do we specifically mean by stimuli files? We kind of have something like a stimuli file with the RespirAct, which programs how we want PETCO2 and PETO2 to change. But we don't have triggers recorded alongside the physiological data (yet) so I assume that'd make it problematic to incorporate into phys2bids?

[vinferrer]

Should we update this issue?https://bids-specification.readthedocs.io/en/stable/

[vinferrer]

Or we go for BIDS 1.3 compilant and then open one for 1.4?

[smoia]

Let's see if we can get the help from the public:
@effigies, we prepared this software to be BIDS 1.3.0 compliant. We saw today that BIDS is now at version 1.4.0.
Since we don't have derivatives as outputs (phys2bids prepares only the raw data), do you think we're also 1.4.0 compatible, or are there more differences between the two BIDS versions?

[smoia]

Looking at the changelog, we should be fine, but I think there is a BIDS validator somewhere. @vinferrer, could you check if our outputs pass the validator? If so, we should be good to go.

[effigies]

We aim for backwards compatibility with the spec, so anything that was valid should still be. (If you had something unspecified, then it could now be specified otherwise, though.) I think you're probably safe, but I would check the changelog to be sure.

[smoia]

@effigies cool, thank you!
Is there a nice badge the BIDS team has to specify the compatibility? If not, we're just going to state which version we're at!

[robertoostenveld]

some files that I see are missing in the tutorial output folder

dataset_description.json
participants.tsv
participants.json (optional)
README
CHANGES (optional)

[vinferrer]

Tutorial output folder: https://drive.google.com/drive/folders/1ZtpONACc443iqasCzmqwDmx3eilcFI8j?usp=sharing

[robertoostenveld]

I am not sure whether .tsv.gz is allowed.
the .log file is not part of BIDS (afaik)

[vinferrer]

Thanks Robert, I was able to review the bids struct to see if we can tackle the basic stuff so we are bids compatible ( in a minimum way) and then build from there. If I am correct the compulsory files that we lack are:

dataset_description.json
Fields
Name (Required)
BIDSVersion (Required)
DatasetType (Recommended)
License (Recommended)

Participants.tsv
Fields
participant_id (Required)
age (Recommended)
sex (Recommended)
handedness (Recommended)

README

So I am gonna create an issue for this where we tackle these basic errors

[vinferrer]

I am not sure whether .tsv.gz is allowed.
the .log file is not part of BIDS (afaik)

Actually, in physiolical recording files tsv.gz is the standard, but for sure we will move away the .log file. Thanks for the help @robertoostenveld

[smoia]

I believe this is closed now?