Question: How do you feel about the CONSER Standard Record?
Hi, several of you are having problems getting your postings to take. Sorry about that! I'll try to keep monitoring the UC CONSER Funnel list & make sure that everything you say gets posted also to this blog.
oh phooey-- I tried and got an incorrect password. Here's what I said:
I like it, although, it drives me bananas when you are given choices, e.g., 362 1 or 515. I didn't see any advantage of one over the other. (If there are any, which would you use when?) and if there aren't any, then why not just one place?
Also, 530 fields-- I can't remember the reason, but I know that Adolfo knows. There is something about the presence of the subfield 'i' in the 776 field that doesn't work well for us.
I tried posting to the blog but couldn't. Valerie, I think various issues with posting will need to get resolved before it will be viable as a discussion vehicle. Regardless, here is what I tried to post.
Below are the comments I sent Les last September during the initial commentary period. To these I add the comment I made at CONSER-at-Large about the 362. Right now, the CONSER standard record requires that it be an unformatted 362. I don't believe that should be a requirement. The issues raised about the 362, user confusion, is a display issue that should be addressed locally, not via this standard.
Becky, I don't recall the issue with the 530 vs 776 $i, I'll check through my various notes to see if I can find anything, do others recall the discussion.
Note, due to lack of time, I have not reviewed the comments below to see if they have been addressed in the current draft of the Standard.
The UCSD Libraries SCFG (Serials Cataloging Fun Group) reviewed the mandatory elements of the proposed access level record for serials presented in the Final Report, Appendix E : Access Level Record for Serials Cataloging Guideline, and Appendix N: MARC 21 recommendations. There was general consensus among SCFG members for almost all of the ideas presented by the Access Level Record for Serials Working Group. They came up with the following recommendations, suggestions, and questions.
1. Final Report and Appendix E: 006 required bytes: The final report, under the "Summary of omitted elements" (p. 5), indicates that the first 2 bytes of 006 are mandatory: "006 and 007: all but 1st 2 bytes." Appendix E indicates that only the1st byte for 006 is mandatory. Clarification needed: Which is correct?
2. Appendix E: Varying forms of title (246): ... "Use $f to indicate applicable date ranges for parallel titles, if these change over time." Recommendation: Do not use $f in the 246 field because it does not save time for the cataloger, nor do we consider it useful for the user.
3. Appendix E: Frequency (310, 321): "... It is not required to provide the former frequency in field 321. If using copy where the frequency in field 310 is no longer current and a field 321 is present, update field 310 to reflect the current frequency and replace existing field 321 information with 'Frequency varies' regardless of how many former frequencies there are." Clarification needed: Are the former frequencies being omitted because they are included in the 891 Publication Pattern Data? Recommendation: Former publication frequency notes (321) should be retained, regardless of number, and should also be a mandatory element. These notes are helpful for both serials catalogers and serials check-in staff for conflict resolution.
4. Appendix E: Dates of publication/designation (260 $c, 362): "It is not required to supply dates in 260 $ c. In all cases, supply dates of publication/designation in a note in an unformatted style (field 362, first indicator 1, “Began with…”) ... It is not required to use abbreviations when supplying this information; formulate the note as usual (i.e., keep the usual order and structure of the note) but instead of using prescribed abbreviations, transcribe what appears on the item (i.e., if a word is spelled out on the item, spell it out; if a word is abbreviated on the item, use the abbreviation as found.). Numbers may be transcribed as found or, if numbers are written out on issues, they may be recorded in Arabic numerals, whichever is easiest." Clarification needed: This new requirement will result in transcription inconsistencies throughout the catalog record. Need clarification for form of numerical designations on serials (e.g., "Vol." vs. "v." vs. "volume"). Example: 362 1_ Began with volume 1, issue 1 (January 2006). The Description based on (DBO) note still uses prescribed abbreviations and would read: 500 Description based on: Vol. 1, issue 1 (Jan. 2006). Recommendation: This requirement also begs the need for a prescription on how to record numerical designations for online serials. Numerical designations for online serials often differ greatly from the numerical designations on the print equivalents. The differences are arbitrary, subject to the whim of publishers and aggregators, and catalogers do not have prescriptive guidelines on how to record numerical designations for online serials. Consider submitting this issue to CONSER for evaluation and inclusion in CCM 31.
5. Appendix E: General notes (500): "Routinely provide only the following 500 notes, but provide them on all records: Source of title, issue on which the description is based (DBO); latest issue consulted (LIC), if applicable." Recommendation: Unless/until the proposal for repeating 260 fields is implemented, the 500 note for recording changes in place of publication/publisher should be mandatory. Notes about changes in place of publication/publisher are helpful for both serials catalogers and serials check-in staff for conflict resolution.
6. Appendix E: Language (008 35-37, 041 $a, 546): "Record the language of the publication in the fixed field (008 bytes 35-37). If the item’s main content is in more than one language, record all languages in $a’s of field 041 but do not code the other subfields. Record information about translations, different languages of summaries, tables of contents, or accompanying material only in an eye-readable 546 note." Clarification needed: The required elements for language are not clear. Our interpretation is as follows:
a. 008 bytes 35-37 (Lang) should be recorded for ALL publications.
b. If the item's main content is in more than one language, code only 008 bytes 35-37 (for main language) and 041 $a. Example: Publication is in English, French, and German, with English as the predominant language. Code as follows: Lang: eng, 041 $a eng $a fre $a ger c. For items that are translations or have different languages of summaries, tables of contents, or accompanying material, code only 008 bytes 35-37 (for main language) and use 546 note. Example 1: Publication translated into French from English. Code as follows: Lang: fre, 546 Translation of: __(English title)___.
Example 2: English language publication with summaries in Spanish. Code as follows: Lang: eng, 546 In English; summaries in Spanish. 7. Appendix E: Linking entry complexity note (580): "... It is not required to supply this information in a note. Use linking entries whenever possible." Recommendation: Can we do away with all 580s altogether and support the use of 7XX $i in their place? This would help resolve OPAC display issues with linking fields. (see related items #8 and #10 re: MARC 21 recommendation for increasing the number of 7XX linking field indicators which may become a MARBI proposal. If approved, the 7XX indicators would replace both 580 and 7XX $i)
8. Appendix E: Linking fields (76X 78X): "Follow CONSER and MARC guidelines for supplying all linking fields except: 773 (host item), 774 (constituent unit entry), and 787 (non-specific relationship), which are not required. It is not required to make added entries (730, 740) that duplicate the linking field access points. Use 776 $i rather than a 530 note, to describe any additional physical formats available." Clarification needed: Would it be useful to retain added entries (730, 740) for online versions with variant titles? e.g., Title A (print), Title B (online). In a library that uses the separate record approach, a user who is searching for the online version would not find it by doing a title search on Title A. Conversely, if a library owns only the online version, the user might search only for Title A since that is the title that is mostly likely going to appear in citation indexes, and would not find the resource since it is cataloged and indexed as Title B. Recommendation: With $i replacing the 530 additional physical format note, consider doing away with 580 notes altogether and extend the use of $i in 7XX linking fields to serve the same purpose. (see related items #7 and #10 re: MARC 21 recommendation for increasing the number of 7XX linking field indicators which may become a MARBI proposal. If approved, the 7XX indicators would replace both 580 and 7XX $i)
9. Appendix E: URLs, URIs (856): "Remote access electronic resources generally have a URI associated with the resource. CONSER records should contain generally-accessible URIs that point to the publisher’s version of the resource or to a version in a trusted archive. Local URIs or password-protected URIs should not be recorded in the national level record." Recommendation: Specifiy that only $u is required in the 856 field. Recommend the deletion of all 856 $z information from CONSER records.
10. Appendix N: Recommendation #1: "Increase the number of 7XX linking field indicators to make a greater range of note displays possible and avoid the need for catalogers to spend time writing notes for field 580 (complex relationship notes). Specifically, change the 780/785 indicators to describe the specific relationship in mergers and splits (as was done in the former “ISSN MARC” used by the ISSN Network until the Network began using MARC 21)." Recommendation: Approval of this MARC 21 recommendation would simplify the linking field requirements for the Access Level Record for Serials and solve OPAC display issues for linking fields and 580s. (see related items #7 and #8)
Hi, I think Becky's comment re: 530 vs 776 $i has something to do with our OPAC display issues. Currently the 776 doesn't display to the public. Does that sound right?
Regarding Adolfo's question about whether UCSD's comments from Sept. 2006 had been addressed in the draft for the CONSER Standard Record, I am happy to report that most of the issues we brought up have been clarified and/or resolved. The only outstanding issues (that I can see) from that original list are:
1. 321 is still "not required" though UCSD felt it should be "mandatory" unless the info is duplicated in the 891 Publication Pattern Data.
2. 500 change in place of publication/publisher notes are "not required" but UCSD felt it should be "mandatory."
3. What is the status of the MARC 21 recommendation (Appendix N of the original Access Level Record for Serials draft) to "increase the number of 7XX linking field indicators to make a greater range of note displays possible"? Is this now a MARBI proposal? This was asked in the context of resolving OPAC display issues for linking fields and getting rid of the 7XX $i and 580.
I might think of something else later but upon my own initial review of the new CONSER Standard Record, I had the following comments and questions:
RE: General Principles "Authority records in the Library of Congress/NACO Authority File (LC/NAF) are required for all headings on CONSER standard records."
Question: If a heading being used on a CONSER standard record is not in LCNAF or is in the process of being established, should we code the record as a minimal level record? Or not add the heading?
RE: Data Elements
008 byte SrTp: When creating original records, the default code for SrTp is blank which applies to annuals and yearbooks. The sample records in the appendices suggest that coding the SrTp is mandatory?
010/042: Since the 010 is a mandatory element for the CONSER standard record/new record creation, how do non-full CONSER members add the 010 LCCN and 042?
050/090: The call number fields such as 050/090 were not included on the data elements list. However, the sample records in the appendices suggest that the 050 is a mandatory element. Is the 050/090 mandatory?
130: Re: Distinguishing uniform titles for resolving conflicts. I already have a difficult time trying to locate the "correct" record for title with identical titles (ones that don't fall into the 2 exceptions for the CONSER standard record) so I can't imagine having to do that without the benefit of distinguishing uniform titles. However, as mentioned in previous documentation, the "non-mandatory" elements in the access level/CONSER standard models can still be added to the record at the discretion of the cataloger. I would imagine that this one will be added so frequently that it may as well become a mandatory element.
362: I was very interested to see the mandated use of an *unformatted* 362. I wondered whether part of the impetus for this was to make allowances for using electronic (or other) surrogates to supply this information in the future?
856 $3: The information contained in the $3 can be volatile and during the normal course of cataloging, we don’t add it to the master record. Could you give an example of when the $3 would be “mandatory, if applicable”? I thought of possible scenarios where the electronic content of a title is split onto 2 websites. However, even then, the coverage can be dynamic. Like the $z, I thought that the $3 would be "not required."
3 comments:
oh phooey-- I tried and got an incorrect password. Here's what I said:
I like it, although, it drives me bananas when you are given choices, e.g., 362 1 or 515. I didn't see any advantage of one over the other. (If there are any, which would you use when?) and if there aren't any, then why not just one place?
Also, 530 fields-- I can't remember the reason, but I know that Adolfo knows. There is something about the presence of the subfield 'i' in the 776 field that doesn't work well for us.
becky
All,
I tried posting to the blog but couldn't. Valerie, I think various issues with posting will need to get resolved before it will be viable as a discussion vehicle. Regardless, here is what I tried to post.
Below are the comments I sent Les last September during the initial commentary period. To these I add the comment I made at CONSER-at-Large about the 362. Right now, the CONSER standard record requires that it be an unformatted 362. I don't believe that should be a requirement. The issues raised about the 362, user confusion, is a display issue that should be addressed locally, not via this standard.
Becky, I don't recall the issue with the 530 vs 776 $i, I'll check through my various notes to see if I can find anything, do others recall the discussion.
Note, due to lack of time, I have not reviewed the comments below to see if they have been addressed in the current draft of the Standard.
Adolfo
***************************************************************************************************************************************
The UCSD Libraries SCFG (Serials Cataloging Fun Group) reviewed the mandatory elements of the proposed access level record for serials presented in the Final Report, Appendix E : Access Level Record for Serials Cataloging Guideline, and Appendix N: MARC 21 recommendations. There was general consensus among SCFG members for almost all of the ideas presented by the Access Level Record for Serials Working Group. They came up with the following recommendations, suggestions, and questions.
1. Final Report and Appendix E: 006 required bytes: The final report, under the "Summary of omitted elements" (p. 5), indicates that the first 2 bytes of 006 are mandatory: "006 and 007: all but 1st 2 bytes." Appendix E indicates that only the1st byte for 006 is mandatory.
Clarification needed: Which is correct?
2. Appendix E: Varying forms of title (246): ... "Use $f to indicate applicable date ranges for parallel titles, if these change over time."
Recommendation: Do not use $f in the 246 field because it does not save time for the cataloger, nor do we consider it useful for the user.
3. Appendix E: Frequency (310, 321): "... It is not required to provide the former frequency in field 321. If using copy where the frequency in field 310 is no longer current and a field 321 is present, update field 310 to reflect the current frequency and replace existing field 321 information with 'Frequency varies' regardless of how many former frequencies there are."
Clarification needed: Are the former frequencies being omitted because they are included in the 891 Publication Pattern Data?
Recommendation: Former publication frequency notes (321) should be retained, regardless of number, and should also be a mandatory element. These notes are helpful for both serials catalogers and serials check-in staff for conflict resolution.
4. Appendix E: Dates of publication/designation (260 $c, 362): "It is not required to supply dates in 260 $ c. In all cases, supply dates of publication/designation in a note in an unformatted style (field 362, first indicator 1, “Began with…”) ... It is not required to use abbreviations when supplying this information; formulate the note as usual (i.e., keep the usual order and structure of the note) but instead of using prescribed abbreviations, transcribe what appears on the item (i.e., if a word is spelled out on the item, spell it out; if a word is abbreviated on the item, use the abbreviation as found.). Numbers may be transcribed as found or, if numbers are written out on issues, they may be recorded in Arabic numerals, whichever is easiest."
Clarification needed: This new requirement will result in transcription inconsistencies throughout the catalog record. Need clarification for form of numerical designations on serials (e.g., "Vol." vs. "v." vs. "volume"). Example: 362 1_ Began with volume 1, issue 1 (January 2006). The Description based on (DBO) note still uses prescribed abbreviations and would read: 500 Description based on: Vol. 1, issue 1 (Jan. 2006).
Recommendation: This requirement also begs the need for a prescription on how to record numerical designations for online serials. Numerical designations for online serials often differ greatly from the numerical designations on the print equivalents. The differences are arbitrary, subject to the whim of publishers and aggregators, and catalogers do not have prescriptive guidelines on how to record numerical designations for online serials. Consider submitting this issue to CONSER for evaluation and inclusion in CCM 31.
5. Appendix E: General notes (500): "Routinely provide only the following 500 notes, but provide them on all records: Source of title, issue on which the description is based (DBO); latest issue consulted (LIC), if applicable."
Recommendation: Unless/until the proposal for repeating 260 fields is implemented, the 500 note for recording changes in place of publication/publisher should be mandatory. Notes about changes in place of publication/publisher are helpful for both serials catalogers and serials check-in staff for conflict resolution.
6. Appendix E: Language (008 35-37, 041 $a, 546): "Record the language of the publication in the fixed field (008 bytes 35-37). If the item’s main content is in more than one language, record all languages in $a’s of field 041 but do not code the other subfields. Record information about translations, different languages of summaries, tables of contents, or accompanying material only in an eye-readable 546 note."
Clarification needed: The required elements for language are not clear. Our interpretation is as follows:
a. 008 bytes 35-37 (Lang) should be recorded for ALL publications.
b. If the item's main content is in more than one language, code only 008 bytes 35-37 (for main language) and 041 $a.
Example: Publication is in English, French, and German, with English as the predominant language.
Code as follows: Lang: eng, 041 $a eng $a fre $a ger
c. For items that are translations or have different languages of summaries, tables of contents, or accompanying material, code only 008 bytes 35-37 (for main language) and use 546 note.
Example 1: Publication translated into French from English.
Code as follows: Lang: fre, 546 Translation of: __(English title)___.
Example 2: English language publication with summaries in Spanish.
Code as follows: Lang: eng, 546 In English; summaries in Spanish.
7. Appendix E: Linking entry complexity note (580): "... It is not required to supply this information in a note. Use linking entries whenever possible."
Recommendation: Can we do away with all 580s altogether and support the use of 7XX $i in their place? This would help resolve OPAC display issues with linking fields. (see related items #8 and #10 re: MARC 21 recommendation for increasing the number of 7XX linking field indicators which may become a MARBI proposal. If approved, the 7XX indicators would replace both 580 and 7XX $i)
8. Appendix E: Linking fields (76X 78X): "Follow CONSER and MARC guidelines for supplying all linking fields except: 773 (host item), 774 (constituent unit entry), and 787 (non-specific relationship), which are not required. It is not required to make added entries (730, 740) that duplicate the linking field access points. Use 776 $i rather than a 530 note, to describe any additional physical formats available."
Clarification needed: Would it be useful to retain added entries (730, 740) for online versions with variant titles? e.g., Title A (print), Title B (online). In a library that uses the separate record approach, a user who is searching for the online version would not find it by doing a title search on Title A. Conversely, if a library owns only the online version, the user might search only for Title A since that is the title that is mostly likely going to appear in citation indexes, and would not find the resource since it is cataloged and indexed as Title B.
Recommendation: With $i replacing the 530 additional physical format note, consider doing away with 580 notes altogether and extend the use of $i in 7XX linking fields to serve the same purpose. (see related items #7 and #10 re: MARC 21 recommendation for increasing the number of 7XX linking field indicators which may become a MARBI proposal. If approved, the 7XX indicators would replace both 580 and 7XX $i)
9. Appendix E: URLs, URIs (856): "Remote access electronic resources generally have a URI associated with the resource. CONSER records should contain generally-accessible URIs that point to the publisher’s version of the resource or to a version in a trusted archive. Local URIs or password-protected URIs should not be recorded in the national level record."
Recommendation: Specifiy that only $u is required in the 856 field. Recommend the deletion of all 856 $z information from CONSER records.
10. Appendix N: Recommendation #1: "Increase the number of 7XX linking field indicators to make a greater range of note displays possible and avoid the need for catalogers to spend time writing notes for field 580 (complex relationship notes). Specifically, change the 780/785 indicators to describe the specific relationship in mergers and splits (as was done in the former “ISSN MARC” used by the ISSN Network until the Network began using MARC 21)."
Recommendation: Approval of this MARC 21 recommendation would simplify the linking field requirements for the Access Level Record for Serials and solve OPAC display issues for linking fields and 580s. (see related items #7 and #8)
Hi,
I think Becky's comment re: 530 vs 776 $i has something to do with our OPAC display issues. Currently the 776 doesn't display to the public. Does that sound right?
Regarding Adolfo's question about whether UCSD's comments from Sept. 2006 had been addressed in the draft for the CONSER Standard Record, I am happy to report that most of the issues we brought up have been clarified and/or resolved. The only outstanding issues (that I can see) from that original list are:
1. 321 is still "not required" though UCSD felt it should be "mandatory" unless the info is duplicated in the 891 Publication Pattern Data.
2. 500 change in place of publication/publisher notes are "not required" but UCSD felt it should be "mandatory."
3. What is the status of the MARC 21 recommendation (Appendix N of the original Access Level Record for Serials draft) to "increase the number of 7XX linking field indicators to make a greater range of note displays possible"? Is this now a MARBI proposal? This was asked in the context of resolving OPAC display issues for linking fields and getting rid of the 7XX $i and 580.
I might think of something else later but upon my own initial review of the new CONSER Standard Record, I had the following comments and questions:
RE: General Principles
"Authority records in the Library of Congress/NACO Authority File (LC/NAF) are required for all headings on CONSER standard records."
Question: If a heading being used on a CONSER standard record is not in LCNAF or is in the process of being established, should we code the record as a minimal level record? Or not add the heading?
RE: Data Elements
008 byte SrTp: When creating original records, the default code for SrTp is blank which applies to annuals and yearbooks. The sample records in the appendices suggest that coding the SrTp is mandatory?
010/042: Since the 010 is a mandatory element for the CONSER standard record/new record creation, how do non-full CONSER members add the 010 LCCN and 042?
050/090: The call number fields such as 050/090 were not included on the data elements list. However, the sample records in the appendices suggest that the 050 is a mandatory element. Is the 050/090 mandatory?
130: Re: Distinguishing uniform titles for resolving conflicts. I already have a difficult time trying to locate the "correct" record for title with identical titles (ones that don't fall into the 2 exceptions for the CONSER standard record) so I can't imagine having to do that without the benefit of distinguishing uniform titles. However, as mentioned in previous documentation, the "non-mandatory" elements in the access level/CONSER standard models can still be added to the record at the discretion of the cataloger. I would imagine that this one will be added so frequently that it may as well become a mandatory element.
362: I was very interested to see the mandated use of an *unformatted* 362. I wondered whether part of the impetus for this was to make allowances for using electronic (or other) surrogates to supply this information in the future?
856 $3: The information contained in the $3 can be volatile and during the normal course of cataloging, we don’t add it to the master record. Could you give an example of when the $3 would be “mandatory, if applicable”? I thought of possible scenarios where the electronic content of a title is split onto 2 websites. However, even then, the coverage can be dynamic. Like the $z, I thought that the $3 would be "not required."
Post a Comment