TBase Project

Context: I am in the process of developing a Contact Management System. Using a large system like CiviCRM seemed overkill and integrating it tightly into Drupal seemed a bit complex. On the other end of the spectrum, a system that relies solely on node_reference CCK types, seemed too limited. I am presenting a middle-ground solution that offers a flexible solution within a modest scope (module currently has 700 lines of source code).

Project: To develop a system that grows with one's understanding of the organization. Out-of-the-box, Drupal offers 50% of the solution. If the current mental model pictures the organization as a network of persons and groups, one can create 2 node types (named 'person' and 'group') and populate the model with instances of persons and of groups. Later on one might discover, that the model of the organization needs to be expanded by adding nodes of the type 'product' and 'event'. Easy done as said: CCK allows to create new types as needed.

But now to the other 50% of the challenge. How do the nodes relate to each other? How can I express...
...that person Fred is a_member_of group Salesforce since 1989 and that he became_VP_of group Salesforce in 1995.
...that person Fred is a_co-worker_of person John and a_supervisor_of person Bill.
There are no limits to how the model of the organization might evolve and what might become relevant: For example, I also might want to track...
...that Fred bought product DrupalBook on Oct. 17, 2005 for $19.95 and bought product LearnToProgramBook.

Proposed solution: Similar to the node table that allows us to keep track of new node instances, we need a transaction table that allows us to keep track of new instances that relate 2 nodes to each other. I have developed a proof-of-concept prototype (called TBase) to demonstrate how such a solution might work. I explain with an example.

EXAMPLE: A transaction-based Contact Management System (TBase)

Screen Shot 1:

In a simple CMS we keep track of the persons in our organization. We also track their interests and their membership in groups. Willy, for example, lives in Boston; is a member of the New England Revolution soccer club and the Drupal User Group; likes to play chess and soccer; and is related to Frieda, Fritz, and Robert.

Screen Shot 1:

A simple CMS

Screen Shot 2:

Expansion of the mental model of the organization. Without having to redesign our CMS, we would like to track the events that take place in our world of interest. We are interested in questions, such as: Who sponsors an event; who registers and attends? Using CCK, we define a new node type 'event'.

Screen Shot 2: Adding Events

Screen Shot 3:

In response to the new node type, a new block 'type_event Nodes' is created. The block will be populated as needed and will be visible when appropriate. The only user interaction required from an admin is to specify in which region of the page the block should show up. In the current example, the admin decides to place the block into the right side bar.

Screen Shot 3: Block 'type_Event Nodes' has been created

Screen Shot 4a,b:

Linking the new event type into the rest of the system is a simple 2-step process. First, the admin specifies that the new type event can be related to node types of person and group.


Screen shot 4a,b: Relating the new node type 'event' to the existing node types.

Screen Shot 5:

In the second step, the admin specifies how a an event can be related to a group or a person. In the screen shot we assume, that the admin has already defined that a group can sponsor an event and that a person can be register for an event. The admin is about to specify a third relation: a person can attend an event.

Screen Shot 5: Define how types may relate to each other

Screen Shot 6a,b,c:

A user can now link instances of type event to the rest of the system. For example, we might start out to specify that the 'Drupal User Group' sponsors the new event 'Programmers' Meeting in Cambridge' and continue to enter registration and attendance information.

Screen Shot 6a,b,c Linking a node to the rest of the system

Screen Shot 7:

Let's compare screen shots 7 and 1. The system has been expanded and now displays what events a person registered for and/or attended.

Screen Shot 7: The expanded CMS (compare to screen shot 1)

Screen Shot 8:

We can use the node relations to reveal connections that are not immediately obvious. For example, we now can infer grandparents (by searching for a person who is child_of a person who is child_of another person). In our example we discover that Robert and Regina are grandparents of Frieda and Fritz. There is no pre-set limit to the length of the calculation chains. The potential of advanced search based on chain calculations is described in the Appendix within paragraph 'A semantic web incursion'.

Screen shot 8: Advanced search

APPENDIX (Source: http://infojunkie.dyndns.org/node/239)
The problem of nodes relationships in Drupal

An important problem that Drupal faces is the inability to create relationships between nodes. Current solutions are either half-baked or over-ambitious. The half-baked doesn't properly model the ER and OO model of relationships, and the over-ambitious attempts to supply a fully Semantic Web framework, even when it's not required, at the cost of considerable design and code complexity. Plus, it's not ported beyond 4.7.

What's needed is a simpler but still semantically correct solution, upon which various contributed modules can add their own decorations. Here are some features of the relationship:

* Bi-directional
* Accept cardinalities at both ends
* Allow arbitrary attributes to be attached, much like a node
* A specific attribute would be "type", a string used to name the relationship type in semantic terms ("isA", "contains", "partOf", "usedToPurchaseAUnitOf", etc.). These terms can be typed or supplied in a list.

A Semantic Web incursion

Whole algebras can be built out of relationships. Consider this: the Semantic Web assigns typed relationships between facts in the form "subject verb object" which is equivalent to an operator acting on the two variables "subject" and "object", to yield a result. Usually, the result is boolean TRUE, meaning that the relationship in question holds. Semantic Web also supports inference, which is to say chaining such relationships in such a way as to relate, logically, the very first subject to the very last object in the chain. This way we can create logic circuits, which are equivalent to algebraic expressions made up of more than 2 terms. In Drupal, the terms are actual nodes, and the relationship circuits define a semantic graph that represents the evolving structure of the content. This way it becomes possible to perform reasoning on the node information. Some examples will help clarify:

* What nodes with status "published" have become obsoletedBy other nodes that are still "in moderation"?
* Find all "unpaid" Invoices whose purchasedBy Customers are less than 1 year since "firstContract".

Hopefully SPARQL can be used to perform those queries. As a last resort, though, a little Prolog query would do the trick.
Meanwhile on Earth: A CCK node_relationship field type

A simple way to implement relationships is to reuse whatever is available to us today. The closest thing that fits the bill is the node_reference CCK type, so we can build a similar node_relationship field type that implements the requirements above:

* When a node_relationship is created on a specific content type, it is required to specify which other content type it can refer to via this relationship. The field label is used as label for the endpoint, and the label for the other endpoint is also specified. This endpoint will be created on the host content type as a symmetrical node_relationship with the mirror parameters.
* The relationship also accepts a "type" attribute which describes the nature of the relationship and is the same on the other endpoint.
* Special attributes can control the behaviour of the relationship:
o Cardinality
o Master-slave: if the lifetime of the other endpoint is enclosed by this one.

* By kratib at 2007-09-25 23:55