An Interesting Idea

People, Organizations & Relationships

This paper describes an Idea I have been thinking about for many years. I implemented it twice in rather privative forms, but lost the code years ago. Fortunately (I think), the concept has still percolated in my brain and came roaring back with I discovered a product called “Gravity Views” which is an add-on to Gravity Forms. The designer of Gravity Views clearly showed a level of conceptual thinking that was so advanced that I think he may be able to incorporate this idea into his product. So I am documenting it here for him to see and think about.

Creating a system for managing contact information is probably the single most common design challenge that software designers face. I have yet to see one that addresses this challenge in a way that is simple, extensible and powerful. Here is mu attempt to address that problem.

The Three Primary Objects

At the heart of any contact management system, there are three primary objects that must appear:

  • Persons
  • Organizations
  • Relationships

Person objects must manage core properties like name, email, phone number(s) and possibly date of birth, address and maybe a few others. However since each customer of this system may need to manage additional properties, the Person object must allow for easily defined additional “custom” properties.

Organization objects describe a collection of people with a common name, It may have additional properties, but it must have a name, and must allow for the easy definition of additional “custom” properties,

Relationships define how persons relate to both other persons and organizations and can be expressed as a simple sentence. For example:

  1. Person <p> “works for” Organization <o>
  2. Organization <o> “employs” Person <p>
  3. Person <p1> “reports to” Person <p2>
  4. Person <p1> “is married to” Person <p2>
  5. Person <p> “is offspring of” Relationship <r>

Note that examples 1 and 2 are mirrors of each other. Only one of these is needed to construct a complete employee list for a given organization.

Adding example 3, we have a simple way of creating an org chart.

Example 4 is an example of a transitive relationship, and it is the only example of a transitive relationship I have found yet. Transitive relationships have an interesting property. They can appear on either side of a different relationship. This characteristic makes it possible to create a family tree very easily.

 

 

As with Persons and Organizations, Relationships must be easily extensible. For example, if we add “Date created” and “Date Dissolved” to the definition of “is married to”, we can describe the history of Liz Taylor and Richard Burton’s marriages. We can also describe blended families where Sam Smith is married to Sue Jones on 12/10/1980, they had three children (Bill, Nancy and Judy), divorced on 4/15/ 1995, then Sam married Jane Doe on 2/10/2001 and they had two more children named Sarah and Mike. All of this is both possible and simple using the three objects I have described.

Adding a “Walker” object to a transitive relationship can navigate a relationship tree from any starting point and walk up and / or down the tree to any desired level. The Walker might present a form like this:

Select Contact A Select Relationship Type Select Contact B
<DDLof contacts> <DDL relationships with Contact A or B> DDL of contacts on right side of relationship

<List of matches>

The user could select contacts on either side of a relationship and the list of matches would show the selected data.

A more advanced Walker would be about to represent this graphically.