This paper presents the submission of the TAAABLE team to the 2017 Computer Cooking Contest. All challenges except the sandwich challenge are addressed. Online systems have been developed for the salad and mixology challenges by adapting previous successful CCC TAAABLE systems to the requirements of the 2017 challenges. However, this paper presents two main contributions. The first contribution is a new approach based on adaptation rules for managing the ingredients available for adapting salad recipes, and the second contribution is a work on cocktail name adaptation which is submitted to the open challenge. The cocktail name adaptation takes into account the name of the recipe which has to be adapted, knowledge about the name of the recipe and about the substituted and substituting ingredients. The naming process uses the problemsolution dependency to the context of the target problem, exploiting knowledge encoded in RDFS, a semantic Web representation language. This approach in the framework of the representation language RDFS is a general approach and can be applied in other problem solving contexts.
This paper presents the participation of the TAAABLE team to the 2017 Computer Cooking Contest. TAAABLE addresses all the challenges except the sandwich challenge. Online systems have been developed for the salad and mixology challenges, respectively available on http://tuuurbine.loria.fr/taaableCCC2017/salad.php and http://tuuurbine.loria.fr/taaableCCC2017/cocktail.php . For these two challenges, previous successful CCC TAAABLE systems have been adapted to fulfill the requirements of the 2017 challenges. The management of a limited set of ingredients (called the fridge in the following) uses, for the mixology challenge, the process that has been presented at the CCC 2015 contest. Once the basic retrieval process of TAAABLE returns a recipe to adapt, this process based on formal concept analysis searches the more accurate available food which has to be used to substitute for a non available one. A first contribution of this paper concerns the salad challenge, for which we propose a new approach to manage the fridge, using adaptation rules. The second main contribution of this year concerns the open challenge for which we present a work about cocktail name adaptation. The cocktail name adaptation takes into account the Copyright © 2017 for this paper by its authors. Copying permitted for private and academic purpose. In Proceedings of the ICCBR 2017 Workshops. Trondheim, Norway dishType ing ing R cocktailDish ?x ?y type
vol type vol
Vodka
4: MintLiquor 2:
The “Green Russian” recipe is identified by the resource R. Its ingredients are 4 cl of vodka and 2 cl of mint liquor. The preparation is not represented. ing relates a recipe to one of its ingredients. type (abbreviation of rdf:type) is an RDF property relating a class to its instance (for example, the triple h?x type vodkai means that ?x is an instance of vodka. The variables are existentially quantified (there exist ?x and ?y such that. . . ). The property vol relates an ingredient to its volume in centilitres. name of the recipe which has been adapted, knowledge about the name of the recipe and about the substituted and substituting ingredients. The naming process uses the problem-solution dependency to the context of the target problem, exploiting knowledge encoded in RDFS, a semantic Web representation language. This approach in the framework of the representation language RDFS is a general approach and can be applied in other problem solving contexts.
The paper is organized as follows: Section 2 introduces the core of the TAAABLE system. Sections 3, 4 and 5 present the TAAABLE systems which adress respectively the mixology, the salad and the open challenges. The challenges, proposed by the CCC since its first edition consists in proposing, according to a set of initial recipes, one or more recipes matching a user query composed of a set of wanted ingredients and a set of unwanted ingredients. Since 2015, the TAAABLE systems are built using TUUURBINE [1] (http://tuuurbine.loria.fr ), a generic case-based reasoning (CBR ) system over RDFS which allows reasoning with knowledge stored in a RDF store, as the one provided by the contest. TUUURBINE implements a generic CBR mechanism in which adaptation consists in retrieving similar cases and in replacing some features of these cases in order to adapt them as a solution to a query. RDF (Resource Description Framework) represents data as triples of resources hsubject predicate objecti, where the resource predicate is a property. A resource is either a constant or a variable (generally called identified resource and blank node, respectively). By naming convention, variables start with the symbol ? whereas constants do not. Fig. 1 illustrates a recipe represented using RDF triples. RDFS gives some semantics—and thus, inference possibilities—to RDF by the mean of inference rules associated to some resources. Only a few rules are used in this paper: ha type Ci hC subc D
ha type Di hA subc Bi hB subc C hA subc Ci i r1 i r3 ha p bi hp subp q
ha q bi hp subc qi hq subc r hp subc ri i r2 i r4 type, subc and subp are abbreviations for rdf:type, rdfs:subClassOf and rdfs:subPropertyOf . type is the membership relation between an instance and a class. subc (resp., subp) is the relation between a class and a superclass (resp., a property and a superproperty). r1 means that if a is an instance of a class it is also an instance of its superclasses. r2 means that if a and b are related by a property, they are also related by any of its superproperties. r3 and r4 state that subc and subp are transitive. For example, the following inference can be drawn:
h?x type Vodkai; hvodka subc Alcohol i
` h?x type Alcohol i
RDFS does not include negation, thus only positive facts can be entailed. However, an inference with closed world assumption (CWA) can be drawn, stating that if B 6` t then t is considered to be false (given the RDFS base B), denoted by B `cwa :t.
SPARQL (SPARQL Protocol and RDF Query Language) enables to write queries to RDF or RDFS bases. If a SPARQL engine uses RDFS entailment, this means that the query is done on the RDF base completed by RDFS entailment. For example, the following SPARQL query addressed to a base describing recipes such as the one of figure 1 returns the set of recipes ?r containing some alcohol, taking into account the domain knowledge, in particular the subclass relations of the food hierarchy presented in Fig. 2. The CWA is assumed: if it cannot be entailed that a recipe contains some alcohol, then it is concluded that it does not.
Qalcohol = SELECT ?r WHERE f?r ing ?a . ?a type Alcohol g
(
TUUURBINE is a generic CBR system over RDFS .
The domain knowledge is represented by an RDFS base DK consisting of a set of triples of the form hC subc Di where C and D are classes which belong to a same hierarchy (e.g, the food hierachy). Fig. 2 represents the domain knowledge for the running examples by a hierarchy whose edges C x! D represent the triples hC subc Di with x, the retrieval knowledge encoded by a cost function cost(hC subc Di) = x. This cost can be understood intuitively as the measure of “the generalization effort” from C to D. How this cost is computed is detailed in [2].
Liquid 0:60
FruitJuice
0:14 OrangeJuice
AppleJuice
Liquor
Vodka 0:10 Tequila
0:01 StrawberrySyrup
0:01 Grenadine 0:17 Curacao A TUUURBINE query is a conjunction of expressions of the form sign prop : val where sign 2 f ; +; !; g, val is a resource representing a class of the ontology and prop is an RDF property belonging to the set of properties used to represent cases. For example,
Q = +dishType : CocktailDish ^ ing : Vodka ^ !ing : Grenadine
(
The signs (empty sign) and + are “positive signs”: they prefix features that the requested case must have. + indicates that this feature must also occur in the source case whereas indicates that the source case may not have this feature, thus the adaptation step has to make it appear in the final case. For example, the term +dishTypeCocktailDish means that TUUURBINE will only retrieve cases which are cocktail recipes.
The signs ! and are “negative signs”: they prefix features that the requested case
must not have. indicates that this feature must not occur in the source case whereas !
indicates that the source case may have this feature, and, if so, that the adaptation step
has to remove it.
The retrieval process consists in searching for cases that best match the query. If an
exact match exists, the corresponding cases are returned. For the query Q given in (
Each one-step generalization is associated with a cost denoted by cost(A B). The generalization of Q is a composition of one-step generalizations 1, . . . n: = n : : : 1, with cost( ) = Pin=1 cost( i). For example, for:
Q = +dishType : CocktailDish
^ ing : Vodka ^ ing : Curacao ^ !ing : Grenadine
(
Curacao is relaxed to Liquor according to the domain knowledge of Fig. 2. At
this first step of generalization, (Q) = dishType : CocktailDish ^ ing : Vodka ^
ing : Liquor ^ !ing : Grenadine, which matches the recipe described in (
When the initial query does not match existing cases, the cases retrieved after generalization have to be adapted. The adaptation consists of a specialization of the generalized query produced by the retrieval step. According to (Q), to R, and to DK, the ingredient MintLiquor is replaced by the ingredient Curacao in R because Liquor of (Q) subsumes both MintLiquor and Curacao. So, the adaptation consists in replacing curacao by mint liquor.
TUUURBINE implements also an adaptation based on rules where a rule states that in a given context C, some ingredients F can be replaced by other ingredients B. C, F and B are the contexts, the “from part” (premise) and the “by part” (conclusion) of the adaptation rule [3]. For example, the piece of knowledge stating that, in cocktail recipes, orange juice and strawberry syrup can be replaced with pineapple juice and grenadine, can be represented by an adaptation rule with C = CocktailDish, F = OrangeJuice ^ StrawberrySyrup and B = PineappleJuice ^ Grenadine. Such an adaptation rule can be encoded by a substitution = C ^ F C ^ B. In the example: CocktailDish ^ OrangeJuice ^ StrawberrySyrup CocktailDish ^ PineappleJuice ^ Grenadine. This rule-based adaptation is directly integrated in the retrieval process by searching cases indexed by the substituted ingredients for a query about the replacing ingredients, for example by searching recipes containing OrangeJuice and StrawberrySyrup for a query about PineappleJuice and
2.6
The TAAABLE knowledge base is WIKITAAABLE (http://wikitaaable.loria.
fr/); WIKITAAABLE is composed of the four classical knowledge containers: (
In WIKITAAABLE , all the knowledge (cases, domain knowledge, costs, adaptation rules) is stored into a triple store. So, plugging TUUURBINE over the WIKITAAABLE requires only configuring TUUURBINE by giving the case base root URI, the ontology root URI and the set of properties on which reasoning may be applied. 3
The mixology challenge consists in retrieving a cocktail that matches a user query according to a set of available foods given by the CCC organizers. For this challenge, the successful TAAABLE system which won the jury and public prizes in 2015 has been adapted to take into account the new list of available foods (vodka, gin, rum, tequila, sake, champagne, tomato juice, apple juice, sparkling water, grenadine syrup, lemon juice, lime, mint, ice cube, brown sugar, salt, pepper). The principles remain the same as the ones used in the 2015 system. TUUURBINE is used to perform the retrieval step which takes into account the available foods (section 3.1). A specific adaptation step based on formal concepts is used when some ingredients of the source recipe are not available, to search the best way to replace them, or in some cases, to remove them (see Section 3.2). TUUURBINE is able to manage a fridge directly through a query modification using the and ! prefixes. Indeed, if answers must only contain the available foods, the initial user query can be modified by adding the minimal set of classes of the food hierarchy that subsume the set of foods which are not available, each class being negatively prefixed by !. For example, let us assume that OrangeJuice and AppleJuice are the available fruit juices, that Vodka and Tequila are the only available alcohols, that Grenadine is the only available syrup, and that the user wants a cocktail recipe with Vodka but without Grenadine. The initial user query will be Q = +dishType : CocktailDish ^ ing : Vodka ^ !ing : Grenadine. According to Fig. 2, Liquor and StrawberrySyrup will be added to this initial query with a ! for expressing that the result cannot contain one of these non available classes of food. The extended query EQ submitted to TUUURBINE will be:
EQ = Q ^ !ing : Liquor ^ !ing : StrawberrySyrup
For this example, TUUURBINE retrieves the “Green Russian” recipe with the
adaptation “replace MintLiquor with Food”. In order to replace MintLiquor by
something more specific than Food, a FCA approach which exploits ingredient combination
in cocktail recipes is used.
FCA is a classification method allowing object grouping according to the properties
they share [4] and so, is able to find regularities in a set of objects. When the objects
are cocktail recipes and the properties are the ingredients the cocktail recipes use, FCA
computes ingredient combination. FCA produces formal concepts as output. A formal
concept is a pair (I; E) where I is a set of properties, E is a set of objects, respectively
called the intent and the extent of the formal concept, such that (
To search a replacing ingredient in a given recipe or in a recipe according to pieces of food that will be kept, the idea is to exploit the lattice which captures concept similarities and organization. Adapting a cocktail is based on the closeness between concepts. For example, when a replacing ingredient is searched for MintLiquor in R (concept #6), some similar concepts (i.e. sharing a same super-concept) can be used. In the lattice given in example, concept #6 can be generalized into concept number #2, which extent contains cocktails with vodka and liquor. The cocktail in the extent of concept #7 is similar to the one of concept #2, because they share the Vodka and the Liquor properties. When removing MintLiquor from the “Green Russian” recipe, a possible ingredient for substitution, given by the lattice, could be Curacao. However, as Curacao is not an available food, concept #7 cannot be used to complete the substitution.
Let CR be the formal concept such that Er(CR) = fRg. A formal concept C close to CR is searched according to the following procedure. C is such that its intent I(C) does not contain the removed ingredient (MintLiquor in the example) and maximizes jEr(C)j. First, C is searched in the ascendants of CR, then in the descendants of the ascendants satisfying the available food constraints. The ingredient to be substituted is replaced by I(C) n I(CR).
Applying this procedure, the most similar ingredient combinations which includes Vodka that can be used to replace MintLiquor are given by concepts #3, #4 and #5 and their descendants. However, concept #4 and its descendants cannot be used to produce a substitution because its intent contains PineappleJuice which is not an available food. Concept #5 intent contains AppleJuice, an available food, but concept #3 is closer to concept #6 than concept #5 is, according to the selection procedure based on the maximal number of objects of Er. The cocktail system will suggest replacing the mint liquor with orange juice.
To implement our approach, data about ingredient combinations in cocktail recipes has been collected. For this, we queried Yummly (http://www.yummly.com/ ) with query composed of one ingredient (one available food from the CCC 2017 new food list). More details about the FCA based approach can be found in [5]. 4
The adaptation challenge requires managing a limited set of available food (like in the cocktail challenge) and adapting the ingredient quantities. 4.1
The approach for managing a limited set of ingredients is rather different in the salad challenge context than in the cocktail one. Indeed, there are many important differences between the knowledge involved to solve a recipe adaptation for the mixology challenge and the knowledge involved to solve a recipe adaptation for the salad challenge. First, there are less salad recipes than cocktails recipes: 70 against 108. Second, the salad recipes use 266 different ingredients of whom 245 are not available in the fridge. For the cocktail recipes, only 139 ingredients (among the 156 different ingredients) are not in the fridge. Third, the minimal, maximal and average of ingredients per recipe is 4, 18 and 10 for the salad recipes and only 2, 10 and 5 for the cocktail recipes. The second and third points directly impact the number of ingredient substitutions required to adapt a recipe to fit the fridge constraint. Adapting a salad recipe requires at least 3 substitutions and in average 8 substitutions (the maximal number of substitutions is 17). For the cocktail recipes, to take into account the fridge, the maximal number of substitutions is only 7, 10 recipes require only 1 ingredient substitution and, in average, the number of substitutions is 3. Fifth, the ingredients involved in the salad recipes are more distributed over the food hierarchy: 13 top categories of the food hierarchy are concerned (Vegetable, Fruit, Meat, Seafood, Legume, Diary, Liquid, Oil, . . . ), whereas only 3 top categories are concerned for cocktail recipes (Liquid, Fruit, and Flavoring). All these facts drastically increase the adaptation effort for the salad challenge comparing to the cocktail challenge: more ingredients to substitute in order to adapt a recipe, more unavailable foods implied and a larger distribution of this foods in the food hierarchy. So, it is not appropriate to generalize an unavailable food to Food because too many food classes will be generalized into Food: 8 in average. With the approach presented for adapting cocktail recipes, it requires searching for each of these 8 ingredients which ingredients of the fridge can be used as substituting ingredients. That is why we propose a new approach using adaptation rules, in order to better control the adaptation. The idea is to define, for each available food f , which ingredients can be replaced by f . About 50 adaptation rules have been added to manage the foods available to cook a salad. For example, the four following adaptation rules:
1 = (SaladDish ^ Diary 2 = (SaladDish ^ CitrusFruit 3 = (SaladDish ^ Egg
SaladDish ^ Yogurt) SaladDish ^ Orange)
SaladDish ^ Salmon) 4 = (SaladDish ^ StoneFruit
SaladDish ^ Strawberry) state that, in salad recipes, dairy may be replaced by yogurt, citrus fruit may be replaced by orange, egg may be replaced by salmon, and stone fruit may be replaced by strawberry.
Let F be the set of available foods. The adaptation rules we defined are all of the form = (SaladDish ^ A SaladDish ^ B), with B 2 F. However, we can consider 3 types of rules relying on the relation between A and B: – If B v A and A 6v B and @C 2 F such that B 6= C and C v A, the adaptation rule allows to substitute all the foods more specific than A with B. For example, = (SaladDish ^ Diary SaladDish ^ Yogurt) will allow to replace a dairy (e.g. Creme) appearing in a case base recipe by some yogurt. The constraint “@C 2 F such as B 6= C and C v A” guarantees that there is no food in the fridge more specific than A other than B. For example, suppose that some Cheese (e.g. Cheddar) is available in the fridge, 1 will be split in more specific adaptatation rules, e.g. if Cheese and Creme are the only direct subclasses of Diary: (SaladDish ^ Creme SaladDish ^ Yogurt), and (SaladDish ^ Cheese SaladDish ^ Cheddar). – If B 6v A and A 6v B, the adaptation rule implies two foods which do not belong to a same category in the food hierarchy. This type of rule allows to take into account that two foods A and B play the same role in a salad dish and so, that they are substitutable. For example, 3 has been created because Egg and Salmon play the same role: they are proteins. This type of rule allows also to fix a food B as the closest available food of A. For example, 4 has been created because there is no stone fruit in the fridge and in this case, when StoneFruit appears in a source case recipe, the best way to substitute it with an available food is with Strawberry,
– If B = Food, the rules state that there is no way to substitute A (e.g. Tea) appearing in a recipe of the case base with something available in the fridge. In this case, A is generalized into Food and an adaptation procedure is triggered to remove all the A which have been generalized into Food.
The impact of such rules in TUUURBINE is that new recipes are virtually created, because a recipe containing for example some grapefruit (which is a citrus fruit) will be retrieved as if this recipe contains some orange. So, the TUUURBINE retrieval process will be able to return recipes whose adaptation effort will be less costly because more controlled (the adaptation process remaining the same).
Let Q = +dishType : SaladDish ^ ing : Salmon ^ ing : Cucumber ^ !Lemon : , be an example query meaning that the user wants a salad recipe with salmon and cucumber but without lemon. Consider the recipe named “Cucumber salad with hard-boiled egg and fromage blanc” which index is idx(R) = Egg ^ FromageBlanc ^ Cabbage ^ Lemon ^ Salt ^ Pepper.
According to the fridge and to the food hierarchy, the unavailable foods are added to this initial query Q with a !. For example, FromageBlanc and Egg are unavailable classes of food. The extended query EQ submitted to TUUURBINE will be :
EQ = Q ^ !ing : FromageBlanc ^ !ing : Egg ^ ::: For simplification, we present only the two classes of EQ which represent unavailable foods that will be taken into account by the adaptation rules. The first generalization which returns results is = Cucumber Vegetable producing the generalized query: (EQ) = dishType : SaladDish ^ ing : Salmon ^ ing : Vegetable ^ !ing : Lemon ^ !ing : FromageBlanc ^ !ing : Egg. With the use of the three adaptation rules 1, 2 and 3, R matches (EQ) because 1 transforms the FromageBlanc, a
3 transforms the Egg of R into Salmon, and Cabbage is a Vegetable according to the food hierarchy. The answer returned by TUUURBINE for adapting R to Q consists in replacing Cabbage by Cucumber, Egg by Salmon, FromageBlanc by Yogurt and Lemon by Orange. The first subsitution comes from the basic retrieval/adaptation processes of TUUURBINE , while the three last ones come from the adaptation rules. 4.2
The ontology-based substitution procedure extended by adaptation rules of TAAABLE favors the substitution of ingredients of the same type (a sauce by a sauce, a vegetable by a vegetable, etc.). So, ingredient quantities can, in most cases, be reused without adaptation. For example, 3 cups of Pasta can be replaced by 3 cups of Couscous, 1 tsp of Oregano by 1 tsp of Cumin, etc. However, there are some kinds of adaptations (coming from the adaptation rules) which require some quantity adjustements. An approach for the adaptation of ingredient quantities based on mixed linear optimization was proposed in [6] and has been used to compute sugar, alcohol and mass compensation when replacing some ingredients by others in the context of cocktail adaptations [5]. This complexity is not required to adapt salads, especially because the substitution procedure is guided by adaptation rules. So, we only define a simple heuristic to provide realistic quantities to the user. This heuristic is the following. Each food available in the fridge is associated with a preferred unit and to a set of possible units coming from the recipes of the case base. For example, the set of possible units for Carrot is funit; g; ozg and the preferred unit is unit. For the quantity adaptation, if the replaced ingredient unit is a mass (e.g. g) or a volume (e.g. cl, tsp, tblsp) in the source case, and if this unit is a possible unit for the replacing ingredient, neither quantity adaptation nor unit adaptation is done. If not, conversion knowledge coming from WIKITAAABLE is used. First, the quantity of the replaced ingredient is converted into its mass, in grams. For example, if the source recipe uses 2 lettuces, the conversion knowledge stating that the mass of 1 lettuce is 360 g is used to computed the total mass of lettuce: 2 360 g = 720 g). Secondly, conversion knowledge associates to each possible replacing ingredient (a food of the fridge) its preferred unit and the correspondance from this unit to a mass in grams. For example, the preferred unit of Carrot is unit and the mass of 1 unit of carrot is 70 g. This allows computing the adapted quantity in the preferred unit of the replacing ingredient, by divided the mass (in grams) of the replaced ingredient by the mass (in grams) corresponding to the preferred unit of the replacing ingredient. In the running example, if Lettuce is replaced by Carrot, and the original quantity of Lettuce is 2 units then 720=70 10 units of Carrot have to be used (the result is rounded). 5
This section presents the TAAABLE team submission to the open challenge. The issue is, when TAAABLE returns an adapted recipe, how to name it according to its original name and to the substitution. For example, what name could be assigned to the recipe obtained from the “Green Russian” recipe after having substituted the mint liquor with curacao.
This issue of adapting recipe names has been suggested by the jury of the 2014 edition of the CCC and the CookingCAKE system [7] has addressed this challenge for the CCC-2015, using a few rules. For instance, the adjective "cheesy" is added to the recipe name if the adapted recipe of a sandwich contains some cheese. The TAAABLE team has addressed this issue more formally in [8], using an approach based on RDFS. In this application, a problem pb is a representation of a cocktail recipe by an RDFS graph. For the first version of this application, only ingredient types are considered, neither the quantities, nor the preparation steps. Therefore, a problem is an RDFS base pb = Sn
k=1fhid ing ?vki; h?vk type fkig where id is a constant (a resource identifying the recipe), ?v1, . . . , ?vn are n variables, and f1, . . . , fn are food classes.
A solution sol(pb) of pb is a literal of type string that gives a name to pb. It is assumed to be in lower case for the sake of simplicity, e.g., sol(pb) = "green russian" solves the problem pb represented in figure 1. The following operations on strings are used: concatenation (denoted by +, e.g., "ab" + "cd" = "abcd"), substring checking (denoted by subStringOf, e.g., subStringOf("bc"; "abcd") = true), and string replacement (e.g., replace("ab"; "cd"; "bababa") = "bcdcda").
A dependency pb between pb and sol(pb) is an RDFS base. Usually, at least one food class fk of pb and the literal sol(pb) occurs in pb: when it is not the case, pb does not relate pb to sol(pb) (which is possible, e.g., when pb = ;, i.e., there is no known dependency between pb and sol(pb)). For each case (srce; sol(srce)), srce is assumed to be given.
A matching pb from srce to tgt is either simple or complex. A simple matching has the form f g where f is a food class of srce and g is a food class of tgt; it represents the substitution of f by g. The removal of a food class f will be denoted by f ;. A complex matching is a composition pb = pqb pqb 1 : : : p1b of simple matchings. pb is built during the adaptation of ingredients process of TAAABLE .
The matching from srce to tgt is built during the cocktail name adaptation. It consists of a set of ordered pairs (d; d0) where d is a descriptor of srce and d0 is a descriptor of tgt, a descriptor being either a resource (that can be a property) or a literal.
We present in the next sections five adaptation strategies: the two first strategies (§5.1 and §5.2) are application-dependent, whereas the last ones should be adaptable to other applications. Strategies presented in sections 5.3 and 5.4 are designed for simple matchings whereas the strategy of section 5.5 combines strategies for dealing with complex matchings. 5.1
Consider a cocktail recipe containing some alcohol, for which the adaptation consists
in removing the ingredients which are alcohol or in substituting them by ingredients
which are not alcohol. In this case, the new cocktail name may be computed by adding
“virgin” to the original recipe name. For example, let sol(srce) = "mojito" be the
name of the “Mojito” recipe, let pb = rhum ; be the adaptation consisting in
removing the unique alcohol of srce, then sol(tgt) = "virgin mojito" will be the
adapted cocktail name. Note that the test about alcohol can be performed by executing
the SPARQL query Qalcohol (cf. equation (
The default strategy is applied when all other strategies fail, this time by adding “the new ” to the original recipe name (e.g. “the new bloody mary”). 5.3
This section models the adaptation example presented in Section 2, where the “Green Russian” recipe is adapted by replacing mint liquor by curacao. srce ing
?i type inEnglish srce = fhMintLiquor color green i; hgreen inEnglish "green" i; h"green" subStringOf "green russian" ig These triples are represented on the left-hand part of the graph of Fig. 4.
Since pb = MintLiquor Curaao , in order to build tgt, the idea is to apply pb on srce and then to make some modifications on the resources and literals to make it consistent with DK. This consistency test must be considered wrt CWA because there is no way to have hMintLiquor color blue i inconsistent with DK in the classical semantics. It is assumed that DK `cwa :hMintLiquor color blue i, thus the mere substitution pb on srce gives an inconsistent result wrt DK under CWA. So, the idea is to relax this triple. One way to do it is to replace green with a variable ?x. More generally, the strategy consists in replacing the descriptors of srce by variables, with the exception of the predicates (that are higher order resources) and of the descriptors occurring in tgt. The variable that replaces sol(srce) is ?solTgt: solving tgt consists in giving a value sol(tgt) to this variable. This gives the following dependency (obtained by applying pb and turning some constants into variables): gen = fhCuracao color ?x i; h?x inEnglish ?yi;
h?y subStringOf ?solTgt ig gen is so-called, since it generalizes pb( srce) (in the sense pb( srce) ` gen), where pb( srce) is the result of applying the substitution pb on srce.
Now, in order to get tgt, the idea is to unify the variables ?x and ?y with some constants, using the domain knowledge. Therefore DK is interrogated with the following
h"blue" subStringOf ?solTgt ig Assuming the only result is the pair f?x blue; ?y "blue"g, it comes: tgt = fhCuracao color blue i; hblue inEnglish "blue" i; and
= f(MintLiquor; Curacao); (green; blue); ("green"; "blue")g
Therefore, tgt involves that sol(tgt) has to respect the following constraint:
sol(tgt) 2 fs : string j "blue" is a substring of sg
(
sol(tgt) = replace("green"; "blue"; sol(srce)) = "blue russian"
Now, consider the example of the adaptation of sol(srce) = "green russian" when = MintLiquor IndianTonic with the same srce as in section 5.3 and assuming that DK gives no color to Indian tonic (i.e., there is no triple of the form t = hIndianTonic color c i such that DK ` t), the adaptation strategy of section 5.3 fails. However, it is assumed that
8< hIndianTonic taste bitter i, hIndianTonic texture sparkling i, 9 DK ` hbitter inEnglish "bitter" i, hsparkling inEnglish "sparkling" i=, : hcolor subp hOPi, htaste subp hOPi, htexture subp hOP i ; meaning that Indian tonic is bitter and sparkling, and that color, taste and texture are organoleptic properties (hOP is an abbreviation for hasOrganolepticProperty ). Therefore, the adaptation strategy described in section 5.3 can be applied with a slight modification: it is sufficient to replace in gen the triple hIndianTonic color ?x i by hIndianTonic hOP ?x i, which is more general according to DK.
One way to address this problem is to search in the domain knowledge for triples for building gen that are similar to ( srce). This can be likened to the retrieval issue in CBR, which can be implemented by a least generalization of the query (see, e.g., [9]). A similar idea is proposed here. It consists in making a best-first search in a space of dependencies such that: – The initial state 0 corresponds to the gen as it is computed in the strategy of section 5.3. – The successors of a state consists in making a generalization of one of its triples.
The following generalization operators can be considered: replace a class (resp., a property) by a direct superclass (resp., direct superproperty) in DK, replace a resource or a literal by a variable, etc. A cost function must be associated to generalization operators, in order to choose the least costly generalization. – A final state is such that the SPARQL query associated with it gives a nonempty set of results.
Once a final state is found, the rest of the approach of Section 5.3 can be applied with gen = .
Back to the example, it comes: 0 = fhIndianTonic color ?x i; h?x inEnglish ?yi;
h?y subStringOf ?solTgt ig In the first triple, color can be generalized into hOP (since DK ` hcolor subp hOPi), giving = fhIndianTonic hOP ?x i; h?x inEnglish ?yi;
h?y subStringOf ?solTgt ig is a final state since exec`(Q; DK) 6= ; for
Q = SELECT ?x ?y WHERE fIndianTonic hOP ?x . ?x inEnglish ?y g Indeed, exec`(Q; DK) = fA1; A2g where A1 = f?x bitter; ?y "bitter"g and A2 = f?x sparkling; ?y "sparkling"g, leading to the two expected solutions: "bitter russian" and "sparkling russian" .
Therefore this strategy consists in finding the minimal generalization of the initial dependency 0 and then in specializing into tgt’s thanks to SPARQL querying on DK, hence the name of the strategy.
When the matching pb is complex, it can be written pb = pqb pqb 1 : : : p1b, with q 2. The idea is then to apply in sequence the strategies associated with simple matchings. For example, for sol(srce) = "green russian" , p1b = mintLiquor curacao, p2b = vodka tequila, the strategy of Section 5.3 can be applied twice to give the name sol(tgt) = "blue mexican". This adaptation is an application of the adaptation based on reformulations and similarity paths (see e.g. [10]). 6
This paper has presented the systems developed by the TAAABLE team for its participation to the 2017 CCC. The two systems presented for the salad and mixology challenges are based on the successful 2015 version of TAAABLE , extended for salad challenge with a new approach to manage the fridge. A new approach has also been presented for adapting the cocktail names from the ingredient adaptation. Several name adaptation strategies have been presented and, if some proposed strategies are applicationdependent, it is claimed that other ones can be applied—or adapted—to a larger framework. Indeed, they match the principles described in some related work about analogical transfer (e.g., [11] and [12]) while proposing an approach benefitting from the standard RDFS and associated tools (RDFS SPARQL engines, RDF stores). A first prototype implementing the three first strategies has already been developed, but the adaptation strategy based on generalization-specialization of dependencies is under development. However, there is an important workload for acquiring dependencies srce , which is currently done manually and for acquiring triples in the domain knowledge. A possibility to address these issues is to query the Linked Open Data (LOD), a huge cloud of RDF and RDFS bases freely accessible on the Web. This knowledge acquisition task is the main future work.