You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think the idea, at least as the DB models are currently written, is that nimads_data is just a static JSON file containing a NIMADS Dataset object. That's basically just a list of Study objects, yes. So in your example above, there wouldn't be an analysis field at the top level (analyses would be nested within studies). Re: your other questions:
should the data under nimads_data be in JSON-LD form?
Let's go with just JSON for now. We can't guarantee that every piece of data will have a unique address, and given all the other downsides of JSON-LD we've talked about, it seems reasonable to just drop that entirely.
If we are not using JSON-LD yet, would looking at a study with api/studies/?nested=true be a good approximation for now?
Yep. And then a dataset would just be a list of studies, plus the other fields (description, doi, etc.).
Are the doi, pmid and other identifying keys are assuming the dataset exists in some published form?
The implication is that there's a digital object published somewhere that contains a description of the dataset. I think of this as "this dataset is associated with this DOI", and not "this dataset is published at this DOI". It's roughly the same relationship as between NeuroVault collections and associated DOIs.
would it be appropriate to interpret a dataset as a subset of the entries in /api/studies?
Not quite, because in principle, a user could push a dataset to Neurostore that hadn't been constructed using our tools, and possibly contains data that comes from other sources. This is why data in the dataset are stored as flat JSON, and not in a relational form. It's probably true that most of the time, the listed studies will be a subset of what's available from /api/studies, but we can't make that assumption. [EDIT: oh, and also, datasets will often be filtered; i.e., even when the studies are a subset of the API, they will typically contain only some of the data for each study (e.g., only images and not coordinates).]
I think the idea, at least as the DB models are currently written, is that
nimads_data
is just a static JSON file containing a NIMADS Dataset object. That's basically just a list ofStudy
objects, yes. So in your example above, there wouldn't be ananalysis
field at the top level (analyses would be nested within studies). Re: your other questions:Let's go with just JSON for now. We can't guarantee that every piece of data will have a unique address, and given all the other downsides of JSON-LD we've talked about, it seems reasonable to just drop that entirely.
Yep. And then a dataset would just be a list of studies, plus the other fields (description, doi, etc.).
The implication is that there's a digital object published somewhere that contains a description of the dataset. I think of this as "this dataset is associated with this DOI", and not "this dataset is published at this DOI". It's roughly the same relationship as between NeuroVault collections and associated DOIs.
Not quite, because in principle, a user could push a dataset to Neurostore that hadn't been constructed using our tools, and possibly contains data that comes from other sources. This is why data in the dataset are stored as flat JSON, and not in a relational form. It's probably true that most of the time, the listed studies will be a subset of what's available from /api/studies, but we can't make that assumption. [EDIT: oh, and also, datasets will often be filtered; i.e., even when the studies are a subset of the API, they will typically contain only some of the data for each study (e.g., only images and not coordinates).]
Originally posted by @tyarkoni in #28 (comment)
The text was updated successfully, but these errors were encountered: