Forum .LRN Q&A: Nominclature Cleanup

Posted by Carl Robert Blesius on

Early work on translating dotLRN has made it clear that there are some problems within the dotLRN nomenclature (in relation to groups/clubs/classes/communities).

This document may help outline the roots of the problem: (login as John White)

Openforce's solution was to make the community titles configurable, but the UI to change the titles ("pretty_names") is gone. Eventually we will need to unearth the UI for this again, but we should take advantage of the situation and make the standard dotLRN install consistent first.

Let me outline some inconstancies using the test servers:

  • Login as an admin and you are presented with the option of creating "Classes" and "Communites"
  • Login as an student and a portlet labeled "Groups" lists your "Classes" and "Communities", where you are also offered the chance to "Join/Drop a Class or Community Group" (Community Groups?)
  • Go to a "Community" and you are confronted with "Subgroups" within a "Community Home"
  • etc.

My main questions:

  • Why isn't a class a community?
  • Wouldn't making both classes and groups subsets of communities solve the problem?
2: Re: Nominclature Cleanup (response to 1)
Posted by Janine Ohmer on
Carl, I completely agree about things being inconsistent.

I think there are probably several answers to your question "Why isn't a class a community".  Here's mine:  classes are associated with subjects, departments and terms.  Communities aren't.  For example, you don't think of the term (2002 - 2003) when talking about the Running Club, and it's not associated with any department - it just exists, and members come and go.  I think making classes and communities two separate group types was deemed  to be the easiest way of supporting this.

I'm only guessing, of course - but it seems somewhat logical to me, at least if you accept that term/dept/subject is the right way to categorize classes.

(btw, when I say "group type" I don't mean that's how they're implemented - I just couldn't think of a better way to describe them)

3: Re: Nominclature Cleanup (response to 2)
Posted by Carl Robert Blesius on

What I am suggesting is making class "unequal" to group and making both class and group "equal" to community.

A class may be associated with terms, subjects, and departments, but that does not prevent it from being a community (I am looking at this from a user's perspective). I feel much more comfortable calling classes "learning communities" than "learning groups" (which the interface now implies).

I agree that the "Running Club" is not a "Class", yet a "Running Club" is both a group and a community.

For me the word "community" has broader implications than "group" and I would like to see this reflected in dotLRN, but this is something that the "dotLRN Group/Community" must decide ;-)

From Marriam-Webster Online (where the borders are grey as well - some definitions omitted [...] to help increase contrast):


1 : two or more figures forming a complete unit in a composition 2 a : a number of individuals assembled together or having some unifying relationship b : an assemblage of objects regarded as a unit c (1) : a military unit consisting of a headquarters and attached battalions (2) : a unit of the U.S. Air Force higher than a squadron and lower than a wing
1 : a unified body of individuals: as a : STATE, COMMONWEALTH b : the people with common interests living in a particular area; broadly : the area itself <the problems of a large community> c : an interacting population of various kinds of individuals (as species) in a common location [...] g : a body of persons of common and especially professional interests scattered through a larger society <the academic community>

This inconsistency was clearly a problem when introducing dotLRN to translators here in Heidelberg (these sessions have turned out to be useful dotLRN "usability" tests - where the users are untainted by SloanSpace).

I bring this up now because we will eventually need added levels of hierarchy in dotLRN 1.1 (seeing that we are going for a university wide deployment) and I have problems posting about it without having a solid foundation to work from.


P.S. In the process I suggest that we drop occurrences of "Clubs" in general ("Groups" covers that base and if someone wants to change the pretty_name to "Club" using the UI all the power to them). "Clubs" is just too specific.

4: Re: Nominclature Cleanup (response to 1)
Posted by Peter Marklund on
here is a sample of messages currently used in the dotLRN UI relevant to this discussion:

- <msg key="dotlrn_main_portlet_pretty_name">Groups</msg> (Group occurs in a few other messages such as "Join a Group" etc.).

-  <msg key="clubs_pretty_name">Community</msg>

-  <msg key="class_instances_pretty_name">Class</msg>

- <msg key="classes_pretty_name">Subject</msg>

