Note This document is posted under the Section Management space, and reproduced here for reference. Please post any comments on the original document

Integration of Web and Institutional User Groups

Ray Davis - 2005-08-25

An LMS (or CLE, or CMS, or "the thing instructors get to work with") is:

1. A collaborative web application framework which...
2. Draws on higher education institutional data and includes education-oriented applications.

This document describes some of the differences between "Draws on" and "Replicates".

An LMS that's controlled by the Registrar may begin by trying to keep the on-line collaborative world and institutional statuses in a one-to-one relationship. But instructors and students tend to need more flexibility, without necessarily discarding data in the process. To take two examples from the Berkeley Pilot Gradebook (which included integrated section management):

• An instructor may manually add a user to the course site as a "student". As far as most applications in the site are concerned, this user is just another student, no different from students who were given site access via integration with registrar data. But an application which wants to filter students based on enrollment status will need to know the difference. And friendly Site and Section Management applications won't encourage the instructor to make changes that will be overwritten by next morning's data synchronization.
• Multiple users might play an "instructor" role in a course site so that they can edit content and create and score assignments. But only one or two of those users have the official ability to submit a student's final grades to the registrar. A course grade submittal utility will need to refer to officially defined data as well as to LMS-managed data.

1. Membership Sets

(All these memberships implicitly include a "role" attribute. As described in Roles as Group-Scoped Permission Sets, it's possible to do without roles by exponentially increasing the number of user groups and fine-grained permission settings, but user descriptions of what's being modeled still usually include roles.)

1.1. Collaborative Web Framework Memberships

• Installation members
• Site members
• Site Group (not to be confused with a "Subsite")

1.2. Higher Education Institution Memberships

• Institution - All persons playing a role in an institution.
• School - Some institutions have an intermediate administrative level before departments.
• Department - Persons playing a special role in an academic or staff department.
• Course Offering - Users officially associated with a course (which also has a department, a name, an ID, number of credits, ...) in a given term.
• Primary Section or Class - Controls official enrollment status and who can assign the final grade. At a large institution, this is typically a Lecture, Seminar, or Independent Study section. At such institutions, the Course Offering membership is determined by the sum of all Primary Section memberships.
• Secondary Section or Class Section - Student membership here is a strict subset of the official enrollments for the Course Offering. At large institutions, the possible membership must be drawn from the sum of all Primary Section memberships or (less commonly) from a particular Primary Section's membership.

In an LMS/CLE/CMS, institutional data feeds into the collaborative web framework so that site memberships don't have to be redundantly managed, and so that information such as department names and meeting times can be easily integrated. Changes going from LMS web applications back into institutional data are rarer, but typically include final grade submission.

The remainder of this document will show a series of increasingly complex relationships between these two membership domains.

2.1. Self-managed sections

"Course" = Site

The simplest scenario uses institutional data only to populate site memberships. Definition and management of user groups within the site are left to applications.

Here are some example mock inputs for "Site Info" in such a scenario.

In all these cases, the only effect for web applications is that the Site membership is automatically populated with students (and possibly instructors). Sections would then be defined and managed via the Section Management application.

Although this is a very simple approach, it offers a number of attractions as an initial development target and potentially as a fallback for a real release.

1. LOW COST - It easily slides on top of Sakai 2.0. Since Sakai's current site management applications feed institutional data into a flat site membership, this completely eliminates short-term cross-project dependencies between Section Awareness and any other development efforts. Many fewer changes would be needed to existing site management tools and enterprise integration approaches. (Basically, the only dependency left is provision of an enrollment status (such as "Enrolled", "Waitlisted", or "Guest") for student site members. The Section Manager UI displays this status, but has no way itself to create or update that data. Obviously, until something provides it, the application won't be able to show it.)
2. HIGH BENEFIT - It accurately matches what the largest portion of institutions need to replace their current LMS. MIT and Stanford already create and manage sections within the LMS rather than reconciling with outside sources; U. Michigan and Indiana could stay backwards-compatible. Even UC Berkeley could scrape by to some extent. It's not everything we want, but it's definitely a step forward.
3. FLEXIBILITY - It allows us a choice of ways to integrate enterprise-defined sections in safe incremental stages. Section Management could add external services for creating and populating sections, and those services could be used by enterprise integration scripts. Or Section Awareness could share data tables with a CM-API-based integration. Or the business logic of Section Management and Section Awareness could be replaced with an implementation that uses core framework or CM-API services, while interfaces and UI stayed exactly the same. We have the flexibility of deciding which approach to take based on where other development efforts are, and other development efforts can work out their own schedules rather than rushing to meet the first Section Aware release.
4. SIMPLE RECONCILIATION - This is the first and simplest phase of reconciling externally-added and manually-added students (and possibly instructors). A student can be manually added to the site membership, and will then immediately available for assignment to any sections via Section Management. Presumably, there will still have to be some distinction made between manually-added and externally-added students, so that that externally-added students can be removed from the site when they're dropped from the data feed, but at least there's only one level to worry about.

2.2. Secondary Section Enterprise Integration

Course = Site = Primary Section

This would result in three membership sets as far as web applications were concerned:

• Site
• Disc 1
• Disc 2

In this scenario, institutional data is used to populate site memberships and to define and populate one level of site subgroups. This is what we've usually mocked up on whiteboards when talking about section awareness and enterprise integration.

Here, some more reconciliation rules need to be specified:

1. If student memberships of "Disc 1" and "Disc 2" are being managed externally, can a manually added student be added to one of the externally-managed sections? If so, how will conflicts be resolved?
2. Is the Section Management application allowed to add new manually-managed sections? If so, what happens if a new externally-managed section shows up with the same name?
3. Some institutions (UC Berkeley, at least) will want some of a site's secondary sections to managed externally for some initial period of time, but then switch to interal management at the instructor's discretion.
4. Some institution (no names specified so far) may want two-way enterprise integration, in which changes made through Section Management are then reflected in external data. (Again, it's unclear how manually added students would be handled in these circustances.)

To put off some of these difficult reconciliation issues, the first version of Section Management is specified to deal with external management on an all-or-nothing basis: either all the sections in the site are handled by Section Management, or else all the student section memberships are treated as read-only.

A prerequisite for this to be part of a functional system is for Site Management to be hooked up to enterprise integration in a more standardized and structured way than in 2.0. This will require UI and business logic changes to Site Management tools. From the high-level design point of view, this structure seems most likely to be provided by a Course Management API. At the very least, what Site Management displays as choices shouldn't conflict with what the Course Management API provides.

2.3. Multiple Primary Sections

Course = Site != Primary Section

This would manage the following web-application-visible membership sets:

• Site (based on P1, P2, and P3)
• P1
• P2
• P3
• Lab 1
• Lab 2
• Lab 3
• Lab 4
• Disc 1
• Disc 2

This turns out to be a very common use case for large courses. Course enrollments and grading responsibilities are split between several primary sections (generally lecture sections), while secondary sections and site membership are drawn from the combined population of all primary sections.

However, common or not, that use case isn't well conveyed by my primitive UI mock-up or by any APIs we've specified. For example, how can it be distinguished from what seems to be a less common case, in which a secondary section's membership must be drawn from one particular primary section, creating a tree (course offering trunk to primary section branches to secondary section leaves) rather than a common pool (primary section memberships feeding a combined course offering membership list which feeds secondary sections)?

Again, handling of manually added site members becomes more complex to specify. Do we let manually added students and TAs be assigned directly to a secondary section, or do we insist that they be assigned to a primary section first?

This is where the Course Management API as currently defined might become problematic. Since course offering, primary section, and secondary section all have different real-world properties, collapsing them into a two-object abstraction might end up obscuring some of their characteristics instead of efficiently modelling them. The CM-API team may decide to support the distinctions more directly.

2.4. Multiple Courses

Course != Site != Primary Section

Finally, we know that some instructors will want to combine the memberships of multiple courses to populate a single site. As far as the higher education institution is concerned, these courses are not cross-listed, and so the relationship won't appear in enterprise data.

This might be intended to result in the following membership sets as far as web applications were concerned:

• Site (based on Psyc 201 P1, Phil 212 P1, and Phil 212 P2)
• Psyc 201 P1
• Phil 212 P1
• Phil 212 P2
• Phil 212 Disc 1
• Phil 212 Disc 2

Or it might not. Were we right to leave out the secondary section definitions for "Psyc 201"? Were we right to start prefixing all the group names with a short course name? The desired results haven't been documented.

Similarly, we haven't documented what the rules will be for manually added students. Can one be put into "Phil 212 Disc 1" without being part of any "Phil 212" primary section?

Frankly, once we get to this level of complexity, I doubt that one set of generally applicable desired results can be documented. To match what real-world instructors want, we'd need Site Management to break apart the notions of membership feeds and defined site groups. That way, if what the instructor wants is something that looks more like a collaborative project site whose memberships happen to be populated automatically by course enrollments, the instructor could say "Use institutional data to create memberships but don't describe them internally as groups." Conversely, if the instructors are dealing with something more like an informal cross-listing, where announcement tools and gradebooks and so on need to be able to display the course names and sections in queries and filters, then the instructor could say "Define site user groups named such-and-such based on this institutional data."

At this point, web framework data and institutional data can no longer be said to be one-to-one in any sense. Either the data has to come from different sources and be displayed in different ways, or some data will have to be obscured or lost. That is, an application which needs to query the Collaborative Web Framework memberships (site memberships, site groups) won't be able to deduce them purely by querying Higher Education Institution memberships (course offerings, primary sections, secondary sections), or vice-versa. The data structures have been related but they're not identical. (Consider the distinction mentioned at the top of this document between someone who is playing an "instructor" role in the site and someone who has "instructor of record" status for students in a particular primary section.)

Similar UI and data modelling issues will arise if sites are populated from multiple (but not all) secondary sections, or if the institution wants to restrict a secondary section's membership to a particular assigned primary section rather than to the sum of all primary sections.

These are not our primary use cases (and so we shouldn't prioritize them), but they are known use cases (and so we should keep them in mind).