SAKAI09 Groups-Roles Notes

Owned by Former user (Deleted)
Last updated: Jul 13, 2009Version comment
12 min read

These are my rough notes from the July 2009 Sakai conference. Please feel free to add material and corrections of your own. – Ray

2009-07-07 - Interview with Daniel Tyger on groups and roles at Antioch University

Antioch is a widely dispersed multi-campus university which emphasizes collaboration within campus-wide communities, programs, departments, and cohorts, rather than rigid class-centric hierarchies. There's been a lot of dissatisfaction with Sakai's "tunnels". He's finding the Liferay Portal (currently being readied for production deployment) to be a much better fit.

They integrate the university's identity management system by creating hundreds of populated groups in their LDAP server. (E.g., "ANE-All", "ANE-Students", "ANE-Alum", "ANE-Staff", "ANE Human Resources", ...) In turn, LDAP provisions Liferay with corresponding "User Groups". Each group gets a community space. Within a community space (or just "a community"), there are two types of pages: public (to everyone, including search engines) and private (available on equal terms to every logged-in member of the community).

Another type of content control is given to individuals via their Profile area. Blogs, wikis, and so forth can be added there, and more fine-grained rights ("access", "write", "comment", "configure") can be assigned to "Roles". Roles are also used to combine User Groups to be treated as a unit. This allows for all kinds of like-minded or like-purposed groups outside the usual course groupings to obtain automated membership spaces. (NOTE FROM RAY: Liferay's use of "role" seems very odd to me and I may still be off on the details. FWIW, a Google search shows that it confuses some customers, as well.)

Many-to-most spaces should be discoverable, but Sakai interferes with several types of high-priority space/group searches and browsing: "Show me available spaces by campus", "by term," "by department," "for science clubs"...

We sketched out a possible model which broke the external compound-name groups into external groups ("ANE" – the New England campus) and external roles ("Student", "Alum", "Staff"), which could then be mixed and mapped into internal space memberships (including internal roles). Daniel thought that might help with two current problems: first, the sheer number of groups that were having to be separately administered; second, the difficulty of giving spaces to roles that cut across multiple groups (e.g., "All Alumni"). The idea of carrying some group and membership attributes from the external provider into the application space also seemed promising (e.g., "term" or "graduation year").

"Liferay roles are confusing, but so are Sakai role creations and realms. The fact is, I've been fully aware of Sakai's complexity for years (and still doesn't meet these needs, even when you try hard for "workarounds..."), yet in Liferay, within a week or so, we figured out their structure and it does meet all of these needs.

"I'll join your effort, if I can be of any use in discussion, planning, use cases, analysis, testing, etc. I'm just not a developer, though I consider myself pretty good at working with them to benefit the teaching and learning (and collaboration) side of the software.

"I'm a huge Sakai advocate and evangelist and want to see a richer future for the project. I have talked with many people in higher ed who have "looked at" (evaluated) Sakai as an option and have bailed for one reason or another, often (IMHO) due to problems / issues like these ones. Very often these schools are looking to get away from vendor lock, yet the feature gap analyses often don't wash in Sakai's favor...

"Why did Moodle spread so far and wide in almost the same time frame ( I actually don't enjoy teaching with Moodle nearly as much as I enjoy teaching w Sakai)? Because a high school student who is pretty savvy can download, configure, and install it within a couple hours and with some attention of a couple (non-developer) motivated people have it deployed in a pilot mode within a week at the school. You can have batch population licked in another few hours..."

2009-07-07 - Interview with Noah Botimer on Porfolio relationships

Since a portfolio typically belongs to an individual, it makes sense to think of "relationships" rather than "roles". These include:

  • Learner (for a student portfolio used for evaluation, this would be the owner)
  • Assigned Mentor (usually but not always an instructor)
  • Selected Mentor (the portfolio owner selects; in both online and real-world social terms, tends to blend into "respected peer")
  • Peer

Typical implied permissions and duties are "See a selection of my work", "Give feedback on a selection of my work," "Officially evaluate a selection of my work" (particularly associated with officially assigned mentors; real-world equivalents include Program Coordinators and External Reviewers).

Typical scenarios:

  • Create named groups of mentors (by discipline, for example).
  • Share this presentation with this group or this individual.
  • Search for a faculty member by name or email and add her to a group.

Besides being used for sharing with and evaluation by external parties, a portfolio is also a useful gathering of "my corpus of work" for the student's private use.

I asked about an authorization issue raised at the EDUCAUSE ID Summit: Students naturally want to keep their access to the work they've done for a course. After all, they did the work, they paid for the privilege, and in the real-world (or paper-world), they're able to keep copies of their returned papers and exams. But in old-style LMS systems, they often lose access to everything online after the course is over. Noah said that yes, this was a difficult and pressing problem for portfolios. Rather than wasting time on an over-engineered (and under-utilized) delegation approach, he'd prefer to let the usual informal human workarounds deal with potentially controversial areas (teachers not wanting their exam questions exposed; commercial course material providers asserting IP; discussion threads that bring up privacy issues) and focus on links to clear-cut authored-in-place material.

We agreed it might be useful to try treating the problem as one of export ("to my university-hosted portfolio," "to my Google Docs area", etc.) rather than one of permanent in-place access ("to the workspace for the class I took three years ago"). That models the real-world scenario more closely ("I got my paper back and now I can throw it away or put it in a binder") and it greatly reduces the ongoing support costs for the university. Think of a "dropbox" that potentially drops a copy to a private storage vendor...

2009-07-08 - Groups BOF

Nicola Monat-Jacobs, David Horwitz, Matt Morton-Allen, Michelle Wagner, Kirk Alexander, Keli Amann, Kristol Hancock, Steven Githens, John Norman, Ian Boston

John N.: Keep each step simple. Don't try to handle every complexity at once.
David H.: Searching or grouping by student residence is a missing requirement.
Other real-world integration points: student societies and clubs.
??: Our ID management system tracks a person's progress from prospective student on, granting increased access while they're an active member of the community, and then reducing access after graduation.
A type of override not yet supported in Sakai: "Opt out" (to decide not to participate in an online workspace to which I've been given access).
An important missing element of externally-driven memberships in general: transparency and explanation as to why and when they've occurred. "Why am I suddenly taking Chem 1a?" "When did this student join my course site? I need to make sure she's seen the introductory lecture notes." "How do I get out of this? (Talk to the registrar.)"
"Dropped" students shouldn't be deleted, since system glitches and human indecision are so common.

2009-07-08 - Integration BOF

Chris Holdorph, Joseph Calzaretta, Hui Jin, Kathy Faella, John Bush, Amber Parrish, Kim Huang, Zhiqing Zhang, Peggy Wang, Sara Chambers

Chris: There's no firm schedule yet for a Sakora update to match the latest IMS LIS drafts. Josh Ryan is working on loading CM through Sakora.
Missing scenario? Ask to join a site and get permission.
Sara may be able to devote resources to ID management integration.
Very widely distributed or multi-campus installations sometimes need different integration methods at the top of the workspace and membership hierarchies.

Templates/profiles for CM and LIS

The Sakai Course Management project was front-heavy: it did a good job with data collection, analysis, and modeling, then it got resource-starved and fumbled the final hand-off. One of our fumbles was not providing easy-to-understand (or better yet easy-to-use) tailorings of the interface. The abstract model was designed to handle a wide range of use cases. But when people with those use cases faced a set of complex decontextualized abstractions, they didn't see the connection. (E.g., deciding the CM API wouldn't help my institution because our classes don't have standard start and end dates.) Besides proving to ourselves that the model fit, we needed to deliver the fit, with standard "profiles" or "templates" to match some common scenarios.
Since IMS LIS doesn't seem vastly simpler and more intuitive than the Sakai CM API, we should try not to repeat that mistake.

2009-07-08 - Interview with Seth Theriault on groups at Columbia

Columbia manages all groups (no matter how small or ad hoc) via a customized version of Unix's group command, extended to include broader affiliations and namespaces (differentiated by conventional prefixes), one pseudo-branch of which contains "real" Unix groups. Here's the list of a librarian-instructor's affiliations:

ACISdialupNet   ACISlabUser     ACISvpn ALOT    ALOT1991
AcisLibraryLabUser      AcisNAVdownload AlumsAndLibFriends
CLIOrestricted  CNETrestricted  CUITPrintCUITStaff
CUITPrintInstructor     CUL_crab        CUL_culis       CUL_dpts-ldpd
CUL_dpts-lito   CUL_dpts-lito-cliogroup CUL_group-clio-opac
CUL_group-idesk CUL_group-reserves      CUL_proj-cerm-license
CUL_proj-fedora CUL_proj-metalib        CUL_proj-namespace
CUL_role-offsite-rare   CUL_role-offsite-withdrawal     CUMSFTlibrarian
CUNIX_cliop     CUNIX_cul       CUNIX_culpub    CUNIX_culweb
CUNIX_eres      CUNIX_guest     CUNIX_id_cul    CUNIX_illiadtest
CUNIX_ldpd      CUNIX_ldpddev   CUNIX_litodev   CUNIX_litoserv
CUNIX_litosys   CUNIX_lso       CUNIX_src       CUNIX_user
CUNIX_voyager   CUNIX_wheel     CUNIX_www       CUalumni
CUinstr_INAMK4320_001_2007_1    CUinstr_INAMK4320_001_2007_3
CUinstr_INAMK4320_001_2008_1    CUinstr_INAMK4320_001_2009_1
CUlibrarian     CUlibrarianFT   CUstaff Campus_Morningside
GROUPSPACE_cul  IDMACCESS_SEARCH        ISULPrintISULStaff
ISULPrintInstructor     OFFICER PAC     PAC1librarian
PAC1librarianFT PSA_Lerner      PSLbasicStaff   PSLnetwork
SLbasicStaff    SLinstructor    WIKI_cul        sisinstructor
CUcourse_INAMK4320_001_2007_1   CUcourse_INAMK4320_001_2007_3
CUcourse_INAMK4320_001_2008_1   CUcourse_INAMK4320_001_2009_1

"The SL* ones are based on the fact that I am a Columbia staff member, while ACIS* and CUIT* stem from my affiliation with the central IT organization, The PAC* ones are based on info from PeopleSoft. CLIO* has something to do with restricted Library resources.

"The CUNIX_* are mapped from Unix groups on our central servers subject to a 16-group limit per UNIX login (my login, slt, is different from my UNI, slt0, but this is uncommon). The WIKI_* ones are groups in a "namespace" called WIKI. Namespaces can be referred to for authz purposes and new ones created as needed. Group membership in all namespaces is managed via a command-line interface on the central timesharing boxes. The nice thing is that you don't have to know anything about hierarchy in order to use these affiliations for authorization purposes:

http://www.columbia.edu/acis/webdev/password-columbia.html http://www.columbia.edu/acis/webdev/affiliations.html

A Columbia-developed identity management system federates from multiple ID, group, and role sources, and publishes them as sets of affiliation IDs on LDAP records. The affiliations are passed on (in translated form) with authentication by a CAS-like WebISO called Wind. Jasig OpenRegistry tackles a lot of the same capabilities as the Columbia ID management system. Contact Benn Oshrin for more info.

Columbia currently runs both a legacy Prometheus-based LMS and Sakai. Integration of both systems with campus data is fairly limited. Daily LDIF feeds are parsed by Perl scripts into CSV files which are then cleaned up and merged into the Sakai user directory via Quartz jobs. Courses created by the registrar are used to create placeholder Sakai course sites, but enrollment data does not feed site memberships; instead, instructors or staff maintain memberships manually.

2009-07-09 - Short talk with Lucy Appert of NYU

Need shared ownership (e.g., student-authored work should be directly accessible by the student).
A spatially organized system in which students can create "rooms" in which they organize material with synopses and comments, with open discussion and collaborative dialog, finished off by export to a PDF. "Select paintings and sculptures for an exhibition, arrange them, and describe them in a way which explains the sequencing."
Support not just portfolios of one's own material, but also PLE repositories of germane content from other sources.
Uses ning to prototype the student area: a mix of private and public.
Truncated because another meeting was scheduled with Daphne later in the conference

2009-07-09 - Drupal authz

During the "Sakai for building apps" panel, Noah mentioned Drupal's flexible approach to setting up groups and roles. Drupal only has three roles out of the box (Anonymous, Authenticated, owner), but provides an easy way to create new installation-specific roles and assign their privileges. From an online introduction: "One thing to remember as you add modules in the future is that each module will more than likely have access privileges for different roles. This means that you can set access to that modules features depending on what role a user is assigned to. I have added modules many times and at first they do not seem to work. It is all because I forgot to give certain roles access to that module."

2009-07-09 - Visit to Harvard's iCommons team

Paul Bergen, David Heitmeyer, Colin Murtaugh, Susan Smith (user liaison)

Each school has their own CIO. 90% of courses at Harvard use iSites as their foundation; there are also 3-4k other sites (research, department, etc.).
Kennedy & Medical schools have their own site software. Particularly interesting to Sakai 3 might be the Medical school's social networking Profiles sofware, which has helped encourage a shared DB of faculty publications.
There's some Facebook integration, but the students tend not to use it. Ian & Nico: More use at Cambridge, but Cambridge's integration provides "What's new" integration might be more compelling.
The "InfoAdvantage" portal lets librarians provide targeted course content. They control that piece and it shows up inside the site. Includes embedded tool panels like "Chat with librarian." Multi-page topic boxes: whole mini-portal within the portal. Pre-configure course sites with placeholders that the librarians can manage independently.
Authz by contextual group: "Page Access Permissions: Same as site, Class List Only, Teaching Staff Only, Harvard Viewable, World Viewable, Custom Permissions, Hidden"
The only officially supported permission levels (aka "application roles") are "Participate" and "View", with "admin" an implied third choice.
Individual tools decide how to utilize the trio of permissions. (For example, a "Final Project Group Page" might handle its requirements by giving students "admin" rights to that page.) So far, no developers have asked for more than the three.
Add groups: Section groups, General groups, LDAP groups, Custom groups (schools, faculty, etc.), Course groups
"Custom" groups are installation-wide; "Course" groups are visible only within workspace.
"My Courses" draws on real course data. When the instructor clicks the link for the first time, she's given the option of creating a corresponding site.
"Course iSites" vs. "Standard iSites".
The clients of the administrative tools are the schools' distributed IT support staff. So those interfaces are rougher and more complex.
Sites can have Neighborhoods: a way to bundle sites to assign to administrators, and for the admins to modify them together. Not visible to end users. A site can be in multiple neighborhoods.
All sites and their topic boxes are linked to a hierarchical content repository which can be searched, browsed...
They're getting feedback that more consistency in error messages, etc. is wanted.
Paul on merged RSS feeds: "Can the instructor have the option to mute the change notification?" (A la Confluence's "Minor change" checkbox.)
John N: Thinking about expanding My Profile into CV, Portfolio type of usage. The contact type (aka the relationship) would be used to set access rights: "Colleagues can see my online presence; Students cannot."
DASH - open access publication system for Harvard, based on DSpace.

2009-07-10 - Hierarchical spaces BOF

Robin Hill organized, and provided a working definition: "worksites that contain worksites".
Matthew Buckett: At Oxford, any student can attend any lectures. So they follow through departmental hierarchies to find courses and lecture notes, and (if allowed) join the workspace area.
Other goals: Comprehensive sharing of content. Invisible administrative membership and privileges. Student project sites with full tools.
Netherlands - Edia - One large organization with different departments, each with their own look and admin spaces. Visibility restricted by top department namespace.
Large course site with section subsites.
Mega-site with full list of cohort members. Only useful for email lists at current. Self-organizing subdivisions would solve it. Student societies cut across cohorts, but they can find each other.
OpenSyllabus: User or integration service can link sites together for concept map and navigation. At HEC Montreal, SIS provides subdivisions of the class. A coordinator for the class as a whole. Sections control their own material. Coordinator oversees them, orders them... Each institution should be able to configure their own approach to a hierarchical site mapping.
John Norman: dotLRN site-within-sites were popular but not always understood. People would create overly complex tree that couldn't be browsed easily.
Visibility boundaries (ability to find material/activities across sub-areas) vs. Alert boundaries (ability to focus on one particlar area) vs. Access rights boundaries (ability to bound off area-specific memberships, data, activities, roles)?
Content repository sites separate from the classroom-activity-focused sites. One assessment definition referred to from multiple section gradebooks, etc.
Matthew: This site is managed by members of this other site. (Treating a site membership as a top-level global group.) They chain the realms but not the memberships. Don't want them to show up as members, but to get access.
Zhen Qian is interested in helping with the "course site" side of Sakai 3 groups-n-roles.

2009-07-10 - Interview with Open Syllabus team from HEC Montreal

Mame Awa Diop, Martin Montminy, YvetteLapa Dessap, Rémi Saïas

Martin: Configuration and change management have solved some similar problems. A central repository with versioning is a solid foundation. As I learned more about the project, it became plain that theirs was exactly the sort of problem that K2 / Sakai 3 is meant to solve. Nail, meet hammer.
Yvette: They already had a successful course authoring tool in production since 2004, and needed to move the functionality into Sakai.
Business school with 12K students, 700 teachers.
Add reference/citaton inside context of lecture rather than forcing leap to new page/tool.
Synchronization between copies (didn't want to have to go to native interface of tool).
Assignments integration: simplified face over service calls.
Section instructors add to base content but can't override it.
Ownership of rich tool-centric content is too coarse-grained. Need to assemble into seamless combined view.
Speculation: Open Syllabus + Agenda = a course-centric lens onto a multi-community Sakai 3 system.
Mapping to application-specific roles-and-permissions - currently solved by being all in one site.
Three-level case: Catalog description/requirements + Coordinate course outline + Sections. Could have more levels for convenient sharing of content.
Personal hierarchies (so section teachers can re-use their own additions in different instances, combining with the official courses' materials).