RDA Relationship designators in MARC Report

MARC Report versions 244 and 245 add 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:

By “Linking Tags” we refer to tags 760-787.

MARC Report continues to provide validation for $4 (MARC Relator codes) in appropriate headings fields.

We do not provide relationship designators support in the Series Added Entry fields because that relationship is explicit in the 8XX fields.

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.

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

To add or edit a relationship designator, either enter a known term directly after an appropriate subfield code, or press the <F7> function key to drop down a context-sensitive list of terms, from which you can select the one you want to apply.

For instance, continuing with 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 RDA relationship' checkbox (selected by default).

Use this option as a quick way to completely 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.

To disable the RDA pop-up list functionality when editing: uncheck all of the MARC tag checkboxes on the left panel

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 corresponding 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

Thus, these options apply both to editing and validation (the latter includes both record mode and batch mode).

In addition to the above, there are a few additional options that allow you to further customize your RDA relationship behavior.

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).

Show reminder if missing relationships

This option will display a message if the record is following RDA description conventions (040 $e is 'rda') and a heading is missing an RDA relationship (for example, a bib 700 field without $e). The default is true.

Why?

In RDA, it is very important to specify the relationship between an Agent and a Resource–this will make your data more useful, especially if that data is to function well in the world to come after MARC.

The next two options are 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).

Capitalize $i phrase

This option is false ('off') by default. If selected, when a phrase from Appendix J is added to a 7XX field, the first letter of the phrase will be capitalized.

Since these phrases might display at the beginning of the relationship in the catalog, some users may want them to begin with an uppercase letter⁵⁾.

Scope of the above options

The two options common to both Appendix I and Appendix J ('force case-sensitive validation' and 'show reminder if missing') are applied only to the tags that are selected in the boxes above them. For example, consider:

100 $aDoe, John,$eAuthor.

If '100e' is selected, and the Appendix I option 'Force case-sensitive validation' is selected, then a message will display about the term $e being in the wrong case (it should be 'author', not 'Author'). If '100e' is not selected, no message will be shown (since in that case, the 100 $e will not even be validated).

The two options that appear only in the Appendix J section ('require colon after $i' and 'capitalize $i phrase') are 'global'–they apply to any of the tags in the Appendix J box, whether they are selected or not.

At the top of the right side of the RDA options page, are the 'Relationship editors' for RDA Appendix I and RDA Appendix J:

These editors provide 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.

These editors use the “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 the associated Appendix will be 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 this 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, such usages are disabled in the default matrix. This restriction makes it easier to select the relationship term that is appropriate for the current tag/subfield.

Continuing with the 'appellant' example, 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

If you do not agree with the decisions about the suitability of terms in various MARC headings fields, create your own “Set” from the default, then 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:

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⁶⁾.

When you are adding or editing relationship designator terms, or validating the work done by others, the option 'Set' 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 'set' is selected, then:

• a record containing 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.
• when editing tag 100 subfield $e, and you press <F7>, only those terms that are checked in the selected 'set' as appropriate or valid in 100 will appear in the pop-up list.

Differences in the Appendix I and J editors

There are a few differences between the two RDA editors.

The Appendix I editor includes the corresponding MARC Relator code after the term. This column is suppressed in the Appendix J editor because there are no MARC Relator codes for WEMI to WEMI relationships.

In the Appendix I editor, term definitions automatically pop-up when the mouse rolls over a term. (You can disable this behavior using the Tools menu). In the Appendix J editor, term definitions appear in the last column of the table. (Click anywhere in the definition column to toggle the line-wrap mode).

Finally, there is only one tag column (“in 7XX”) in the RDA Appendix J editor. This checkbox will disable or enable terms for any of the tags that are listed in the Appendix J section on the main RDA options form.

Notes

Terms with red text are deprecated and should not be used in current records–they have been replaced with another term (we are working on that part).

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 the option RDA relationship support on the RDA page of the options.

You can sort any column in the editors by clicking on the column header. Instant filtering is also available for all columns, although this will most likely be useful only for columns that contain repeated data.

