Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add another example to inheritance principle for .json without entities #2019

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

yarikoptic
Copy link
Collaborator

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
    Replace "inheritance" with "summarization" principle 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 ;-)

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 ;-)
Copy link
Collaborator

@effigies effigies left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The legacy validator required the task entity for BOLD files, but the schema validator consistently permits entity-less top-level JSON for any suffix.

@effigies
Copy link
Collaborator

To save other reviewers time:

link

image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants