Sites and groups

[Michael Feldstein]

Could somebody please point me to the documentation (to the extent
that it exists) regarding how site and group creation/representation
are going to be handled in K2? I know that these two concepts are
distinct from each other, but that's about all I know at this point.

Thanks.

[Ian Boston]

Michael,
In K2 these are separate concepts.

Groups are described here
http://groups.google.com/group/sakai-kernel/web/users-and-groups-implementation

I am in the process of writing a description of how the Sakai use
cases map to this implementation.

Sites are locations in the content system, that have some associated
metadata that makes them a site. With each site is associated a list
of Groups.

This is one of the last things that we did in Agnostic K2, and hence
there documentation, only code, however once I have done the page on
Group use cases, I will move on to describing this area.

Ian

[Michael Korcuska]

The question that lingers for me is how permissions are assigned when
a group is given access to a site. We discussed this to some degree
quite awhile ago near middle of this thread:

http://groups.google.com/group/sakai-kernel/browse_thread/thread/e9d6d13abbbd96dc

The overall conception I have is that groups have a very simple role
system (owners and members? maybe admins too?), essentially only what
is needed to manage membership in the group. Sites may have a more
complex set of roles and roles are what give users permissions to do
things in that site. We need a mechanism for a default mapping of
group roles to site roles and for changing that mapping for individual
users (or for certain site types?). And, of course, changing fine-
grained permissions for individual users in a site should be possible,
but I think that's a separate issue.

There's a bunch of issues around the group role<->site role
relationship, I think, that I won't try to elucidate right now.
Perhaps Sling has a way of handling this already?

Michael

--
Michael Korcuska
Executive Director, Sakai Foundation
mkor...@sakaifoundation.org
phone: +1 510-931-6559
mobile (US): +1 510-599-2586
skype: mkorcuska

[Ian Boston]

I will be documenting this shortly.
Ian

[Cris J. Holdorph]

Another thing that's worth considering up front is the type of behavior
that the Course Management API tried to add to Sakai 2.x "after the
fact". The CM-API was/is a great addition to Sakai 2.x, but nothing can
help that it's obvious it was considered/done "after" Sakai
sites/groups/etc was already done. Just one example is the quartz jobs
that exist to keep data in sync.

It would be nice if we could consider the same concepts the CM-API tried
to handle, earlier in the development of the Sakai 3/kernel 2
sites/groups work.

---- Cris J H

[Ray Davis]

This might be a good time for me to duck out of lurk mode for a couple
of minutes, since just this morning I was at a phone meeting on this and
just last Friday I attended my first MACE-paccman meeting:

http://middleware.internet2.edu/paccman/

Very briefly, I expect the upcoming IMS LIS standard (and its attendant
implementations and clients) to be very close to the 2.4 Sakai CM API --
which isn't exactly a coincidence :) -- but you're absolutely right that
the biggest integration issues aren't there anyway. They're in Sakai.

And, as I've come to understand the problem, *that* isn't exactly a
coincidence either. Figuring out how to handle federated authorization
(which is what an LMS/CLE needs in a large American university) is far
more difficult than just figuring how to describe one of the *sources*
of that authorization.

Given the K2 team's very different working priorities, I've been trying
to stay out of their hair on this stuff as much as possible. My hope is
that we can get another development project ramped up fairly soon to
start pushing in a practical, hands-on way at the integration
boundaries. So far I'm not too worried about the immediate K2 work
painting 3akai into a Sakai Old Skool corner. We have far more knowledge
about cross-institutional requirements now and many more potential
collaborators, and Ian seems to be breaking the right ice in adding more
dynamic authorization decisions to Sling.

Best,
Ray

[John Norman]

Ray

As someone familiar with the work, can you resurface the requirements
around the CM-API and relate it to the IMS specification.

Chris

Could you work with Ray to incorporate an understanding of the Sakora
work?


I know this stuff is important, but I am not sure where to go to get
the straightforward explanation of the issues from Sakai's perspective.

John

[Clay Fenlason]

I'd also be interested in seeing this worked up in a clear way. In
the interim, I can say that we've been wrestling with these issues in
Sakai in three main areas:

1) The enrollment structures that the registrar needs do not map well
to the preferred structures for course site management, which vary
widely with both course and instructor. My feeling is that the root
issue in a majority of cases is very large courses and the sorts of
coordination or delegation of control models that work for them.
Another key complicating factor are of course graduation requirements
and majors, and how many courses are "cross-listed" or
interdisciplinary, so that there is a path-sensitivity to your
enrollment even if it makes no difference within the activity of the
course itself.

2) Grade reporting prevents a unidirectional simplification of the
problem: since at the end of the term we have to once again resolve
course site memberships into accurate enrollment lists the SIS
understands, it's not enough to simply allow arbitrary clumping and
clustering on the Sakai side. Sakai must push as well as pull (or at
least pull and then later be pulled).

3) Insulating ourselves from proprietary idiosyncrasies or breaking
version upgrades of the SIS. Not just a technical problem, as every
new cycle forces meetings between teams with very different world
views to get together and explain once again how things really work,
and try to locate the shifting common ground. Technical solutions are
often superstructures of administrative powerbases.

~Clay

--
Clay Fenlason
Director, Educational Technology
Georgia Institute of Technology
(404) 385-6644

[Ray Davis]

John: Yes, once the IMS LIS is officially released (if you're not
actually on the committee, you're not allowed to look at the drafts), I
guess I'll probably be asked to produce a mapping and migration plan,
probably with many emails to the Sakora team. (Although I've been wrong
about assignments before!)

Clay: Excellent starting list. The CM API and the IMS LIS which followed
were basically attempts to do a much better job on problem 3 than was
previously available, and as far as I can tell, they juggle the
requirements for flexibility and practical utility pretty well (albeit
at the cost of some complexity). Since CM came out, I only know of one
major use case that it missed, and that one only seemed to require a
slight change to the model. However, standardizing a plug to the outside
world doesn't radically simplify areas 1 or 2 or other Sakai-internal
sides of the integration. We can get the data through a standard API,
but then we still have the problem of dealing with it usefully.

I just posted a massive backgrounder on my blog, BTW:
http://ray.media.berkeley.edu/blog/?p=43

Best,
Ray

[Ian Boston]

Ray,
I don't have access to the IMS LIS, but you do have access to the
JSR-283 spec and Jackrabbit/Sling, and all the AuthZ, User & Group
information in this group and the code base.

Could you have a look trough the information on the kernel group
relating to 283 and sling and give us a view on where their may be
potential gaps with what you are proposing.

Since we made the switch to OSGi+Sling I have had to throw away the
original user and groups structure and the the authz work and adopt
the approach used in Sling with some mild extensions, not to do so
would be a major rewrite of a number of areas of Jackrabbit and Sling.
If its not going to be possible to support your use case, then I think
we need to know now, before we waste any more time.

Thanks
Ian

[Michael Feldstein]

I'm checking with some colleagues to find out whether we can get
permission post the draft version of the LIS course information model
to this group. In the meantime, here are the basics:

- Each course section as defined by the registrar is sent over as a
Course Section record. A course section in LIS is intended to
represent a group and be semantically decoupled from any notion of a
course site.

- Each course section can have one Membership record associated with
it. This record maps which persons (sent in Person records and
identified by the SourcedIDs of those records) are members of the
Course Section.

- Course Section records may be semantically linked to each other by a
Section Association record. The point here is to deal with the
mismatch between the SIS and the LMS. For example, two cross-listed
course sections may be separate from the registrar's purpose because
they are in different departments, satisfy different degree/major
requirements, etc., but the union of the two sections is, in the
physical world, one group of students taught by one teacher in one
room at one date/time. In LIS, the Section Association record
preserves the registrar's view while providing the LMS with semantic
hints that could be useful for things like course site provisioning.

- The LMS is expected to persist section membership information, in
large part to make grade reporting possible. In other words, if the
LMS merges two groups of students from different sections into one
course site, the LMS grade book must be able to remember which
students are members of which original sections.

- Course Section records may have (but are not required to have)
parent Course Offering records which, in turn, may have parent Course
Template records. These record types are very similar to but not
identical to constructs in the CM-API. Cris probably knows more than I
do about how the two map to each other in practical experience.

- m

> >> On Fri, May 1, 2009 at 1:46 AM, John Norman <j...@caret.cam.ac.uk>  

> >>>>>>http://groups.google.com/group/sakai-kernel/browse_thread/thread/e9d6...

>
> >>>>>> The  overall conception I have is that groups have a very simple
> >>>>>> role
> >>>>>> system (owners and members? maybe admins too?),  essentially only
> >>>>>> what
> >>>>>> is needed to manage membership in the group. Sites may have a  
> >>>>>> more
> >>>>>> complex set of roles and roles are what give users permissions  
> >>>>>> to do
> >>>>>> things in that site. We need a mechanism for a default mapping of
> >>>>>> group roles to site roles and for changing that mapping for
> >>>>>> individual
> >>>>>> users (or for certain site types?). And, of course, changing  
> >>>>>> fine-
> >>>>>> grained permissions for individual users in a site should be
> >>>>>> possible,
> >>>>>> but I think that's a separate issue.
>
> >>>>>> There's a bunch of issues around the group role<->site role
> >>>>>> relationship, I think, that I won't try to elucidate right now.
> >>>>>> Perhaps Sling has a way of handling this already?
>
> >>>>>> Michael
>
> >>>>>> On Apr 30, 2009, at 18:46, Ian Boston wrote:
>
> >>>>>>> Michael,
> >>>>>>> In K2 these are separate concepts.
>
> >>>>>>> Groups are described here

> >>>>>>>http://groups.google.com/group/sakai-kernel/web/users-and-groups-impl...

[Ray Davis]

"Now" is not a realistic deadline given what "the use case" consists of
and considering that I'm not currently assigned to this task, but I'll
see what I can manage. FWIW, fellow K2 team members like Clay and the UC
Davis team also have plenty of experience with authz integration issues.
I just happen to have worked on some projects that focussed on them
directly.

I thought, however, that the K2 team was (very sanely) trying to limit
its immediate target to more familiar and limited social-networking
needs rather than trying to immediately take on the full set of LMS/CLE
use cases everywhere?

Best,
Ray

[Clay Fenlason]

You're right, Ray, that we're not trying to take on the full set of LMS use cases, but even our more basic requirements have taken us to the point of needing to patch Jackrabbit and/or Sling (along with attempting to negotiate with those projects the best way this could be done), and so if we can see that we're going to need to press on these issues even harder, I think the concern is that we may want to adopt another strategy even now.

-Clay

>>>>>>>> There's a bunch of issues around the group rolesite role

[Ray Davis]

Understood, but surely it's all a matter of pragmatics. The CM API has
been a stable part of Sakai since 2.4 and a tutorial's been on
Confluence since December 2007:
http://confluence.sakaiproject.org/confluence/display/SAKDEV/Course+Management+Integration
For testing K2 against real-world use cases, I feel I can rely on the
integrations experience of the GIT and UCD K2 members. On the very few
occasions I've thought some tricky nuance might have been missed, I've
spoken up on list, but since I'm not assigned to the project, I run a
high risk of pushing the team off-topic.

OSGi, of course, is completely agnostic about authorization approaches.
I admit that one of the things that surprised me about the decision to
base the kernel squarely on JCR was the probable mismatch between the
authorization requirements of a typical content repository and the
authorization requirements of an LMS/CLE. But I wasn't involved in that
decision, and as I wrote in my first message on this thread, it
certainly looks (to my non-expert eyes) as if Ian's taking an excellent
approach to expanding Sling's and Jackrabbit's reach.

Best,
Ray

[Ian Boston]

Ok I understand you don't have time and are not allocated.
If you have any pointers/links to any documented uses cases that you
have locally could you please share them. AFAIK the current model
works for the beading edge institutions and the early adopters. I
don't want to be in the same possition as Sakai2 was, retrofitting a
CM system with comporomises. Hence I am asking the questions now, and
checking the evolving implementation against supplied use cases.

BTW, we are certainly not limiting the implementation to cover social
networking as most of the early adopters will be running full courses.

Any information you can share would be very helpful. (naturally at
minimal effort on your part if possible :))
Ian

[Ian Boston]

Michael, thank you, comments inline:

On 1 May 2009, at 19:53, Michael Feldstein wrote:

>
> I'm checking with some colleagues to find out whether we can get
> permission post the draft version of the LIS course information model
> to this group. In the meantime, here are the basics:
>
> - Each course section as defined by the registrar is sent over as a
> Course Section record. A course section in LIS is intended to
> represent a group and be semantically decoupled from any notion of a
> course site.

This fits the model K2 is persuing exactly.

>
>
> - Each course section can have one Membership record associated with
> it. This record maps which persons (sent in Person records and
> identified by the SourcedIDs of those records) are members of the
> Course Section.

yes, no problem here.

>
>
> - Course Section records may be semantically linked to each other by a
> Section Association record. The point here is to deal with the
> mismatch between the SIS and the LMS. For example, two cross-listed
> course sections may be separate from the registrar's purpose because
> they are in different departments, satisfy different degree/major
> requirements, etc., but the union of the two sections is, in the
> physical world, one group of students taught by one teacher in one
> room at one date/time. In LIS, the Section Association record
> preserves the registrar's view while providing the LMS with semantic
> hints that could be useful for things like course site provisioning.

I think that we have this covered, although it might require what we
are calling Dynamic groups. I think its would be worth mapping out
exactly how this will work to make certain that nothing is blocked. I
will have a think about this one and try and draw some mappings.

>
>
> - The LMS is expected to persist section membership information, in
> large part to make grade reporting possible. In other words, if the
> LMS merges two groups of students from different sections into one
> course site, the LMS grade book must be able to remember which
> students are members of which original sections.

Yes, absolutely, K2 stores its view of groups and persists them in is
user and group structure, all changes are also versioned with
timestamps, so even if associations change we can look back in time.

>
>
> - Course Section records may have (but are not required to have)
> parent Course Offering records which, in turn, may have parent Course
> Template records. These record types are very similar to but not
> identical to constructs in the CM-API. Cris probably knows more than I
> do about how the two map to each other in practical experience.

parents of parents of parents etc etc etc are no problem. I haven't
thought exactly how to represent templates at the moment other than to
mark group structures as being templates and to take copies. We don't
at the moment have linked templates where changing the template will
cause changes throughout the system. That would be an extra change to
the standard User and group structure. It would probably follow an
"extends" type pointer between the real and template group.

I am fairly certain this is not going to be a problem, but it will
need definition surrounding how to achieve it in the current structure.

-----

Thank you for this insight, very useful, if you get permission for any
more that would be great. I will pull these into the documentation set
I am building.

Ian

[Ray Davis]

Michael's preview is very helpful, I agree! The Oracle marketing data
sheet's not a bad place to start, either:

http://www.oracle.com/industries/education/pdfs/oracle-education-student-integration-pack-ds.pdf

Clay's already described some good use cases to try "thought experiment"
implementations against, and I bet he, Jon, and Thomas can come up with
others with a little prompting. :) For myself, to repeat some earlier
links:

http://confluence.sakaiproject.org/confluence/display/SAKDEV/Course+Management+Integration
http://ray.media.berkeley.edu/blog/?p=43

Following on from there:

http://confluence.sakaiproject.org/confluence/pages/viewpage.action?pageId=46727298#comment-46727473
http://confluence.sakaiproject.org/confluence/display/SECT/Integration+of+Web+and+Institutional+User+Groups

As you can see at those links, I can spout pretty much indefinitely on
potential use cases. But in terms of being able to say, "Yes, this bunch
of fast-moving technologies with which I have no experience is capable
of meeting these use cases in the following ways" (or "No, this
bunch....") -- well, I think you'll be safer relying on in-house K2
expertise rather than on someone who's just been playing catch-up on a
part-time basis before the *real* fun begins.

I do look forward to the real fun beginning, though. It sounds as though
that might even be next week. :)

Best,
Ray

[Ray Davis]

> On 5/1/2009 10:32 AM, Ian Boston wrote:
> Ray,
> I don't have access to the IMS LIS, but you do have access to the
> JSR-283 spec and Jackrabbit/Sling, and all the AuthZ, User & Group
> information in this group and the code base.

...

A bit out of sequential order, but in case my earlier message wasn't
clear: *I* don't have access to the IMS LIS working specification
either. I wasn't being coy about its status -- I was expressing
suspense. :)

