Index: openacs-4/packages/dotlrn/www/doc/nomenclature.adp
===================================================================
RCS file: /usr/local/cvsroot/openacs-4/packages/dotlrn/www/doc/nomenclature.adp,v
diff -u -N -r1.3 -r1.3.2.1
--- openacs-4/packages/dotlrn/www/doc/nomenclature.adp 3 Jul 2015 10:43:59 -0000 1.3
+++ openacs-4/packages/dotlrn/www/doc/nomenclature.adp 22 Jun 2016 08:25:00 -0000 1.3.2.1
@@ -3,7 +3,7 @@
dotLRN Nomenclature: a dotLRN Primer
by Ben Adida, part of dotLRN Documentation. (last updated: 28 February 2002)
+href="./">dotLRN Documentation. (last updated: 28 February 2002)
dotLRN is a Learning Community Management System
@@ -15,7 +15,7 @@
1. dotLRN Communities
-The core concept within dotLRN is the dotLRN User Community.
+The core concept within dotLRN is the dotLRN User Community.
Community
@@ -28,16 +28,16 @@
Class
-A class is a topic of instruction, such as "Finance 101." A
-class is not a community (this will become clearer
+A class is a topic of instruction, such as "Finance 101." A
+class is not a community (this will become clearer
soon).
Class Instances and Clubs
Two basic types of communities implemented in core dotLRN are
-Class Instances and Clubs. Class Instances 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
@@ -50,38 +50,38 @@
Open, Wait, Closed Communities
-Communities can have one of three Join Policies. A join policy
+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
+community. For now, we will consider only dotLRN Full Access
+Users (see below for more information on other types of dotLRN
users).
-A community with open join policy is visible in read-only
+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
+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
+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: Class Instances and Communities
-In MIT SloanSpace, dotLRN Communities are referred to as SloanSpace
-Groups, while dotLRN Clubs are referred to as SloanSpace
-Communities.
+In MIT SloanSpace, dotLRN Communities are referred to as SloanSpace
+Groups, while dotLRN Clubs are referred to as SloanSpace
+Communities.
@@ -98,18 +98,18 @@
2. dotLRN Users
-A dotLRN User is an individual with an email address username and a
+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.
+dotLRN users can have either Limited Access or Full
+Access.
-A limited-access user is one who has access only to class instances
+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
@@ -118,7 +118,7 @@
-A full-access user is one who has access to all browsing
+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
@@ -128,7 +128,7 @@
Access to Private Information
-Certain users of the system may be dotLRN Guests, meaning that
+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
@@ -143,7 +143,7 @@
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.
+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.
@@ -152,21 +152,21 @@
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.
+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
+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
+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.
@@ -175,28 +175,28 @@
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
+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
+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
+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
+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.
@@ -205,17 +205,17 @@
4. Portals
-The entire dotLRN architecture is based on the New Portal
-Architecture. The design and specifics of this architecture are
+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
+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.
@@ -227,23 +227,23 @@
Portal
-A Portal is a set of portal pages that are tied together so
+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
+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
+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
+portal page #2 is one portal element that corresponds to
the instantiation of portlet within a portal page.
@@ -258,24 +258,24 @@
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
+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
+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 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.
+of "day" for the calendar_view parameter.