In my use case, a Contact can be an individual, business, organization, school, class, etc. So in the Group isContact connects the singular Contact that is the equivalence of the Group. For example a group might be a School and another group might be a specific class of the school. This is a 1:1 relationship. Every group represents a singular Contact (usually not an individual type).
The AccessRight forContact connects which contact has that specific access right within the group. My use case is for each access right to be specific to a singular contact. This makes it so changing one access right is only changing rights for one connected contact which usually represents an individual user.
My use case potentially will support groups within groups and this lays the foundation for this framework with some more rule modifications. For instance a group could be a school and a another group could be a class. The class has access rights within the school and users in the class can potentially inherit rights through the class to the school. This would allow multiple classes and the school as a whole to collaborate on something collectively without needing to specifically grant every user in every class specific access rights within the parent group, just grant the classes.
I didn’t take this example use case in the articles to its fullest potential and if you want to model it differently then go for it, as this was just some content to get people thinking on how it all flows together.