metadata

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.

• 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

http://drupal.org/node/62120

Please review this proposal and comment, it's not to late to get students to write up a proposal.

• 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.