Index: openacs-4/packages/dotlrndoc/www/doc/architecture-overview.adp =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/dotlrndoc/www/doc/architecture-overview.adp,v diff -u -r1.2 -r1.3 --- openacs-4/packages/dotlrndoc/www/doc/architecture-overview.adp 24 Oct 2001 23:27:22 -0000 1.2 +++ openacs-4/packages/dotlrndoc/www/doc/architecture-overview.adp 29 Mar 2002 17:21:56 -0000 1.3 @@ -15,211 +15,174 @@ 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. +different forms but remains the crux of the architecture. -

Learning Community

+

dotLRN Community

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

Class Instances & Clubs

+

OpenACS Group

+The core dotLRN group type is dotlrn_community. This group +type defines some basic attributes that all communities have: + + 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. +clubs. While Clubs need no additional attributes, +Class Instances require information concerning the Term and Year of +the Class Instance. -

Class Instances

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

Site Node

-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 important. +In dotLRN, a community is mounted only at one particular node. In the +future, if communities end up being multi-mounted, there will have to +remain a canonical location for the community in order to ensure +maximal modularity - specifically the ability to point to a +community's URL using only the community_id as a starting +point. -

+

Instance of dotLRN Community Manager

-Since all class instances have a common basic set of parameters, the -class instance groups should all be a single core group type, called -dotlrn_class. The dotlrn_class group type defines the -attributes above (year, term, section). dotlrn_class is a -group type that subtypes dotlrn_community. +The core dotLRN OpenACS package is called dotlrn +(surprisingly enough). This package is meant to be remounted to handle +community types and specific communities. A package_id +corresponds to each community.

-In addition, in order to group class instances by the class they refer -to, the dotlrn_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 -dotlrn_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: +The group types for these two dotLRN Community Types are +dotlrn_class_instance and dotlrn_club. -

+

Use of NPA

-

Communities (Clubs)

+dotLRN makes heavy use of the New Portal Architecture. -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. +

+Each full-access user has a personal portal where all data from all +communities is centralized in one place. This is called the dotLRN +User Portal. +

-Thus, unlike class instances, the group type structure for clubs can -be much simplified. A root group type, called dotlrn_club can -encompass all club groups without any additional level of group typing. +Each community has a non-member portal which displays information +to those browsing the system and wanting to find out more about a +community before joining it. This is called the dotLRN Community +Non-Member Portal. +

-

dotLRN Packages

+Each community also has an administrative portal which centralizes all +administrative functionality for that community. This is called the +dotLRN Community Admin Portal. -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. +

+Finally, each community member has her own dotlrn Community Member +Portal. The important distinction here is that there is a +different portal for each member of this community. Thus, if a +community has 100 members, there are 100 individually managed +portals. These portals are initially created from the dotLRN +Community Portal Template that administrators of the community control. + +

dotLRN Applets

+ +dotLRN Communities have various packages of functionality. These +packages (dotLRN applets) 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 three OpenACS 4 -packages: +Thus, a dotLRN Applet is composed of three +pieces that may each be a separate OpenACS package:

-The relationship between the NPA and the portlet package are defined -using ACS Service Contract. This is described in greater detail -in The Portal Interface (futher down). +

NPA Interactions

+The relationship between the NPA and the portlet functionality is +explored in the NPA Architecture Manual. +

+

dotLRN Applet API

+ The relationship between dotLRN and the specific dotLRN-dependent -packages (dotlrn-bboard, dotlrn-faq, etc...) is also defined using +packages (dotlrn-bboard, dotlrn-faq, etc...) is defined using ACS Service Contract. ACS Service Contract defines a standard provider/consumer interface with special contract APIs. The dotLRN system defines the dotLRN Applet Contract, which includes the following operations:

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 Architecture (NPA) will feature the -ability to programmatically create and edit single Portal -Pages. A single Portal Page will be defined by: - - -

- -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 NPA will require portlet packages much like the old portals -package. Each portlet package is responsible for: - - -

The Per-User Interface

- -Each user will have a single NPA 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. - -

- -The per-user interface will use slightly different portlets than the -community-specific ones, given that those portlets will require -scanning information across package instances. There is some thought -that this may be "not so kosher." As long as the cross-package -information is kept to a minimum, though, it should be just -fine. We'll make sure to keep associating packages with the -communities they belong to. -

- <%= [dotlrn_footer] %> Index: openacs-4/packages/dotlrndoc/www/doc/dotlrn-faq.adp =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/dotlrndoc/www/doc/dotlrn-faq.adp,v diff -u --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ openacs-4/packages/dotlrndoc/www/doc/dotlrn-faq.adp 29 Mar 2002 17:21:56 -0000 1.1 @@ -0,0 +1,162 @@ +<%= [dotlrn_header "dotLRN FAQ"] %> +

