Re:

["Ilya A. Volynets-Evenbakh" <ilya@total-knowledge.com>]

Not exactly what I had in mind :)

Let's see. Here are some thoughts:

1. Voting is associated with each UMO.
This, among other things, means, that when one votes for a child UMO, it
has _no_ effect on parent UMO. i.e. no cumulative/derived voting.
Reasoning:
While every individual element of some topic might be easy, overall topic
might be too difficult due to sheer amount of material.
Or other way around: while some explanations might be extremely terse,
others might be very clear and detailed, combined with good subset of
problems, making overall topic very easy to digest.

2. Voting subjects are not fixed in database
i.e. we don't have separate table "topic_difficulty_votes" and
"topic_relevance_votes".
Instead each UMO type has a "_vote_subjects" and "_vote_counts" tables
associated
with it. "_vote_subjects" lists things one can vote on...

3. Only people who tried to pass an UMO can vote on given UMO. What does
"tried to pass" mean is dependent on UMO type. All UMO types do have
concept of being passed however.

Questions/comments/etc. before I put this into UU spec?

Alexey Parshin wrote:
> Well, in this case it's pretty simple. Every completed test gets a
> vote, and we can always find all the tests within the topic or with
> the course (TLT) - for all the tree of topics.
>
> I'm starting to suspect, that we need an acceleration field
> top_level_topic in every topic.. A slight de-normalization..
>
> 2006/12/18, Anatoly Volynets <av@total-knowledge.com
> <mailto:av@total-knowledge.com>>:
>
>     Sounds reasonable.
>
>     Ilya A. Volynets-Evenbakh wrote:
>     > We could limit voting to only those who tried to pass an object.
>     I don't
>     > know if its a good idea, but if we do this, there will be no
>     need for
>     > separate
>     > voting tables.
>     >
>

-- 
Ilya A. Volynets-Evenbakh
Total Knowledge. CTO
http://www.total-knowledge.com