BIBFRAME模型公布

来自nalsi的消息(1月30日),BIBFRAME有了自己的网站:http://bibframe.org/,前往一看。
网站目前有几个部分,其中View of the BIBFRAME vocabulary along with supporting formal specifications实际上首次完整发布了BIBFRAME模型。其他包括演示及转换工具,以及书目框架转变行动的重要文件链接。

———-BIBFRAME模型:词汇及形式规范———-
2012年11月模型草案公布时,只是一个框架,没有具体的元数据格式;12月早期实验代码公布,也只能通过转换代码的规则部分,拼出元数据格式。现在可以看到BIBFRAME元数据规范了。

四个核心类(class)创作作品、实例、规范、注释都有用于资源(Resource)及具体类的属性(Property),属性说明包括:取值(Expected value)、说明(Description)[update 2013-3-9: 现称“标签(Label)”]、MARC映射(MARC Mapping)和RDA相关附注(Related RDA Note)──或许还来不及做,RDA部分基本空白。

———-演示区(a demonstration area)———-
呈现测试数据集。目前有7个参与机构提供的8个样本数据集,分别是美国国会图书馆(2个)、不列颠图书馆、德国国家图书馆、乔治·华盛顿大学图书馆、美国国家医学图书馆(NLM)、OCLC和普林斯顿图书馆。
采用Exhibit 3.0发布,类似于分面OPAC,左侧栏有创建者、主题、贡献者、提供者/出版者四个分面限定项。大致浏览了一下,有四个感觉:
(1)部分条目下列有多个作品(Work)。不知道这条目是何含义,因为在BIBFRAME模型中,作品是最高层。
(2)作品下列有包含作品(分析)和相关作品,尤以OCLC数据为多。相关作品并没有指出具体的相关关系。
(3)作品没有都列出实例(instance)──更像是规范数据而非书目数据。
(4)作品有多个实例的比较少见。看到美国国会图书馆有两个实例的,只是ISBN不同(10位和13位),出版信息等相同;德国国家图书馆数据中倒是有一些真正的两个不同实例,但也没有看到不同contributor的。难道其Work对应的是内容表达(对应ISTC)?
记得OCLC曾有一个统计,有百分之十几书目属于作品的不同版本,如果以内容表达作为顶层,这个比例更低,汇集资源的价值也会降低──比如无法汇集同一作品的不同译本。当然可以通过定义作品之间的具体关系做关联(而不是笼统的“相关”关系)。

———-BIBFRAME词汇与MARC21对应———-
目前尚无链接,但在模型部分已经有部分MARC21映射.

———-代码与支持服务———-
– 代码,参见:BIBFRAME早期实验代码公布
– 支持服务(工具):评估BIBFRAME模型中MARC书目记录的工具
1、比较服务:针对LC的MARC记录,输入001字段值或LCCN,看MARC/XML记录和BIBFRAME RDF/XML记录
似乎看到了未来LC关联书目数据的URI,如:http://id.loc.gov/resources/bibs/123456
2、转换服务:提交MARC/XML记录(联机网址或直接粘贴文本),由Exhibit转换后以BIBFRAME资源呈现,转换结果可下载

———-背景链接———-
2011年10月31日LC发布《数字时代的书目框架》以来的重要文件
参见:相关博文

———-关注:发布工具Exhibit 3.0———-
Exhibit 3.0是大规模丰富数据交互网页的发布框架,软件有两个独立模块:脚本式(Scripted),用于建立较小的浏览器内展示;舞台式(Staged),用于较大的基于服务器的展示。

参见:
BIBFRAME早期实验代码公布(2012年12月11日)
书目框架模型草案发布(2012年11月26日)
书目框架模型相关信息及讨论(2012年11月26日)
ONIX方面对BIBFRAME的评论(2012年12月3日)

BIBFRAME早期实验代码公布

上月下旬BIBFRAME模型草案发布,只是一个框架,并没有具体的元数据格式。在邮件组中,发布者曾说会在12月后分享早期实验结果。才过了两个星期,上周五,LC的Kevin Ford在邮件组中提供了从MARC书目记录转换到BIBFRAME的两个程序,分别是LC开发的XQuery版和Zepheira开发的Python版。下载网址:https://github.com/lcnetdev/marc2bibframe
一直以为老外是下班时间不干活的,没想到周末就有不少人把这两个程序装上做试验,从MARCXML转换成分层次的BIBFRAME,还发现了些问题。
不擅长IT的编目员,则关注元数据格式。通过邮件组的讨论,也了解到可以从程序中看到转换规则──并拼出BIBFRAME的元数据格式

python的marc2bibframe https://github.com/lcnetdev/marc2bibframe/blob/master/python/lib/marc.py
XQuery的marc2bibframe
https://github.com/lcnetdev/marc2bibframe/blob/master/xquery/modules/module.MARCXMLBIB-2-BIBFRAME.xqy

Karen Coyle的做了个简单的BIBFRAME实验网页,放一些MARC记录对照的样例:
http://kcoyle.net/bibframe/
周一的时候只有普通图书、地图和CD三个样例。她还在征求记录,今天看增加了文集、缩微品和带头衔的人名。

ONIX方面对BIBFRAME的评论

