Kernel Information WG VC Aug 17
General topics on the call:
Next call we should start with P10 agenda discussion
I'd like to advocate for a decision criteria for inclusion / disclusion
for kernel information be based on whether the information is structural
metadata. If a field is structural in nature, it qualifies for
inclusion. If not structural, it does not. I'd like to discuss this
tomorrow if agenda permits.
A definition of structural metadata that I think is most appropriate
comes out of the digital library community*:
In digital library community usage, structural metadata describes the
intellectual or physical elements of a digital object. For a file that
represents a single page as a compound document (e.g., a JPEG 2000 jpm
file), the structural metadata may include information on page layout.
In a multi-file digital object (e.g., a scanned book with many page
images), structural metadata describes the object's components and their
relationships: pages, chapters, tables of contents, index, etc. Such
metadata can support sophisticated search and retrieval actions as well
as the navigation and presentation of digital objects. METS offers one
model for the encoding of structural metadata.
In some engineering and related technical contexts, the term structural
metadata refers to physical or technical information about a digital
object, such as file format, size, media, etc.
What can be done with structural metadata alone? With structural
metadata alone one can:
-- linking related objects,
-- verifying quality
-- making optimization decisions (based on size)
-- associating actionable entities to a data object (such as registering
a reader in DTR for a file format or media)
-- allows information about object granularity to
This I advocate is a strong set of functionality. Additionally,
structural metadata can be bounded far more easily than can trying to
draw a fuzzy line around and through descriptive metadata.