One of issues I have been facing recently is getting data to and from user interfaces; interfaces for input, interfaces for display. In the old, naïve days, this used to be a relatively easy task because I would store data in a way that meant it could be read and written one-to-one.
Translating “storage data-structure” as “final and ideal representation of data” is harmful. In some cases — and here I particularly mean known-but-not-directly-implemented-schema cases like MARC and Dublin Core — we’ve considered our apparent conceptual data model, e.g. the model that we base our data on, to be an ideal representation and therefore storage form. In both cases, we end up with rigid and unusable data that is neither nice to look at, nor to edit. There is also a lot of manipulation that occurs in the application in order to make the data work in the ways we want, taking basic structures in the data and creating new, more basic structures for use by the application.
Transposing data isn’t a bad thing, it’s inevitable, however, it isn’t necessarily trivial when the data is locked up in a conceptual structure suited to a single application (or even worse, a committee-driven understanding of an application).
It seems that there lies an answer in having some structure in the fundament that is abstract both to the levels of conceptual model and display. Generating logical structures from an understanding of the fundamental data, need not be a one-shot thing; I expect to do this again and again.