-
Notifications
You must be signed in to change notification settings - Fork 12
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
Next steps for BIDS-Prov #125
Comments
In terms of documenting the format specification of BIDS-Prov within the BIDS specification, I can imagine that it would be shortly mentioned in the https://bids-specification.readthedocs.io/en/stable/02-common-principles.html or in the https://bids-specification.readthedocs.io/en/stable/03-modality-agnostic-files.html sections, and then elaborated upon in an appendix. I can imagine that the BIDS-Prov specific tooling (like the visualizer, but possibly also a non-graphical validator) could continue to live in their own repository under the bids-standard organization. |
If future BIDS extensions like derivatives for ephys heavily depend on BIDS-Prov (i.e., to specify ephys derivatives one MUST use BIDS-Prov), then I think BIDS-Prov should be maintained 100% within BIDS. Else, if BIDS-Prov becomes something like a "recommended way to document provenance" but not strictly necessary within BIDS, then I would vote for it living in its own repository (like statsmodels, execution, ... ) with only a short mention in the BIDS spec.
|
I think we could have a situation where the BIDS-Prov format definition lives on its own, but some way of defining required entries could still live in BIDS. Similar to how we specify JSON metadata keys/values without defining JSON inside BIDS. |
I do not think any derivatives should rely heavily/depend on BIDS-Prov (jsonld) which is why we have introduced the descriptions.tsv, allowing to specify all the steps performed, but if one wants to include a full reproducible workflow then use BIDS-Prov From a more general perspective, BIDS is about documenting data, and BIDS-Prov documents a process (which I agree gives rise to the data, still it's not the same as a json next to a file). In that respect it does make sense to live next to the main spec. |
I am inviting @bclenet to the discussion as he will be working on BIDS-Prov form now. |
I'm opening this issue to figure out what a finalized BIDS-Prov would look like. A couple options:
Other arrangements could be imagined, but I think the "in BIDS" or "alongside BIDS" distinction is the main one to settle on, and then work out the details.
Other questions:
@bids-standard/steering
@bids-standard/maintainers
The text was updated successfully, but these errors were encountered: