dandi / dandi/dandi-cli

schema: version and its annotation

Open
#568 0 comments 0 reactions 0 assignees View on GitHub
schema
Dominant language
Python
Stars
28
Forks
37
Avg merge
1d 17h
Merged PRs (30d)
9

Description

@satra caught me in the middle of writing this, so I will just submit what I had, but intermediate agreement was `wasGeneratedBy` will be the remedy (details yet to be worked out ;))

ATM we have
```python
class DandisetMeta(CommonModel, Identifiable):
...
version: TempOptional[str] = Field(readOnly=True, nskey="schema")
```
dandi-api returns also created/modified time stamps (not part of the metadata but just come from DB), and I already requested addition of "description" to `publish` call: https://github.com/dandi/dandi-api/issues/189 . Also the notion of a `Version` is present within perspective Python client/API redesign: https://github.com/dandi/dandi-cli/pull/447/files#diff-ca726fb8fbfbf61284ae89742c7c5621e5d4305fc9fd8a83047f71eb07a28379R89 which ATM mimics it more from dandi-api returned structure.

I feel that if we are to have `version` within metadata, we should also encapsulate other related to that publishing process metadata (date of publishing, and optionally description). I wonder where should it "fit" in the metadata record for a published dandiset? I guess it could be added to `wasGeneratedBy`.

But ATM we override it to be of type `Optional[List[Project]]` from the original (in `CommonModel`) "wider" `Optional[List[Activity]]`. Should we then make it `Optional[List[Union[Project,Activity]]` (although Project is subclass of Activity, I guess it would be useful to direct web UI?)

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.