add support for dtst date types r, b, u (008/06) in BF #112
Description
We narrowed down the ways this byte is supported or not supported by BIBFRAME. There's two categories of this issue. One is something that is lossy where there's no support for the specific dtst code in BIBFRAME. The 2nd one is where the conversion specifications have an issue, those we'll document in the respective github repositories & I'll come back and add a link.
I tested these by converting sample records to BF using m2bf 2.3, converting the BF to marc using bibframe2marc 2.3.
I also tested converting the cbd.rdf serialization from id to marc.
Codes
r - Reprint/reissue date and original date. Enter reprint/reissue date in Date 1 and date of original in Date 2.
Example:
r20191912
changes to
s2019||||
Test records:
- OCN 1347435106
- LCCN 2021431038
- ID 22330346
Summary:
The way the specs and the conversions are written Date 2 is lost and the dtst is changed from r to s.
r is specified in marc2bibframe2 to ignore the Date2 which in our opinion is the case because there's no place to put this date, we request you fix this. There are approximately 800,000 LCCNs with this code.
b - No dates given; B.C. date involved. Use blanks in Dates if one or more of the dates are B.C.E. dates. Enter the appropriate code and B.C.E. date or dates in field 046.
Example:
b
changes to
|||||||||
In addition, there's no 046 support in BF:
<datafield ind1=" " ind2=" " tag="046"> <subfield code="a">q</subfield> <subfield code="b">2200</subfield> <subfield code="d">1900</subfield> </datafield>
Test records:
- LCCN 2020741371
- ID 22011442
Summary
b is specified in marc2bibframe2 to be ignored as well as almost all of the 046 that is required with this code, we're requesting that you add support for b and all of the 046 field.
u - Continuing resource status unknown. No clear indication exists that publication of the continuing resource has ceased.
Example:
u197uuuuu
is changed to
m197uuuuu
Test records:
- LCCN 2019354658
- OCN 233638732
- ID 21316072
Summary
u has support in the specifications but it has the exact same specifications as m, which is first so it fires first in m2bf. I'm adding this here since it seems more ontological than conversion related (aka no place for the code).