Print

Print


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