MARC Report 250: Program changes
The automatic dropdown lists in tags 336, 337, and 338 might become annoying in some editing tasks. So we've added a new sticky option to the Edit menu labeled Disable 336/337/338 auto dropdown. If this option is selected, one can click on these tags and immediately begin editing. To restore the automatic dropdowns, simply deselect this item under the Edit menu.
In a minor change to the Edit Session interface, the old kludge to reveal the MessageId of an error by right-clicking on the Notes panel has been removed. Right-clicking on the Notes now results in the standard Windows menu, so we can do 'Select All' and 'Copy' them to the clipboard. To reveal the MessageId of an error, right-click on the error message itself.
The format used by the file named
codelist.txt has been changed slightly in this version: there are now 4 columns instead of 3, and the data is UTF-8 encoded. If you have customized the
codelistLocal.txt file, note that it does not need to be updated to the new format (but it might be worthwhile reviewing the
customizing instructions here ).
We added a new option to the Files & Directories page labeled Select the last MARC file used on startup. If this is selected, then whenever you start the program, it will (try to) set the MARC source file to whatever file was last used by the program (providing it still exists, etc.). We have found this option to be a great time-saver, but it really depends on the type of work being done. By default, this option is not selected.
The option to add a Tag/Message filter to a batch mode run has been improved to support multiple strings in the filter. When multiple strings are used in a filter, they should be separated by a vertical bar '|'. A batch mode run using the filter in the following example will report only those messages that match any of the three partial message strings listed (The other usages of this filter have not changed–a list of comma-separated tags or message Ids):
needs matching 00|needs matching 33|value is not rda
After a series of conversations with those who know more than we do about … punctuation, we've amended the message in the cataloging check that scans for two pieces of ending punctuation in a field. So, for those who prefer to add a period at the end of a title even when it already ends in a piece of ending punctuation, the message about repeated ending punctuation has been modified to note that this practice is permitted by a certain policy statement.
This version adds a new cataloging check to the 336, 337 and 338 fields that crosschecks the concepts described in the subfield $a (Term) and subfield $b (Code) and produces an error message if they are not describing the same concept. This check requires that both $a and $b be present, and that the $2 contain one of the RDA terms (rdacontent, rdamedia, or rdacarrier). One
recommendation is that different concepts should be described in separate occurrences of the tag. This recommendation will reduce the amount of confusion that might occur when $0 and $1 begin to be added to these fields.
Not much new is happening in RDA these days, as we await the completion of the 3R project, but there are 6 new relationship designators in Appendix J, and all have been added to our support tables:
Back to top