Open pschreur opened 10 years ago
do you mean issue 26 https://github.com/lcnetdev/marc2bibframe/issues/26? Can you give an example marcxml? We're doing clean-string on $c which strips square brackets. I guess in the 26xs your data is less likely to be cleanable to an actual date than the 008 date, so we could just spit it out.
Sure, here's the record. The date is bracketed and it appears in brackets in the BibFrame conversion. Not related to #26.
MARCXML:
On 7/17/2014 10:10 AM, Nate Trail wrote:
do you mean issue 26 #26 https://github.com/lcnetdev/marc2bibframe/issues/26? Can you give an example marcxml? We're doing clean-string on $c which strips square brackets. I guess in the 26xs your data is less likely to be cleanable to an actual date than the 008 date, so we could just spit it out.
— Reply to this email directly or view it on GitHub https://github.com/lcnetdev/marc2bibframe/issues/85#issuecomment-49335602.
Philip E. Schreur Head, Metadata Department Stanford University 650-723-2454 650-725-1120 (fax)
I would also prefer to have brackets eliminated and replaced with a specific date tag(s) specifically identifying bracketed dates as not authoritative/implied/guesstimated. It's not clear to me that users really understand what the brackets mean when we use them, the brackets interfere with indexing/faceting by date, and brackets may not be used universally in all descriptive schemes to indicate the same thing.
Date-related properties are consistently defined as literals. This is good for transcription, where punctuation and words can be included as needed. It is not as good for machine manipulation. We think BF needs some parallel date-typed properties to support searching and facets.
Here is an example of two calendar systems in one subfield:
264 _1 |a [Bangkok] : |b Samnakphim Sārakhadī, |c 2554 [2011]
bf:providerDate can handle the string, but it is transcription. We also need a way to encode the dates.
Also, BF should make use of dates in fixed fields, retaining their date typing.
We earlier submitted an issue in which brackets were not being included in date fields such as the 264. We felt this data was important as an indication that the date came from some alternative source. We're now wondering if brackets themselves should be included in data which will be assumed to be numerical. Is there another way of encoding what the brackets imply without having to literally use them?