关联数据的“调和”与“解析”

关联数据应用中,相同实体判定是重要工作,决定最终的应用效果。对于从原有数据转换而来的关联数据,这项工作尤其重要。比如从MARC转换到BIBFRAME、schema.org或其他格式,完成格式上的映射后,做一个转换程序不会太难,麻烦的是给转换后的实体配上相应的URI。当然可以简单地设置自家URI/IRI,但后续也需要与其他/通用URI匹配,才能发挥作用。比如把书目记录中的某个作者,关联到维基百科中的某个人物词条。调和与解析(Reconciliation & Resolution),就是对实体进行匹配。

LD4 Community Working Group on Reconciliation
基于安德鲁梅隆基金系列课题(LD4L、LD4L-Labs、LD4P)的LD4社群,在2017年5月成立了一个开放参与的“调和与解析工作组”,致力于解决这个问题。目前志愿参与的成员来自Europeana、芬兰赫尔辛基大学、美国国会图书馆、史密森学会、斯坦福大学、华盛顿大学、印第安那大学、加州大学圣迭戈分校、加州大学圣芭芭拉分校、加州大学校长办公室、艾利贝斯集团、Apache软件基金。
工作组目标是为文化遗产/GLAM(美术馆、图书馆、档案馆、博物馆)的资源元数据的调和与解析,总结匹配算法、工作流程、工具和功能需求
对于相关概念,小组认定的术语含义如下(目前工作内容仅涉及前二者):
调和(Reconciliation):实体/URI到实体/URI
实体解析(Entity resolution):字符串到实体/URI(常误称“调和”)
词汇化(Lexicalization):实体/URI到字符串(即得到相应的标签label)

调和与解析相关工作,在实际应用中可能不只是匹配一种情况。目前小组正在公开征集用例、功能需求、当前服务、工作流程等。有一个提交用例的简单模板,包括主要行动者(参与人员)、涉及范围、描述(story)三项内容。
GitHub上到今天(2017-8-10)已经提交了38个用例(编号21-76,有跳号),比如:#76跨语言匹配,#70运行优化,#68使用本体,#39断言两个实体不同。

via BIBFRAME listserv: Call for Reconciliation & Entity Resolution Use Cases / Needs / Stories. Brian Tingle. 8 Aug 2017
参见小组工作计划:LD4 Community Working Group on Reconciliation, 2017-2018 Work Plan

另参见:重量级图书馆关联数据项目LD4P获得资助(2016-5-10)

3R项目与RDA“四路径”

假期看RSC官网上2017年PPT,最新的是6月底ALA年会上的报告,好几个都是对先前会议上报告的更新,基本上看年会的就可以了。
报告重点自然是3R项目,2017.4-2018.4 RDA内容冻结,进行RDA内容重构和工具包网站重新设计。
RDA内容重构,主要是与IFLA-LRM一致,由此新增元素,也将导致章节发生较大变化,并推倒原有编号体系——变化会相当大。不过,应该类似RDA发布后的“重写”(re-write),条款内容/规则本身还是相对稳定的,因此ALA的RSC代表Kathy Glennan在年初ALA仲冬会议的RDA论坛称,这不是RDA2.0,只是一个新的“内容表达”Outcomes of the November 2016 RDA Steering Committee Meeting)。

3R项目参见:
RDA是个全球标准吗?以使用、翻译和治理作为指标(2016-10-20)
RDA将在2017年依照IFLA-LRM更新(2016-11-21)
RDA为3R项目所做修改(附:多个首选名称)(2017-2-19)

——— 四路径(4-fold path)———
多个报告涉及“四路径”(4-fold path)。按设想,更新后的RDA将在开始的总章中设置“四路径”节,每个元素章节中也会有相应的“四路径”部分。这是个值得注意的变化。
RDA编制过程中,时任RDA编辑的Tom Delsey曾向JSC提出过《RDA数据库实施场景》(RDA Database Implementation Scenarios, 5JSC/Editor/2/Rev, 1 July 2009),有3种场景:场景1关系/面向对象数据库结构,场景2关联书目和规范记录,场景3扁平数据库结构(无链接)。
针对不同场景,RDA提供3种基于文本/字符串(string)的表达方式(并非与以上场景一对一):
1非结构化描述(没有可供机器分拆的内部结构,只能抽取关键词。如转录、自由文本的附注)
2结构化描述(有某种形式的内部或外部结构,如由子元素值组成的规定顺序的字符串,来自取值词表或规范档的术语)
3标识符(“由代码、数字或其他字符串组成的nomen,通常独立于自然语言或社会命名惯例”,区别于基于语言的描述/著录,“本地的”、在全域范围内不唯一。如ISBN,ISNI)
另外在RDA注册/关联数据应用中,还有第4种方式:
4 IRI/URI(基于事物 thing,全域范围内唯一)
所谓“四路径”,即指这4种表示方式。

