Quantcast
Channel: BIBFRAME –编目精灵III
Viewing all 122 articles
Browse latest View live

BIBFRAME扩展:哈佛电影本体及动态图像扩展

$
0
0

在LD4P和LD4L-Labs项目中,哈佛大学的工作包括对哈佛电影档案馆(Harvard Film Archive, HFA)馆藏的关联数据转换。据哈佛的LD4P项目计划(Harvard Project Proposal,由 Alissa Hafele创建, 最终由 Michelle Futornick修改于 二月 07, 2017):
“作为LD4L-Labs配套项目(5.2哈佛电影档案馆(HFA))的一部分,哈佛将探索和评估将动态图像资源的遗留元数据转换为关联数据的问题。本项目还将探讨使关联数据对研究和发现有用的问题。将开发元数据转换工具,为哈佛电影档案馆(HFA)拥有的各种格式(电影拷贝、底片、DVD、VHS、超8等)和内容(故事片、预告片、家庭电影、民族志电影、宣传片)及相关档案资料(包括制作元素、艺术品、电影剧照和宣传短片)创建关联数据描述。本项目将评估BIBFRAME作为数据模型用于描述动态图像资料,对于研究需求的有效性,并在关联数据环境中识别用于描述这些材料的特定词汇表。HFA项目将为HFA电影拷贝数据库中的记录创建映射,重点关注女性导演的一部分动态图像材料(之前曝光不足的作品,在许多情况下是该馆藏的独特之处)。在可能的情况下,实体将与关联数据URI进行调和,包括个人和公司名称(ISNI、LCNAF)、地名(GeoNames)、体裁(LC体裁/形式、Getty AAT)和作品。”

据介绍项目完成了35,000电影单件从Filemaker Pro数据库到关联数据的转换,生成3,600,000三元组,1,000电影制作人名称获取到ISNI身份。为描述HFA资料所用的哈佛电影本体,对BIBFRAME在动态图像资源方面估了有限的扩展,称为MI扩展(MI extension)。
哈佛电影档案使用主要本体如下(注意到非限定RDA得到多处利用):
描述领域:Works ; Instances ; Items;模型/本体: BIBFRAME
描述领域:Work to work relationships;模型/本体:BIBFRAME, RDAU, MI extension
描述领域:Titles ; Notes ; Annotations;模型/本体:Bibliotek-o, Web Annotations
描述领域:Activities and Agents;模型/本体:Bibliotek-o, dcterms, ISNI, FOAF
描述领域:Content/Carrier/Media ; Subjects ; Genres ;模型/本体:dcterms, schema.org, MI extension
描述领域:AV characteristics and preservation;模型/本体:RDAU, MI extension
描述领域:Provenance;模型/本体:ArtFrame-RareMat

via: LD4P + LD4L Labs projects for geospatial and cartographic resources + moving image materials at Harvard (Marc McGee and Christine Fernsebner Eslao; presentation for IGELU-ELUNA Linked Open Data Working Group Show & Tell, July 10, 2018,梯子自备) [slides]

去GitHub上的LD4L_Film_Ontology(2018-4-20最后更新)看MI extension.ttl,新增词表中技术细节不多,更偏重使用。概要如下:

新增类(4个)及其取值(Individuals,41个)
mi:ConditionDefect(缺陷情况),18个取值
mi:ConditionGrade(等级情况),4个取值
mi:Caution(注意),11个取值
mi:ColorCharacteristic(色彩特征),8个取值

新增子类(5个):
bf:Identifier子类:
– mi:ImdbNumber(IMDb标识符)
活动子类(bib:指bibliotek-o.org命名空间)
bib:Activity 子类
– mi:ProductionCompanyActivity(?原文件说明有误)
– mi:UseActivity(使用)
— mi:ScreenerActivity(促销放映)
bib:AcquisitionActivity 子类
– mi:PurchaseActivity(购买)

新增属性(4个):
dcterms:language(语言)子属性:
– mi:intertitleLanguage
– mi:spokenLanguage
– mi:subtitleLanguage
rdau:P60305(is based on)子属性http://www.rdaregistry.info/Elements/u/#P60305
– mi:isPromotionFor(是……的宣传片)【2018-4-20 最后增加】

更多详细信息见:Working documents for Moving Images LD4L Labs(Created by Christine Fernsebner Eslao, last modified on Apr 18, 2017)


MODS到BIBFRAME映射

$
0
0