Best,
Ray

[Michael Feldstein]

One other point worth making here is that Unicon has, in fact, gotten
the CM-API to work with LIS and I'm not aware of any major issues they
had in terms of matching up the information models. (Again, I defer to
Cris here.) If that's right, then there's every reason to believe
that, if K2 can handle the CM-API's groupings, then it will be able to
handle LIS's groupings.

- m

> ...
>
> read more »

[Michael Feldstein]

Actually, let me modify that statement a little bit. The Sakora
project does not currently handle section associations. As I
understand it, one of the reasons for creating the CM-API was that
nothing like section association records existed in the standard. So,
lacking good hints from the LMS, a Sakai-internal mechanism for
combining sections appropriately was developed. Going forward, it
would be good to have a mechanism that supports both internal and
external cues for combining sections.

- m

> ...
>
> read more »

[Clay Fenlason]

There's something I think we lose in these kinds of discussions, but
it's likely not relevant for K2 so I'll just slap down a post-it here
for future reference: we need to group people by what they do together
more than their designations.

An easy example with CM API overlap is labs vs. sections. Often these
are the same sets of people, but they may have different instructors
or assessment workflows, meet at different times, and they certainly
have different activities. What's the best user-centered
representation of this? A different site? A different set of pages?
A sub-site of some sort?

What is the proper data model representing my lab partner? I pose the
question rhetorically, but I want to think about what these standards
are leaving out - the real-world associations that better apprehend
the learning environment. Is this another place for social networking
devices to intervene?

~Clay

[Christopher Holdorph]

I'd like to say something really insightful, but all I can do is say,
"Yup". Michael has it right. The Sakora effort was able to match
most of the IMS spec up with the CM API pretty easily with the
exception of the IMS section association concept. That did not have a
simple CM API concept, at least in the main hibernate implementation.

---- Cris J H

[Ian Boston]

Ok thank you, I will go and read.
Ian

[Ian Boston]

Replying to the head of the thread:
One think to be aware of in all of this from a K2 point of view is
that it contains none of the Sakai 2 implementation in users, sites,
realms, roles groups or sections.
It also does not contain the CM API.
At the moment I don't have a strong view on how to connect the K2
Users/Groups/Sites (NB K2 terminology != Sakai2 terminology) to IMS
other than it is an important use case that needs to be supported, So
I don't know how the CM API and other related work might evolve
relative to K2.

One thing to remember is that K2 is based on a push model, rather than
a dynamic lookup. The Dynamic lookup that is in place, is only
intended to be used when external rules systems are required to
determine membership of Dynamic Groups (of all types).

So it will receive a stream of provisioning messages or events that
will modify its internal structure, rather than pulling the
information dynamically.

Ian

[Ray Davis]

I'll try to respond to some of these messages in order -- apologies
for any fragmentation.

The CM API effort began because the existing IMS "enterprise
integration" standard (along with all other related standards we could
find) was too vague to practically meet our integration use cases in
any way that could be truly transportable from institution to
institution or application to application. (Sections were a big part
of that, but still only one part.) In our one meeting with
representatives working on the new standard -- last year sometime, as
I remember -- it seemed that most of the concepts were being kept in
place but that there had been some (understandable) confusion about
how to use the CM API's vaguest "catch-all" object: "Course Sets". Not
being part of the closed group which determined the new interface, I
don't yet have access to documentation on what you call a "section
association", but it could be that it's playing a similar role without
the committee realizing it.

Best,
Ray

> ...
>
> read more »

[Ray Davis]

If there's one thing I'm certain of after all these years, it's that
"the best user-centered representation" of existing higher educational
structures in an open collaborative web site framework is
*undecidable* as a general question. We have real-world use cases for
virtually every mapping I can imagine.

Which is why our first emphasis was on defining a way for the web
application to reach those structures -- classes, sections, enrollment
records, official instructors, departments, and so on -- unambiguously
and without any noise from assumptions made inside the web application
framework. That way it becomes possible to cut through the concerns of
(say) a discussion board to get to real-world associations when
they're needed -- for example, to show lab meeting times or to give
permission to submit final grades. And we allow at least the
possibility of letting a particular discussion section have its own
site, or giving it special rights in an area within a class site, or
letting it join a cross-departmental Rhetoric for Discussion Sections
site.

