I think I agree.  It would be cleaner, and easier to understand.

Also, as my colleague Carol Chou points out, the definition of the 
contentLocation (offset) of the bitstream could use some clarification, 
since you probably want to point to the bitstream header.

Rebecca, I think this boils down to one erratum and one suggestion, if 
you could update the website.  The erratum is the storage container 
should be optional for bitstreams.  The suggestion is to make storage 
not applicable to bitstreams and define a new element for recording the 
location of a bitstream.


Zhiwu Xie wrote:
> Very good point, Priscilla.
> Actually I am thinking perhaps it's better that the storage element
> applies only to files, and use a separate term for bitstreams to
> describe their location information relative to the hosting files. This
> term should be bitstream specific and does not mix with other existing
> terms. It does not explicitly relate to the stroage, therefore should
> not appear so.
> Thanks,
> Zhiwu
> On Tue, 2006-02-07 at 08:16, Priscilla Caplan wrote:
>>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
>>>What do you think?
>>>Zhiwu Xie
>>>Graduate Research Assistant
>>>Research Library
>>>Los Alamos National Lab