MODS(Metadata Object Description Schema,元数据对象描述方案)是美国国会图书馆(LC)在21世纪初提出的书目元素集XML规范,基于MARC21书目格式。不同于LC上世纪末提出的MARCXML直接采用MARC21及其字段、子字段名(数字+字母),MODS取MARC21最常用子集,采用基于英语的标签表达元素(比如titleInfo)。最新版为3.7(2018-1-4)。
由于MODS基于MARC21书目格式,图书馆在建立数字资源库时可以方便地由现有MARC记录转换,且其比都柏林核心15个基本元素具有更丰富的书目信息表达能力,因而在国外数字图书馆项目中有较多应用。
时光流转,技术逐渐由XML转向RDF,LC开始MODS RDF行动计划(MODS RDF Initiatives),打算把MODS转换到RDF,并建立了MODS/RDF命名空间(MODS/RDFNamespace Document,草案,最后更新2012-06-19)。然而此计划多年来一直处于“进行中”,2011年开始的由书目框架取代MARC的计划应该是重要原因。
随着BIBFRAME开发逐渐完成,官方的MODS编辑委员会提出《MODS 3.6到BIBFRAME 2.0转换》(MODS 3.6 to BIBFRAME 2.0 Conversion,2018-2-1),有放弃MODS/RDF直接采用BIBFRAME的迹象。
上述转换文件按20个MODS顶层元素列出MODS到BF2的转换。转换大量采用空节点方式(如mods:name对应BF:_:w a bf:Work bf:contribution [a bf:Contribution ; bf:agent [a bf:Agent] .),且有很多特性没有映射,也就是说BIBFRAME达不到MODS的揭示粒度——考虑到MODS只是MARC21的子集,这似乎有点不可思议。

ALA 2019仲冬会议的BIBFRAME更新论坛

$
0
0

德国国家图书馆的Reinhold Heuvelmann在BIBFRAME邮件组发消息,看到BIBFRAME更新论坛的所有报告都上线了(官方未发信息)。

2011年书目框架行动启动以来,自2012年冬起更新论坛每年2次在ALA仲冬和夏季年会中举办。参见:
LC书目框架转换行动:首届更新论坛(2012-2-7)
ALA 2016仲冬会议的BIBFRAME更新论坛(2016-1-29)
2016 ALA年会BIBFRAME更新论坛(2016-8-27)
2017年BIBFRAME更新论坛(2017-7-26)
2018年BIBFRAME更新论坛(2018-11-14)

今年照例除美国国会图书馆(LC)本身外,还请了其他机构,除从不缺席的OCLC,特别是欧洲的出席,共4家5个报告。
BIBFRAME Update Forum at ALA Midwinter Meeting 2019 (2019-1-27)

一、LC的BIBFRAME试验扩展
1、Expanding the Pilot / Sally McCallum, Library of Congress (PPT, 76KB)
【完成了从MARC到BIBFRAME转换,开始反向转换。】
转换的动机。
转换中遇到的问题,包括:BIBFRAME作品到MARC题名规范或者书目作品?非拉丁文字880字段;来自BIBFRAME数据的URI(带入MARC);MARC子字段末尾标点(不再有)。

2、Anonymous Resources, Blank Nodes, And Providers, Oh My! / Kevin Ford, Library of Congress (PPT, 392KB)
【本次会议最有意思的报告:BIBFRAME转换的匿名资源或空节点问题,实验通过规范控制或实体URI减少空节点】
使用匿名资源会导致大量重复资源,匿名资源的数量正在导致或将导致性能和扩展问题。
以“提供者”(主要是出版者)为例:在1800万MARC书目记录中=约1500万匿名提供者Agent资源。其中许多(大多数?)表达相同实体,比如Harcourt Brace, Penguin Books, Harper Collins。1500万中有120万独特提供者。
因此我们创建了一个“提供者”文档……做实验【即出版社规范档:id.loc.gov/bfentities/providers/…,实验对出版社使用URI】

二、LD4P2
3、LD4P Status update / Philip Schreur, Stanford University (PPT, 868KB)
介绍使用Sinopia作为BIBFRAME编辑器,使用SHARE-VDE转换记录为BIBFRAME(2018年BIBFRAME更新论坛上有SHARE-VDE介绍),以及LD4P的成果。
参见:
BIBFRMAE应用进展:LD4P实施之路(2018-7-8)
LD4P2走向实施之路:目标与工作(附LD4系列)(2019-1-8)

三、欧洲BIBFRAME研讨会
4、European BIBFRAME Workshop / Reinhold Heuvelmann, German National Library (PPT, 3.23MB)
欧洲BIBFRAME研讨会已经召开两届,每年9月召开:
2017.9.26-27 European BIBFRAME Workshop 2017, German National Library, Frankfurt https://wiki.dnb.de/display/EBW
2018.9.17-19 European BIBFRAME Workshop 2018, European University Institute, Fiesole (Florence), Italy http://www.casalini.it/EBW2018
2019.9.17-18 European BIBFRAME Workshop 2019, National Library of Sweden, Stockholm,

四、OCLC
5、OCLC BIBFRAME Update / Nathan Putnam, OCLC (PPT, 13.61MB)
介绍OCLC研究部的BIBFRAME相关工作:
* 使用LC的转换器,将WorldCat中的MARC记录转换为BIBFRAME数据,得到的经验教训是:[1]作品ID很重要,在处理开始就有用;[2]URI很重要,空节点=不可互操作;[3]OCLC处理书目记录=很少单件/实例数据【?】。
* OCLC研究部当前活动:创建可用的BIBFRAME数据图,供最终用户测试,已经完成:[1]Hash URI代替空节点;[2]移除已经有VIAF或FAST的额外实体属性【指哪些?】;[3]评审BIBFRAME管理数据【BF管理元数据放在作品下有点奇怪】;[4]在WorldCat记录集上测试图修改。
* 现在:OCLC研究部与全球产品管理部共享信息,前进的道路取决于回答有关问题:[1]工作流程,[2]用例,[3]期望成果/服务。
* 向前走,我们知道我们将提供BIBFRAME数据,需要答案的问题集中在社区需要和期望的内容上:[1]重要的是什么(标识符来源,转换选项,质量等);[2]如何评估数据?(API、下载、导出等)[3]应当强化什么?[4]WorldCat中的编目工作流程是什么?
* 与成员馆合作:
与RLP成员合作:[1]焦点小组,[2]收集需求,[3]期望的工作流程,[4]实践工作流程开发。
与成员馆和小组合作,如PCC、OCLC元数据首创咨询组、MOUG(音乐OCLC用户组 )、OLAC(关注非印刷资料的编目员组织)、OCLC CJK用户组等。

URI是标识符还是资源?

$
0
0

Dan Scott在BIBFRAME邮件组中提问:什么时候一个bf:Identifier是URI?并举如下例子:
@prefix bf: <http://id.loc.gov/ontologies/bibframe/> .
<http://example.org/2335409#Work> a bf:Text, bf:Work ;
bf:identifiedBy <http://worldcat.org/entity/work/id/638612>.
<http://worldcat.org/entity/work/id/638612> a bf:Identifier .

其下有跟贴20余条,算得上热烈讨论,问题一度变成了“bf:Identifier怎么用、是什么意思”。
因为我也曾有过困惑(为什么URI还要用引号),因此总结下相关信息点。
首先记录答案:对于URI,有引号的是标识符,没有引号的是资源/Thing

一、在BIBFRAME中,bf:Identifier 标识符(类)的定义是:与资源关联的标记或名称,例如URI或ISBN(Token or name that is associated with a resource, such as a URI or an ISBN.)。
解说:标识符是“名称”,因而以文字/字符串表示(即取值必须用引号),即使是URI——如果URI作为标识符,必须用引号。

二、与bf:Identifier同用的一对互逆属性是bf:identifiedBy/bf:identifies.
表达资源标识符的最基本形式:<资源> bf:identifiedBy “标识符”
解说:对于属性的使用条件,BIBFRAME2没有用“定义域”Domain、“值域”Range,而是用限制不太严格的“用于”Used with、“期望值”Expected Value。

三、LC的BIBFRAME样例中,标识符最常见的使用形式如:
@prefix bf: <http://id.loc.gov/ontologies/bibframe/> .
<http://example.org/2335409#Work> a bf:Text, bf:Work ;
bf:identifiedBy [ a bf:Identifier ;
rdf:value “http://worldcat.org/entity/work/id/638612”
] .
解说:bf:Identifier 有很多子类,包括其定义中所举的bf:Isbn,但没有bf:Uri。如果标识符取值是URI,直接用bf:Identifier类。
LC回应如有用例,不排除增加子类【当URI作为标识符而非Thing,似乎也没有特别强调其为URI的必要?】

四、不加引号的URI代表资源而不是标识符
本文最初Dan Scott的例子,可以简化为:
<http://example.org/2335409#Work> bf:identifiedBy <http://worldcat.org/entity/work/id/638612>
LC的BIBFRAME团队讨论后(由Ray Denenberg回复)认为,上例是断言两个资源相同:
A机构有一个作品:<http://example.org/2335409#Work>
B机构有一个和它一样的作品:<http://worldcat.org/entity/work/id/638612>
尽管资源不能标识资源(bf:identifiedBy用法不对)。
LC同时承认BIBFRAME中没有断言相同资源的属性:我们认识到需要做出这样的断言,而bibframe目前没有提供,我们将进一步调查。

讨论见:[BIBFRAME] When a bf:Identifier is a URI (2019.2.15-)
相关讨论:rdf:value和rdfs:label的差别(2016-6-22)

欧洲BIBFRAME研讨会

$
0
0

欧洲图书馆界一直走在关联数据应用的前列。2008年瑞典国家图书馆率先发布全国联合目录Libris为关联数据,十年后的2018年6月再次率先上线关联数据系统LibrisXL,取代其原有图书馆自动化系统Voyager的核心部分,词表基于BIBFRAME 2.0。而美国国会图书馆(LC)自2011.5.13启动“书目框架转换行动”(Bibliographic Framework Transition Initiative),研发BIBFRAME近8年、已历多轮试验,还没宣布何时“转换”——LC背负的MARC负担实在太重。

欧洲BIBFRAME研讨会(EBW)自2017年首次召开,已成为每年9月召开的年会。会期2天(2018年会前另有1天培训),报告人不限于欧洲,报告数量远超美国图书馆协会冬夏两个年会期间LC主办的BIBFRAME更新论坛,是了解BIBFRAME应用进展的最佳来源。第3次年会将于2019年9月17-18日在瑞典国家图书馆举办。

European BIBFRAME Workshop 2017 (2017.9.26-27,法兰克福德国国家图书馆)【会议报告
2017年会议成果:《对ILS投标者的BIBFRAME期望》(BIBFRAME Expectations for ILS Tenders, 2018-02)
会前介绍博文:BIBFRAME在欧洲启动?2017欧洲BIBFRAME研讨会(2017-5-18)

European BIBFRAME Workshop 2018 (2018.9.17-19,意大利,Casalini Libri & European University Institute)
2018年会议成果:《就RDA与BIBFRAME致信RDA指导委员会》( Letter to the RDA Steering Committee about RDA and BIBFRAME, 2018-12-13)
会议报告【一句话概览】
培训1:BF入门
培训2:宏观
培训3:Casalini的BIBFRAME项目/SHARE VDE
培训4:转换和调和
培训5:瑞典联合目录Libris XL采用BIBFRAME2为主的本体KBV,用MarcFrame转换到JSON-LD
培训6:开源关联数据编辑器CEDAR
培训7:LC的BIBFRAME编辑器
培训8:PCC的ISNI试验项目(2017.7-2018.7)
报告1:BIBFRAME开发(Pilot 2)
报告2:LD4P状态更新
报告3:语义网在匈牙利国家Széchényi图书馆
报告4:加拿大BIBFRAME现状 [貌似没做什么]
报告5:生产中的BIBFRAME:瑞典联合目录Libris XL
报告6:用BIBFRAME的匈牙利通用目录
报告7:SHARE-VDE:项目如何满足BIBFRAME模型
报告8:乔治华盛顿大学实验:1 Schema.org的Action,2 MARC中URI
报告9:芬兰国家图书馆通过BIBFRAME转换到Schema.org/对转换程序的评价
报告10:图书馆关联数据的3个选择:BIBFRAME 2.0,,Schema.org,链接MARC,提出BF到schema映射项目
报告11:截屏1997年FRBR开始的历年重要文件、模型、PPT
报告12:PCC自2015年起为关联数据所做准备
报告13:MARC转换到BIBFRAME过程中书目家族抽取评估
报告14:PCC任务组:URI、BIBFRAME
报告15:FOLIO [更像是拉客广告]
报告16:重用作为缓存

2018 EBW:就RDA与BIBFRAME致信RDA指导委员会

$
0
0

2018年欧洲BIBFRAME研讨会(EBW),与会者80人,来自17个欧洲国家及美国、加拿大和卡塔尔。作为会议成果,在2018年12月发出了一封给RDA指导委员会(RSC)的信,由丹麦皇家图书馆Leif Andresen署名,代表EBW组委会7人(其中包括负责BIBFRAME开发的美国国会图书馆网络和MARC标准办公室主任的Sally H. McCallum)。截至2019-4-3,RSC官网消息中未见回应——RSC通常每年11月举行年会,2019年预定在智利首都圣都亚哥。
参见:
会议网站:European BIBFRAME Workshop 2018 (2018.9.17-19)
介绍博文:欧洲BIBFRAME研讨会(2019-3-29)

—— 就RDA与BIBFRAME致信RDA指导委员会(译文) ——
Letter to the RDA Steering Committee about RDA and BIBFRAME (2018-12-13)

在Fiesole今年的欧洲BIBFRAME研讨会*期间,一再明确RDA用户和BIBFRAME用户之间存在很大的重叠。自其构想以来,RDA已经允许实施关联数据,现在其实现比以往任何时候都更加明显。在这种情况下,必须评估RDA和BIBFRAME之间的关系,以便允许使用两种标准的全部潜力
到目前为止,大多数RDA实现都基于MARC 21格式,而MARC21很可能会被BIBFRAME取代。我们正在迅速接近这一时刻,即RDA需要被BDAFRAME所用,或者和MARC格式同时、或作为MARC格式的替代品。然而,MARC 21和BIBFRAME都无法满足RDA的全部粒度——前者因为是在RDA之前的世界中建立的,后者是因为[RDA]范围超出了专门的图书馆应用。
BIBFRAME的概念模型与FRBR或IFLA LRM并不完全一致,而IFLA LRM确实构成了3R后工具包的基础。同样,RDA关注解析(粒度)和记录选项,而BIBFRAME关注关系和链接,已经迫使BIBFRAME实施要仔细评估其数据模型的某些粒度和方面的目的和必要性。 RDA描述要包括在描述中的数据,但不一定建议单独识别每个元素。在BIBFRAME中容纳RDA元素有很多选项,例如扩展,或者只选择那些已经很容易表示的元素。当然,在BIBFRAME研讨会期间,许多参与者心中的问题是:我们如何能够在原生BIBFRAME环境中实施RDA
新兴的BIBFRAME社区希望与RSC建立一个工作组,为在BIBFRAME内推荐的RDA表示制定一套指南。虽然这些指南不能是规定,但它们会代表一种标准化方法,既能确保图书馆之间最简单的数据交换,又能确保供应商可以建立服务的稳定表示。
我们期待听到RSC对这种方法的反应,并解决这个问题,以改善我们社区的两个部分。

2017 EBW:对ILS投标者的BIBFRAME期望

$
0
0

关于欧洲BIBFRAME研讨会(EBW),参见:
欧洲BIBFRAME研讨会(2019-3-29)
2018 EBW:就RDA与BIBFRAME致信RDA指导委员会(2019-4-2)
[update,对本文件的反馈: 对《对ILS投标者的BIBFRAME期望》的意见(2019-4-3)]

2017年欧洲BIBFRAME研讨会上讨论了对集成图书馆系统(ILS)实现关联数据模型的要求,尤其是应用BIBFRAME。由此2018年EBW组委会要求Tiziana Possemato(意大利数据/系统厂商 Casalini Libri – @cult)草拟规范《对ILS投标者的BIBFRAME期望》,作为2017 EBW成果。文件提出了ILS转向BIBFRAME/关联数据的不同级别,可作为招标需求。其中ILS主要指其编目模块,共定义了3个类型、逐步过渡到关联数据环境的10个级别。以下摘译“ILS的BIBFRAME一致性级别”部分。
注:其中提到主/从(技术):“一种通信模型,其中一个设备或进程对一个或多个其他设备具有单向控制。 在某些系统中,从一组符合条件的设备中选择一个主设备,其他设备扮演从设备的角色”

EBW-ILS

—— 对ILS投标者的BIBFRAME期望(摘录) ——
BIBFRAME Expectations for ILS Tenders (2018-02)
ILS的BIBFRAME一致性级别

以下一致性级别可分为三种不同类型:
a. 元数据生成/维护:1-8级
b. 发现:9级
c. 文档化/未来能力:10级
当图书馆提供更加成熟和明确的要求时,将来可以改进这些类型组中的每一个。

1. 第一级(入门级):ILS需要管理格式并能够生成“做得好”的数据(这意味着高质量的MARC数据),准备转换为BIBFRAME。该系统仍然处于传统环境中,但供应商已经改进了编目标准或格式,使传统MARC记录更易于转换。这些功能的一些示例是:
 管理对数据转换为BIBFRAME有用的属性和关系的可能性;
 使用RDA条款和指南进行编目的可能性;
 使用URI管理和丰富MARC记录的可能性;
 管理ILS级别的书目和规范记录之间的链接、使转换变得更加容易的可能性,因为系统确保了链接的一致性。
通常,任何提高数据质量的功能都有助于以后的转换。在这种情况下,编目模块完全面向记录

2. 供应商可以提供转换工具,能够转换为各种模型,包括BIBFRAME(从MARC/MODS …格式到关联数据),不包含在ILS中,但可用于转换数据。在这种情况下,编目模块完全面向记录,之后实现到BIBFRAME的转换。关系数据库为主、三元组库为从。

3. 供应商可以提供连接到ILS的BIBFRAME转换器:这意味着一次性实现海量数据转换,但系统应允许逐个记录RDF(BIBFRAME)数据集的更新。此外,系统应允许更新已经采用RDF格式的数据。在这种情况下,编目模块仍然完全面向记录,之后实现了对BIBFRAME的转换。关系数据库为主、三元组库为从。这两个环境应保持一致。这将使数据作为关联开放数据提供给外部应用程序以供使用。

4. ILS便于使用BIBFRAME编辑器,以在BIBFRAME中创建和编辑数据。供应商提供API层以将RDF数据转换并下载到关系数据库中(以传统格式)。在这种情况下,数据变为面向实体,并且它们被转换为传统格式,以允许使用传统数据的其他服务(用于流通等)。在这种情况下,主/从关系由“编辑器”确定(它可以有一个存储系统)。这将使数据作为关联开放数据提供给外部应用程序以供使用。

5. ILS有自己的BIBFRAME接口(在图中称为GUI),因此编目不再是面向记录的,而是面向实体的。系统在两个环境中同时管理两个不同的数据库(关系和三元组库)和每个编目操作(发出 – 编辑 – 删除 – 获取)更新。在这种情况下,主是三元组库,从是关系数据库。

6. 系统允许原始编目在RDF/BIBFRAME环境中进行。编目过程完全是面向实体的(关联开放数据环境);供应商提供API/Web服务以将系统与传统系统连接(转换和管理来自传统系统的数据)。没有必要拥有平行的传统环境,但图书馆希望与现有的传统环境保持联系。

7. 系统允许原始编目在RDF/BIBFRAME环境中进行。编目过程完全是面向实体的(关联开放数据环境),整个ILS很可能在RDF中生成和管理数据[或者情况可能并非如此,但这种情况不属于本文档的范围] 。没有理由拥有并行环境,因为完全实现了向新的关联开放数据环境的过渡。

8. 供应商将确保前面提到的工具/技术将考虑BIBFRAME的演变;特定组件将更新吸收BIBFRAME模型和词汇表中的更改,通过… [定义特定时间,例如从新BIBFRAME版本发布后一年]。

9. 供应商将提供一个发现工具,该工具能够为BIBFRAME提出的实体关系模型提供证据。面向OPAC/面向BIBFRAME的发现系统的详细信息需要本文档的另一部分(或其他特定文档)。就OPAC/发现工具而言,此列表并未全面展示前端系统的可能演变。如果没有以前的级别,则该级别不被视为更高级别的合规性,而是较低级别的合规性。

10. 供应商必须确保共享所有项目文件(技术和实践),以便将来在供应商的专属领域之外管理系统。

对《对ILS投标者的BIBFRAME期望》的意见

$
0
0

2018-8-22 德国国家图书馆 Lars Svensson 在BIBFRAME邮件组中,针对2018年2月《对ILS投标者的BIBFRAME期望》提出意见,认为应当提出“功能需求”而不是“技术要求”,并参考2013年BIBFRAME用例与需求,从不同方面举例。

原文件参见:2017 EBW:对ILS投标者的BIBFRAME期望(2019-4-3)

—— 对《对ILS投标者的BIBFRAME期望》的意见 ——
[BIBFRAME] Some comments on “BIBFRAME Expectations for ILS Tenders” / Lars Svensson (2018-8-22)

……我认为该文所采取的总体方向存在一些问题。我觉得它主要关注技术而功能要求太少。本文建议过渡,从范式(1)其中编目在MARC记录中直接完成,并且图书馆集成库系统(ILS)使用关系数据库(RDBM)存储编目和任何相关联的数据存储到另一范式(2)其中编目在RDF中完成(使用BIBFRAME数据模型),ILS使用三元组库来存储必要的信息。我想说的是,第一个假设未必是真实的(有相当长的一段ILS其中数据不使用RDBM存储,至少一些图书馆编目不通过创建或编辑MARC记录,但使用其他元数据格式,如果需要可以转换为MARC)。我还要说,对新系统范式的建议过于狭隘,甚至可能通过强制要求使用哪种技术来阻碍创新。例如,有一种称为图数据库的新兴技术,它允许以有趣的方式分析图中的数据,包括找到两个节点之间的最短路径,找到“孤岛”(图或子树未连接到图的任何其他部分)或松散连接的子树(例如仅由一条边连接的子树)。如果我们要求使用三元组库,则供应商将无法使用此技术,因此将失去实现有趣统计功能的可能性。在我看来,招标应该尽可能技术中立(至少在系统内部方面)。

那么招标要包含什么呢?
我的看法是它应该指定所需的功能。毕竟,有趣的是我们希望系统做什么(或者至少我们想要对系统做什么)。对于基于关联数据的系统,我能想到的非详尽列表将是【引用2013 BIBFRAME使用案例与需求,参见:BIBFRAME使用案例与需求(2014-10-26)】

– 系统必须能够以下列格式导入图书馆数据:
— MARC 21(多半有不同风味)【比如:德国的没有ISBD标识符?LC较少用连接字段?】
— 使用BIBFRAME数据模型的RDF
— 使用RDA数据模型的RDF
— …
– 系统必须能够以下列格式导出数据:
— MARC 21(多半有不同风味)
— 使用BIBFRAME数据模型的RDF
— DC-XML(用于OAI-PMH)
— …
– 系统必须支持下列导入和导出接口:
— SRU/SRW
— OAI-PMH(双向同步)
— Z39.50 😉
— W3C WebSub(确保系统是Web的)
— …
– 编目模块必须允许编目员:
— 将题名和规范连接到驻留在本地系统中的其他题名和规范(例如,连接出版物与其继承者或作者;连接作者与其出生地、出生地与其所属国家)
— 将题名和规范连接到驻留在联机数据库中的其他题名和规范(可能要求系统必须支持的搜索界面列表)
— …
– 系统必须允许管理者:
— 配置数据录入表单,如限制编目员可以使用哪个规范档
— 以标准化格式导入和导出数据录入配置和元数据纲要(可能说明此种格式清单,如SHACL, ShEx, JSON Schema, XML Schema……)
— 无缝包含第三方数据库(IEEE Xplore, EconBiz, PubMed, ………)到最终用户检索中
– 系统必须允许最终用户:
— 使用单一、统一搜索界面搜索图书馆内部内容和第三方数据库
— 导出书目引文到第三方引文管理系统
— 对匹配定制搜索的新内容订阅RSS/Atom源【推送】
— …
对我,此方法的优点是:
1) 客户需要考虑他们真正希望系统做什么
2) 供应商可以专注于以舒适的方式实现此功能,而不必专注于新技术。

