I love this module - Using it in a genealogy web site to relate Researchers to Surnames being researched. For every Researcher, I have a Note field per Surname specifying the scope of his research - currently have nowhere to put the data.

What would be brilliant is the ability to add a description/notes field to the Relativity table that describes the relationship between parent and child, and then to render this as part of the list of children eg.

Researcher: Paul Mare
Surnames
Surname: Mare, All of South Africa & France before 1795
Surname: Erasmus, All of South Africa
Surname: Bouwer, Direct ancestors only

An integration with flexinode might be more interesting - that would perhaps allow flexible field definitions for relationships that can be rendered in the UI? More complex though, would prefer a quick fix or path to handle just a free-form description field for now.

Many thx for considering...

Comments

zeliboba7’s picture

I'm voiting for this feature also!
it is useful for me also, since I'm collecting scientific papers and relate them using "citations" and "cited by" (similarly to http://isiknowledge.com). sometime it is very useful not only to say "paper A refer to paper B", but also to make a note in which context paper A refer to B (let's say "paper use a method described in B"). I guess it is rather easy to implement: just add one more field to linking table where you keep references and interface.
thank you

darius’s picture

I would like to encourage more discussion, comments, detailed suggestions, even patches from everybody regarding this feature. Go ahead and brainstorm.

zeliboba7’s picture

unfortunately my experience with mysql and php is not big enough, so I cannot suppose a good patch or so. my idea is to modify the table relativity like this:

CURRENT:
+------------+------------------+------+-----+---------+-------+
| Field      | Type             | Null | Key | Default | Extra |
+------------+------------------+------+-----+---------+-------+
| nid        | int(10) unsigned |      | MUL | 0       |       |
| parent_nid | int(10) unsigned |      | MUL | 0       |       |
+------------+------------------+------+-----+---------+-------+

MODIFIED:
+------------+------------------+------+-----+---------+-------+
| Field      | Type             | Null | Key | Default | Extra |
+------------+------------------+------+-----+---------+-------+
| nid        | int(10) unsigned |      | MUL | 0       |       |
| parent_nid | int(10) unsigned |      | MUL | 0       |       |
| comment    | longtext         |      |     |         |       |
+------------+------------------+------+-----+---------+-------+

then implement functions which add, display, edit the field comment. That's basically it. but as I sad, I cannot implement this...

PaulMare’s picture

Maybe extend Relativity as follows:

nid
parent_nid
Comment (for quick and easy free-form descriptions)
relationship_nid (for structured data on the relationship)

where the last field refers to a node containing more information on this specific relationship. One could then use that node's teaser and body generation logic to render a user interface...

On settings, the new fields could have an not used/optional/required flag; when creating a new relationship, ui should work as it currently does if fields are "not used"; otherwise, we need an additional UI piece to capture related comment. If relationship_nid is used, the new node should be created and presented for editing...

Trust this makes sense, otherwise shoot me :-)

Cheers
Paul

efolia’s picture

I'm afraid that adding anything that approaches *content* to the table would ruin the whole concept of Relativity. The idea (genius) behind it is that it allows related data to quickly link to each other and to enforce those relationships in a way that is not really possible otherwise. Content has to *exist* somewhere, as part of another node in the graph, otherwise it has no intrinsic value. Therefore whatever data structure you want to manage should to be a part of the directed graph (http://en.wikipedia.org/wiki/Directed_graph) that Relativity manages.

Adding semantics to the vertex would require the integration of RDF (or OWL), something the Relationship module (http://drupal.org/project/relationship) aims at implementing. Darius mentionned he'd eventually work on it this integration (I'd be more than happy to collaborate on that too... it's a fascinating project). A successful merge between those two modules would probably go down in the history of computer science as one of it's turning point as far as data management is concerned -- since RDF is so intrinsically cryptic that it has few if any practical applications except in some highly specialized fields, and Relativity (as a front end) works *out of the box* to perform it's magic.

-) efolia (-

MrTaco’s picture

i don't have any suggestion when it comes to adding *general* types of fields to a relation object

but it really sounds like all you need is one "label" for the relationship that allows you to specify what type of relationship it is, as well as to display this relationship label on page view

this (as well as inline CRUD operatoins) is easily accomplished with my cck subform module (http://subform.googlecode.com/svn/trunk/subform_trunk.zip)

JohnG-1’s picture

If anyone is still interested in this feature, see comment #13 at http://drupal.org/node/82415

It is a method for displaying (CCK) field data for each (Relativity) child in a (Views) table embedded in the parent node (via node-parent.tpl.php).

Hope you like it :)