Node Relativity

The Relativity module provides a comprehensive mechanism within the Drupal framework to manage relationships between nodes.

N.B.: It is not the mandate of this module (version 3.0 for Drupal 6) to solve issues relating to semantic web. To implement the RDF spec, further discussion and development will be required; yet this goes far beyond the initial scope of this module.

Documentation and instructions are available in the separate Relativity Handbook.

Summary - Why you might need Relativity?

If you find yourself in a situation where Drupal's core taxonomy functionality or the book.module do not seem to fulfill deeper relationship needs between nodes, this module may provide the solution for you. The following is a set of case studies to demonstrate what Relativity could do for you.

Example #1: Books

The most basic hierarchy between any two nodes is a 1 to 1 relationship. In this example we essentially provide the identical functionality of the book module (core Drupal module). Though inherently this module is not extensible, with Node Relativity, the hierarchy can be expanded upon. Any content type you create can essentially be used as a parent (book node) and child (page node) for the basic structure of your relationship.

The following graph highlights the connection between these two content types.

       Book
      (parent)
         |
         |___ Page
             (child)

Since we are providing a mechanism to define these relationships, it is possible to create a 1 to many and have the hierarchy develop a more complex structure.

The following graph highlights possible combination of content types. The relationship is not limited to two content types, it could be any combination of 1 or more content types. so the following structures are legitimate possibilities:

       Page               Book                    Book
      (parent)           (parent)                (parent)
         |                  |                       |
         |___ Page          |___ page               |___ page
         |   (child)        |   (child)             |   (child)
         |                  |                       |
         |___ Page          |___ Book               |___ page
             (child)            (child/parent)          (child/parent)
                                  |                       |
                                  |___ page               |___ page
                                      (child)                 (child)

Example #2: CD Albums

This is a classic example where the relationship between nodes is quite important in order to establish a hierarchy of information. For instance, if a content type defined as an Artist collects information relating to a particular member of a Band, we might say the Artist node is a child of a Band node.

Each band will likely produce music tracks assemble into a collection, therefore requiring an Album content type. The fields for each node type is arbitrary to this discussion, so we won't go into the specifics of each content type. Suffice it to say, a Band is a parent of a child node of type Album, or more simply: Album is a child of a Band node.

We can see from these two points, a hierarchy of nodes is required to demonstrate their relationships. This module can help establish the way in which these content types interact.

The following graph highlights the connection between these content types.

           Band
         (parent)
            |  |
  Artist ___|  |___ Album
  (child)           (child)

This heirarchy could be extended even further with the introduction of a Track content type. The obvious connection point would be the Album content type. Here, the relationship would be described as a Track is a child of an Album node.

           Band
         (parent)
            |  |
  Artist ___|  |___ Album
  (child)           (child/parent)
                      |
                      |___ Track
                      |   (child)
                      |
                      |___ Track
                          (child)

We can see that a complex tree of relationships begins. A relationship that is not obvious at first though, since our graph does not describe it visually, is the connection between the Artist and the Track content types. Though the hierarchy is not explicit, it is implied. Therefore, exposing this relation to a user is paramount. How it is presented is up to the individual themer/site developer, yet the functions should be exposed to the front end through API and Drupal handlers for ease of deployment.

N.B.: more examples to come.

A point to note here, you could use the CCK Node Reference module as a way to relate these nodes together, and with the help of Views and Taxonomy, create an elaborate solution to build this hierarchy. The likely outcome though is a node management nightmare. Many such hierarchies over several nodes and with all the permission controls required to limit access to unwanted data or previously selected data may become onerous to work with. Since flexibility is the key, providing users with a simple methodology for connecting, creating and managing nodes together in complex hierarchies is essential.

Identifying and managing these relationships with Relativity is much simpler and ultimately more powerful. In the following pages, we hope to document the future of the module and how we plan to develop its underlying engine.

Upcoming Sections

• Instructions
• Theming Documentation