Karen Coyle与Lars进行了一番互动,认为在关联数据的讨论中缺少内容:要做哪些链接?由此Lars对需求作了补充:
这让我想到了另一个重要的要求,我通常认为这是理所当然的,但这可能需要明确:
系统必须为系统中管理的所有实体公开可解引的URI。管理员还必须有一种方法可以为所有或某些类型的实体(例如,不得共享的资源)禁用此功能


RDA与BIBFRAME对话

$
0
0

RDA的理念之一是格式中立,不与特定元数据格式绑定。但由于目前编目主要采用MARC,因而与MARC的映射仍是RDA附录的重要内容。随着计划取代MARC的BIBFRAME开发逐渐进入应用阶段,如何让RDA能顺利地应用于BIBFRAME成为关注点。

在模型和元素层面,RDA和BF两者其实有很大差异。RDA遵循FRBR/LRM,采用4层WEMI模型,BF是3层。RDA采用LRM的实体和属性,类少、元素多,BF的类则几乎于属性数量相当。编目时似乎用类还是属性不是什么问题,毕竟BF编辑器提示用的就是RDA元素,但在技术层面实现时,估计会有各种问题——这是我个人的猜测。

作为2018年欧洲BIBFRAME研讨会的后续,在刚结束的2019年ALA年会上,RDA指导委员会(RSC)代表和欧洲BIBFRAME研讨会组委会进行了一场对话,涉及RDA和BF的关系及互操作,确定将开展短期和长期任务、并将继续开会和讨论。

此消息由美国国会图书馆网络开发与标准办公室(LC/NDMSO)主任Sally H. McCallum在BF邮件组中发布,并说明欧洲BIBFRAME研讨会组委会成员包含美国的国会图书馆网络开发与标准办公室、LD4P和Share-VDE。消息在RSC网站上也有发布。

比较有意思的是,多年来两家开发方一直没有公开的直接对话——而LC本身除了是BF唯一主导开发者,也是RDA开发的重度参与者。两条消息的标题差异似也耐人寻味。

RSC新闻:Conversation between RSC and BIBFRAME (2019-7-15)

BIBFRAME邮件组:Conversation about relationship between RDA and BIBFRAME / McCallum, Sally(2019-7-16)

参见:欧洲BIBFRAME研讨会(2019-3-29)

2019 ALA年会BIBFRAME更新论坛

$
0
0

前几天发现在今年ALA年会上召开的BIBFRAME更新论坛PPT已经上线:

BIBFRAME Update Forum at the ALA Annual Conference 2019 (2019-6-23)

