search

dandi / dandi-cli

DANDI command line client to facilitate common operations
https://dandi.readthedocs.io/
Apache License 2.0
21 stars 25 forks source link

model: should we remove "access" and "repository" for now? #344

Open yarikoptic opened 3 years ago

yarikoptic commented 3 years ago

I think we would be better to start with smaller, more manageable metadata record for dandiset, without hard-coding things such as repository and access (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 on repository and even access). 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 https://github.com/dandi/dandi-api/issues/64 and https://github.com/dandi/dandi-api/issues/63

satra commented 3 years ago

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.

dchiquito commented 3 years ago

Right now GUI sets the metadata of newly created dandisets to {"name": ..., "description": ...}, because that's what was stable at the time it was implemented. It's fairly easy to adjust that default, if more fields are required. Is there any clarity on what exactly the metadata for a new dandiset should look like?

satra commented 3 years ago

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.

yarikoptic commented 3 years ago

what is a data template? a YAML/json with fields present but not specified?

satra commented 3 years ago

all the fields could be null for example.