Universe University. Specifications for Web Based Educational Environment
Universe University aims to answer 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. We believe these goals sound good for anybody today but real construction and technology of the modern schools go back to 17th century and can effectively provide only informing and training. All the rest is up to a teacher. Our understanding is that modern school has to be reconstructed entirely so that priorities could be switched. The whole educational process must aim directly on thinking and creativity. Students must enjoy and be interested in the subject itself vs. worrying about credits and other superficial reasons. If this happenes then information and skills, or generally speaking, knowledge of traditional type will be acquired as a side effect and in much better degree.
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.
Problem solving feature will be provided with the following tools of the environment.
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..
Every UMO has a set of standard features, such as UMO author, UMO type (see below), UMO version (an integer number of version), a date when UMO was created, and an optional date when UMO was published. The create date, UMO type and author are filled in once when UMO is created, and never modified. A publish dated is set when UMO is published, and locks UMO in published state. A UMO description is optional, and may be omitted. That is to a contrast from UMO title that must exist and be non-empty.
Some of the UMO properties, like title and description, may exist in several languages simultaneously. Such properties are stored as content records. When UMO is created, at least one content record is created, to hold UMO title and description in this UMO default language. There is no limit to a number of content records, however only one content record per language can be created.
Every UMO may exist in several versions. A version is created when there is a need to create a modified version of existing UMO. The new version of UMO derives the original UMO version' title, content records, and administrators and editors groups. The user that creates a new UMO version becomes that UMO version' author.
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.
Properties can be created for any UMO for storing some special UMO 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.
Keywords are made of UMO content title and description. This is completely automatic process that runs when UMO content is created or modified. Keywords are indexed so keyword-based searches are very fast.
Each UMO can include or be included in a work flow:
This property will be tested by dependent objects to implement the work flow.
Each UMO can say what student faculties or other the UMO author's objectives it was created for.
Each UMO can refer a user to outside (not UU bound) sources related to the object.
Each UMO can be rated by users
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 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.
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.
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:
Number is really associated with Topic, not with explanation, as an explanation can be shared between different topics.
Text of the explanation
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.
It is a number, starting with 1, incrementing by 1, but can go in opposite direction as well: 0, -1, etc.
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.
1. A work flow can be implemented in a form of:
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)
A competition can be set on any UMOs of the same type
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.
An UMO of the course level. They are problems of different level of difficulty, collected on any bases.
Through Problem can be created if at least one problem is supplied.
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)
DoT can be created if at least one text is supplied
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:
"Link to" is an UMO (see below)
It is an object featuring:
Just a piece of text loosely associated with a 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
Custom UMO can be created if at least two child UMOs are supplied.
Universe University has to be accessible and functional on different languages. There are two important aspects of localization to consider
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.
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.
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.
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.
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.
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.
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 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:
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.
Different groups may be granted different permissions on different UMOs.
Members of a group with EDIT access to an UMO can perform following actions:
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.
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.
Members of a group with TEACH access to a classe can "teach" it. This means following actions are allowed:
in all course-related communication tools for this class.
Members of a group with ADMIN access to a class can perform following actions:
Members of a group with STUDY access to a #Class can have following properties:
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.
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
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
UMO gets automatically from a course into the Repository or can be created specifically for the repository depending on its author.
All of above repositories will be presented to 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:
User will also be able to specify any combination of the following sort criteria (both increasing and decreasing):
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)
Following administrative tasks will be allowed:
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.
Any sub-categories are also unhidden, recursively.
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)
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.
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.
Items from the General Storage move up into the Featured storage by getting rated.
Stores submissions disapproved by the 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.
(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.
(For Open server only)
May include tools for analyzing tree structures, and pointing out similarities to authors, etc.
Simple features to make sure no conflicts are created during simultaneous work on courses.
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.
1. Voting: on courses, problems, authors, messages, etc.
2. Functional: on people, participating in through subject chess mastership type rating
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
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
E-Bay style rating of any UMO
Each entity in course can have set of publically viewable notes attached to it, that anyone can add to.
?The notes are moderated by?
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
1. All items in the lists below go with related "demographics"
2. All lists are cross referred
3. Lists