本次会议共5个报告,第1个按惯例是LC介绍BIBFRAME进展;本次后2个是LD4P项目介绍,其一是Sinopia关联数据编辑器,其二是外部数据访问(规范查找服务);第4个是一直不曾缺席的OCLC报告;第5个是厂商Innovative。所有报告的PPT标题与页面所示标题均有出入(报送题名与最终题名的差异吧)。

一、LC

Library of Congress BIBFRAME File Access and Pilot (PPT, 225 KB) / Sally McCallum, Library of Congress

【PPT标题】LC Update: File access / Pilot expansion(LC更新:文档获取和试验扩展)【介绍】

首先以“活动爆发”为题总结BIBFRAME最近4个方面的现状:

(1)LD4编辑器(Sinopia)把超过17个机构带入BF环境

(2)SHARE-VDE(来自意大利厂商Casalini)使超过22个机构看到/感受到其记录作为BF描述。

(3)Innovative公司正在实验BF发现

(4)LC公开提供其BF作品/实例/单件文档(文档获取),并增加50多个编目员到项目中(试验扩展/做原编)

然后详述LC在两方面的进展:文档获取和试验扩展

【文档获取】BF作品和实例文档现在通过LC的关联数据服务提供(id.loc.gov),包含整个LC书目记录+题名规范+馆藏,含1900万MARC书目+120万题名规范。提供3种RDF格式(RDF/XML,N-triples,JSON),有详细(含数据字符串)和紧凑(只含数据URI)2种。

【试验扩展】增加57名编目员,在7月进行培训,9月期望有107名编目员(2017.6试验开始时称有60名,看来之后仅50名)。新增编目员包括10名非书媒介领域(录音、乐谱、地图)和10名来自LC在世界其他地区的办公室(非洲的开罗、内罗毕,亚洲的伊斯兰堡、雅加达)。

秋季将实施“BIBFRAME到MARC的转换”——这是LC不再做MARC编目前必须完成的任务,提到转换涉及的一些问题,比如“题名规范”(要为所有作品编制题名规范记录吧)。

二、LD4项目

2、LD4’s Sinopia BIBFRAME Editor (PPT, 24 MB) / Jeremy Nelson and Josh Greben, Stanford University

【PPT标题】Introducing Sinopia【功能演示】

