[ENH] Clarify the position toward non-compliant derivative datasets and files#334
Conversation
|
Given the lack of critique, I'm going to propose this to be included in common derivatives. I would appreciate reviews, @bids-standard/derivatives. |
PeerHerholz
left a comment
There was a problem hiding this comment.
IMO, the clarification is clear and sound.
| (see [Non-compliant datasets][non-compliant-datasets] for further discussion). | ||
| This specification does not prescribe anything about the contents of `sourcedata` | ||
| folders in the above example - nor does it prescribe the `sourcedata`, | ||
| `derivatives`, or `rawdata` folder names. |
There was a problem hiding this comment.
The last part is a bit confusing to me:
nor does it prescribe the
sourcedata,derivatives, orrawdatafolder names.
with that you mean that I can call my BIDS dataset root, e.g. eeg_matchingpennies ... or whatever - and it is valid BIDS? However, WITHIN eeg_matchingpennies, I am not free to give sourcedata any other name than sourcedata.
I think this could be clarified.
There was a problem hiding this comment.
No, I understand it as
-- whatevenyoucallthis
|-- sourcedata_or_so
|-- rawdata_in_bids
`--pipeline_results_or_so
|-- pipeline1_in_bids
`-- pipeline2_in_bids
where the top level is up to you (e.g. it could be D:), and neither sourcedata_or_so nor pipeline_results_or_so are themselves according to BIDS. But both rawdata_in_bids and each pipelineX_in_bids directories is a BIDS dataset. So BIDS only starts playing a role further down in the directory tree, and there are three (related) BIDS datasets here.
There was a problem hiding this comment.
I think that the example might already be more clear if it would be renamed like this
my_project/
originaldata/
...
rawdata/
dataset_description.json
participants.tsv
sub-01/
sub-02/
...
my_results/
pipeline_1/
pipeline_2/
...
where only rawdata, pipeline_1 and pipeline_2 are organized according to BIDS.
There was a problem hiding this comment.
Yes, @robertoostenveld's interpretation is correct. I think part of the issue is that that context is missing from the diff.
Still, I'm happy to make any modifications (such as that suggested by Robert) which make that clearer.
|
This one has had a reasonable review period, IMO. For further concerns, please comment directly on #265. |
This is a proposal in follow-up to #265 (comment) and the ongoing discussion. It is not intended for immediate inclusion, but as a concrete example that can be discussed and critiqued.
This is also related to #264, where discussion of non-standard files in the main specification is being updated.
@bids-standard/derivatives I would appreciate wide input on this, as it has a significant impact on the overall interpretation of the standard, with regard to tooling.