[Building Sakai] Automating the site creation process AND Sakai 3 Groups
ray at media.berkeley.edu
Mon Nov 23 10:06:17 PST 2009
I think of the Oxford admin case as an example of using cross-context
(or cross-site) group references: there is a "Course Administrators"
space whose Sakai-managed membership list is used in many other contexts
(or sites). When the only purpose of such a "site" is reaching
group-management capabilities, then we could think of the "site" part as
Another approach, though, is to make "navigable collaborative spaces"
less dependent on traditional site creation and management. We often
hear about institutions who would like to do something like "let
academic department administrators have authoring access to all sites
associated with courses in that department." If the necessary
information to set this up is available externally, then there's no need
to explicitly manage "sites".
Example: Classics Admin Matthew logs in and sees on his dashboard:
* My Contacts
* My Workspaces
* My Department
** Byzantine Greek
** Latin 1a
*** Latin 1a 02 2009
*** Latin 1a 03 2009
If information on Matthew's department and its courses and their
enrollments is available to Sakai 3 (via IMS LIS or Kuali or LDAP, say),
that information can be used by Sakai 3 in a site-like way *without*
requiring explicit site creation: view the enrollment history of Latin
1a, look at course catalog data for Byzantine Greek, send messages to
the instructors for Latin 1a 03 2009, etc. Sakai 3 capabilities (whether
"content authoring", "pedagogical activity", or "group management")
could be smoothly layered on non-Sakai-hosted functionality only as needed.
On 11/23/09 2:09 AM, Matthew Buckett wrote:
> 2009/11/22 John Norman <john at caret.cam.ac.uk>:
>> The Oxford document makes an interesting read as an example of a 'group' structure that
>> doesn't really need a site.
> Just for a bit of background. The reason used a site is that the tools
> (Site Info) for managing this group could be reused.
> In a short summary any user who has a permission in an admin site gets
> it in all sites that are managed by that admin site. This allows for
> people to admin large numbers of sites (by the fact they have site.upd
> in the admin site) without being members of them. It also allows for
> external auditors to get read only access (content.read, site.visit,
> etc) to sites.
More information about the sakai-dev