Sinopia是LD4P项目,开源的协作关联数据编辑环境,运行于亚马逊网络服务公共云(https://sinopia.io)。Sinopia设计不限于特定词表(如BIBFRAME),而是通用的关联数据编辑和发布平台。项目始于2018年秋,正结束其第一个工作周期,接下来数月即将发布一个最低可行产品(MVP)【2019-8-9发布1.0版】。本报告主要是截屏演示使用Sinopia编辑器。

3、Questioning Authority (QA) Data Access (PDF, 2.9 MB) / Lynette Rayle, Cornell University; Dave Eichmann, The University of Iowa

【PPT标题】Authority data: the good, the dirty and the semantic(规范数据:好的、脏的和语义的)【技术实现细节】

QA是LD4P项目,用于支持从各个规范库访问受控词表,包括在Sinopia编辑器中应用等。报告很技术,包括架构、为什么对部分来源要用缓存以及如何处理,等等(总之我看不懂)。代码入口:https://github.com/ld4p/qa_server;试用:https://lookup.ld4l.org。

使用的关联数据规范库:AGROVOC, DBPedia, GeoNames, LOC (Demographics, Genres, Names, Performance, Subjects), MeSH, NALT [?], OCLC FAST, Wikidata, ISNI

三、OCLC

4、OCLC Current BIBFRAME Activities (PPT, 10 MB) / Nathan Putnam, OCLC(元数据质量部主任)

【PPT标题】OCLC BIBFRAME Update

首先介绍OCLC的“关联数据原型”:2017.12-2018.9,16个成员馆参与,120万实体、含来自wikidata、VIAF和WorldCat的数据——详细报告即将发布。

关于在WorldCat中启用BF:OCLC研究部实验LC的BF转换程序,使用FAST、VIAF及其他URI以防止空白节点、确保互操作性,为作品和载体表现使用WorldCat集群ID。

表达OCLC的立场:(方法)建立在WorldCat的基础上,与社区领导者协作并合作,进行迭代进步而不是等待完美。(关联数据)为图书馆创建新功能,以各种格式导入、存储、丰富和发布关联数据,包括BIBFRAME和Schema.org。(MARC)支持希望继续在MARC工作的图书馆。

最后给了《OCLC与关联数据》宣传小册子链接。

四、III公司

5、BIBFRAME Discovery at Innovative Interfaces (PDF, 752 KB) / Martha Sanders, Innovative Interfaces

【PPT标题】BIBFRAME-BASED DISCOVERY @ INNOVATIVE

6月初公布会议日程时并无Innovative报告,一周后日程更新时加入。报告演示该公司产品的可视化界面(从截屏上未见涉及BF);以及更多的打算(如与Wikidata和其他外部数据源集成)。意义在于表示厂商的积极参与态度吧。

《BIBFRAME手册》之编辑器和数据库

$
0
0

美国国会图书馆(LC)2019年7月发布的BIBFRAME手册《BIBFRAME编辑器和BIBFRAME数据库》,主要面向使用BIBFRAME编辑器的编目员。

Library of Congress BIBFRAME Manual: The BIBFRAME Editor and BIBFRAME Database. Prepared by Policy, Training, and Cooperative Programs Division, Library of Congress. 2019. 113 pages

手册后附词汇表,含术语及解释。以下列出所有术语及部分解释(BF=BIBFRAME),备查(特别关注:Clone, Field, Stub)。

  • Administrative Metadata / 管理元数据
  • BIBFRAME Database / BIBFRAME数据库(存放所有BF描述的数据存储)
  • BIBFRAME Editor / BIBFRAME编辑器(编目员用BF描述资源的界面)
  • Clone / 克隆(BF编辑器配置文件中的一个功能,编目员可以为一个资源集设置标准化描述,共享相似数据)
  • Data Boxes / 数据框(显示在一个字段中输入的特定数据的框)
  • Dereferencable URI / 可引用URI(是一种资源检索机制,它使用HTTP来获取其标识的资源的副本或表示形式。 如果语义Web数据是根据最佳关联数据实践发布的,则标识Thing的URI与标识描述Thing的Web文档的URI不同)
  • Description / 描述
  • Dialog Field / 对话框字段
  • Direct-Entry Field / 直接输入字段
  • Fields / 字段(输入编目数据的模板上的单独空间)【与MARC不同的含义,是否应当用不同的翻译?】
  • Field Edit Buttons / 字段编辑按钮(“笔”修改数据;“垃圾筒”删除数据)
  • ID.LOC.GOV / LC关联数据服务
  • Instance / 实例
  • Internationalized Resource Identifier (IRI)
  • Item / 单件
  • JSON-LD(BF编辑器中,用JSON-LD序列化编目员输入的描述)
  • Linked Data / 关联数据
  • Lookup / 查找(亦称“自动完成”)
  • Post / 发布(BF编辑器功能,用于发送完成的资源描述到BF数据库)
  • Profile / 配置文件(创建资源或概念描述的在线模板。在BF编辑器2.0中有:专著,乐谱,连续出版物,地图,录音:音频CD、录音:音频CD-R、录音:模拟、录音:卡带,动态图像:蓝光DVD,动态图像:35mm胶片,珍稀资料)
  • Resource Description Framework (RDF) / 资源描述框架
  • Resource Template / 资源模板(BF编辑器的构建块。 资源模板描述与给定配置文件关联的各种资源之一,如:作品、实例、单件、标识符、语种等)
  • Semantic Web / 语义网
  • Stub / 存根(从MARC书目7XX题名生成的BF作品。软件会检查BF文档中是否存在现有作品以建立链接,但如果找不到题名,则软件会使用其所有的(仅题名或作者/题名)做一个非常简短的作品描述。这些在BF数据库中以“来自书目的作品存根”进行标识)
  • Template / 模板(可以对BF配置文件进行个性化修改,以简化资源描述)
  • Triple Statement / 三元组陈述
  • Uniform Resource Identifier (URI )
  • Web of Data / 数据网(“语义网”的松散同义词)
  • Work / 作品
  • Workspace / 工作空间(BF编辑器的区域,可以在其中使用对话框、自由文本字段、菜单、按钮和查找功能来创建BF记录。 此外,“浏览”链接会将您带到保存BF记录的工作区)

附手册目次:

  • Unit 1: Getting Started 入门(BIBFRAME,ILS,BF编辑器)
  • Unit 2: BIBFRAME and Linked Data(关联数据,数据网,RDF,三元组陈述,URI/IRI,词表和本体)
  • Unit 3: Searching(查BF数据库,用BF编辑器查,查LC规范档/LCSH及其他规范)
  • Unit 4: Introduction to ID.LOC.GOV, the Library of Congress Linked Data Service LC关联数据服务导论
  • Unit 5: Templates(创建模板,克隆作品或实例)
  • Unit 6: Creating a New Work and Instance 创建新作品和实例
  • Unit 7: Adding a New Instance to an Existing Work 添加新实例到现存作品
  • Unit 8: Importing Descriptions from the BIBFRAME Database 从BF数据库导入描述
  • Unit 9: Preview and Post 预览和发布
  • Unit 10: Workflows 工作流程
  • Unit 11: Non-Latin Scripts 非拉丁文字
  • Glossary 词汇表
  • Help, Support, and Other Resources(限员工访问网址)

2019欧洲BIBFRAME研讨会

$
0
0

欧洲BIBFRAME研讨会(EBW)始于2017年秋,此后成为年会。2019年第三届于2019/9/17-18在斯德哥尔摩瑞典国家图书馆举办,有来自20个国家的93人参会。2020年第四届原定在匈牙利国家图书馆召开,不知到秋天COVID-19是否能消减而正常召开。

瑞典国家图书馆(KB)作为第三届的举办单位有多个报告,介绍他们的Libris XL,可以说是首个正式使用的基于BIBFRAME的联合目录系统。意大利厂商Casalini-@Cult的Tiziana Possemato也有多个报告,他本人及其他人的报告中频繁出现Share-VDE,是既有应用、又在发展中的系统。另外,美国国会图书馆(LC)及LD4P的斯坦福等也有多个报告,涉及不同方面。

第2天的报告分为五个方面,有说明语,体现当前本领域的关注点:关注身份、关注[数据]更改、关注基础架构、关注关系、关注编辑器。

European BIBFRAME Workshop 2019. National Library of Sweden, Stockholm, September 17 and 18, 2019

以下为本次会议报告一览及简介,题名按PPT修改(与会议报告面页不尽一致)。

(第一天)

  • BIBFRAME expansion and access / Sally H. McCallum, LC // BIBFRAME:扩展与获取【BIBFRAME进展】
  • LD4P: Pathway to Implementation / Philip E. Schreur, Stanford, LD4P // LD4P:实施之路【LD4P项目,以及下一个项目(发现,自持续PCC数据池,扩展Sinopia,扩展询问规范,扩展培训计划)】
  • National library platform based on BIBFRAME / Niklas Lindström, KB // 基于BIBFRAME的国家图书馆平台【瑞典国家图书馆基于BIBFRAME2.0的联合目录系统Libris XL】
  • Possible extensions of BIBFRAME in modelling data / Tiziana Possemato, Casalini-@Cult // 建模数据中BIBFRAME的可能扩展【Share-VDE超级作品,如何在共享环境中管理实例】
  • RDA and BIBFRAME at the Library of Congress / Sally H. McCallum and Jodi Williamschen, LC // 美国国会图书馆的RDA和BIBFRAME
  • RDA WORKS IN BIBFRAME & SINOPIA PROFILES / Nancy Lorimer, Stanford // BF和Sinopia配置文件中的RDA作品【LD4P的BIBFRAME编辑Sinopia如何处理作品/内容表达】
  • Working with BIBFRAME at the National Library of Sweden / Fredrik Klingwall, KB // 瑞典国家图书馆与BIBFRAME共舞【Libris XL词表,基于BF2】
  • Opus Ex Machina: Modelling SuperWork, Work, and Instance Entities in BIBFRAME / Ian Bigelow, University of Alberta // Opus Ex Machina:在BIBFRAME中建模超级作品、作品和实例实体【Share-VDE的作品ID工作组;超级作品,对应BF的Hub】
  • Community-building and Extending BIBFRAME for Special Collections: the Art & Rare Material BIBFRAME Ontology Extensions and the LD4P Rare Materials Affinity Group / Jason Kovari, Cornell 等 // 为特藏社区建设与扩展BIBFRAME:艺术和珍稀资料BIBFRAME本体扩展和LD4P珍稀资料亲和小组【LD4P的本体ARM(ArtFrame和RareMat)和LD4P珍稀资料亲和小组(RM-AG)】
  • BIBFRAME Agent data from MARC authority records – is it an unnecessary redundancy? / Miklós Hubay, National Széchényi Library Hungary // 从MARC规范记录中获取的BIBFRAME施事者数据——不必要的冗余?【BF1到BF2对规范的处理。MARC$0问题?】
  • Linked Data in the LSP * FOLIO and Linked Open Data * Reality, Speculation, Provocation / Charlotte Whitt, Index Data // 图书馆服务平台中的关联数据:FOLIO和关联数据【Index Data自我介绍及FOLIO概述】
  • PCC Task Group on Metadata Application Profiles / Jackie Shieh, Smithsonian // PCC元数据应用配置文件任务组【元数据应用配置文件简称MAP】
  • RERO THROWN INTO BIBFRAME / Nicolas Prongué, RERO //【介绍瑞士公司应用BIBFRAME情况及问题】
  • Challenges on transforming data in RDA vocabulary to BIBFRAME / Michalis Sfakakis, 希腊爱奥尼亚大学 // 转换RDA词表数据到BIBFRAME的挑战【因RDA的4层与BF的3层模型导致的BF虚假关系问题】
  • The Relevance of BIBFRAME Beyond our Walls / Richard Wallis // BIBFRAME超越壁垒的意义【Richard Wallis的第一天小结发言:认为BF在图书馆界之外缺乏相关性,需要与schema.org结合,呼吁参与似乎颇为冷清的W3C的BIBFRAME2Schema.org社区小组】

(第二天)

Panel 1: Concerning Identities 关注身份

我们谈论的是一个新环境,在该环境中我们可以扩展我们的资源来管理身份,特别是名称规范。我们想使用哪些来源? Wikidata? ISNI?NACO?// 例如,当我们指向包含20个标签的VIAF资源时,它如何工作?机构是否仍具有本地规范档?这是否意味着该机构应该托管一个类似于ID.LOC.GOV或DATA.DNB.DE的小型关联数据网站?// 规范描述是否仍需要遵循特定规则来构建规范检索点?如果规范位于本地系统之外,如何执行规则?是否需要服务中心来维护描述以及描述所需的URI?有没有免费的服务?所有描述都驻留在“本地”文件中还是有些保留在带有链接的其他站点上?// 当机器使用标识符运行时,人们需要标签:标签缓存如何适合图片?是否有服务收集使用的不同文件,而不是将所有内容存储在本地?本次会议不为讨论RWO(真实世界对象)、标识符和名称标签。真正的问题是在公共环境中工作。

  • The Cluster Knowledge Base approach to identities management / Tiziana Possemato, @Cult-Casalini Libri // 集群知识库身份管理方法【Share-VDE的集群知识库Sapientia】
  • Concerning Identities: For Things, but not the easy Things [Contains Hubs Part I] / Kevin Ford, LC // 关于身份:针对事物,但不是简单事物(含Hub 第1部分)【BF的Hub】

Panel 2: Concerning Changes 关注更改

在当前环境中,我们有不同的方式来提供更改并将更改应用于资源描述。如何将其转换为RDF/三元组存储环境? 我们是否需要表示已对他人使用的描述进行了更改? 如果是这样,存在什么策略,或者我们可能考虑将更改传达给下游消费者?// 我们是否需要在本地或共享系统中显示三元组的出处? 记录谁做出了更改会成为三元组/断言的挑战? 是否有本地跟踪的更改以及共享的其他更改?// 哪些类型的更改需要通知,例如标签更改,主题的添加/删除或仅在资源更改时通知? 是否需要修改本地系统和本地实践?

  • BIBFRAME CHANGE MANAGEMENT / Nate Trail, LC // BIBFRAME对变化的管理【基于图的方法处理更改】
  • Use case implications for change / Tiziana Possemato @Cult-Casalini Libri // 更改的用例含义【创建、更新、删除实体。Share-VDE的集群知识库(CKB)维护工作组】

Panel 3: Concerning Infrastructure 关注基础架构

为了支持RDF/关联数据,我们需要提供描述和URI的基础架构。例如,美国国会图书馆已将http://id.loc.gov内置到数据源中,以帮助在我们的BIBFRAME数据库中添加URI,并支持用于创建描述的查找和其他助手。虽然LC已使其他人可以访问ID,但我们希望任何机构或网络都需要使用自己的此类工具版本来支持描述创建和检索。 其他人如何处理此基础架构需求?

  • Running the Sinopia Stack on Amazon Web Services / Jeremy Nelson // 在亚马逊Web服务上运行Sinopia【原链接误为作者另一报告】
  • LC BIBFRAME INFRASTRUCTURE / Nate Trail, LC // LC的BIBFRAME基础设施【如何让LC关联数据服务、BIBFRAME编辑器、BIBFRAME数据库一起工作】
  • Finto service for controlled vocabularies as a component of Linked Data cataloging / Osma Suominen, 芬兰国家图书馆 // 作为关联数据编目组成部分的受控词表Finto服务

Panel 4: Concerning Relationships 关注关系

关系是新环境的基石。在机构或网络中,如何处理它们?机构内外资源之间的关系如何处理?其他机构是否看到需要诸如Hubs(美国国会图书馆)或Superworks(Casalini)之类的总体收集设备的需求?此链接的主要组成部分是什么?// 将旧数据从MARC转换为BIBFRAME并(可能)转换回MARC的挑战是什么?

  • Performances and Works: THE INTERACTION OF WORKS AND EVENTS IN MODELING SOUND RECORDINGS IN BIBFRAME & PMO / Nancy Lorimer, Stanford // 表演音乐中的事件和作品和关系【表演音乐本体(PMO)扩展BF,BF事件模型。Sinopia的相关模板】
  • Concerning Relationships: Hubs Part II / Kevin Ford, LC // 考虑关系:Hub 第2部分【Hub的MARC来源,及作为聚合器的3个功能(主题、相关作品、RDA意义的作品)】
  • SuperWorks, MasterInstance and relationships / Tiziana Possemato, @Cult-Casalini Libri // 超级作品、主实例和关系【Share-VDE咨询委员会及子委员会正讨论发展Share-VDE实例由描述到实体】
  • Extensions for past and future relationships / Fredrik Klingwall, KB // 为过去和未来关系扩展【个人名称的呈现问题】

Panel 5: Concerning Editors 关注编辑器

创建和修改Bibframe描述的编辑器是移至BIBFRAME环境所需的主要开发。在这种新环境中,哪些附加功能将有助于编目人员有效而丰富地描述图书馆资源?// 我们是否必须逐个编辑RDF资源,这对于编目员来说可能效率低下,还是我们可以通过RDF图来编辑,这在技术上更具挑战性? 如果按图显示,确定要加载到编辑器中的图的范围以及如何将其保存回来(即删除/替换已编辑的图)有哪些挑战?// 配置文件的最佳用途是什么? 对属于与编辑配置文件不匹配的图的描述性元素(三元组)怎么处理? 编辑始于MARC且因此没有明确配置文件的描述有哪些复杂性?

  • Sidestepping the graph – Sinopia Linked Data Editor’s approach for editing RDF / Jeremy Nelson // 回避图——Sinopia关联数据编辑器的编辑RDF方法
  • Editing JSON-LD at the National Library of Sweden : copying from Fredrik, Ola et al / Niklas Lindström // 在瑞典国家图书馆编辑JSON-LD【编辑命名图为JSON-LD,使用应用本体、Lens和2种b节点(内容确实复制自其他PPT)】

前两届会议介绍博文:

Hub:BIBFRAME模型下的超级作品

$
0
0

众所周知,在BIBFRAME2.0模型中,书目资源为三层三个核心类(作品——实例——单件)。一般认为BF2的“作品”对应于《IFLA图书馆参考模型》(LRM)和《资源描述与检索》(RDA)的四层模型中的“作品+内容表达”,但实际上LRM/RDA的内容表达与作品间关系、作品与作品间关系,在BF2中难以区分,汇集LRM/RDA作品也是一个麻烦事。因此有“超级作品”之议。

前些日子看2019年欧洲BIBFRAME研讨会的报告(参见:2019欧洲BIBFRAME研讨会,2020-6-16),注意到多个报告中提到BIBFRAME在作品之上新增了Hub,对应Share-VDE中定义的超级作品SuperWork——如此几种模型就都是四层了。

不过,目前BIBFRAME词表(BIBFRAME Ontology)中并没有看到Hub类,在会议报告【以下报告三】示例中提到的LC的BIBFRAME扩展bflc中也没有找到,因而定义不明。

但是,在LC的关联数据服务(id.loc.gov)中,BIBFRAME的检索范围有三种:BIBFRAME Works、BIBFRAME Instances和BIBFRAME Hubs。搜索结果的侧栏分面,Scheme下有BIBFRAME Hubs,Type中也有Hub,可见在数据层面广泛应用此区分。

在结果一览中,“词表”栏取值有BIBFRAME Hubs,不过此时“概念”栏取值为Work而不是Hub。以查“Shakespeare, William”为例:

  • Scheme分面(=命中数):BIBFRAME Hubs=1413,BIBFRAME Works=7323
  • Type分面(=命中数):Hubs=1413,Works=8736

主要相关报告:

一、美国国会图书馆的RDA和BIBFRAME(RDA and BIBFRAME at the Library of Congress / Sally H. McCallum and Jodi Williamschen, Library of Congress)

报告人Sally H. McCallum是美国国会图书馆(LC)网络开发和MARC标准办公室(NDMSO)主任,该办公室负责BIBFRAME开发。这个报告不但未提及Hub,反而仍强调BF“灵活使用作品/内容表达”,即作品和内容表达合一,因为大多数资源是一次性的;处理多媒体、特别是唯一资源时作品/内容表达识别有问题。

二、Opus Ex Machina:在BIBFRAME中建模超级作品、作品和实例实体(Opus Ex Machina: Modelling SuperWork, Work, and Instance Entities in BIBFRAME / Ian Bigelow, University of Alberta)

报告人所在图书馆应当是参与Share-VDE相关工作。报告中用“Opus”(作品)作为书目资源顶层实体的名称,以避免“Work”的多义性:Opus = BF的Hub = Share-VDE的SuperWork = LRM/RDA的Work。据称2019年1月Share VDE数据中引入超级作品类,2019年ALA年会前LC引入Hub到他们的数据。

三、关于身份:针对事物,但不是简单事物(含Hub 第1部分)(Identities for hubs, providers, and other things / Kevin Ford)

四、考虑关系:Hub 第2部分(Hubs and managing relationships / Kevin Ford)

报告人Kevin Ford是LC的NDMSO开发人员,应该是BF数据处理的实际执行人。在两个报告中专门讲述Hub:

启用Hub理由:1、意识到在bf:Work上做得太多了;2、意识到对于题名/名称-题名检索点没有很好的解决方案;3、上述题名/名称-题名检索点都是空白节点;4、与SHARE-VDE和Casalini合作以及SuperWork概念。
MARC来源:规范1XX$t,规范130,书目1XX+240,书目130,书目600/610/611$t、630,书目700/710/711$t、730【难道BF作品不是由这些字段抽取的?如何区分“作品”和“Hub”?】
MARC来源说出其作用,Hub作为聚合器(aggregator)执行3个功能:主题、相关作品、RDA意义的作品。

报告出处:European BIBFRAME Workshop 2019. National Library of Sweden, Stockholm, September 17 and 18, 2019

2020居家办公时期的BIBFRAME更新论坛

$
0
0

新冠肺炎全球横行,工作仍要继续,于是很多时候变成了居家办公。BIBFRAME开发几乎没有中断,原本在ALA年会期间召开的BIBFRAME更新论坛,如期举办但改为线上会议——BIBFRAME from home于2020-6-24举办,PPT日前已上网。

5个报告,美国国会图书馆(LC)3个,分别介绍进展概况、新的BF编辑器和BF到MARC转换;另外2个介绍梅隆基金资助项目,也是延续先前的LD4P系列和OCLC。

BIBFRAME Update Forum – June 2020(2020-6-24)

一、BIBFRAME from home / Beacher Wiggins,LC采访与书目获取部主任

介绍会议日程,概述BF试验进展(由另2位报告人详述)。

二、Cataloger’s editor / Matt Miller, LC网络开发与MARC标准办公室(NDMSO)

BIBFRAME编辑器(BFE)重构,主要重点放在用户(编目员)界面与体验,NDMSO委托SAMHAENG做UX咨询与设计。

新的编辑器界面设计(截屏)见BF官网:BIBFRAME Implementation, Tools, and Downloads 之Editor interface design

当前编辑器见:BIBFRAME Editor(正常显示需架梯)

五、BIBFRAME to MARC refined / Sally McCallum, LC NDMSO主任

2020-5-1,LC宣布提供新的BIBFRAME 2.0组件,用于将BIBFRAME数据转换为MARC。

特别说明与半年前ALA仲冬会议BIBFRAME更新论坛上Jodi报告中的2个变化(更新):

  • 没有007字段 -> 007字段添加007/00(资料类别)和007/01(特定资料标识)
  • 仅通用008字段 -> 添加特定媒介008数据
参见:
LC发布BIBFRAME到MARC转换(2020-5-6)
2020ALA仲冬会议BIBFRAME更新论坛(2020-2-11)

三、LD4P, LD4P2, LD4P3, and community / Philip Schreur, Stanford University

概述2016-2018年的LD4P和LD4L-Labs,2018-2020年的LD4P2(实施之路),以及最新的2020-2022年LD4P3(闭环 CLOSING THE LOOP)

LD4P3目标:发现;合作编目项目PCC的自维持数据池;扩展Sinopia;扩展质询规范;扩展合伙人培训计划。

参见:LD4系列

四、Shared Entity Management Infrastructure Project update / Chelsea Dalgord, OCLC元数据服务部产品分析师

共享实体管理基础设施项目的进展。基本情况可参见:OCLC获梅隆基金资助开发实体管理基础设施(2020-1-11)

项目计划交付:实体主干:数百万实体、永久URI;生产规模;生产基础设施;通过API访问搜索、读取、创建、更新;基本的用户界面。

对图书馆有什么好处:基于Web的发现结果;丰富的背景、联系材料和馆藏;数据品质;数据的机器可操作性和使用;跨馆藏和资料类型的元数据工作流程的一致性和效率。

美国实施新RDA:不早于2022年7月

$
0
0

测试版RDA工具包已在2020-12-15如期切换为官方版(新RDA)。LC于12-18发布信息,表示其项目团队已完成7500多条的政策声明(LC/PCC-PS)草案【可怕的工作量】。PS目前仍有待审查、修订和测试,将在新RDA发布后首次升级(预计2021-4-5)之后,再接受各方评论。

政策声明只是转换实施新RDA的起点,还需要完成另二种配套文件:1)PCC应用配置文件,2)PCC RDA元数据文档。

