|
⇤ ← Revision 1 as of 2008-10-03 12:44:30
Size: 1503
Comment:
|
Size: 2215
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 16: | Line 16: |
| == Working with data files in DOMS == | |
| Line 17: | Line 18: |
| We have devised procedures for working with datafiles in DOMS, that will leave the system consistent. First, a few ground rules need to be defined. * There should always exist a one-to-one correspondance between File objects in Fedora and files in Bitstorage. A file in bitstorage that does not have a File object can never be found again and will be lost. * The only way to upload files to Bitstorage is through the Bitstorage_API. * Bitstorage is a write-once system. Files are uploaded and then approved. When approved, they cannot be deleted later. * Fedora is a write-once system. Objects are created. They can be updated, but this just creates new versions. |
Datafiles in DOMS
DOMS handles files, and metadata about these files. The way it does this it somewhat unusual, and deserve futher explanation.
The DOMS repository is really two different systems, the Fedora metadata storage, and the Bitstorage data storage. There are two kinds of metadata handled by Fedora. The first kind is the information about the actual files, such as fileformat, bitrate, length and so on. Ie. metadata about the actual files, which is nessesary for preservation efforts. The second kind is metadata about the actual contents of the files, ie. the author, and the category of the work. So we have three levels of data in Doms:
- Data about the artistic work
- Data about the digital manifistation of the work
- The digital manifistation of the work.
Most other systems make no distintion between the first and second level, which, for preservation purposes, is unfortunate. One of the advantages of this system is when you have multiple manifistations of the same artistic work. Rather than copying the data about the artistic work, the metadata object just reference each of the manifistations.
One of the results of this is that there are two types of objects in Fedora. There are the normal digital objects, and the File objects, which reference a file in Bitstorage. All File objects must have the content model [:DataModel/ContentModel_File: doms:ContentModel_File], and only such object may ever reference a file outside Fedora.
Working with data files in DOMS
We have devised procedures for working with datafiles in DOMS, that will leave the system consistent. First, a few ground rules need to be defined.
- There should always exist a one-to-one correspondance between File objects in Fedora and files in Bitstorage. A file in bitstorage that does not have a File object can never be found again and will be lost.
- The only way to upload files to Bitstorage is through the Bitstorage_API.
- Bitstorage is a write-once system. Files are uploaded and then approved. When approved, they cannot be deleted later.
- Fedora is a write-once system. Objects are created. They can be updated, but this just creates new versions.