Best,
Ray

On May 1, 6:30 pm, Clay Fenlason <khomo...@gmail.com> wrote:
> There's something I think we lose in these kinds of discussions, but
> it's likely not relevant for K2 so I'll just slap down a post-it here
> for future reference: we need to group people by what they do together
> more than their designations.
>
> An easy example with CM API overlap is labs vs. sections.  Often these
> are the same sets of people, but they may have different instructors
> or assessment workflows, meet at different times, and they certainly
> have different activities.  What's the best user-centered
> representation of this?  A different site?  A different set of pages?
> A sub-site of some sort?
>
> What is the proper data model representing my lab partner? I pose the
> question rhetorically, but I want to think about what these standards
> are leaving out - the real-world associations that better apprehend
> the learning environment.  Is this another place for social networking
> devices to intervene?
>
> ~Clay
>

> ...
>
> read more »

[Ray Davis]

Also, Clay, I'm glad you've brought up social networking. As regards
authorization, the job of integrating general collaborative web
applications with SIS and personnel data isn't that much different
than the job of integrating locally defined groups and roles with
groups and roles defined inside Google Groups or Facebook or other
community sites. That's one reason I'm interested in the efforts some
American universities are making to use Google's application engine:
it abstracts the problem to something of interest to a wider
population of developers.

Best,
Ray

[paulbr]

Just scratching down some thoughts which are much less coherent than
what's gone before. They're mostly questions rather than answers and I
need to ruminate some more on them. But in case they're helpful I'll
inflict them on you :)

I've been reading a number of the linked resources today, I'd love to
see more of the LIS stuff too, and the CM is something I'm not
terribly familiar with - we use a group provider connected to an
external authz system which deals with authz for a number of our
services based on enrolment, user type, employment org unit, etc.
I've always wanted to broaden this into a more generic attribute and
rule based authorisation system. I think MACE grouper is the closest
thing I've seen to this anywhere.

Subsites

A site has one or more groups as members. Sometimes there will be a
need for different groups within a site to have their own instance of
or context for a tool - subsites? These often map to sections in the
standard terminology.

May include situations where a subject offering has one or more groups
for lectures, a number of tute groups, lab groups etc. So they have
some stuff in common, other stuff is specific to a subgroup.The
subsites model assumes we create new instances of tools or services
for the small group. Perhaps we could use filters to give them a view
specific to their section? In some cases we could also allow them to
select the broader set - the user can choose how much info to get.

Should these subsites or section groups or whatever allow for self
selection? Should students be able to self-organise into sub groups?
The filter model would allow for multiple concurrent sub group
memberships.

Groups within Groups

Apparently LIS allows for mapping student admin groups based on
enrolment in structures relevant to admin into groups relevant to how
teaching is delivered using Section Association records. This looks
much the same as allowing groups to be members of groups - so we could
say a site membership group had a number of subject offering or
section groups as members. We could (would?) attach different groups
to individual resources allowing finer grained authz within the site.
So the aggregated group gives site membership but another role gives
resource access.

Can tools be configured to select based on current group - could a
user with multiple group memberships allowing access choose to see the
results only obtained from one or more of them? Do tools/widget
services whatever normally filter the resources they access based on a
user's memberships and not a site's?

Just what do we want to protect - is authz on a resource, on a
resource in a site context, and/or a resource in a site/tool context?

What is a site? I think it's just a way we can facilitate discovery of
resources relevant to a group. But I think it has a lot more baggage.
I think subsites may be a consequence of this baggage - if authz is on
the resource the concept of a subsite is not really necessary. However
we may need subsites to make it easier for users to understand their
context.

We're (at CSU) guessing one effect of creating a resource within a
site context is that the resource authz will default to that of the
site. Could we have widgets/tools that modified the default to the
user's current group?

What about tools that cross site boundaries, that attach to the user
rather than the site? Do these exist? Chat? Presence? Are these global
tools that can be filtered for site?

It still feels like the focus is on site authorization - this gives
you membership, it allows you to have a page with the site title at
the top. But does it alone give you anything else? Or is the main game
resources? How much does site membership matter?