Hi there, What you propose, is a *very* interesting idea, but it is still very academic, therefore I want to present three Drupal use cases that IMO should be covered by this new relation 'thing'. If these are all covered it will: * save code * introduce better generalisation * introduce cross-site relations 1) Outlining (now called books). 2) Filed_under (simple taxonomy) 3) Taxonomy (complex taxonomy) ad1) IN essence its a simple node to node relation with some additional information. In your scheme it would look like: f_type | f_data | r_type | r_data | r_who | t_type | t_data node | 12 | parent | 5 | | node | 16 node | 22 | parent | 8 | | node | 12 node | 12 | parent | 4 | | node | 50 would make an outline of: -22 -- 12 ----50 ----16 The r_data is what we now call "weights". ad2) term | dog | taxo | | moshe | node | 17 "taxonomy relationship between term dog and node 17, by moshe ad3) term | dog | taxo | | moshe | node | 17 term | teckel | parent | | moshe | term | 100 taxo tree will be - dog ----teckel node is related to dog. Hope this will convince more developers that this idea is GREAT. Ber ------------------ ON a sidenote: I have been experimenting with relativities for a while too now. I coded a node to node relation a while back, and recently made a module that uses taxonomy for node to node parent-child relations: (one of thse badly named...) clipper. My plans are to continue on this road in near future, The site that uses these relations is Remixreading.org. It needs parent-child relations betwwen pieces of art. My plans were, to merge clipper into books, and call it outlines. outline.module or so. However, your post shines some new light over these plans: Relate anything. Op zaterdag 12 maart 2005 00:53, schreef Morbus Iff:

In working with taxonomy, I'm now leaning toward the following as a replacement for term_node (I'm using words here for readability, but assume all "id" columns are, in fact, numbers):

tid | uid | type | id ----------------------------- cat | morbus | image | 67 cat | moshe | node | 17 dog | killes | comment | 129 cool | dries | user | 1

which would also satisfy node/899 as well. But, my work with librarian tech and the LibDB project (now halted) has resurfaced because of the above. The "type / id" mentality was used in LibDB's relationship table, but was expanded to include a generic two way relationship. I'd like to bounce the same idea for Drupal core and see what you think.

Here is the table structure and example data (again, assume that if an ID makes sense in the column, it'd be there, and that "f" is "from", "r" is "relationship" and "t" is "to"). I've include explanatory sentences under each column:

f_type | f_data | r_type | r_data | r_who | t_type | t_data ------------------------------------------------------------ term | cat | taxo | | morb | image | 67 "taxonomy relationship between term cat and image 67, by morbus"

term | dog | taxo | | moshe | node | 17 "taxonomy relationship between term dog and node 17, by moshe

user | morb | user | friend | moshe | user | dries "user relationship: moshe asserts that user morbus is a friend of user dries"

user | jonbob | user | lover | morb | user | dries "user relationship: morbus asserts that user jonbob is a lover of user dries"

user | walkah | rating | 6 | walkah | node | 16 user | morbus | rating | 10 | morbus | user | dries "user walkah has given node 16 a rating of 6" "user morbus has given user dries a rating of 10"

And so on and so forth. In essence:

* anything can relate to anything else. * the types of relationship are defined by the module. * relationships may have additional data (rating, "friend").

The above is pretty powerful (but at what cost - who knows a lot about gigantic tables - is the lookup insanely bad?), and is flexible enough to handle a lot of features that would normally require overhauling existing tables or creating new ones entirely. Two recent modules I've seen, for example, serve the following purpose:

* different URLs use different templates (sections module, I think). * nodes can be in a child/parent rel (node_relativity, I think).

I'm assuming they both do this magic with new tables. But, what about:

url | /forums | sections | | morbus | template | happy.tpl node | 16 | relativity | child | morbus | node | 19 node | 18 | relativity | inspired | morbus | node | 25

And so on. Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]

Morbus Iff wrote:

And so on and so forth. In essence:

* anything can relate to anything else. * the types of relationship are defined by the module. * relationships may have additional data (rating, "friend").

The above is pretty powerful (but at what cost - who knows a lot about gigantic tables - is the lookup insanely bad?), and is flexible enough to handle a lot of features that would normally require overhauling existing tables or creating new ones entirely.

this reminds me much of http://lists.drupal.org/archives/drupal-devel/2003-05/msg00042.html just a random thought :) -- ax Cameron: [singing] When Cameron was in Egypt's land..."let my Cameron go!"