Year, Term, InstrlD, Location, T ime Slot, Days what are yau coking far? Figure 1: Extract from the course database nts: in other cases we can rely on external functions led by the sQl statements. T 1.1 Motivation Our work on FlexRecs was motivated by, and has been imple- mented as part of CourseRank, a social tool we have developed 2: Fixed recommendations in Course Rank in our lab. CourseRank helps students in our university to make informed choices about classes and take advantage of the avail- proach X be more effective than approach Y in our environment? able learning options. It displays official university information What are the right weights for blending two recommendations(e.g and statistics, such as bulletin course descriptions, grade distri one based on what students like. and another based on what courses tions, and results of official course evaluations. Students can are more critical for completing a major)? What is the best way to anonymously rank courses they have taken, add comments, and predict, not good courses, but likely grades a student will obtain in rank the accuracy of each others'comments. They can also get future courses? Implementing many different recommendation ap- recommendations, organize their classes into a quarterly schedule proaches and their variants from scratch, possibly as different sy or devise a four year plan and track their progress. CourseRank also tem modules, can be time-consuming and counter-productive and functions as a feedback tool for faculty and administrators, ensur- does not lend to high code reusability. It also leads to a recommen ing that information is as accurate as possible. To support this func- dation system that is not easily expandable and manageable and it nakes experimenting with different recommendation possibilities the courses offered, the instructors, the students, the textbooks cumbersome and slow and so forth. Figure 1 provides a small snapshot of the database hema. The use inside the university, out of a total of about 14, 000 students. The describe recommendations. These descriptions would also need to vast majority of users are undergraduates, and there are only about handle parameters, so that end-users could at run time personal 7,000 undergraduates in our university. ize their recommendations, e.g., by choosing a selection condition, recommendations The need for flexibility and expressivity. Although the ini- ing Flex Recs framework has indeed made it possible to(a) easily tial version of Course Rank has been very popular [2], we received capture multiple recommendation paradigms and allow users dy nany requests, from students and administrators, for more flexible namically personalize them to fit their needs, (b)experiment with recommendations: As most commercial recommendation systems, novel recommendation strategies, (c)design a flexible and extensi our initial version offered no choices, just a list of recommended ble system and increase developer productivity: instead of adding courses for the student to consider. as shown in Figure 2. The new modules, a developer needs to define a new recommendation ure displays a general list of collaborative recommendations fo workflow or expand the library of reusable functions if a new com- particular student containing a Robotics course and a Spanish lan arison or prediction model is needed. The new version of Cours- guage course. If the student is interested in Spanish courses, she cRank employs the flexible recommendation engine to support di lay prefer to see more Spanish courses. If she is interested in ferent features and to let end-users tailor their recommendations French courses, she may not want to see any of our recommenda- We have also designed a user interface for flexible recommenda- tions. Students want to specify the type of course they are inter- tions in CourseRank [16 ested in(e.g, a biology class, something that satisfies the univer sity's writing requirement). They also want to request recommen- 1.2 Contributions dations based on a peer group they select (e. g, students in their major, or freshmen only)and based on different criteria For exam In summary, the contributions of our work are as follows: ple, a student may want recommendations for CS courses from C We propose decoupling the definition of a recommendation pro students with similar grades(i.e, with similar performance)and for cess from its execution and present FlexRecs, a framework for dance classes from students with similar ratings (i.e. with similar fining flexible recommendations over structured data. In Flex astes). In some cases, students want to see the recommendations Recs, a recommendation approach can be defined declaratively the system would give their best friend, not themselves s a high-level parameterized workflow comprising traditional The need for experimentation and higher productivity. As rec- relational operators ommendations comprise an integral part of the system, we want to We introduce an extend operator that generates a virtual experiment with different recommendation approaches: Would relation. For example, a tuple in an extended student rel ar stories are known from other domains [1, 5]. For y contain an attribute that gives all the courses taken by Amazon customer that once bought a book for his student. Although there is nothing new in the concept of a favor of milar to other kidsbooks buyers and is bound to see makes the whole framework work: extended relations simplify recommendations in his/her future transactions with the system. the definition of our other operatorDepartments(DepID, DepCode, Name) Courses(CourseID, DepID, Title, Description, Units, Url) CourseSched(CourseID, Year, Term, InstrID, Location, TimeSlot, Days) Instructors(InstrID, Name, Url) Students(SuID, Name, Class, GPA, Status) StudentStudies(SuID, StudyPrgID) StudyPrograms(StudyPrgID, ProgramName, Classification, DepID) StudentHistory(SuID, CourseID, Year, Term, Grade, Rating) Comments(SuID, CourseID, Year, Term, Text, Rating, Date) Figure 1: Extract from the course database SQL statements; in other cases we can rely on external functions that are called by the SQL statements. 1.1 Motivation Our work on FlexRecs was motivated by, and has been imple￾mented as part of CourseRank, a social tool we have developed in our lab. CourseRank helps students in our university to make informed choices about classes and take advantage of the avail￾able learning options. It displays official university information and statistics, such as bulletin course descriptions, grade distri￾butions, and results of official course evaluations. Students can anonymously rank courses they have taken, add comments, and rank the accuracy of each others’ comments. They can also get recommendations, organize their classes into a quarterly schedule or devise a four year plan and track their progress. CourseRank also functions as a feedback tool for faculty and administrators, ensur￾ing that information is as accurate as possible. To support this func￾tionality, we maintain a database that stores rich information about the courses offered, the instructors, the students, the textbooks, and so forth. Figure 1 provides a small snapshot of the database schema. The system is already used by more than 9,000 students inside the university, out of a total of about 14,000 students. The vast majority of users are undergraduates, and there are only about 7,000 undergraduates in our university. • The need for flexibility and expressivity. Although the ini￾tial version of CourseRank has been very popular [2], we received many requests, from students and administrators, for more flexible recommendations: As most commercial recommendation systems, our initial version offered no choices, just a list of recommended courses for the student to consider, as shown in Figure 2. The fig￾ure displays a general list of collaborative recommendations for a particular student containing a Robotics course and a Spanish lan￾guage course. If the student is interested in Spanish courses, she may prefer to see more Spanish courses. If she is interested in French courses, she may not want to see any of our recommenda￾tions1 . Students want to specify the type of course they are inter￾ested in (e.g., a biology class, something that satisfies the univer￾sity’s writing requirement). They also want to request recommen￾dations based on a peer group they select (e.g., students in their major, or freshmen only) and based on different criteria. For exam￾ple, a student may want recommendations for CS courses from CS students with similar grades (i.e., with similar performance) and for dance classes from students with similar ratings (i.e., with similar tastes). In some cases, students want to see the recommendations the system would give their best friend, not themselves. • The need for experimentation and higher productivity. As rec￾ommendations comprise an integral part of the system, we want to experiment with different recommendation approaches: Would ap- 1 Similar stories are known from other domains [1, 5]. For instance, an Amazon customer that once bought a book for his 9-year-old will be considered a kids’ books fan or be mistakenly considered similar to other kids’ books buyers and is bound to see irrelevant recommendations in his/her future transactions with the system. Figure 2: Fixed recommendations in CourseRank proach X be more effective than approach Y in our environment? What are the right weights for blending two recommendations (e.g., one based on what students like, and another based on what courses are more critical for completing a major)? What is the best way to predict, not good courses, but likely grades a student will obtain in future courses? Implementing many different recommendation ap￾proaches and their variants from scratch, possibly as different sys￾tem modules, can be time-consuming and counter-productive and does not lend to high code reusability. It also leads to a recommen￾dation system that is not easily expandable and manageable and it makes experimenting with different recommendation possibilities cumbersome and slow. Faced with the above challenges, we need a way to declaratively describe recommendations. These descriptions would also need to handle parameters, so that end-users could at run time personal￾ize their recommendations, e.g., by choosing a selection condition, or by weighting recommendations that are blended. The result￾ing FlexRecs framework has indeed made it possible to (a) easily capture multiple recommendation paradigms and allow users dy￾namically personalize them to fit their needs, (b) experiment with novel recommendation strategies, (c) design a flexible and extensi￾ble system and increase developer productivity: instead of adding new modules, a developer needs to define a new recommendation workflow or expand the library of reusable functions if a new com￾parison or prediction model is needed. The new version of Cours￾eRank employs the flexible recommendation engine to support dif￾ferent features and to let end-users tailor their recommendations. We have also designed a user interface for flexible recommenda￾tions in CourseRank [16]. 1.2 Contributions In summary, the contributions of our work are as follows: • We propose decoupling the definition of a recommendation pro￾cess from its execution and present FlexRecs, a framework for defining flexible recommendations over structured data. In Flex￾Recs, a recommendation approach can be defined declaratively as a high-level parameterized workflow comprising traditional relational operators and new recommendation operators. • We introduce an extend operator that generates a virtual nested relation. For example, a tuple in an extended student relation may contain an attribute that gives all the courses taken by that student. Although there is nothing new in the concept of a nested relation, this particular flavor of nested relation is what makes the whole framework work: extended relations simplify the definition of our other operators