标签： 郢书燕说

FRBRoo的连续出版物扩展——PRESSoo

PRESSoo由ISSN国际中心和ISSN评审组的代表，以及法国国家图书馆代表组成的工作组开发，目标是应用FRBR家族模型到连续出版物和连续性资源。
ISSN网站上的PRESSoo页面：PRESSoo
2013年3月发布了0.1版征求意见：
PRESSOO, Extension of CIDOC CRM and FRBROO for the modelling of bibliographic information pertaining to periodicals, Version 0.1. March 2013 / Editor: Patrick Le Boeuf (BnF)（48页PDF文件）
导论起始的定义：“PRESSoo，一个意在抓取与表达关于连续性资源书目信息的基础语义的正式本体，特别针对期刊（杂志、报纸等）。PRESSoo是FRBRoo的扩展，而FRBROO本身是CIDOC CRM的扩展。”

连续出版物的主要FRBRoo类是连续作品 F18。导论中包括13幅FRBRoo、PRESSoo及CIDOC CRM的类与属性间关系的图示，有助于了解连续出版物中的各种关系。文档最后是ISSN手册中的数据元素到PRESSoo的对照清单（含PRESSoo、FRBRoo及CIDOC CRM的类与属性，PRESSoo继承了后两者的类与属性）。

PRESSoo定义了12个类（Z1-Z12），43个属性（Y1-Y43）。属性比较好理解，基本上是期刊的各种演变关系。类可分为两部分，一是各种事件：
– 作品概念 F27：连续出版物转换 Z1、分离 Z3
– 活动 E7：吸收 Z2、发行规则[刊期]改变 Z5、元数据管理 Z8
– 出版事件 F30：临时代替 Z4、开始出版 Z6、结束出版 Z7
另外一部分不知道怎么归类
– 存储单元 Z9（如装订本）
– 编号模式 Z10（如数字、月份）
– URL Z11
– 发行规则[刊期] Z12

参见：FRBRoo读后（2014年2月9日）

FRBRoo读后

FRBRoo问世已久（2009年6月1.0版），一直没有看，昨天大致浏览一遍。
FRBRoo（FRBR object-oriented version, harmonised with CIDOC CRM)，即FRBR面向对象版，按CIDOC CRM网站“FRBRoo Introduction”的说明，“FRBRoo是一个正式的本体，意在抓取与表达书目信息的潜在语义，方便书目与博物馆信息的集成、中介与交换。”

正式文件：FRBR, object-oriented definition and mapping to FRBRer (version 1.0)（146页pdf文件）
文件署名：FRBR与CIDOC CRM协调国际工作组（International Working Group on FRBR and CIDOC CRM Harmonisation），编辑：Chryssoula Bekiari，Martin Doerr和Patrick Le Boeuf。

看后梳理如下几个基本知识点：
1、FRBRoo是一个本体，定义了类(Class，对应FRBR的实体)和属性（Property，对应FRBR的关系）；属性连接不同类，一个属性可能适用于多个不同的类。
– 类：将FRBR原来3组10个“实体”扩展为33个（名称为F1-F33），包括细化作品、内容表达和载体表现（子类）（1.2.2），以及增加“事件”（event）。
– 属性：将FRBR原来以样例说明的“关系”明确为31+8种（名称为R1-R31，以及8个“类属性”CLP）。未仔细对照是否有所扩展。对创作与生产过程加以分析，是FRBR与FRBRoo的差异之一（1.2.3）
– FRBR中的Attribute基本不在FRBRoo中（除CLP为针对F3的物理属性）。自己一直把Property和Attribute都译作属性，其实一直有点困惑两者的区别。网上查了下，一般建议是前者译为属性，后者译为特性。

