标签： MARC

LC提供2500万书目记录免费批下载（附LC在Library.Link）

2017年5月，美国国会图书馆（LC）宣布免费提供2500万条书目记录批下载。时间段为1968-2014年，应该就是2014年前LC制作的所有MARC记录。很多年前LC的书目记录就可以通过Z39.50逐条获取，但批量数据以前是付费订购的。虽说“主要供研究与开发利用”（MARC Open-Access），但因为并未限制使用目的，估计很多书目服务商听到消息第一时间就去下载备用了。
根据LC网站的 MARC Distribution Services (data set) 网页上的FAQ说明，本次免费提供的数据截止到2013年12月，以后可能每年更新。订购数据则更及时，目前截止2015年12月底，同时提供每日、每周更新。
开放MARC数据的目的是希望书目数据得到原有目的之外的、更广泛的利用。LC采访与书目访问部主任Beacher Wiggins在报道中说：“为了更有效的信息分享、更方便可视化与其他不可预知的分析，我们希望社会科学家、数据分析师、开发者、统计学者及其他人在工作中使用数据，对大数据集做创新工作，强化新知识的学习与生成”。
via Fortune: The Library of Congress Just Made 25 Million Records Available for Free (2017-5-17)

——— Library.Link中的LC书目数据 ———
今天看到Library.Link中，对LC书目记录经关联数据转换后发布。LC宣布开放数据是2017-5-17，数据被载入Library.Link是2017-6-12，发布是2017-6-15，可谓反应迅速。不知道是不是最早的公开发布应用。
关于Library.Link，参见：2016 ALA年会BIBFRAME更新论坛（2016-8-27）

LOC.Library.Link
LC像其他加入Library.Link的图书馆一样，有一个主页。如果有帐号，可以看访问统计。
右栏是“资源”，即由MARC记录转化后的Bibfra.me类（共16个）及数量，字顺排列：
Agent 2338223
Collection 667912 （由相关题名字段转换而来？）
Concept 6546780
CopyrightEvent 564
Family 25860
Form 9336
Instance 12898932
Meeting 228118
Organization 1200225
Person 4891149
Place 634135
ProviderEvent 6005730
Series 958273
Temporal 8906
Topic 303503
Work 13649505

每次在新形态下看发布的书目数据，总不免看到一些原本埋没着不知道的原始数据错误，如以前看分面OPAC，现在看关联数据。选择“个人”随意浏览，本当为人名，但排序在前几页的都是非字母开头的（标点符号、数字），有些可能是非拉丁字母转化的字符问题，还有相当部分应该是原始数据有问题。
比如有个”16 juli 1993″，根据题名返回到LC目录查原记录，LCCN=94124897（https://lccn.loc.gov/94124897），果然有：
7001_ |a “16 juli 1993.”
本书1993年出版，可能把500误作700了。

接下来还有不少以冠词A起始的，很有意思，比如：A 1st class boy, A British officer, A Californian, A lady of this city …
比如：A lady of this city
LC目录中查到原记录LCCN=16009701（https://lccn.loc.gov/16009701）
245 04 $a The life of the beautiful and accomplished danseuse, Mademoiselle Fanny … $c … Selected and comp. by a lady of this city.
700 0# $a A lady of this city.
原来还有这样直接用题名页上称呼做个人名称检索点。

MARC21格式：非排序控制字符技术指南

西文编目中，对题名有首冠词的，做统一题名时通常跟随英美做法省略。当编目规则由AACR2变为RDA，统一题名变成规范题名/首选题名，还是继续省略首冠词的做法，直到德国提出欧洲是保留首冠词的。为体现国际化，RDA相应条款被修订，保留首冠词；为兼容英美原来的做法，省略首冠词作为交替规则保留，LC-PCC PS采用交替规则。问题似乎圆满解决，皆大欢喜。

最近Gene Fieg在RDA-L邮件组中提问，如果做规范检索点（AAP），题名首冠词到底是要还是不要？
[RDA-L] title : with or without initial article (2017-7-10)
答案肯定是跟着首选题名，但竟然引起热烈讨论，也真出乎意料。问题恐怕在于，同样用RDA，采用正文规则还是交替规则，AAP不一样。这也从侧面说明，注重形式一致的AAP已经没有多少意义了。

