Modeling attendees, organizer, requestor, requestee

This is a long-standing problem and one that's not going to be easy to resolve. Cloud membership, sharing boundaries, single-instancing of information, and bidirectional refs do not play together well so far. I had a proposal a few days earlier for a ContactRef item, which Katie pointed out is really a Principal. I decided to start implementing Principal and see what snags I run into.

• diff.txt: I've attached a snapshot of my diffs in case they're illustrative.

The big snag so far is the breakage of bidirectional references between Content Items and Contacts. For example, we had a list attribute on Contact which was "taskRequests" -- the list of all tasks for which this Contact was a Requestee. But we can't implement this way in the long run because Requestee needs more information -- we need to know what email address was used to make this request, for example. Email.toAddresses is an even clearer example of this -- we need to know which email address the email was addressed to, and we need to know which contact that email corresponds to -- and we really want the Contact to know which emails were sent to it. If we simply point the Event.toAddresses attribute to a bunch of Principal items, and also Event.attendees point to the same kind of Principal items, then even if the Principal items point to the Contact (and the Contact back to the Principals) we have no easy way of just finding the events that the Contact is attending. To find those, we have to get the list of Principals linked to the Contact, and then scan through them to see which ones point to Events.

How can we address this?

Annoying Idea: If Prinicipal has a different sub-class every time it's used, then we have a more clearly identified way from a Contact back to the things the Contact is used in. E.g. we subclass Principal as Attendee, so then from every Event we have a list of Attendees; from every Attendee we have a single Contact (or none). To go backward, from every Contact we have a list of links to Attendees (an attribute called 'attendingEventAs'?) and a single link from every Attendee to its Event. Two sets of bidirectional links, and the thing in-between is unique to each purpose. This already sorta works for Attendee, where I was thinking of having a subclass anyway to define the attribute RSVPStatus. But it is really annoying for all the others, culminating in the situation where we would have to subclass Principal about a dozen times and they'd all be the same except for the name of the role.

Crazy Idea: The information arrows we want are more circular than bi-directional: Email(toAddress) --> Principal --> Contact --> Email. So, we could allow the data model to support circular link families, where "bi-directional" is merely the simplest case of a circle. So the data model could be perfectly happy to have the link circle defined. Thus, when an Email is created, and a Principal is created, and the Principal is assigned to the Email's toAddress, the data model would see if the Contact were also known to the PRincipal, and complete the circle by putting the Email in the Contacts "emailsTo" attribute. OTOH if the circle is incomplete -- the contact is not known -- no problem, this is an email to somebody that isn't in our Contacts list. This works fine with clouds and sharing boundaries because the cloud for sharing an Event could include the Event and the Requestee, but not the Contact the Requestee item points to.

Bad Idea: We could make bi-directional links more specific in some cases. A link from an Email to a Contact's email address would be mirrored by a reverse link from the Contact to the email's toAddress attribute. So if you're starting from the Email.toAddress attribute, you can either get the emailAddress specified or the Contact directly from that link. If you're starting from the Contact and looking at the Contact.emailsTo attribute, you can get the Emails or the values of the toAddresses of those emails. This doesn't work so well with clouds, and it doesn't solve things like RSVPSTatus so it seems like a Bad Idea; I list it for completeness and in case it seems better on closer examination.

Katie's Idea: Katie's Relationship idea is that we model relationships more directly in the data model, so a relationship can be annotated. This is a way of saying that the important link is really between the Email and the Contact, and the email address that happened to be used is just a piece of data about the relationship. Similarly, RSVPStatus is a piece of information about the relationship between an Event (the attendee attibute) and a Contact. SharingStatus^? is a piece of information about the relationship between any shared Content Item and a Contact. This plan doesn't quite yet address the whole problem we created Principals to solve: when you're sharing a regular Content Item, how can you share only certain information about the Contact it points to? E.g. for an Email, we want the email addresses and displayNames related to the toAddress to be shared as well, but not the rest of the Contacts. So the Relationship annotation would also have to include the displayname for the thing being linked to, and Clouds would have to be able to specify which Relationships should be excluded, which Relationships should have only certain things included, and which Relationships ought to be full included (including the thing linked to).

-- LisaDusseault - 30 Jul 2004