2、FRBRoo基于FRBR和CIDOC CRM，文件中有各自的类和属性清单：
– FRBRoo类和属性清单（2.6、2.7）
– 参引的CIDOC CRM类和属性清单（4.3、4.4）
还有多种对照表：
– FRBRoo类与CIDOC CRM部分类的等级校准（2.5）（CIDOC CRM的类用E1-E90表示）
– FRBRoo属性与CIDOC CRM部分属性的等级校准（2.5）（CIDOC CRM的属性用P1-P148表示）
– FRBR本身（FRBRer）与FRBRoo映射（3）（FRBR章节号对照）

3、FRBR第一组4个实体WEMI，在FRBRoo中被区分为5个类，分别有如下层次：
– F1作品——F2内容表达——F3载体表现生产类型（Manifestation Product Type）——F5单件
– F1作品——F2内容表达——F4载体表现单例（Manifestation Singleton）
即当载体表现只有一件时（非批量生产，如手稿），取F4（不用F3），此时其下没有F5单件。

4、作品与内容表达还另细分有子类（2.5.1）：
– 作品 F1
— 个别作品 F14——集合作品 F17
— 复杂作品 F15——连续作品 F18
— 容器作品 F16——集合作品 F17、录制作品 F21、出版作品 F19（——连续作品 F18）、表演作品 F20
– 内容表达 F2
— 独立内容表达 F22——出版内容表达 F24、表演计划 F25、录制 F26
— 内容表达片断 F23

5、除FRBR实体第1组（18个）、第2组（2个）、第3组（4个）外，类还有如下2种：
（1）名称 F12 和标识符 F13
（2）事件
– 创作 E65 ——作品概念 F27、内容表达创作 F28（——录制事件 F29、出版事件 F30）
– 活动 E7 ——表演 F31
– 生产 E12 ——载体生产事件 F32、复制事件 F33

6、FRBR是静态的实体-关系，表现活动的结果；而CIDOC CRM是动态的，以事件（Event）表现创作等活动过程。FRBR与FRBRoo的首要差别就是后者引入了时间实体、事件与时间处理过程（temporal entities, events and time processes，1.2.1）。
被图书馆编目洗脑多年的人，对动态与静态的区别需要细细体会（下图引自CIDOC CRM网站）。

Work and Expression, Static view
作品和内容表达的静态视图
From Work to Expression, dynamic view
从作品到内容表达的动态视图

———附：中文资料———

印象中以前看到过中文相关论文的，这次竟然没查到。用FRBRoo查全文，CNKI上只有3篇，大致都是进展综述中涉及而非专论；万方6个结果全是外文；维普则完全查不到。摘录其中一篇的片断：
顾犇. 第76届国际图联大会编目相关论文评析. 中国图书馆学报, 2010,36(5):82-87
(p.83)FRBRoo即面向对象的FRBR(书目记录的功能需求),FRBRoo书目数据模型是CIDOC概念参考模型(CRM)形式化、普遍的本体的一部分,是国际图联推出的FRBR(书目记录的功能需求)与国际博物馆理事会下属的国际文献工作委员会提出的CIDOC CRM这个面向对象的概念参考模型之间协调的结果。促进FRBRer(实体- 关系的FRBR)和FRBRoo的持续发展是国际图联编目组2009/2011战略计划的一部分。……FRBRoo是为了弥补FRBR中的一些缺陷而提出的。

另外查到一个比较全面的PPT——台湾中兴大学图书资讯学研究所张慧铢2012年在“資訊組織進階班”上的《FRBR家族的發展與應用》，FRBRoo（译为“FRBR物件导向”）部分包括开发过程、简介、功能、架构、FRBR和CIDOC CRM间转换对照、表演艺术应用及未来发展。摘取对“事件”的解说部分：
– 书目产品是创作和生产过程的结果
• FRBR采取“静态”的观点为其构建模型，不包括任何相关事件（events）
• 在CIDOC CRM中，事件（event）是主要的概念，时间实体（temporal entities）扮演主要的角色，是连接物件【对象】与时间（time‐spans）、地点、和关系人（agents）的唯一方式
• FRBRoo的作品概念（F27）产生一个想法，然后内容表达创造（F28）同时产生了内容表达（F2）和它的第一个载体表现（以载体表现单件（F4）的形式出现），两者共同实現了一个作品（F1），见下图（引自CIDOC CRM网站）

