> --- On Wed, 8 Sep 2004, Carla Montori wrote:
> My interest in the DCMI Kernel metadata effort comes from my work in
> preservation.  My institution uses conversion to digital file formats via
> scanning as its preservation reformatting option of choice, a choice that
> then requires us to provide a range of metadata to describe the new format,
> to facilitate navigation within the files, etc.  I'd like to know what
> others think are the minimum data elements required to describe adequately a
> digital file created to be a surrogate for an orginal in another format.  I
> have some experience with metadata requirements for presrvation surrogates
> that are so onerous that the institution cannot commit the cataloger time to
> create those data points.

Carla,

Thanks for adding this important perspective, which raises several issues.
If I understand correctly, I'd frame them in a context something like this:

   1.  An object X needs to be preserved.  I'd guess that this object X
       already has metadata, possibly quite rich, that makes it useable
       in your environment (for discovery, retrieval, etc).

   2.  A digital object Y was created, with preservation in mind, as a
       surrogate for the purpose of keeping a kind of copy of object X,
       but in a different format.  Object Y needs to be kept and it needs
       metadata, but Y is a surrogate that is not the direct focus of the
       preservation effort (X is).  One day, object X might disintegrate,
       in which case Y, as the next best thing, might then be promoted to
       become the focus of an ongoing preservation effort.

   3.  Money for creating surrogates such as Y depends on a special kind
       of metadata.  This money may be given out by granting agencies who,
       to stretch their funding, avoid redundant efforts by requiring
       grantees to record their "intent to digitize" in a central registry.
       A grant would be awarded to digitize object Z only if no match on
       its metadata could be found in the registry (to make sure that no
       one else had already done it or was planning to do it).

For kernel metadata the essential question is,

    "how little metadata can we get away with for orderly management
    of our collection (without getting fired ;-)"?

Putting Carla's preservation issue in that context, I'd guess that at
least one question for constructing requirements is:  what's the minimum
metadata needed to satisfy a reasonable registry lookup requirement?

The answer I think has two parts.  First, use the basic ERC to identify
the work itself; this is the "anchoring story" of the ERC, described in
section 6.2 of [1].

Second, this working group (that's us) would try to invent a suitable way
to augment that ERC with a description of the surrogate -- who digitized it,
what format it's in, when digitized, and where the surrogate is located.

If I haven't wandered off in the weeds, would anyone care to be involved
in this definitional work?

-John


[1] http://jodi.ecs.soton.ac.uk/Articles/v02/i02/Kunze/

    ... [ from section 6.2 ] ...
    An anchoring story need not be the central descriptive goal of an ERC
    record.  For example, a museum provider may create an ERC for a digitized
    photograph of a painting but choose to anchor it in the story of the
    original painting instead of the story of the electronic likeness;
    although the ERC may through other segments prove to be centrally
    concerned with describing the electronic likeness, the provider may have
    chosen this particular anchoring story in order to make the ERC visible
    in a way that is most natural to patrons (who would find the Mona Lisa
    under da Vinci sooner than they would find it under the name of the
    person who snapped the photograph or scanned the image).