Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Sign upBeyond the Repository (BtR) Spec Change Proposal V1.3.0 #21
Conversation
This comment has been minimized.
This comment has been minimized.
@tdilauro thanks for the PR! Can you send a note to digital curation list and ask folks for input/feedback? Let's say put a deadline of November 30, 2019 in the message, and we can go from there once we get input. |
This comment has been minimized.
This comment has been minimized.
jwestgard
commented
Nov 16, 2019
I would like to register my support for this PR. The manifests-allowed would offer some additional flexibility and and precision and has no downside that I can see. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
jscancella
commented
Nov 21, 2019
+1 |
This comment has been minimized.
This comment has been minimized.
@tdilauro pinging again on the comment above. Once we sort that out, I'm happy to get this merged. |
This comment has been minimized.
This comment has been minimized.
@ruebot Took a look at the validator today. It seems a little loose, but I can certainly add functionality to validate the Manifests-Allowed and Tag-Manifests-Allowed behaviors. |
This comment has been minimized.
This comment has been minimized.
@tdilauro great! thanks! |
This comment has been minimized.
This comment has been minimized.
@tdilauro caught the validator PR this morning. thanks! Still looking for an update to one or both of the example profiles as well. Which may affect the tests on the validator. Can we get this sorted out? |
This comment has been minimized.
This comment has been minimized.
@ruebot I am waiting on a response from one of my BtR colleagues to review and merge my changes. Also, I would advise against updating one of the existing profiles to a new Bagit-Profile-Version, as it would break tests in other branches of the validator, since they all refer to a profile in the master branch. Ideally, the example profiles used by the validator would live in the validator repo, so that they could stay in sync with the branch they're on. Thoughts? |
This comment has been minimized.
This comment has been minimized.
Yeah, that's a good point. |
tdilauro commentedNov 14, 2019
The BagIt Team of the Beyond the Repository project is recommending changes to the BagIt Profiles specification.
This PR updates the BagIt Profiles specification to:
description
property for free-form textual description related toBag-Info
tags.Manifests-Allowed
andTag-Manifests-Allowed
properties, respectively.These changes are non-breaking for v1.2.0, thus packages built to that specification would not require changes (aside from
BagIt-Profile-Identifier
tag inbag-info.txt
).description
property of theBag-Info
object is optional.Manifests-Allowed
andTag-Manifests-Allowed
lists are optional and reasonable behaviors are defined for the default values.Description Property
The
description
property enables the conveyance of any information that might be helpful to either the producer or the consumer of a bag to understand how to provide or interpret the information associated with a particular tag. There is no restriction on the length ofdescription
, so it may be less than ideal to use as a tooltip for its associated tag.Manifests-Allowed and Tag-Manifests-Allowed Properties
With
Manifests-Required
andTag-Manifests-Required
, the current BagIt Profiles specification (v1.2.0) supports the enumeration of any algorithms for which a corresponding payload or tag manifest, respectively, MUST be present in a bag. If these lists are specified, though, all listed algorithms must be represented.We needed an additional mechanism through which to designate the set of algorithms supported (rather than required) by the consumer of a bag, so that producers are able create bags appropriately.
Manifests-Allowed
andTag-Manifests-Allowed
fulfill this need. If unspecified, these properties impose no constraints on the algorithms available to a producer. IfManifests-Required
is specified, then ifManifests-Allowed
is specified, it must include at least those algorithms listed inManifests-Required
. The same relationship applies forTag-Manifests-Required
/Tag-Manifests-Allowed
.