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.
