In early PREMIS discussions, creatingApplication was considered part of
objectCharacteristics like size and format. However, it was moved out
of objectCharacteristics for two reasons. First, it seemed like in
future METS schema development, creatingApplication might want to go in
digiProv, while the other objectCharacteristics would certainly go in
techMD. Second, objectCharacteristics pertains
only to files and bitstreams, but it was felt that creatingApplication
could apply to a representation. The example given was a Quark compound
document: a native Quark file that needs to be viewed with Quark, but
has eps subcomponents.
For these reasons, creatingApplication was separated from
objectCharacteristics and made a container at the same level, applicable
to representations, files and bitstreams.
However, in the onion model, you would repeat the objectCharacteristics
block for each compositionLevel. So, if PDF file A is
gzipped, I have one objectCharacteristics block for A.pdf
(compositionLevel 0) and one for A.pdf.gz (compositionLevel 1). Each of
these has a separate and distinct creatingApplication. I can record
both creating applications because creatingApplication is repeatable,
but I can't link the creatingApplication element to the appropriate
objectCharacteristics/compositionLevel.
Maybe this isn't a problem. Logically as a human I can look at the two
creatingApplication element values and know that the Adobe application
must have made the PDF and the Unix gzip application must have made the
compressed file. Still, I'm wondering if there should be some way to
tie these together.
We can't put creatingApplication back under objectCharacteristics
because of the conflict in applicability. But maybe creatingApplication
should have a compositionLevel like objectCharacteristics?
Anybody else have any thoughts on this?
p
|