-
Notifications
You must be signed in to change notification settings - Fork 0
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 metadata field to create_nwb_file #1
base: readwrite-nwb
Are you sure you want to change the base?
add metadata field to create_nwb_file #1
Conversation
@chrisroat , what do you think of this addition? |
In general I'm a bit wary of such a wide interface. I would hold off though, as it may become moot depending on the output of discussion about this branch. The branch hasn't gotten any feedback on if this is even the right approach. Also, it might be that we drop create_nwb_file altogether -- maybe there is no need to output NWB if the input is not NWB. (maybe it's better to be static-y and force the upstream to convert to NWB). That is my leaning, so we can drop this metadata faking -- which avoids the code smell of such a wide interface. |
Outputting NWB files with fake, incorrect metadata is a bigger problem to me than whether you can save the raw and processed data to the same file. It is common for users to want to separate raw and processed data, due to the raw data being so large, so I doubt you will get traction with forcing users to combine them. |
Incorrect metadata is easy to solve -- just drop the create_nwb_file function. :) This also avoids the wide metadata interface. I think it is fair to only allow support NWB if the input is NWB, but I realize that can be a separate debate. But getting back to the crux of the branch -- I also would prefer to save the data to separate files. But NWB felt like it was pushing me in same-file direction, as it seems to require the copying of all the metadata over when I create the new file (my previous interaction with Subject ID left a bad taste in my mouth). I'm intrigued by the external file references, and if we can use them here to avoid duplicate subject/device/plane/channel objects in the two files. |
Yes, you could get around some of this data duplication with external references, especially if you want to build an internal processing pipeline. You can learn about how to use them here. However, be warned that this feature is not yet compatible/tested with DANDI. |
OK. I think I would take the shallow-copy approach here -- does that sound right? Is integration with DANDI likely to come soon? If it's only a short-term issue, we might just proceed with the shallow-copy, and then just materialize the file if we need to upload to DANDI. |
Add options for specifying metadata as a dictionary