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.