Differences
This shows you the differences between two versions of the page.
— |
help:rdarelationships [2021/12/29 16:21] (current) |
||
---|---|---|---|
Line 1: | Line 1: | ||
+ | ====== 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, | ||
+ | |||
+ | Beginning with version 244, relationship designator support is provided for the following fields/ | ||
+ | |||
+ | |||
+ | ^ MARC ^ RDA ^ | ||
+ | | 100/700 (without $t) **$e** | ||
+ | | 110/710 (without $t) **$e** | ||
+ | | 111/711 (without $t) **$j** | ||
+ | | 700 (with $t) **$i** | ||
+ | | 710 (with $t) **$i** | ||
+ | | 711 (with $t) **$i** | ||
+ | | 730 **$i** | ||
+ | | Linking Tags **$i** | ||
+ | |||
+ | By " | ||
+ | |||
+ | 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, | ||
+ | |||
+ | ===== Introductory concepts ===== | ||
+ | |||
+ | 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" | ||
+ | |||
+ | 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' | ||
+ | < | ||
+ | 700 1 $aDoyle, Arthur Conan, | ||
+ | |||
+ | 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**((and if the tag in the example was 710 instead, the relationship would be to a corporate body, and so on)). 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 " | ||
+ | |||
+ | 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: | ||
+ | < | ||
+ | |||
+ | 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, | ||
+ | < | ||
+ | 245 10$aPersuasion /$cJane Austen ... | ||
+ | 700 1 $aDothard, Robert L.,$ebook designer.</ | ||
+ | | ||
+ | ===== RDA relationship designators in MARC Report ===== | ||
+ | |||
+ | 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 " | ||
+ | < | ||
+ | 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, | ||
+ | |||
+ | * select the designator that you wish to apply from the pop-up list | ||
+ | * press < | ||
+ | |||
+ | 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, | ||
+ | * 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" | ||
+ | * press < | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | __Notes__ | ||
+ | |||
+ | Punctuation, | ||
+ | |||
+ | The pop-up list of relationship designators supports ' | ||
+ | |||
+ | Note that when typing multiple letters, as in ' | ||
+ | |||
+ | 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 ' | ||
+ | |||
+ | |||
+ | ===== RDA Relationship Options ===== | ||
+ | |||
+ | Customization of this new feature is handled on the ' | ||
+ | |||
+ | {{: | ||
+ | |||
+ | \\ | ||
+ | |||
+ | Note at the top of the left-panel is an ' | ||
+ | |||
+ | 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 | ||
+ | |||
+ | ---- | ||
+ | |||
+ | ==== MARC-based validation options ==== | ||
+ | |||
+ | On the left side of the RDA options page, are two groups of MARC tags and subfields for RDA Relationships: | ||
+ | |||
+ | |||
+ | For example, in the Appendix I group, if ' | ||
+ | |||
+ | - Text in 100 subfield $e will be validated against the terms from RDA Appendix I | ||
+ | - 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 ' | ||
+ | |||
+ | - Text in 100 subfield $e is not validated | ||
+ | - 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, | ||
+ | |||
+ | Show reminder if missing relationships | ||
+ | This option will display a message if the record is following RDA description conventions (040 $e is ' | ||
+ | |||
+ | 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 [[http:// | ||
+ | |||
+ | Capitalize $i phrase | ||
+ | This option is false (' | ||
+ | |||
+ | 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((though it would be much better if this was a local system option instead of a data option)). | ||
+ | |||
+ | __Scope of the above options__ | ||
+ | |||
+ | The two options common to both Appendix I and Appendix J (' | ||
+ | |||
+ | 100 $aDoe, John, | ||
+ | | ||
+ | If ' | ||
+ | |||
+ | The two options that appear only in the Appendix J section (' | ||
+ | |||
+ | ==== RDA-based options ==== | ||
+ | |||
+ | At the top of the right side of the RDA options page, are the ' | ||
+ | |||
+ | {{: | ||
+ | |||
+ | 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 " | ||
+ | |||
+ | Press ' | ||
+ | |||
+ | {{: | ||
+ | |||
+ | \\ | ||
+ | |||
+ | __**How does this work?**__ | ||
+ | |||
+ | Note the column captions beginning with " | ||
+ | |||
+ | For example, at the top of the list is the term " | ||
+ | |||
+ | 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 ' | ||
+ | |||
+ | For example, RDA makes it possible to distinguish between ' | ||
+ | \\ | ||
+ | |||
+ | Continuing with the ' | ||
+ | * " | ||
+ | * " | ||
+ | * an error message will appear if " | ||
+ | * an error message will appear if " | ||
+ | |||
+ | A much more complex issue is that of the MARC Main entry vs. Added entry concept. For example, " | ||
+ | * " | ||
+ | * an error message will appear if " | ||
+ | |||
+ | |||
+ | ---- | ||
+ | |||
+ | ==== RDA Customization ==== | ||
+ | |||
+ | If you do not agree with the decisions about the suitability of terms in various MARC headings fields, create your own " | ||
+ | |||
+ | * 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 ' | ||
+ | |||
+ | {{: | ||
+ | | ||
+ | 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((But for best results, to disable validation completely, uncheck all of the MARC Tag checkboxes on the main RDA options page)). | ||
+ | |||
+ | When you are adding or editing relationship designator terms, or validating the work done by others, the option ' | ||
+ | * 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 ' | ||
+ | * a record containing tag 100 subfield $e with the term ' | ||
+ | * when editing tag 100 subfield $e, and you press <F7>, only those terms that are checked in the selected ' | ||
+ | |||
+ | __**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 [[244: | ||
+ | |||
+ | 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 ' | ||
+ | |||
+ | The ' | ||
+ | |||
+ | 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. | ||
+ | |||
+ | |||
+ | ---- | ||
+ | |||
+ | ==== 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: ' | ||
+ | |||
+ | 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 ' | ||
+ | |||
+ | 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 ' | ||
+ | USEPCCWORKAROUND | ||
+ | There is one for validation, and one for editing. To disregard the PCC shortcut, set them both to ' | ||
+ | |||
+ | |||
+ | ---- | ||
+ | |||
+ | ==== Local Terms ==== | ||
+ | |||
+ | In RDA, the relationship designators listed in Appendix I and Appendix J are considered ' | ||
+ | |||
+ | //"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 ' | ||
+ | |||
+ | The caption ' | ||
+ | |||
+ | {{: | ||
+ | \\ | ||
+ | |||
+ | 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, ' | ||
+ | | ||
+ | The local filename is also listed in the status bar of the 'Edit Local terms' form ((where in fact, clicking on the status bar will open Explorer into the appropriate folder)) | ||
+ | | ||
+ | |||
+ | ===== Cataloging checks and Validation ===== | ||
+ | |||
+ | When MARC Report checks the relationship designators present in the MARC fields and subfields listed in the table [[244: | ||
+ | |||
+ | The brief message will state, for example: | ||
+ | |||
+ | < | ||
+ | |||
+ | The decision to use ' | ||
+ | < | ||
+ | $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 ' | ||
+ | |||
+ | 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-- | ||
+ | |||
+ | < | ||
+ | |||
+ | --followed by the explanatory note: | ||
+ | |||
+ | < | ||
+ | relationships between the resource and another work, expression, manifestation, | ||
+ | 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: | ||
+ | |||
+ | < | ||
+ | |||
+ | < | ||
+ | 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. | ||
+ | </ | ||
+ | |||
+ | ===== Language support ===== | ||
+ | |||
+ | 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, | ||
+ | [[http:// | ||
+ | |||
+ | __VALIDATION__ | ||
+ | |||
+ | Access the "RDA Language Support" | ||
+ | click the " | ||
+ | |||
+ | {{: | ||
+ | |||
+ | 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 ' | ||
+ | |||
+ | |||
+ | __HOW IT WORKS__ | ||
+ | |||
+ | Validation is tied to the ' | ||
+ | |||
+ | Thus, if the language of cataloging is ' | ||
+ | |||
+ | However, if the language of cataloging is ' | ||
+ | |||
+ | 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, ' | ||
+ | |||
+ | 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' | ||
+ | 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 ' | ||
+ | |||
+ | __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, | ||
+ | |||
+ | 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/ | ||
+ | |||
+ | |||
+ | __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 ' | ||
+ | |||
+ | 3. Decisions made using the Appendix I and Appendix J editors apply to all languages. | ||
+ | |||
+ | |||