IQSS / IQSS/dataverse

Feature Request/Idea: Export metadatablock definition per Dataverse collection

Open
#9,477 2 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

Feature: API SPA Type: Feature User Role: API User
Dominant language
Java
Stars
1.1k
Forks
564
Avg merge
2d 2h
Merged PRs (30d)
29

Description

Overview of the Feature Request

Currently the Native API supports the export of an overview of metadatablocks and a detailed view using .../metadatablocks and .../metadatablocks/$blockID respectively. Same applies to Dataverse collections, but these are missing the detailed view. Hence, it would be a valuable addition to the Native API to allow the export of a metadatablock on this level, since it helps capturing custom settings.

What kind of user is the feature intended for?

API Users

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

  • Extend Native API with a new endpoint .../$collectionName/metadatablocks/$blockID

Use case

The addition of this endpoint could allow EasyDataverse to connect to a specific Dataverse collection and build objects according to the custom settings given. For instance, if a user decides that an optional field of a metadata block should be required, this could be reflected onto the generated Python objects.

This would lead to an extension of the given connect method, that, when provided with a URL to a collection, fetches the specific metadata block definition:

from easyDataverse import Dataset

dataset = Dataset.connect("https://demo.dataverse.org/my_dataverse")

# ... add metadata

# Uploads to the collection 
dataset.upload() 

Assuming a custom required field (e.g. grant number) is not given, upon trying to upload the dataset, a validation will be done, which results in a report on which fields are missing or wrong. For this PyDantic`s validation capabilities would be used that result in such a message:

ValidationError: 1 validation error for Citation
grant_number
  field required (type=value_error.missing)

Currently EasyDataverse needs to assume that every field is optional since the information is not given natively. Hence, this would be a valuable addition.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the existing Native API endpoints for the global and collection-level metadatablocks views, then trace how the detailed $blockID view is exposed. Done means adding and documenting the collection-scoped endpoint .../$collectionName/metadatablocks/$blockID so it returns the collection's customized metadatablock definition, with coverage for API users.

Written by the indexing model from the issue text.

Assessment

Tech stack
java
Domain
api
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.