Requirements

These notes are from the September 17/18 kick-off meeting in the Hesburgh Library.

Fixity Requirements

Tools that help users or data curators identify whether a digital file is fixed, or unchanged.

• Recognize when things change

• Be able to recover from these changes

• Multiple Hashes both coming and going

  • MD5

  • SHA256

  • SHA512

• Look into parity files for "bit rot" recovery

• If you experience a data loss / bit rot, you would use the parity files to reconstruct the original files. Bear in mind that this is a very expensive operation since you have to go bit-by-bit

• Q: Does PresQT need to deliver files inside of a packaging spec? If so, this would require all targets to accept this spec?

• Q: Alternatively, would PresQT send across file X, along with hashes and parity files.

• Ideas

  • Electron desktop app that allows target-to-target file syncing between services.

  • API Data Layer with multiple hashes/parity files.

Is there an avenue here to utilize blockchain technology as a fixity measure/proof?

Preservation Requirements

Tools that provide an assessment of a digital object's metadata completeness or preservation quality

• It sounds like one of the concerns that some members have is how data is modified between it's initial intake and when it is uploaded as a "final product" to a research repository.

• Robust Metadata

• Open Formats

• "Provenance" - this term comes up a lot in this domain.

• Important to capture the complete execution stack.

One of the big issues that we need nail down is what metadata is going to be required and/or derived from files and/or packages being processed by PresQT.

Keyword Assignment Requirements

Definition: Tools that automate or nudge for better or easier tagging

• Sounds like there are only vague ideas of what might be done in this arena.

• Perhaps