This is a good point and it raises some other issues as well.

First, should storageMedium apply to bitstreams?  Zhiwu Xie is probably 
correct that the value is applicable to bitstreams but it should be the 
same as the file that contains the bitstreams.  I could not find 
anything in the PREMIS minutes where the applicability of storageMedium 
to bitstreams was discussed.  I am guessing that we thought if you were 
implementing this in a repository system, you would never record 
storageMedium at the bitstream level, because it would be unnecessary. 
However, we were trying to be implementation-neutral, so that should not 
affect that applicability.  Therefore, I would suggest that 
storageMedium should apply to the bitstream.

Second, this points out another contradiction.  In the data dictionary, 
storage is Mandatory for files and bitstreams, contentLocation is 
Optional for both files and bitstreams, and storageMedium is Mandatory 
for files and n/a for bitstreams.  That means the container (storage) is 
mandatory for bitstreams, but of the two contained subelements, one is 
optional and the other is n/a.  Logically, either the container has to 
be optional for bitstreams, or one of the contained subelements has to 
be mandatory.

Finally, PREMIS clearly intended that the contentLocation of a bitstream 
was always an offset within a file.  However, a bitstream does not need 
to be a contiguous set of bits, and in some formats like AVI where audio 
and video bitstreams are interleaved and their interpretation depends on 
the codecs, this can be very complex.  Unless the contentLocation is the 
starting offset only.  I think this needs some more thought.


Zhiwu Xie wrote:
> According to the data dictionary, the term "storage" is defined as
> "Information about how and where a file is stored in the storage
> system". It applies to, and is also mandatory for both files and
> bitstreams. However, the storageMedium, which is contained in the
> storage, applies only to the files but not the bitstreams. There seems
> to be an inconsistent use of the term storage.
> If the storage is about how and where a certain content (not only files
> but also bitstreams) is stored in the storage system, the storageMedium
> should also be applicable to bitstream, although its value should be the
> same as the file which contains the bitstreams. But a "not applicable"
> value of the storageMedia to bitstreams seems to imply a different
> semantics, therefore a different term, which should not be related to
> the storage.
> However, if the contentLocation of a bitstream is to be meaningful, it
> will have to be related to the storage system. A bitstream in the middle
> of a transfer will not have a definite location. If the applicability of
> the storage to bitstreams is related to the storage system, then IMO the
> storageMedium should also apply.
> A further question is that to record the contentLocation of a bitstream,
> perhaps the contentLocationValue will have to start from the location of
> the file in the storage system. Because the relation between a bitstream
> and the file is an optional field, if it is not recorded, then the the
> example of 64[offset from start of file] (data dictionary, p. 2-37) will
> not resolve to a definite location, because the file location is
> missing.
> What do you think?
> Thanks,
> Zhiwu Xie
> Graduate Research Assistant
> Research Library
> Los Alamos National Lab