Skip to content
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

Add versioning notes to metadata #8431

Open
adam3smith opened this issue Feb 17, 2022 · 6 comments · May be fixed by #11068
Open

Add versioning notes to metadata #8431

adam3smith opened this issue Feb 17, 2022 · 6 comments · May be fixed by #11068
Labels
Component: JSF Involves modifying JSF (Jakarta Server Faces) code, which is being replaced with React. Feature: Metadata Type: Suggestion an idea User Role: Curator Curates and reviews datasets, manages permissions

Comments

@adam3smith
Copy link
Contributor

Moving this here from the community google group:

Overview of the Feature Request
While the version table includes a list/diff of changes, there is no way to specify the occasion/reason for a version change (new data? major error in the data? small typo? format update for preservation?, etc.). Including this as a metadata field would be very helpful. As per @jggautier, this exists in both DataCite and DDI metadata and actually used to exist in metadata:

DDI Codebook has an element called verStmt that the Dataverse software mapped to its versioning notes field. I looked around but couldn't find any discussion from back then about why that field was removed. Maybe Sonia or the folks from Odum might know why. (...)

The DataCite schema has a way to include a description of version changes, too, if the software were to add a field for that and wanted to include version notes in that export.

What kind of user is the feature intended for?

  • Depositors, Curators, and data users

What inspired the request?

  • We're increasingly updating data for a variety of reasons and it'd be helpful to make it clear why, since some updates do make meaningful changes, others just affect preservation or accessibility and it'd be good for users to be clear on this, e.g. when datasets serve as a version of record of sorts for preservation.
  • Odum via @donsizemore & @jonc1438 also said they're interested

What existing behavior do you want changed?
I see three implementation options -- we'd be happy with any of them, but others may have preferences:

  1. The field could just be a regular metadata field. Easiest implementation, but potentially a cause for bad data entry, especially on self deposits
  2. The field could be a regular metadata field but only show after v1 is published
  3. The field could be an active prompt on version changes

The main difference between 2 and 3 would likely be that 3 would make it more likely that self deposits with version updates include these changes.

Any brand new behavior do you want to add to Dataverse?
No

Any related open or closed issues to this feature request?
There are several open issues related to versioning (#4499 is probably most relevant ), but none directly addressing this that I could find.

@donsizemore
Copy link
Contributor

In Dataverse 3.n this was the datasetversion.versionnote field; after our migration from 3.6 to 4.n the only populated datasetversion.versionnote fields concern deaccessioned datasets.

@akio-sone
Copy link
Contributor

As of version 5.9, the setVersionNote() method of DatasetVersion class is used only for deaccessioning a Dataset (DatasetPage#setDatasetVersionDeaccessionReasonAndURL()). The GUI input-combo design (pre-specified reason list + input free-text box ) for this deaccessioning can be recycled for the GUI pane for saving a new Dataset version.

@stevenmce
Copy link

+1 for ADA @mdmADA

@pdurbin
Copy link
Member

pdurbin commented Oct 1, 2022

The field could be an active prompt on version changes

This is how it was it DVN 3. There was a popup you could type into or leave it blank and click "save" to make the popup go away. Generally, people found this extra popup annoying so we removed it in Dataverse 4.

All this is to say, if we bring this back (and I can definitely see the value in it), let's please get the UI/UX right. 😄

@pdurbin pdurbin added Type: Suggestion an idea Feature: Metadata User Role: Curator Curates and reviews datasets, manages permissions Component: JSF Involves modifying JSF (Jakarta Server Faces) code, which is being replaced with React. labels Oct 13, 2022
@adam3smith
Copy link
Contributor Author

OK, so we're getting ready to implement this at QDR. Obviously what we end up with needn't end up in the core code, but we'd like to get this right and hopefully get our PR accepted so others can benefit.

So, here's our current thinking:

  1. Create a new field "Versioning notes"
  2. My current thinking is that we'll make this field always available, so that it can be used for datasets added to a Dataverse in a later version, but we're also open to just allowing it for version 1.1 onwards
  3. We won't require the field, nor will we prompt for it.
  4. Current thinking, but very open to changing my mind: We'll only add the field as a free text field: I'm not seeing any controlled vocabulary we could use.
  5. Mapping: again, happy to be convinced otherwise, but I'm thinking we'll map to
    • DDI verStmt. DDI is a bit messy here (help welcome), but my thinking is that we'd want <verStmt type="note"> See the DDI entry on the verStmtType attribute for this.
    • Datacite description with descriptionType TechnicalInfo (see Datacite version for this)

@pdurbin
Copy link
Member

pdurbin commented Mar 19, 2024

Sounds like better UX than the DVN 3.x version. I'm glad you don't plan to require the field. And you don't plan to prompt for it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Component: JSF Involves modifying JSF (Jakarta Server Faces) code, which is being replaced with React. Feature: Metadata Type: Suggestion an idea User Role: Curator Curates and reviews datasets, manages permissions
Projects
Status: QDR working on or planning
Status: 🔍 Interest
Development

Successfully merging a pull request may close this issue.

5 participants