COST logo Eurocode 2 Food Coding System logo Discussion Note N001

Objectives of the Eurocode 2 food coding system

[Eurocode 2 Home Page] [Eurocode 2 Discussion Group] [Eurocode 2 Proposals] [Eurocode 2 Feedback Form]

Contents  •  IntroductionComments by:29 Oct 99
  •  Stated objectives, 1991
  •  Review of stated objectives
  •  Suggested objectives for modified Eurocode
  •  Further objectives and requirements
  •  Closing discussion of objectives


The Eurocode Review Project of the Danish Veterinary and Food Administration plans to further develop the Eurocode 2 Food Coding System into a practical tool for recording food consumption data. Any modified system will be extensively based on the existing work completed in 1993. However to ensure that the results of the project are useful and acceptable to a wide range of potential users, it is necessary to discuss and prepare a revised statement of objectives for the system. This document notes and reviews the stated objectives defined for the existing version of Eurocode 2 and suggests objectives for the modified system. Please send your comments either using the project feedback form or by e-mail to Ian Unwin.

This is a working document into which feedback will be incorporated, a final discussion will be added and the final objectives will be produced. Comments received by 29 October 1999 will be particularly helpful as they will contribute to the next stage of the project which is the production of a draft position paper. This will outline the present status of the Eurocode 2 food coding system and discuss the options for further development and implementation. It will be discussed at a meeting of the COST Action 99 Eurofoods Food Description working group being held on 3 to 5 December.

Stated objectives, 1991

Poortvliet, E.J., Klensin, J.C. & Kohlmeier, L. (1991).
Rationale Document for the Eurocode Food Coding System.
Institute for Social Medicine and Epidemiology, Berlin.
The Rationale document for the Eurocode 2 Food Coding System produced in 1991 (Poortvliet et al., 1991) stated that "The Eurocode 2 was developed to serve as a standard instrument for nutritional surveys in Europe and to serve the need for food intake comparisons" (page 4). Earlier the introduction stressed the need to design a system around specific and well-defined problems and requirements. A code system should:
  1. describe foods in common terms, as they are reported by subjects of consumption surveys
  2. contain no more information than a subject can provide
  3. allow for consistent and reproducible grouping of foods by aggregation of smaller food groups and food items
  4. follow consistent rules for classifying and finding specific foods, and provide reasonable criteria for arbitrary decisions
  5. provide exactly one code for any given food
  6. adequately reflect distinctions among foods that are nutritionally important in the European diet.

Review of stated objectives

The numbered points can be considered requirements for the system stemming from the stated objective. A possible (?likely) problem for the acceptance of Eurocode 2 is that its design objectives do not match those of its potential users. A starting point for reviewing (and possibly revising) its objectives is to consider the listed requirements and the implications they have for the objectives that the system can fulfil.
  1. describe foods in common terms, as they are reported by subjects of consumption surveys
    This first point is a deceptively simple statement relating to issues that are central to defining the objectives of Eurocode 2. It is necessary to define what information Eurocode 2 should record. Should it record how a consumed food is reported or should it involve translation to a controlled language? Producing a classification implies the latter but this imposes the following requirements:
    • the translation must not lose important information (and it must defined what is 'important')
    • the translation must be possible and practical for the machine or coder performing it, i.e. suitable information must be available from the subject and/or the Eurocode documentation
    • the translation must be as far as possible consistent, for example through the system minimising the need for the same or similar difficult decisions to be repeated independently.

  2. contain no more information than a subject can provide
    This might be restated more precisely. The coding operation must not add information that is not correct because the subject did not know it, for example through the assignment of a too-specific term. On the other hand it is acceptable (and probably necessary) that the system should add information that is implicit in the reported item. For example, when the consumption is reported of cornflakes, coding should automatically incorporate descriptors for components added as fortification.

  3. allow for consistent and reproducible grouping of foods by aggregation of smaller food groups and food items
    The Eurocode classification provides a single option for aggregation through its hierarchy. If there is a requirement to use alternative grouping systems (endnote) for aggregation, the coding categories must be reorganised into separate hierarchies. Accepting the need for alternative groupings for data aggregation has its advantages for the development of Eurocode. It means that categories can be placed in their logical place with respect to consumption reporting rather than the need to categorise by source. In particular, substitutes based on, say, Soya beans can be placed according to their product type rather than their source organism.

  4. follow consistent rules for classifying and finding specific foods, and provide reasonable criteria for arbitrary decisions
    As far as possible, arbitrary decisions should be included in, or added to, the Eurocode documentation so that they are consistently applied.

  5. provide exactly one code for any given food
    This is an absolute requirement which unfortunately is impossible to achieve. It requires that it is always possible to distinguish "any given food" unambiguously from all other foods that may be encountered (endnote). This is a target to be aimed at, not one to be achieved.

  6. adequately reflect distinctions among foods that are nutritionally important in the European diet
    The final point directly addresses the overall objectives of the system. However it bases this on a generalisation, the European diet, which might be more precisely defined. It should adequately support studies of the diets of ethnic communities and possibly comparative studies with non-European locations.

Suggested objectives for modified Eurocode

