Skip to Content.
Sympa Menu

grouper-users - Re: [grouper-users] schema(s) for departmental groups ?

Subject: Grouper Users - Open Discussion List

List archive

Re: [grouper-users] schema(s) for departmental groups ?

Chronological Thread 
  • From: "RL 'Bob' Morgan" <>
  • To: Steven Carmody <>
  • Cc: Grouper-Users <>
  • Subject: Re: [grouper-users] schema(s) for departmental groups ?
  • Date: Tue, 23 Aug 2011 08:00:53 -0700 (PDT)

We're currently thinking of this set of top level containers:

This seems to be working well enough for us.

Bob's naming rule of thumb: hierarchies, if needed, should be based on naming authorities, ie, a defined group that manages names in its subspace. Taxonomy is to be avoided, especially if the naming authority for the taxonomy elements is "me, the architect". 8^)

- RL "Bob"

On Tue, 23 Aug 2011, Steven Carmody wrote:

I'm seeking thoughts and experience. Let me provide some background information, and our current thoughts. However, I'm really looking to start a conversation, and hear what other people are thinking.

We've begun to walk down the road to providing departments with department-related groups. We're expecting to provide 1) some auto-magically provisioned groups using information from various Business systems, and 2) delegate to the department the authority to create and manage groups for their specific needs. Beyond that, of course, we have the usual range of departments, from very small to very large, including both administrative and academic. So there's a wide span of requirements and complexity.

Having spent too many years with naming hierarchies of various sorts, my initial inclination is to provide a small standard set of top level containers within each department container. Having a single flat name space at the top level frankly gives me a bad sort of itch; I think our experience with file systems, etc gives us enough hints about the types of groups people will want that we can make some educated guesses about "categories". OTOH, we don't want to over-prescribe a single framework on everyone, and we don't want to force a deep multi-level hierarchy on everyone.

We're currently thinking of this set of top level containers:

-- People (this would contain auto-provisioned groups like Faculty, Staff, Grad Students, Concentrators, student workers, etc). The dept could manage groups containing "affiliated faculty" (eg people in other depts who aren't official members of this dept but are considered to be unofficial members of this dept; some affiliates could be from other campuses);

This container would likely also contain groups related to the administrative structure of the dept. In all likelihood, these would have to be manually maintained by the dept.

-- Projects This would contain groups related to various Projects that the dept is involved with; many of these could contain people from other depts; research groups could contain people from other campuses. The dept would be authorized to manage everything in this container. We're assuming that a Research group would create their own container and namespace within this container.

-- Applications (or Services). This would contain groups that have various privileges within centrally-offered services (eg who can edit/approve changes to the dept web site on the central web server). We expect that each application will include a "grouper-lite-lite" GUI allowing an admin to browse and manage memberships relevant to this application. These groups are placed in a well-defined location so that the relevant application can find them.

-- Other (love that name...) The dept can do whatever they want within this container...

-- a dept can also ask us to create additional top level containers for their use.

-- Note that Course-related groups are placed elsewhere in the hierarchy.

So... what are other sites doing with departmentally-related groups ?

Archive powered by MHonArc 2.6.16.

Top of Page