Forum OpenACS Development: relations in contacts package

As pointed out by Matthew (https://openacs.org/forums/message-view?message_id=197490 in this thread) I'm starting to work on implementing relations between contacts and organisations & contacts and contacts in the contacts application.

For this purpose I'm looking at using the existing group/composition/relational segments datamodel as implemented in acs-kernel. Before doing this I'd like to ask if this is actual valid use for this datamodel - or is this exclusively meant to be used for modeling oacs usergroups, and do I have to built the relations for contacts on the more general relationship datamodel?

Ok then. I'm about to implement the following wrt relations
in the contacts package.

For relations between contacts & organisations:
- Turn "organizations" into oacs groups (currently they are just parties)
- Contacts are parties already, no changes needed
- Add ui for adding contacts to organizations etc.

Question (mostly for John): is it ok for me to turn organizations into groups? (or why are they currently just parties?)

As a side note - I'd like to strip the 'organization_type' stuff out of the organizations package. The same functionality can also be had by using categories - that's more generic and ui for adding/modifying/etc. category trees is already available. UI for doing those same things to org types is not (they are currently hard-coded)

How to go about with relations between contacts, I'm not sure yet. The issue is that there are two types of relations in that case:
- hierarchical (manager/assistent)
- peers (e.g. two contacts, perhaps even in different orgs can have some sort of functional relationship)
Also in some cases one contact could have multiple supervisors.

The easy way to model this is by simply mappings using acs_rels, basically ending up with a adjacency list model in case of hierarchies. The downside isthat one potentially has to do recursive queries to e.g. find all subordinates for a given manager. But I guess that would a rare issue?

Also, as acs_rels are objects, it is possible to annotate relations using general comments - right? Might be a nifty feature.

Keeping the KISS principle in mind, unless someone comes up with a brilliant idea in the next 2 days, I implement it in the simplistic way using simple mappings based on acs_rels.

<blockquote>
he reason they are parties is this allows them to not have to be registered
users. And groups makes absolutly no sense at all to me.

</blockquote>
Hmm - *that* does not make sense to me. They are already parties. Groups are a direct descendant of parties.

Also, organisations are groups (of people) by nature.

Dave told me he used it this way and it did work. Could you elaborate on this?

<blockquote>AFA, stripping organization_type stuff, again, this is based on HR-XML
standards and that is the reason it is there.

</blockquote>
Well, this is actually less of an issue to me than the group thing - I really don't care leaving it the way it is. But does the HR-XML standard say that the type has to be stored in the same table as the org name? Because using categories basically means you store the type info in a different table. Nothing more.

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 :)

Hmm - yes. Nice idea. That would mean making this a new service, much like General Comments or Categories, which allows for defining arbitrary relations between arbitrary objects.

I think I'm gonna give that one a spin.

As far as I know this package is about storing common information like phone, fax, website, and many more attributes in a general way. The question is why should this information be tied to a party?

Say you organize an event with a couple of people and want to add contact information about that event. It shouldn't be necesarry to enter a bogus contact just to associate your event with contact information. Fax, email and phone may even be handled by different parties.

An other example: say I work in different location. When I create webpages for those different worklocations (and each webpage is an object), I would need to associate attributes like address, phone, fax, etcetera with each webpage. It doesn't matter which party picks up my fax or phone, does it (as long as they know what to do of course)? Currently, however, I should make myself a group/organization and make bogus contacts for every worklocation, AFAICS.

In short, if a contact has to be a party, it will be harder for third (or custom) packages to use the contacts package for storage of common information, IMO. Especially if this "third package" evolves around rooms, locations, events, or other non-party objects.

Or am I missing something?

Dave,

the contacts package requires the packages you mention. So I know contacts builds on top of them.

It is not address and phone alone that I would need. But the main thing is to understand why the contact package should restrict itself to parties/persons? Do you know? The person itself is sometimes less relevant. Often, entering a contact person for a organizations or business is optional. So, why should an organization be a party (this has been discussed, I know) ?

Within openACS it is also about UI, but not UI alone.

One of the major re-writes i'm currently doing to contacts is to seperate out the contacts attribute management system. This will create a new package called attribute management system (AMS) that lets you tie revision controlled attributes to any object not just party_id (This package will auto ad_form generate the same way contacts does)... So, you'll get the attribute management of contacts on any acs_object just like you want... this should take care of Alberto's (legitimate) concerns... it will be in CVS by next week (i'm currently testing it).

Next week i'll make the offical posting announcements and the like. I think this will be valueable to all packages, since it will let them all customize their info collected. I need to write up some documentation before i announce it officially since it is a bit complex, but i'm pretty sure that this is what you are looking for. Contacts will use AMS to store its attributes and provide an example to other packages of how they can tie in to dynamically created attributes that can be used in ad_form and are version controlled via the content repository.

Contacts should be parties. This will let contacts use the group structure in the future and allow for simple migration from contact to person to user, etc... since parties are people or groups of people (orgs, etc.) it makes sense that a contact is also a party.

Thanks a lot Matthew, I look forward to it! Walter, thanks for posting!

Since this thread is about relations I just wanted to point out the problems that arise when a non-party object needs to be related to party contact information. I would need to relate the one non-party object to an administration department for postal address, a party for finances, a reception for the phone, etcetera. Obviously that is not very practical and hard to explain to users. I'am hoping we will end up with a solution, possibly in AMS, form widgets, relations, or a combination.