-
Notifications
You must be signed in to change notification settings - Fork 165
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
ElectricalStimulationParameters: objects instead of string #1669
Comments
Permitting arbitrary objects is an invitation for incompatibility. With strings, at least there can be no assumption of compatibility, and they practically demand human intervention. This seems like a thing to seek agreement on among producers and consumers of these metadata, and at least avoid conflict with iEEG - Electrical stimulation and BEP 26 - Multi-electrode recordings, BEP 32 - Animal electrophysiology, and BEP 37 - Non-Invasive Brain Stimulation. |
This is a really nice overview of what type of stimulation parameters could be used! The question seems where to store this information: in the _ieeg.json file or somewhere else? I am not sure what a good location would be if the _ieeg.json would explode with this information. perhaps linking across to a more detailed specification of other stimuli in general? In issue #153 there is a discussion of a more detailed representation of stimuli conditions. |
I would definitely urge to discuss with BEP37 to make sure that the standardization of invasive and non invasive brain stimulation are, at a minimum, not in conflict with each other and, at best, overlap as much as possible in terms terminology and where to store what information. BEP37 has done a lot work trying to map out the different use cases for non invasive brain stimulation. I would be surprised if some common ground could not be found. |
Agree that there is lots of overlap with BEP 37 - Non-Invasive Brain Stimulation. |
Happy New Year, and thanks for the feedback. |
as per BIDS rules, all BEP documents that are open should allow comments from the public :-) so you should be able to just comment. However, if you intend to give extensive feedback, then getting in touch with the BEP leads beforehand can't hurt! |
Is this a good candidate for BIDS 2.0 and be moved/copied to https://github.com/bids-standard/bids-2-devel/ ? |
I don't think there are blockers to implement this in BIDS 1.0, so it's a future item, but not necessarily BIDS 2.0 |
Hi,
Is it necessary for the data type for ElectricalStimulationParameters to be a string? Since it is a free text field anyway, would it not be possible to use a nesting of objects as a data type, as with the hardware filters? I can speak here primarily from the perspective of deep brain stimulation and temporal MEG/EEG measurement. Here, information on the stimulation settings is often relevant for later analyses. However, these can differ for the stimulation setting during the measurement and the clinical stimulation setting as well as for the individual electrodes. A three-layer system would therefore be suitable for data such as I use. Here is an example:
This can all be saved in one long string, but then it becomes unreadable.
I look forward to your feedback.
Greetings,
Matthais
The text was updated successfully, but these errors were encountered: