 |
 |
On 1/31/15 8:16 AM, [log in to unmask] wrote: > So, from my personal experience, I do not recommend to propose a > MARC-centered "serialization only" Bibframe dialect. It will not > improve Bibframe or ease the migration, it will just add a truncated > RDF without links, without URIs, with another migration path. +1. The "semantics" of MARC fields are not well-organized. Had MARC been treated to something like a relational-database analysis some decades ago, we wouldn't have a situation where things like dates of publication can be found in 3 or 4 different places in the record 008 date of publication 046 special coded dates (because there wasn't room in the 008 for expansion) 240 (sometimes) date of the expression 260 display form of date of publication Oftentimes it is the same date that appears in each of these places in the record. Nor would we have multiple ways to indicate the source of the data in the field: indicator value (e.g. 0 = LCSH) indicator value 7 + code in subfield $2 (The indicators alone are a can of worms. See: http://futurelib.pbworks.com/w/page/44421482/indicators) To my mind, the only way forward with our data is to deconstruct MARC into semantic units, and move forward with those semantics, separate from the MARC structure. And in case you are not aware of this, at this very moment new additions to MARC are being discussed at the ALA midwinter meeting in Chicago. That boggles my mind. kc -- Karen Coyle [log in to unmask] http://kcoyle.net m: +1-510-435-8234 skype: kcoylenet/+1-510-984-3600