Re:

["Alexey Parshin" <alexeyp@gmail.com>]

The only problem with the generic voting is the reference to the object of voting. We may have (in the votes table) something like: 

- person
- vote_selection (reference to the vote_selection)

Vote_selection table should contain possible choices for voting and reference to vote_group (or something like this - I don't like the name).
Voice_group contains the title of the vote group, and confidential flag. If the vote is confidential, the person stored to avoid duplicate votes, but isn't displayed anywhere. 
Also, voice group may contain a type of object (TLT, for instance) and an object id. This is, however, a pretty bad structure because it doesn't provide any referential integrity (unless we have only one optional object type - TLT).

2006/12/18, Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com>:

What do you mean "barely usable"?
Author of a course should set DL of objects within his course,
since he decides which audience he is targeting and which
difficulty levels are appropriate for which objects for this
audience.

Now, voted DL is a separate thing, and I think we should implement
generic voting mechanism, not just "voting for DL".


Anatoly Volynets wrote:
> There was not consensus, because I did not agree. It looks barely usable
> this way.
>
> sergey@total-knowledge.com wrote:
>
>> I sow that in Ilya's message in Difficulty Level topic. See below
>>
>> --------------
>>
>>
>>>> 2. This same UMO DL in the course or among courses by the same Author,
>>>> set by the Author.
>>>>
>>>>
>>
>>
>>> It seems that common consensus is that object DL should be bound to
>>> course. I guess
>>> we'll go with it then.
>>>
>>>
>>
>>
>>> --
>>> Ilya A. Volynets-Evenbakh
>>> Total Knowledge. CTO
>>> http://www.total-knowledge.com
>>>
>>>
>>>
>>>
>> ---------------
>>
>>
>>
>>
>>> I don't remember that agreement, but I need two part difficulty level
>>> (one part set for Repository by community, another  set within the
>>> course or between courses of this author by this author) as I described
>>> it.
>>>
>>>
>> I was talking about Author's part of difficulty level in DB schema, not
>> Repository's.
>>
>>
>>
>>> sergey@total-knowledge.com wrote:
>>>
>>>
>>>> If i understood it correctly, we agreed that difficulty level should be
>>>> bound to a Course. Imho it's reflected in the latest DB schema.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> I have added study_course, study_course_acl, and study_course_payment
>>>>> to
>>>>> support our discussion results.
>>>>> However - I'm not really sure if the relation between topic (TLT) and
>>>>> study_course is right. Currently, top-level-topic owns course. The
>>>>> alternative is - course owns all the topics inside.
>>>>> Also, I'm not sure yet how to control access to payments.
>>>>>
>>>>> 2006/12/14, sergey@total-knowledge.com <sergey@total-knowledge.com>:
>>>>>
>>>>>
>>>>>
>>>>>>>>> 3. Assign Course or any other UMO within a Course to a Student.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> What that means? Recommendation or administration? If latter - see
>>>>>>>> above.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> I'd like to know that too :)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> For example, assign a Problem to a Student
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>> 4. Set grades(ratings) to a Student.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> Same story. We don't have grades in specs.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> We do have some ideas at least as far as grading problem solving
>>>>>>> goes.
>>>>>>> Most of it is automatic, but at least some is human-controlled. I
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> don't
>>>>>>
>>>>>>
>>>>>>
>>>>>>> care too much about grading abilities, but we'll need it eventually.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> We
>>>>>>
>>>>>>
>>>>>>
>>>>>>> need better definition though. Or at least some definition, since
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> there
>>>>>>
>>>>>>
>>>>>>
>>>>>>> really isn't anything specific in the spec.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>> 5. Assign Students to certain difficulty levels within a
>>>>>>>>> Course.(Student
>>>>>>>>> will be able to see only UMOs of certain difficulty level)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> All the same. It is all for student's discretion as of today.  We
>>>>>>>> can
>>>>>>>> probably think about some specific channels where students can find
>>>>>>>> recommendations not from teacher only. I am not sure there is need
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>> for
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> this. We can discuss it though.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> 6. Ability to change any UMO difficulty level within a Course(No
>>>>>>>>> new
>>>>>>>>> version should be created)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> np
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> No. Difficulty levels are author's responsibility.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>> 7. Sets the price for a Course
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> It is necessary feature. I believe we have it in specs.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> Teacher or Author?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> Teacher sets the price, students buy it. Author? I don't know how
>>>>>> authors
>>>>>> make money, maybe teachers buy courses from authors then sell it to
>>>>>> students? No need to teach anything, just make a couple of
>>>>>> transactions.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>> 8. Chooses his prefered language(s) for the Course from the list of
>>>>>>>>> available languages for this Course.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>> Preferred for what? Expand on this please.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> I mean his language(pl_preferred_language column in person_list
>>>>>> table).
>>>>>> Course may have several languages available, Author selects the one he
>>>>>> speaks. You don't want, for example, students send an Author problems
>>>>>> solutions in language different from the one he speaks.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>> 9. Ability to hide(not update) from Student certain UMOs in the
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>> Course
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>> that he teaches.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> Don't need it. Actually, there is one more issue here postponed for
>>>>>>>> future versions: work flow. It relates to administration, but not
>>>>>>>> entirely.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> --
>>>>>>> Ilya A. Volynets-Evenbakh
>>>>>>> Total Knowledge. CTO
>>>>>>> http://www.total-knowledge.com
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>> --
>>>>> Alexey Parshin,
>>>>> http://www.sptk.net
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>> --
>>>
>>> Anatoly Volynets, Co-Founder
>>> total-knowledge.com
>>> culturedialogue.org
>>>
>>>
>>>
>>>
>>
>>
>
>

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

-- 
Alexey Parshin,
http://www.sptk.net