Hi,

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.

T

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.

On Thu, Jun 24, 2010 at 6:40 PM, Tamas Jambor <[EMAIL PROTECTED]> wrote:
> Hi,
>
> 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.
>
> T
>

thanks. I don't really agree that it's not relevant, though. Many new
methods are beginning to integrate temporal dynamics into the models.
On 24/06/2010 21:53, Sean Owen wrote:
> 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.
>
> On Thu, Jun 24, 2010 at 6:40 PM, Tamas Jambor<[EMAIL PROTECTED]>  wrote:
>    
>> Hi,
>>
>> 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.
>>
>> T
>>
>>

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: [EMAIL PROTECTED]

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 <[EMAIL PROTECTED]>:
> 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: [EMAIL PROTECTED]
>

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<[EMAIL PROTECTED]>:
>    
>> 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: [EMAIL PROTECTED]
>>
>>