RDA Relationship designators

MARC Report 244 adds extensive support for two important lists of RDA Relationship designators that we use in MARC to describe relationships:

• Relationships between a resource and a persons, family, or corporate body associated with the resource (from RDA Appendix I)
• Relationships between works, expressions, manifestations, and items and other works, expressions, manifestations, and items (from RDA Appendix J)

Beginning with version 244, relationship designator support is provided for the following fields/subfields:

Version 244 also continues to provide validation for $4 (Relator codes) in appropriate headings fields.

We do not provide this support for the series relationship designators, because that relationship is explicit in the 8XX fields.

Validation based on this new relationship support is applied only to 'RDA' records (that is, those records with an 040 $e 'rda').

We will provide support for subject relationship designators, in a later version.

In MARC, tags and coding alone are usually not explicit enough to indicate specific relationships. The 8XX tags are sufficient for the appropriate “In series” relationship designator; but, e.g, MARC tag 700 tells us only that there is a relationship between the resource and something else; it does not say anything about the nature of that relationship.

Looking at the subfield coding can tell us a little more. Continuing with the MARC 700 example, if a subfield $t is present, we can at least know that the resource being described is being related to another resource. Here, Doyle's work “Hound of the Baskervilles” is related in some way to the graphic novel that is described by the record in which this 700 appears:

700 1 $aDoyle, Arthur Conan,$d1859-1930.$tHound of the Baskervilles.

Whereas, if a subfield $t is not present in a 700 field, we know that the resource being described is being related to a person or family¹⁾. Here, the described resource (titled: Persuasion) is related in some way to a person named Dothard, Robert L.:

245 10$aPersuasion /$cJane Austen ...
700 1 $aDothard, Robert L.

However, this still does not tell us anything specific about the relationships involved, and this is where the RDA relationship designators step in.

In the first example, we might ask “exactly how is this resource related to Hound of the Baskervilles”?

RDA provides a way to answer to that question by having us add a relationship designator; as implemented in MARC, we use a subfield $i for resource-to-resource designators:

700 1 $iBased on (work):$aDoyle, Arthur Conan,$d1859-1930.$tHound of the Baskervilles.

Similarly, in the second example, we might ask “what does Robert Dothard have to do with Persuasion”?

Again, adding a relationship designator sheds light on the nature of the relationship, and in MARC we use a subfield $e for resource-to-person designators:

245 10$aPersuasion /$cJane Austen ...
700 1 $aDothard, Robert L.,$ebook designer.

Starting with version 244, MARC Report makes it easy to add, validate, and edit these RDA relationship designators in your records.

To add or edit a relationship designator, you can either type a known term directly after an appropriate subfield code, or you can now use the <F7> function key to choose an appropriate term for that subfield from a pop-up list.

For example, for the “Persuasion” example above–

245 10$aPersuasion /$cJane Austen [...]
700 1 $aDothard, Robert L.

–to add an appropriate relationship designator from a pop-up list for a subfield $e:

• put the cursor at the end of the 700 field
• type $e
• press <F7>:

Pressing <F7> presents a list of applicable relationship designators, immediately below the field ²⁾

• select the designator that you wish to apply from the pop-up list
• press <Enter>.

MARC Report adds the selected term to the field at the cursor position, and also automatically adjusts preceding and succeeding punctuation:

(But if you wish to adjust the punctuation manually, go for it! MARC Report will not double-up on the punctuation)

Slightly differently, to add a relationship designator in a subfield $i:

• put the cursor at the beginning of the field, in front of subfield $a
• type $i
• press <F7>
• select the relationship that you want to add (in the “Hound of the Baskervilles” example this was “Based on (work)”)
• press <Enter>³⁾.

Notes