目前RDA中的结构化描述、非结构化描述,主要针对揭示FRBR实体间关系。但根据以上说明,广义而言也有其他元素提供上述3种方式(尤其是各种转录、各种附注),重构后将扩展到所有元素(不适用者除外),并且会提供相应的样例。ALA年会的《3R项目更新》报告(Update on 3R Project)举了元素”个人所用语言”的例子:
Element: language of person
* 非结构化描述:“The author writes in English”
* 结构化描述:“English”
* 标识符:“eng”
^ IRI: http://id.loc.gov/vocabulary/languages/eng
(其中*指字符串/string,^指事物/thing)

第4条路径的加入,是RDA进一步融入关联数据应用的反映。前面对四路径的说明性文字主要取自RSC现任主席Gordon Dunsire的ALA年会报告: Appellations, Authorities, and Access Plus。他还解释了四路径与LRM用户任务之间的关系:对于“识别”,如果有本地标识符或全域IRI,则不需要“首选”名称字符串;对于“查找”与“探索”,还是需要人读的名称;强调的重点由“规范形式”转向名称的多种形式,可参考虚拟国际规范档VIAF。
最后一句蕴含的意思是:既然名称的作用在于“查找”与“探索”而非“识别”(区分),自然各种名称形式多多益善,哪个“首选”已经不重要了。

用类表达类型相对于属性的3个优点

BIBFRAME2.0增加了很多类,增加的类中,很大一部分来自原来的属性。参见:BIBFRAME2.0类的变化(2016-5-2)
比如1.0有数十个表示标识符类型的属性(doi、isbn等),2.0只保留了一个通用的标识符属性identifier(改为一对互逆属性identifiedBy / identifies),其他具体标识符类型大都变成了类(bf:Identifier的子类),有些则取消了(比如isbn的子属性isbn10, isbn13)。

属性变为类,用三元组表达有很大不同。以ISBN为例:
BIBFRAME 1.0(bf:isbn 定义域为实例,值域为 bf:Identifier)
<http://bibframe.example.org/5226/i1> bf:isbn “0394856309”
BIBFRAME 2.0(bf:identifiedBy 不限定使用范围,期望值为 bf:Identifier)
<http://bibframe.example.org/5226#Instance> a bf:Instance;
bf:identifiedBy [ a bf:Isbn ;
rdf:value “0394856309” ]

对人类而言,1.0方式直观、易解,2.0方式比较绕。对于机器可能完全不一样。BIBFRAME 2.0 RDF Conventions (2016-4-21) 在“4)类与类型”部分对此有如下解释:
表达类型为类而非属性有若干优点
可重用。以标识符为例。对于BIBFRAME中表达的每个标识符,创建一个bf:Identifier资源。如果创建为一个关联数据资源(赋予URI),则可被BIBFRAME之外获取与重用。用类反映标识符来源意味着会在被用时获知。如果来源仅由BIBFRAME属性传达,则该来源只当在BIBFRAME环境中访问时才获知。
查询效率。表达类型为类通常让数据更易于被查询。例如“查找类型X的东西”,当X是类时比是属性时更简单。
柔性降级。假定在某外部命名空间(ex:)中创建新的附注类型。如果新类型用属性表达,形如:
ex:noteType “note content”
另一方面,如果类型用类表达,形如:
bf:note [ a ex:NoteType ;
rdfs:label “note content” ]
如果接收系统不认识命名空间ex,则在第一种情况中,陈述完全没有意义。在第二种情况中,系统至少能够认识它是一个附注(尽管不知道附注类型)。

【需要说明的是,对于编目员/元数据制作者,只需要知道有哪些类/属性可用于揭示资源,并不需要了解实际的编码方式。那些都交给计算机程序去解决】

关于“BIBFRAME 2.0 RDF Conventions”,另参见:rdf:value和rdfs:label的差别(2016-6-22)