Feature Request/Idea: Harmonization and simplification of the citation metadata block.

[johannes-darms]

Overview of the Feature Request
Harmonization and simplification of the citation metadata block.

What kind of user is the feature intended for?
(Example users roles: API User, Curator, Depositor, Guest, Superuser, Sysadmin)
API User, Curator, Depositor, Guest, Superuser, Sysadmin

What inspired the request?
The current citation metadata captures information about people or entities that are involved with a resource in different ways. The Author, datasetContact, contributor, distributor, depositor, and producer entities have slightly different properties but describe either a human or a legal entity with different granularity. While author and datasetContact can capture information about affiliation with a particular person, contributors cannot. This complicates data collection and data management.

What existing behavior do you want changed?

1. Extending the controlledVocabulary contributorType with the following properties: author, datasetContact, distributor, producer and depositor.
2. Extension of the none DataSetField contributor to include the union of the harmonized properties of author, datasetContact, distributor , producer, depositor.
3. Removal of the none DataSetFields author, datasetContact, distributor , producer, depositor with all sub-properties.

With this proposed change, all existing data can be migrated - without data loss - to the new representation. Alignment with existing standards will not be affected as the same information will be captured and stored. In addition, the adjustments to exports and visualizations are minimal, as only code to filter by a specific "contributorType" needs to be added. The main advantage is the harmonization of six objects into one, reducing the complexity of the data model and eliminating inconsistencies.

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

Any related open or closed issues to this feature request?

[poikilotherm]

Hi @johannes-darms maybe you can drop by in Matrix chat or even better one of the community calls (today!) to explain your idea in more detail?

Most likely your ideas need more context and talking about them with people like our metadata pro @jggautier, our great CCO @pdurbin, the multi-hat-dev @qqmyers, our architect @scolapasta and many many others.

[pdurbin]

Good idea. People are people.

This issue is directly related:

• Citation Metadata: Add Affiliation and Identifier for Contributors #3048

These are somewhat more tangentially related:

• Feature Request/Idea: Incorporate CRediT vocabulary for author/contributor roles #8213
• Unresolved feedback from community review of Citation metadata fields #8467

[johannes-darms]

To sum up the idea:
Move from this:

to this representation:

[pdurbin]

Related:

• Feature Request/Idea: Allow an account to have multiple Affiliations. #9248
• Add ORCID to uploader/contributor of dataset #10087

[cmbz]

2025-04-21

• Was discussed with UX Working Group
• @jggautier will add context about discussion

[jggautier]

Last year the UX working group considered this idea as it worked through stages of a design sprint for redesigning Dataverse's metadata fields in order to improve how Dataverse collects information about people and organizations associated with data and code.

This idea is also related to what @stevenmce brought up in #4859 when we were talking about how Dataverse's fields give people two ways to indicate who funded their deposit. Steve favored considering funders as a kind of contributor.

In one of my first design proposals I used a compound field to let a user indicate how any person or organization was associated with the data or code. And other child fields would be available depending on how the person or organization was associated.

Eventually we abandoned the idea because we didn't have the resources to continue addressing some of the challenges, including:

• As the number of child fields increases, depositors might have a hard time filling these fields and everyone might have a hard time making sense of the metadata when it's displayed on pages
• We weren't sure if not having a separate field for certain types of contributors, like authors, would make sense for most folks in the Dataverse community. For example, there was some concern over a metadata model that treated "authors" as a kind of "contributor".

More info:

Here's one set of early mockups:

Mockups like this one helped us talk about challenges with this idea and how the Dataverse community might resolve them.

One of the challenges, about the number of child fields, affects the "Related Publication" fields, fields in a metadata block informed by the Darwin Core metadata standard (#6243), and other metadata blocks (like IQSS/dataverse.harvard.edu#232).

We iterated on a few ideas using designs and interactions we've seen in other applications. Here's another set of mockups:

Eventually the UX working group abandoned this idea of somehow combining all of the people and organization fields into a single compound field and we considered #4859 as out of scope for the group's design sprint. The other challenge, about not having a "separate field" for certain types of contributors, would require more discovery research and outreach with more of the community, which we didn't have the time for, and the design sprint had already become more of a marathon.

We did continue iterating on designs with the use of chips and popups to address issues with organizing many fields and displaying metadata made up of many fields. But because of resource constraints we also abandoned those ideas and agreed to move forward with changes to the Author and Funding Information fields specifically (IQSS/dataverse.harvard.edu#326).

[vera]

Are there any plans/is there a future possiblity of allowing the entry of identifiers such as ORCID for persons/organisations other than the ones listed as authors, e.g. for those listed as contributors?

[qqmyers]

~yes. There's already a config for using ORCIDs in the depositor field and I'm actively looking at other possible fields for ORCIDs/RORS (supported by Dataverse NO). If you're also thinking of working on these, or would like to test early versions, etc. let me know.

[vera]

Yes!

For context, we are currently migrating a repository to Dataverse. The current repository metadata includes ORCIDs for different kinds of contributors, not just authors. So they asked us whether it would be possible to store that in Dataverse. I thought of e.g. adding contributorIdentifierScheme and contributorIdentifier to the contributor compound field, mirroring the author field. Is this in line with what you're looking at, or are you planning to do it differently?

[pdurbin]

@vera I'm not aware of any concrete plans. Please do experiment and keep us posted. I'm curious if a SQL migration script will be necessary since these would be new fields. 🤔