In attempting to preserve *and* disseminate the documents in the Berry collection, we considered both aspects pretty extensively to be sure. In our preliminary evaluations of potential software, we didn’t find Omeka to purport to handle long-term preservation as one of its main use cases, and haven’t really found anything more in our initial implementation either. This forced a reassessment of how to handle long-term preservation, and we turned it into as a secondary requirement/aspect of the project given the limited resources and time available.

Our plan therefore basically breaks down as follows: sticking to very common digital imaging formats (tiffs, jpeg derivatives) we feel will provide enough long-term accessibility for the foreseeable future (at least until such time as another project can focus on long-term preservation as *primary*); as to the metadata, that too we feel is sufficiently open and static (textual data in a standard, documented database table in a popular, open-source RDBMS) that it is foreseeably-future-proof until/unless additional resources are put toward converting it further.

Basically, I think that both of these cases leave us with data that can be easily (i.e. *programmatically*) transformed or exported into yet another format/configuration/implementation using an almost limitless number of methods or tools currently available. There really isn’t anything about Omeka that locks the data or metadata into any particular form, and the forms we chose were based on their presumed availability moving forward.

I hope that helps somewhat but if we can clarify any of these points or if you have additional insights, we’d welcome further discussion.

(I could also be over-optimistic about Fedora et al’s capabilities here, I do not have a lot of experience in this area).

Since you are calling your project an “Archive”, did you consider issues of long-term digital preservation? Does Omeka offer anything relevant there?