R-Tree

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

Every record that you view in RIMMF will have an R-Tree button in the bottom-right corner of the form.

Pressing the <R-Tree> button in this Work record will display a form that looks like this:

If you look back up at the Work level, you will see that this starting R-Tree display is showing all of the links that are found in the Work record, where you invoked this option:

• At the top: the Authorized Access Point (AAP) for the Work record (where you started)
• Then, links to:
  • the AAP for the linked Expression record
  • the AAP for the two linked Author records

If you wish to dig deeper and display records that are linked to each of the records shown in the starting R-Tree disply, you can click on the 'Dig' button (on the bottom-right of the screen above; it changes to a number representing the 'level' of the dig, once it has been clicked), and 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, the top level is showing the Authorized Access Point (AAP) for the Work record. Below it we see the AAP for the Expression record, and the 'dig' exposed the AAP for the Manifestation record.

You can also 'dig' down at a specific AAP, by clicking on the plus sign ([+]) if it is showing. If it is not showing, you might have to use the 'dig' button to expose the next level first; after which the [+] will appear, if another level is present. If we click the [+] for the Manifestation, we see the AAP for the Item record:

When 'Dig' is pressed, the program moves down one level and retrieves all relationships for all rows at that level.

In the examples above, we show what displays when you have the 'De-dupe' option turned on. If you want to see every link in every record displayed, even if it has already been displayed, you can turn off this option and get something like this:

The 'De-dupe' option prevents an entry from appearing more than once in the R-Tree, which results in a much neater display. 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.

• RIMMF will only display entries in the R-Tree for linked elements. For example, if you make an expression record in RIMMF, and add a contributor to that record, but instead of linking to the Person record for that contributor, you simply enter the contributor's name in the Authorized Access Point element, then RIMMF cannot add that contributor to the R-Tree.

• 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 3 relationship designators for the entry for 'Glen Morgan':

And opening the R-Tree, with 'De-dupe' on, we see Morgan, Glen given with only one designation, the first one listed:

But if we turn 'De-dupe' off, we can see his name repeated, for each designation:

This illustrates when it might be useful to turn off 'De-dupe', at least until we can figure out how to make this situation display better.

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.

–>