Course:CPSC312-2024-Concert recommend
Authors: Joseph, Dusty, Michael
What is the problem?
As a fellow concert enjoyers, we want to create a concert and live show recommender system to recommend users different concerts based on their interests. The user can give basic information about themselves (ie. genres of music or artists they like, location or specific venues, price range) and we can recommend a concert based on that information. The interface will support a range of answers to prompts about their interests. For example, user can enter their location and their favorite artist to see if their favorite artist is performing in near the, anytime soon. They are also able to skip entering certain information to get a broader range of suggestions: for example, they are able to skip entering an artist and are able to see a wide range of concerts happening in their city. Currently, our recommender only supports cities in Canada, but could be easily expanded to include more countries.
Our recommendation system is split into 2 parts: the first is the typical recommender system described above, while the second is a query where the user can enter information about a concert they already know about, and the system will return detailed information about that event.
What is the something extra?
We are fetching data from the Ticketmaster API to get all the latest data of concerts and shows.
After fetching the data from the API, we asked the user if they want either suggestions to concerts based on their favorite artists and location, or query a specific event. For the suggestion part, if the user is interested in knowing more about the event/concert, we allow user to ask for specific details using a basic NLP system.
What did we learn from doing this?
We found that prolog is suitable for doing a recommender system, the hard part was to parse users input while catching errors. The error catching is particularly hard since it relies on the previous predicate function, in which whenever an error is caught in a function, it goes to the previous "top" function, but not necessarily the desired function that you want it to loop back to. It was relatively easy to access API data using Prolog -- there are a number of built-in libraries that you can access in order to make it relatively simple. The hardest part about using the API was figuring out the specific structure of the response, and going through various dictionaries to find the information we were looking for.
Work division
Dusty: Set up the base of the recommender system, wrote functions to access API including the construct_api_url, suggest_event, and the various functions to access and display the API response, assisted Michael in creating and debugging the NLP. We all worked together in catching invalid inputs.
Michael: help dusty optimize the cosntruct_api_url, suggest_event. Create the NLP with dusty , and some error catching
Joseph: worked on the query function based on the functions that were set up by Dusty and Michael to increase the user experience for the application, and also implemented some error catching for user input.