| Food Composition Data: A User's Perspective (1987) |
|Experiences with food composition data: the context|
|The INFOODS system|
Just as there are decisions that we expect each region will make separately, even if several of them reach the same conclusions, there are decisions that we expect will usually be made at facilities within the regions. For convenience, we describe these as "local decisions" and "local facilities," recognizing that some facilities that operate within regions and below the regional level may, themselves, operate as subregions with several levels of smaller or more local machines dependent on them for data or other services.
Each local site will be able to make its own decisions about what programs it should run and what hardware they should be run on. That flexibility is needed for at least two reasons - the need to be able to accommodate local interests or requirements for different types of data processing or entry, and the reality of constrained choices in hardware, and sometimes software, in various parts of the world (for example, if an institution has decided to run only IBM mainframe hardware and no stand-alone machines, then there is no value in a recommendation for "standard" software that requires a desk-top machine).
Not unlike the regions, each local facility will have to make its own decisions about what data are retained and for how long. While at the regional level this question applies primarily to the foods to be retained, at the local level there is the additional question of what data - nutrients, quality information, data-source information, other descriptive information, non-nutrients, and so forth - about each food should be kept as well.
Similarly, requests for data to be imported into a particular local facility will need to be made at that facility. Neither INFOODS nor a regional centre can make sensible recommendations about what data (especially extra-regional data) a particular local facility should retain or make available to its users. In this context, any software, especially end-user (small machine) and the user interfaces of regional software maintained by INFOODS, will be produced primarily as demonstrations of the feasibility of the general structures, of at least one way to do things, and, in the case of interchange formats, references as to how those formats are handled. INFOODS is also likely to produce some subroutine-level codes that will be suitable for embedding in other systems to provide debugged interfaces to facilities defined as part of the INFOODS work. There is no obligation on any facility, local or regional, to utilize any of that software directly, and its principal purpose will be demonstration and reference. None the less, we expect that it will be directly useful to some facilities, and they will certainly be invited to use it if they wish. The decision to do so will be another decision that can be made regionally or locally, as appropriate.
If we have a single group of recommendations for everyone, whether local facility or regional centre, it is that programs and systems be designed on the assumption that change, probably a great deal of change, will occur and is inevitable. In particular, as technical groups and individual scientists in different parts of the world progress with their work, we can expect to see explosions in both data and requirements: more foods, more nutrients, more desire to accommodate non-nutrients and source, quality, and description information, and a continuing flow of new and updated data as analytic methods improve. For those of us who have become attached to relatively small machines, there may also be changes in systems and architectures every few years as our perceived needs expand to match new generations of hardware and software. We argue strenuously below that the best system may be one that is closely tailored to a particular set of needs and users, with no presence at being "general purpose," but even such special systems should be designed so that the next study to be performed, or the next nutrient to be entered, does not completely disrupt them.
"What does the user need?" One theme that surfaces frequently in discussions is that users have only two important needs, "data and more data." We suggest that this is not true. The reason why it is not leads us to the first of our major system design suggestions. Data, as data, are essentially worthless. Computer systems should serve us in two important ways - to organize and catalogue data so that they can be managed, retrieved, and processed, and to provide assistance to process the data into information, something that we do need and probably need more of. Information has to be defined in terms of particular needs, and it is essential that the needs of food composition data be articulated and documented.