IQSS
Implement datasetType metadata block support (at global level)
Overview
- See https://github.com/IQSS/dataverse-pm/issues/307 and Proposal: Supporting Multiple Dataset Types in Dataverse for details
Proposed release not snippet (scope of work)
(See also notes where this snippet was iterated on.)
Metadata Blocks Can Be Associated with Dataset Types
Metadata blocks (e.g. "codemeta") can now be associated with dataset types (e.g. "software") using new superuser APIs.
This will have the following effects for the APIs used by the new Dataverse UI:
- The list of fields shown when creating a dataset will include fields marked as "displayoncreate" (in the tsv/database) for metadata blocks (e.g. "codemeta") that are associated with the dataset type (e.g. "software") that is passed to the API.
- The metadata blocks shown when editing a dataset will include metadata blocks (e.g. "codemeta") that are associated with the dataset type (e.g. "software") that is passed to the API.
For more information, see the guides and #10519.
Depends on
- https://github.com/IQSS/dataverse/pull/10694
- ~~https://github.com/IQSS/dataverse/issues/10518~~
See also
- https://github.com/IQSS/dataverse-pm/issues/307
As discussed at tech hours yesterday, I pulled this into FY25 Sprint 5 two weeks ago without realizing how poorly defined this issue is and without grasping that the proposal, as written, implies a lot of work on the JSF code, which we intend to dispose of. 🗑️
I liked the suggestion from @qqmyers that a possible direction would be to create a series of superuser-only APIs that allows an installation to be configured to associate a dataset type with metadata fields. However, what should the JSON look like that will ultimately be used by the SPA? Should we hide this output behind the "admin" API for now and check in with the frontend team (when they are ready) to see if the JSON is agreeable? In short, there would be no value to the end user yet, but we could make progress on database tables and business logic.
@scolapasta suggested that a smaller group (than all of tech hours) could discuss this issue further and unblock it. Meanwhile, perhaps the size should be removed and it should go back into "need sizing" for this discussion to happen (heads up to @cmbz).
2024/09/25:
- Possible option for SPA Q4 work. @GPortas will add as task to SPA Q4 proposal for evaluation.
- @qqmyers @scolapasta @pdurbin and @cmbz will meet (coord via Slack) to follow up
Notes from our discussion (thanks, all).
In the issue description I'll copy the important bits and might try to future clarify things.
Updated: Sep 30, 2024 datasetType Discussion 2024/09/30
Attendees: Ceilyn Boyd Gustavo Durand Philip Durbin Jim Myers
Notes
- https://github.com/IQSS/dataverse/issues/10519
- The API-only option for configuration will meet GREI needs for Year 3, along with the Java/back-end changes to show the configured blocks when creating/editing a dataset. We will address the UI in Year 4 when the SPA beta is completed.
- The current UI / SPA should already be leveraging this code in the way they get the metadata blocks, or should only require small tweaks.
- A similar plan should work for configuring licenses for dataset types. Implement list of allowed datasetType licenses (at global level) · Issue #10520 · IQSS/dataverse (github.com)
- Templates are out of scope and not expected to change
- Tasks
- Create a series of superuser-only APIs that allows an installation to be configured to associate a dataset type with metadata blocks (fields in the future) at the global/installation level
- Modify underlying code to get fields that's used by JSF and API
- Modify the API the SPA uses to get the fields, allow type=software to be passed
- Change displayOnCreate to true for CodeMeta fields
- Test case 1
- don't enable CodeMeta for a collection
- create dataset with type=software and ensure that CodeMeta fields show up
- Ask SPA team to add a query parameter for type=software?
Action items *
2025-01-22: Closing as complete: https://github.com/IQSS/dataverse/issues/10519.