Re: Teachers

[sergey@total-knowledge.com]

Let me clarify.
TLT may have different sets of subtopics based on difficulty level, since,
as we agreed finally, that difficulty level will be bound to a TLT.
Please take a look at this page:
http://gateway.total-knowledge.com/~sergey/UU/CourseView1.html
User can choose dificulty level from dropdown and see different list of
subtopics that linked to the chosen difficulty level. It may look
different on UI in life version, but the idea is the same.
I may be wrong, but I can't see how this functionality handled in your DB
schema. Am I missing something?


> Well, I meant TLT, not a Course as an administrative unit.
> I may miss something in your schema, but imho you should have something
> like topic_to_tlt relation table containing "difficulty" column that has
> relation with difficulty_level table in similar way as it's orginized for
> problems, for example.
> Regarding the name, I think it maybe changed since users can study course,
> not UMO Course.
>
>
>> I'm not sure if we are talking of the same thing. Study_course is an
>> administrative object, currently for course-wide permissions and
>> payments.
>> It refers to top-level-topic (TLT) that is a course. Now, TLT has the
>> difficulty level, content, etc.. May be, study_course isn't the best
>> name
>> for the object?
>>
>> 2006/12/16, sergey@total-knowledge.com <sergey@total-knowledge.com>:
>>>
>>> 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
>>> >
>>>
>>>
>>>
>>
>>
>> --
>> Alexey Parshin,
>> http://www.sptk.net
>>
>
>
>