The extension type for the unicyclist type is unicyclist_ext, but the table is not created. This is a default situation, you can still create the table later through the group UI. But I don't think you could do the setup here via the UI (at least at the time I wrote the code).
Also, the new groups which get created don't have any extension tables by default, but they can be added.
Focus on the use of acs_rels: this make it easy to do queries to find both sides of a relationship, then you have a reduced set to do permissions checking on, but driving very targeted queries is a big benefit of acs_rels.
I've been working on a generalized object relationship model, very similar to RDF which is easier to understand, but the acs_rels concept is general, integrated with OpenACS, but difficult to setup.
More specific to this example:
1. users and groups are created normally.
2. additional membership relationships are used to relate these users and groups
3. membership is granted to main site
4. admin permission is granted to new user over new group.
Note: the new group is to allow for a central point for relationships between users (cyclists, coaches, parents, clubs).
The example demonstrates that without the need to create any additional tables, you can model complex relationships and query them pretty easily. Of course the individual groups can then have unique extensions which don't affect the structural/permission relationships.
