Relationships & site structuring

Monday May 5, 2008
Moscone Center SF

This is a barcamp/unconference style Drupal meetup for us at CommunityOne! So bring the topic you want to discuss!

Space available in Hall A - section of tables, white boards, wifi (opportunity for it to be very noisy)
- space is available 5/5 from 11a - 8p (reception is held in that hall from 6-8p)

I can see about a projector if it is needed. I will have a camera guy there too documenting.

Please Register so they have enough space, food and such! I believe currently we have room for 40.

For a flexible, scalable Drupal site, are you better off modeling your domain and it's related content as a large number of smaller/related content types ('related' using say nodereferece+nodereferrer), or as a smaller number of larger content types with less inter-node dependencies?

What are the performance implications one should be aware of that should steer you in one direction or the other? Assume you the purpose of discussion that you are planning on using Views, Panels, Organic Groups to mix and match content and display in various contextual ways

This is the 5-minute "video from the future" demo presented by Dries in his State of Drupal keynote presentation at Drupalcon Boston 2008. The video demonstrates some of the mashup capabilities of an RDF and SPARQL-enabled Drupal as envisioned by Dries for the upcoming Drupal 7.x release. The version of the demo below includes the original narration by Ben Lavender (the audio from Dries's actual presentation is also available - the RDF material starts after the 52m:30s marker).

I'd like to share some quick thoughts on how Drupal Data could be described in RDF. The attached schema represents the mappings between the current Drupal data structure and the proposed RDF Schema, reusing existing ontologies such as Dublin Core, FOAF, SIOC and SKOS.

The green circles represent the Drupal objects (node, revision, user, role, term), with their equivalent RDF class. The rectangles are the values used in Drupal. It's important to differentiate a class from its actual instances (resources) which are each defined by a unique URI, see the examples below. This schema is meant to be simple, incomplete, and to show the main core features.
Comment and Node are 2 different elements in Drupal, they can be combined in the same Class with the recursive property sioc:has_reply (Comment as Node). Node and Revision objects are separate here as they are in the Drupal Data structure, but they could fundamentally be merged as well.

I presented SIOC at DrupalCon Barcelona, and showed how it can be used to describe online communities. The SIOC sioc:Item class which I used here as equivalent of a Node is a broad Class with many sub-types: AddressBook, AnnotationSet, AudioChannel, BookmarkFolder, MailingList, MessageBoard, BlogPost, BoardPost, WikiArticle... See the SIOC Types Module for more details.

A number of projects are now working with RDF and the Semantic web.

They may not all share the same RDF store, but for data interchange, they should all share the same RDF structure. RSS, ATOM and OPML are standards, but RDF can be rich.

Here's a quick outline to get this page going:

Question 1:
Should we be considering OWL?

Hi all,

I just wanted to introduce myself. I've been an amateur musician for about 20 years and a professional programmer for about 10. I've been using Drupal for a year or so and have built a bunch of sites with it.

Now I'm building a site for my new band (I haven't been in a band since high school), and I've decided to do it with Drupal's multisite feature under a fresh install of a fresh domain. I'll be starting with some (or all) of the suggestions from http://groups.drupal.org/node/5167 and I'll try to report my findings here.

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 ?

How do you deal with object composition within drupal ?

Do you use Taxonomy + Panel + View ?

Do you use node reference with CCK node ?

Other solutions ?

What are your ways to define a container of other objects ?

Which drupal modules are involved in "object composition" nowadays ?

Object composition is about building "large" objects from "smaller" ones.
Here is a definition of object composition on wikipedia : http://en.wikipedia.org/wiki/Record_(computer_science)

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.

"Relationship" I understood as relationships between fields (nodes are many relationships, which are subject of more advanced process).

Wanted features:

1. Powerful and without limitation thanks to the most abstract (see: "everything is a field", compare this to: Global CCK fields, A controversial(?) point: store translations as nodes).
2. Build-in categorization features.
3. Build-in views features (listing fields, not necessary nodes).
4. Build-in menu features.
5. Support for Semantic Web/Microformats/similar.

Observations about current situation:

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.

Hello views aficionados. If anyone has the time, could you review the module posted in

http://drupal.org/node/103171

It's a module (that I will recode as a patch to views itself, eventually) that provides views within forms. These views can be used to select nodes. It includes exposed filters and a pager, and it generally behaves exactly the same as any other view would.

