Here is how I can see an acs_rel working in my case.
A parent logs in to the system and is presented with a list of unicyclists that they can read/write/admin for. They choose one and kind of soft login as that unicyclist.
When they want to add some information, they do it in their name, for instance a blog entry:
skill_log -- simplified
______
log_id
party_id
log_entry
Previously the system set up a parent_rel, an acs_object, with the context_id set to the uni_group group_id for the unicyclist.
When this entry is added, the user_id of the parent is used in the skill_log table, but the context_id is set to the parent_rel rel_id. This preserves the route that the information was added for the unicyclist, but I don't know how easy it will be to grab all the log entries for the user/party. Maybe the party_id in the skill_log table should refer to the uni_group group_id, and the context_id to the rel_id. Then who edited it should go in the creation_user field for the acs_object. By looking at the acs_object__name for the context_id of any log entry, you could determine who added the entry and in what role, for instance if you auto named the acs_rel 'Joe Blow, parent of Sam'.
This data model would then allow entries to go in for other groups: unicycle_club groups for instance, or if several unicyclists were working togeather on a set of routines in an expanded uni_group.
So the helpfulness of the acs_rel usage would be to simplify the query of what a person can do on the site, what role they want to play, and what group of objects they want to look at. By choosing a certain parent_rel or coach_rel, that would in one pick identify both.
