-
Notifications
You must be signed in to change notification settings - Fork 25
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
model: should we remove "access" and "repository" for now? #344
Comments
i believe the api server should populate metadata with the appropriate schema defaults on dandiset creation. (@dchiquit - how do we want to do this in the short term where we are developing cli and api, and we would want changes in cli to be reflected in api (creation/validation/etc.,.)) those defaults make sense to me. but those can definitely be adjusted or removed. but the only reason the current access default exists is because we don't have the others implemented. however, i would be open to removing access from dandiset meta, as long as we have it in every asset. i'm not sure i like properties at the dandiset level that are aggregates of properties really of assets. the alternative would be to not allow a list and make it fixed, but then a future virtual dandiset could never mix open + embargoed data for example. |
Right now GUI sets the metadata of newly created dandisets to |
in addition to creating the schema, we should create a data template also in the schema repo. this would help the api use this without having to pull in the latest cli changes. although validation would probably require the cli. |
what is a |
all the fields could be null for example. |
I think we would be better to start with smaller, more manageable metadata record for dandiset, without hard-coding things such as
repository
andaccess
(seems to be also a tricky one: #343 ). It would always be easier to extend, or to provide custom mapping (e.g. based on identifier being DANDI we could make claims onrepository
and evenaccess
). WDYT @satra?edit 1: I somewhat also dislike them since they are "the defaults" for any
DandiMeta
(which might not even yet was considered to be uploaded to the archive's metadata record).edit 2: Actually - may be they are ok IF dandi-api server would populate them since it is not client's job since we do not upload dandiset metadata (although #341 is coming to facilitate migration). But first let's figure out #343 and then file an issue or PR for dandi-api to complement dandi/dandi-archive#64 and dandi/dandi-archive#63
The text was updated successfully, but these errors were encountered: