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

added archival.tsv metadata block #10626

Open
wants to merge 6 commits into
base: develop
Choose a base branch
from
Open
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
19 changes: 19 additions & 0 deletions scripts/api/data/metadatablocks/archival.tsv
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll just leave this comment on the first file but we should add docs and a release note to this PR.

For docs, the new archival block should be listed under a future version of https://guides.dataverse.org/en/6.2/user/appendix.html#experimental-metadata

The release note can just say "A new, experimental archival metadata block has been added." The procedure is here: https://guides.dataverse.org/en/6.2/developers/version-control.html#writing-a-release-note-snippet

Original file line number Diff line number Diff line change
@@ -0,0 +1,19 @@
#metadataBlock name dataverseAlias displayName blockURI
archive Archival Metadata
#datasetField name title description watermark fieldType displayOrder displayFormat advancedSearchField allowControlledVocabulary allowmultiples facetable displayoncreate required parent metadatablock_id termURI
archiveSubmitToArchivalAppraisal Archival Appraisal An assessment whether the dataset should be submitted for archival appraisal text 0 #VALUE TRUE FALSE FALSE FALSE TRUE FALSE archive
archiveArchivedFrom Archived from A date (YYYY-MM-DD) from which the dataset is archived YYYY-MM-DD date 2 #VALUE TRUE FALSE FALSE FALSE FALSE FALSE archive
archiveArchivedFor Retention period The retention period for which the archived dataset is to be kept by the holding archive text 3 #VALUE TRUE TRUE FALSE FALSE FALSE FALSE archive
archiveHoldingArchive Archived at Holding Archive The holding archive where the dataset is archived text 4 #VALUE FALSE FALSE TRUE FALSE FALSE FALSE archive https://schema.org/holdingArchive
archiveArchivedAt Archived at URL URL to holding archive where the dataset is archived URL url 5 <a href='#VALUE'>#VALUE</a> FALSE FALSE TRUE FALSE FALSE FALSE archive https://schema.org/archivedAt
#controlledVocabulary DatasetField Value identifier displayOrder
archiveArchivedFor 1 year 1_year 0
archiveArchivedFor 3 years 3_years 1
archiveArchivedFor 5 years 5_years 2
archiveArchivedFor 10 years 10_years 3
archiveArchivedFor 20 years 20_years 4
archiveArchivedFor Indefinitely indefinitely 5
archiveArchivedFor Unknown unknown 6
archiveSubmitToArchivalAppraisal Yes yes 0
archiveSubmitToArchivalAppraisal No no 1
archiveSubmitToArchivalAppraisal Unknown unknown 2
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this the boolean? Yes, no, or unknown? As discussed here (and in person in Mexico):

Copy link
Author

@Asbjoedt Asbjoedt Jun 12, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This PR only implements a controlled vocabulary list, because the boolean is not yet in the source code. The PR, #10480 , has grown stale, I think, but if possible when 10480 is further refined and merged, then the PR for this archival.tsv metadata block should adopt the boolean for this field specifically, because yes, as we discussed in Mexico, those fields you mention are exactly the use case why we need the boolean to properly handle the data type in Dataverse. My thought at the moment is to merge the archival.tsv and then when 10480 is merged send in a new PR to adopt it for archival.tsv.

what do you think?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, what you've done is similar (I think) to other quasi booleans we've defined in other metadata blocks, given the tools we have.

As of that boolean PR, I did at least leave a comment just now: #10480 (comment)

And yeah, especially if archival.tsv is marked as experimental in the guides, I imagine we could update it to take advantage of new functionality (like booleans) as they come along.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cool! Thanks for your comments.

The mapping of the boolean from frontend to backend could work like this:

Yes = true
No = false
Unknown = null