R-Tree

'R-Tree' is short for 'Relationship Tree'.

Every record that one views in RIMMF will have an R-Tree button in the bottom-right corner of the form (in the 'WEMI Links' panel).

Given a record like the following:

pressing the R-Tree button will result in a form that looks like this:

The purpose of the Relationship Tree is to select all of the elements in the record that link to other elements in other records, and display them in a sort of hierarchical (or tree-like) format.

Further, each time one presses the 'Dig' button (on the bottom-right), RIMMF 'digs' one level deeper in the relationship tree and adds more child rows to the display. When there are no more relationships to discover, the 'Dig' button disables itself.

The R-Tree display always begins with a row for the record from which the R-Tree was launched; so in the example above, that would be the 'MARC21 for everyone' Manifestation record. It then lists, as children of that row, all of the elements in that record that link to othe records. In the example, there is only one other (Direct) link, and that is to the Expression (not shown in the first screenshot).

When 'Dig' is pressed, the program moves down one level and retrieves all relationships for all rows at that level. Going back to the first 'R-Tree' screenshot, when we press 'Dig', RIMMF starts with the 'Expression manifested' and retrieves an entry for each element in the Expression record that links to another record. In the case of our example, the result is:

So, in the expression record, we see that there is only one link, and that is to the work. If we dig again, RIMMF starts with the work record, and comes up with the following:

The work record contains links to two creators, and they are both listed as children of the work in the last display.

But hold on, shouldn't there be a a link from the work to the expression?

Yes, there should be, and there is. But to see it in the R-Tree you will need to turn off the 'De-dupe' option (to the left of the Dig button).

The 'De-dupe' option prevents an entry from appearing more than once in the R-Tree, which is why the 'Expression of work' is not being displayed in the screenshot above. If we de-select this checkbox, we will have an R-Tree display like this:

As you may observe, running the R-Tree with dedupe disabled will result in a more complete picture; but for records with large numbers of linking elements, this complete-ness can quickly become a bit too much.

So we will leave it for you to decide which approach you prefer.

There are a couple of limitations to the R-Tree functionality in version 1.

First, RIMMF will only display entries in the R-Tree for elements that link to elements in other records. For example, if you made an expression record in RIMMF, and added some contributors to that record, but instead of using the 'Link to' menu, you simply entered the contributor's name in the Authorized Access Point element, RIMMF will not add that contributor to the R-Tree.

For example, in the following excerpt:

the Contributors were entered as Authorized Access Points instead of as links to Person records; thus in the resulting R-Tree, no trace of these contributors will be found:

This is a limitation in RIMMF; there is nothing in RDA that requires that an identifier to link to another record¹⁾.

Second, RIMMF will only display the first relationship designator for an element (in cases where the same element contains more than one). For example, in the following snap, note that there are two relationship designators for the entry for 'Glen Morgan':

And opening the R-Tree, we see that only the first designator is given for 'Glen Morgan':

Third, RIMMF does not automatically create backlinks when you make a link from one PFC to another. The reason is that, in order to do this, RIMMF has to figure out the inverse of the relationship designator in the link from entity. To fix this we need a table of inverse relation designators.

For example, if we link the record for a Person to a Corporate Body, RIMMF will not automatically (as it does for the WEMI entities) make the corresponding backlink from the Corporate Body back to the Person. Thus, if opening the R-Tree for the Person, no entry for the Corporate Body appears. The workaround for this is to open the Corporate Body record (after you make the link to it from the Person), and add a link back to the Person in the 'Related Person' element.

<!– Both of these problems are related to our implementation.

To make 'linking' work in RIMMF, we created something called the RLD table (RIMMF Linking Data), which consists of little more than a list of every record and all of the other records that it links to:

This type of table fits in very nicely with the RDBMS approach that we used beneath the surface in RIMMF, and allows very quick access to the data needed to generate the menus used in linking, and in the R-Tree.

However, the table was based on the assumption that only links will be of interest–as opposed to data entered directly into Authorized Access Points; and as we have seeen above, not every 'access point' will be a link.

Second, one constraint that we applied to the RLD was that one record will only link to another record once. This logic was based on the thinking that, since in RDA, everything is separated into entities, a record for something like a work should only link to a record for something like a person once. But we forgot to account for the concept of repeated relationship designators, and thus, the design falls a bit short in this case also.

Its probably worth noting in this context, that the R-Tree is based completely on the RLD; any data not found in the RLD will not appear in the relationship tree.

–>