10月底PCC政策委员会会议确定,不早于2022年7月实施,会议成果(PoCo 2020 Meeting Outcomes, 2020/10/28-30)涉及新RDA进展部分如下:

  • 决定:PCC实施新RDA的日期不早于2022年7月;LC和PCC将尽可能协调其实施。
  • 行动:PCC主席将向PCC讨论邮件组发送消息,重申在2020年12月15日发布新RDA时,不应在PCC记录中使用新RDA,并宣布预计实施日期不得早于2022年7月;稍后将发送更详细的消息。可能会有一个实施过渡期。
  • 决定:与新RDA有关的LC-PCC文档将统称为“ PCC RDA元数据文档”。
  • 决定:将为MARC和BibFrame描述创建新RDA培训材料。
  • 决定:PCC将在实施前对新RDA进行测试,大概需要2个月。在开始测试之前,应完成PCC RDA元数据文档。
  • 行动:PCC秘书处将讨论可能解除对新的非渠道PCC成员的禁令。【?】

成果中还有3份相关文件链接:

  • LC-PCC政策声明进简述展(Brief update on LC-PCC Policy Statements)
  • 政策委员会讨论:新RDA实施计划( PoCo Discussion: Plans for New RDA Implementation)
  • RDA测试版实施时间表(Timeline for RDA Beta Implementation)


最后这份即《新RDA工具包实施》(Implementation of the New RDA Toolkit, 2020/11/04),有2021/1-2022/6分季度时间表(各种文档准备与测试),2022年7月开始培训编目人员……【实际实施不知何时】

实施准备中有多处提及BIBFRAME,尤其引人注意的是“LC希望使用BIBFRAME编辑器实施RDA,因此不会对员工进行在MARC环境中应用RDA工具包的培训”,可见LC要在转换到BIBFRAME以后再实施新RDA——换言之,BIBFRAME实施已为期不远

看来新RDA要加快BIBFRAME映射工作了(目前各“元素参考”部分仅有LRM和MARC映射)。

欧洲各国实施新RDA计划参见:2020年“RDA在欧洲”虚拟会议:从头开(2020-10-13)


2021仲冬BIBFRAME更新论坛(LC的BF/RDA计划)

$
0
0

因为新冠肺炎(COVID-19),今年ALA仲冬会议为虚拟会议,BIBFRAME更新论坛仍是其中一个分会场,于2021-1-24举行。今年四场报告分别是:主办方美国国会图书馆(LC)、艾利贝斯(Ex Libris)、Indexdata(宣传FOLIO)和OCLC。

LC终于开始实施BIBFRAME了。报告中4人分别介绍不同方面,内容较为丰富。

LC报告第4部分对编目未来范式的探讨,以及其他3个报告中涉及的关联数据理念方面的问题,值得编目员深思。【RDA-L邮件组中的某些争论正源于此】

一、BIBFRAME 100 / Sally McCallum, Judith Cannan, Kevin Ford, Paul Frank, Library of Congress

1、BIBFRAME 100 / Sally McCallum

  • BIBFRAME 100指LC的2021年目标,即百分之百编目员使用BF系统进行编目。经过3年部分编目员的试验,2021年起全部350名编目员将每周5天用BF编目,换言之,不再做MARC记录了(由BF转换为MARC)。
  • 编辑器在去年重新开发,今年3月将切换到新编辑器,调整编辑器将是全年的任务。
  • 另一项主要任务是优化MARC与BF的双向转换:LC需要MARC到BF转换,以使用其他来源数据(供应商记录、CONSER记录、CIP数据等);LC也需要BF到MARC转换,一是用于目前该馆的ILS【未提及何时采用下一代ILS】,一是向社区提供【全国乃至全球都在使用它家MARC记录】。
  • 另外还有系统及其他数据基础设施方面的工作。

2、BIBFRAME and RDA / Judith Cannan, Chief, Policy, Training, and Cooperative Programs Division

  • LC计划今年将编目员纳入BIBFRAME,到2022年再专注于新RDA。RDA实施时间表:
  • 2021冬春——起草和校对RDA政策声明,然后实施评论程序
  • 2021春及以后——PCC RDA元数据文档,应用政策声明在MARC和BIBFRAME环境,测试
  • 2022冬夏——RDA官方工具包培训