Work and Time
作品与时间

《Europeana数据模型入门》笔记

Europeana原来的元数据方案称为《Europeana语义元素》（Europeana Semantic Elements, ESE），基于都柏林核心（DC），将不同来源、不同格式的元数据都简化到DC这个“公分母”，其结果是源数据中原有精确信息的损失。为改变这种状况，Europeana设计了开放、跨领域、基于语义网框架的《Europeana数据模型》（Europeana Data Model, EDM）。

《Europeana数据模型入门》（摘译【理解】）
来源：Europeana Data Model (EDM) Documentation 
（原文中有较多RDF图，说明采用EDM对物件进行的语义描述）

1 导论
1.3 EDM准则
区分提供者提交的智力与技术创作（关于提供者保管的一个物件的资源包[元数据]）、其涉及的物件、以及可通过Web获取的该物件的数字表达。
遵循支持数据网（语义网）方法的建模原则，即没有一种固定模式只提供一种表达数据方法。EDM为通用模型，至少可在语义层部分互操作，同时数据保持其原来的表达性与丰富度。它不要求改变本地方法，尽管鼓励改变本地实践以改善数据的跨领域有用性，如采用公共获取词表（对个人、地点、主题等）。
1.4 如何阅读
URI涉及的命名空间：【2015-2-8更新：以下URI应当只是示例。根据Definition of the Europeana Data Model v5.2.4，EMD未用FOAF/VIAF/rdaGr2】
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
@prefix dc: <http://purl.org/dc/elements/1.1> .
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix ore: <http://www.openarchives.org/ore/terms/> .
@prefix edm: <http://www.europeana.eu/schemas/edm/> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix viaf: <http://viaf.org/viaf/> .
@prefix rdaGr2: <http://RDVocab.info/ElementsGr2/> .

2 EDM需求与设计原则提示
需求：
– R1. 区分被提供的物件与其数字表达
– R2. 区分物件与描述物件的元数据记录
– R3. 同一物件允许有多条记录，包含对物件潜在冲突的说明【因为记录可能有多个来源】
– R4. 支持由其他物件组成的物件【物件分层】
– R5. 兼容不同抽象度的描述（如遵循FRBR第一组的区分）【描述分层】
– R6. 提供可被专门化的标准元数据格式
– R7. 支持情景资源，包括来自受控词表的概念
基本动机是支持不同模型的集成，这样就可以收集并通过较高层概念关联所有原始描述。三项基本设计原则：
– D1. 允许在开放环境中集成数据：不可能预期所有贡献的数据【即不强制提供的数据格式一致】
– D2. 允许丰富功能性，可能通过扩展方式
– D3. 尽可能重用现有（标准）模型

4 数据表达为集合体（aggregation）
三个核心类资源：
• 文化遗产物件本身（edm:ProvidedCHO）【即“作品”】
• 该物件的一个或多个可访问的数字表达（edm:WebResource）某些可能被用作预览图【edm:hasView】
• 表达提供者活动结果的集合体（ore:Aggregation）【“真实的”物件（由其标识表达）与其数字视图之集合】
edm:aggregatedCHO和edm:hasView为ore:Aggregation的子属性。