The dotLRN FAQ

+ +
Contents
+ + +
+
Basics
+
The OpenForce Role in dotLRN
+
dotLRN and OpenACS
+
Licensing
+
Miscellaneous
+ + + + + +

Basics

+ +
Q: What is dotLRN?
+ +
+ dotLRN is a full-featured application for rapidly developing web-based learning communities, specifically in the context of Course Management. The dotLRN software relies on OpenACS v4 and includes data model, application logic, and templates to get you up and running very quickly. +

Read more at dotLRN.mit.edu +

+ + + +
Q: Is dotLRN usable?
+
+ dotLRN is currently in alpha state. The target audience at this time is mostly early adopters. Note also that no backwards-compatibility will be ensured until a beta version. That said, dotLRN is quite stable as is and can most certainly be used to determine near-term usability in a production environment. +
+ +
Q: When will dotLRN ship?
+
+ dotLRN beta is planned for May 1st, 2002. dotLRN v1.0 is planned for August 1st, 2002. +
+ +
Q: How can I contribute?
+
+ We are currently developing our contribution mechanisms. If you would like to work on the core, you should email dotlrn-core@openforce.biz. If you would like to build new dotLRN extensions, you can check out how to build dotLRN extensions. +
+ + + +

The OpenForce Role in dotLRN

+ +
Q: What's the relationship between Sloan and OpenForce?
+
A: Sloan hired OpenForce to develop dotLRN to replace the aging SloanSpace v1.
+ + + +
Q: How will OpenForce work with other OpenACS + developers?
+
+A: OpenForce will continually provide anonymous CVS access to the dotLRN +development tree. OpenForce will continue to provide architectural +direction and goals for dotLRN. Over time, OpenForce will qualify and +include new developers in the core development process. OpenForce +expects to lead - but not monopolize - the dotLRN process. OpenForce +will also provide a repository of dotLRN applications available for +all to obtain existing dotLRN extensions and provide new ones to the community. +
+ + + +
Q: Will OpenForce develop, support, and/or host + dotLRN commercially?
+
A: Absolutely.
+ +
Q: Will OpenForce preclude me from providing +my own services surrounding dotLRN?
+
A: Absolutely not.
+ +
Q: But Why? Aren't you crazy to throw away +such clear business opportunity?
+
A: We are not in the business of selling +packaged closed-source software. We believe that open-source software +and a strong developer community provides plenty of opportunity for +numerous commercial services. We intend to stick to the Open-Source +track 100%. No tricks here.
+ + + +

dotLRN and OpenACS

+ +
Q: Is dotLRN a part of the OpenACS project?
+
dotLRN is not part of the OpenACS project, but +is an OpenACS application. This means that dotLRN will install on a +vanilla OpenACS without additional modifications and through the +regular, accepted OpenACS API. While dotLRN developers happen to also +be core OpenACS developers, the dotLRN team is taking all possible +measures to ensure that any modification suggested to the OpenACS core +is approved by other OpenACS developers that do not have a direct +stake in dotLRN.
+ + +
Q: Will dotLRN be merged into OpenACS?
+
A: This is a question to be answered by the OpenACS +community. +
+ + + + +

Licensing

+ + +
Q: What are the terms of use for dotLRN?
+
A: dotLRN is distributed under the GNU General +Public License v2. +
+ + +

Miscellaneous

+ +
Q: How is dotLRN spelled and pronounced?
+
A: It's sometimes written as .LRN, but + the spelling and capitalization dotLRN is + preferred. dotLRN is pronounced "daught-learn" We are currently accepting voice applications for the dotLRN MP3 pronounciation file. +
+ + + + + + + + + + + +
+ + + + + + + + + + + + + + +
Contact OpenForce +
return to top +
+ © 2002 OpenForce, Inc.
+
+ + + + + + + + + + Index: openacs-4/packages/dotlrndoc/www/doc/index.adp =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/dotlrndoc/www/doc/index.adp,v diff -u -r1.7 -r1.8 --- openacs-4/packages/dotlrndoc/www/doc/index.adp 28 Feb 2002 18:40:13 -0000 1.7 +++ openacs-4/packages/dotlrndoc/www/doc/index.adp 29 Mar 2002 17:21:56 -0000 1.8 @@ -5,17 +5,21 @@ Index: openacs-4/packages/dotlrndoc/www/doc/nomenclature.adp =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/dotlrndoc/www/doc/nomenclature.adp,v diff -u -r1.1 -r1.2 --- openacs-4/packages/dotlrndoc/www/doc/nomenclature.adp 14 Oct 2001 21:42:58 -0000 1.1 +++ openacs-4/packages/dotlrndoc/www/doc/nomenclature.adp 29 Mar 2002 17:21:56 -0000 1.2 @@ -1,59 +1,287 @@ <%= [dotlrn_header "dotLRN Nomenclature"] %> -