3、BF100 – System Changes / Kevin Ford

  • 从图示看,现在有两部分:id.loc.gov(LC的关联数据服务,包含数据库和公众界面)和BFDB(包含数据库和编目员界面)。
  • 将来后者融入id.loc.gov,新(编目)编辑器和ID编辑器均直接操作(查找与编辑)。

4、BIBFRAME from HOME / Paul Frank, Policy, Training, and Cooperative Programs Division

  • 【由于COVID-19,在家远程成为一种工作状态】LC在2020年4月向编目员调查,结果表明BIBFRAME的生产不受远程办公的影响。
  • 未来的范式?编目人员应如何依赖主要资源进行编目?转录可能导致BIBFRAME/RDF中的空节点,BIBFRAME(或编目)的投资回报率在哪里:描述性元数据?受控检索?贡献角色、主题检索、出版者数据?(备注:是时候质疑实际上手握资源以完成编目活动的重要性了。为什么不能使用代理人【自动转录?】?这会削弱书目描述的完整性吗?创建在关联数据中功能上是死胡同的数据“字符串”有什么价值?是否应该进行更多的编目工作,以提供对书目记录的受控检索,而花费较少的精力进行详细描述?)

二、关联数据:原则、愿景和未来的想法 Linked Data: Principles, vision and thoughts of the future  / Itai Veltzman, Ex Libris (Alma Product Manager)

  • 1、为什么图书馆需要关联数据
  • 1)更好的可发现性:显示强化,更易于导航及准确,可进行复杂提问、更快找到所需。
  • 2)全球可互操作:向图书馆系统外的其他谷仓如研究开放。
  • 3)有效编目:更准确、较少人工;易于创建关系;专注于特藏和独特资料。
  • 2、关联数据原则和愿景
  • 艾利贝斯关联数据支柱(略)
  • Alma和Primo现在有什么:
  • 1)记录强化:自动用URI对语言、标识符、名称和主题。
  • 2)Alma细化(refine):在Alma中支持细化工作流程,目录可用Getty, Wikidata和Geonames关联开放词表。
  • 3)搜索中显示:在结果有记录视图(也可显示BIBFRAME)。
  • 4)发布:整个目录,BIBFRAME、RDA/RDF。
  • 5)API端点:格式BIBFRAME、RDA/RDF和JSON-LD。
  • 6)发现:改进目录对搜索引擎的可发现性。
  • 3、未来的想法:艾利贝斯关联数据路线图2021
  • 1)曝光:改进在Web上的可见性,允许机构最大限度让其目录在搜索引擎中可用。
  • 2)编目:(1)能够存储及基本使用关联数据记录,用户将能上传并检索以关联数据编目的记录。(2)集成第三方关联数据编辑器,编目员能够创建新关联数据记录并存储在Alma,用基本功能(如Sinopia、LC BIBFRAME编辑器)。

三、MARC世界中的BIBFRAME:困难时期书目生存的工作流程 BIBFRAME in a MARC World: Workflows for bibliographic survival in troubled times / Wayne Schneider, Sebastian Hammer, Indexdata

  • 1、我们想要生活于由参照来编目:1)描述资源,参照稳定的标识符,而不是字符串。2)让IFLA LRM用户任务(查找、识别、选择、获取和探索)有更大的有效性。3)编目工具:协作、云端
  • 2、跨越鸿沟:1)MARC到BF转换;2)由BF生成MARC。
  • 3、什么是FOLIO?【图示FOLIO模块,了解元数据地位及“实体”等】

四、Updates from OCLC / Nathan Putnam, OCLC

BIBFRAME/MARC数据双向转换程序更新(880字段消失)

$
0
0

日前美国国会图书馆(LC)的BIBFRAME/MARC数据双向转换程序更新(New BIBFRAME-to-MARC Conversion Tools)https://www.loc.gov/bibframe/news/bibframe-to-marc-conversion.html。转换程序由Index Data公司为LC编制,使用XSLT。

LC网络开发与标准办公室主任Sally McCallum在BIBFRAME邮件组中介绍了MARC到BIBFRAME转换的4个更新:

  • 对某些标识符使用bf:assigner代替bf:source
  • 丛编说明处理修改
  • MARC记录中出现在不同位置的数据元素去重【估计是代码与著录重复】
  • 修改处理MARC 880字段存储的非拉丁文数据并说明BIBFRAME到MARC转换也相应更新。

于是去LC目录,通过“专家检索”找有880字段的丛编记录看双向转换。使用LC目录的关键词检索(https://catalog.loc.gov/vwebv/searchKeyword),用检索词 K490 或 K880,查找使用字段490(丛编)或880(非拉丁文字)的记录。在命中记录中选一条两者兼有的,比如繁体中文的傅緯平《本國史》属于丛书《民国籍粹续》,原书1933年出版,近年影印(001字段/书目ID=18564390 或 010字段/LCCN=2016401477)。

BIBFRAME到MARC https://id.loc.gov/tools/bibframe/comparebf-id/18564390.txt

本记录编制于1999年(据008字段)、非RDA记录(据头标),2016年入库时修改(据010、005字段)、添加336-338字段,属混合记录。BIBFRAME记录实际上是由MARC到BIBFRAME转换来的(见https://id.loc.gov/tools/bibframe/compare-id/full-rdf?find=18564390),但MARC记录则是由此BIBFRAME记录转换重新生成的(见884字段),与原MARC不同。特别明显的是,转换后的MARC记录不用880字段,著录用繁体中文、规范名用汉语拼音,简洁、很赞:

cam a22     ua 4500001    18564390
003    DLC
005    20160719093452.0
008    991116s2013    cc a          00| |chi |
010    $a  2016401477
042    $alccopycat
050 00 $aAC149$b.M568 2013 vol. K490
100 1  $aFu, Weiping.$0http://id.loc.gov/authorities/names/n82019332$4http://id.loc.gov/vocabulary/relators/ctb【$0规范ID,$4责任方式】
240 10 $aBen guo shi【统一题名,汉语拼音】
241 10 $aBen guo shi【新增字段?MARC21标准网站无】
245 10 $aBen guo shi$c傅緯平編著246 1  $a復興初級中學敎科書
264  1 $a上海$b商務印書館$c民國22 [1933
300   $a4 v.$bill.$c20 cm.
336   $atext$0http://id.loc.gov/vocabulary/contentTypes/txt
337   $aunmediated$0http://id.loc.gov/vocabulary/mediaTypes/n
338   $avolume$0http://id.loc.gov/vocabulary/carriers/nc
490 0  $a民国籍粹续
500   $aPhotocopy. [北京 : 中印集团数字印务有限公司, 2013?]. 20 cm. (民国籍粹续)【原MARC记录用533字段】
651  0 $aChina$0http://id.loc.gov/authorities/names/n79091151$xHistory$0http://id.loc.gov/authorities/subjects/sh85061212$vTextbooks$0http://id.loc.gov/authorities/genreForms/gf2014026191【$0规范ID】
830  0 $aMinguo ji cui xu【规范丛编名,汉语拼音】
852   $ahttp://id.loc.gov/vocabulary/organizations/dlc【位置/收藏馆】
884   $aDLC bibframe2marc v1.1.0-SNAPSHOT$g20210619231058.0$qDLC$uhttps://github.com/lcnetdev/bibframe2marc【描述转换信息,2015新增字段】

发现的唯一问题是040字段编目来源遗漏,不应该。难道是bf:assigner代替bf:source没有修改完全?但bf:descriptionModifier也没有。BIBFRAME中相应部分(RDF XML):

<bf:assigner>【040$a$c】
<bf:Agent>
<bf:code>CIBTC</bf:code>
</bf:Agent>
</bf:assigner>
<bf:descriptionModifier>【040$d】
<bf:Agent rdf:about="http://id.loc.gov/vocabulary/organizations/dlc" >
<bf:code>DLC</bf:code>
</bf:Agent>
</bf:descriptionModifier>

参见:

BIBFRAME本体2.1版发布(4层确认)

$
0
0

美国国会图书馆(LC)赶在BIBFRAME更新论坛于2021/6/29召开前,发布了BIBFRAME本体的2.1版(之前为2.0.1版),涉及50个类与属性的变化。美国国会图书馆网络开发与MARC标准办公室主任Sally McCallum在BIBFRAME邮件组中说明,其中绝大多数来自社区中一直在使用Bibframe词表和模型的实施者,并表示感谢。 见:BIBFRAME Ontology Updated / McCallum, Sally (2021-6-24)

LC网站上有修订后的本体:http://id.loc.gov/ontologies/bibframe。主要讨论场所则在GitHub:https://github.com/lcnetdev/bibframe-ontology

LD4社区应该是所指的重要实施者,BIBFRAME本体中有4个属性(awards、custodialHistory、dimensions、fontSize)在编辑附注中注明“请参阅 ARM Ontology(艺术与珍本资料本体) 以了解更详细地对此信息建模的策略”。【参见:BIBFRAME扩展:bibliotek-o(及ArtFrame和RareMat)(2018-5-1)】

Kevin Ford昨天在BIBFRAME的GitHub中发了上百条评论、包括关闭问题,涉及对建议的处理结果,如在BF中声明FOAF命名空间等,特别有一条解释新增的Hub类。之前在某PPT已经见过Hub,此评论可认为是官方解释。概言之,Hub为作品的子类,对应于RDA作品。也就是说,BIBFRAME对应于LRM/RDA的资源四层结构为:Hub—BF作品—实例—单件

Proposal: New class – bf:Hub #75

bf:Hub 的实验始于三年多前(在 LC),并于2019年6月首次公开实例化[用于实例?]。Hub被定义为作品的子类,是抽象资源,充当两个作品之间的桥梁。通过这种方式,它们起到聚合和配置资源的作用。例如,它们使收集马克吐温的《汤姆·索耶历险记》(Tom Sawyer)的所有西班牙语翻译成为可能,或者捕获包含弗朗西斯科·塔雷加(Francisco Tarrega[西班牙吉他演奏家、作曲家])的《随想曲》(Capricho árabe)的其他BF作品。在LC的实验中,Hub作为聚合器执行三个功能:作为主题、作为相关作品以及作为 RDA 意义上的作品。Hubs,作为BF作品,可以作为主题来描述其他作品。

—— 附:BIBFRAME 2.1的变化 ——

根据Change Notes总结(红字,日期2021-06-09),共86处修改,有些属性涉及多处修改。

一、新增22个类/属性,大致可分成两部分

(一)类(7个)及相应属性(6个)

  • AccessionNumber(登录号,标识符Identifier子类)
  • CollectionArrangement(资料信息的组织)collectionArrangement(资源集合的组织安排)/ collectionArrangementOf,collectionOrganization(资源分成较小单元的方式)
  • Eidr(Entertainment Identifier Registry,标识符Identifier子类)
  • Ensemble(合奏,新增上位类:有子类MusicEnsemble)
  • Hub(中转站/枢纽=桥接两个作品的抽象资源,作品Work子类)
  • Material(材料=资源的物质或组成,新增上位类:有子类BaseMaterial、AppliedMaterial)material(有子属性baseMaterial、appliedMaterial)/ materialOf(有子属性baseMaterialOf、appliedMaterialOf)
  • PubFrequency(资源的出版频率)pubFrequency

(二)原有属性的互逆属性(9个)

adminMetadataFor,agentOf,appliedMaterialOf,arrangementOf,baseMaterialOf,contributionOf,noteFor,subjectOf,titleOf

二、其他修改

  • 1、因新增上位类导致的变化(AppliedMaterial、BaseMaterial、MusicEnsemble;appliedMaterial、baseMaterial、ensemble、ensembleType)
  • 2、修改标签(MovementNotation、MusicNotation、Script、TactileNotation、mount)
  • 3、修改定义(Arrangement、Event、GenreForm、Mount、Urn;arrangement、ensemble、expressionOf、hasExpression、originDate、originPlace、relatedTo)
  • 4、修改/增加附注(Classification、Identifier、Note;awards、custodialHistory、dimensions、fontSize)
  • 5、修改Comment(hasPart、partOf:也用于Event)
  • 6、修改上位属性(otherEdition)
  • 【以下定义域/值域的修改基本上是为减少对使用的限制】
  • 7、扩大定义域/用于(appliedMaterial、assigner、baseMaterial、issuedWith、otherPhysicalFormat、subject、title)
  • 8、移除定义域/用于所有资源(electronicLocator、firstIssue、frequency、geographicCoverage、lastIssue)
  • 9、扩大值域/期望值(colorContent、extent)
  • 10、移除值域/期望值为所有资源或取值(acquisitionSource、agent、appliedMaterial、assigner、baseMaterial、derivedFrom、descriptionModifier、genreForm、grantingInstitution、heldBy、issuedWith、originPlace、place、source)
  • 11、修改值域(hierarchicalLevel、pattern)

2021夏BIBFRAME更新论坛

$
0
0

自2012年起,美国国会图书馆(LC)每年在美国图书馆协会冬夏两次年会上召开BIBFRAME更新论坛。由于COVID-19,去年夏天开始都是虚拟会议,今夏6月28日召开。今年四个报告,比较罕见地没有OCLC、也没有厂商。报告已经上网:

BIBFRAME June 2021 Update Forum

一、BIBFRAME 100进展报告(Progress Report on BIBFRAME 100 / Sally McCallum, Library of Congress)

在今年仲冬会议上已经报告过BIBFRAME 100,即2021年起全部350名编目员将每周5天用BF编目,这里的100原本是100%的意思,不知为何现在的目标是成功达到80-90%编目员用BIBFRAME。

报告的第2部分是四个主要任务:

二、LD4P与社区:PCC数据池与LD4(LD4P and Community: The PCC Data Pool and LD4 / Philip Schreur, Stanford University,代表LD4社区;会议网站标题:Community and Data Pool)

报告首先用1张图示PCC数据池:编目员、[编辑器]Sinopia<->实体数据存储、OCLC-PCC编目,SHARE-VDE、SHARE-VDE簇&知识库、QASHARE-VDE缓存<-规范缓存。

其后介绍LD4社区,包括其原则、兴趣小组(发现、伦理、非拉丁文字、Sinopia、[应用]纲要、珍本资料、连续出版物、维基数据),以及将在2021/7/19-23在线召开的2021年LD4关联数据会议。会议主题包括:关联数据教育,包容不同的声音,采用关联数据的实用步骤,关联数据的可靠性和可用性,将关联数据纳入日常运营,关联数据宣传。

关于LD4可参见:关联数据编目走向现实——新项目LD4P3及LD4社区(2020-12-10)

三、BIBFRAME数据交换规划(BIBFRAME Data Exchange Planning / Melanie Wacker, Columbia University, Chair, Program for Cooperative Cataloging Policy Committee,代表PCC编目政策委员会)

主要介绍将于2021/9/9-10召开的PCC虚拟会议,议题是:在系统与实施之间交换BIBFRAME数据。参与者包括:PCC政策委员会(PoCo)、LC、欧洲BIBFRAME小组、OCLC、厂商、LD4、国家图书馆【有哪些?】等(含观察者)。

1、召开本次会议的原因有:

  • 1)BIBFRAME 100——LC正推动大多数编目员只做BIBFRAME
  • 2)PCC参与LD4/Sinopia
  • 3)数据池
  • 4)PCC元数据应用纲要将使用“BIBFRAME 作为初始基础数据模型”
  • 5)美国以外的BIBFRAME工作
  • 6)实施间的不一致会对系统之间的数据交换和跨数据源的查询产生负面影响。如:rdfs:label 与 rdf:value;bf 命名空间的扩展如 bflc, pmo, arm; LCSH 复杂主题标题的编码(如使用 MADS/RDF);bf:Agents建模使用来自 LC 名称规范档的规范 URI vs RWO URI,或者Wikidata;使用 URI 而不是空节点。