5 EDM中的描述元数据
EDM包括一套“描述”和“情境”属性，捕捉资源的不同特性，同时在其情境中与其他实体关联。
描述元数据的可能方法可分为“物件中心”和“事件中心”，EDM同时遵循这两种方法。EDM还有“类”可抓取“丰富数据”。
5.1 物件中心法（Object-centric approach）
专注于所描述的物件：信息以陈述形式，直接关联所描述的物件与其特性——但只是字符串或是指示来自真实世界实体的更复杂资源。采用都柏林核心的大多数元数据实践属此（如创作者、题名、创作日期、前拥有者等）。
物件中心法对附于物件或事件的资源，并不指明特定的“语义丰富性”级别。
5.2 情景实体-更丰富的元数据（Contextual entities – richer metadata）【类】
描述元数据的某些值不关联到物件，而是关联到描述中的另一资源。如有关创作者的进一步细节——如其生卒地点与日期。在EDM中，这样的信息可使用表达创作者本人的实体来捕获。为支持对此种语义丰富的建模，并支持进一步丰富，EDM具有表达“情景”实体的“类”：
– edm:Agent 代理，用于代表个人或组织
– edm:Event 事件
– edm:Place 地点，用于空间实体
– edm:TimeSpan 时间范围，用于时间段或日期
– skos:Concept 概念，对来自如叙词表、分类法（包括某些地名辞典或个人规范档）……的知识组织体系的所有实体
5.3 事件中心法（Event-centric approach）
事件中心法认为物件描述应当关注描绘物件参与的不同事件，通过表达构成物件历史的事件，将导致建立更丰富的实体网络。此法基于CIDOC-CRM模型。
在EDM中使用三个属性表达：
– edm:wasPresentAt 参与事件的资源
– edm:happenedAt 事件发生的场所
– edm:occurredAt 事件与发生的时段
5.4 灵活的数据模型（EDM as a flexible data model）
确保语义层互操作的关键是映射，遵循语义网框架内的共同实践。
需要把专指属性映射到一个语义互操作核心，确保通用工具能利用至少部分语义。这种映射在RDF中典型地通过维护专指构建与核心构建间的语义关系来达到。
通用与专指层间的同现，允许如：
– 使用基于通用描述的索引搜索该物件【粗放索引】
– 使用由提供者制作的更精细度区别显示该物件的信息【精细显示】
这一机制事实上已经在EDM不同层的描述数据中起作用。如hasMet是指EDM中重用很多其他属性的超属性【可用于合并索引】，如创作者、贡献者、出版者。本属性将允许用户发现与某个人相关的物件，无论他们“遇到”的这个人是其主要的创作者、第二位的贡献者或是出版者。
5.5 ESE和EDM间关系
ESE所用大部分属性（DC属性）实际上构成EDM的语义互操作核心。
第一个差别是属性的使用。为兼容遗留数据及未丰富方式的数据，ESE/DC属性可用简单字符串作为值。但EDM推荐图8中首先引入的VIAF例子【即采用URI或ID】。
ESE和EDM利用同一属性方式的另一个差别是“一对一原则”的应用。ESE中，所有字段捆绑为一个记录，因之难以区分某个字段是应用于“真实世界”的物件、还是其数字表达、还是与该物件相关的任何其他实体的属性，如其创作者。而EDM允许做这种区分。