dotLRN Nomenclature

-by Ben Adida, part of dotLRN Documentation. +

dotLRN Nomenclature: a dotLRN Primer

+by Ben Adida, part of dotLRN Documentation. (last updated: 28 February 2002)

-dotLRN is a Course Management System which means it -helps manage courses, but does not perform the actual instruction of -the courses. This document defines the nomenclature -in the dotLRN project, because the components of a Course -Management System are named very differently by various teaching -institutions. In particular, since dotLRN is being developed for MIT -Sloan, an attempt is made to cleanly work within existing MIT -terminology while being generic enough to use by all. +dotLRN is a Learning Community Management System +which means it helps manage communities of users and the exchange of +information therein. This document defines the +nomenclature in the dotLRN project, with specific +examples of how this nomenclature can be used in the context of +dotLRN's primary use: that of a Course Management System.

+

1. dotLRN Communities

+The core concept within dotLRN is the dotLRN User Community. -

Class

+

Community

-A class is a topic being offered by the -institution. An example is "Introduction to Micro-Economics". Some -institutions use the term "course", but this conflicts with MIT's -reference to entire departments (Course 15). A class is thus a single -topic that spans across years and does not specify a single offering -of that topic. +A community is a group of users that work together and exchange +various types of information. There may be different types of +communities, but all have basic properties, such as a community name +and community ID. -

Class Instance

+

-A class instance is a particular offering of a -class. An example is "Introduction to Micro-Economics - Spring 2002, -Section A". A class instance thus has a very well-defined student -list, professor, and TAs. It has specific material relevant to that -offering of the class, a schedule, news events, etc... +

Class

-

Student

+A class is a topic of instruction, such as "Finance 101." A +class is not a community (this will become clearer +soon). -A student is an individual who is registered for a particular class -instance. +

+

Class Instances and Clubs

-

Instructor

+Two basic types of communities implemented in core dotLRN are +Class Instances and Clubs. Class Instances are +for structured groups of students, while Clubs are for unstructured +student activities. A Class Instance, as its name indicates, is a +specific instance of a Class. "Finance 101 - Spring 2002" is an +instance of "Finance 101." It doesn't make sense for "Finance 101," +the topic of instruction, to be itself a community, since Finance 101 +Fall 2000 and Finance 101 Spring 2005 will probably have nothing to do +with on another apart from teaching approximately the same material. -An instructor is one who teaches a particular class instance. An -instructor could be a professor in title or not. The term instructor -allows the system to be more flexible to different teaching -environments. +

-

TA

+

Open, Wait, Closed Communities

-A TA (Teaching Assistant) is one who assists the instructor in the -teaching of the class instance. +Communities can have one of three Join Policies. A join policy +defines the process by which a dotLRN User can become a member of the +community. For now, we will consider only dotLRN Full Access +Users (see below for more information on other types of dotLRN +users). -

Administrator

+

-An administrator is one who assist in managing issues surrounding a -class instance, but doesn't play a role in the teaching process. +A community with open join policy is visible in read-only +state to non-members. Any full-access user can join the community at +will, without the intervention of any other user. -

+

+A community with wait join policy is visible in read-only state +to non-members. A full-access user can apply to join the +community. The application must be approved by an administrator of the +community. + +

+ +A communty with closed join policy is not visible to +non-members. Users become members only when explicitly added by the +community administrator. + +

+ +

in MIT SloanSpace: Class Instances and Communities

+ +In MIT SloanSpace, dotLRN Communities are referred to as SloanSpace +Groups, while dotLRN Clubs are referred to as SloanSpace +Communities. + +

+ +The reason for this potential nomenclature confusion is historical: +SloanSpace v1.0 used a certain terminology. It would be unacceptable +to change it for SloanSpace v2.0. Similarly, it would be unacceptable +to stick to the SloanSpace nomenclature and impose it to all users of +dotLRN. + +

+ +Thus, dotLRN nomenclature, although internally self-consistent, is +entirely configurable by the user using global parameters. + +

2. dotLRN Users

+ +A dotLRN User is an individual with an email address username and a +password to the dotLRN system. Each user is uniquely identified by +email address. + +

Access Level: Limited or Full

+ +dotLRN users can have either Limited Access or Full +Access. + +

+ +A limited-access user is one who has access only to class instances +and communities she is registered for and has no ability to +browse any other section of the dotLRN application. This applies even +to open communities: if a limited-access user is not a member of a +given open community, she will not be able to browse any page that may +enable her to become a member. + +

