Release notes for LensKit 0.4
Recommendation and Prediction API
To support more types of recommenders easily, we have changed the way the dynamic recommendation and prediction components and their APIs work (#issue(109), #issue(110)). These changes are backwards-incompatible; client code and implementations need to be updated for 0.4.
ItemScorer, an generalization of prediction that scores items for users.
ItemScorer, and deleted its
predict(...)methods in favor of the item scorer methods. It now serves as a type-level indicator that a scorer returns predicted preferences as scores.
Removed dynamic interfaces in favor of putting the history-based methods directly in the
ItemRecommenderinterfaces. An added
canUseHistory()method on each interface indicates whether the history will be used or ignored. This greatly simplifies the inheritence hierarchy for recommender components.
Changed the behavior of item recommenders when a
nullexclude set is provided. Previously, this was equivalent to the empty set. It is now equivalent to a default exclude set which will be recommender-specific but generally a set of items the user is unlikely to need recommended (such as all items they have rated). All recommenders have been updated with this change.
The old design was easier to slightly implement but made less sense from a client API perspective. The new design, where
nullis the default exclude set, makes the API cleaner (the fully-general method can use default exclude sets). The loosened specification of default exclude sets also gives us greater flexbility for LensKit to be used as a basis for novel recommendation approaches.
Incompatible data structure changes
To clean up APIs, we made a couple notable incompatible changes to layout and data structures. These are all compile errors; no subtle behavior changes that the compiler won’t catch here.
UserHistoryand related classes to the
UserRatingVector, as they type distinction severely complicates configuration for generalized model builders. The upside: types remain sane and configuring basket recommenders will be feasible. Downside: the type system doensn’t indicate whether a user vector contains ratings or some other data.
DynamicRatingPredictor.predict(long, Collection, Collection)to take a
UserHistoryof events rather than a collection of ratings.
Made abstract recommenders and predictors uniformly expose the DAO as a protected final field.
Added methods to
DataAccessObject, with default implementations in the abstract implementation, to allow user history objects to be directly retrieved for given users.
Added snapshotting as an explicit concept to the data layer.
DAOFactorynow has a
snapshot()method, which is supposed to return an immutable snapshot of the data for test/build purposes. Iterative algorithms still use rating snapshots, as they’re faster and provide indexing, but this allows us to be more flexible in what kinds of data access recommender component builders can perform. Factory implementations now need to provide a snapshot method; this can be done by simply creating an event collection DAO from the events. Users with large data sets may want to use more exotic methods like database replication or transactions.
JDBCRatingDAOfactory makes snapshotting configurable. By default, it assumes the database is unchanging; it can be configured to take an in-memory snapshot and return an