MODS到RDF映射建议(Samvera版)

samvera

Samvera原名Hydra,是一个开源的机构库解决方案(由Fedora机构库软件、Solr索引、Blacklight分面搜索浏览定制显示界面和Samvera集成组件4个部分构成)。最初是Hull、Stanford、Virginia三所大学的跨机构项目,现在已形成一个参与广泛的开发社区。
上月Samvera MODS to RDF Working Group发布《MODS到RDF映射建议》1.0版,定位是非官方的应用纲要/应用配置文件(Application Profile)——MODS本身有官方RDF但一直处于草案阶段(参见:MODS到BIBFRAME映射,2019-2-15)。
Kathleen Gerrity在MODS和BIBFRAME邮件组发消息,如此介绍《MODS到RDF映射建议》:
本应用纲要提供对数字对象映射MODS XML元数据到RDF关联数据类和属性,使用广泛采用的RDF命名空间。
十多家学术和公共图书馆成员协作成果,文件包含MODS元素到RDF的综合映射,使用真实世界元数据用例和数百样例。
不同于使用单一词表或新提出正式本体来实施直接的XML到RDF方法,本映射包含来自大量现有词表的属性,为关联数据环境中的记录提供更大价值。提供直接的“直接”映射(不需要为诸如主题、人或地点之类的概念创建本地对象)和更彻底的“铸造对象”(minted object)映射。
尽管工作在Samvera数字机构库框架下实行,本映射与系统无关,希望在广泛环境下可应用。
via [MODS]邮件组: MODS to RDF Mapping Recommendations now available / Kathleen Gerrity (2019-2-12)

本建议重用22个命名空间,包括少数自定义属性采用的不透明命名空间(OpaqueNamespace,开源社区支持的本体框架,提供永久URI)。有些命名空间仅采用一二个属性(如基础的owl, rdf, rdfs, skosxl)。非图书馆领域开发的词表主要用于相关项(mods:relatedItem)。
另外用到多个LC代码表,不是作为取值,而是作为属性,如以关系词代码作为属性,涉及责任者、出版发行项以及馆藏机构——尤其是出版发行机构与地点采用关系词代码,感觉脑洞比较大:
直接映射例2:
<https://example.org/objects/1> relators:pup <http://vocab.getty.edu/tgn/7013445> ;
relators:pbl “published by John P. Soule” ;
bf:editionStatement “3rd edition” ;
dcterms:created “1930?” .

——《MODS到RDF映射建议》摘译——
MODS to RDF Mapping Recommendations (v.1.0) / Samvera MODS to RDF Working Group. January 2019

背景与需求
2015年中,为升级到Fedora 4,必须由基于XML、存储为数据流的元数据,转换到存储为RDF属性的元数据。许多机构大量使用MODS XML,但MODS不易翻译为RDF图模型,除非使用空节点(在Samvera和Fedora中有问题),或为元数据元素(如创作者和主题)铸造对象类(minted object classes)。因此前波士顿公共图书馆的Steven Anderson创建MODS到RDF工作组,提出创建创建一个社区设计的应用纲要,映射MODS描述元数据到RDF。

战略与决定
评估发现MODS RDF本体不合需要:[1]缺少积极维护;[2]实施中过于依赖使用空节点和/或铸造对象;[3]缺乏机构采用。
决定选择使用已在其他关联数据数据集中广泛使用的各种词表,将MODS XML元素映射到RDF。
虽然使用如此多不同的词表[见后]增加了映射指南的复杂性,但这种方法可以比作“不把所有鸡蛋放在一个篮子里”的想法。虽然机构必须准备评估许多词表的当前和未来稳定性,但如果一个词表不再受支持或进行主要版本更改,只需要更新这些映射的一部分,而不是整个文档。
早期考虑采用MODS RDF、BIBFRAME(从v.1到v.2)、都柏林核心元素和都柏林核心术语,但发现不足以表达必要的面向机构库的内容概念,或者与Fedora 4环境中的实现不合。进而研究其他词表如Schema.org、FOAF、SKOS、BIBO和RDA等。