The present project aims to update the Eurocode 2 food coding system into a form which will be more widely accepted and used. Clearly stated objectives are important to this. Even if the modified system does not fully support all the stated objectives, these will help to ensure that its development is moving in an agreed direction. Thus the objectives must accord with the requirements of users and potential users.

This discussion paper provides the opportunity to formulate and agree these objectives collaboratively. As a starting point, the following are suggested but this initial drafting is completely open to any suggestions for revision. We look forward to your contributions and comments.

The suggested objectives are:

Further objectives and requirements

Further applications:  The objectives drafted above emphasise the recording of consumption data, clearly covering intake data for individuals contributing to group studies. Eurocode has been considered for related applications, in particular for the standardised recording of Household Budget Data and this aspect will be discussed at the working group meeting in December.

Food and nutrient calculations:  Applications that process the recorded data such as aggregation and matching with composition data are cited as secondary objectives above such processing may be undertaken at a later stage. However the necessary information must be contained within the recorded data or be available from related resources (which, for example, organise the Eurocode categories into alternative classifications for specific data aggregation requirements). Calculation of the amounts of nutrients or other food components consumed may be derived if the food composition data are also associated with Eurocode codes. Simple matching will be possible only when the consumption code corresponds to the code of one food item in the composition data. Thus it is likely that nearest-matching procedures will need to be developed and used. (Can anyone supply existing examples of these, please?) These may interrelate nearness in the Eurocode classification with other information, particularly that stored in the descriptor system noted in the next section. This will require that the overall Eurocode system (the primary classification, the descriptor system, definitions within the documentation, etc.) allows as much detail and precision of information to be recorded as possible so that matching algorithms can derive optimal results.

Descriptor system:  So far the Eurocode Review Project has concentrated on revising the categories defined within the Main Groups of the primary classification system. The categories are intended to record the food item itself (either by the food source or product type according to the policy defined within the documentation) rather than other information such as the processing, preservation or cooking applied to the food at any stage prior to consumption. The Eurocode version 93/1 system used a simple Descriptor System to record such additional information. This will need to be recorded for consumption data (and in composition data) to meet a number of objectives and indeed these objectives will determine the types and level of detail of information that should be supported through the assignment of descriptors. General objectives and more detailed requirements for the handling of additional information using descriptors need to be defined so that a more extensive descriptor system can be specified. The resultant system should be closely allied to the LanguaL food description language but the exact relationship will depend on the objectives and requirements identified for the Eurocode system.

Recipe information:  Food composition databases compiled in association with food consumption surveys often include substantially more foods than equivalent published food tables, with a wider range of recipe variations contributing to the extra coverage. Thus a system for recording food consumption data is probably required to provide effective support for recipe information. It might hold full details for a consumed dish, relate the consumed dish to a standard recipe or a variation of one, or need to record the consumption of incompletely defined recipes. A recipe made be associated with descriptors for its preparation or the state of its ingredients. It will probably be associated with numeric data for the amounts of its ingredients and possibly for weight change (yield) and cooking temperature. Eurocode classification and description may be used to manage yield and nutrient retention factor information, possibly creating a further objective for the system.

Amounts consumed:  As well as handling numeric data for recipe information, the system should specify the ways in which the amount of the food consumed should be expressed. This might include the management of standard (or expected) portions, either overall for food items or as defaults within the data for one subject or for given types of subject. Such information (as is the case for composition records and recipe ingredient information) might be linked to specific food items in a database or to items specified using Eurocode.

Closing discussion of objectives

Please send your comments on the proposed objectives either using the project feedback form or by e-mail to Ian Unwin. After the closing date for feedback, a discussion of the results will be drafted and posted on the site as part of the preparation of the Postion Paper. This further discussion will be open to final comments and revisions up to 30 November 1999 in preparation for the working group meeting.


Alternative grouping systems

Two possible approaches to implementing alternative coding systems are to use completely separate hierarchies designed specifically for aggregation or to use a multi-faceted food description system such as Langual. In the latter, the alternative groupings would use different facets as the primary division of the hierarchy, for example product source or cooking method. However the effectiveness of reorganising coded data into alternative hierarchies is likely to be influenced by aspects of the coding hierarchy design and coding rules. Taking an example, milk might be reported without information on the source as cow or soya and thus however it is recorded it cannot be reorganised by product source. There are two alternatives, it could be posted to a higher level "generic milk" or there could be an extra category of "Milk, source unknown" at the same level as "Milk, cows'". Discussion and further work is required to determine the better alternative.
(The example raises a separate grouping issue in that Milk is subdivided by fat content not source organism. The latter aspect may now be more important than 10 years ago and it would be helpful to develop a system that can record both aspects.)   – Return

Foods and their labels

The identification of a food relies heavily on its name, but it may be best to consider this as a label separate from the food itself. It should not be used as the basis for defining the classification or coding a food. For example the presence of the word "pie" in a food name should not necessarily detemine that that is how it should be classified or coded in a Pie category (anymore than "Bombay duck" should be considered Poultry). Synonyms may also be problematical. It is convenient in coding documentation to equate these to a particular category (i.e. code), but the synonym may have subtleties of meaning that differ from those of the main food name.   – Return



Ian Unwin
Updated:  6 October 1999