[FIX] Add resolution metadata in derivative

[Remi-Gau]

• fixes https://github.com/bids-standard/bids-validator/issues/1790

[Remi-Gau]

@effigies
While fixing this I started wondering about the way the spec says resolution entity metadata can be store as a string or an object of strings.

Example JSON file corresponding
to pipeline1/sub-001/func/sub-001_task-rest_run-1_space-MNI305_bold.json
above:

{
  "SkullStripped": true,
  "Resolution": {
    "hi": "Matched with high-resolution T1w (0.7mm, isotropic)",
    "lo": "Matched with original BOLD resolution (2x2x3 mm^3)"
  }
}

What was the rationale for allowing Resolution to be an object of strings?
Was it to minimize duplication of metadata?

I am worried of how the inheritance principle will play with this.

[effigies]

What was the rationale for allowing Resolution to be an object of strings? Was it to minimize duplication of metadata?

I am worried of how the inheritance principle will play with this.

I guess the idea was so we could say at the root level space-MNI152NLin2009cAsym_bold.nii.gz, and not duplicate with res-hi and res-lo. I think the advantage at leaf level is basically nil, so I wouldn't expect people to go through the trouble of creating them if they don't intend to put them at the root.

[effigies]

Maybe worth saying that I have a mental model where a tool will basically shunt all incoming metadata into exact-match sidecars (since it "sees" metadata as being attached to the individual file) while specifying its own conventions at the root level, as it will know if it always means the same thing with entityX-valueY_suffixZ.

[Remi-Gau]

I see.
Thanks for the explanations