Dokeos LCMS design

From Dokeos

Jump to: navigation, search
The information on this page might not be completely up to date. 
But it stays usefull as a reference to learn about the goals and 
ideas behind the LCMS project.

Contents

Introduction

This pages gives an overview of the design to convert Dokeos from course based learning management system to a repository based learning management system. Where Dokeos is now a course based learning environment, we want to turn it into a repository based learning environment. Basicly this means storing all learning content into a central repository.

Course based to user based

Currently Dokeos uses a course based storage system. Every single course in Dokeos has its own database in which all learning objects are stored. There's a major problem with this. If you want to use a learning object in 2 courses, 2 copies of the same learning object are stored. This doesn't look too bad at first sight. But imagine a learning path including several presentations. If a teacher wants to use this learning path in, let's say, 5 different courses, there's a need of re-using the same learning object.

So a user based storage system is more appropriate. Each user in the system has his/her own repository of learning objects which can be used in several courses. Every single object in the repository has an owner. This owner is the person who stored the learning object in the repository. Using a flexible role & rights system, it is possible to attach several access rights to those learning objects.

A course will be nothing more than a structured presentation of learning objects.

Remarks:

René: Referring again to the concept of Dokeos as an hierachical (folder) system, subclasses of 'folder' might include 'desk' (on which owners can place private objects and private folders, and on which 'course'-type folders can be shared with others), and compound objects currently already available in Dokeos, such as 'category', 'course', 'tool', 'folder', 'learning path'.
René: With the generalized 'folder' concept, and if sharing is limited to objects of 'folder' classes, a 'folder' object can contain basic learning objects (files, links, ...) and shares of other 'folder' objects. A 'folder' object can be shared according to the class rules (the 'share' method might not be the same for all classes derived from 'folder'), but not in itself, either directly or indirectly.

Manage your learning objects

When moving to a user based storage system, we give the users a tool to manage their objects.

  • These actions are very similar to the actions we currently have in Dokeos. The user interface will be the same.
    • Create a learning object
    • Edit an existing learning object
    • Delete a learning object
  • Other actions will be new compared to current Dokeos versions.
    • Organize learning objects into categories (compare this with your harddisk where you store all types of files in a single tree structure)
    • Search learning objects
    • Add metadata to a learning object: Currently Dokeos has the possibility to add metadata to documents (actually also other types of objects, but UI is missing). We will allow users to add metadata to all kind of objects. This functionality can be optional (so each institution can decide if their users should use metadata to describe their learning objects). Metadata helps improving the search capabilities of the system and a lot of metadata can be generated automatically.
    • Sharing objects. This allows users to attach permissions to their objects
    • searchable: can other users read the description (metadata) of this object while searching for some learning objects
    • readable: can other users see this learning object
    • use: can other users use this learning object in their courses
    • write: can other users change this learning object
    • ...

Remarks:

René: If learning objects can be shared, then the same object can be found in more than one folder, so strictly speaking the folder structure is not hierarchical, it is a DAG...

Database Abstraction

A first step to change Dokeos to a LCMS, is the introduction of some abstraction layers. Currently every single tool in Dokeos uses a direct connection to the database to manipulate his data.

There are some drawbacks with this situation:

  • Changing database (MySQL) to another database (Oracle, MSSQL, ...) means changing al lot of code.
  • A lot of code duplication
  • ...

The situation we're proposing is showed in the following image.

A repository data manager is the link between the learning object repository and its underlying storage system. Currently PEAR::DB is used as a database abstraction layer, but it is perfectly possible to define other repository data managers using other storage systems.

An Object Oriented design

LearningObject

Currently, we don't use the concept of learning objects in Dokeos. Introducing this term will facilitate some things: All objects have a title, a description, a (ideally worldwide) unique identifier,... Like mentioned above, additional metadata can be attached (see IEEE LOM and Dokeos 1.6)

On the long term, permissions could be attached to all learning objects (to share learning objects with other users), see

Benefits of using the concept of learning objects

  • Resource linker and learning path can do a lot of their work with learning objects rather than dealing with all types of learning objects
  • It will less work to define new types of learning objects. Other tools (resource linker/learning path) can work with the type 'LearningObject' without being aware of the actual type of the object.
  • If we centralise those common functionalities of learning objects, (hierarchically, by defining a object class hierarchy with properties and methods), code duplication can be reduced.


For every type of learning object a derived class will be defined which will provide more specialized implementations for functions to get/save/create/delete objects. For example, an Announcement can be seen as a core LearningObject (only with a title, description,..) and will not need to overwrite these functions. A more advanced learning object, like a forum for example, will certainly need more advanced implementation of these functions. In the LCMS Developer Cookbook there's a chapter titled Defining your own learning object type

Remarks:

