[Building Sakai] Automating the site creation process AND Sakai 3 Groups

[Ray Davis]

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 
disposable.

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.

Best,
Ray

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.
>