<%= [dotlrn_header "dotLRN Architecture"] %>

dotLRN Architecture

by Ben Adida and Arjun Sanyal, part of dotLRN Documentation.

dotLRN is built on OpenACS 4.x, a modular architecture for community-oriented web applications. dotLRN is also modular in that new course management functionality can be added as desired. Since dotLRN modules must function within the dotLRN architecture, dotLRN modularity must be built on top of OpenACS modularity.

The dotLRN architecture attempts to define a framework within which learning communities develop. A learning community may take many different forms, but remains the crux of the architecture.

Learning Community

A Learning Community is architected as a series of OpenACS components, with a heavy use of the subsite concept. One community is represented by:

a group: this will serve to define membership and roles within the learning community. These groups are not necessarily all in the same group type.
a site node: this will serve to define a consistent URL for the learning community, and to segment away each communities from one another. An example is /dotlrn/alumni-1998.
an instance of the dotLRN Community Manager package: this will serve to display community-specific data in a way that is clearly segmented away from the other learning communities using the acs-subsite constructs.

Class Instances & Clubs

There are two different types of learning communities in the basic dotLRN release: class instances and communities (clubs). Both have the same functional capabilities but have different attributes and roles for their respective members.

Class Instances

Class Instances are related to a particular class, and must specify:

Year (e.g. 2002)
Term (e.g. Spring)
Section (e.g. Section B)
Start Date
End Date

The fist three parameters may be stored as separate items, all in one, or combined in some way. The current architectural direction is to separate Year and to group Term and Section, but this may change. In terms of the global architecture, this isn't very critical.

Since all class instances have a common basic set of parameters, the class instance groups should all be a single core group type, called Class. The Class group type defines the attributes above (year, term, section).

In addition, in order to group class instances by the class they refer to, the Class group type is subtyped into further group types, where one class is itself a group type. For example, 6.001 is a group type, whose parent group type is Class. Then, 6.001 is the group type that all instances of 6.001 belong to. 6.001 - Spring 2002, Section B is a group of group type 6.001. This architecture allows for:

class-specific attributes in addition to the generic set,
relating different class instances to a single class,
reusing existing OpenACS 4 concepts of group memberships and permissions.

Communities (Clubs)

Clubs are fairly generic Learning Communities, with no specific attributes. Clubs are timeless, in that they don't start and end on certain dates. Membership lists evolve, but the clubs remain unique, without instances.

Thus, unlike class instances, the group type structure for clubs can be much simplified. A root group type, called Club can encompass all club groups without any additional level of group typing.

dotLRN Packages

Learning communities have various packages of functionality. These packages are much like existing OpenACS 4 packages, but with added specifications, special callback interfaces, and predictable APIs that not every OpenACS 4 package will have.

Thus, a dotLRN Package is composed of two OpenACS 4 packages:

an OpenACS 4 raw functionality package (e.g. bboard), whose dependencies are completely independent of the core dotLRN application.
a simple OpenACS 4 package (e.g. bboard-dotlrn), dependent on the core dotLRN application, whose role is to wrap the raw OpenACS 4 functionality in the required dotLRN APIs.

The specifics of creating a dotLRN package are described in the dotLRN Package Creation Guide.

The Portal Interface

dotLRN will present most of its interface in portal form. Each dotLRN package will present its information inside a portlet within the appropriate portal page.

The current Portals package is inappropriate for this effort, given that there is no clean API for creating portal pages, setting up portal pages configuration, and rendering portal pages programmatically. Instead, dotLRN will need a much more programmatic portal mechanism.

A Portal Page

The New Portals Package (NPP) will feature the ability to programmatically create and edit single Portal Pages. A single Portal Page will be defined by:

a layout type (3-columns, 2-columns, etc..)
a set of portlets and their individual configuration information
a set of permissions for viewing the portal page

The dotLRN application will then create, configure, and associate individual portal pages with specific users' sections of the site. This will allow portal functionality to exist within the dotLRN application without handing over all control to the portals package.

Portlets

The NPP will require portlet packages much like the old portals package. Each portlet package is responsible for:

rendering itself within a portal page
providing a set of editable parameters
linking to all appropriate features in the underlying OpenACS package

The Per-User Interface

Each user will have a single NPP interface which groups information from all dotLRN classes in one page. Given the subsited architecture of each class, the per-user interface must be subsite aware, and must be able to query information across subsites.

<%= [dotlrn_footer] %>