Here is my take on the terminology as it currently stands. There are two types of communities in dotlrn - clubs (called Community in UI, i.e. student organizations etc.) and classes (called Subjects in the UI, the word subject doesn't even exist in the source code). As far as "Group" goes it seems to be used in the UI as a synonym for community (both clubs and classes). This means the structure we are dealing with is really quite simple, we just have to make sure our terminology is consistent (and avoid synonyms).

I always found the term subject in the UI quite misleading and I think it should really be class. The question then of course is what to call class instances and I don't really have a good answer to that. Maybe we can get away with not having a term for class instances though. A class instance is simply the community for a class given during a certain term.

5: Re: Nominclature Cleanup (response to 4)
Posted by Carl Robert Blesius on
Peter's Example:
<msg key="dotlrn_main_portlet_pretty_name">Groups</msg>
(Group occurs in a few other messages such as "Join a Group" etc.)

My suggestion:
<msg key="dotlrn_main_portlet_pretty_name">Communities</msg>
(this would be one of the few places Communities would show up, because it is one of the few places where "classes" and "clubs" are listed in the same place. The " Join/Drop a Class or Community Group" link that can be found in this portlet would then read "Join/Drop a Class or Group"

Peter's Example:
<msg key="clubs_pretty_name">Community</msg>
My Suggestion:
<msg key="clubs_pretty_name">Group</msg>

This <msg key="class_instances_pretty_name">Class</msg> would not change.

Subject doesn't really belong in this discussion, because it is just a a way of grouping classes. The confusion in the UI comes from there being no way to add a class using the "Classes" link on the admin page (please feel free to try it here: ). In order to add a class we have to use the "Subjects" link.

I am not really sure why we should even limit Groups (or clubs if you will) from being associated with subjects or terms. Why shouldn't we be able to associate the "Group" Ancient History Club with the "Subject" Ancient History and the History "Department"? Why wouldn't we want to be able to limit the existence of a group (e.g. Students Against War in Iraq) to one term? What happens when we add Research Communities? They are usually associated with departments and subjects as well.
I do not want to unnecessarily complicate things here (sorry for going off on a tangent). One thing after another.

Sloan has a naming solution that works for their users and because there is a way to define "pretty_names" they do not need to change their way of naming groups, clubs, or communities. Openforce stuck to their guns with the "anything that is not a class is a club" concept, which makes naming them something else in the standard dotLRN install pretty simple.

In the long term we want to keep things simple. We need to think about what kind of communities we are going to be adding to dotLRN in the future and how we can keep confusion to a minimum in the process.

I am not interested in turning everything on its head, but I am very interested in consistency in the standard install before 1.0 goes out the door. We need to decide which way we want to go on this: replacing "Subgroups" within "Communities" with "Sub-communities" or replacing references to "Communities" with "Groups" (and vice versa). The longer we wait on this the more the confusion an inconsistency trickles into the translations that we all have been working on for the last couple of weeks.

6: Re: Nomenclature Cleanup (response to 1)
Posted by Alfred Essa on
There is definitely need for cleanup and consistency. I need to read this thread more carefully and I have not done so. My questions are pragmatic:

1. What is the alternative being proposed?

2. What's the time and resource implication for .LRN release?

3. If (2) is significant, can't we wait until .LRN v1.1?

4. What is the migration path/costs/implications for existing users?

There's a tradeoff here between getting the release out as soon as possible and getting it perfect. At the same time, it would be advantageous to fix some fundamental flaws before dotLRN goes out the door.

7: Re: Nomenclature Cleanup (response to 6)
Posted by Carl Robert Blesius on

Okay... one last time (using html as an aid).

1. These titles in the dotLRN UI Now ->

    • Classes
    • Communities

Suggestion ->

    • Classes
    • Groups

2. The resource implications are limited because we are only talking about the UI here (this discussion is taking me more time than actually changing things would). Using the translation tools in 1.1 I could probably have it finished in 5 minutes. It is NOTHING like what I would like to see as part of the "Killing" dotLRN movement: making the dotLRN "subsites" model fit under an improved OpenACS subsites umbrella.

3. This should be decided on before 1.0. Even if we stick to the way things are we need to go through and clean things up.

4. It seems that OF made most instances of these titles parameters that can be changed using the UI. If this is true across the board the implications for existing users of dotLRN would be minimal.

8: Re: Nominclature Cleanup (response to 1)
Posted by Alfred Essa on

What would we call "subgroups" in the new scheme? Currently, both communities and classes can have subgroups as subsets.

9: Re: Nominclature Cleanup (response to 1)
Posted by Don Baccus on
I agree with everything except the use of "GROUP" in Carl's last example.  It doesn't really convey the sense that "clubs" would (though we can't use "clubs" because these communities are useful for far more than clubs)

"Subject" rather than "Class" is, I do believe, an MIT-ism ...

10: Re: Nominclature Cleanup (response to 1)
Posted by Carl Robert Blesius on
Modified version with html models:
  • 1. (now) GROUPS
    • Classes (w/ subgroups)
    • Communities (w/ subgroups)
  • 2. GROUPS
    • Classes (w/ sections)
    • Communities (w/ subcommunities)
    • Classes (w/ sections)
    • Groups (w/ subgroups)

Webster Online : sub·com·mu·ni·ty
Function: noun
: a distinct grouping within a community

Webster Online : sec·tion
Function: noun
11 a : one of the classes formed by dividing the students taking a course b : one of the discussion groups into which a conference or organization is divided

We just need something that makes sense for the standard install. If section doesn't work for an institution there needs to be a site_wide_pretty_name_parameter in addition to the one that a course administrator can set.

Subject=Class at MIT? That would be quite atypical. In dotLRN a subject is just a way of grouping classes.


Wow I just got stuck in a "group loop". I just added a subgroup to a subgroup to a subgroup to a subgroup of a class and started to get dizzy.

Fixing up 1 would be the easiest solution (EVERYTHING is a group and EVERYTHING can have subgroups). We will just have to worry about cleaning up various strings to reflect this.

It needs to be clear that these ARE the key terms in dotLRN. These terms are what dotLRN is about and they need to be as clear (and general) as possible. If we do not have a clean nomenclature in this area we will add confusion to the dizziness caused by the infinite number of "subgroups" possible.

This might be a factor when we start to think about how to add additional organizational units to dotLRN 1.1 -> we will need more ways of "grouping groups" than just departments and subjects (which at the moment are not actual groups in the subsite sense) and we will need to bind certain roles to these groupings (e.g. departmental administrator can administer classes in a specific department... or faculty). The question is if we use the grouping structures already possible in dotLRN or think of something else. We need to start talking about this as soon as we solidify the 1.0 release (it is getting harder to find people willing to contribute funds for the second version of a product when the first version isn't even out the door).

So what is it going to be: 1, 2, or 3? We need to know so we can start posting bugs and patches for these changes. The optimal window for the dotLRN 1.0 launch is approaching fast.