6 EDM和代理（proxies）
Europeana数据来自许多提供者，因而会有对同一资源的多个视图；此外，Europeana将试图增加对该资源的其自己数据，给出另一个视图。这些视图不会合并。在这种场合，元数据很可能不同，如同一创作者用不同名称。Europeana考虑来自ORE（对象重用与交换）模型的代理机制，可以在集合情景下表达资源，使得对同一资源有不同的视图。
6.1 代理导论
以《蒙娜丽莎》为例，有两条不同来源的记录。每个传递给Europeana的数据产生一个ore:Aggregation类的特定实例，用于组合来自同一个提供者的一个资源的所有元素。每个提供者贡献不同的数字对象集，有不同的解析度、不同的文件类型、不同的位置。
每个提供给Europeana的元数据记录也给出了所描述物件的专指代理，使用ore:Proxy资源建模。一个代理特定于一个给定的集合体，用于表达所提供物件的描述。通过代理，可能表达对所提供物件以不同的、可能冲突的信息，同时仍能追踪信息的出处。如两处《蒙娜丽莎》有不同的题名。
一个集合体对每个提供物件（CHO）只能有一个代理，因为它来自一个提供者的活动。
现阶段，如何、何时识别相同物件仍有讨论余地。如两个提供者为相同资源贡献了两个不同的URI，应采用某些识别机制在两个URI间推出owl:sameAs链接，以能“合并”资源。
6.2 Europeana代理和丰富数据（data enrichment）
Europeana为摄入的物件创建新数据，以期为用户提供更多价值。通过使用ESE格式处理标准化数据，用链接到情景实体在（词表、地名/人名规范档、主题词表）语义上丰富物件描述。这导致更丰富的功能，如提问扩展（使用创作者名称的交替形式）、使用语义关系推荐物件（关联艺术家创作的物件）等。这是关键方面，Europeana试图大规模处理这样的语义丰富，使用EDM为特定目的导入的类。
6.3 Europeana集合体和代理
Europeana集合体edm:EuropeanaAggregation是ore:Aggregation的子类，可以用来管理自己的IPR和访问限制等。
Europeana集合体采用ore:aggregates链接到所提供物件，也能集合其他资源，尤其是物件的数字表达，或使用edm:landingPage属性到其参考着陆页。关键一点是，Europeana集合体是集合关于相同物件的每个特定提供者的集合。
6.5 提供者应当提供EDM核心模式的什么部分？
期望来自提供者的最重要信息之一是区分物件本身的元数据和数字表达的元数据。
下一个问题涉及为不同物件提供URI标识符。第一个建议是提供者为网络可访问数字表达（如图片）和所提供的物件或已有永久标识的集合体提交URI。Europeana本身会注意为它创建的代理或集合体赋予或再赋予URI，它也会为所有edm:ProvidedCHO资源创建URI。【提供者和Europeana各自提供URI】
6.6 代理vs命名图（named graphs）
对于做EDM原型时，我们经常被问到为什么考虑ORE代理来表达特定资源视图，而RDF提供“命名图”的概念满足相同需求。因为命名图目前还非W3C推荐标准，但图的概念将出现在下一版RDF，到那时，Europeana当然将考虑将图放入EDM架构中。

7 高级EDM
EDM允许更复杂的表达，特别关注以下情况：
– 物件的等级
– 物件间关系，如表达作品间关系或艺术衍生
– 通过ORE资源地图明确表达数据包
本文件只表达简单的等级物件及表达链接。其他方面在未来版本详述
7.1 表达等级物件
以一幅来自荷兰的地图为例
– 用dcterms:hasPart and dcterms:isPartOf 表达包含链接
– 用edm:isNextInSequence表示物件各部分间的顺序
代理机制允许对相同物件配置多个等级视图。
7.2 物件间其他链接类型
– 两个物件描画同一地点巨石阵：
直接关联两幅图片，让用户从一个物件浏览另一个，采用Europeana目前带有十分精确信息的“进一步探索”功能，依赖于手头数据的精确程度，使用通用属性edm:isRelatedTo或（可能领域专用的）专用属性。
也可能非直接关联物件，通过说明其链接到相同资源。比如由空间覆盖判断为巨石阵（地点）
– 第二个例子是《蒙娜丽莎》的衍生作品-拼贴画，采用edm:isRelatedTo的子属性edm:isSimilarTo的专门edm:isDerivativeOf属性
Europeana还收割了一条描述《蒙娜丽莎》照片的记录，是19世纪法国摄影师所摄，采用edm:isRepresentationOf，说明这一历史图片与原画的关联

———译名说明———
（1）object=物件（正好与模型中提到的“event=事件”对应）
不采用“实物”：因为有digital object，译为“数字实物”比较奇怪，参考台湾译为“数位物件”
不采用“对象”：适应面太广、专指性不强，如“研究对象”
（2）contextual=情景
不采用“上下文”：大多数情况下并不涉及“文字”