讨论中，Charles Croissant提到MARC21格式在2013年批准了关于不排序字符使用的规定
Re: [RDA-L] title : with or without initial article (2017-7-11)
他说是应德国编目界的要求，但在英语编目中并未采用。

看规则，基本上就是原来用不排档字符数(nonfiling character)，可以改用不排序控制符（花括号{}），两种方法取其一：
Guidelines for the Non-Sorting Control Character Technique (June 20, 2013)
以下取上述指南中几个规范检索点的例子，原来题名省略首冠词的，用此法可以保留：
100 1# $a Luther, Martin, $d 1483-1546. $t {Der }Grosse Katechismus
130 0# $a American men and women of science. $p {The }medical sciences.
240 10 $a {The }Pickwick papers.

在机器学习时代，无论是人为提供的不排档字符数还是不排序控制符，此类处理手法显得过于稚拙，暂且不提。忽然明白欧洲保留首冠词，看来并不要一同排序，似乎只是用来显示。而MARC21格式中，很多字段原就定义有指示符“不排档字符数”，本可以处理保留首冠词的情况——原来因为规定省略首冠词，指示符一律取值0，白白浪费了这些字段指示符。

MARC到BIBFRAME转换：并列比较工具

上月美国国会图书馆（LC）公布了BIBFRAME2.0词表更新、相关组件，其中包括MARC字段到BIBFRAME2.0的转换对照表（MARC 21 to BIBFRAME 2.0 Conversion Specifications）。近日，LC以提供了MARC到BIBFRAME转换的并列比较工具，可以直观浏览一条MARC记录转换为BIBFRAME记录后是什么样子的：

BIBFRAME Comparison Tool — Compare MARCXML to BIBFRAME2
提供2种查询记录的途径：书目记录ID（001字段）或LCCN控制号（010字段）
BIBFRAME2的序列化方式2种可选：Turtle 或 RDF/XML（默认前者）

该工具副标题“从MARCXML到BIBFRAME2”，但目前展示的是MARC编辑界面，并非MARCXML。这是由于实际转换工具是由MARCXML转为BIBFRAME的，即需要先经过早年的转换工具将MARC转换为MARCXML。选择显示MARC而非MARCXML，应该是由于对编目员来说，其可读性和简洁性上更高。

默认样例为BIB ID=5226/LCCN=82060878，非RDA记录。看BIBFRAME记录，大致区块为以下6大类：
1 作品 ，包含：
– 题名（首选题名）
– 管理元数据（头标/0XX部分）
– 分类号（050/082）
– 008部分代码
– 贡献（1XX/7XX，连接“施事者”）
– 连接“实例”
– 连接“主题”
2 实例 ，包含：
– 著录（2XX-5XX）
– 008部分代码
– 连接“馆藏”
– 连接“作品”
3 馆藏（050LC索书号）
4 主题（6XX）
5 施事者（1XX/7XX）
6 各类代码值，定义所属“类”，用于以上各类的属性取值，多为头标/0XX的代码。

样例中可以看到几处bflc: 命名空间（BIBFRAME的LC扩展）的使用，应该都是为转换处理而临时设置的：
编目级别（管理元数据）：bflc:encodingLevel a bflc:EncodingLevel ;【头标17，#=f/full】
贡献（作品）：bf:contribution a bflc:PrimaryContribution【主要责任者1XX】
题名（作品/实例）：bflc:titleSortKey “Snoopy on wheels /” ;【去不排序字符？含子字段末“/”】
施事者：
bflc:name00MarcKey “1001 $aFlanagan, Terry.” ;【含MARC子字段名】
bflc:name00MatchKey “Flanagan, Terry.” ;【不含子字段名的字符串】
bflc:primaryContributorName00MatchKey “Flanagan, Terry.” .【主要责任者1XX】

BIBFRAME2.0不以元素区分创作者、贡献者，所有责任者都是“贡献”contribution，再加上不同的“职能”role 。或许是在处理上还不能一步到位地提供具体的职能，LC扩展了表明主要责任（创作者）的类 bflc:PrimaryContribution 和3个属性 bflc:primaryContributorName00MatchKey，bflc:primaryContributorName10MatchKey，bflc:primaryContributorName11MatchKey（应该分别对应100/700、110/710、111/711）。为什么7XX？因为7XX也可能是创作者。