Course:CPSC312-2017-Airbnb

From UBC Wiki

Enhanced Airbnb Search

Authors: Harvey, Malinda, Chamantha

What is the problem?

State the general problem. If applicable, tell us what information you will use, e.g., a link to some website that provides the information you used. What will you do?"

The problem is that there is no way to search for a listing on Airbnb without manually setting the filters you want. Currently, a user must enter the location for a listing they want, press search, and then set additional filters if they want more specific results. We will build a natural language interface that will allow users to enter a single sentence and retrieve listings that match the properties/values they mentioned. Our project will aim to evaluate the feasibility of this idea for improved convenience. Ideally, this could support a more generic search option for Airbnb, or could be linked to an Airbnb integration for a voice search interface like Siri or Google Assistant.

We will use airbnb.ca/s/Vancouver--Canada to build our initial set of listings to test our natural language interface on.

What is the something extra?

What is the in-depth aspect you will do? If the problem is related to some other group's project, tell us how they fit together. If in doubt, include the information."

Manually finding a listing and entering its various properties into the Prolog program is time consuming and not a scalable solution. To solve this, we will build a web scraper that automatically scrapes similar listings (given a listing ID) using an endpoint from the Airbnb API. It will fetch the data, parse it into Prolog terms, format the info into our clause format, and save them into a separate database.pl file. Using this method, we can easily build a rich set of predicates to test our natural language interface on.

What did we learn from doing this?

(This should be written after you have done the work.) What is the bottom-line? Is logic programming suitable for (part-of) the task? Make sure you include the evidence for your claims.

We learned that Prolog was well suited for building a NL interface, but not so well suited for dealing with edge cases (for example, ambiguity in grammar), primarily because of its declarative nature. There were cases where using an imperative programming language would have been simpler (for example, when looping through listings from an API response). However, the declarative nature of Prolog made declaring and storing properties of listings an easy task. We were able to complete an NL interface that worked for complex queries such as “is there a place located in Vancouver which costs between 100 and 200 with 5.0 star rating 2 beds 1 bathroom” which is something that a person could definitely ask (especially through some voice interface like Siri or Google Now).

This program was not only a feasible solution for searching listings in Canadian cities, but also for any listing in the world. Given an existing listing ID, the web scraper that we added successfully fetches, parses, and stores (into a database.pl file) listings similar to the provided listing. What makes it extensible is that you can provide the ID of a listing from anywhere in the world and it would fetch similar listings (i.e. a listing from that specific area).

To be specific, we learned how to build a natural language interface (using the examples we were provided in the lectures as a guideline), find endpoints of an API, make HTTP requests in Prolog, parse JSON in Prolog, and manipulate files in Prolog.

We also learned about the limitations of our solution. For example, a potential issue in scalability in our current solution would be cities that have the same names but are in different countries - we would need a way to differentiate between them. The only information the API endpoint currently provides that would help with this is the full address of the listing (neighborhood, city, country). Figuring out which specific city it was would be far less complicated in an imperative language where you can easily check for substrings. Moreover, this is the only relevant & publicly available API endpoint, so our solution cannot extend to fields that were not included in the API response (like breakfast, heating, and internet availability).

In conclusion, we learned that our Prolog solution was a functional solution to the problem we put forward, and is reasonably scalable (with the exceptions being the edge cases, like duplicate city names).

To see the evidence for our claims, you can run our code against the sample queries. You can find the code for our project here: (https://pastebin.com/raw/FwjUz41m)