The 'uri' column in both editors is actionable. Doubleclicking the uri will open a browser on the RDA Registry information for the clicked-on term.

The 'Toolkit' column is also actionable in the same way, although RDA Toolkit access requires a subscription ⁷⁾.

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.

MARC Report version 244 provided a Relationship editor only for RDA Appendix I. The corresponding editor for terms from Appendix J (WEMI to WEMI) was added in version 245.

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 of 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.

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.

The capability to validate RDA strings in languages other than English was added to MARC Report in version 2.50. Currently, French, German, and Spanish are supported. We may add more languages in the future.

RDA validation is based on the RDA Registry. Therefore, the universe of language support in MARC Report is limited to the languages in which RDA has been fully translated into.

For information about RDA translation, visit this link: http://www.rdaregistry.info/rgAbout/rdaref/translations/

VALIDATION

Access the “RDA Language Support” options from the “RDA” page of the program options–
click the “Edit” button (in the middle of the right side of the page) to pull up the language options.

Select the codes for the languages that you want to validate.

The default language is English.

The validation of RDA strings applies to the MARC content designators that you have selected for validation on the preceding page of the options. In the default setup, this would be the following:

100 $e, 110 $e, 111 $j
336 $a, 
337 $a, 
338 $a
700 $e, 700 $i
710 $e, 710 $i
711 $i, 711 $j
730 $i

As time goes on, this list may change. For example, support for validation of the 34X fields could be added to a future version; if that happens, language support for these fields will also be simultaneously implemented.

IMPORTANT NOTE

The leader character encoding byte (000/09) must be set to 'a' in order for validation of non-English RDA strings to take place.

HOW IT WORKS

Validation is tied to the 'Language of cataloging', as specified by the 040 $b language code in a record.

Thus, if the language of cataloging is 'fre', and if you have selected 'fre' on this options page, then the program will validate the RDA strings from the selected content designators against the corresponding French strings in the RDA registry.

However, if the language of cataloging is 'fre', and you have not selected 'fre' on this options page, the program will validate the RDA strings against the default (English) strings from the registry; and if the language of cataloging really is French, then you will likely see a lot of error messages.

In this second case, one of the first error messages you will see will say

040 $b validation disabled

as a way of prompting you to check your RDA language options.

If the language of cataloging is not one of the language codes currently supported, for example, 'ita', then instead the following message will appear:

040 $b validation not supported

as a way of advising you that because we do not yet support RDA strings for Italian, then we cannot validate them.

Note that the reason for this 'lack of support' of a language may be either:

1) There is not a full translation available from the RDA Registry, or
2) MARC Report lacks the capability to display diacritics for that language

As mentioned above, English is the default validation language in MARC Report. So, in either of the cases above where an error message regarding the 040 $b is displayed, the program will try to validate the RDA strings in the record against English language strings.

To further illustrate, and to emphasize the importance of the 040 $b, lets consider the following scenario: you have selected French as a validation language option, and you import a record with 040 $b set to 'eng'; you then change all of the RDA terms in the record from English to French, but do not change 040 $b to 'fre'. MARC Report will then spit out an 'Invalid' message for every one of strings in the record that are validated as RDA strings.

RDA APPENDIX OPTIONS

Beginning in version 2.51, a language dropdown box that appears when customizing the list of relationships from RDA Appendix I or Appendix J.

The purpose of this box is to display the strings–the relationship labels and their definitions–in the supported languages. So, for instance, if you would prefer to see French labels and definitions, then simply select “fre” from the dropdown box.

What's important to note is that only the strings displayed change–the validation selections (eg. “In 100”, “In 700”, etc.) remain the same across all available languages. For example, if I modify the default set (by creating a new set), and turn on “In 100” and “In 110/11” for the relationship labelled “editor” in English, and then change the language of the strings to “fre”, the selections for “éditeur” for “In 100” and “In 110/11” will remain in place.

LANGUAGE SUPPORT SUMMARY

1. Use the RDA Language Support page to modify which languages are validated.

2. The leader character encoding byte (000/09) must be set to 'a' in order to validate non-English

3. Decisions made using the Appendix I and Appendix J editors apply to all languages.