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

Dataset Metadata - display productionDate, not publicationDate #3369

Closed
donsizemore opened this issue Sep 21, 2016 · 6 comments
Closed

Dataset Metadata - display productionDate, not publicationDate #3369

donsizemore opened this issue Sep 21, 2016 · 6 comments
Assignees

Comments

@donsizemore
Copy link
Contributor

donsizemore commented Sep 21, 2016

Phil suggested Akio add a global setting to the DatasetVersion getCitationDate method to allow this.

Odum can use the native API to fix existing datasets, but newly-created datasets will revert to publicationDate. We'd much prefer productionDate, particularly for older data.

@pdurbin
Copy link
Member

pdurbin commented Sep 21, 2016

Here's an approach I suggested to @akio-sone via email:

Maybe you could add a setting for which field to use, globally (per installation of Dataverse):

https://github.com/IQSS/dataverse/blob/v4.5/src/main/java/edu/harvard/iq/dataverse/DatasetVersion.java#L750

Settings go in the "Key" enum in SettingsServiceBean:

https://github.com/IQSS/dataverse/blob/v4.5/src/main/java/edu/harvard/iq/dataverse/settings/SettingsServiceBean.java#L35

The Key enum is referenced from SystemConfig:

https://github.com/IQSS/dataverse/blob/v4.5/src/main/java/edu/harvard/iq/dataverse/util/SystemConfig.java

@pdurbin
Copy link
Member

pdurbin commented Sep 21, 2016

This issue related to Add Backend Support for Changing Citation Date #2606 and pull request #3000.

@mheppler mheppler changed the title display productionDate, not publicationDate Dataset Metadata - display productionDate, not publicationDate Oct 10, 2016
@pdurbin pdurbin added the User Role: Curator Curates and reviews datasets, manages permissions label Jul 4, 2017
@jggautier
Copy link
Contributor

Hi @donsizemore, you wrote that for the date displayed in the dataset citation, "[w]e'd much prefer productionDate, particularly for older data". Could you share how that date is used on UNC Dataverse?

@donsizemore
Copy link
Contributor Author

@jggautier Hi from the future! (this is my oldest open issue)

We have a fair amount of historic content (e.g. census data) which may have been digitized and published in 2007 but generated/produced in 1937. Looking at our homepage facets, the mode for publication year is 2007, which must have been a bad year to be a flatbed scanner.

@jggautier
Copy link
Contributor

Thanks, Don!

Is it fair to say that the UNC Dataverse managers believe that it's more important to highlight how old the data is, and not as important to highlight when it was first published in the Dataverse repository? And that the 2007 date has or might give data searchers the wrong impression about the age of the data?

I wonder if this is the case with most types of data or if the thinking is different in different research disciplines or cultures? There might be a lot to learn from any studies done for book and article citations.

In any case, maybe what might work is what Phil suggested when this ticket was open: "add a global setting to the DatasetVersion getCitationDate method to allow this." To me this means the creation of an installation-level setting that forces the year shown in every suggested dataset citation to be the year entered in a specified date metadata field. And if there is no date in that field, the citation uses the year of the system created publicationDate (the year when the dataset was first published in that Dataverse repository).

So for example UNC Dataverse can say that for the suggested citation of every dataset published anywhere in the repository (or in a particular Dataverse collection in the repository), use the year in the productionDate field if it exists, otherwise use publicationDate.

Does that sound right?

@cmbz
Copy link

cmbz commented Aug 20, 2024

To focus on the most important features and bugs, we are closing issues created before 2020 (version 5.0) that are not new feature requests with the label 'Type: Feature'.

If you created this issue and you feel the team should revisit this decision, please reopen the issue and leave a comment.

@cmbz cmbz closed this as completed Aug 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants