可作为编目手册的《RDA全视角解读》

罗翀主编《RDA全视角解读》. 国家图书馆出版社, 2015.5

去年《RDA全视角解读》出版后收到赠书,翻了下觉得很实用,转手借给做编目的同事参考。前些日子书还回来,今天花半天时间粗细结合看过一篇,感受到作者们对RDA的深入了解,而本书也确如前言所称,可作为“指导编目员实践工作的应用手册和编目工具”,值得推荐。
本书第1-5章为RDA基础。最后的第15章提出RDA在我国图书馆的应用策略,能在多大程度上实现不得而知。可作为手册使用的是6-14章及附录。
第6-11章以RDA框架、结合MARC21格式,讲述RDA规则,很接地气。
第12章“特殊类型资源RDA元素综合记录”,针对连续出版物、集成性资源、地图资源、电子资源、音像资源、音乐资源、缩微资源7种类型资源,分别讲述按照RDA规则的MARC记录编制。特殊类型资源相应的336-338字段术语及代码,则可参照附录B。
第13章“RDA与AACR2规则差异分析”,从宏观的总体差异到体现在MARC字段上的微观差异,相当全面。其中表5“AACR2与RDA载体类型术语对比一览表”对特殊类型资源编目会很有帮助。
第14章“MARC21为RDA所做修订”基本以MARC21标准网站“RDA in MARC”为纲撰写,解释清晰。可配合附录C“MARC21为RDA新增字段表”阅读。
附录D“RDA完整样例分析”精选有代表性的例子并做解释,对理解不同类型文献RDA规则应用十分有帮助。

——— 纠缠的分割线 ———
首先想说明的是,书中有些做法与LC实践有所不同——当然不存在对错。
一是没有出版年有版权年,或者出版年与版权年相同时:LC通常不记录版权年,只记录出版年、或者以版权年估计的出版年(加方括号)。 为什么不保留版权年信息,却不得而知。
二是丛编规范,LC在前些年已经放弃维护,因而通常只做490字段、不做830字段。当490内容与830相同时,更不会在490之外再做830。

其次是“与责任说明相连接的名词短语”问题,这是RDA与AACR2不同之处。按AACR2要区分不同情况,或入责任说明(当作为承担角色)、或作为其他题名信息(当说明作品的性质时)。而RDA2.4.1.8则简化为“如果名词或名词短语与责任说明一起出现,则将该名词或名词短语作为责任说明的一部分”。
书中p.273页举了两个例子,都是说明作品性质的,AACR2记录入245$b,RDA记录入245$c。例2:
AACR2记录:245 10 $aPacazo :$ba novel /$cby Roy Kesey.
RDA记录:245 10 $aPacazo /$ca novel by Roy Kesey.
例子完全没有问题。只是读者或未注意“一起出现”或“与责任说明相连接”的含义,上例题名页版式当如:

Pacazo
a novel by Roy Kesey

如果题名页版式如下时,RDA记录与AACR2记录应当是完全一致的:

Pacazo
a novel
by Roy Kesey

如果能有页面版式对照,举两个分别入$b和$c的不同例子,相信不至产生误解。

——— 附《RDA全视角解读》目次 ———
1 RDA的前世与今生
2 RDA的思想基础
3 RDA的普及与推广
4 RDA在美国图书馆界的测试
5 RDA的框架与内容
6 识别载体表现和单件
7 识别作品和内容表达
8 识别个人
9 识别家族
10 识别团体
11 描述关系
12 特殊类型资源RDA元素综合记录
13 RDA与AACR2规则差异分析
14 MARC 21为RDA所做的修订
15 RDA在我国图书馆的应用策略
附录A RDA工具套件应用说明
附录B RDA内容类型、媒介类型和载体类型术语表
附录C MARC 21为RDA新增字段表
附录D RDA完整样例分析

Schema.org: Web上结构化数据的演变(笔记)

来自谷歌和微软的三位Schema.org开发者,2015年底发表了一篇介绍四年来Schema.org演变的文章,在追求“结构化数据”的大背景下,详述开发的前因后果,以及与关联数据的关系:

R.V. Guha, Dan Brickley, Steve Macbeth. Schema.org: Evolution of Structured Data on the Web. Queue vol. 13, no. 9 (December 15, 2015)

文章小标题:Big data makes common schemas even more necessary.
体现在文章结论的最后:“对大数据的增长兴趣使得对共同schema的需求比以往更相关。当数据科学家探索数据驱动分析的价值,需要从不同来源把数据抓在一起,因此对共享词表的需求正在增长。我们希望schema.org将对此有所贡献。”

【结构化数据标准的发展】
早期(1997年前?)有XML和MCF (Meta Content Framework)。
1997-2004年间针对语法和数据模型开发了不同的标准(RDF、RDFS和OWL)。针对具体行业提出许多词表,某些得到广泛采用,如hCard、FOAF。不同垂直领域的词表完全独立,导致大量重复和混乱。更糟的是,不同搜索引擎推荐不同的词表。
针对此问题,2011年主要搜索引擎公司Bing, Google, Yahoo(及后来加入的Yandex)创建Schema.org,目的是提供跨领域的单一词表。最初是三个公司关起门来做决定,后来逐步开放,先是在W3C公共论坛讨论,后来改变模式为所有决定都公开做出[在GitHub上],有一个来自资助公司、学界及W3C的指导委员会。
Schema.org发布时297个类、187个关系,四年后增加至638个类、965个关系。

愿景图“来自多个网站的知识库样例”比以前看到过的图更具说明性

【Schema.org应用】
– 首个应用是谷歌搜索结果的丰富片断(Rich Snippets)在2011年转用Schema.org词表。[snippet最早由雅虎采用、谷歌跟进,当时依据垂直领域词表]
– 用作谷歌知识图谱(Knowledge Graph)的数据源,显示在检索结果侧栏的事实面板。
– 电子邮件。预订饭店、旅馆、航班等电邮嵌入Schema.org标记,电邮辅助工具可抽取结构化数据,通过手机通知、地图、日历等使用。Gmail和Google搜索产品使用此数据提供提醒,如订餐会基于饭店位置、用户、交通状况等,触发提醒去饭店。
微软小娜(Cortana)通过电邮讯息利用schema.org
Pinterest利用Schema.org提供针对菜谱、电影、文章、产品或地点的丰富钉板(rich pins)。
苹果的Searchlight/Siri使用Schema.org提供搜索特性,包括集成评分、供应者、产品、价格、互动计数、机构、图像、电话号码及潜在的网站搜索行动。还用于新闻RSS。

【采用统计及原因分析】
在100亿网页的样本中,31.3%网页有Schema.org标记,1年前是22%。含有标记的网页平均参引6个实体、作出26个逻辑断言。估计至少1200万网站使用Schema.org标记。结构化数据标记现在与Web本身是一个数量级的了。
快速增长的原因是第三方工具的扩展支持,如Drupal和Wordpress,以及垂直内容管理系统(如Bandsintown和Ticketmaster)。

【设计决策:成功原因分析】
设计Schema.org的驱动因素是方便站长发布其数据。总体上,设计决策把更多负担放在标识的消费者。
– 支持多种语法:RDFa、JSON-LD、Microdata
– 多态性:关系/属性可以有多个定义域、多个值域(减少不必要的类)
– 实体参引:只有非常少的部分要求唯一URI
– 增量复杂性:从简单开始,逐步增加表达性。受实用性引导,定义从不为追求完美模型而改变,但回应来自发布者和消费者的反馈。
– 清理:清除无有意义使用的术语[类似文献保障原则]

【扩展】
保持最通用为核心,其他作为扩展。
参见:Schema.org扩展机制(及汽车&书目扩展)

———-关联数据的分割线———-
【对关联数据现状的基本判断】
自2006年,“关联数据”口号重定向W3C的RDF社区,从强调语义网本体和规则语言,到开放数据活动和实践数据共享。
关联数据宣传已经成功地从各种公共部门和开放数据源引起了大量以RDF表达的公开数据(如图书馆、生命科学和政府)。但是,强调标识符调和、复杂的最佳实践规则(包括HTTP的高级使用)、使用任意数量的部分重叠词表(schema),限制了关联数据实践在专业信息管理者以外领域的成长。关联RDF数据发布实践没有在广泛的Web得到采用。
(与“从语义网到知识图谱——语义技术工程化的回顾与反思”文章的认识一致。参见:知识图谱、语义网、关联数据;另见:关联数据注意事项

【与关联数据的异同】
Schema.org分享很多关联数据社区方法:使用相同的数据模型和标记语言(RDFS)和语法(如JSON-LD和RDFa),分享很多相同的目标。也分享了关联数据社区对语义网旗下实施的很多学术工作中发现的对过早成熟的形式主义的怀疑(规则系统、描述逻辑等)。尽管Schema.org也避免假定这类基于规则的处理会是普通的,但它不同于典型的关联数据指引,假定来自Web的结构化数据能在应用中利用前,通常会需要不同类型的清理、调和及后处理。【换言之,对Schema.org,数据清洗不是必要的——想起情报检索语言的前控和后控】

关联数据的目标更高,并因此带到Web的数据源数量很小、然而其质量往往很高。这两种方法相结合提供了很多的机会——例如,专业发布关联数据常能规范描述来自更广泛主流Web的schema.org描述中提及的实体。【公共部门继续承担需要更多费用的专业工作】

知识图谱、语义网、关联数据

2014年时,约翰霍普金斯大学图书馆系统馆员Jonathan Rochkind写了篇博文:语义网还是个事儿吗?当时我作了译介(2014-11-8)。一年后他离开了已经工作9年并且热爱着的图书馆,去了一家软件公司就职。发消息前两天他写了长篇博文《关联数据注意事项》(Linked Data Caution),用众多事实佐证自己先前的看法。在离开博文中,他说自己身心俱疲(Career change, 2015-11-25),不是因为关联数据而离开,但那篇博文可作为他的临别赠言。可以看出他对图书馆前景的深度失望,以及对图书馆界在关联数据上投入巨大的深度担忧。

今天看到鲍捷的《从语义网到知识图谱——语义技术工程化的回顾与反思》,让我又想起Jonathan Rochkind和他对关联数据的看法。计算机领域变化太快,不同观点太多(或者说共识少,要不然也不会有那么多死在沙滩上的前浪),鲍文的观点有待验证。无论如何,作笔记如下。

———从语义网到知识图谱——语义技术工程化的回顾与反思(笔记)———
– 基本观点:“语义网”这两年改名“知识图谱”;工程优于科学【逻辑】。
关于关联开放数据:Tim Berners-Lee(就是我们的神)呼吁:语义网 -> (因为感觉走偏)2006年提出关联数据 -> 2009年公开数据(用RDF结构化)。
关于元数据和知识图谱:元数据 -> 演变成RDF -> 然后演变成一堆奇奇怪怪的语言 -> 然后是schema.org【一统天下?】 -> 最后演变到了今天的知识图谱。
关于RDF:RDF不适合作为存储语言。
RDF的发展:知识的交换语言 -> 数据建模语言 -> 数据存储语言。作为存储语言,由于要完全从头开发,高成本低性能而失败。
2013年Google推目前知识图谱用的Microdata,后来JSON-LD,充分利用现有工具。
存储语言:RDF数据 -> 图数据库(键值数据库?)。图数据库比三元组库和SPARQL更主流。
【乱弹:如此则RDF与MARC倒是很类似,是交换语言而非存储语言。ILS内部并不按MARC格式保存】
关于本体语言OWL和RDF1.1:弱语义的语义网,优于强语义的OWL。
OWL2语言很失败、没人用。
2004的RDF语义是怪胎,2014年RDF1.1是厄运的开始。【在计算机界,常见不同版本并用,并非未及升级,如当年的RSS】
逻辑或推理非常需要成本,在实践中很少使用。大多数时间有数据就够了,有一个结构化的东西就好。
Dublin Core等没能发展起来,因为都是面向机器的,它考虑的是怎么提高机器的效率。RSS想的是我怎么提高人的效率,这样就火起来了。【图书馆界在说要让机器能够用数据,他说要让人用得高效】
构造知识图谱,需要知识工程的技术,需要自然语言处理的技术,需要规则系统,需要正则表达式。有效的才是最好的。

——— Google趋势:知识图谱vs语义网vs关联数据———
在先前博文中语义网(SW)和关联数据(LD)搜索对比基础上,增加知识图谱(KG)做对比。Google搜索趋势显示,在SW下降与LD上升趋势交汇后的2012年5月,KG异军突起超出SW和LD,2012年12月出现第2个超出SW和LD的峰值,其他时间均在两者之下,搜索量起伏不大。SW仍持续下跌,LD则平稳起伏。

Google Trends: KG,SW,LD

另看国家趋势
KG前五:印度100、美国60、德国50、英国47、法国39(没有其他国家)
SW前五:韩国100、巴基斯坦98、印度87、奥地利85、爱尔兰/伊朗74,(英国37、美国30)
LD前五:印度100、巴基斯坦68、菲律宾28、英国/美国均21