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

Why limit to neuroscience ? #6

Open
jcolomb opened this issue Sep 11, 2020 · 2 comments
Open

Why limit to neuroscience ? #6

jcolomb opened this issue Sep 11, 2020 · 2 comments

Comments

@jcolomb
Copy link

jcolomb commented Sep 11, 2020

Is there any reason to restrict the scope of this project to "neuroscience" ? Couldn't we think about life science in general?

Especially when one consider that neuroscientists sometimes also do metabolics studies, immunology studies, molecular analysis, single cell proteomics,... They may want to keep the same data structure for all their experiments ?

@jcolomb jcolomb changed the title why Limit to neuroscience ? Why limit to neuroscience ? Sep 11, 2020
@SylvainTakerkart
Copy link
Collaborator

SylvainTakerkart commented Sep 28, 2020

indeed, this is a question we should ask ourselves, and in general: "what is the scope and aim of this data structure?"

our reasoning has been that there is already a large-enough diversity in neuroscience so that our endeavor might be difficult... my personal feeling is that maybe we might have to restrict ourselves to a subpart of neuroscience at first, while thinking about keeping things as flexible as possible so that extensions to other subparts of neuroscience (or other fields in life science) remain easy... anyhow let's see how the other issues progress (the three main ones listed below) and we will clearly reconsider this question later on...

#2
#3
#4

@yarikoptic
Copy link
Member

the overall approach should indeed have minimal set of "assumptions" (e.g. "having a participant level directory") and thus possibly generalize across fields of endeavor. Standardization of fields naming cannot avoid to be domain specific but ideally should indeed have terms possibly used in other fields in mind to avoid possible future ambiguity etc. (e.g. vague terms like "imaging" should be avoided etc). Values should follow some standard formats (e.g. ISO 8601 for date time) allowing for arbitrary precision which might be needed in specific cases (e.g. subsecond in time), and see https://bids-specification.readthedocs.io/en/stable/99-appendices/05-units.html#unit-table for units standards used in BIDS.

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

No branches or pull requests

3 participants