+ +A full-access user is one who has access to all browsing +sections of the dotLRN application. A full-access user can surf around +and register for open communities, apply to be accepted into wait +communities, etc... A full-access user also has the ability to store +user-specific information, like personal files and personal calendar events. + +

+ +

Access to Private Information

+ +Certain users of the system may be dotLRN Guests, meaning that +they do not belong to the parent organization that runs the dotLRN +instance. These guests may participate in the community as +full-fledged members but, for certain legal or privacy reasons, may +not be allowed to view other users' private information. + +Any dotLRN user can be a guest or a non-guest. Full-access members can +be guests. The only difference between a guest and non-guest is +whether private user information (email address, address, phone #, +etc...) can be read by these guests. + +

System-Wide Roles

+ +dotLRN users have system-wide profile information. For example, in the +context of a Course Management System like MIT SloanSpace, they may be +Professors, Students, or Administrative Staff. +These system-wide roles define the user's specific profile in the +system as a whole, without regards to community-specific roles. + +

+ +

Community-Specific Roles

+ +dotLRN users have specific roles within the communities they belong +to. These roles are classified in two main categories: dotLRN +Community Members and dotLRN Community Admins. + +

+ +dotLRN Community Members of a given community have normal +read/write access to a community. They cannot perform administrative +functions, like create a new forum, add group calendar events, create +a new survey, etc... However, they can contribute to existing +discussion forums, view calendar events, and respond to surveys. + +

+ +dotLRN Community Admins have all the privileges of normal +community members plus complete administrative rights over all +components of the community. dotLRN Community Admins completely +control a community: they need no further help from any other users to +add data, applications, or users to their workspace. + + +

3. dotLRN Applets

+ +A dotLRN community is mostly a container of users and applets. A +dotLRN Applet (nothing to do with a Java applet) is a small +application that can be added to the community to enable new +functionality. + +

+ +Examples of existing applets include: Discussion Forums, Surveys, +FAQs, News, Calendaring. These applets are scoped in order to +correctly segment communities from one another. Data that belongs to +one community is not viewable by another: it is as if it doesn't exist +unless you are in the appropriate community. + +

+ +Certain applets are community-centric in that they offer +functionality that makes sense only in the context of a given +community. Discussion Forums is one solid example of this: a +discussion forum must pertain to a given community. + +

+ +Other applets are user-centric in that they also manage data +that is user-related, not linked to any given community. Calendaring +is one such applet: although there are community events, there are +also personal events. + +

+ +

4. Portals

+ +The entire dotLRN architecture is based on the New Portal +Architecture. The design and specifics of this architecture are +described in another document, but the basic terminology and concepts +are as follows. + +

+ +

Portal Page

+ +A Portal Page is a single page display of portal boxes. A +portal page has a Portal Layout that defines how the boxes are +arranged on the page. Common layout schemes include 2-column, +3-column, 3-column-with-header. New portal layouts can be implemented +at will. + +

+ +A portal page can be configured so that the portal boxes can be moved +around the page by someone with appropriate permissions. + +

Portal

+ +A Portal is a set of portal pages that are tied together so +that a browser may navigate easily between the various portal +pages. This is particularly useful when portal boxes need to be +organized by functionality theme. + +

Portlet or Portal Datasource

+ +A Portlet or Portal Datasource is a set of functionality +that is presented in the form of a portal box. A bboard portlet, for +example, is functionality that displays discussion forums inside a +portal box. + +

Portal Element

+ +A Portal Element is a single box on a given portal page. A box +that display discussion forum information on Jane Doe's personal +portal page #2 is one portal element that corresponds to +the instantiation of portlet within a portal page. + +

+ +A portal element can be moved, shaded, or hidden altogether, given the +appropriate permissions. It can be moved to a different page of the +same portal. While a portlet can be instantiated multiple times within +a given portal, a portal element is unique per portal as it represents +a single instance of the portlet: thus, a portal element can appear on +only one page of the portal in one location. To appear in more than +one place, a new instance of the portlet would have to be instantiated. + +

Portal Themes

+ +A portal page can be rendered in a given Portal Theme that +determines the look-and-feel of each box. The layout is NOT +determined here, only the specific look-and-feel of portal element +borders, buttons, and internals. + +

Portlet Parameters; Portal Element Parameter Values

+ +For each portlet, there is a set of Portlet Parameters. For +example, the calendar portlet has a calendar_view parameter +that indicates whether the portlet should display data in the form of +a list, day-, week-, or month- view. + +

+ +Each Portal Element has Portal Element Parameter Values for +each parameter of the portlet it instantiates. For example, the +calendar portal element on Jane Doe's personal portal may have a value +of "day" for the calendar_view parameter. + +

+ +

Portal Template

+ +A portal template is much like any other portal, except that it is +used as a template for creating other portals. + <%= [dotlrn_footer] %> + +