Somewhat related to #5989

Related:

• Metadata: Support radio buttons for Yes / No responses #2727
• Re-evaluate metadata blocks, metadata display, help, and metadata sources #6030
• Unresolved feedback from community review of Citation metadata fields #8467

Hi @pdurbin
Do you have any news on implementing this feature?
It is something we want to use in a custom metadata block for our forthcoming Dataverse, so users can tick the box/field, if they regard the dataset relevant for submission to National Archives repository.

@Asbjoedt no news. Let me mention @scolapasta and @cmbz to let them know you (and others) are interested.

Is this something you (or others) might want to create pull request for? That often helps move things along. 😄

I agree it would be a nice feature.

@Asbjoedt also, in the past I've encouraged installations to maintain a project/board of issues they care about. A great current example is https://github.com/orgs/IQSS/projects/15 maintained mostly by @DS-INRA.

If you'd like a board like this, please open an issue at https://github.com/IQSS/dataverse-installations using the "request a project board" template.

@jggautier Any connection here with the NIH GREI metadata recommendations?

Hmm, yeah having the option to use a checkbox might help depositors provide information that those recommendations ask for.

@pdurbin I can try to look at the source code. I know some Java and strictly speaking this is about implementing the Java boolean data type as a Dataverse data type for metadata blocks, if you agree on this approach?

I've found the file "DatasetFieldType", may you provide me with a list of names of other files that are necessary to change to implement the boolean?

I can't promise, I can create a PR for this, but I may take a look.
I have forked the repo and created a branch, is this sufficient for you to receive a PR?

@Asbjoedt great! For details on what files to edit (I'd need to look) maybe you can start a thread in #dev at https://chat.dataverse.org and we can figure it out together.

@Asbjoedt Please comment here if you decide to make a PR. After discussion with @jggautier this issue appears to be aligned with our NIH GREI objectives.

Here's the conversation so far: https://dataverse.zulipchat.com/#narrow/stream/379673-dev/topic/The.20boolean/near/405225599

To summarize, I agree with @poikilotherm that his commit at https://jugit.fz-juelich.de/fdm/dev/dataverse/-/commit/d4aece03aebcf9c2237aa7842c17c0d96af6a79a is a good one to study.

Hi there, I just checked every conversation and commits related to this issues and I strongly believe that this field type is not useful as we already have a way to do it by using text fieldtype and controlledVocabularies (i.e. controlled values). A good example is #10626 with archiveSubmitToArchivalAppraisal allowing values Yes, No and Unknown.

The Needs :

• Being able to support "true" / "false" and a possible third value null, "unknown" or unfilled value.
• Being able to make it not nullable which is possible using required property
• Being able to internationalize "true" / "false" or third value depending on the input title
• Being able to export the "boolean"
• Having a dropdown as it seems to be the favorite GUI component.

All of this is possible using controlled vocabulary of metadata customisation. I would just advice to use values of "True" and "False" for the sake of json export quality and the harvesting using dataverse_json format.

Note that null and unknown is not the same, as one mean unfilled value and one mean "I don't know".

Another good point is to avoid cost a creation and the maintenance of a new boolean data field type related code (JSF, JAVA, SOLR, DOC). Also, no one seems really sure on if we should allow nullable or a third value, personally, I think flexibility is the best way to go, so text fieldtype + controlled values is a great option.

I created a new PR #11064 for documentation
I created a PR Asbjoedt#1 to update #10626 with the adviced values and added archival.properties.

Hey! I do not think I have a problem with leaving the boolean data type behind and instead keep using controlled vocabularies as a way to tweak Dataverse to have a boolean. I am partial to this solution because the other approach has stalled and getting archival.tsv into the codebase was our initial intention.

Thanks @luddaniel for keeping this moving and to @Asbjoedt for the flexibility.

Since @luddaniel's PR is "docs only", I went ahead and put it "in review". This one:

• Update Metadata Customization page to suggest how to implement booleans #11064

We're in the middle of trying to get 6.5 out the door but we'll get to it soon. I'll probably request a review from @jggautier as well.

I believe we can handle the PRs about adding archival.tsv separately from the one above about booleans. These:

• added archival.tsv metadata block #10626
• Changed yes/no to true/false and added archival.properties Asbjoedt/dataverse#1

That is, we can merge the docs about booleans and THEN think more about archival.tsv PR (with the updated values of "yes" and "no" @luddaniel is proposing).

Thanks again.