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. -<h2>Learning Community</h2> +<h2>dotLRN Community</h2> -A <strong>Learning Community</strong> is architected as a series of +A <strong>dotLRN Community</strong> is architected as a series of OpenACS components, with a heavy use of the <strong>subsite</strong> concept. One community is represented by: <ul> -<li> <strong>a group</strong>: this will serve to define membership -and roles within the learning community. These groups are not -necessarily all in the same group type (well, they are all ROOTED in -the same group type, <tt>dotlrn_community</tt>). -<li> <strong>a site node</strong>: this will serve to define a +<li> <strong>an OpenACS group</strong>: this serves to define membership +and roles within the learning community. +<li> <strong>a site node</strong>: this serves to define a consistent URL for the learning community, and to segment away each communities from one another. An example is <tt>/dotlrn/alumni-1998</tt>. <li> <strong>an instance of the dotLRN Community Manager -package</strong>: this will serve to display community-specific data +package</strong>: this serves to display community-specific data in a way that is clearly segmented away from the other learning communities using the <i>acs-subsite</i> constructs. </ul> -<h2>Class Instances & Clubs</h2> +<h3>OpenACS Group</h3> +The core dotLRN group type is <tt>dotlrn_community</tt>. This group +type defines some basic attributes that all communities have: +<ul> +<li> <b>a short name</b>: a simple name with no spaces, no special +characters, usually all lowercase. e.g. finance-101 +<li> <b>a pretty name</b>: a name that is used in pretty +presentation. e.g. Finance 101 +<li> <b>start and end dates</b>: for communities that have certain +validity periods, a start date and end date. +</ul> + There are two different types of learning communities in the basic dotLRN release: <strong>class instances</strong> and -<strong>communities (clubs)</strong>. Both have the same functional -capabilities but have different attributes and roles for their -respective members. +<strong>clubs</strong>. While Clubs need no additional attributes, +Class Instances require information concerning the Term and Year of +the Class Instance. -<h3>Class Instances</h3> -Class Instances are related to a particular class, and must specify: -<ul> -<li> Year (e.g. 2002) -<li> Term (e.g. Spring) -<li> Section (e.g. Section B) -<li> Start Date -<li> End Date -</ul> +<h3>Site Node</h3> -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 <tt>community_id</tt> as a starting +point. -<p> +<h3>Instance of dotLRN Community Manager</h3> -Since all class instances have a common basic set of parameters, the -class instance groups should all be a single core group type, called -<b><tt>dotlrn_class</tt></b>. The <tt>dotlrn_class</tt> group type defines the -attributes above (year, term, section). <tt>dotlrn_class</tt> is a -group type that subtypes <tt>dotlrn_community</tt>. +The core dotLRN OpenACS package is called <tt>dotlrn</tt> +(surprisingly enough). This package is meant to be remounted to handle +community types and specific communities. A <tt>package_id</tt> +corresponds to each community. <p> -In addition, in order to group class instances by the class they refer -to, the <tt>dotlrn_class</tt> group type is subtyped into further group -types, where one class is itself a group type. For example, -<tt>6.001</tt> is a group type, whose parent group type is -<tt>dotlrn_class</tt>. Then, <tt>6.001</tt> is the group type that all -instances of 6.001 belong to. <tt>6.001 - Spring 2002, Section B</tt> -is a group of group type <tt>6.001</tt>. This architecture allows for: +The group types for these two dotLRN Community Types are +<tt>dotlrn_class_instance</tt> and <tt>dotlrn_club</tt>. -<ul> -<li> class-specific attributes in addition to the generic set, -<li> relating different class instances to a single class, -<li> reusing existing OpenACS 4 concepts of group memberships and permissions. -</ul> +<h2>Use of NPA</h2> -<h3>Communities (Clubs)</h3> +dotLRN makes heavy use of the <b>New Portal Architecture</b>. -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. +<p> +Each full-access user has a personal portal where all data from all +communities is centralized in one place. This is called the <b>dotLRN +User Portal</b>. + <p> -Thus, unlike class instances, the group type structure for clubs can -be much simplified. A root group type, called <tt>dotlrn_club</tt> 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 <b>dotLRN Community +Non-Member Portal</b>. +<p> -<h2>dotLRN Packages</h2> +Each community also has an administrative portal which centralizes all +administrative functionality for that community. This is called the +<b>dotLRN Community Admin Portal</b>. -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. +<p> +Finally, each community member has her own <b>dotlrn Community Member +Portal</b>. 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 <b>dotLRN +Community Portal Template</b> that administrators of the community control. + +<h2>dotLRN Applets</h2> + +dotLRN Communities have various packages of functionality. These +packages (<b>dotLRN applets</b>) 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. + <p> -Thus, a <strong>dotLRN Package</strong> is composed of <b>three</b> OpenACS 4 -packages: +Thus, a <strong>dotLRN Applet</strong> is composed of <b>three</b> +pieces that may each be a separate OpenACS package: <ul> -<li> an OpenACS 4 raw functionality package whose -dependencies are completely independent of the core dotLRN -application (e.g. bboard). -<li> an OpenACS 4 portlet, using the New Portal Architecture (NPA), whose -role is to summarize the information in one portlet -(e.g. bboard-portlet). This is dependent on the NPA, but not on dotLRN. -<li> an 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. +<li> <b>OpenACS raw functionality</b>, to provide discussion +forum functionality. As much as possible, this shouldn't depend on +other dotLRN components. (e.g. bboard) + +<li> <b>OpenACS portlet</b>, using the New Portal Architecture (NPA), +to provide the ability to display the raw functionality in a portal +interface. This obviously depends on the the NPA, but should otherwise +be as independent as possible from dotLRN. (e.g. bboard-portlet) + +<li> <b>dotLRN functionality hooks</b>, to link the raw functionality +into the appropriate dotLRN structure. This obviously depends on +dotLRN, but should be as thin a layer as possible on top of the the +previous two components. (e.g. dotlrn-bboard). </ul> <p> -The relationship between the NPA and the portlet package are defined -using <b>ACS Service Contract</b>. This is described in greater detail -in The Portal Interface (futher down). +<h3>NPA Interactions</h3> +The relationship between the NPA and the portlet functionality is +explored in the <a href=npa-architecture.adp>NPA Architecture Manual</a>. + <p> +<h3>dotLRN Applet API</h3> + 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 <b>ACS Service Contract</b>. ACS Service Contract defines a standard provider/consumer interface with special contract APIs. The dotLRN system defines the <b>dotLRN Applet Contract</b>, which includes the following operations: <ul> <li> <b>GetPrettyName</b>: Obtain a pretty, presentable name for the applet in question. -<li> <b>AddCommunity</b>: Add the applet to a -new community. This will most probably entail creating a new package for +<li> <b>AddAppletToCommunity</b>: Add the applet to a +new community. This will most probably entail instantiating a new package for this functionality, mounted below the community's main mount point. It will also involve setting up applet-specific data structures (e.g. a new forum inside bboard). -<li> <b>RemoveCommunity</b>: Remove the applet from the +<li> <b>RemoveAppletFromCommunity</b>: Remove the applet from the community. This will entail cleaning up any applet-specific data structures, removing the mount point and package instance. -<li> <b>AddUser</b>: add a user to the community, and perform any +<li> <b>AddUser</b>: add a user to dotLRN in general. This user has +not yet joined any community, but may need user-specific functionality +enabled (a private folder for files, a personal calendar, etc..) +<li> <b>RemoveUser</b>: remove a user from dotLRN in general. This +cleans up the AddUser operation. +<li> <b>AddUserToCommunity</b>: add a user to the community, and perform any applet-specific related actions. For applets that are represented via a portlet (which is often, but not always, the case), this will add the right portlet to the user's portal page for that community. It will also add the generic portlet to the user's main, cross-community workspace. +<li> <b>RemoveUserFromCommunity</b>: remove a user from a community, +and thus clean up the actions of AddUserToCommunity. </ul> <p> The specifics of creating a dotLRN package are described in the <a href=writing-a-dotlrn-package.adp>dotLRN Package Creation Guide</a>. -<h2>The Portal Interface</h2> -dotLRN will present most of its interface in portal form. Each dotLRN -package will present its information inside a <i>portlet</i> within -the appropriate portal page. - -<p> - -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. - -<h3>A Portal Page</h3> - -The <strong>New Portals Architecture (NPA)</strong> will feature the -ability to programmatically create and edit single <strong>Portal -Pages</strong>. A single Portal Page will be defined by: -<ul> -<li> a layout type (3-columns, 2-columns, etc..) -<li> a set of portlets and their individual configuration information -<li> a set of permissions for viewing the portal page -</ul> - -<p> - -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. - -<h3>Portlets</h3> - -The NPA will require portlet packages much like the old portals -package. Each portlet package is responsible for: -<ul> -<li> rendering itself within a portal page -<li> providing a set of editable parameters -<li> linking to all appropriate features in the underlying OpenACS -package -</ul> - -<h2>The Per-User Interface</h2> - -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. - -<p> - -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. -<p> - <%= [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"] %> +<h2>The dotLRN FAQ</h2> + + <div class=heading><div class=orange>Contents</div></div> + + <!-- contents --> + <div class=para></div> + <div class=contents><a href=dotlrn-faq.adp#basics>Basics</a></div> + <div class=contents><a href=dotlrn-faq.adp#openforce>The OpenForce Role in dotLRN</a></div> + <div class=contents><a href=dotlrn-faq.adp#openacs>dotLRN and OpenACS</a></div> + <div class=contents><a href=dotlrn-faq.adp#licensing>Licensing</a></div> + <div class=contents><a href=dotlrn-faq.adp#misc>Miscellaneous</a></div> + <!-- end contents --> + + + <!-- begin q and a --> + + <div class=heading><P><a name=basics>Basics</a></div> + + <div class=question>Q: What is dotLRN?</div> + + <div class=answer> + 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 <a href=http://openacs.org>OpenACS v4</a> and includes data model, application logic, and templates to get you up and running very quickly. + <P>Read more at <a href=http://dotLRN.mit.edu>dotLRN.mit.edu</a> + </div> + + + + <div class=question>Q: Is dotLRN usable?</div> + <div class=answer> + 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. + </div> + + <div class=question>Q: When will dotLRN ship?</div> + <div class=answer> + dotLRN beta is planned for May 1st, 2002. dotLRN v1.0 is planned for August 1st, 2002. + </div> + + <div class=question>Q: How can I contribute?</div> + <div class=answer> + We are currently developing our contribution mechanisms. If you would like to work on the core, you should email <a mailto:dotlrn-core@openforce.biz>dotlrn-core@openforce.biz</a>. If you would like to build new dotLRN extensions, you can check out <a href=>how to build dotLRN extensions</a>. + </div> + + <!-- end Basics --> + + <div class=heading><P><a name=openforce>The OpenForce Role in dotLRN</a></div> + + <div class=question>Q: What's the relationship between Sloan and OpenForce?</div> + <div class=answer>A: Sloan hired OpenForce to develop dotLRN to replace the aging SloanSpace v1.</div> + + + + <div class=question>Q: How will OpenForce work with other OpenACS + developers?</div> + <div class=answer> +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. + </div> + + + + <div class=question>Q: Will OpenForce develop, support, and/or host + dotLRN commercially?</div> + <div class=answer>A: Absolutely.</div> + + <div class=question>Q: Will OpenForce preclude me from providing +my own services surrounding dotLRN?</div> + <div class=answer>A: Absolutely not.</div> + + <div class=question>Q: But Why? Aren't you crazy to throw away +such clear business opportunity?</div> + <div class=answer>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.</div> + + <!-- end OpenForce --> + + <div class=heading><P><a name=openacs>dotLRN and OpenACS</a></div> + + <div class=question>Q: Is dotLRN a part of the OpenACS project?</div> + <div class=answer>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.</div> + + + <div class=question>Q: Will dotLRN be merged into OpenACS?</div> + <div class=answer>A: This is a question to be answered by the OpenACS +community. +</div> + + + <!-- end OpenACS --> + + <div class=heading><P><a name=licensing>Licensing</a></div> + <!-- end Licensing --> + + <div class=question>Q: What are the terms of use for dotLRN?</div> + <div class=answer>A: dotLRN is distributed under the GNU General +Public License v2. +</div> + + + <div class=heading><P><a name=misc>Miscellaneous</a></div> + + <div class=question>Q: How is dotLRN spelled and pronounced?</div> + <div class=answer>A: It's sometimes written as <tt>.LRN</tt>, but + the spelling and capitalization <tt>dotLRN</tt> is + preferred. <tt>dotLRN</tt> is pronounced "daught-learn" We are currently accepting voice applications for the dotLRN MP3 pronounciation file. + </div> + + <!-- end misc --> + +</div> + +<!-- end q and a --> + + +<!-- End Body --> +<!-- Begin Footer --> + +<CENTER> +<TABLE WIDTH="100%" BORDER="0" CELLPADDING="0" CELLSPACING="0"> + <TR> + <TD COLSPAN="2"><IMG SRC="/images/blank.gif" WIDTH="1" HEIGHT="25" ALT="" BORDER=0></TD> + </TR> + <TR> + <TD COLSPAN="2" BGCOLOR="#000000"><IMG SRC="/images/blank.gif" WIDTH="1" HEIGHT="1" ALT="" BORDER=0></TD> + </TR> + <TR> + <TD COLSPAN="2"><IMG SRC="/images/blank.gif" WIDTH="1" HEIGHT="5" ALT="" BORDER=0></TD> + </TR> + <TR> + <TD ALIGN="left" VALIGN="top"><DIV CLASS="footer"><A HREF="contact.adp">Contact OpenForce</A> + </DIV></TD> + <TD ALIGN="right"><DIV CLASS="footer"><A HREF="#top">return to top + <IMG SRC="/images/up.gif" BORDER="0"></A><BR> + © 2002 OpenForce, Inc.</DIV></TD> + </TR> +</TABLE> +</CENTER> + +<!-- End Footer --> + +</BODY> +</HTML> + + + + + 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 @@ <ul> <li> <a href=schedule.adp>Schedule</a> -<li> <strong><a href=detailed-todo.adp>Detailed TODO</a></strong> -<li> <strong><a href=left-to-finish-core.adp>TODO to finish core</a></strong> +<li> <a href=detailed-todo.adp>Detailed TODO</a> +<li> <a href=left-to-finish-core.adp>TODO to finish core</a> <p> -<li> <a href=nomenclature.adp>Nomenclature</a> +<li> <strong><a href=nomenclature.adp>Nomenclature: a dotLRN Primer</a></strong> +<li> <a href=architecture-overview.adp>Architecture Overview</a> <li> <a href=permission-overview.adp>Roles, Sections, and Permissions</a> | <a href=permission-api.adp>Permission API</a> <li> <a href=permission-portals.adp>Portal Permissions</a> -<li> <a href=architecture-overview.adp>Architecture Overview</a> <p> <li> <a href=sloan-bboard.adp>Sloan Bboard</a> <li> <a href=openacs/>Building OpenACS 4.x Applications</a> + +<p> + +<li> <a href=dotlrn-faq.adp>dotLRN FAQ</a> </ul> 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"] %> -<h2>dotLRN Nomenclature</h2> -by <a href=mailto:ben@openforce.net>Ben Adida</a>, part of <a href=./>dotLRN Documentation</a>. +<h1>dotLRN Nomenclature: a dotLRN Primer</h1> +by <a href=mailto:ben@openforce.net>Ben Adida</a>, part of <a +href=./>dotLRN Documentation</a>. (last updated: <i>28 February 2002</i>) <hr><P> -dotLRN is a <strong>Course Management System</strong> which means it -helps manage courses, but does not perform the actual instruction of -the courses. This document defines the <strong>nomenclature</strong> -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 <strong>Learning Community Management System</strong> +which means it helps manage communities of users and the exchange of +information therein. This document defines the +<strong>nomenclature</strong> 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. <p> +<h2>1. dotLRN Communities</h2> +The core concept within dotLRN is the <b>dotLRN User Community</b>. -<h2>Class</h2> +<h3>Community</h3> -A <strong>class</strong> 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. -<h2>Class Instance</h2> +<p> -A <strong>class instance</strong> 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... +<h3>Class</h3> -<h2>Student</h2> +A <b>class</b> is a topic of instruction, such as "Finance 101." A +class is <b><i>not</i></b> a community (this will become clearer +soon). -A student is an individual who is registered for a particular class -instance. +<p> +<h3>Class Instances and Clubs</h3> -<h2>Instructor</h2> +Two basic types of communities implemented in core dotLRN are +<b>Class Instances</b> and <b>Clubs</b>. 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. +<p> -<h2>TA</h2> +<h3>Open, Wait, Closed Communities</h3> -A TA (Teaching Assistant) is one who assists the instructor in the -teaching of the class instance. +Communities can have one of three <b>Join Policies</b>. A join policy +defines the process by which a dotLRN User can become a member of the +community. For now, we will consider only <b>dotLRN Full Access +Users</b> (see below for more information on other types of dotLRN +users). -<h2>Administrator</h2> +<p> -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 <b>open join policy</b> 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. -<h2></h2> +<p> +A community with <b>wait join policy</b> 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. + +<p> + +A communty with <b>closed join policy</b> is not visible to +non-members. Users become members only when explicitly added by the +community administrator. + +<p> + +<h3><i>in MIT SloanSpace</i>: Class Instances and Communities</h3> + +In MIT SloanSpace, dotLRN Communities are referred to as <b>SloanSpace +Groups</b>, while dotLRN Clubs are referred to as <b>SloanSpace +Communities</b>. + +<p> + +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. + +<p> + +Thus, dotLRN nomenclature, although internally self-consistent, is +entirely configurable by the user using global parameters. + +<h2>2. dotLRN Users</h2> + +A <b>dotLRN User</b> is an individual with an email address username and a +password to the dotLRN system. Each user is uniquely identified by +email address. + +<h3>Access Level: Limited or Full</h3> + +dotLRN users can have either <b>Limited Access</b> or <b>Full +Access</b>. + +<p> + +A <b>limited-access user</b> 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. + +<p> + +A <b>full-access user</b> 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. + +<p> + +<h3>Access to Private Information</h3> + +Certain users of the system may be <b>dotLRN Guests</b>, 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. + +<h3>System-Wide Roles</h3> + +dotLRN users have system-wide profile information. For example, in the +context of a Course Management System like MIT SloanSpace, they may be +<b>Professors</b>, <b>Students</b>, or <b>Administrative Staff</b>. +These system-wide roles define the user's specific profile in the +system as a whole, without regards to community-specific roles. + +<p> + +<h3>Community-Specific Roles</h3> + +dotLRN users have specific roles within the communities they belong +to. These roles are classified in two main categories: <b>dotLRN +Community Members</b> and <b>dotLRN Community Admins</b>. + +<p> + +<b>dotLRN Community Members</b> 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. + +<p> + +<b>dotLRN Community Admins</b> have all the privileges of normal +community members <i>plus</i> 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. + + +<h2>3. dotLRN Applets</h2> + +A dotLRN community is mostly a container of users and applets. A +<b>dotLRN Applet</b> (nothing to do with a Java applet) is a small +application that can be added to the community to enable new +functionality. + +<p> + +Examples of existing applets include: Discussion Forums, Surveys, +FAQs, News, Calendaring. These applets are <b>scoped</b> 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. + +<p> + +Certain applets are <b>community-centric</b> 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. + +<p> + +Other applets are <b>user-centric</b> 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. + +<p> + +<h2>4. Portals</h2> + +The entire dotLRN architecture is based on the <b>New Portal +Architecture</b>. The design and specifics of this architecture are +described in another document, but the basic terminology and concepts +are as follows. + +<p> + +<h3>Portal Page</h3> + +A <b>Portal Page</b> is a single page display of portal boxes. A +portal page has a <b>Portal Layout</b> 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. + +<p> + +A portal page can be configured so that the portal boxes can be moved +around the page by someone with appropriate permissions. + +<h3>Portal</h3> + +A <b>Portal</b> 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. + +<h3>Portlet or Portal Datasource</h3> + +A <b>Portlet</b> or <b>Portal Datasource</b> 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. + +<h3>Portal Element</h3> + +A <b>Portal Element</b> 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 <b><i>one</i></b> portal element that corresponds to +the instantiation of portlet within a portal page. + +<p> + +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. + +<h3>Portal Themes</h3> + +A portal page can be rendered in a given <b>Portal Theme</b> that +determines the look-and-feel of each box. The layout is <b>NOT</b> +determined here, only the specific look-and-feel of portal element +borders, buttons, and internals. + +<h3>Portlet Parameters; Portal Element Parameter Values</h3> + +For each portlet, there is a set of <b>Portlet Parameters</b>. For +example, the calendar portlet has a <tt>calendar_view</tt> parameter +that indicates whether the portlet should display data in the form of +a list, day-, week-, or month- view. + +<p> + +Each Portal Element has <b>Portal Element Parameter Values</b> 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 <tt>calendar_view</tt> parameter. + +<p> + +<h3>Portal Template</h3> + +A portal template is much like any other portal, except that it is +used as a template for creating other portals. + <%= [dotlrn_footer] %> + +