Print

Print


I should also note that AFAIK nothing (with one exception [1]) is being done with indicators in that BF code. Indicators are important [2] and can even change the meaning of a field, as in the 100 where:

0 - Forename
1 - Surname
3 - Family name

without the indicators there is no way to know that this is a family name, not the name of a person[3]:

100 3#$aFarquhar family.

Again, presumably this table may not cover everything that is done with the MARC data by the program, but leaving off an analysis of the indicators seems unwise.

kc
[1] https://github.com/zepheira/pybibframe/blob/master/lib/reader/marcpatterns.py#L139
[2] Partial analysis of indicators: http://futurelib.pbworks.com/w/page/44421482/indicators, with a section on those that change the meaning of the field.
[3] A better data design would have been to give families their own tag, but this is a good example of where MARC doesn't follow best practices for data, and another reason to not carry forward MARC practices. The use of indicators is a mess of different purposes... well, I could go on. Just read [2] (which is probably not complete)


On 4/22/15 4:40 PM, Karen Coyle wrote:
[log in to unmask]" type="cite">Well, in the famed "this is not code" Zepheira python module with the MARC-to-BF mapping[1], there is no listing for 006, 007 or 008.

kc
[1] https://github.com/zepheira/pybibframe/blob/master/lib/reader/marcpatterns.py

On 4/22/15 2:18 PM, Tim Thompson wrote:
All,

I'm currently working on a pilot project to describe a collection of unprocessed serials using BIBFRAME, and I'm wondering whether anyone who has tested or worked on the current vocabulary has focused on how it represents serials, specifically.

I'm finding that BF seems to preserve the stringy data from MARC (although sometimes with a loss of semantics--for example, just a general bf:note for MARC's 515 field[1]) while ignoring some of the structured data in the fixed fields[2][3].

For serials, the 008 field[4] lets you be pretty specific about things like Publication Status, Frequency, Regularity, Type of Continuing Resource, etc., with coded values for each. I'm not a serials cataloger, but this kind of data seems worth recording/preserving, doesn't it?

Tim

[1] http://www.loc.gov/marc/bibliographic/bd515.html
[2] Sample MARC record: http://bibframe.org/resources/ftB1429734330/marcxml.xml
[3] Converted to BF: http://bibframe.org/resources/ftB1429734330/bibframe.rdf
[4] http://www.loc.gov/marc/bibliographic/bd008.html

--
Tim A. Thompson
Metadata Librarian (Spanish/Portuguese Specialty)
Princeton University Library


-- 
Karen Coyle
[log in to unmask] http://kcoyle.net
m: +1-510-435-8234
skype: kcoylenet/+1-510-984-3600