Open adelavega opened 1 year ago
Datatype is not listed as an entity in the schema. Maybe it makes sense to treat it the same way as extension/suffix, i.e. as an additional property of the Artifact class.
This will require to extend the Artifact's definition:
Artifact:
.doc: >-
An artifact is a file whose name conforms to the BIDS file naming convention.
.extends: File
suffix:
type: str
use: required
**datatype:
type: str**
entities:
type: EntityRef
min: 1
max: -1
yes, I did notice that its not in the schema. I think we will need to think about whether datatype should be deprecated or added to the schema to minimize "exceptions"
Datatype is in the schema:
What I am not sure about yet is how to handle the datatype in derivatives as files are not required to be in a datatype (sub-)folder. Can we reliably infer the datatype from the suffix in case a file is not in a datatype folder?
Can we reliably infer the datatype from the suffix in case a file is not in a datatype folder?
I don't think the BIDS specs ever defined a 1:1 mapping between suffix
and datatype
tbh.
It took me several read to understand the modality
-> datatype
-> suffix
hierarchy and how it relates to file collections.
It just happens that most modalities define a 1:1:1 between all three so it's easy to make this shortcut. I started to reconsider when I read about events, and then much later when the derivatives specs were refined.
in derivatives [...] files are not required to be in a datatype (sub-)folder.
AFAIK, datatype
is still listed in the derivatives section of the specs, and all proposed derived types feature one.
See: https://github.com/bids-standard/pybids/pull/863#discussion_r1026856773