Commit 4a01d9b
Add another example to inheritance principle for .json without entities (#2019)
Upon re-reading current Inheritance principle formulation, nothing seems to
forbid that, and such use in general is great since allows to generalize
common metadata across all files of that datatype.
Notes on possible side-effects from "embracing" such approach (which in
principle I think is not disallowed ATM).
- per rule 4, presence of `bold.json` forbids presence of another `_bold.json`
(i.e with entity) on the same level. So if further specialization e.g. per
each task- is needed, common metadata needs to be duplicated across them
(that is what heudiconv does ATM).
Such restrictions could potentially be elevated if we adopt
"summarization" refactoring of inheritance principle
bids-standard/bids-2-devel#65
since order would stop to matter and thus multiple files can apply.
- I think that bids-validators are fine as checked on a single
ds000248/T1w.json in bids-examples and modified 7t_trt.
- I do not know if tools implement it though but since there was precedence
for ds000248/T1w.json - they better do ;-)
Co-authored-by: Julia-Katharina Pfarr <111446107+julia-pfarr@users.noreply.github.com>1 parent 557ca40 commit 4a01d9b
1 file changed
+22
-0
lines changed| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
909 | 909 | | |
910 | 910 | | |
911 | 911 | | |
| 912 | + | |
| 913 | + | |
| 914 | + | |
| 915 | + | |
| 916 | + | |
| 917 | + | |
| 918 | + | |
| 919 | + | |
| 920 | + | |
| 921 | + | |
| 922 | + | |
| 923 | + | |
| 924 | + | |
| 925 | + | |
| 926 | + | |
| 927 | + | |
| 928 | + | |
| 929 | + | |
| 930 | + | |
| 931 | + | |
| 932 | + | |
| 933 | + | |
912 | 934 | | |
913 | 935 | | |
914 | 936 | | |
| |||
0 commit comments