Yes it is up to you, or any caller, to extend existing DataModels to build objects that carry more information. You can use this extra information in customized alogrithms however you see fit. You do not just need to use DetailedPreference. You are free to create other implementations with whatever info you like.
Your specific question seems to be, rather than pass two 'ID' parameters, is it better to pass them inside a Preference object? This seems more indirect to me at first glance so I am inclined to say no. If you mean you need information from the Preference that the user expresses for the item - the method can look it up. From an API perspective, I do not think the caller should be forced to do this. Does that still allow you to get the behavior you want? Sean On Apr 15, 2009 3:03 PM, "Andre Panisson" <[email protected]> wrote: Hi Sean, I have a doubt about estimating preferences with help of more information than only user and item ids. What if I have other information like date for example? I see that there is an implementation of DetailedPreference that provide an object container for this information, and I think it is simple to provide a dataModel with DetailedPreference as the base type of the preferences, and a Recommender that uses it to learn. But the problem is when I need to use the Recommender interface: it has a method estimatePreference(Object userID, Object itemID) where you can provide only user and item ids. I think it would be more straightforward to have a method estimatePreference(Preference pref), where the given Preference argument have only the preference value undefined. Then, in the method implementation, one could make casts and take all provided information. What you think? André
