1 Resource scoring

Proposal for the new scoring formula:

S = ∑_{i=1}^{n} e^{−d_{i}}e^{k_{i}}

Where:

• S - total score

• i - index of the DeskopEvent associated with the specific resource (from 1 to n)

• d_{i} - time passed since the i^{th} DeskopEvent happened

• k_{i} - coefficient depending whether the DeskopEvent is read event or modify event

1.1 Explanation and reasoning

• The more time passes, the event becomes less relevant, thus e^{−d}

• Viewing and saving files have different importance, thus different coefs.

• e^{k} is being used instead of just k because it produces prettier math (read on)

1.2 Improvements over the current implementation

1.2.1 Updateable score Currently, the score is calculated each time from scratch - analyze all DeskopEvents, and process them. With the new formula, this is no longer the case.

Let S_{1} be the score at some point in time.

S_{1} = ∑_{i=1}^{n_{1}} e^{−d_{i}}e^{k_{i}}

And S_{2} score at some point in time after S_{1} was calculated

S_{2} = ∑_{i=1}^{n_{2}} e^{−d′_{i}}e^{k_{i}}

n_{2} ≥ n_{1} and d′_{i} = d_{i} for i = 1..n_{1} - the first n_{1} events are the same ones we had in S_{1} and we have some new ones. We can write the above formula as

S_{2} = ∑_{i=1}^{n_{1}} e^{−d_{i}−d}e^{k_{i}} + ∑_{i=n_{1}+1}^{n_{2}} e^{−d_{i}}e^{k_{i}}

⇔ S_{2} = e^{−d} ∑_{i=1}^{n_{1}} e^{−d_{i}}e^{k_{i}} + ∑_{i=n_{1}+1}^{n_{2}} e^{−d_{i}}e^{k_{i}} Which, with the knowledge of S_{1} becomes:

S_{2} = S_{1} · e^{−d} + ∑_{i=n_{1}+1}^{n_{2}} e^{−d_{i}}e^{k_{i}}

1.2.2 No special cases Implicit events like the last modified date when no DeskopEvent exist are not a special case anymore - it can be covered in the formula with a simple change of the weight coeficient k_{i}.

1.3 Regressions from the current implementation

1.3.1 Not including the rating From my point of view, this is not an important regression - both score and rating are in the database and if we want to use them both when sorting the results, we can.

On the other hand, I have aversion from having directly dependant data in the database.

1.3.2 No handling of types and file patterns This is (for me) the only real drawback compared to the current code.

1.4 Appendix: Current score

The database (Nepomuk) holds the value of the score the last time it got updated. If it hasn’t been updated for a while, the real score will be:

S_{real} = e^{−d} · S_{saved}

where d is the time since the update.