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数据集的理想格式。

MARC到BIBFRAME 2.0转换工具:使用报告

芬兰国家图书馆的Osma Suominen在美国国会图书馆(LC)发布MARC到BIBFRAME 2.0转换工具后,第一时间进行了试用,并在BIBFRAME邮件组分享了他的试用报告。
转换MARC书目记录为RDF,是芬兰国家图书馆关联数据工作流程中重要一环。相对于MARC到bf的原转换工具,试用报告对MARC到bf2转换工具给予较高评价,也非常赞赏规范与具体转换分离的方式,称之为solid engineering。只是对于LC来说,比较遗憾的或许是BIBFRAME只是作为一个中间过渡,芬兰国图的关联数据主要采用Schema.org作为目标数据模型。
LC的marc2bibframe2转换工具芬兰国图的书目数据到RDF转换流程bib-rdf-pipeline 都放在GitHub上,Osma Suominen在使用过程中发现问题可随时提交,或给出自己的修正,充分显示了GitHub平台在应用分享和共同维护上的优势。

Osma Suominen使用报告摘译如下:
[BIBFRAME] First impressions of new MARC to BIBFRAME 2.0 converter / Osma Suominen (2017-3-23)

1、技术架构
转换器基于XSL样式表,有很多可用的实施。本次转换按README文件建议使用xsltproc XSL处理器。
代码分成约20个XSL文件,每个对应一个发布为Excel表的转换规范,还有相应的使用XSpec写的单元测试,用于验证转换是否产生想要的结果。
XSL执行比bf转换所用XQuery好很多。同时由规范(Excel表)到实施(XSL)和单元测试(XSpec)的链条,让转换的需求和实施验证显得很清晰。旧转换器中,代码本身作为规范,并且没有单元测试。
2、性能
性能良好。单记录少于0.2秒,原转换工具使用Saxon要4秒。批量,单CPU约每秒160条记录(快于原每秒100条记录)。用4CPU并行转换1M记录约20分钟,几乎是原4倍速(75分钟)。
3、问题
发现一些bug,已在GitHub上作为问题报告。生成不正确RDF语法的问题及时得到解决。最严重的问题是转换语言信息,会混如本批中其他记录中的信息,我已修改转换器防止此问题,并作为pull提交。
4、缺失性能
相对于原转换程序:
【1】没有从240字段创建译本的“作品”
【2】没有转换10位ISBN到13位,也没有去短横
【3】序列化格式只支持RDF/XML,原来有N-Triples和JSON。这个可以理解,可以用其他工具实现。
5、文档
所有文档都在GitHub repo的顶层的README文件中。

RDA元素分析表中的“元素子类型”和“子元素”

RSC秘书在多个邮件组发布消息,《RDA元素分析表》更新。
RDA elements (March 2017) RSC/RDA/Element analysis table/rev/4 (14 March 2017)

“元素分析表”是RDA元素与RDA条款的对照表。本次为第4次修订,内容与工具包2017年4月发布同步。
与自己先前保存的第2次修订相比,本次修订多了“核心状态”栏,注明是否为核心元素。没有作对比,估计应该还有一些因条款编号或名称变化所致的修改。

与第2次修订文件一样,分析表开始是表栏名称及说明。关于元素的分类(标注在对照表中各元素前):
元素 element:一个占位,存储由应用RDA条款而产生的值
元素子类型 element sub-type:元素的细化,限定元素的含义或范围
o 子元素 sub-element:一个元素,是较粗元素组成部分,该较粗元素是一个集合体或两个及以上(子)元素的组合。
集合或超元素 Aggregating or Super Element: 指集合一个子元素的元素,或者是一个元素子类型的超类型

比如超元素“题名”下各元素(如“正题名”)为元素子类型(实心圆),即每个都是某种类型的题名,相互之间是平行关系;
而超元素“版本说明”下各元素(如“版本标识”)为子元素(空心圆),即多个共同构成版本说明,相互之间是补充关系。
有时可能区分并不那么显而易见。

对于上述区分,在RDA-L和BIBFRAME邮件组分别引发提问:
– Karen Coyle 在 BIBFRAME 邮件组中问:“集合或超元素”是不是等同于RDF的类/超类?如果不是,区别是什么?
Stephen Hearn 在 RDA-L 邮件组:指出 Rev. 4 中的几处错误,并询问区分“元素子类型”和“子元素”的实际意义

第2天,RSC秘书致谢Stephen Hearn,并将 Rev.4 更新为 Rev. 5
RDA elements (March 2017) RSC/RDA/Element analysis table/rev/5 (15 March 2017)
以下4个由元素子类型改为子元素:
— latitude(属于longitude and latitude)
— longitude(属于longitude and latitude)
— right ascension(属于right ascension and declination)
— declination(属于right ascension and declination)

而RSC现任主席Gordon Dunsire则在BIBFRAME邮件组针对以上两个问题作对回复,说明:
这种区分在2009年时确定,RSC技术工作组一直有修改意向,但没有定论。
元素子类型是元素的细化,用RDF表达是作为较粗粒度元素的子属性
子元素是元素的成份,在DCAM/DCAP中,由语法编码体系(Syntax Encoding Scheme)指定。
至于RDF子类,RDA用来表达实体的子类型,如“个人”是“Agent”的子类。
3R项目期间,将审视元素分析表及其表达。术语本身源于2007年在不列颠图书馆召开的数据模型会议。(参见:图书馆从传统数据观走向关联数据及语义网:五周年,2012-5-16)