Punctuation, the bane of MARC, is probably not always as straightforward as in the example above. In some cases you might need to correct the automatically applied punctuation, as the automation may not anticipate every possibility (and if you find something that just doesn't seem to work, please let us know so we can fix it).

The pop-up list of relationship designators supports 'type-ahead' (aka, incremental search); so that, in the Dothard example, pressing 'b' after the list displays will drop down to the first term that begins with 'b' (currently, 'binder'); and pressing 'b' + 'o' will drop down to … 'book artist', and from there 'book designer' is one down arrow press away.

Note that when typing multiple letters, as in 'b' + 'o', a timer is involved, so that the 'o' must be pressed fairly quickly–just as if you were typing the word 'book'. If you wait too long before pressing 'o', the type-ahead feature jumps instead to the first word beginning with the letter 'o'.

NB. The relationship designator list that is used in MARC Report by derived from the RDA Registry. At present, the Registry is not perfectly in sync with the RDA Toolkit. So if a designator is added to the Toolkit (because of 'fast-track' change, etc.), but not (at the same time) added to the Registry, it will not appear in MARC Report. Thus, a valid designator may appear in a new MARC record but be flagged as invalid by MARC Report. If you find this happens, please report the omission to us. Another alternative is to add the designator as a 'Local term' (and then remove it once the update has trickled down to MARC Report).

Customization of this new feature is handled on the 'RDA' page of the program options.

Note at the top of the left-panel is an 'Enable' checkbox (selected by default).

You may use this option as a quick way to switch on/off RDA relationship validation in MARC Report.

Note that this option does not affect the list of terms that appears when pressing <F7> while editing a record, or the more comprehensive documentation that appears when pressing <F1> for MARC Help.

On the left side of the RDA options page, are two groups of MARC tags and subfields for RDA Relationships: one for RDA Appendix I and one for Appendix J. Use the checkbox for a MARC tag/subfield code (e.g., 100e) to enable/disable validation checks and pop-up lists for the tag/subfield⁴⁾

For example, in the Appendix I group, if '100e' is selected, then in MARC Report:

1. Text in 100 subfield $e will be validated against the terms from RDA Appendix I
2. Pressing <F7> –while editing subfield $e in tag 100–provides a pop-up list of appropriate terms from RDA Appendix I

On the other hand, if '100e' is not selected, then in MARC Report:

1. Text in 100 subfield $e is not validated
2. Pressing <F7> –while editing subfield $e in tag 100–has no effect

NB. Its important to note that the options here apply both to editing and validation.⁵⁾

In addition to the above, there is a separate option for each RDA Appendix that applies only to validation:

Force case-sensitive validation 

Since RDA is not particularly concerned about capitalization, the default is 'off' for this option (so capitalization differences will not generate a warning message). However, you could turn this validation check on, if you are concerned about consistency in the display of the relationship terms in your online catalog (especially those from Appendix J, perhaps).

A second option is applied only to the Appendix J terms:

Require colon after subfield $i

This option is on by default and:

• adds a colon after a selected relationship designator, added in subfield $i
• warns about a missing colon in an existing subfield $i

If you are not using a colon as separating punctuation for this data, despite LCPCC-PS 1.7.2, then turn this option off. (Note that no warning is given when this option is turned off and a term in subfield $i ends in a colon).

To completely disable MARC Report validation and pop-up lists of RDA relationship designators when editing:

• Go to the RDA page of the options
• Uncheck all of the MARC tag checkboxes on the left panel

At the top of the right side of the RDA options page, is another 'Relationship' option:

This option provides an interface to a detailed view that makes it possible to control the pop-up lists and validation of the terms from the RDA appendices on a term-by-term by tag basis.

This option uses a similar “Sets” design that can be found throughout MARC Report: we supply a default “set” of options, which the user may then customize by deriving their own set from the default.

Press 'Edit' to open the editor. The default 'matrix' will be displayed. Each RDA term from Appendix I is listed on the left, followed by a series of checkboxes.

How does this work?

Note the column captions beginning with “In”; this is a short means of saying “Appropriate to or valid in this tag”. Each column contains a checkbox for each term in the list. We might read each row as saying “the term on the left is appropriate to or valid in the MARC tag provided in the column header above”.

For example, at the top of the list is the term “abridger”. The first two checkboxes on this row are not checked, but the last two are; which is to say, the term, “abridger”, is not appropriate in a MARC 1XX Main entry field, but the term is appropriate in a MARC 7XX Added entry field.

Using this form, or matrix, you can configure validation and pop-up lists for each RDA relationship individually.

We have, after much research and analysis, determined that not all of the RDA terms are appropriate in all of the MARC tags for which they are possible, and the result of this analysis is the 'DEFAULT' set.

For example, RDA makes it possible to distinguish between 'person' and 'corporate body' in some cases, e.g., “appellant person” or “appellant corporate body”. Since its not appropriate for a term that specifically applies to a corporate body to be used in a MARC X00 field, nor a term that specifically applies to a person to be used in a MARC X10 field, these fields are not checked in the default matrix. This means that:

• “appellant person” will appear in the pop-up list that is provided for the 100 and 700 (person heading) fields, but will not appear in the pop-up list for the 110/111 or 710/711 (corporate body/conference heading) fields
• “appellant corporate body” will appear in the pop-up list that is provided for the 110/111 and 710/711 (corporate body/conference heading) fields, but will not appear in the pop-up list for the 100 or 700 (person heading) fields
• an error message will appear if “appellant person” appears in a 110/111 or 710/711 (corporate body/conference heading) field and the DEFAULT set is in place
• an error message will appear if “appellant corporate body” appears in a 100 or 700 (person heading) field and the DEFAULT set is in place

A much more complex issue is that of the MARC Main entry vs. Added entry concept. For example, “writer of added commentary”, “writer of added text”, etc., are relationship terms that are appropriate only for headings given as MARC added entries, and so, in the default matrix, the 1XX fields are not checked for those terms, but the 7XX fields are checked. This means that, e.g.:

• “writer of added commentary”, will not appear in the pop-up list that is provided for a 100, 110, or 111 field, but will appear in the pop-up list for a 700, 710, 711 field
• an error message will appear if “writer of added commentary” appears in a 100, 110, or 111 field and the DEFAULT set is in place

Customization

Just in case you do not agree with our decisions about the suitability of terms in various MARC headings fields, you can create your own “Set” from the default, and adjust the matrix to suit your own decisions. To create your own Set:

• Select 'File | Create new set'
• Enter a name for the new set
• Customize the resulting matrix–which will always begin as a copy of the default set

To quickly enable or disable all of the checkboxes in the matrix, use the appropriate option from the 'Tools' menu for the RDA options page

Note that disabling all of the checkboxes in the matrix has the same effect as disabling all of the MARC Tag checkboxes on the main options page (as shown here):

In short, no validation will be performed, and no pop-up list of terms will display when editing.

For best results, uncheck all of the MARC Tag checkboxes on the main RDA options page to disable validation for these relationships completely.

When you are adding or editing relationship designator terms, or validating the work done by others, the Relator matrix that you choose will dictate what is:

• provided as a pop-up list of relationship designator terms that are appropriate for the 100$e, 110$e, 111$j, 700$e, 710$e, 711$j
• given as an error message for relationship designator terms that are not provided in the pop-up lists for the 100$e, 110$e, 111$j, 700$e, 710$e, 711$j

For example, if the default options are in place, then:

• a record containing a tag 100 subfield $e with the term 'illustrator' will pop up an error message, and you will be alerted that this concept belongs in an added entry field.
• if you are editing a tag 100 subfield $e, and press <F7>, only those terms that are checked in the matrix as 'appropriate or valid in 100' will appear in the pop-up list. This restriction will make it easier to select a relationship term that is appropriate for the tag/subfield.

Difficulties in MARC usage

Its easy to see how far apart MARC and RDA are when we look closely at some of the MARC usage of subfield $e.

For example:

100 1  $a Stone, Melicent, $e author, $e illustrator.

Here we see two concepts, which in RDA require separate statements, joined together in MARC: 'author' is a subproperty of 'Creator', from the 'Work' entity or class; 'illustrator' is a subproperty of 'Contributor', from the 'Expression' entity, or class.

The practice of joining incompatible RDA properties together like this is provided for by one of those MARC-centric guidelines that many of us never see:

PCC Guidelines for the Application of Relationship Designators 
in Bibliographic Records

Guideline 10.

If more than one relationship designator is appropriate because the same entity 
has multiple roles, preferably use repeating $e (or $j for MARC X11 fields).  
If necessary, multiple headings may be used instead. 

We have defaulted MARC Report to accept entries like the 'Stone' example above without showing an error message.

However, if you wish to be more faithful to RDA, there is a way to achieve this.

When the program is not running, go to your 'Documents\MarcReport' folder and open the file 'marcreport.ini' in a text editor. Scroll down to the '[RDA Options]' section and look for the two entries that begin

USEPCCWORKAROUND

There is one for validation, and one for editing. To disregard the PCC shortcut, set them both to 'N' and save the file.

Notes

This version of MARC Report (244) only provides a Relationship editor for terms from RDA Appendix I. There is, currently, no corresponding editor for terms from Appendix J (WEMI to WEMI). We are still assessing the need for this.

In order to support hybrid records, the validation described on this page is applied to both RDA and non-RDA records. If you are not using RDA at all, you may want to disable RDA relationship support on the RDA page of the options.

The MARC Relator code, listed in the second column of the matrix, is for reference purposes only, at present.

The subject access fields in MARC (6XX) also support relationship designators. But as there is quite a lot of new work taking place with regards to subjects in RDA at the moment, we have decided to delay adding support for subject relationships to MARC Report until a later version.

In RDA, the relationship designators listed in Appendix I and Appendix J are considered 'Open' lists. To quote the RDA Toolkit:

“If none of the terms listed in this appendix is appropriate or sufficiently specific, use another concise term to indicate the nature of the relationship”.

In order to support the concept of an Open list in MARC Report, we have added a separate editors for Local terms to the Appendix I and Appendix J options; these editors are accessed by pressing the 'Local Terms' button at the top right corner of the corresponding appendix options (shown above).

Pressing this button displays the form shown here:

Use this form to add a term for a relationship that is not already listed in Appendix I or Appendix J.

Note that terms added to this list are not displayed in the list of official RDA terms for the corresponding appendix. However, if the option to 'Enable local terms' is selected on the main RDA page, then local terms will be merged at runtime with whatever terms are selected using the currently defined set, and as such, they will be present both for validation and editing purposes.

The caption '[local]' is appended to terms entered using the Local Terms form when they are displayed in a pop-up list–so that you can easily distinguish your own terms from the RDA terms.

But this caption is stripped from the data if and when it is added to the MARC record.

If you invest time and thought in creating Local Terms, we recommend that you add your files of local terms to your backup regimen. The names for these files are:

My Documents\MarcReport\Options\local.rdi
My Documents\MarcReport\Options\local.rdj

(where the last letter, 'i', or 'j', indicates the corresponding RDA Appendix.

The local filename is also listed in the status bar of the 'Edit Local terms' form ⁶⁾

When MARC Report checks the relationship designators present in the MARC fields and subfields listed in the table above, and finds a term that is not present or not selected in your chosen matrix Set, or in your list of Local terms (if you have one), the presence of that term will be reported as a Cataloging Check error (the brief message appears in red text) rather than a Validation error (brief message is in blue text).

The brief message will state, for example:

700: Subf $e value is undefined

The decision to use 'red' (cataloging check) instead of 'blue' (validation) for this message is perhaps an academic distinction, but there is nothing in MARC that tells us what terms to use in these fields. There is simply the following instruction (to quote the example from the subfield $e section of the X00 page)

  $e - Relator term 
  
  Designation of function that describes the relationship between a name and a work, 
  e.g., ed., comp., ill., tr., collector, joint author. 

Hence our decision to dub these 'errors' as cataloging checks, instead of validation errors⁷⁾.

In addition to this newly added RDA relationship support in MARC Report, we have also added some new cataloging checks that will help prevent some obvious errors when adding relationship designators to headings fields.

For example, if a subfield $i is added to a 700 field that does not contain a subfield $t, a cataloging check error message like the following will display–

7XX: Subf $i relationship needs $t

–followed by the explanatory note:

In a 7XX (Added entry field), subfield $i (relationship information) is used to describe
relationships between the resource and another work, expression, manifestation, or item, 
but this field lacks the content designator necessary (subfield $t, Title of a work) 
for a work, etc. Remove the subfield $i, or update the 7XX to describe a related work, etc.

Similarly, if a subfield $e is added to a 700 tag that contains a subfield $t a cataloging check error message and explanatory note will also be displayed:

7XX: if subf $t then no $e

7XX (Added entry field) contains a name/title heading (i.e., $t is present). 
This heading refers to another resource, and not to a person, family, or corporate body 
associated with the resource: thus, subfield $e (Relator term) cannot be added to field. 
Delete the $e from this 7XX.

MARC Report supports automatic updates to the lists of relationship designators that it uses.
For a complete description of how it works, please visit this link.
To view the RDA relationship designator update history, click 'List Updates' in the sidebar on the left.