Maybe creatingApplications does not have to be directly linked to
compositionLevel? I think this part of the data dictionary is good as it
is.

compositionLevel seems to assume you can trace back the original file or
bitstream by reversing the encoding/bundle, regardless of the
creatingApplication. You may zip-compress the file with WinZip, but
without knowing the creatingApplication is Winzip, with only the
information that the file is zip compresed, we can use other
applications such as winrar to unzip the file. The encoding information
is supposed to be clear from the format info, therefore independent from
the creatingApplication, or at least the creatingApplication should be
obvious given the format info. Because this is just for
decoding/unbundling, the date and time info is not important therfore is
not recorded.

creatingApplication seems to serve some other purposes. If the creating
process is a lossy one, e.g., apply a lossy compression to a jpeg file,
or with an application that is close source/propriatery, e.g., create a
pdf with Acrobat from a MS word file, then we will not be able to get
back the original word file, even if the creatingApplication is readily
available. I think this part of info is just for the sake of preserving
as much as we know about the creating process, just in case they will be
useful later, but not necessarily readily useful for decoding or
unbundling.

Although the sequence info for the the creatingApplication is useful,
(becasue applying application A then B to a file does not necessarily
get the same result as applying B then A) but such info may be inferred
from the dateCreatedByApplication. If the later is not avilable, all we
can say is we don't know much about how the creating was done.

Hope this makes sense,

Zhiwu


On the other hand, given multiple creatingApplications

An example would be if I creat a jpeg file by compress the

On Fri, 2006-02-17 at 07:43, Priscilla Caplan wrote:
> 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