245 title statement

[CECSpecialistI]

https://github.com/uwlib-cams/MARC2RDA/blob/main/Working%20Documents/2XX.csv

[CECSpecialistI]

Began in-meeting group review on 2022-08-10

[lake44me]

FWIW: I tracked what I was looking for, the latest version of DACS (Describing Archives: A Content Standard, maintained by Society of American Archivists). Its crosswalks appendix, mapping among other things, DACS elements to MARC21. It's now hosted in GitHub: .

DACS	EAD 2002	EAD3 (draft)	MARC
2.4 Date	<unitdate>	<unitdate> or <unitdatestructured>	264 _0 $c

No mapping to 245 $f or $g was found.

This is not to say that there aren't guidelines or practices for MARC mapping of archive descriptive elements elsewhere (perhaps with a less geographically limited focus) that govern where or where not to put the date ranges defined for those fields in MARC.

The DACs section 2.4 cited does appear to say that you would always provide inclusive dates even if you also want to provide bulk dates. Possibly the availability of two distinct subfields in 245 would be the advantage of using those subfields over 264 $c . It may also be a consideration for whether we can somehow make a distinction when we have both, and are mapping to RDA entities etc.

Archivists who create these records could give better perspective than I can - I just go by what I've seen and limited exposure in the past. It may be that an older practice was to use the 245 subfields, and that changed at some point to using the 264. Here's a link to one of our older records for an archive . If you click on "Staff view" you can see in the MARC that the 245 has $f with a date range and that neither 260 nor 264 is present in the record. Our newer records seem to be using the 264 $c . OCLC BFAS for 264 even has "Archival instructions" to "Enter the date of production of an archival collection as a year or range of years. If you are cataloging a single manuscript, you may include the month and day in that order following the year, if appropriate."

Since the presence of $f and (or) $g indicates that the manifestation is of a collection work (and thus an aggregating work), it seems to me that "has date of manifestation" doesn't feel appropriate. The date(s) relate to the included members that are aggregated, not to the collection manifestation itself (which may have been "created" or collected far later than the creation dates of its contents). But for mapping, it may not be worthwhile to try to pursue an alternative relation for 245 $f and/or $g if the same dates are now to be entered in 264, which we could not easily distinguish from other dates of creation.

Would the possibility of having both $g and $f mapped need to be accounted for? Would having two "has date of manifestation" statements for one manifestation violate anything?

[lake44me]

Uh oh Crystal - it looks like I accidentally clicked on something and closed the issue. Can we reopen it?

[lake44me]

I think I fixed that. Sorry.

[CECSpecialistI]

