Re: First portion of data structure to start from

[Anatoly Volynets <av@total-knowledge.com>]

Alexey Parshin wrote:

> Please, consider this structure as a proposition and not as a statement.

I surely got it this way, don't worry!

> 2006/4/30, Anatoly Volynets <av@total-knowledge.com 
> <mailto:av@total-knowledge.com>>:
>
>     Now, I want some clarifications:
>
>     Person to Course relation:
>       Type: many to many ------ means many people can relate to the same
>     course, while a person can relate to many courses
>       Fields:
>         type (student/apprentice/author) ----- so these are fields of the
>     intermediate table?
>
>
> 1) Yes 2) No, these are the possible values for the field "type" 
> (assumed the referrence to some table of three or more rows)
>  
>
>     BTW, I am not sure, I remember what exactly an apprentice is here? A
>     co-author or teacher with some limited rights or a student with some
>     expanded duties (makes sense if we talk about a group of
>     students)? Any
>     suggestions? 
>
>
> IMHO,  an apprentice is a trusted student, with some extra rights/duties.
I believe we do not need Aprentice. I think it used to be just another 
name for student.

>     Topic to Required Topics relation:
>       Type: one to many ----------- means a topic can be optional or
>     mandatory? We have related issue in specs: prerequisites for a topic,
>     but it seems to be much complicated. There can be many
>     topics/courses/texts/problems/tests/games/other objects
>     pre-required for
>     the given topic, or course,  or  problem, or  game, or....  Thus we
>     need  to  provide  one-to-many prerequisite-relation for an object
>     in a
>     course to objects from Repository (I start to think)?
>
>
> Means - a topic may require an optional list of other topics. And yes, 
> this is one of the required relations, probably the most important. It 
> means - the person can't start topic if he/she didn't complete the 
> required topics.

We do not have it in specs and I think now, we need some more generic 
relation - see my previous note (some kind of object-objects 
one-to-many). I'll put it in specs. Let me make up my mind :)

>     Keyword to Topic relation
>       Type: one to many
>       Fields:
>         keyword
>
>     One keyword an be used in many topics, courses and so forth, while
>     many
>     keywords can be used in a course, topic, explanation, etc. So it is
>     many-to-many and involves many objects, not only topics.
>
> Yes, however if we do it this way - we have more complicated structure 
> with not so much of the gain. It may be done both ways, with some pros 
> and cons.


Well, many keywords for an object - is plain reality. Having many 
objects for a keyword makes it possible keyword-based search. Am I right?

>     Explanation to Topic relation
>       Type: one to many ---- if one-to-many, then Topic to Explanation:
>     there supposed to be many explanations for a topic
>
>     Explanation to Person relation - I'm not sure we need this at all
>       Type: one to many
>
>     Explanation
>       Fields:
>         name,
>         reference to source, ---- Why we need this? If an author refers
>     students to a text from Repository instead of writing his own text
>     (next
>     field)? I think this situation does not differ from usage of other
>     objects.
>         text
>
>
> Don't you want to know - where (from outside) this text came from? The 
> Bible, a book, etc.. It's optional.

As I said - in this case an object "explanation" is originated from 
another object "text" and as such  have to bear  the "origin stamp".  
OTOH, normally, explanation is a regular text, written by its author for 
this course. If there are just regular references like in a regular 
book, we have to think how to put them there. Probably, plain web-links 
to outside-uu sources?

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



--

Anatoly Volynets, Co-Founder
total-knowledge.com
culturedialogue.org