2、期望成果:

  • 1)生态系统和基础协议- 就 BIBFRAME 环境中数据交换的含义达成一致- 定义 BIBFRAME 交换的核心需求,如: 应该有一个标准化的序列化吗? 是否需要商定最低 BIBFRAME 描述? 如何建模/塑造 BIBFRAME 元素? 开发工具,包括验证技术;对发现层和用户体验的影响
  • 2)工作流程和工具- 确定需要在哪些系统之间共享哪些数据的用例和期望。随着更多图书馆和供应商进入该领域,这可能会发生变化;接收新数据的可接受频率是多少?如何鼓励*上游*更改以避免数据冲突?- 就何时、为何链出以及何时在本地复制数据和缓存的最佳实践达成一致- 测试交换的想法。开发系统之间共享数据的用例和计划,潜在有:Share-VDE、Sinopia、国家图书馆、LC、OCLC、需要的系统如ILS厂商。为测试制定粗略的实施时间表- 探讨成立国际BIBFRAME标准化与交换小组

四、BIBFRAME 2.1版及未来计划(Version 2.1; And future plans …. / Kevin Ford, Library of Congress,会议网站标题:BIBFRAME Vocabulary: An update and future plans)

概述BIBFRAME 2.1更新。然后回顾MARC更新史,包括内容、负责与参与机构、修订方式。对比BIBFRAME,现在并没有指导小组或咨询委员会,在GitHub以问题(ISSUE)方式提出建议、讨论……。

参见:BIBFRAME本体2.1版发布(4层确认)(2021-6-25)

2021欧洲BIBFRAME研讨会信息

$
0
0

2021年欧洲BIBFRAME 研讨会(第五届年会),9月21-23日在网上举行。原计划在匈牙利布达佩斯国家塞切尼图书馆举办的吧,由于COVID-19而变成虚拟会议。PPT已上线,部分没有PPT的只能去油管看视频(可以根据会议日程时间定位)。

BIBFRAME Workshop in Europe 2021 

  • 欧洲 BIBFRAME 研讨会是一个论坛,用于分享有关 BIBFRAME 实施的实践、生产和规划的知识。
  • 我们将致力于使用BIBFRAME模型和相关工具、从MARC过渡到关联数据的人们聚集在一起。
  • 研讨会重点关注 BIBFRAME 的实际实施,而不是理论上的关联数据/语义网络活动。

丹麦皇家图书馆Leif Andresen的开场报告 Welcome and practicalities(欢迎和实用信息),浓缩了3天的会议内容、可按图索骥;又汇总历届BFWE(原称BWE)概况,相当实用:

  • [一] 日程:
  • 第1天,实施进展:1、美国国会图书馆BF100计划;2、瑞典国家图书馆[Libris XL];3、SVDE=Share-VDE 2.0
  • 第2天,新发展:1两个编辑器的故事(斯坦福[Sinopia]和LC [BFE]);2、Sinopia和Folio;3、Sinolio,在folio中集成Sinopia关联数据编辑器试验[无PPT];4、尼日利亚编目员对BIBFRAME的认知[调查];5、ARM 1.0,艺术、档案和珍稀资料[BIBFRAME扩展] [无PPT]
  • 第3天,数据交换:1、BIBFRAME本体更新[无PP]】;2讨论:在向关联的图书馆数据过渡中RDA/RDF可以发挥什么作用?[1/5有PPT];3、BIBFRAME数据交换:1)关于 BIBFRAME 数据交换的 PCC 会议报告,2)BIBFRAME数据交换小组讨论[无PPT]
  • [二] 2021年在线参会:
  • 非洲5国:阿尔及利亚、贝宁、埃及、马里、尼日利亚
  • 亚洲9国/地区:孟加拉国、香港、印度、伊朗、以色列、日本、巴基斯坦、菲律宾、卡塔尔
  • 澳洲1国:澳大利亚
  • 欧洲26国:奥地利、比利时、克罗地亚、塞浦路斯、捷克共和国、丹麦、爱沙尼亚、芬兰、法国、德国、希腊、匈牙利、爱尔兰、意大利、拉脱维亚、卢森堡、荷兰、挪威、波兰、葡萄牙、斯洛文尼亚、西班牙、瑞典、瑞士、乌克兰、英国
  • 北美洲3国:加拿大、墨西哥、美国
  • 南美洲3国:阿根廷、巴西、哥伦比亚
  • [五] 组织者小组
  • Harriet Aagaard, National Library of Sweden 瑞典国家图书馆
  • Leif Andresen, Royal Danish Library(联系人 leif@kb.dk)丹麦皇家图书馆
  • Michele Casalini, CasaliniLibri (Share-VDE) Casalini Libri公司(Share-VDE项目)
  • Reinhold Heuvelmann, German National Library 德国国家图书馆
  • Miklós Lendvay, National Széchényi Library of Hungary 匈牙利国家图书馆
  • Sally H. McCallum, Library of Congress (NDMSO) 美国国会图书馆
  • Philip E. Schreur, Stanford University. Green Library (LD4P) 斯坦福大学图书馆(LD4P项目)
  • Osma Suominen, National Library of Finland 芬兰国家图书馆

前3届会议,另参见:

Viewing all 122 articles
Browse latest View live