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
    (* Add detailed descriptions to some UMO types. * Replace "user types" list with "access control system". * Start "Authorship" section)
    Line 1: Line 1:
     +
    <keywords content="university,school,on-line,online,study,specification,design,programming,C++,course,subject,math,physics"/>
     +
    Universe University. Specifications for Web Based Educational Environment
    Universe University. Specifications for Web Based Educational Environment

    Revision as of 13:53, 18 January 2009


    Universe University. Specifications for Web Based Educational Environment

    Contents

    Philosophy

    Goal

    Universe University aims to answer to contemporary challenge to education. The core demand to educational system today, is to develop thinking and creativity vs. pure informing and training, which has traditionally been implemented through Western schools since XVII century. If we find a way to bring up, say, math thinking, this means that our students enjoy math, and are interested in the subject itself, as opposed to worrying about credits and other superficial and side reasons. In this case, information, training, and generally speaking, knowledge of traditional type will be acquired as a side effect of the educational process.

    In order to accomplish stated goal we create a very special environment with countless possibilities for creating of courses and studies.

    Working Educational Principles

    There are two major principles contemporary education should be based on: dialogue and problem solving. Correspondingly we want these to be implemented within Universe University in different ways.

    Dialogue will be provided in the following features of the environment.

    1. First, directly through different communication tools, which can be used in conjunction with work on studies or course development. We intend to build organic system of all suitable communication protocols to be embedded in the Universe University: message boards, chat rooms, etc.
    2. Second, we offer special feature for course structure, which allows one to create what we call "parallel explanations" for each single topic. That is, an author may use absolutely different explanations for a single fact, including those, which interpret it in opposite directions. Such an approach was traditionally considered unacceptable, because a traditional course is built sequentially. However, sequential courses do not awaken thinking this way. If a student encounters different explanations for a single fact, this will rise questions, which is the first step in thinking.
    3. Generally, Universe University offers an environment to built courses of "open source" type. That is, different people may participate in a course construction, bringing in different approaches, stand points, understanding of a subject, and so forth. This alone develops definitely dialogic environment, attitudes and mood. On the other hand, those authors, who are not inclined to do work in cooperation with others, have at their disposal tools to do it alone.
    4. Universe University is supposed to offer various tools for feedback on courses, single topics, problems, problem solutions, authors, and so forth, which is also a normal dialogic form.
    5. One more tool featuring dialogue in UU is also unique, though functionally very simple component, which is called "Dialogue of Texts". Dialogue of Texts is not a course, or is not included in a course, neither does it includes courses. It is exactly, what it called: dialogue of texts, a collection of texts contradicting each other and having some specific features. This work of high level experts, scientists, scholars implies the same idea: to provoke thinking.

    Problem solving feature will be provided with the following tools of the environment.

    1. Each single topic of a course can feature blocks of problems of different levels of difficulty.
    2. A problem consists of a "problem statement" and a "solution control definition". Solution control definition determines exact way of providing student with an interface to enter his answer and the way to determine if the answer was correct. We plan on providing following solution control definition types initially: single answer, multiple choice, solution template, semiotic model
    3. We also plan to implement the generator of formalized classes of problems/exercises to ensure training of any level of perfection, whenever a course author finds it necessary.
    4. A course may include built in testing, rating and work flow based on the pace of problem solving.
    5. UU allows to conduct cross-course problem solving based contests and rating system.

    User Manageable Objects - UMOs

    User Manageable Objects (UMO) are main building blocks of UU. Courses, topics, problems, etc. are all types of UMO. UMO is the object which can be studied. UMOs may be constructed from other UMOs (depending on type). For example, a topic consists of sub-topics, explanations, problems, etc..

    Common UMO Features

    Available UMO Types

    • Course
    • Dialog of Texts
    • Topic
    • Explanation
    • Problem
    • Game
    • Exercise
    • Link to

    UMO Sharing

    • Same object can be used in multiple other UMOs without limitations (depending on UMO types).
    • Same object can be worked on by multiple users - depending on its author's assignment.
    • A course can be copied by a user for business purposes. In this case only proper attribution required (see Licensing).

    Stamp of Authenticity

    • It says, what this object is in terms of authorship:
      • An original + who is the author or
      • One derived from someone's original + who is the author and other info about the original + who is the editor or
      • A borrowed object + who is the author and other info about the original
    • It includes the time stamp of its creation.

    Object Versioning

    Let's say user X creates object O. The user Y uses O in his course. Now X changes O. Will the course include edited version of O, or original one? Ideally it should be up to Y to decide that. This leads us to the concept of object versioning. i.e. each change to an object creates a new version, and old one stays. When linking objects to each other (e.g. adding problem to topic) author decides which version to use.

    Mandatory UMO Properties

    Following properties are common for all UMOs in UU, and must be set for each object.

    • Author
    • Title

    Optional Features

    • Keywords (TBD later)

    Each UMO can specify keywords essential to it and useful for searching for it.

    • Work Flow (Prerequisites and possibilities) - for next version!!!
    Each UMO can include or be included in a work flow:
    
      • Each UMO can say which other objects can be useful if acquired by a student beforehand, shortly - are prerequisites to study or exercise this one.
      • Each UMO can specify possibilities for further studies this object brings in.
      • Each UMO can be completed by a student
      This property will be tested by dependent objects to implement the work flow.  
    
    • Faculties/Objectives

    Each UMO can say what student faculties or other the UMO author's objectives it was created for.

    • Outside References

    Each UMO can refer a user to outside (not UU bound) sources related to the object.

    • Statistics
      • Usage in other UMOs
      • Usage by students
      • Usage by authors
    • Rating

    Each UMO can be rated by users

    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.

    In all other respects, course behaves just like a regular Topic#topic.

    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)
    • Test
    • Blocks of problems of different difficulty levels

    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 that one he needs.
    • Different approaches for the same subject to provoke dialogue between students and critical thinking.

    Necessary Features

    • Title is <the same as of its Topic>dot<Specific 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.
    

    Optional Features

    Text of the explanation

    Problem

    Necessary Features

    • Problem statement,
    • Solution and
    • Answer.
    • Choice of solution control
      • As of today, 5 solution control methods are being developed:

    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 Features

    • Required time to solve

    Work Flow - This is in discussion and to be implemented in the next version if any (see Optional Features)

    The Idea

    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 or just an author's experience.

    Forms and Features

    1. A work flow can be implemented in a form of:

    • A flow-chart or
    • Pseudocode, consisting of sequences, choices and cycles of actions to do or
    • Just a set of rules
    • It can be "virtual". That means it is invisible, may or may not contain controlling feature and controls a sequence of UMO offering to students so that they get aquired in certain order, but the order is not controlled by students.
    • A work flow also may include means of control whether a student or group of students follow the work flow.

    Relationship with other UMOs

    • Work Flow can be attached to any object
    • Work flow can organize any objects, including courses

    Test

    • Test can be attached to any other UMO.
    • A test may include undetermined number of:
      • Problems,
      • Exercises,
      • Games
    • There can be Test Templates, 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

    General Idea

    A competition can be set on any UMOs of the same type

    All Features are Necessary

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

    Homework - To be discussed and implemented in the next version

    • A homework can be comprised from any UMOs?
    • A homework can be attached to any UMO?

    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.

    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.

    Problem In

    • Necessary Features
      • Number, starting with 1, incrementing by 1
      • Links to previous and next if any
      • Presenter - the person to present the problem into collection
      • Author - the author of the problem, if available

    Dialogue of Texts

    Dialogue of Texts (DoT) is an UMO of the course level, that is a course independent object. They are classical texts compiled accordingly (see features)

    Necessary Features

    • Basis for collection
    • Author - the person to start the collection
    • Interconnected text list
    • Text In

    DoT can be created if at least one text is supplied

    Content of DoT

    Dialogue of Texts is organized set of texts cross-referenced on basis of arguments. Each dialogue has set of "points", and each text is broken into sections, that refer to these points. Dialogue can be presented to user in following ways:

    • One text at a time, annotated with links to relevant "points"
    • As list of "points", with references to places in each text where these points are discussed
    • As interleaving texts, for cases where arguing texts are organized similarly enough for that to make sense.

    Text In

    • Features
      • Presenter
      • Author
      • Number, starting with 1, incrementing by 1
      • Links to all related texts in the Dialogue

    "Link to" is an UMO (see below)

    Link To

    It is an object featuring:

    • Two linked texts
    • Their relationship, such as:
      • Contradicts
      • Develops
      • Complements
      • Repeats
      • Mocks
      • Custom

    Text

    Just a piece of text loosely associated with a UMO

    • Necessary Features
      • Subject
      • Text body

    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

    • Necessary Features
      • Name (Category)
      • Description
      • Child UMOs

    Custom UMO can be created if at least two child UMOs are supplied.

    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. 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.)

    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

    • Is a very special feature of the UU. 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.

    • A UMO can get in one out of three storages:
      • Featured Storage
      • General Storage
      • Disagreement Storage

    Catalog

    All of above repositories will be presented to user as catalogues. Catalogs themselves are browsable tree-like sets of categeories [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

    Catalog Administration

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

    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 catalog
    This will hide the category from catalog and
    from UMO author UIs for association of UMO with
    categories.
    
    • Unhide hidden category
    • 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)
    

    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 are available. Each category may have its own separate rating formula.

    1. Classical problems
    2. Border line subject-to-subject problems
    3. Classical texts
    4. Border line science-to-life problems
    5. Games
    6. Teaching techniques
    7. Work Flow
    8. Explanation
    9. Exercise

    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

    (For Open server only)

    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 make turning multiple courses into one easier

    (For Open server only)

    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, participating in through subject 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

    We intend to use all available Open Source communication tools

    List of tools

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

    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

    • This section supposed to be developed (but is not yet) in order for UU to be used by groups and organizations of any type.
    • We need some form, posiibly wiki, to get requests from organizations about this section

    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

    Open Server

    1. The general condition to use the Open Server is that courses and any other objects created here fall under Authoright license (http://www.culturedialogue.org).
    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

    • 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.
    • 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.
    • 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.