Low level information is best stored using endemes. Endeme migration is an interesting situation. Part of the idea of information programming is getting it right (rather than getting it perfect). So your endeme sets will evolve as you change your endeme sets from time to time. But what about the endemes developed using a previous version of the set?
Four Solutions to the Endeme Migration Challenge
I can think of four possibilities for handling this situation in which endeme sets change over time in a production system.
- Migrate each of the old endemes to the new set, possibly using an endeme proxy translation for the migration.
- Allow the old endemes to degrade gracefully or perhaps less than gracefully.
- Create a new set and an old set and change the set for the old endemes to the old set (or just some of them) and change the code to use the correct set as needed.
- Throw the system away perhaps because it was not built architecturally or info-architecturally right
Certain kinds of endemes/sets will degrade gracefully
- Small changes to sets will degrade more gracefully, larger changes may have to be migrated.
- Since endemes are a form of qualitative information, qualitative factors are important. For example if a characteristic letter gains a radically different very important meaning, the degradation will not be graceful. Migrate in this case.
- Endemes that control software may not degrade gracefully, endemes that characterize resources are much more likely to degrade gracefully. What matters most is how they are used.
- The importance of what is done with the endeme set also weighs in.
The Process of Migrating Information
Migrating can be used for writing proxy endemes between the old and the new version of the endeme set. A translator endeme can be devised for many old to new set conversions. In fact translator endemes can be used for far more than just migrations.