DACS practice would be to use 245 $f and $g and omit 264, so my guess agrees with yours, that the duplication is to try to cover both rda and dacs bases. I'd be interested in other opinions, but DACS and RDA are different enough that I don't think they should be combined in one record. On Wed, Mar 29, 2017 at 4:23 PM, Casey Mullin <[log in to unmask]> wrote: > [excuse cross-posting] > > > > Dear CW, > > > > I note that dates of archival collections are covered by the RDA element > 2.7.6.7, which maps to 264 _0 $c. There is an optional addition for the > bulk dates, in addition to the inclusive dates. > > > > My question is: is there provision in RDA for *also* (or instead) giving > these date ranges in 245 $f and $g? Example: > > > > 245 ... papers, ǂf 1861-2015 ǂg (bulk 1923-1995). > > 264 _0ǂc 1861-2015, bulk 1923-1995. > > > > I note that 245 $f and $g are not included in the MARC to RDA > Bibliographic mapping in the Toolkit. So my initial answer to my own > question would be no. > > > > Some cursory searching in OCLC for archival collection records coded RDA > reveals a diversity in practice. Sometimes 245 $f (and $g if applicable) > are given, but 264 is not. Sometimes both. Sometimes the inclusive dates > are given in both fields, but the bulk dates in 245 only. Etc. Does such a > redundancy suggest a practice "borrowed" from DACS (which I am not versed > in); some records I found are coded *both* dacs and rda in 040. > > > > I'm OK with the 245/264 redundancy for our local purposes, but I'd like to > ensure our records are RDA-compliant. > > > > Thanks, > > Casey > > ________________________________ > > Casey A. Mullin > Head of Cataloging and Metadata Services > Western Washington University > > > Chair, Music OCLC Users Group > > > > 360-650-7458 <(360)%20650-7458> > > [log in to unmask] > > > -- Christine DeZelar-Tiedman Metadata and Emerging Technologies Librarian University of Minnesota Libraries 160 Wilson Library (612) 625-0381 PH 309 19th Ave. S. (612) 625-3428 FAX Minneapolis, MN 55455 [log in to unmask]