Re:

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

A question, before I start implementing this structure. We agreed that difficulty level doesn't affect access to UMO. So, from any standpoint, it is just a number on the screen. Implementing this number, however, requires the vote counter and average vote. This, in turn, requires a table per UMO type. Now, the question:

Does implementing a community difficulty level worth implementing 5..7 tables plus corresponding stored procs?

I can, of course, make an economy class implementation - all UMO' votes in the single table (victimize the data integrity).. But still? I'm starting after your command.

2006/12/16, Anatoly Volynets <av@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.

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

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