mahout-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tamas Jambor <jambo...@gmail.com>
Subject Re: store time in DataModel
Date Fri, 25 Jun 2010 15:39:15 GMT
I think getPreferenceTime(long userID, long itemID) would be all I 
really need, and to sort by date in the preference array. Most of the 
algorithms I know based on the assumption that the sequence the user 
rated items and the items received ratings gives you an additional layer 
to detect behaviour.

Tamas

On 25/06/2010 16:09, Sean Owen wrote:
> OK well if there are several people interested in using this info --
> and there are viable algorithms making good use of it, sounds worth
> integrating. It's not some arbitrary datum -- timestamp is pretty
> fundamental.
>
> I think this change is basically a change to DataModel. Something like
> getPreferenceTime(long userID, long itemID) ? What kind of API is
> needed beyond this?
>
> Sean
>
> 2010/6/25 Christoph Hermann<hermann@informatik.uni-freiburg.de>:
>    
>> Am Freitag, 25. Juni 2010 00:43:50 schrieb Tamas Jambor:
>>
>> Hello,
>>
>>      
>>>>> Just wondering if there is an option to store time in one of the
>>>>> DataModels? Looking at the code, it looks this is not implemented
>>>>> yet.
>>>>>            
>>      
>>>> No, this is not really part of collaborative filtering per se. But
>>>> nothing about the model precludes you from storing and using time
>>>> -- it's just not relevant to the core CF algorithm. For example
>>>> you're welcome to have a timestamp column in your database table
>>>> alongside other columns, doesn't matter.
>>>>          
>>      
>>> thanks. I don't really agree that it's not relevant, though. Many new
>>> methods are beginning to integrate temporal dynamics into the models.
>>>        
>> I totally agree on that.
>> What about changing Mahouts core code to be able to implement this more
>> easily?
>>
>> I thought about having an Interface that could be extended depending
>> which data you have. Since you (almost) always have Users and Items,
>> that should be default and then additional interfaces could add either
>> ratings or timestamps (or both) and then extend the code this way.
>> Also separating User and Item based recommenders would remove the need
>> to throw UnsupportedOperationExceptions (just a thought).
>>
>> I've implemented a recommender for learning environments which is
>> completely based on timestamps, I'll present it at the upcoming AACE Ed-
>> Media in Toronto.
>> The basic idea is that when users behave the same way over time, you can
>> use timestamps of items and their relations to create recommendations.
>> So yes, i think there are settings where timestamps are worth to be
>> used.
>>
>> regards
>> Christoph Hermann
>>
>> --
>> Christoph Hermann
>> Institut für Informatik
>> Tel: +49 761-203-8171 Fax: +49 761-203-8162
>> e-mail: hermann@informatik.uni-freiburg.de
>>
>>      

Mime
View raw message