Of course, I was making it too complicated. Taking a look at the source
for GenericBooleanPrefItemBasedRecommender made it much clearer. Just
overriding doEstimatePreference worked quite well, and as a bonus, i
don't need to regenerate the ItemSimilarities and get live results when
people like/unlike their content.
Thanks kindly for the suggestion, I'm gradually wrapping my head around
all these classes and their roles.
--aaron
On 11-06-15 4:38 PM, Sean Owen wrote:
In item-based recommenders, similarity is used as a weight. You can
modify this weight however you like. I think you would find it most
straightforward to modify the recommender to increase the weight when
you are dealing with an item the user "likes", rather than modify the
similarity. You could simply double it, for example.
On Wed, Jun 15, 2011 at 8:27 PM, aaron barnes<aa...@stasis.org> wrote:
I'm working with data very similar to the typical storefront item scenario.
We're trying to find items that a user might like based on commonalities
between them and other users who have bought similar items.
LogLikelihoodSimilarity is working very well for us. However, our
storefront also has the idea of 'liking' something you have purchased. I'm
looking for a way to incorporate this data to improve our recommendations so
that purchasing commonalities are the primary reason things are recommended,
but the additional 'liking' of a purchase gives it extra weight.
I'm thinking this still most closely resembles a 'boolean' model, because
it's not a matter of the user assigning a rating to every purchase, so we're
not looking primarily for users who have given similar ratings to similar
items, but rather giving extra weight to items that a user particularly
likes.
Am I on the right track here? Any advice on whether it would be better to
modify LogLikelihoodSimilarity to add an additional multiplier when a user
has 'liked' something? or is there a better preference based similarity
model i should use that would still give me a similar effect to a boolean?
--aaron
