Relations can take place between many different items in Drupal. Items can be content, users, categories, or other. The fruits of relations could be represented in many different ways including embedded links on story pages showing related stories, a block in the sidebar showing related terms to the current article you are reading, a user's buddylist showing related users, or in other words, the user's buddies, a graphical map representing FOAF or sixth degree relations between users on a site, a list of nodes that refer to a given file in the Drupal files directory, a list of users who are attendees to an event...

In a concept writeup on a hierarchical relations system in Drupal, Allie Micka writes

Drupal already has a "node" concept to cover all kinds of content. That's great, but how do you relate nodes to users? Or vocabularies to nodes? Or (and this one has bitten me) users to vocabularies? "Node" general, but I want a hierarchy system that's cognizant of all kinds of information so I need to be even more general.

Allie goes on to describe an example of one end of the UI:

Say, for example, we have event->user (0-10)(linked) and event->image (1-5)(embedded) and event->weblink (1-1)(embedded),
which means that an "event" can have 0-10 participants, 1-5 images and exactly 1 weblink.
When editing an event, its driver (node) discovers these possible relations and includes a form to:

1) Select <10 users from a dropdown. If there are more than 10 users selected, node validation fails.
2) Select 1-5 images, OR indicate that I will add new ones (OR both).
The next form page contains 5 image upload dialogs
3) Include a "weblink" field - some kind of a mini-inline-node interface, and set validation to require it.

Upon displaying the node, some kind of user list/links will be appended and the images and weblink appear inline. Similar to how Flexinode does this, also themeable by each module and by the theme system itself.

The discussion here of how to handle relations in Drupal deals with how specific or general the system should be. Javanaut compares the ongoing discussion to what was done with the node_access API and how reaching an agreeable code base perhaps led to greater innovation in the use of node_access via other modules. Javanaut says,

I do, however, like what was done around the node_access construct. A structure was built that allows multiple node_access modules to potentially coexist without breaking the system. The modules manage the data and drupal core queries it to determine access to a node for a given user. This lets modules be in control while centralizing a lot of overlapping code. I don't recall if multiple node_access-like modules existed prior to the development of this system, but several do now. This feature brought about some innovation that I doubt would have happened without the core code.

Ber last wrote his first aim is to get the relations system working for three particular modules: shazamgallery, clipper, and buddylist. Ber has a point in getting the system working, actually getting the code written, then reworking and developing the API as more modules move toward using the general relations system, which will then result in reworing the original modules that were made to work with the relations system. Allies arguement has been to make clear objectives on with what and how the relations system can serve items in general in Drupal, without starting too narrow for just a couple module's needs - perhaps these few modules do not represent the more than 10 relation-like modules in Drupal contribs.

To follow shortly is a summary on several relations type modules available for Drupal.