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也可能是创作者。

[RDA记录样例] 按需印刷品:PCC的POD规定

RDA关于摹真和复制品的规则很简单:
RDA 1.11 摹真与复制:著录摹真和复制品时,在适当元素中记录与摹真或复制品有关的数据。适当记录与原始载体表现相关的任何数据为相关作品或相关载体表现。
也就是说,应当按摹真或复制品本身著录,所依据的原本只能作为相关资源。

尽管RDA 1.11没有交替规则,仍有三家设置了本地政策(美国LC-PCC、德语国家D-A-CH、加拿大LAC)。LC-PCC的政策分别对缩微、按需印刷复制品和影印件(Print on Demand (POD) Reproductions and Photocopies)作出了规定。本博文只论后者。
在LC-PCC PS 1.11“摹真与复制”中,PCC对POD采用的方法是“provider-neutral”(提供者中立),或者说不考虑提供者:同一原始载体表现的所有POD制品只做一条记录(比如图书A的影印本,和图书A数字化副本的HathiTrust的POD复制品)。

具体字段说明如下(* 为记录POD特征字段):
008/06:日期类型不使用 r 重印
008/07-10, 11-14:记录原印刷资源的日期
008/15-17:记录原印刷资源的出版地代码
* 008/23(图书) | 008/29(地图):记录单件形式(Form of item)为 r,表明是印刷复制品【MARC标准网站尚无此值】
* 020:如果商业POD服务提供者提供ISBN,记录在$a;原资源如果有ISBN,记录在$z;限定信息入$q。必要时重复020字段。
* 037:如果需要,记录商业POD服务提供者为采购来源。必要时重复037字段。
* 040:$e pn,代码表示提供者中立(provider neutral)【著录规则来源代码显示,此代码原为电子资源设置】。$e可重复,如果符合RDA标准,可同时做 $e rda
245-300:按原印刷资源提供所有载体表现元素如题名、版本说明、出版说明、资源数量等
* 33X:记录适用于复制品的内容类型、媒介类型和载体类型 ,无论采用什么编目规则(即AACR2记录也需提供)
* 533:创建单个复制附注,内容为:$a Print reproduction.
* 775/776 相关载体表现(可选):记录复制品与原件关系,使用775字段(物理格式相同)或776字段(物理格式不同,如PDF与打印件)。$i 使用关系说明语如:Reproduction of (manifestation): ,或者非结构化的其他关系信息如:Print version.

由上可知,PCC的规定也是按照复制品著录、原件作为相关资源著录在775/776字段,与RDA条款似不冲突。但是,此规定在生产出版发行制作说明上完全不考虑POD。由于按需印刷并不修改内容,今年印和明年印是一样的,所以这个规定是合理的,对于合作编目尤其如此。
如果同一原始资源,由不同POD服务提供者制作,该如何处理?从以上字段说明看,重复037及020字段即可。

说明:本规定所指的“按需印刷复制品”与“影印件”都是在提出要求后印制、与原件相同的复制品(包括文本材料、乐谱、地图),无论是内部制作还是向服务提供者订购。差别仅在于前者通常由数字文件打印,而后者通常由实物文献复印。
此法不适合一般的印刷出版、再版、重印、摹真复制等或者缩微复制(如国内较常见的授权影印书不在此列)。
特别注意:当不确定时,不采用此政策。(现在有些专门从事电子书打印的出版社,其出版物是否也应参照POD做,值得考虑)

另外,在LC-PCC PS 1.11“摹真与复制”的最后,也提供了非PCC的交替做法(应该是完全符合RDA条款的做法):基于复制品的著录
机构如愿意基于照相复印、缩微复制或POD复制本身进行著录(而非原件),可以这样做,但这种记录不应当在MARC字段042标记为pcc。同时,原始资源细节可放在MARC字段534。

MARC数据转换为RDF流程:芬兰国家图书馆实践

GitHub上芬兰国家图书馆的 bib-rdf-pineline ,包含各种脚本和配置,供转换MARC书目记录为RDF,对有意实施类似项目者当有不少参考价值。
芬兰国家图书馆的关联数据采用Schema.org,以BIBFRAME作为转换MARC格式的中间步骤。如果直接采用BIBFRAME,步骤当可简化,而汇集“作品”的部分必然会有所不同。
翻译repo中的README文件中的转换步骤备记:

1、ILS系统导出的全部MARC记录文件
2、分割为较小的批处理文件
3、使用unix工具(如grep和sed)除去MARC记录中本地特殊内容
4、使用Catmandu转换为MARCXML并强化MARC记录
5、运行LC的 marc2bibframe2 转换MARC为BIBFRAME的RDF
6、计算”作品“键(如:作者+题名组合),供后续合并相同创作作品的数据
7、转换BIBFRAME数据为Schema.org的RDF,N-Triples格式
8、按相同作品合并Schema.org数据
9、转换原始Schema.org数据为HDT格式,如此完整数据集可通过命令行用SPARQL查询
10、统一数据,如通过重写URI,把主题移到原始作品
11、转换统一后的数据为HDT
12、(待续)
13、获益!

查了下其中提到的另外两个陌生的名词:Catmandu、HDT,附后。

关于marc2bibframe2,参见:MARC到BIBFRAME 2.0转换工具:使用报告(2017-3-24)

——— Catmandu数据处理工具 ———
Catmandu:命令行工具,从数字图书馆、研究服务或任何其他开放数据集,访问和转换数据 。
性能:
– 通过多种协议下载数据,包括:OAI-PMH, SRU, SPARQL 和 Linked Data Fragments
– 转换格式,如:MARC, MODS, Dublin Core 等等
– 生成 RDF,说语义网的语言
– 索引数据到数据库如:Solr, Elasticsearch 和 MongoDB
– 使用简单的 Fix 语言,转换元数据为任何格式

——— HDT格式 ———
HDT (Header, Dictionary, Triples) 头标、词典、三元组
RDF的紧凑数据结构和二进制序列化格式,压缩大数据集以节省空间,同时维持查询和浏览操作而无需预先解压缩。是在Web上存储和共享RDF数据集的理想格式。