Course:CPSC312-2016-Project1-StarbucksRedux

Title

Authors: Aditi Chakravarthi, Nancy Chen

What is the problem?

Everyone loves Starbucks drinks (and food, maybe). However it is difficult to tell how these tasty lattes, macchiatos and brownies are affecting your health. The information regarding each food item is not available unless the user goes online ( Starbucks Drink Calories ). Now even when the users read through the given chart it is impossible to know what food item suites certain dietary needs (e.g. a beverage for a low-carb/diary-free diet).

Our natural language interface will handle a range of calorie inquiry in drink items. Based on the specificity of the drink item the interface can provide one or more options that satisfy the user's need.

What is the something extra?

While the information on Starbucks drink items is available online, the process to obtain it is tedious. The flow of information is also static/one-way. Not only will this interface allow users to obtain data in a lively "question-asking" format but it also supports users to solicit suggestions based on their drink customizations. Because Prolog allows flexible answer-matching output for the language, the answers will give a very relative and compact set of information for side-to-side comparison. We think this interface tackles a real-world issues and can be used as a prototype for food recommending systems.

What did we learn from doing this?

We learned that Prolog's flexing pattern matching that gives a range of suitable answers to a question was very useful for our system which has multiple combinations of drinks. For instance, asking how many calories are in a tall pumpkin spice latte gives eight possible answers with different combinations of milk and whipped cream.

?- ask([how,many,calories,in,a,tall,psl],A).

A = [whole, whip|330] ;

A = [partial, whip|300] ;

A = [skim, whip|260] ;

A = [soy, whip|270] ;

A = [whole, nowhip|270] ;

A = [partial, nowhip|240] ;

A = [skim, nowhip|200] ;

A = [soy, nowhip|210] ;

One big benefit of NLP is that users can query the knowledge base without an understanding of any query language such as SQL. We found this feature greatly complemented our interface in that it allows non-technical people to be able to access to large food nutrition databases using their natural languages.

In terms of coding, we were able to store drink adjectives dynamically to apply them on the drinks and learned how to link different objects if the knowledge base is well-designed. With pattern matching ability Prolog allows fast class implementation, which was very helpful for designing a database representing the intricate categories of Starbucks drinks. However maintaining this knowledge base is costly -- because it was very inefficient to manually enter and update the knowledge base given that each drink varied in its size, milk fat content and whip/no whip, we had to significantly reduce the scope of our knowledge base given project time constraints.

A more sophisticated parser would definitely have increased the range of types of questions that could be asked without restricting users to conform to a certain style of question - the current system can answer 'how many calories are in a tall pumpkin spice latte' but not "how many calories in pumpkin spice latte that is tall". It was difficult to interpret modifying phrases which again, restricted the style of question - for example, 'how many calories in a tall psl' was easier to parse than 'how many calories are in a tall psl' which was more more difficult to parse. This made us appreciate the sheer variety that is present in natural language and the inherent difficulty in parsing queries that are structured in natural language.