Forum OpenACS Development: Re: Group membership

Collapse
13: Re: Group membership (response to 1)
Posted by Dave Bauer on
Tom,

Thanks! I apologize for missing your point earlier. I guess I didn't believe it until I saw the code! Thanks for the explanation. It makes perfect sense to have a group membership rel which is simple and doesn't require and changes to the existing code! (Unless we decide we need to add a group_membership_rel to the core).

Collapse
14: Re: Group membership (response to 13)
Posted by Tom Jackson on
Dave,

The point is that you can add new relationship types. You need to model the type of relationship. If the current rel is changed, it changes for everyone, every application, etc. The point of this data model is to provide specific models of the relationships, so if there you relax the specification.

Here is an example:

Types of users (Not using subtypes):
Cyclists
Parents
Coaches

Group Subtypes:
Cyclist_Group
Cycle_Club

Goal:

Cyclists, usually kids, join this community and maintain data on their training, etc. Parents need to login and view this data, they may have several kids. Cyclists may have a coach. A coach may coach several cyclists. Coaches also need to view the data for their students.

Cyclists may join one or more clubs. If they do, their parents and coaches remain the same.

Relationship:

Cycling person to Cyclist Group -- each cyclist is created with a corresponding group, with their name as the group name. They are given a cyclist_rel to this group so we can tell who the cyclist is later on.

Parent Rel -- users who are parents can get a parent_rel to the cyclist_group of their kids. Now a parent can easily find their kids using this rel_type.

Coach Rel -- users who are coaches can be given the coach_rel by their cyclists to the cyclist_group. Coaches can now find all their students.

Club Rel -- Cyclist Group (one cyclist + parents + coach) can join to a Cycle Club using a club_rel. (Group to Group). Now a student can find all the clubs s/he belongs to.

Clubs are probably run by other users who might have a direct membership or admin relationship to the group. Each club can easily find their cyclists, parents, coaches.

Objects can be attached to each of these relational segments, and permissions can be granted, as needed to the members of the rel_segments.

Collapse
15: Re: Group membership (response to 14)
Posted by Tom Jackson on
Oops, bad editing of my previous post, last sentence of first para should have been removed. But I think a more relaxed relationship could be added, not changing the ones we have now, and overall I think that rel_types can apply between any object type, not just parties and party subtypes.

Also, I left out one final relationship: coach_rel could be applied between a coach and an club, or a new rel_type could be used for this.

Maybe it is worth noting that this setup is very similar to RDF (subject --predicate--> object), where you have typed relationships, which is more than mapping.