-
Notifications
You must be signed in to change notification settings - Fork 8
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
Version control of datasets #44
Comments
@erikriverson is working on some sort of version control, where we specify which version is read in in the datasets.yaml, but having a publication version indexed might also make sense. I would suggest to have a separate field in the same yaml file. Would that work? |
Field in the yaml file that indicates the date of the publication version?
I like that. The advantage over the column approach is that this will also
reflect changes within a row (e.g., correction of one cell)
Am Mi., 18. Nov. 2020 um 18:08 Uhr schrieb Christina Bergmann <
[email protected]>:
… @erikriverson <https://github.com/erikriverson> is working on some sort
of version control, where we specify which version is read in in the
datasets.yaml, but having a publication version indexed might also make
sense. I would suggest to have a separate field in the same yaml file.
Would that work?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#44 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AD4RHG6POAVZXUOCFPJIOLLSQOFIBANCNFSM4TZKUZ6A>
.
--
Assistant Professor
The University of Tokyo International Research Center for Neurointelligence
(IRCN)
Personal website: https://sites.google.com/site/tsujish/home
Lab website: https://babylab.ircn.jp/
Blog: https://cogtales.wordpress.com/
|
Yes, we are working with versions that are automatically generated by google sheets, which indeed also accommodates changes in cells that are part of the published version. (Which does happen). |
I don't have strong feelings re: yaml vs. column in the data, so long as
it's trivial from the user point of view to explore the publication version
of the dataset (i.e. check a box).
…On Wed, Nov 18, 2020 at 3:17 AM Christina Bergmann ***@***.***> wrote:
Yes, we are working with versions that are automatically generated by
google sheets, which indeed also accommodates changes in cells that are
part of the published version. (Which does happen).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#44 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABO7NCPWDUK7B7FMO3JZNZTSQOGJ3ANCNFSM4TZKUZ6A>
.
|
Discussion from meeting: can we quietly put the SHA for the specific data version somewhere in the viz app (and also in the metalabr data retrieval) also see: langcog/metalabr#8 |
Suggestion from @mllewis:
It'd be great if we had a way on Metalab to do version control a little more systematically. I'm imagining adding an optional column to the data where you could indicate which rows were associated with a publication version of the data, and then on the visualization app, you could optionally subset to only the published rows. That would allow (a) for researchers to continually update meta-analyses, and (b) for Metalab to function as an interactive SI for publications, even after the data have been updated
The text was updated successfully, but these errors were encountered: