...

• Enable accurate, meaningful, fine-grained, and globally-understood identification of a <tt>Bitstream</tt>'s data format.
• Maintain backward compatibility with most existing code, and existing archives.
• Introduce the binding of persistent, externally-assigned data format identifiers to <tt>BitstreamFormats</tt>.
• Integrate tightly with "standard" data format registries, using a plugin framework for flexible configuration:
  • Anticipate that the Global Digital Format Registry (GDFR) will be the registry of choice, but allow free choice of other metadata sources.
  • Recognize references to entries in "standard" data format registries in ingested content (e.g. technical MD in SIPs) to facilitate exchange of SIPs and DIPs.
  • The DSpace data model directly includes only the subset of format metadata it has an immediate use for, and references entries in an external format registry for the rest.
  • Refer to formats by the external data format registry's identifiers so format technical metadata is recognized outside of DSpace.
• Improve the automatic identification of data formats in batch and non-interactive content ingestion.
• Help interactive users identify formats easily and with accuracy during interactive submission.
• Rationalize use of <tt>BitstreamFormat</tt> object:
  • Eliminate the overloaded use of the "License" format and "Internal" flag in BitstreamFormats to mark and hide deposit license bitstreams.
  • Attempt to accurately describe the data format of every Bitstream, even the ones created for internal use.
• Create pluggable interface to external data format registries, to encourage experimentation and track developments in this highly active field.
• Add a separate pluggable format-identification interface to allow a "stack" of methods to identify the format of a Bitstream by various techniques.

Use Cases

See BitstreamFormat + Renovation Use Cases for the sketches of the
anticipated use cases that drove this design. The text grew too
large for one page.

...