René: Object ID's URN and URI compliant, e.g. urn:ugent-be:zephyr.TW05DBRH.Document.147
René: It is to be investigated whether limiting permissions and sharing to the 'folders', as described in the above references ('Consider Dokeos as an hierachical (folder) system'), is a workable and more efficient intermediate goal
René: On the long term, all objects could have versions; as an intermediate goal, this might be limited to 'basic' objects such as files and links (and 'folders' would not have versions)

RepositoryDataManager

This class provides the abstraction layer mentioned above. This manager class offers a clean interface for course modules (and perhaps other future functionalities) to retrieve, create,... learning objects. RepositoryDataManager is an abstract class, so different implementations can be created.

Application

Several Applications can be built on top of the LearningObject repository. A first Application is a WebLCMS. This Application provides the functionality we currently have in Dokeos (i.e. creating courses which contain several tools in which LearningObjects can be published). Another possible Application can be a Portfolio for example. Image:Lcms_applications.png

LearningObjectPublication

When we publish a learning object in a course module, we actually create a LearningObjectPublication. These type of objects keep track of

  • the published learning object
  • the course, module and modulecategory in which it was published
  • publish date
  • who published
  • who can see the object (all, selected users, selected groups,..)
  • are there any attachments
  • the display order of the object
  • ...

This is the kind of information we currently store in the item_property table of Dokeos. In the code we make abstraction of all this information by putting it in an object.

LearningObjectPublicationCategory

When publishing learning objects (as LearningObjectPublications) in a course module, we can organize these objects in categories. For this purpuse we defined a LearningObjectPublicationCategory object. This object gives us a clean interface to work with categorized objects in modules. For every module at least one LearningObjectPublicationCategory is defined. This is the root category in the module. This root category can contain zero or more subcategories and zero or more LearningObjectPublications.

RepositoryTool

There are many common actions in a course module. Roughly speaking, only the way learning objects are presented is different in the several modules. Events for example are displayed in a tabular calendar-view while announcements are displayed one a single pages below each other.

Common actions in course modules are:

  • create/edit/delete categories
  • publish/remove learning objects
  • sorting learning objects
  • ..

All these actions can be defined in a common class RepositoryTool. Earch course module can be derived from this class to implement module specific functionality, such as displaying the items. Not all common action will be used by every module, the display_order of events in the calendar module isn't defined for example as we sort events chronological. And we currently only have one level of categories in the Link module. But when having all functionality available in the core RepositoryTool class, changing the Link module to allow hierarchical structuring of links can be achieved very easily.

Relation between the Object Repository and course modules

Activity Diagram

In the activity diagram below, an overview is given of possible actions inside a course module. The red part is presentation stuff (= a course) while the blue part is CMS stuff. As you can see, it will not require more steps to create new items than current situation. All modules will have a new option to add an existing learning object. This will lead to the CMS where the user can select the object.

Example: Publishing a learning object in a course module

When adding a learning object to a course module, you'll have 3 choices (browse objects, search objects, create object). These can be grouped in a tabbed overview. For example, let's add a link to our link module in a course. We click the 'add link' icon in the link module and we get an overview of all our learning objects of the type 'link' Image:Cms add link tab1.png We can choose one of those links, or select the 'search' tab. Image:Cms add link tab2.png Or, if we want to create a new link, we select the 'create' tab. Image:Cms add link tab3.png

Once we have selected the learning object we'd like to publish, a form is presented with some publishing options. Here we can provide options like:

  • who can see this learning object (all users, selected groups, selected users,...)
  • when will this learning object become visible and for how long
  • some attachments (selecting attachments can be same interface as above)

Image:Cms add link publish options.png

The implementation of the steps above can be made very easy as the only thing that's different for every course module is the type of learning objects they contain.

User interface

It is very important that we have a smooth integration of these CMS features in Dokeos. We will use the same layout as Dokeos.

  • same colors
  • same icons
  • same type of messages
  • ...

The users personal object repository should be another 'My' function. (like 'My profile', 'My agenda',...)

Database design

As we move towards a user based design, we shouldn't keep the course based database scheme. Having a single database to store all learning objects we can easily implement things as:

  • search in all objects (simple on title and description or more advancede on metadata etc)
  • defining a quota for every user (which takes ALL objects into account)
  • defining a quote for every course (which takes ALL objects into account)
  • reuse of learning objects in several courses

This all doesn't mean it is impossible to have a database per course. You could see every single course as a single repository of learning objects and keeping that in mind, store all objects for a course in a different database. This will, of course, have some consequences on functionality as sharing objects, searching in all objects,... Image:Cms database scheme.png As you see in the image above, a table learning_object stores the common properties of all learning objects (id, title, description,...). For most types of learning objects a table is needed to store some more specific information (for example the URL of a Link object) others may not need extra information (like an Announcement object). When a learning object is published in a course, a record is added to the module_object table (which is, as mentioned above, similar to item_property table). Here information like publish date, publisher, which course/module/category,... is stored

Retrieved from "http://www.dokeos.com/wiki/index.php/Dokeos_LCMS_design"
Personal tools