Re: Representing distinct item states

Reflecting on MacKenzie's comments and Jason's comments, it's clear that there
must be a way to explicitly specify what metadata gets collected about what
items under what circumstances. MacKenzie comes at it from an important
perspective --- let's remember what it is for, no archivist is likely to care
about some/many of the fine-grained changes we have discussed here, including
perhaps changes to metadata. Her comments address what the high-level goals
(policies) of the institution would be. These must be encoded.

We DON'T WANT TO HARDCODE these policies into the system; doing so makes them
hard to implement, hard to get right, hard to change, hard to review and
validate, etc. Regardless of the granularity, there must be a general-purpose
way to explicitly specify these sorts of policies

All this to echo what Jason has said:

> MacKenzie made an excellent point about policy and its
> importance to the History System in the last PI call.  If
> we consider History as a metadata generator, then these
> (missing) policies can define some of the behavior of
> History and can answer some of the more recent questions
> posed on this list.  In other words, it is a policy decision
> whether adding a bitstream to a bundle changes the containing
> item.  In most use cases that I can think of, maximum utility
> is achieved by not propagating changes out of the local object,
> but I can only be confident enough about this decision to make
> it the default behavior.  Another policy decision may be whether
> to record the replacement of one bitstream in the same bundle
> with a new bitstream with the same content. Depending on the
> application, someone may or may not need this
> information.

John

Received on Tuesday, 27 May 2003 09:42:59 UTC