分析过程
参与机构分别对20个MODS顶层元素如何映射逐个进行确认并提供样例等,由小组从以下方面评审,[1]数据保真度、[2]可接受的损失、[3]特定命名空间的相对优点(如采用率、预计未来可行性)、[4]遵守属性的定义域和值域取值的必要性、[5]实现的复杂性,最终达成共识。某些元素有简单和复杂两种选项。
偶而在通用命名空间找不到合适映射,小组建议在不透明命名空间(OpaqueNamespace,http://opaquenamespace.org/开源社区支持的本体框架,提供永久URI)中提出新的谓词,但目前这些谓词[属性]尚未在OpaqueNamespace中注册。

映射建议
映射分为两大类:直接映射(简单选项)和铸造对象映射(复杂选项,限部分元素)。
直接映射(简单选项)提供从MODS XML元素到RDF语句(主体、谓词、客体)的映射,且无需为主题、人物、事件或地点等概念创建或维护本地对象。所有语句都以源自外部词表(例如LCSH)的URI或文字值(文本字符串)结尾。可以使用所描述的数字对象直接存储、维护和更新这些RDF语句。此法简单,但有时会丢失MODS记录的粒度和细节,因为并非每个数据点都可以直接映射到RDF属性。
铸造对象映射(复杂选项)为该MODS元素(题名对象、名称对象等)创建本地概念对象(必须由本地机构库系统维护),以替代使用空白节点。本地对象具有单层RDF语句(主体、谓词、客体),它们提供源自外部词表的URI、本地对象的URI或文字值(文本字符串)。与所描述的数字对象一起存储的RDF语句是指向这些本地概念对象的指针。此选项允许将MODS记录中的所有详细信息序列化为RDF,以用于复杂的MODS元素如名称和主题。
铸造对象增加了数据模型的复杂性,但描述性书目元数据本身就很复杂。【直接映射中客体取文字值的较多,但】书目或文化遗产本体中使用的许多RDF谓词都具有URI或其他RDF对象类型的定义值域(可接受值的类),而不是字符串文字。本文档中的映射力求遵守所有示例中定义的值域,这需要为未由现有URI表示的概念、题名、人员、地点、馆藏或组织创建本地对象。
本映射中,某些情况提供多种方式映射元素或值【元素选择不多,值URI选择较多】。机构应创建并维护本地应用配置文件,以记录最适合其自身数据、应用和用户需求的方法。

使用命名空间
BIBFRAME (v.2) 【LC。用于mods:recordInfo;另外铸造对象的类多采用BF2】
The Bibliographic Ontology (BIBO)【用于mods:relatedItem】
Classification Schemes classSchemes【LC。用于mods:classification】
DBPedia Ontology【用于mods:relatedItem】
Dublin Core Metadata Element Set, Version 1.1
DCMI Metadata Terms
DCMI Type Vocabulary
EBUCore【用于mods:relatedItem】
Europeana Data Model (EDM)
FOAF (Friend of a Friend)【foaf:name;铸造对象的类:foaf:Person,foaf:Organization,foaf:Agent】
GeoJSON-LD【坐标 geojson:bbox,geojson:coordinates,用于mods:subject】
MARC Code List for Relators【LC。大量采用关系词作为属性:各种责任者,出版发行生产制作地、者,收藏机构rps=Repository】
OpaqueNamespace【不透明命名空间】
OWL 2【owl:sameAs】
Portland Common Data Model【用于mods:relatedItem】
RDA Unconstrained
The RDF Concepts Vocabulary (RDF)【rdf:type】
RDF Schema 1.1【rdfs:label,rdfs:seeAlso】
Schema.org
SKOS (Simple Knowledge Organization System)【skos:note;skos:exactMatch,skos:closeMatch,skos:relatedMatch;类:skos:Concept】
SKOS eXtension for Labels【skosxl:prefLabel,用于mods:titleInfo,mods:subject】
Standard Identifiers Scheme【LC。大量采用】

直接映射(简单选项)【仅摘<mods:titleInfo>片断】
dcterms:title 文字
dce:title URI
dcterms:alternative 文字
例1:题名含不排序字符及子题名
<https://example.org/objects/1> dcterms:title “The wintermind : William Bonk and American letters” .
例6:统一题名
<https://example.org/objects/1> dce:title <http://id.loc.gov/authorities/names/n00020514> .

铸造对象映射(复杂选项)【仅摘<mods:titleInfo>片断】
类:bf:Title
dce:title URI
bf:variantType 文字
rdfs:label 文字
skos:note 文字-编目员提供题名
skos:relatedMatch URI-规范题名
skosxl:prefLabel URI-首选题名

例1:题名含不排序字符及子题名
<https://example.org/objects/1> dce:title <https://example.org/titles/1> .
<https://example.org/titles/1> a bf:Title ;
rdfs:label “The wintermind : William Bonk and American letters” .

例6:统一题名
<https://example.org/objects/1> dce:title <https://example.org/titles/1> .
<https://example.org/titles/1> a bf:Title ;
rdfs:label “Bible” ;
skos:relatedMatch <http://id.loc.gov/authorities/names/n00020514> ;
bf:variantType “uniform” .

BIBFRAME2.0实施注册2018项目(附UIUC的关联数据来源)

又去LC官网看BIBFRAME2.0实施注册(BIBFRAME 2.0 Implementation Register),2017年7月迄今仅有3项新增或更新,都是2018年的:
(1)Reasonable Graph(2018.2.27更新)
据称是个开源项目,支持广泛的本体模型,已经实现BIBFRAME,希望用于图档博领域。
有一个在线演示,看了没什么感觉。

(2)Ex Libris, Alma(2018.4.24更新)
已完成的是:URI强化MARC记录;可以查看和导出BF格式的书目记录
计划:编辑、导入BIBFRAME记录
参见:
艾利贝斯与哈佛图书馆合作开启“BIBFRAME路线图”(2017-5-12)
2018年BIBFRAME更新论坛(2018-11-14):12月发布的Alma 2017,能够以BF发布整个馆藏

(3)University of Illinois at Urbana-Champaign Library(2018.6.28更新)
UIUC在2015年BIBFRAME 1.0时期就有一个项目,当时是把30万册电子书由MARC转换为BIBFRAME。看样例,外部链接是主题词(id.loc.gov)和创作者(VIAF)。提供4个当时的核心类(作品、实例、注释、规范)的RDF文件。
本次是19世纪英国小说的数字收藏:从Dublin Core转换为BIBFRAME 2.0共7,829项,并使用关联开放数据来增强发现。看样例,外部链接有所扩大:卷册链(Internet Archive电子书),作者(VIAF),DDC(OCLC的DDC概要网站),馆藏链接(机构馆主页,可惜不是OPAC);
因为是小说,没有主题词。提供各卷册(可以算实例)的BIBFRAME 2.0 RDF。

参见:
BIBFRAME 2.0实施注册(2017-4-26)
BIBFRAME 2.0实施注册新增项目(附:意大利SHARE目录)(2017-7-25)

———- UIUC的关联数据来源 ———
UIUC的项目页(最后更新2017.6.24)有Linked Data Sources,抄录如下:
作品标识符:xISBN: Worldcat Work ID(http://xisbn.worldcat.org/xisbnadmin/index.htm)
实例标识符(本地OPAC):University of Illinois at Urbana-Champaign Vu-Find Catalog(vu-find)
BIBFRAME 2.0作品标识符OCLC WorldCat services(https://www.oclc.org/support/services/worldcat.en.html)
BIBFRAME 2.0实例标识符(同上,本地OPAC)
个人名称、团体、地理名称The Virtual International Authority File (VIAF)(http://viaf.org/)
主题
Library of Congress Authority Files (LC/NACO Authority File)(http://authorities.loc.gov/webvoy.htm)
LC Linked Data Service: Authorities and Vocabularies(http://id.loc.gov/)
Faceted Application of Subject Terminology (FAST)(http://experimental.worldcat.org/fast/)
Medical Subject Headings (MeSH) RDF Linked Data(http://id.nlm.nih.gov/mesh/)
研究者与机构
The International Standard Name Identifier (ISNI)(http://isni.org/)
ORCiD(http://orcid.org/)

可与PCC《创制和获取URI:常用词表和参考源指南》对照。参见:
创制和获取URI的常用词表和参考源指南(2018-3-2)

LD4P2走向实施之路:目标与工作(附LD4系列)

LD4P2是Andrew W. Mellon基金会资助的LD4系列的第4个2年期项目(2018-2020),成员为康奈尔大学、哈佛大学、美国国会图书馆?、斯坦福大学和爱荷华大学。本期项目的终级目标是实施,即以关联数据来描述图书馆资源。特别值得注意的是与合作编目项目(PCC)和Wikidata的合作。
先前曾关注项目的7个目标(见下参见),现在已看到2个有所进展,因此再重复记录如下;项目维基网站还有6个工作包,在此一并记录:
Linked Data for Production: Pathway to Implementation (LD4P2)

7个目标:
[1] 由一个学术图书馆的核心小组,创建以BIBFRAME表示的关联数据的连续馈送池
[2] 开发基于云的沙箱编辑环境,以支持扩展的图书馆合伙人创建和重用关联数据【2018.11.1宣布已招募到17家学术图书馆承担子项目:Stanford Libraries announces Linked Data for Production (LD4P) cohort members and subgrant recipients;先前已召开合伙人会议,定下2019.4开始生成数据的目标】
[3] 开发用于使用标识符自动增强MARC数据的策略、技术和工作流程,以便尽可能干净地转换为关联数据
[4] 开发用于创建和重用关联数据及其支持标识符作为图书馆核心元数据的策略、技术和工作流程
[5] 通过与Wikidata的协作,更好地将图书馆元数据和标识符与Web集成【2018.8.27 斯坦福大学为此公开招聘一位驻留维基媒体人:Wikimedian-in-Residence position at Stanford University
[6] 使用基于关联数据的发现技术增强广泛采用的图书馆发现环境(Blacklight)
[7] 通过开发一个名为LD4的组织框架来协调持续的社区协作,确保在分布式发展社区中不断交流思想和技术。

6个工作包:
WP1:Sinopia:基于云的合作编目环境/原编元数据创建环境
WP2:元数据重用(MARC-to-BIBFRAME转换管道+直接使用原生RDF描述)
WP3:链接到外部规范和Web语境数据(标识符URI+Wikidata发布、链接和丰富)
WP4:发现(Blacklight+知识面板+语义搜索+浏览+可视化+微数据)
WP5:原生关联数据描述生产流程(特藏=电影+地图+音乐+唱片:与数字化配套、与Wikimedia链接)
WP6:社区协作(建立LD4社区+2次国际会议)

——— 附:LD4L: Linked Data for Libraries (The Gateway) ———
LD4L 2014 (2014-2016):“创建一个模型,既可以在各机构内部又可以通过一个协调可扩展的关联开放数据网络运作”(100万美元;斯坦福、康奈尔、哈佛)
LD4L Labs (2016-2018):“帮助图书馆使用关联数据来改善对学术资源信息的交流和理解”(150万美元;康奈尔、哈佛、爱荷华、斯坦福)
LD4P (2016-2018):“转变技术服务生产工作流程”(150万美元;斯坦福、哥伦比亚、康奈尔、哈佛、普林斯顿、美国国会图书馆)
参见:重量级图书馆关联数据项目LD4P获得资助(2016-5-10)
LD4P2 (2018-2020):“为编目社区建立一条途径,开始转向关联数据来描述图书馆资源”(400万美元;斯坦福、康奈尔、哈佛、爱荷华)
参见:BIBFRMAE应用进展:LD4P实施之路(2018-7-8)