array(1) { [0]=> string(108) "
  • [[#cite_ref-0|↑]] This has nothing to do with parent-child relationships of UMOs
    • " } UU - Total Knowledge
    Total Knowledge Projects Jobs Clientele Contact

    UU

    Personal tools
    From Total Knowledge
    (Difference between revisions)
    Jump to: navigation, search
    (→Required Properties for Creation)
    Current revision (00:57, 13 October 2015) (view source)
    m (→Business Assumptions)
     
    (41 intermediate revisions not shown.)
    Line 7: Line 7:
    == The Goal ==
    == The Goal ==
    -
    UU (Universe University) aims to answer essential and the most pressing challenges to modern education. Nowadays, the core demand to educational systems is to provide for development of independent and critical thinking, creativity and responsibility. These goals surely sound good for anybody but real construction and technology of the modern schools go back to the 17th century and aim to informing and skills' training only. All the rest is up to a teacher. However, these up-to-a-teacher features, despite being in major demand, cannot normally work against the entire system. They either get swallowed by the system and simply turned into yet other forms of informing and training, or they bounce against the wall, break up and get thrown out. No other outcome of educational reforms and innovation could be observed since 19th century in any part of the world. Hence, our understanding is that modern school has to be wholly reconstructed so that the entire system would aim directly to bringing up independent and critical thinking, creativity and responsibility. We believe that in the course of such an educational process information and skills, or generally speaking, knowledge of traditional type will be acquired as a side effect and in a much higher degree.
    		+
    Universe University (UU) aims to address the core demand to the modern education: development of independent and critical thinking, creativity and responsibility. However, the general technology of the contemporary schools go back to the 17th century and is directed to informing and skills' training only. That is so for the more than 300 years, while critical thinking is mostly up to a teacher, or better say, up to a good teacher. The question is whether personal efforts of a teacher to provide for creativity development and general educational technology to inform can work in concert?
    -
    == Dialogue as Educational Principle ==
    		+
    First, knowledge and creativity as such are not one and the same. They can relate in one process and go away in another. Let's see how that works in the history and philosophy of the existing school:
     +
    <UL>
     +
    <LI>The most general idea the contemporary western school is based on interprets knowledge as the absolute objective truth.</LI>
     +
    <LI>This kind of knowledge, just by definition, requires only accurate transmission by a teacher (objectively put in position of passive transmitter) to a class (objectively put in position of passive receivers).</LI>
     +
    <LI>That infers an idea of lesson, a portion of knowledge to be presented, which is determined by certain period of time.</LI>
     +
    <LI>That infers and idea of class as group of students the lesson to be presented to simultaneously.</LI>
     +
    <LI>The entire construction is a conveyor to drug a class through a course with predetermined speed. Since students are of different abilities the conveyor must mark each by the level of ones´ achievement at special moments. This is done by grading systems.</LI>
     +
    <LI>That, in turn, shifts subjective goal of a student from knowledge to a grade itself.</LI>
     +
    <LI>Which, in turn, pushes their teacher to shift focus from knowledge as such to grading students.</LI>
     +
    </UL>
     +
    It is noteworthy that in above described mechanism all elements are logical. They fit the fundamental understanding of knowledge and one another! The above described construction is essentially the same for the great majority of mainstream schools worldwide. They may differ in details but not in essence.
    -
    Independent and critical thinking, creativity and responsibility are all theoretically and phenomenologically based on dialogue: Dialogue as inner speech ("Thinking is the quiet talking of the soul to itself," Plato) and as free communication between humans. That is why dialogue is the central idea and the core feature to be provided by UU. Some specific UU and also common, elsewhere developed features providing for dialogue to be utilized:
    		+
    It is evident that objectively this construction and corresponding technology do not promote development of independent and critical thinking, creativity and responsibility. These could be, as we mentioned before, provided by a teacher, individually.
     +
    However, those up-to-a-teacher features, despite being in major demand, cannot normally work against the entire system. They can only work despite the system, against it. Worldwide experience for centuries tells us the same story all over: Educational innovations either get swallowed by the school, digested and turned into yet other forms of informing and training, or they bounce against the wall, break up and get thrown out. No other outcome of educational reforms and innovations could be observed since 19th century in any part of the world.
    -
    === The common ones: ===
    		+
    Hence, our understanding is that modern school has to be wholly reconstructed bottom up, so that the entire system would aim directly to bringing up independent and critical thinking, creativity and responsibility. Moreover, we believe that in such a school, knowledge will be acquired along and it will be acquired willingly, deeper and more intensively than within any current system.
     +
     
     +
    == Dialogue As Educational Principle ==
     +
     
     +
    There are several fundamental ideas a new school can be built on. The most promising, in our view, is dialogue. Dialogue theoretically and in practice proves to be a foundation for independent and critical thinking, creativity and responsibility.
     +
     
     +
    There are two "modes" of dialogue: dialogue as inner speech, which actually is thinking (Plato: "thought is the silent and inner conversation of the soul with itself") and dialogue  as free communication between humans.
     +
     
     +
    In short, that works as follows: If someone has to explain something not understood by another one, that requires to find a way to overcome misunderstanding which infers creativity.
     +
     
     +
    The creativity is also needed for the listener, who is trying to understand. If the listener is not just to remember what is explained but to understand, that requires to recreate the subject anew.
     +
     
     +
    Creativity, in turn, requires answers to not-so-evident questions, that is, requires independent thinking. One pulls another in. And if we make a step back to the goal of the conversation when I, who tries to explain something, need to understand what exactly you do not understand in my explanation, we already in the realm of critical thinking.
     +
     
     +
    What about responsibility? It is also here because if I am looking for the right argumentation that means I took upon myself responsibility for it. Another face of responsibility shows up in the very beginning, it is for my interlocutor. If I haven't taken the responsibility for her I would not even started talking! Remember, we discuss free communication.
     +
     
     +
    All that said easily translates from discussion to thinking. In thinking I am responsible for myself to move from hypothesis to certainty, from fantasy to idea, from opinion to understanding. I need to be creative to come up with  these starting points and very critical about them and myself so that not to be satisfied with opinions, fantasies and hypotheses but proceed to understanding of the truth and reality.
     +
     
     +
    That is why we take dialogue as the central idea and the core feature of UU.
     +
    In order to provide that we develop several unique features and are going to utilize many available tools developed by others and useful to this effect.
     +
     
     +
    === The common features ===
    <UL>
    <UL>
    -
    <LI>A system of communication protocols in UMO (User Manageable Object, see below) studies or development.</LI>
    		+
    <LI>A set of communication protocols to be used in development and studies of User Manageable Objects (UMO, see below).</LI>
    -
    <LI>Overall open source type of the courses and other educational units created within UU framework.</LI>
    		+
    <LI>Overall open source type of the UMOs, including courses and other educational units created within UU framework.</LI>
    -
    <LI>Various feedback tools on courses, single topics, problems, problem solutions, authors, and so forth.</LI>
    		+
    <LI>System features to provide collaborative UMO creation and studies.</LI>
     +
    <LI>Rich feedback environment</LI>
    </UL>
    </UL>
    -
    === The specific ones: ===
    		+
    === The unique features ===
    <UL>
    <UL>
    -
    <LI>An UMO Explanation for a Topic. Unlimited number of Explanations can be created in parallel, that is, an author may use different explanations, including those, which contradict one another. Such an approach is traditionally seen unacceptable. In our view,  on the contrary, dramatically different explanations of the same subject provoke questions and doubts and lead to independent thinking. This feature can also be used for explanations on different levels of generalization. This feature allows to bring dialogue into traditionally hierarchical courses.</LI>
    		+
    <LI>An UMO Explanation. Unlimited number of Explanations can be  
    -
    <LI>An UMO Juxtaposition. This object is to join other UMOs based on relationships between ideas, such contradiction, complementation, similarity, discrepancy, etc.</LI>
    		+
    created in parallel, that is, an author may use different explanations,  
    -
    <LI>An UMO Technology reflects certain understanding of an educational process and school construction as a whole. That presupposes development of a unique educational systems and hence brings forward the idea of dialogue in the entire educational environment. Technology adds specific features to default UMOs.</LI>
    		+
    including those, which contradict one another. Such an approach is traditionally  
    -
    <LI>System features to provide collaborative UMO creation and studies.</LI>
    		+
    seen unacceptable. In our view,  on the contrary, dramatically different  
     +
    explanations of the same subject provoke questions and doubts and lead to  
     +
    independent thinking. UMO Explanation allows to bring dialogue into
     +
    traditionally hierarchical courses. This UMO can also be used for explanations on  
     +
    different levels of generalization.</LI>
     +
    <LI>An UMO Juxtaposition. This object is to put together other UMOs based on  
     +
    relationships between ideas, such as contradiction, complementarity, similarity,  
     +
    discrepancy, etc.</LI>
     +
    <LI>An UMO Technology reflects certain understanding of an educational process  
     +
    and school construction as a whole. That presupposes development of a unique  
     +
    educational systems and hence brings forward the idea of dialogue in the entire  
     +
    educational environment. Technology adds specific features to default UMOs.</LI>
     +
    </UL>
     +
     
     +
    == A few particular goals in works ==
     +
    Beside many UU features we want to emphasize the following in respect of the ideas of the dialogue and whole educational technology:
     +
    <UL>
     +
    <LI>Plain promotion of those ideas. Wherein, the dialogue is to be promoted in two aspects: First, a specific school based on dialogue entirely; Second, dialogue in entire educational system as a social institution</LI>
     +
    <LI>Tools to support schools oriented on the above ideas</LI>
     +
    <LI>Tools to support virtual dialogical courses</LI>
     +
    <LI>Tools to add dialogical features to other educational units</LI>
    </UL>
    </UL>
    Line 72: Line 125:
    == General Features ==
    == General Features ==
    === Required Properties ===
    === Required Properties ===
    -
     
    		+
    To be created an UMO requires the following properties:
    -
    <OL type="a">To be created an UMO requires the following properties:
    		+
    <OL type="a">
    -
    <LI>title</LI>
    		+
    <LI>Title</LI>
    -
    <LI>subject</LI>
    		+
    <LI>Subject</LI>
    -
    <LI>author(s).  In case the author is unknown, the Public is set as the author and presenter is required</LI>
    		+
    <LI>Author(s).  In case the author is unknown, the Public is set as the author and presenter is required</LI>
    -
    <LI>a child UMO and its presenter, if required</LI>
    		+
    <LI>A child UMO and its presenter, if required</LI>
    -
    <LI>type</LI>
    		+
    <LI>Type</LI>
    -
    <LI>date of creation. The creation date, type, and author are set when an UMO is created and never change, unless a dispute of authorship arises. In this case UU instance administrative board sets the authors as following: <Author 1 in dispute with Author 2></LI>
    		+
    <LI>Date of creation. The creation date, type, and author are set when an UMO is created and never change, unless a dispute of authorship arises. In this case UU instance administrative board sets the authors as following: <Author 1 in dispute with Author 2></LI>
    -
    <LI>a published UMO has also a date of publication. A publication date is set when UMO is published that locks UMO in the published state.</LI>
    		+
    </OL>
    </OL>
     +
    A published UMO has also a date of publication. A publication date is set when UMO is published that locks UMO in the published state.
    === Optional properties ===
    === Optional properties ===
    <OL type="a">
    <OL type="a">
    -
    <LI>an UMO may or may not have a description</LI>
    		+
    <LI>Description</LI>
    <LI>Custom properties can be created for any UMO for storing some special information that may be represented as pairs of names and values. Every property has a type and a string value. Property type defines property name and a type of UMO the property can be used with. Properties can be used for searching.</LI>
    <LI>Custom properties can be created for any UMO for storing some special information that may be represented as pairs of names and values. Every property has a type and a string value. Property type defines property name and a type of UMO the property can be used with. Properties can be used for searching.</LI>
    <LI>Keywords are made of UMO content title and description. Keywords can be extracted by the system when UMO content is created or modified and added by the author manually. Keywords are indexed to make keyword-based search faster.</LI>
    <LI>Keywords are made of UMO content title and description. Keywords can be extracted by the system when UMO content is created or modified and added by the author manually. Keywords are indexed to make keyword-based search faster.</LI>
    Line 98: Line 151:
    </UL>
    </UL>
    </LI>
    </LI>
    -
    <LI>Rating. An UMO can be rated by users.</LI>
    		+
    <LI>Rating by users.</LI>
    </OL>
    </OL>
    Line 109: Line 162:
    </UL>
    </UL>
    === Stamp of Authenticity ===
    === Stamp of Authenticity ===
    -
    <UL>It says what this object is in terms of authorship:
    		+
    SoA says what this object is in terms of authorship:
    -
    <LI>An original + who is the author or</LI>
    		+
    <UL>
    -
    <LI>One derived from someone's original + who is the author and other info about the original + who is the editor or</LI>
    		+
    <LI>That the UMO is original + who is the author or</LI>
    -
    <LI>A borrowed object + who is the author and other info about the original</LI>
    		+
    <LI>The UMO is derived from someone's original + who is the author and other info about the original + who is the editor or</LI>
     +
    <LI>The UMO is borrowed object + who is the author and other info about the original</LI>
    </UL>
    </UL>
    It includes the time stamps of its creation and publication if it is published.
    It includes the time stamps of its creation and publication if it is published.
    Line 185: Line 239:
    This feature may be used to provide:
    This feature may be used to provide:
    -
    * Any number of short or detailed explanations, so that a student could use that one he needs.  
    		+
    * Any number of short or detailed explanations, so that a student could use one he needs.  
    -
    * Different approaches for the same subject to provoke dialogue between students and critical thinking.
    		+
    * Different approaches for the same subject to provoke critical thinking and dialogue between students.
    === Required Properties for Creation ===
    === Required Properties for Creation ===
    Line 257: Line 311:
    == Work Flow ==
    == Work Flow ==
    -
    There must be an ability for an author to implement some educational scenarios comprising instructions or procedures to folow by a student or group of students. It can be based on different psychological foundations and / or the author's experience. [It is specific type of UMO, not to study]
    		+
    There must be an ability for an author to implement some educational scenarios comprising instructions or procedures to folow by a student or group of students. It can be based on different psychological foundations and / or the author's experience.
    === Required Properties for Creation ===
    === Required Properties for Creation ===
    Line 281: Line 335:
    * Test can be attached to any other UMO.
    * Test can be attached to any other UMO.
    -
    == Required Properties ==
    		+
    === Required Properties ===
    * At least one of the following child UMOs supplied:
    * At least one of the following child UMOs supplied:
    ** Problem
    ** Problem
    Line 288: Line 342:
    * Points for "PASSED" grade.
    * Points for "PASSED" grade.
    -
    == Optional Properties ==
    		+
    === Optional Properties ===
    * Test Rules. For example:
    * Test Rules. For example:
    Line 338: Line 392:
    * Description / Rules
    * Description / Rules
    -
    == Through Problems ==
    		 
    -
    An UMO of the course level. They are problems of
    		 
    -
    different level of difficulty, collected on any bases.
    		 
    -
    		 
    -
    === Necessary Features ===
    		 
    -
    		 
    -
    * Author - the person to start the collection.
    		 
    -
    * Basis for collection
    		 
    -
    * Problems in
    		 
    -
    Through Problem can be created if at least one problem is supplied.
    		 
    == Juxtaposition ==
    == Juxtaposition ==
    An UMO of the course level.  It is a collection of different UMOs based on their contents and ideas they implement. Juxtaposition provides a possibility for in depth studying and understanding of fundamentals in any area of human activities. It is more a research than instructional tool. Juxtaposition provides subject for dialogue and provokes it, in the first place, while learning comes in as a side effect.
    An UMO of the course level.  It is a collection of different UMOs based on their contents and ideas they implement. Juxtaposition provides a possibility for in depth studying and understanding of fundamentals in any area of human activities. It is more a research than instructional tool. Juxtaposition provides subject for dialogue and provokes it, in the first place, while learning comes in as a side effect.
    -
    === Required Features ===
    		+
    === Required Properties ===
    *Author(s) - every person contributing to the collection.  
    *Author(s) - every person contributing to the collection.  
    *Basis for collection, that is a non-empty text, a formulation of an idea.
    *Basis for collection, that is a non-empty text, a formulation of an idea.
    Line 391: Line 435:
    A user can create a custom UMO, which cannot be structured, but can have all general UMO features. Custom UMO can be included as a child in any other UMO
    A user can create a custom UMO, which cannot be structured, but can have all general UMO features. Custom UMO can be included as a child in any other UMO
    -
    * Necessary Features
    		+
    === Required Properties ===
    -
    ** Name (Category)
    		+
    * Name
    -
    ** Description
    		+
    * Description
    -
    ** Child UMOs
    		+
    -
    Custom UMO can be created if at least two child UMOs are supplied.
    		+
    = Generic System Functions =
    = Generic System Functions =
    Line 545: Line 587:
    == Structured Shared Repository ==
    == Structured Shared Repository ==
    -
    * Is a very special feature of the UU. It is the repository of all created objects ever.
    		+
    It is the repository of all created objects ever.
    -
    UMO gets automatically from a course into the Repository or can be created specifically for the repository depending on its author.
    		+
    UMO gets automatically from a course into the Repository or can be created specifically for the Repository.
    -
    * A UMO can get in one out of three storages:
    		+
    * The repository consists of three storages:
    ** Featured Storage
    ** Featured Storage
    ** General Storage
    ** General Storage
    ** Disagreement Storage
    ** Disagreement Storage
    -
    === Catalog ===
    		+
    === Catalogue ===
    -
    All of above repositories will be presented to user as catalogues.
    		+
    All of above repositories will be presented to a user as catalogues.
    Catalogues themselves are browse-able tree-like sets of categories <ref>This has nothing to do with parent-child relationships of UMOs</ref> based around
    Catalogues themselves are browse-able tree-like sets of categories <ref>This has nothing to do with parent-child relationships of UMOs</ref> based around
    subject matter and also based on UMO authors.
    subject matter and also based on UMO authors.
    Line 609: Line 651:
    === Featured Storage ===
    === Featured Storage ===
    This is repository of shared objects with high ratings. Formulae for object ratings are TBD.
    This is repository of shared objects with high ratings. Formulae for object ratings are TBD.
    -
    Following categories are available. Each category may have its own separate rating formula.
    		+
    Following categories to be provided, each may having a different rating formula.
    <OL>
    <OL>
    <LI> Classical problems
    <LI> Classical problems
    Line 615: Line 657:
    <LI> Classical texts
    <LI> Classical texts
    <LI> Border line science-to-life problems
    <LI> Border line science-to-life problems
    -
    <LI> Games
    		 
    <LI> Teaching techniques
    <LI> Teaching techniques
    <LI> Work Flow
    <LI> Work Flow
    -
    <LI> Explanation
    		+
    <LI> Faculties
    -
    <LI> Exercise
    		+
    </OL>
    </OL>
    Line 671: Line 711:
    === Possibility to link any unit to any course ===
    === Possibility to link any unit to any course ===
    -
    		 
    -
    (For Open server only)
    		 
    Each entity in course can be included into any other  
    Each entity in course can be included into any other  
    Line 678: Line 716:
    attribution to authors and sources.
    attribution to authors and sources.
    -
    === Tools to make turning multiple courses into one easier ===  
    		+
    === Tools to turn multiple courses into one ===  
    -
     
    		+
    -
    (For Open server only)
    		+
    May include tools for analyzing tree structures, and  
    May include tools for analyzing tree structures, and  
    -
    pointing out similarities to authors, etc.  
    		+
    pointing out similarities to authors, etc.
    === Locking-unlocking for editing ===
    === Locking-unlocking for editing ===
    Line 711: Line 747:
    1. Voting: on courses, problems, authors, messages, etc.
    1. Voting: on courses, problems, authors, messages, etc.
    -
    2. Functional: on people, participating in through subject chess mastership type rating
    		+
    2. Functional: on people, chess mastership type rating
    === General user rate formula ===
    === General user rate formula ===
    Line 761: Line 797:
    == Communication Tools ==
    == Communication Tools ==
    -
    === We intend to use all available Open Source communication tools ===
    		+
    === List of tools, including but not limited to: ===
    -
     
    		+
    -
    === List of tools ===
    		+
    * Blogs
    * Blogs
    Line 776: Line 810:
    * Message Boards
    * Message Boards
    -
    		 
    -
    * Other
    		 
    === Object Rating ===
    === Object Rating ===
    Line 799: Line 831:
    == Statistics/Demographics ==
    == Statistics/Demographics ==
    -
    * Each UMO bears publically accessible statistics of:
    		+
    Each UMO bears publically accessible statistics of:
    1. Visiting
    1. Visiting
    Line 817: Line 849:
    == Group Admin. Tools ==
    == Group Admin. Tools ==
    -
    * This section supposed to be developed (but is not yet) in order for UU to be used by groups and organizations of any type.
    		+
    TBD
    -
    * We need some form, posiibly wiki, to get requests from organizations about this section
    		+
    == Search Engine & Lists ==
    == Search Engine & Lists ==
    Line 850: Line 881:
    = Business Assumptions =
    = Business Assumptions =
    -
    == Open Server ==  
    		+
    == UU is a Software as Service which is supposed to work as an Open Server ==
    <OL>
    <OL>
    Line 870: Line 901:
    == Proprietary Server ==
    == Proprietary Server ==
     +
    * The role of the Proprietary server is in discussion. Our thinking was to contrast two servers in order to prove advantages of the open one. Still, we are not sure we need a proprietary server at all. For the moment it is thought to be as follows:
    -
    * An author can create here a "closed source" course, which means that neither course, nor any of its object can be used by another author.
    		+
    * An author can create here a "closed" course, which means that neither course, nor any of its objects can be used by another author without the creator's permission.
    * The Proprietary Server is a paid service.
    * The Proprietary Server is a paid service.
    -
    * If an author copies a course from the Open Server on the Proprietary one this does not affect in any way the prototype or its usage on the Open Server. All proper attributes are required like in all other cases.
    		+
    * If an author copies a course or any other UMO from the Open Server on the Proprietary one: First, this does not affect in any way the prototype or its usage on the Open Server; Second, all proper attributions to the open prototype are enforced.
    -
     
    		+
    -
    * The same applies to any object created at the Open Server and copied to the Proprietary Server: free usage of the prototype on the Open Server goes on unaffected.
    		+
    -
    * Any object created at the Prprietay Server can be removed by its author at his own discretion.
    		+
    * Any object created at the Proprietary Server can be removed by its author at her own discretion.

    Current revision


    Universe University. Specifications for Web Based Educational Environment

    Contents

    Philosophy

    The Goal

    Universe University (UU) aims to address the core demand to the modern education: development of independent and critical thinking, creativity and responsibility. However, the general technology of the contemporary schools go back to the 17th century and is directed to informing and skills' training only. That is so for the more than 300 years, while critical thinking is mostly up to a teacher, or better say, up to a good teacher. The question is whether personal efforts of a teacher to provide for creativity development and general educational technology to inform can work in concert?

    First, knowledge and creativity as such are not one and the same. They can relate in one process and go away in another. Let's see how that works in the history and philosophy of the existing school:

    • The most general idea the contemporary western school is based on interprets knowledge as the absolute objective truth.
    • This kind of knowledge, just by definition, requires only accurate transmission by a teacher (objectively put in position of passive transmitter) to a class (objectively put in position of passive receivers).
    • That infers an idea of lesson, a portion of knowledge to be presented, which is determined by certain period of time.
    • That infers and idea of class as group of students the lesson to be presented to simultaneously.
    • The entire construction is a conveyor to drug a class through a course with predetermined speed. Since students are of different abilities the conveyor must mark each by the level of ones´ achievement at special moments. This is done by grading systems.
    • That, in turn, shifts subjective goal of a student from knowledge to a grade itself.
    • Which, in turn, pushes their teacher to shift focus from knowledge as such to grading students.

    It is noteworthy that in above described mechanism all elements are logical. They fit the fundamental understanding of knowledge and one another! The above described construction is essentially the same for the great majority of mainstream schools worldwide. They may differ in details but not in essence.

    It is evident that objectively this construction and corresponding technology do not promote development of independent and critical thinking, creativity and responsibility. These could be, as we mentioned before, provided by a teacher, individually.

    However, those up-to-a-teacher features, despite being in major demand, cannot normally work against the entire system. They can only work despite the system, against it. Worldwide experience for centuries tells us the same story all over: Educational innovations either get swallowed by the school, digested and turned into yet other forms of informing and training, or they bounce against the wall, break up and get thrown out. No other outcome of educational reforms and innovations could be observed since 19th century in any part of the world.

    Hence, our understanding is that modern school has to be wholly reconstructed bottom up, so that the entire system would aim directly to bringing up independent and critical thinking, creativity and responsibility. Moreover, we believe that in such a school, knowledge will be acquired along and it will be acquired willingly, deeper and more intensively than within any current system.

    Dialogue As Educational Principle

    There are several fundamental ideas a new school can be built on. The most promising, in our view, is dialogue. Dialogue theoretically and in practice proves to be a foundation for independent and critical thinking, creativity and responsibility.

    There are two "modes" of dialogue: dialogue as inner speech, which actually is thinking (Plato: "thought is the silent and inner conversation of the soul with itself") and dialogue as free communication between humans.

    In short, that works as follows: If someone has to explain something not understood by another one, that requires to find a way to overcome misunderstanding which infers creativity.

    The creativity is also needed for the listener, who is trying to understand. If the listener is not just to remember what is explained but to understand, that requires to recreate the subject anew.

    Creativity, in turn, requires answers to not-so-evident questions, that is, requires independent thinking. One pulls another in. And if we make a step back to the goal of the conversation when I, who tries to explain something, need to understand what exactly you do not understand in my explanation, we already in the realm of critical thinking.

    What about responsibility? It is also here because if I am looking for the right argumentation that means I took upon myself responsibility for it. Another face of responsibility shows up in the very beginning, it is for my interlocutor. If I haven't taken the responsibility for her I would not even started talking! Remember, we discuss free communication.

    All that said easily translates from discussion to thinking. In thinking I am responsible for myself to move from hypothesis to certainty, from fantasy to idea, from opinion to understanding. I need to be creative to come up with these starting points and very critical about them and myself so that not to be satisfied with opinions, fantasies and hypotheses but proceed to understanding of the truth and reality.

    That is why we take dialogue as the central idea and the core feature of UU. In order to provide that we develop several unique features and are going to utilize many available tools developed by others and useful to this effect.

    The common features

    • A set of communication protocols to be used in development and studies of User Manageable Objects (UMO, see below).
    • Overall open source type of the UMOs, including courses and other educational units created within UU framework.
    • System features to provide collaborative UMO creation and studies.
    • Rich feedback environment

    The unique features

    • An UMO Explanation. Unlimited number of Explanations can be created in parallel, that is, an author may use different explanations, including those, which contradict one another. Such an approach is traditionally seen unacceptable. In our view, on the contrary, dramatically different explanations of the same subject provoke questions and doubts and lead to independent thinking. UMO Explanation allows to bring dialogue into traditionally hierarchical courses. This UMO can also be used for explanations on different levels of generalization.
    • An UMO Juxtaposition. This object is to put together other UMOs based on relationships between ideas, such as contradiction, complementarity, similarity, discrepancy, etc.
    • An UMO Technology reflects certain understanding of an educational process and school construction as a whole. That presupposes development of a unique educational systems and hence brings forward the idea of dialogue in the entire educational environment. Technology adds specific features to default UMOs.

    A few particular goals in works

    Beside many UU features we want to emphasize the following in respect of the ideas of the dialogue and whole educational technology:

    • Plain promotion of those ideas. Wherein, the dialogue is to be promoted in two aspects: First, a specific school based on dialogue entirely; Second, dialogue in entire educational system as a social institution
    • Tools to support schools oriented on the above ideas
    • Tools to support virtual dialogical courses
    • Tools to add dialogical features to other educational units

    User-UU Interaction Scenarios

    Student

    Self-studying

    • A student, i.e. a registered user finds a course of interest and indicates self-study. In this case the student automatically gets enrolled in default Self-study class and proceeds with studying.
    • A student finds an UMO of interest and indicates self-study. In this case a default course, consisting of the UMO, activated. The rest works as above.

    Mentoring

    • A student finds a course of interest and submits a request for mentoring. One may do a general request for a mentor available or pick a mentor from a list. If a mentor agrees to serve the student a class for the course is created with one student and one teacher.
    • A student finds an UMO of interest and indicates self-study. In this case a default course, consisting of the UMO, activated. The rest works as above.

    Teacher

    Class setting

      A teacher may create class for a course study. It may be:
    1. Open enrollment class, where every registered user can sign up, or
    2. Restricted enrollment, where the teacher determines either
      • Formal policies of enrollment or
      • Personally who is to be taught in the class

    Mentoring

      A teacher may
    • Announce an intention (and be responded) or respond to a request to teach a course one-on-one. In this case a class for two is created.
    • Announce an intention (and be responded) or respond to a request to teach an UMO one-on-one. In this case a course, consisting of the UMO and a class for two is created.

    Author

    • Creates UMOs. Each UMO has a property of Default course, which belongs to the Default class for self-study. The author formally belongs to the Default class teaching college but is not obliged to actually teach.
    • Arranges UMOs in a course, which belongs to the Default self-study class and may be used as a base to create a specific class with actual teaching.

    UMO or User Manageable Object

    UMOs are main building blocks of UU. Courses, Topics, Problems, etc. are all types of UMO. An UMO may include other, child UMOs.

    General Features

    Required Properties

    To be created an UMO requires the following properties:

    1. Title
    2. Subject
    3. Author(s). In case the author is unknown, the Public is set as the author and presenter is required
    4. A child UMO and its presenter, if required
    5. Type
    6. Date of creation. The creation date, type, and author are set when an UMO is created and never change, unless a dispute of authorship arises. In this case UU instance administrative board sets the authors as following: <Author 1 in dispute with Author 2>

    A published UMO has also a date of publication. A publication date is set when UMO is published that locks UMO in the published state.

    Optional properties

    1. Description
    2. Custom properties can be created for any UMO for storing some special information that may be represented as pairs of names and values. Every property has a type and a string value. Property type defines property name and a type of UMO the property can be used with. Properties can be used for searching.
    3. Keywords are made of UMO content title and description. Keywords can be extracted by the system when UMO content is created or modified and added by the author manually. Keywords are indexed to make keyword-based search faster.
    4. Some of the UMO properties, like title, subject and description, may exist in several languages simultaneously. Such properties are stored as content records. When an UMO is created, at least one content record is created to hold title in this UMO default language. There is no limit to a number of content records. Only one content record per language can be created.
    5. Outside References. An UMO can refer a user to outside not UU bound sources.
    6. Statistics
      • Usage in other UMOs
      • Usage by students
      • Usage by authors
      • Usage by teachers
    7. Rating by users.

    Sharing

    Sharing within UU is to provide open source aspect of the environment. That is, different people may participate in UMO construction, bringing in different approaches, stand points, understanding of a subject, and so forth. On the other hand, all UMOs can be used by other authors and teachers for any purposes, given the proper attribution is done (the latter is technically enforced). Authors, who are not inclined to work in cooperation with others, can do it alone.

    • Same object can be used in other UMOs as a child without limitations.
    • Same object can be worked on by multiple users. If an author publishes a UMO, but doesn't want others to develop it further, other users can create the UMO copy and work on it without limitations.
    • Any UMO can be used by a UU registered user for any purposes, including commercial ones, without limitations.

    Stamp of Authenticity

    SoA says what this object is in terms of authorship:

    • That the UMO is original + who is the author or
    • The UMO is derived from someone's original + who is the author and other info about the original + who is the editor or
    • The UMO is borrowed object + who is the author and other info about the original

    It includes the time stamps of its creation and publication if it is published.

    Versioning

    An UMO may exist in several versions. New version is created whenever author publishes new edition of the UMO. In this case existing UMO versions stay. The author can mark new version as minor or major edit. Users of the UMO decide whether to upgrade it or not. When linking objects to each other (e.g. adding a problem to a topic) author decides which version to use. The new version of UMO keeps the original UMO title, content records, administrators and editors groups. The user that creates a new version becomes that version's author.

    UMO Types

    • Course
    • Topic
    • Explanation
    • Problem
    • Faculty
    • Work Flow
    • Test
    • Competition / Contest
    • Homework
    • Exercise
    • Game
    • Juxtaposition
    • Text
    • Technology
    • Custom


    Course

    Course is a UMO which represents collection of other UMOs, and which allows classes to be signed up to it. The only way to study an UMO in UU is to sign up for some class, which is signed up for a course, which contains the said UMO. What if a user wants to study a course by self and thus doesn't want to sign up to existing classes? For that case UU produces a default class for this course, actually invisible for that user. (S)He signs up for self-studies. The "self-studies class" functionally doesn't differ from regular classes. Only human (teacher) controlled problems are not guaranteed to work although UU communication environment makes needed help quite probable. [Actually, we can think of teachers for the default class too. It'd be just opposite direction of relationship: in regular class teacher looks for students, while in the default class a student looks for teachers, volunteering consultants which could differ for different problems]

    Topic

    Topic is main structural object of a course. It allows course authors to organize other UMOs for presentation to students. Topic can contain subtopics, explanations, tests, exercise problems, etc. Basically any UMO except for course can be linked as a child to a topic.

    Required properties

    • Explanations

    A topic can be published if at least one explanation is supplied by the author 

     Each topic can have number of explanations. In this case, each explanation has some
 unique number, which reflects order to show explanations in explanation list for the
 topic. This number (together with difficulty level of explanation) will also affect
 which explanation is shown to a student by default.
 Note that both sequence number and difficulty level of given explanation are
 tied to the topic that includes said explanation, not to explanation itself.

    Optional Features

    • Summary (Annotation)

    Explanation

    An author may write his own explanations or include chunks of classical texts. He may neatly explain some subject, ways of problem solving or make a discourse around a topic, research his subject instead of explaining. A author may make just one explanation for a topic, which is traditional way to build courses. However the app allows to build unlimited number of parallel explanations.

    This feature may be used to provide:

    • Any number of short or detailed explanations, so that a student could use one he needs.
    • Different approaches for the same subject to provoke critical thinking and dialogue between students.

    Required Properties for Creation

    • Title is <Its Topic Title>dot<Specific Explanation Title>
    • Number, starting with 1, incrementing by 1 
     Number is really associated with Topic, not with explanation, as an explanation
 can be shared between different topics.

    Required Properties for Publication

    • Text of the explanation

    Optional Properties

    • References to other explanations of this topic

    Problem

    Required Properties for Creation

    • Problem statement

    Required Properties for Publication

    • Solution
    • Answer
    • A solution control. As of today, 5 solution control methods are considered:

    1. Single Answer 

    Student is presented with a problem statement, and a single one-line field,
where (s)he has to type his answer in. Student's answer should match the correct
answer (match can either be case-sensitive or case-insensitive, and it could be
simple text, or a regexp)

    2. Multiple Choice 

    Student is presented with a problem statement and a set of choices.
Choices can be either radio button set (in case only single answer is
allowed) or a check-box set (in case more then one answer could be
correct). In case of multiple correct answers, problem creator may
specify whether all answers have to be checked for solution to be considered
correct, or if any of them will suffice.

    3. Template 

    Student is presented with a problem statement, and a problem solution
with blanks, which (s)he has to fill in. Each blank should match.

    4. Generator driven full control: 

    a) Semantic Model

    b) Custome/Language Driven Control

    5. Human controlled 

    A student solves a problems and passes the solution in a required form to the teacher
that, in turn, passes comments to the student.
    • Level of dificulty

    It is a number, starting with 1, incrementing by 1, but can go in opposite direction as well: 0, -1, etc.

    Optional Properties

    • Required time to solve
    • Grades or Points assigned to solution

    Faculty

    Required Properties

    • Name

    Optional Properties

    • Description
    • Basis

    Work Flow

    There must be an ability for an author to implement some educational scenarios comprising instructions or procedures to folow by a student or group of students. It can be based on different psychological foundations and / or the author's experience.

    Required Properties for Creation

    • A form of implementation. As of today 4 forms of implementation are considered:
    1. A flow-chart or
    2. Pseudocode, consisting of sequences, choices and cycles of actions to do or
    3. A set of rules
    4. A lose sequence of UMOs where:
        • An UMO can say which other UMO are prerequisites to study or exercise this one.
        • An UMO can specify possibilities for further studies.
        • An UMO completion by a student may be determined by certain described conditions.
    5. A type of control. As of today 2 types of control are considered:
        • Enforced control when an order of UMOs offered is not controlled by students.
        • Self-control by a student or group of students to follow.

    Test

    • Test can be attached to any other UMO.

    Required Properties

    • At least one of the following child UMOs supplied:
      • Problem
      • Exercise
      • Game
    • Points for "PASSED" grade.

    Optional Properties

    • Test Rules. For example:

    5 randomly generated problems would represent a particular test. For test problems only time allowed should be specified. "PASSED" or "NON PASSED" grade should be assigned. Points for "PASSED" grade should be specified for each test. In order to get "PASSED" grade 6 times allowed to take a test. The rate score ( RT ) should be assigned to each student after successful completion of test. (based on the time deduction principle, 10 sec = 1 point) RT is a function of only time specified for the test. In the case a student has RT not equal to zero, the system will let him/her to solve the general problems to improve their regular rating.( but only within this particular topic)

    Competition / Contest

    A competition can be set on any collection of UMOs.

    Required Properties

    • Type of Competition in Terms of Time:
    1. Continuous (e.g. problem of the day)
    2. Real time
    3. Long term rating (e.g. chess style mastership)
    • Types of Competition in Terms of Participants:
    1. Competitors of the same type (individuals, classes, schools, etc.)
    2. Competitors of mixed types (say, an idividual challenges a research lab)
    • Rules

    Homework

    Required Properties

    • A Number, starting with 1, incrementing by 1 for this Topic.
    • A Title, which is the <Topic Title>.<Number>
    • General task. Non-empty text describing the task.
    • An UMO. A homework can be created and published if at least one UMO supplied.

    Optional Properties

    • Date HW is assigned
    • Date HW must be submitted
    • Grades assigned to HW

    Exercise / Games

    A game or exercise may be included by the author in the course or topic for different reasons. It is not controlled in any way.

    Required Properties

    • Description / Rules


    Juxtaposition

    An UMO of the course level. It is a collection of different UMOs based on their contents and ideas they implement. Juxtaposition provides a possibility for in depth studying and understanding of fundamentals in any area of human activities. It is more a research than instructional tool. Juxtaposition provides subject for dialogue and provokes it, in the first place, while learning comes in as a side effect.

    Required Properties

    • Author(s) - every person contributing to the collection.
    • Basis for collection, that is a non-empty text, a formulation of an idea.
    • Child UMOs, at least two.
    • A set of Points, at least two, one for each Child. A Point is also non-empty text referring in any way to a Child content.
    • Their Relationship. It is a non-empty text that explains the relationship between children, such as:
      • Contradicts
      • Develops
      • Complements
      • Repeats
      • Mocks
      • Etc.

    The Points and Relationship technically forced into a syllogism like structure: <Point 1> & <Point 2> => Relationship.

    Text

    A piece of text.

    Required properties

    • Text body

    Technology

    Required Properties for Creation

    • Basic Idea. A non-empty text, formulation of the basic educational idea.
    • A Child UMO Types. This can be type of any UMO specified in UU. At least two UMO types are needed for Technology creation.
    • Relationship General–between Basic Idea and a Child UMO Type. Non-empty text consisting of two points:
    1. Specifics of this UMO type within the technology
    2. Logical relationship between the Basic Idea and the UMO type. One General Relationship per UMO type is needed.
    3. Relationship Specific–between two Child UMOs. Non-empty text describing logical relationship between the UMOs.

    Required Properties for Publication

    • A technology can be published after all default UMO Types developed accordingly.

    Custom UMO

    A user can create a custom UMO, which cannot be structured, but can have all general UMO features. Custom UMO can be included as a child in any other UMO

    Required Properties

    • Name
    • Description

    Generic System Functions

    Localization

    Universe University has to be accessible and functional on different languages. There are two important aspects of localization to consider

    • Localization of user interface
    • Localization of content

    Locality to use when rendering objects and UI to users will be negotiatable using standard HTTP content-negotiation protocol, but will be forcable through personal user settings.

    User Interface Localization

    We will (probably) use gettext system for translations. .po files will be (as everything else in our Open Source application) pubic, and translations will be contributed by interested users.

    Content Translations

    There will be special role: "translator". This person will be listed as such for given object (along side with authors). Translator will have full editorial access to translations of object for his language, but will have no administrative rights. There will be standard set of tools for creating and editing tranlations of object.

    Definitions

    • Translation of an object is translation of text of all core object data into a given language. Specifically, that does not include any dependant objects.
    • Main object language is language in which original object is written, and in which new versions can be created.

    Translation vs. Versioning

    Object tranlation does not constitute a separate version. When translations are added/removed/editied, they are implied to be a minor edit. Translations will have their separate "publish" flag though, to avoid making an unfinished translations visible, when working on an object which main language was already published.

    Editing Translations

    When editing a translation, a separate, temporary copy is created, and that copy is the one that work is being done on. It can be saved across editing sessions. Once it's ready, translator will "publish" it, at which time this copy will replace any existing translation for given version of given object in given language.

    Policies

    A Host of an instance of the Universe University has tools to develop and enforce certain policies regarding contents and other features of courses and other objects created and offered to the general public at the Hosts' servers.

    UMO Access System

    ACL Group

    Access to objects in UU is granted to "ACL Groups". ACL Groups is just a group of users. Membership in ACL groups is controlled differently, depending on what the group is used for.

    Class

    Class is a special object, which is used to give users ability to study courses. Class itself doesn't support versions. It has three groups associated with it:

    • Administrators
    • Teachers
    • Students

    When class is signed up for a course, class'es "Students" group gets Study access to the whole course UMO structure (that is all subtopics, explanations, problems, etc.). In order to pass the class, a student must pass all the UMOs that class is connected to.

    Access Types

    Different groups may be granted different permissions on different UMOs.

    Edit

    Members of a group with EDIT access to an UMO can perform following actions:

    • Create new versions of the UMO
    • Modify unpublished versions
    • Link other UMOs as children
    • Publish UMO

    Translate

    Members of a group with TRANSLATE access to an UMO can create new translations for that UMO, as long as version in unpublished state exists.

    View

    Members of a group with VIEW access to a UMO can get a preview of the UMO. What is displayed depends on type of the UMO.

    • #Course and #Topic will show up with tile and annotation (and possibly list of child objects)
    • #Problem will show title and (possibly) problem statement
    • #Explanation will show ... well... Explanation...

    Teach

    Members of a group with TEACH access to a classe can "teach" it. This means following actions are allowed:

    • Has access to check class' students' solutions of "human-controlled" problems
    • Marked as a teacher on all course-related communication tools.
    • Marking someone as teacher, automatically grants them moderator power

    in all course-related communication tools for this class.

    Administer Class

    Members of a group with ADMIN access to a class can perform following actions:

    • Add more class admins
    • Add users to the class' teachers group
    • Control how students are signed up for the class
    • Manually sign up students to the class

    Study

    Members of a group with STUDY access to a #Class can have following properties:

    • can "Study" any UMO which belongs to courses which the class is signed up for
    • are marked as students in all class-related communication tools

    Authorship

    Authorship and appropriate credit concepts are extremely important. UU handles it in the following way: Each UMO has authorship info associated with it. By default author list is comprised of all people who made any modifications to an UMO. However, in some cases it is not the right thing. For example, someone may decide to publish someone elses text book as a course on UU. In such case the published is [b]not[/b] the author. To accomodate this, UU allows UMO administrator to specify author list manually (once it's done, author list has to be kept up to date by hand).

    There is still access to lists of app people who did modifications to UMO, as well as separate lists for translators.

    In addition, there will be "history" page, which shows UMO modification history, along with contributors to each modification.

    Payment

    a) An author can set up payment for a students on per course basis with a drop-off grace period. b) In this case the author has choice of payment to UU either

    • Flat rate per course, or
    • Flate rate per student, or
    • Commissions

    c) No other transactions (except for sponsorship) are possible respecting Open Server

    d) Flate rate service charge is added to any author on Proprietary Server

    Variants for subscription management

    • Regular Revisions (say every 6 mo)
    • Price, picked by subscriber

    Structured Shared Repository

    It is the repository of all created objects ever. UMO gets automatically from a course into the Repository or can be created specifically for the Repository.

    • The repository consists of three storages:
      • Featured Storage
      • General Storage
      • Disagreement Storage

    Catalogue

    All of above repositories will be presented to a user as catalogues. Catalogues themselves are browse-able tree-like sets of categories [1] based around subject matter and also based on UMO authors. While browsing, user is allowed to filter out visible objects based on following criteria:

    • Available translations
    • UMO types
    • Ratings (TBD)
    • Creation time
    • Last update time

    User will also be able to specify any combination of the following sort criteria (both increasing and decreasing):

    • Alphabetical topic
    • UMO types
    • Rating
    • Creation time
    • Last update time

    Catalogue Administration

    Administration of catalogue categories is performed by users from a special "catalogue administrators" groups. Each category in catalogue has such an administrative group associated with it. Members of group controlling higher-level category are automatically allowed to any category in the sub-tree.

    Example: 

    Math (user1)
 |
 +-Algebra (user2)
 +-Geometry (user3)
    • user1 will be able to administer any of listed categories.
    • user2 will have only access to Algebra
    • user3 - only to Geometry

    Following administrative tasks will be allowed:

    • Hide category from catalogue 
    This will hide the category from catalogue and from UMO author UIs for association of UMO with categories. Any sub-categories of the hidden category are also hidden, recursively.
    • Unhide hidden category. 
    Any sub-categories are also unhidden, recursively.
    • Remove UMO from category 
    This one is for moderating categories (e.g. if UMO is being spammed to too manu
categories in catalog, which it doesn't belong to)
    • Search UMOs by category or combinations of categories. 
    Category search by the parent category also includes any sub-categories for this category.
For instance, in the example above, search results for search by the category Math would also include UMOs from Algebra and Geometry categories.

    There will also be an external tool (probably command-line) for permanent removal of categories from the database. It's intended for use by UU instance administrators, in cases where a category was created erroneously.

    1. ↑ This has nothing to do with parent-child relationships of UMOs

    Featured Storage

    This is repository of shared objects with high ratings. Formulae for object ratings are TBD. Following categories to be provided, each may having a different rating formula.

    1. Classical problems
    2. Border line subject-to-subject problems
    3. Classical texts
    4. Border line science-to-life problems
    5. Teaching techniques
    6. Work Flow
    7. Faculties

    General Storage

    Items from the General Storage move up into the Featured storage by getting rated.

    Disagreement Storage

    Stores submissions disapproved by the Masters Board

    Masters Board

    It is a wikipedia-type board comprised from authors and experts to determine where a UMO belongs. Reviews automated submissions and special submissions.

    Problem Generator

    Problem Control Tools

    • Single Answer
    • Multiple Choice
    • Template
    • Semantic Model
    • Custome/Language Driven Control

    Editing Tools

    Templates

    • Templates exist for any UMO development and described in the Page Flow section
    • Developing directions (links)
    • More complex/hard to guess problems (links)
    • Easier problems (links)
    • Off topic gigs (links)
    • Images, diagrams, charts, other graphics
    • Videos
    • Sound

    Possibility to link any unit to any course

    Each entity in course can be included into any other course or linked to some other places, subject to attribution to authors and sources.

    Tools to turn multiple courses into one

    May include tools for analyzing tree structures, and pointing out similarities to authors, etc.

    Locking-unlocking for editing

    Simple features to make sure no conflicts are created during simultaneous work on courses.

    Object versioning

    Every object will have versioning history. Version is created every time an author indicates that this text is ready for inclusion. Until that time any changes are saved, but are not visible to anyone but authors.

    Other users of the object get notified the object has changed. They can choose to upgrade the object or leave it as is.

    If a user of a object edits the object or builds a new one upon the used one it is up to this user to consider himself an author or an editor. In any case everyone using the original object gets notified and the new or edited object bears its history: which object it is built upon.

    References to external sources

    Rating System

    Types

    1. Voting: on courses, problems, authors, messages, etc.

    2. Functional: on people, chess mastership type rating

    General user rate formula

    It is a function of:

    1. Fact of growing

    2. Level of difficulty of problems

    3. Frequency of participation

    4. A single problem solving time

    5. Rating of courses taken

    6. Other factors

    Specific user rate formula

    It is a function of:

    1. Should be around 50 for every topic in the course.

    2. Points for the problem - N (m, k, l, p), where m - the level of the course ( 0 < m < 3); k - the number of the theme within the course; l - the level of the problem ( 0 < l < 4 ); p - the number of the problem within the course ( 0 < p < 50).

    3. Correspondence: 0 < N ( m, k, 1, p) < 40; 40 < N (m, k, 2, p) < 65; 65 < N ( m, k, 3, p) < 90; 90 < N ( m, k, 4, p ) < 100.

    4. Rating RG is a function of average amount of:

    5. Points of the last five problems chosen,

    6. Overall points,

    7. Deductible points,

    8. Levels of courses and problems taken,

    9. Communication,

    10. Activity.exercise

    Communication Tools

    List of tools, including but not limited to:

    • Blogs
    • Forums
    • Wikis
    • Chat Rooms
    • Mailing Lists
    • Message Boards

    Object Rating

    E-Bay style rating of any UMO

    PHP-doc style comments

    Each entity in course can have set of publically viewable notes attached to it, that anyone can add to.

    ?The notes are moderated by?

    Default Tools

    1. UU level mailing list, forum and wiki.
    2. Each course generates mailing list, forum and wiki for students
    3. A course, when started or got completed, sends message on UU mailing list and UU forum

    Statistics/Demographics

    Each UMO bears publically accessible statistics of:

    1. Visiting

    2. Attendance

    3. Revenues

    4. Rating

    5. Participations/Results in/of within/out UU contests

    6. Usage in other courses

    7. Usage out of UU

    Group Admin. Tools

    TBD

    Search Engine & Lists

    1. All items in the lists below go with related "demographics"

    2. All lists are cross referred

    3. Lists

    • All objects
    • All courses, including languages
    • All topics
    • All problems
    • All languages
    • All course subjects
    • All authors, teachers, experts, students, etc.
    • All schools w. their level of participation
    • All groups w. their level of participation
    • All of the above associated with a user

    Business Assumptions

    UU is a Software as Service which is supposed to work as an Open Server

    1. The general condition to use the Open Server is that courses and any other objects created here fall under Authoright license.
    2. Specifically this means all courses created at the Open Server can be copied and offered to the audience on any conditions with the only requirement for proper attribution to the authors and original source.
    3. Any other objects from a course or General Repository can be used to create another course.
    4. Authoright driven references get technically implemented and enforced by the application.
    5. Using Open Server for creation of a course is free.
    6. However, offering a course for payment results in certain payment to the host.
    7. A course or any other object created at the Open Server cannot be tacken away except for those cases when its contents or any other feature contradicts the law or the Host policy. The decision to remove an object from the Open server is at the Host's discretion entirely.

    Proprietary Server

    • The role of the Proprietary server is in discussion. Our thinking was to contrast two servers in order to prove advantages of the open one. Still, we are not sure we need a proprietary server at all. For the moment it is thought to be as follows:
    • An author can create here a "closed" course, which means that neither course, nor any of its objects can be used by another author without the creator's permission.
    • The Proprietary Server is a paid service.
    • If an author copies a course or any other UMO from the Open Server on the Proprietary one: First, this does not affect in any way the prototype or its usage on the Open Server; Second, all proper attributions to the open prototype are enforced.
    • Any object created at the Proprietary Server can be removed by its author at her own discretion.
    Retrieved from "http://www.total-knowledge.com/wiki/UU"