Relationships & site structuring

It's exciting to read about the Social Networking Analysis (SNA) Tool that is 1 of 14 2006 Summer of Code projects selected to write Drupal code with the financial support of Google.

Kudos to Robert Douglass and Angela Byron for all their excellent work in helping put together the 2006 SOC!

The basic SNA module is an analysis tool that will map and analyze how nodes and users are interlinked. It is useful for knowledge management in organizations because it provides an insight on what nodes have greatest value and which users are frequently tapped by other users for knowledge. Since node analysis (eg most popular nodes) is already existent in other modules, we will focus here on an analysis of user networks.

I'm copying out jimw's recent comments (http://groups.drupal.org/node/465#comment) to begin a separate thread.

jimw brings up a couple of issues that has been talked about at some length. Specifically he is interested in roles like "volunteer", "presenter" etc. as they relate to Events:

Here is a first pass at documenting all of the use cases* to be touched on by the Events system. This list drew from the existing documentation that I could find and tries to be inclusive and exhaustive. I will update as people point out additions, mistakes etc.

• Use Cases are a notation meant to capture meaningful system capability from an end-user perspective. They can be used to document requirements and inform implementors as to the intent behind requirements. There are some standard ways to create and use Use Cases - but personally I feel that they are what you make of them. The image below does not contain Use Cases per se, but the titles of Use Cases. They are meant to describe the scope of the project in a way that is useful to all participants.

• Users, comments, taxonomy terms and attachments become nodes
• Why do this:
  • Simplicity, consistency and code reuse
  • Allow us to extend these content types as we do for nodes, without rewriting code
  • Allow relationships between these, without needing a mapping table
  • Why users:
    • Use CCK and taxonomy instead of profile.module
    • Use workflow for user signup/promotion
    • Location module does not need to deal with users separately, just location enable the users node type
    • Users birthdate can just be an event field. Birthdays are just repeating events
  • Why comments:
    • Use workflow to moderate comments
    • Use taxonomy to classify comments
    • Use relationships for threading
  • Why taxonomy:
    • The taxonomy builder becomes a streamlined interface to both build a tree of terms (nodes) and select an item from that tree to classify a node
    • Both the tree and each classification can be designated using relationships
    • All the taxonomy storage and retrieval functions can be encapsulated by the relationship API
  • Why attachments:
    • Less confusion about when to attach media directly to a node and when to add it using a media module node
    • The current attachment interface could then be a quick and easy UI to view/add/update attachments - uploading and adding attachment nodes, and relationships to those nodes (from the original node) on the fly. Expanding title/description fields that update the attached node could also be provided
    • A unified view of all attachments, whether they are added using the standard attachments control, or a more sophisticated media module
    • Potential to write generic gallery modules that don't need to understand different media module node types
• Each of these already has a well defined APIs, meaning that changing the backend storage to nodes should not be overly hard
• Existing API code would generally move to node hooks, and the old API functions would just become wrappers
• Modules that are directly accessing affected tables (most commonly the users table) will be broken by this change, but if their own uid columns are updated things should still work fine, as user metadata would still be stored in the users table as it is now (the only duplication of data might be user name - stored in both the node title and the user table)
• What will be significantly harder will be to upgrade existing sites, as all the id's will change.
  It should be possible to use some mapping to work around this:
  • Find the highest 'old-style' id in existence.
  • Ensure that the next nid is higher than this (bump it up if it is not). This value becomes the threshold.
  • Create nodes for each object, adding their old and new id's to a mapping table.
  • Update all fields in existing tables to use the new id's for each object (this could also be done automatically for contrib module tables, assuming that uid fields are for users etc).
  • When a request is made for an id below the threshold, map it transparently to the new id. This could be done at the function level for greater compatability, or (more simply) at the URL aliasing level.
  • This functionality could be wrapped in a module, which could be disabled for new sites as it is not needed.
• Potential DEP Dependencies:
  • Relationship API. A lot of the benefits/simplicity of taxonomy and comments becoming nodes comes from the ability of relationships to provide a standardised way to store the node-relation metadata.