The module even includes a test harness where you can click a few buttons and test the new form element with any view on your website.

This is not production code, but I wanted to alert people early. Please do review this module and let us know what you think. It's a lot of code, and may require some changes to the underlying views implementation, so the more people who try it, break it, and suggest changes the better. Also, you can use this to start testing with your own modules.

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:

[ Edit ]
To make a long story short, it turns out that robroy was already well ahead of me in figuring out why the old documentation wasn't helping people and will update the documentation next week. Serious props to his chops for the effort.

If you're interested in how this is shaping up, take a look here.

[ / :) ]

I noticed webchick had pulled the old documentation for writing installation profiles a couple of days ago, and after kiting her a brief email, feel like I know what's going on with Drupal, for once, or at least the docs. Short version being that the old ones were as dated as they appeared, and new ones will require a little research to complete, so I will be taking a stab at this over the next couple of days.

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.

So, I have been doing my monthly round up of really cool sites, and have been coming across a number of candidate Web sites using podcasting and / or multimedia solutions.

While I am not ready to tack any modules onto Drupal.org, I wanted to write about some low cost ways podcasting and multimedia can be added to a campaign budget. As I see it, the main benefit of adding audio and video in a campaign context is it is a direct appeal from a candidate to potential voters and donors and really gives people a chance to present themselves in the best light. Every campaign I know of has video of speeches and debates that probably should be shown in some context, and there are a number of really cheap ways to pull all this information into a site without a lot of effort.

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.. :)

As I've already posted, I'm working on nodeprofiles as summer of code project - project page. Now I've some first code you might be interested to test.

I'll try to give you a short overview of the modules I built:

usernode.module - Automatically creation of usernodes
nodefamily.module - Builds nodefamilies based on content types and author information
nodeprofile.module - Marks content types as profiles

check the readme or my site for more detailed information.

• 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

I've got nodes categorized under multiple categories. Lets say one of those nodes has the keyword "Huba" and is categorized under A, B and C. In the search results for Huba, I'm getting links to nodes A, B and C, as well as for the node containing Huba. This doesn't seem right to me. Please explain. My mistake? Bug? Feature?

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.

In my opinion, the use of timestamps for the representation of dates in Drupal core is problematic. It is fine for recording all events that happen now, and it is even fine for recording historical events, as long as they happened 1970 or later. They are utterly useless if you want to make a geneology site.

More disturbingly, the event module also relies on timestamps for representation of events. As far as I can tell, this is a huge limitation. The CCK date field uses the ISO 8601 standard which saves times as as string: 20060610T20:47:48+01:00. While there are lots of arguments about how the data should be persisted in the database, to me, it is clear that the ISO 8601 string is ideal for representing the date in Drupal code (unless you're doing archeology, then I've got no idea what you do with BC dates).

Might be an interesting module. Haven't checked it out yet:

http://drupal.org/node/67385

-M

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.

there's are a few issues in the project module's queue (http://drupal.org/node/44162 and some duplicates), about how to link different issues together and record relationships between issues. so far, we've been talking about issues from the project module, but the ideas are generally applicable. i thought people interested in the issue tracking and relationships groups might have ideas. a few potential use cases:

1) recording the duplicate issue id so that a) we can automatically add a comment to the "parent" issue that another duplicate was just created (which bumps the issue's access time, since effectively the duplicate means another instance of the issue was just noticed), b) we could have a block of links in the parent that showed all the duplicates, and c) we have a consistent way to display the parent issue inside the child...

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:

I've done more work to define what I think a reasonable "first pass" could look like for events. My objective is to establish end-to-end functionality, but to cut back on features so that this phase could be completed in a relatively short timeline. I have used the UCs from my original pass through and so this new diagram is a subset of the original:

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.

One of the things I came away with from the Vancouver DrupalCon, is that we already have our relationship API, in the form of CCK and what I want to do with forms 2.0.

Firstly, in forms 2.0, there will be 2 discrete steps.

Step 1: Defining Fields for form. (or node type, or whatever)
Step 2: Placing these fields within their final form structure (add tables, fieldsets etc).

Now I am basing this functionality off of the cck field definitions, so that all the validations and field type
code will be built using cck, and one of these field types is 'nodereference'

CCK already handles all the 'has, can have and single / multiple' bits of the relationship api, and with

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