出版行业的元数据标准ONIX由EDItEUR维护。BIBFRAME模型草案发布后,EDItEUR的首席数据架构师Graham BellBIBFRAME邮件组中发表了评论,涉及到ONIX背后的概念模型<indecs>及其与FRBR模型的异同。翻译并[简评]如下:

[BIBFRAME] Comments on BIBFRAME draft model from EDItEUR (2012-11-29)

对报告概述的BIBFRAME模型草案,我们的第一反应很大程度上是正面的。然而,对于缺乏“单个复本”实体(以及BIBFRAME“实例”实体潜在的令人困惑的命名),我支持对此表示保留的评论。我想澄清一些报告中涉及的对ONIX和< indecs >的误解。
[第一句完全是客套话。本段其实是在质疑BIBFRAME类的设置及其名称。BIBFRAME有4个主要类,对应FRBR“单件”的不是独立的类,而是属于“注释”类;对应FRBR“载体表现”的,是“实例”类]

如同FRBR,<indecs>是一个概念模型。事实上,<indecs>包含两个基本模型:报告中引用的商务模型(“人们做东西、用东西、交易东西”),还有指代“东西”的“制作模型”或称“创作模型”(非常接近对应FRBR,尽管两者是完全独立开发的)。在目前语境下,相关的<indecs>是创作模型,基于3个而非4个概念层──抽象(Abstraction)(大约相当于FRBR内容表达,也明确是一个知识产权项目)、载体表现、单件。“内容表达”及相关的“定位”(Fixation),是抽象和载体表现间关系的方面。没有对应FRBR作品的。对熟悉的图书,“单件”就是单个复本,“载体表现”是一类相同的册(典型的以一个ISBN标识),“抽象”是许多潜在“载体表现”的抽象类,现在可以用一个ISTC(国际标准文本码)标识,可以与其他“抽象”形成多对多关系──这当然不只用于图书。
[<indecs>三层:抽象=内容表达-ISTC、载体表现、单件。对应BIBFRAME的三层是:作品、实例、注释中的馆藏]

在某种程度上,BIBFRAME草案近乎<indecs>。值得注意的是,<indecs>也预示了今天对关联数据的关注:“一项元数据即某人声称两个实体间存在的关系。” [1]

然而,<indecs>包含“单件”实体,而BIBFRAME模型草案没有,似乎是个奇怪的遗漏。我想说,必要时最好能够识别个别复本,能够分开适用于资源的个别复本的BIBFRAME“注释”,与适用于整个BIBFRAME“实例”的“注释”(“实例”组成所有复本的类)。
[注:BIBFRAME把“单件”归入“注释”之下]

如报告所说,图书ONIX(ONIX for Books)是部分基于<indecs>的,本身关注描述“载体表现”,尽管“载体表现”的很多属性无疑继承自“抽象”。图书ONIX最初由美国出版者协会(AAP)构想于1999年,2000年发布1.0版。进一步的联合开发经由EDItDUR实施,与书业研究组(BISG)和书业交流会(BIC)合作,但目前已由EDItDUR管理多年,由代表约20个国家用户组织的国际指导委员会领导,这些国家包括最近的中国、日本和阿拉伯国家。这是个真正的国际贸易标准,并且免费使用。
[ONIX有图书和连续出版物两种格式]

图书ONIX最广泛采用的是2.1版,发布于2003,之后只做过少量更新。最新发布的是3.0,有一个微小更新到3.0.1(增加了两个属性,用于非字母文字如日语汉字的人名或题名的语音排序)[2]。EDItEUR已经宣布2014年底为“日落之日”(sunset date),将减少对2.1的支持,鼓励所有实施者更新到3.0。

BIBFRAME模型草案与<indecs>的紧密校准(alignment),为商业元数据──以ONIX为例──与图书馆元数据之间更大程度的语义互操作提供了极大的希望。目前ONIX和MARC数据间的对照(Crosswalks)过于复杂,而BIBFRAME具有大大简化商业与图书馆数据交换的潜力。更大互操作的益处也可以延伸到音乐,如DDEX──相当于录音贸易中的ONIX──也基于<indecs>。
[或者说,既然BIBFRAME并没有采用FRBR,图书馆界也基于<indecs>算了?]

图书ONIX的关键价值之一是用于ONIX元数据的大量控制词表集(并且很大程度上在不同版本间共享)。EDItEUR将在未来数月内,(用SKOS)为每个术语发布权威的URI,如此这些术语将可被任何人用于发布关于图书或其他图书馆资源的关联数据。
[当年看ONIX,不知道其三层模型,感受最深的就是其词表的开放性,同一个“字段”,接受各种来源的词表,不像MARC格式那么严格规定采用一种。现在,RDA词表的出版还在磨磳中,ONIX词表已经要发布了──未来关联数据环境下,出版业将领先?]

连续出版物ONIX(ONIX for Serials)系列信息──最初由EDItEUR和NISO开发、现称订阅产品ONIX(ONIX for Subscription Products)──与图书ONIX相比,布署得相当有限,主要用于图书馆订阅代理者和主要期刊出版者之间的交流。相关信息标准特别用于如描述保留馆藏。

[1] The <indecs> Framework
[2] ONIX 3.0 Specification, Implementation and best practice guide, and latest controlled vocabularies