Forum .LRN Q&A: Re: thinking in dotlrn and the university educational model

From looking at your diagram: I have not thought about modelling faculties, but this is definitely not a bad idea. What do you mean by "subject" - "class"? Is this the same as "class" - "class_instance" from dotlrn? Everyone seems to use different terms for those two things :)

I thought model departments and classes with community-types. Why not?.
It is not a problem to have a community type "department" as a base type for all departments and one named "class", thats for sure. But if i create a new class or department (eg. Maths), i do not want them to be types but communities. Otherwise i cannot have members, portals, etc for them. Departments have staff like secretary, lecturers etc. This information should be modelled as well. But i think your model also is meant like that is it? In dotlrn a new department is just a community-type and nothing else.

I think the tables for the base types you mention are ok. In our version i have added some attributes to the departments table (telephon, fax, address etc). For the connection between departments and classes i created a mapping table. The tables are rather easy to rewrite, most of the work will probably come from changing psql and tcl-code. Things i have added as well are a table to save consultation hours for a department (person) and a table for class lecturers. Otherwise you will probably need a 6-table join using acs-rels to get a listing of every lecturer working for a department. If you are interested, i can send you the changes i did via mail, but i am far from ready.

Other modifications i thought about: I am not quite sure about the structure of dotlrn´s packages. The first thing i did was to create a new global dotlrn-admin package and removed the /admin subdir from the main dotlrn package. In addition the url for the departments, classes and class_instances need to be changed. I think the best option is to just use the respective key for that and make sure it is unique. Using the name for the url in 3 levels (department, class, class_instance) can create monsters like "Abteilung für Informationsverarbeitung/Einführung in betriebliche Informationssysteme/Einführung Java SS2003/". Another thing about the url is the mount point for classes , right now dotlrn does not take the semester into account when setting a name, so you have to integrate the term into the name if you have equal names in every term.

My idea for that (i am working on this right now) is to mount all of the class instances with their acs-ids and grant access to them via virtual url handlers from underneath the classnames path. Using this version you could get the following paths:

  • /class_shortname/class_instance_university_id/ (current term) eg: /math/6543.01/
  • /class_shortname/archive/termname/class_instance_university_id/ (archived class) eg: /math/archive/SS2003/6543.01/
We will probably want to use our universities codes for the class instances url key and i do not want to integrate the terms name in every url. What do you think about this issue?