Relationships & site structuring

Hi all,

Is there a way to make vocabularies hierarchically dependent, so that their terms would inherit this hierarchy?

Example:

Now for tagging an event we first select Country, then City, then Theater.
I found no solution for this on D5, now I'm on D6.
Any ideas (patches are welcome too)?

And, of course, having this working together with http://drupal.org/project/hierarchical_select would be great.

p.s. Thing which is not an option - placing terms in one vocab.

Hello there,
I´m working with Drupal some years now, and everytime I need to set some sort of classification, I think always in taxonomy. So I create some taxo vocabs and terms and everything goes smooth.

But recently I started to rethink my way of doing it, and started to play with CCK list fields.
You can work with them in a flexible manner, and it does have excellent Views support. You can show them in views and use them as filters, exposed or not.

So, overall, replacing Taxonomy terms for CCK text list fields are OK in my book.

Hi,

I am planning a multisite project where I want to be able to share users and some content between sites.

All sites will be more or less clones of each other, but they will have different target markets (countries mainly).

What I want to do is:

<

ul>

I'm going to bring the following issue under your attention

http://drupal.org/node/132988

Currently the directory where you can store userpictures is restricted to a map within the directory you've selected for your files
(user_picture_path must reside within file_directory_path)

However, if you're working on a multisite, with a shared database and shared tables for the usernames, seperate settings for file_directory_temp and file_directory_path it is NOT POSSIBLE to have a common pictures directory, thus severely limiting multisite possibilities.

My request is to release the restriction for the user_picture_path, and make the variable in a similar way as done with the file_directory_path (sites/domain/files) and the file_directory_temp (sites/domain/tmp) variable so we can have for example sites/all/pictures (or something else) set for user_picture_path
(user_picture_path side-to-side with file_directory_path)

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.

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

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.

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?

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.

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 ?

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)

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.

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:

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

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.

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:

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.

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

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.

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

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.

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

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

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.

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

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

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.

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