Relationships & site structuring

I would be very interested in a workshop session at DrupalCon on relationships. I think there are many people working in this area, and I would really like to know where we all are.

I have been building some "social mapping" sites over the last year, and have many lessons to share. (http://nm-x.com and http://www.l-atlas.net are some examples) I would also like to perhaps find a group to collaborate on actually building the relationship api we have been talking about for who knows how long.

I registered a drupalcon session. Maybe, we can get it scheduled and have a chat ?

I am reporting some findings that I hope will help others who decide to try any access control module currently available to Drupal 5.1 or earlier.

The most abstract concept in my opinion: "everything is a field" (fully atomic value) instead of "everything is a node". CCK is ardent proof that this idea could work. If that's the case, we can share the same field (as regards value), node is just a set of fields tie together by new relationships system, whereas content type is a predefined set of relationships between fields.

i've had this sitting around in my sandbox for a while, but with the 4.8/5.0 dev cycle, I was too busy to do much with it. it's a proposed relationship API for inclusion into drupal's core.

Schema-wise, it works like this:

required fields:
rid -- the relationship id. just an auto-id to give us something concrete to connect to. term_node lacks this, and it's a PAIN.
source_nid
target_nid -- the two nodes being connected to each other
relationship_type -- a simple descriptor like 'child' for a book page or 'comment' for a comment or 'describes' for a taxonomy-term-as-a-node.

optional fields:

A striking similarity of all examined content translation modules is that they store translated content as separate nodes. Some of the vocal members of the community expressed their concern about this solution, refering to 'content duplication' as a problem. I suggest that we should store translations as their own nodes, but it does not mean we would not be able to solve any of the problems raised. Let's see what are the disadvantages of storing translations as nodes, and what do we get as an advantage.

I've got a views integration for my nodeprofile modules working. This also works for general nodes, not only for nodeprofiles.

By doing the nodefamily views integration I ended in writing the module views_fusion:

With this module its possible to build views which display information of several nodes in one view - useful for tabular views.

This is achieved by defining multiple views, one for each node. Then the views fusion module is used to melt these views to a big one which contains all the information.

More information on this module

This module works great together with the nodefamily module, so it's possible to use nodefamily relations for joining the views/nodes. However I've written the module in a general way so that it's possible for other node relation modules to use it the same way.

Of course testers and feedback are welcome.. :)

• Standard set of hooks to allow modules to express relationships and query them
• Requirements (based on discussions at OSCMS Vancouver 2006):
  • Pluggable frontends (ways of entering and viewing relationships). Experience has shown that there are many different ways relationships can be created and presented to users. See the 'Relationship UI' child page for a simple frontend.
  • Pluggable backends (ways of storing/retrieving or deriving relationship data). Experience has shown that some modules will need direct control of the relationship storage space. See the 'Network Relationships', 'Hierachical Relationships' and 'CiviCRM Relationships' child pages for example backends.
  • Extensible
  • Works with both 1-1 and 1-many relationships
  • Object neutral - can relate nodes, users, comments, relationships, URIs
  • Can retrieve direct relationships (e.g. friend - L1) as well as as indirect relationships (e.g. friend-of-a-friend - L2, friend-of-a-friend-of-a-friend - L3 etc)
  • Can retrieve relationships taking into account direction (e.g. only parents or only children) or ignoring direction (e.g. relatives)

  Additional requirements for discussion:

  • Each relationship type can be a node - easily extensible with metadata explaining what this relationship 'means'. Additionally - or alternatively - we could allow a simple keyword to define the relationship type.
  • Split off the API from the 'standard' backends and frontend to make it easier to maintain and add to core.
  • Direct (L1) relationships could be cached with the node - we could even 'grow' the node relationship cache for higher level relationships as they are requested, possibly with certain limits.
  • Relationships can be directional or non-directional - we could track this with the relationship type (i.e. if the relationship type has an 'inverse' then it is directional).
• Potential use cases for relationships in Drupal
• Node authorship (multiple authors!)
• Taxonomy (which is relating to a point in a taxonomy tree, which can also be created using relationships)
• Media or other attachments to a node
• Web Links (relating to an external URI) - these could optionally be picked up from the node body and/or tracked using weblinks.module
• Event and volunteer signups
• Comment threading
• Metadata in general
• Tracking users buddies
• Tracking user content likes/dislikes
• Adding AI-like capabilities 'If you liked this, you'll love...'
• Lastly, but certainly not least - the semantic web (RDF, FOAF...) revolution!
• Potential DEP Dependencies:
  • Users, comments, taxonomy terms and attachments become nodes. Without this DEP the RAPI would be significantly more complex, because of the need for either a table mapping 'object-ids' to node, comment and user ids, or tracking the tables in question directly with each relationship

Boris suggested I cross-post this here (originally posted http://drupal.org/node/69957)

We are building out functionality to allow multiple locations associated with a content node. The idea is to make location nodes, changing nothing to the location module, but making a new module which will facilitate in the creation of and association between location nodes to their content nodes.