On Wed, Feb 08, 2006 at 01:32:32PM -0700, Zhiwu Xie wrote:
> The following elements in PREMIS are allowed to be empty:
>
> - creatingApplication
> - environment
> - dependency
>
> >From the schema point of view this is no big deal, it allows an empty
> element in the record. But from the semantic view this basically says:
> you don't have to preserve A, but if you do want to preserve it, you
> still can just give me an empty record.
i don't understand this.
> Perhaps a bit more elaboration on this part can help the semantics
> to be clearer.
could you clarify the question?
> For example, if we do want to preserve the creatingApplication,
the intent of the element wasn't to preserve the creating
application. it was to provide information about the creating
application.
for example, if i'm preserving document A, which is of a particular
document type, it's still possible that creating application B
introduces some quirks into A. optionally knowing that B created A
might help us better understand the format of A when it comes time to
migrate it, for example.
if, however, you want to preserve the creating application, then
either creating application can't be applied, because you don't know
it (you're dealing with commercial products), or, if it's something
you wrote, then the creating application might be, say, a particular
version of a C compiler.
> perhaps at least we must preserve either the creatingApplicationName
> or the dateCreatedByApplication, or both, otherwise some record may
> only contain a creatingApplicationVersion number without specifying
> who and when.
i think that this is an interesting point. can we codify common sense
here? if i say Name and Version and DateCreatedBy are all optional,
does it makes sense only to record Version? no. what's the best way to
address this?
> In case of dependency, I think perhaps dependencyIdentifier needs to be
> mandatory, because the dependencyName is just a hint.
>
> What do you think?
i don't think so. you may have identified a dependency on something
that isn't in your repository. also, the rationale for DependencyName
is: "It may not be self-evident from the dependencyIdentifier what the
name of the object actually is." so clearly it was thought that the
name served as more than just a hint.
|