'R-Tree' is short for 'Relationship Tree'.
You can open the R-Tree for a record from the Entity Index:
You can open the R-Tree for a record from the record itself:
The R-Tree opens with your chosen entity at the top, and all of the links to that entity, and links to those links shown in a 'tree' structure below.
In the snap above you see:
I you want to switch to an R-Tree for a different entity, you can do it 3 ways:
To see more links to your chosen record, you can dig deeper in 4 ways:
If a heading in an R-Tree has a Plus sign (as in the AAP for the Expression record in the snap, above):
If heading does not have a plus sign, but the <Dig> button (on the bottom-right of the R-Tree) displays either 'Dig' in bold, or a number, then:
Whether or not a heading in an R-Tree shows a Plus sign, you can try to dig deeper using the context menu:
Whether or not a heading in an R-Tree shows a Plus sign, you can try to dig deeper using the <Ctrl+D>:
You can use the <Dig> button, at the bottom left of the R-Tree screen, to expose all possible links to the heading at the top of the R-Tree:
Once you click that button, its label changes from “Dig” to a number that represents the 'level' of the dig, and RIMMF 'digs' one level deeper in the relationship tree and adds more rows to the display.
Every time 'Dig' is pressed, the program moves down one level and retrieves all relationships for all rows at that level.
When there are no more relationships to discover, the <Dig> button disables itself.
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.
You can add or remove columns in the R-Tree by clicking on the Column control button, to the left of the Relationship heading:
Here, I removed the 'Short URI' column:
The display returns to the default setting, the next time you open an R-Tree.
To select a heading from an R-Tree display, individually:
To select all of the records shown in an open R-Tree:
If the Delete button is not visible at the bottom–
If the Delete button is visible at the bottom, the checkbox in the column header has a different behavior. In this case, clicking the checkbox in the header selects only visible rows.
Collapsed rows (those hidden beneath '+' glyphs) will not be selected. To check these items they must be visible, so you will have to either 'Dig' them out, or use the individual '+' buttons to expand them, or, in later versions of RIMMF, use the big '+' button at the bottom of the form to expand everything.
The reason for this different behavior is to try to prevent the inadvertent deletion of an entire entity index.
If you have a lot of records open, and would like to quickly close one or more of those records that are included in an open R-Tree:
If you would like to export the record(s) for one or more of the headings shown in an open R-Tree:
<!–
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.
–>