Jeroen, i would really encourage you to allow for the dynamic creation of acs_rels... and i agree with the others that the current datamodel stays in tact. I am currently re-writing the contacts datamodel (a bit), but the one thing you can count on in your work is for a contact to be a subset of party. I will use the id contact_id in this structure:
Party (party_id)
Person (person_id)
User (user_id)
Organization (organization_id)
Contact (contact_id)
Lets assume we have party X and party Y. If party X employs party Y, party Y is an employee of party X. And if party X also employs party Z then we need to have the UI be able to list "Employees" and if party Z is also employed by party Q then they are party Z's "Employers." Its this UI view that is the tricky part. It needs to be in a logical easy to read way (for example, having spouse relationship might be more important than mechanic relationship, if its a friends database, so we should be able to have some kind of hierarchy of relational importance in the UI (we might also only care about creating a sortable listbuilder list of rels)... i haven't thought throughly about this so i might be talking jibberish. Note people can employ other people too, there is not just orgs employing people... BUT, what would be really cool (and very difficult from a admin UI perspective) is if a rel type could be bound to a category. So if you set a relationship for Party X employing Party Y it could (if the users chooses) automatically also put party X in the "Employers" category. Stuff to think about...
Anyways, it seems reasonably straightforward programming wise, the trick is in coming up with a simple UI for selecting relational contacts. And also allowing users to create their own relationships (without having object name conflicts and the like). BTW, i would use acs-lang to store translations, so the name in the acs_rel_roles should be "<span>#</span>contacts.Employer#, etc... this UI is the major difficulty, and where i was really stuck on this issue, and i'm glad that you are taking care of this so i won't think about it too much more :)
