 |
 |
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. > > p > > > > 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 > >