No worries! From: Laura Akerman ***@***.***> Sent: Wednesday, August 17, 2022 2:30 PM To: uwlib-cams/MARC2RDA ***@***.***> Cc: Crystal E. Clements ***@***.***>; Assign ***@***.***> Subject: Re: [uwlib-cams/MARC2RDA] 245 title statement (Issue #115) I think I fixed that. Sorry. — Reply to this email directly, view it on GitHub<#115 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AKJWNZNYZGHUEICOLDDI4MLVZVKVJANCNFSM5IXKNZWA>. You are receiving this because you were assigned.Message ID: ***@***.******@***.***>>

[AdamSchiff]

F245 10 $a [New paintings by Franz Kline : $b opening ... December 4 to December 30, 1961 : at Sidney Janis 15 East 57 N Y].
Is this a correct way to add brackets in the field?

The bracketing here reflects how we used to bracket entire fields when everything has been supplied. Under current ISBD provisions, each subfield would be bracketed:

245 10 $a [New paintings by Franz Kline] : $b [opening ... December 4 to December 30, 1961 : at Sidney Janis 15 East 57 N Y].

[AdamSchiff]

F245 10 $a [Rhan o waith Mr. Rees Prichard ...] : $b [= Some part of the works of Mr. Rees Prichard.]

The record with our holdings on it in OCLC looks like this:

[Rhan o waith Mr. Rees Prichard ... ǂb = Some part of the works of Mr. Rees Prichard.].

The equals sign is not in the correct place. I've changed the record to:

[Rhan o waith Mr. Rees Prichard ...] = ǂb [Some part of the works of Mr. Rees Prichard.].

[AdamSchiff]

The record in OCLC for the 3rd example looks like this:

245 00 Shakespeare lecture series. ǂp Hamlet : ǂb structure, speeches, and staging : [acts III-IV] / ǂc produced by Bill Wisneski ; directed by Bill Wisneski and Chia Longtree.

We do not have our holdings on this record in OCLC, which tells me it comes from the ExLibris CKB. It's in the community knowledge base of records for a video package that we subscribe to. The whole thing is badly cataloged, but we can't do much because the record comes from a vendor and even fixing it in OCLC won't affect what users see in the catalog because it isn't in our institution zone of Alma. We could possibly fix it in the community zone, but we don't have the staffing to correct all the mistakes in vendor-supplied records (no one does). "Shakespeare lecture series" shouldn't even be in the 245, it is series information. In fact in the OCLC record there is also a 490 0 Shakespeare lecture series. The 245 should really be something like:
245 00 Hamlet : $b structure, speeches, and staging : [acts III-IV]
or maybe
245 00 Hamlet. $p [Acts III-IV] : $b structure, speeches, and staging

I have no idea where the parallel Chinese is coming from. It isn't in the OCLC record that matches most closely. And it isn't parallel in any way to the other 245 field. This is a crap record.

[AdamSchiff]

F245 14 $a The Letters of William Cullen Bryant $b Volume VI, 1872–1878 / $n Volume VI, $p 1872-1878 / $c edited by William Cullen Bryant II and Thomas G. Voss. $p 1872-1878 / $n Volume VI,

I think this is another case of very bad vendor record in the ExLibris CKB. The record in OCLC that we have our holdings on does not look like this. It still had errors, but not as bad as this. I have corrected the OCLC record:

245 14 The letters of William Cullen Bryant. ǂn Volume VI, ǂp 1872-1878 / ǂc edited by William Cullen Bryant II and Thomas G. Voss.

but this correction will not fix the crap that is in Alma community knowledge base, unfortunately.

[GordonDunsire]

@cspayne:

1. Where two or more mapped subfields are surrounded by brackets, a note on manifestation should be added for each mapped RDA element and value. For example, subfield $b and $c values enclosed in a single pair of brackets should generate a note about the other title information value and the statement of responsibility relating to title proper value. The brackets are intended for display of an ISBD layout to inform the user of 'not from the chief source of information' data provenance.

2. Yes, I think so. The practice of adding square brackets, etc. goes way back, and is deeply engrained in cataloguer practice, irrespective of other ISBD punctuation.

[cspayne]

The code for 245 has been updated based on our decisions. Please feel free to check out the 245 output for review files to review these changes.

[lake44me]

@cspayne I'm checking on the status of this issue for 245 relative to reproduction conditions. I see that some lines in the spreadsheet were changed to "1st pass", so status is no longer "Done".

I see that reprod. conditions were added to some lines but not others. Specifically, the first 2 lines that still say "Done" - one mapping just $a (with no conditions), one mapping $a when $n, p, s are present. Then the next line. first pass, maps all subfields where condition "NOT (a)" is there. Are these lines still part of the mapping, or superseded by following lines? Should the reproduction condition and instructions (map to both reproduction and original manifestation) be applied to these? I think the status should be moved to "Review in progress" and a label for Code recheck maybe applied, but will leave that to you.

Re the test output - very interesting... I know a huge amount of work and discussion has gone into this tag, and hope we're near the completion. My first impression was "aren't we missing something...?" - I see it looks like the parts are all there, just not in the order of the MARC tag. I still feel like having a mapping to something that includes $a and $b in a single string (keeping the colon in between if present) would be great, like maybe in a http://rdaregistry.info/Elements/m/P30293 "Manifestation title and responsibility statement" - but that's probably just me. Seeing titles and subtitles concatenated without punctuation between in our catalog drives me nuts, and there's no easy remedy. @CECSpecialistI Anyway, this might be worth reviewing at a group meeting.

@dchen077 I removed the Reproduction Condition from $h Medium (the "General Material Designation") The GMD if present would probably describe the reproduction. The intent for 245 conditional mapping is to provide a title for the Original Manifestation we created a URI for so as to identify it. The Title Proper would probably serve this purpose, but I left the other mappings to be duplicated (including $c statement of responsibility) as a possible help for future identification and reconciliation. I deliberated about $f inclusive dates and $g bulk dates - probably unlikely $g will be in a record for an archival collection that got reproduced... but $f might show up and it seems like a value that would apply to the original if so. So I left the conditions in.

[cspayne]

I see that reprod. conditions were added to some lines but not others. Specifically, the first 2 lines that still say "Done" - one mapping just $a (with no conditions), one mapping $a when $n, p, s are present. Then the next line. first pass, maps all subfields where condition "NOT (a)" is there. Are these lines still part of the mapping, or superseded by following lines? Should the reproduction condition and instructions (map to both reproduction and original manifestation) be applied to these? I think the status should be moved to "Review in progress" and a label for Code recheck maybe applied, but will leave that to you.

Hi @lake44me, I just changed the first two rows from 'done' to 'first pass' because we have been adjusting them as we review and discuss 245. I don't think they need reproduction conditions because they map to work properties. There are actually two rows with those conditions, one for the work property and one for the manifestation property. I believe Doreen has added reproduction conditions for the manifestation properties.

[lake44me]

Duh, work property, of course. Need better glasses for this stuff. Thanks.