In this work, we propose a novel knowledge-based tool that provides nutritional recommendations to users based on their profile. While the aim of the conceived framework is to take into account the most relevant features in the users’ profiles for dietary advice, in this prototypical implementation, only the BMI and the corresponding overweight and obesity types are considered. The overall architecture of the ontology-based nutritional recommender system is depicted in
Figure 1 and is comprised of three modules, namely the User Data Collector, which was designed to enable users to interact with the system, the Ontology of Dietary Recommendations (ODR), which contains the conceptualization of the diet domain, and the Diet Recommender, which is responsible for providing users with the recipes that best suit the individual users’ diet needs.
Mainly, the system’s target is to assist people with finding recipes that enable them to lose weight. In brief, the system works as follows. First, a user inserts his/her personal data by using the collector. Details such as weight, age, height, and so on, need to be provided. Then, the system will take advantage of these details to determine the user’s health condition. For instance, if the introduced weight and height are 160 cm and 80 kg, the user is associated with Obesity Type I since the BMI is between 30 kg/m and 34.9 kg/m. Next, the system will select the dietary plan to reduce the overweight considering the type of nutritional disorder detected. To do so, the reasoner will utilize the ODR. Following the above example, the diets that will be suggested given the identified obesity type are bland, dissociated, Dukan, and Mediterranean. Finally, the outcome of the system will be a list of the recipes that match the nutritional restrictions defined in the health plan of those suggested diets. In the following subsections, each component is described in detail.
3.1. Ontology of Dietary Recommendations
To build the ontology, we used the iterative method proposed by Abdel-Badeeh and Hisahm (Salem, 2012), which comprises several stages to specify the requirements, collect and analyze the data, and finally, construct the initial model. As a baseline, the FOKB [
36] was employed to structure the ODR. The following classes were preserved from the original schema:
, which classifies ingredients by EAN (European Article Number);
, to express relations between food and allergen items;
, to define the building blocks of the recipes; and finally,
, which includes different rates to quantify indicators such as the Basal Metabolic Rate (BMR), the BMI, or Blood Pressure (BP), among others. For the purposes of our work, several elements were added to obtain the resulting ODR schema, namely
,
, and
. Next, the purpose of these added classes is described.
: Axioms were included to define the most common variety of eating disorders that can affect users. There are several ways to determine whether an individual is suffering from this dietetic situation. A variety of measures can be considered to specify the grade of obesity. Depending on the measure obtained, the individual will be classified into a set of grades that go from ‘Very Severely Underweight’ to ‘Obesity Type III’. In particular, for this work, the BMI was chosen to assess the grade of obesity because of its simplicity and low cost. In [
49], Weir and Jan set the cutoffs to estimate the body fat. Concretely, for obesity type I, they estimated that the BMI must be between 30 kg/m
and 34.9 kg/m
. Consequently, to express these cutoffs in the ontology, we defined the
data property to declare the limits and various classes to represent the different types of obesity. For example,
was defined as a class equivalent to
whose BMI is between the margins previously set. Following the same procedure, the following defined classes are declared:
,
,
,
,
,
,
, and
.
Table 1 contains the semantic description of these defined classes.
: This organizes the types of diets recommended by the system. At the moment, only the normal and hypocaloric diets (i.e., a diet that is low in calories) are defined since those are the ones associated with overweight/obesity problems representing one of the main challenges for dietitians and nutritionists. Eight subclasses were considered representing eight different hypocaloric diets (see
Figure 2), namely
,
,
,
,
,
,
, and
. This is an initial set of diets chosen based on existing literature [
50,
51,
52]. Some of these diets have been refuted by health experts given their relationship to nutritional deficiencies, but were included due to their popularity. Please bear in mind that this set of diets is dynamic and can be updated based on the latest scientific evidence.
Each diet was systematically associated with a nutrition disorder that is related to users’ metabolism rates. For example, in
Figure 3, the axiom defined to link
to
is depicted. Therefore, the recommendation engine will consider such an association when providing dietary suggestions to users depending on their health profile.
: This contains the entire taxonomy of all the recipes included in the knowledge base. The
dataset (
https://www.kaggle.com/elisaxxygao/foodrecsysv1 (accessed on 17 December 2021)), where thousands of recipes have been collected from the Allrecipes.com website, was used to create such a hierarchy. The dataset includes data such as ingredients, nutritional components, and even users’ ratings. We randomly selected 105 recipes from the whole dataset and scrutinized details about the ingredients and nutritional components to integrate each recipe in our knowledge base. To do so, we developed a procedure (see Algorithm 1) that analyzes each recipe, extracts its ingredients and nutritional values, and expresses the extracted information in the form of OWL axioms. The process takes such details and utilizes data properties and object properties to link the retrieved data to entities already defined in the knowledge base. For instance, the recipe “Abuelas_Picadillo” is made of red wine, butter, bell pepper, garlic, and olive oil, among other ingredients, and contains 74 mg of cholesterol, 378 calories, and 24 g of proteins. Then, the procedure utilizes this information to define the axioms that represent the new recipe with the mentioned ingredients and nutritional values.
Algorithm 1 Mapping ingredients. |
- 1:
procedureanalyzeRecipe() - 2:
while not at end of the recipe do - 3:
- 4:
if then - 5:
//word is an ingredient - 6:
- 7:
- 8:
else if then - 9:
//word is a nutritional value - 10:
- 11:
- 12:
end if - 13:
end while - 14:
end procedure
|
In addition, in order to associate recipes with the type of diets, we defined a specific subclass of
for each diet type (see
Figure 4). The aim of this hierarchy is to clearly state the unique constraints, in terms of both ingredients and nutritional values, that a recipe should satisfy to be valid for a given diet. Essentially, each class defines in OWL language the set of nutritional restrictions that users must follow to implement the diet. Therefore, the number of proteins, calories, or allowed types of the ingredient constitute some of the rules defined in those classes. In this way, when a diet is selected, the recipes will be filtered according to these nutritional restrictions in an automatic way using a reasoning engine. For example, the class
is defined as shown in
Figure 5. Since the
is characterized by high fruit and vegetable content, avoiding chicken, red meat, and eggs, among others, recipes for such a diet should comply with those restrictions.
3.2. User Data Collector
The user data collector represents the entry point for users to utilize the system. It provides an interface that enables users to enter personal information such as weight, height, and age. The system will use these details to determine the health condition of users. Based on these data, metabolic indicators such as the BMI, the BMR, or the BP, among others, will be calculated. Such information will help the recommendation engine to identify whether users suffer from a nutritional disorder and to suggest the diet that most fits the users’ dietetic problems.
In
Figure 7, the process followed to define the axioms in the ontology from the data inputted by the users is depicted. Two parts can be easily differentiated in the figure, the form in which users insert their personal information on the left and the data type properties defined in the ontology on the right. Each property relates a
entity to each data introduced by the users.
Algorithm 2 shows the method developed to insert a new user in the ontology.
stands for the ontology’s namespace, and
contains the string “Person”, identifying the name of the parent class, namely,
. The new user is then included as a new class in the ontology, subclass of the class
.
Algorithm 2 Populate ontology with a new user (class ). |
- 1:
procedureinsertNewUser(, , ,) - 2:
- 3:
- 4:
- 5:
- 6:
- 7:
- 8:
- 9:
- 10:
end procedure
|
3.3. Diet Recommender Module
The Diet Recommender module acts as the mediator between the user interface and the knowledge base. It is responsible for systematically converting the data collected by the user interface into an OWL language to ask the reasoner for the users’ health condition. The query was written in Manchester OWL Syntax using classes, the object properties, and the data properties identifiers. As a result, it retrieves the users’ category of obesity, BP level, or the BMR. Similarly, the system will utilize the information inferred to select the diets most recommendable for the users’ health status. Hence, the module works as follows:
Hence, depending on the user’s taste, different recipes can be combined to follow the recommended diet. For instance, let us suppose that a new user called Robert, age 48, 90 kg, 1.70 cm, aims to receive nutritional advice given his current health status. First, he has to introduce his personal details in the form. The User Data Collector module will harvest the information, compute the measures, and create a new entity in the ODR ontology model. Second, considering the information inserted, the Diet Recommender module will utilize an OWL Reasoner to infer the user’s health status. In particular, in this example, the module will consider the BMI to infer the obesity type suffered by the user, if any, and will associate the most advisable diets, accordingly. Finally, the user can choose from various recipe options and organize his menu regime by complying with the chosen diet.