FOLIO的元数据管理和编目业务.pdf

工作探索FOLIO的元数据管理和编目业务*宋琳琳，蔡思妍*本文系国家社科基金项目“图书馆编目数据化的理论与实践研究”（项目编号：20btq017）研究成果。0前言我国图书馆正步入关键转型期，在关于推进实施国家文化数字化战略的意见指导下，新一代图书馆系统需要实现跨层级、跨地域、跨系统的数据流通和协同治理，推动不同层级、平台和主体间的文化数据分享1。元数据作为资源组织、整合与服务的基础，是过渡到新一代图书馆系统的关键。元数据建设从专业本位转变为社会分享，“元数据就是服务”，它聚焦“实体”的多元呈现，采用先进适用技术和现代分享手段，利用“下一代元数据”(Next Generationof Metadata)框架改善信息检索方式2。下一代元数据在元数据模型上要求开发的关联数据模型灵活、可扩展；在元数据管理上强调不同格式、位置和环境中元数据的应用；在元数据发展上强调探索和尝试使多领域专家有效协作的元数据工作环境；在元数据迭代上要求图书馆学习适用BIBFRAME，同时进行传统的书目控制3。新一代图书馆系统FOLIO在元数据管理方面的创新体现为Codex的建立和编目工作的变革。Codex由FOLIO数据模型工作组负责，资源管理特殊兴趣小组和元数据管理特殊兴趣小组参与建设4。Codex应用轻量级(简化)的元数据模型来描述资源，可以映射到大多数现有的元数据模型，从而提供一个共同的词汇表。Codex提供规范化的描述，消除编码和格式上的差异以及管理方式的差别，为所有资源提供一个单一的表摘要文章从概念模型和数据模型两方面分析Codex的实体及其关系，比较Codex与BIBFRAME的异同。在此基础上，揭示Codex在FOLIO中发挥的分层次描述、解决数据纠缠、协同EMA管理实体和元数据管理等功能；从编目规则、编目工具和流程两大方面系统梳理FOLIO的编目方案及Codex的作用。关键词FOLIOCodex编目元数据引用本文格式宋琳琳，蔡思妍.FOLIO的元数据管理和编目业务J.图书馆论坛，2023，43（10）：96-107.FOLIOs Metadata Management and Cataloging ServicesSONG Linlin&CAI SiyanAbstractThis article analyzes the entities of Codex and their relationships in terms of conceptual and datamodels，and compares the similarities and differences between Codex and BIBFRAME.On this basis，it identifiesthe functions offered by Codex in FOLIO，such as hierarchical description，data entanglement solution，collaborative entity management with EMA and metadata management.It systematically examines the catalogingscheme of FOLIO and the role of Codex in two aspects：cataloging rules，cataloging tools and processes.KeywordsFOLIO；Codex；catalogue；metadata962023年第10期工作探索述，由此实现规范化。此外，Codex跨越存储位置建立资源管理的虚拟化层，保障FOLIO整合各种元数据，允许不同资源使用一个共同的词汇和描述，由此实现虚拟化。1文献综述新一代图书馆系统既与传统图书馆系统兼容，又灵活支持图书馆的各项创新。美国国会图书馆已于2022年宣布采用FOLIO平台。国内学者的研究介绍了Codex元数据模型和实体的基本情况：许磊等研究Codex与不同书目格式间的映射5、Codex元数据管理方案和FOLIO的实体管理6；周纲等介绍Codex的查询和管理资源关系的功能7；王文清等分析Codex元数据模型及其实体的特点8。较少研究从宏观视角分析FOLIO平台的元数据管理流程，尤其缺少FOLIO编目业务的探究。国外学者研究主题包括但不限于Codex方案和FOLIO编目功能。Peter介绍Codex理念9；Natascha等以典藏应用程序(InventoryApp，典藏)为核心，辅以FOLIO编目框架介绍FOLIO编目功能10；Kristen介绍Codex元数据模型、Codex记录来源及其编辑方式、Codex简要的工作流程11；Lynn等以编目为切入点概述Codex与其他域的交互，介绍Codex的实体及对应元数据元素12；Charlotte从数据导入、原始编目、复制编目和数据清洗 4 个方面系统介绍FOLIO编目功能13。笔者以FOLIO的元数据管理为核心，系统梳理FOLIO元数据管理中数据的流转与应用，从规范控制和实体管理的角度研究FOLIO的编目创新，更好地发挥元数据在资源服务中的作用。2Codex元数据模型Codex元数据模型基于“图书馆参考模型”(IFLA Library Reference Model，IFLA-LRM)，受BIBFRAME2.0的启发，在参考相关书目格式、复用通用元数据的基础上设计而成。Codex与IFLA-LRM连结，与书目世界的其他编目规则和书目格式关联。作为数据模型，Codex模型简易轻便、跨越存储位置，提供资源的单一表示和保障映射。2.1Codex七大实体Codex元数据模型14包括七大实体(见图1)，方框的实例(Instance)、单件/馆藏(Item/Hold-ings)、资源包(Container)、馆藏地(Location)和收录范围(Coverage)是模型已有的实体；圆框的作品(Work)和主题(Subject)是待添加到模型的实体。除Codex，FOLIO其他资源管理应用程序也有专用数据模型和实体，如典藏数据模型及以Codex格式编码和存储的实体15，可与Codex对应实体高效联通。与此同时，FOLIO实体管理应用程序(Entities Management Application，EMA)中已设置作品(Works)和主题(Subjects)两类实体，而现有Codex模型却未补充作品和主题实体。由于EMA注重规范控制13，因此Codex后续完善模型是必要的。作品连接连接包含连接包含资源包实例主题单件/馆藏单件/馆藏有有收录范围馆藏地包含图1Codex元数据模型14(1)单件/馆藏。虽然单件和馆藏含义不同，但从数据建模角度看，描述二者的元数据元素集存在大范围重叠，因此Codex使用同一实体表达两个概念14。单件是实例特定材质的副本，包含识别和追溯单篇文献的信息(如条码)。通过数据共享，单件从父级实例继承诸多字段。父级实例字段的变化会同步到单件。FOLIO支持在单件级别编辑继承字段。馆藏用于描述图书馆与单件的关系，以便图书馆管理。97工作探索(2)资源包。资源包是为了使Codex在资源包的层次上封装、调控资源。这种个性化定制使图书馆能够不受数据商捆绑机制限制，自定义分组资源，掌握配置资源的自主权。(3)馆藏地和收录范围。考虑到FOLIO可能需要复用馆藏地和收录范围，为说明二者的可重用性，馆藏地和收录范围被提取为实体14。二者还可以作为字段嵌套在更高级别的实体中，如资源包的元数据元素集中有可被调用的收录范围14，因此二者具有双重身份。2.2Codex元数据元素受DC最小化原则启发，Codex筛除或扩展DC的15个内容元素，形成一套通用且量少的元数据元素集。表1中的通用元素支持资源管理应用程序中各类资源的描述，既包括常用元素contributor、title 和 description 等，也包括为满足特定功能而设计的 Instance：id，Item：isCustomized 和 Location：parking 等。因此，Codex不仅在揭示和描述资源上具有简单高效和统一管理跨媒体资源的特点，还有与其他元数据模型进行语义互操作的可能。2.2.1特有元素与功用(1)实例的元素：source是返回到源记录的链接，允许图书馆从源记录中提取更多描述性元数据，表明Codex的目标并非提供资源的完整描述，而是提取支持图书馆正常运作的关键元素。identifier为图书馆提供可自定义的类型和值，使Codex资源描述更灵活。(2)单件/馆藏的元素：isCustomized用于指示单件继承父级实例的状态，允许单件覆盖父级实例所赋值。这在外部知识库更新时十分必要；在FOLIO外部编目时，为防止图书馆无法编辑相关实例字段，覆盖操作是图书馆在单件级别控制相关内容的有力措施。(3)馆藏地的元素：parking提供可由图书馆自定义的类型和值(如Name=LC Call Number，Value=PN2001.R2502022)，用于定位馆藏。2.2.2元素来源Codex元数据元素来源广泛，有的由系统自动匹配，如Instance：id是用于区别平台多来源元数据的特定编号；有的源于DC，与DC中的对应元素基本一致，如Instance：contributor；有的继承父级实例，强调元素的复用和跨层实体的数据共享，如Item：title；有的直接调用别的实体，被调用的实体作为一个数据对象发挥效用，如Container：coverage。2.3与IFLA-LRM的联系在元数据模型构建中，Codex基于IFLA-LRM层次结构，在EMA作品实体辅助下，通过“集群作品-作品-实例-单件/馆藏”细分实体类型，与IFLA-LRM建立连结(见表2)。EMA作品实体中包含LC Hubs和Share-VDE Opus一类的集群作品(Clustered Work)，能够聚合和配置关联作品。IFLA-LRM的“资源(Res)”表示为所有作品的“超类”，同样位于实体的顶层，二Codex实体Instance实例Item/Holdings单件/馆藏元数据元素idtitlealtTitleseriescontributorpublisherdatetypeformatidentifiersourcelanguagerightsversionlastModifiedidinstanceiddescriptiontitlealtTitleseriescontributor(s)publisherdatetypeformatidentifier(s)language(s)rightscopyNumberbarcodeCodex实体Items/Holdings单件/馆藏Container资源包Location馆藏地Coverage收录范围元数据元素vendorPackagecoveragelocationitemStatusisSelectedisCustomizedididentifiernamedescriptiontypevendoridvendorplatformitemsitemCountselectedCountcoverageisSelectedidinstitutioncampuslibraryparkingplatformuriidrangestatementembargo表1Codex已实现的实体及其部分元数据元素14982023年第10期工作探索者表现出良好的对应性。此外，IFLA-LRM的“命名(Nomen)”表示实体与指称该实体的名称间的关系，与EMA的主题呼应。Codex数据模型中，实例混合FRBR的内容表达和载体表现，因此可与IFLA-LRM进行对应处理。实例代表一些相对具体的东西，如资源类型(电子读物、印刷读物、有声读物等)；不同实例可能汇聚于发现层中。而作品是图书馆将实例聚集在一起的一种方式，支持查找相关实例。虽然Codex与IFLA-LRM层次结构并不完全一致，但彼此的对应为Codex与各种元数据模型的兼容提供保障。在EMA的辅助下，Codex元数据管理更加立体、系统，有助于全面揭示和充分表达资源间的关系，实现资源的互操作和开放共享。表2IFLA-LRM与Codex、EMA间的实体关系IFLA-LRMRes资源Work作品Expression内容表达Manifestation载体表现Item单件Nomen命名CodexWork作品Instance17实例Item/Holdings单件/馆藏EMAWorks(LCHubs，Share-VDEOpusetc.)16作品(含LCHubs，Share-VDEOpus等)Subjects主题2.4Codex与BIBFRAME2.0Codex和BIBFRAME2.0均注重表达实体关系 和 实 现 关 联 数 据 功 能。Codex 受 到BIBFRAME2.0的启发，二者在模型架构和实体设 置 上 具 有 较 高 的 相 似 性。Codex 对BIBFRAME2.0的借鉴主要有以下考虑：一是未来一段时期内，MARC 仍会存在于图书馆，Codex需要满足图书馆既坚守MARC，也拥抱BIBFRAME的需求；二是BIBFRAME2.0支持聚合不同来源的记录以提供资源管理的完整视图，这与Codex集成FOLIO中任何资源以提供单一表示的愿景不谋而合17；三是其他书目格式致力于与BIBFRAME2.0兼容发展，这使得Codex在与这些书目格式映射时具有一定的原生优势。为实现Codex在FOLIO中的中介与虚拟作用，Codex并不严格遵循BIBFRAME2.0，二者间的差异主要体现在：一是Codex中的资源包强调在该层次上对资源的个性化分组，凸显了Codex 对 资 源 管 理 的 支 持。二 是 相 比 于BIBFRAME2.0，Codex元数据模型并没有提供区别作品和内容表达的方法，但从聚合资源角度，为避免混淆作品和内容表达的概念、更契合IFLA-LRM模型，Codex在现有基础上新增集群作品较为可行。三是Codex在类、属性和元素的设计方面具有特点。FOLIO决定资源类型大致对应RDA内容类型，支持图书馆从RDA中取值，也允许图书馆添加额外的词汇表并自定义本地资源类型值。目前 FOLIO 外部编辑工具兼容BIBFRAME等格式；图书馆还可调用应用程序编程 接 口(Application Programming Interface，API)实现实体映射，并在实体管理工具的作用下进行规范控制。3基于Codex的FOLIO资源管理3.1分层描述体系域、模块和应用程序是FOLIO资源管理的核心概念。域是模块或应用程序的组合，如Codex 域包含应用程序 Codex Search、模块mod-codex-mux和mod-codex-ekb等。一个应用程序通常包含多个模块18，如典藏包含模块 mod-inventory 和 mod-inv-storage。不过，模块的定义更为广泛和宽松，有时也会代表FOLIO的微服务19。FOLIO的核心是资源管理，对各域资源描述的广度和深度不做同一化要求。比如，采购域关注所购资源的价格，而编目域不会注重采集与存储同资金交易相关的信息18。FOLIO根据资源描述的细节深度和服务目的将其分为不同层次，形成分层描述体系，见图2。在 分 层 描 述 体 系 中，从 统 一 记 录 层(Unifying Records)到 业 务 记 录 层(WorkingRecords)，再到正式记录层(Formal Records)，资源描述的广度依次下降而精度逐层提升，见表3。在实际应用中，位于顶层的 Codex 借助99工作探索Codex Search，深入到业务记录层(如典藏)再到正式记录层，无须顾虑资源编码和格式差异，搜索与定位平台所有资源。比如，馆员想要查看西游记的详细编目记录，首先使用CodexSearch锁定典藏，随后基于业务记录层和正式记录层间的连接，查看 西游记 的底层编目记录。3.2解决应用程序间的纠缠问题在FOLIO中，理论上模块只需关注与保障自身功能的交付，但在实践中域总是作为整体发挥作用，域内模块间存在必要的交互以保障域的高效运作。在交互时，模块可以保留其他模块的接口信息，以自我为中心建立多重连接，但这必然与其他模块产生依赖，导致模块纠缠，降低平台灵活性。FOLIO通过Codex实现模块间的交互。Codex充当代理的角色，集成各模块，将繁杂的交互关系转化为线性依赖，进而使平台成为立体架构。模块无需管理自身与其他模块的关系，只需与Codex集成18。实际应用中，图书馆为确保用户访问资源，可能在多个系统上重复购买电子书。Codex的引入为资源管理提供了统一完整的视图，使得图书馆可以从顶层出发访问不同域的资源，确保图书馆不会迷失在不同域中而重复购买资源，节省成本。在微服务理念的指导下，FOLIO通过Codex联系各个部分以支持彼此交互，将待处理问题由大化小。Codex的代理角色被认为是FOLIO有别于传统集成图书馆系统的一大亮点。3.3协同EMA管理实体FOLIO中各域基于实体完成本域的既定任务，并依赖实体在不同域间构建的关联实现域间协调运作，由此可见实体及其有效管理在FOLIO中十分重要20。Codex的实体通常会与EMA的实体整合应用。考虑到FOLIO大型管理任务或工作区域一般配有相应程序以提供专门功能，实体管理工作组将EMA作为其工作区域单独的应用程序13。EMA 是 FOLIO 集成内外部实体的桥梁，是 FOLIO 管理受控实体的中心。对于FOLIO内的实体，EMA为本地定义的实体提供持久的 URI 创建、维护、发布和存储。对于FOLIO 外的实体，当其被导入到 FOLIO 时，EMA会发现和报告，并与导入实体匹配。EMA与Codex的区别在于：Codex是一种规范极简的元数据模式，旨在处理FOLIO的描述性元数据，包含FOLIO所有应用程序必须理解的高级子集，侧重于管理整个平台的资源。而EMA侧重于实现资源规范化、高质量的描述，同时扩展资源的关联范围，支持FOLIO存储任一元数据模式16。首先，EMA能有效解决众多书目格式的规范化问题，这无疑减轻了平台的压力和复杂性。EMA集合并统一维护需要规范控制的实体(包括代理、类型、地理、主题、作品、其他实体)，保障资源描述的质量，促使平台资源与外界资源互联互通。其次，不是每一个实体都需要规范控制。EMA缓存LC主题词表、LC名称规范表等关联数据词表16，解决传统MARC编目的重图2FOLIO分层描述体系18资源的统一视图资源的功能视图典藏Codex统一记录层知识库订单应用程度业务记录层正式记录层数据导入应用程序源记录描述细节增多表3FOLIO各记录层内容、特点和功能的简介层级统一记录层业务记录层正式记录层对象内容Codex域应用程序工作域源记录域特点服务于Codex跨域资源管理中间层，Codex提取记录基础服务于Codex的归一化功能FOLIO管理全域资源的统一入口向下与底层记录连接获取完整记录，向上集成到Codex中与其他应用程序交互，建立资源管理层间的连接提供FOLIO最详细的记录，包括原始书目记录和其他记录1002023年第10期工作探索复劳动问题。因此在数据规范方面，Codex借助EMA专门规范控制功能，更兼具模型轻量和资源单一表示的优势。3.4元数据管理流程3.4.1导入FOLIO有两种主要的生成Codex记录的方式，如图3所示。第一种是导入的书目数据生成Codex记录。在此情形下，图书馆可从各类知识库中下载并导入完整的书目数据到FOLIO编目域。导入到正式记录层的书目数据在FOLIO默认值映射器的作用下，被获取、分解并放置到典藏对应实体中22。基于典藏数据模型与Codex模型在实体方面的映射关系，书目数据被提取、转换格式并存储，关键的元数据便输送到Codex以创建或更新Codex记录。同时，馆员能在FOLIO的编目域以本机格式编辑导入的书目数据，所做更改随后同步到对应Codex记录。第二种是基于API创建Codex记录。Codex域通过已有API将可用于创建Codex记录的元数据字段从外部知识库(如OCLC或LC)传输到自身域。因此，FOLIO中一般没有与Codex记录对应的源记录。比如，查尔姆斯理工大学图书馆的书目数据主要源于外部知识库，主题标题和注释等数据一开始并未在FOLIO中完整存储，而是在外部知识库中。无论资源是在本地还是在平台外部，最终均可映射转换为 Codex 记录，插入到Codex元数据模型的相应层次中，在不同实体级别借助各元数据元素揭示和描述资源。Codex也以这些记录作为其跨越存储位置管理资源的基础。3.4.2映射Codex作为各域的共同交叉点，与各模型连接，做到管理资源而不管其格式、编码和存储位置的差异18。基于Codex的中介作用，Codex仅提取各域的关键数据用于实现检索和非编目功能，同时最小化元素集，尽可能降低与其他域的重复程度。(1)映射的规则。FOLIO中，处于统一记录层的Codex从下层中提取关键且适用于全局资源管理的元数据，表面像是每个域都引用Codex，由此体现Codex元数据模型的分布式特点。以原始书目数据的映射为例，典藏是关键的映射中介。其数据模型及实体，特别是与Codex实体一致的资源包、实例、馆藏和单件，既规范书目数据，也是Codex提取记录的基础。一般情况下书目数据在导入到典藏的实体字段前需完成格式转换，转换逻辑由映射规则定义。基于映射规则编辑书目数据并将其分配给典藏对应的实体属性，由此实现原始书目格式到Codex格式的归一化。以典藏中MARC记录映射到实例为例，映射规则在JSON的Rule元素中描述，作用于MARC记录的001字段，提取相关值放置在实例的人类可读 ID(HumanReadable ID)字段中23。映射中的数据整合，为保障Codex元数据框架适应更广泛的资源类型和记录结构，处于正式记录层的源记录在映射到Codex时，由原来的三层结构整合为Codex两层结构，见图4。具体映射元素与关系见表4。映射中的数据调取，借助Codex中指向源记录的指针17，如Codex实例中的source元素。图3FOLIO描述性元数据导入图例21图4从源记录结构映射到理想的Codex结构24实例馆藏单件源记录结构实例单件/馆藏拟议Codex映射检索和非编目工作流程转换参考FOLIOCodex复制编目工作流程动态格式转换器参考编目工作流程外部知识库详细记录原始格式的记录如MARC、BIBFRAME、EXIF和NISO MIX101工作探索表4Codex部分实体部分元素的映射示例24元数据元素实例title实例contributor单件/馆藏publisher单件/馆藏location单件/馆藏coverage简要的映射情况映射自MARC245，子字段abcfghknps可重复字段，映射自MARC700，710，711和730；关系由RDA定义映射自MARC264，子字段b映射自MFHD852|b映射自MFHD85X/86X匹配字段或866摘要(2)映射数据的存储。此处存储的映射数据指向Codex记录。目前Codex记录在规范化的关系数据库中进行本地存储17，然而Codex域缺失存储模块。对域中应用程序来说可能需要单独的数据存储模块以有效管理资源25，因此Codex域需实现数据存储功能。3.4.3应用作为资源管理的核心，Codex可以使图书馆检索跨域资源、定位全域资源、追溯底层资源、构建资源联系和共享跨平台资源等。(1)资源的检索、定位与追溯。Codex Search具有统一检索资源的功能，有两种部署模式。一种是作为单独的应用程序，使用通用简化的元数据模型定位资源。在此情况下，Codex Search开放接口供各域部署，作为资源查询的起点，在锁定资源来源后深入到对应域中进行更为细致的检索，以追踪到源记录。另一种是作为嵌入式组件部署在各域中，由此在任一域中发现其他域的资源。如图5中订单应用程序可以基于嵌入式Codex Search定位和追溯知识库中的资源，以便选择和提取需要的数据创建订单。(2)创建资源间的关联。资源间宏观关系以分层描述体系为切入点，统一记录层的Codex和业务记录层的不同域间存在关联，搭建一条逐层向下深入的线路，以聚合和管理全平台的资源。资源间微观关系以Codex和各域元数据模型实体的关联为切入点。假设电子馆藏应用程序的电子资源和典藏的纸质资源存在关联，相比于在任一应用程序中创建作品实体的做法，Codex提供作品实体并将其连接到两个应用程序中，既避免各应用程序额外的工作量，也解决其间的纠缠问题18。此外，Codex的实体能依据图书馆具体需求在FOLIO各域间灵活创建关联。如图6所示，以Codex中单件/馆藏实体与知识库、典藏的关联为例：假设图书馆需要购买新的电子资源，基于Codex在典藏和知识库间创建的关联，馆员能知悉平台已购知识库资源包中的单件情况，在确认资源包内无重复电子资源后做出采购决策。(3)跨 平 台 的 资 源 共 享。Codex作为资源管理的核心，保障图书馆的信息资源共享。如图7所示，图书馆基于Codex跨越资源存储位置的优势，与馆内外资源实现互动。首先图书馆联盟开放典藏，方便联盟成员馆A和B的Codex各自从中提取数据，自此二者均有本地和共享典藏的数据。各馆间信息资源共享的范围是可选择的，如A选择集成联盟的采购域而B没有18。基于此模式，各馆也可开展联机合作编图5基于Codex的资源定位图示18图6基于Codex部分实体的资源关系构建图示26知识库参考Codex参考典藏资源包实例单件馆藏地馆藏地单件/馆藏收录范围有有包含实例包含包含包含主题资源包作品资源包供应商题名包含有有有有馆藏地供应商资源包名称提供订单应用程序采购域典藏采购域部署CodexSearch界面，订单应用程序包含伪资源知识库典藏和知识库部署CodexSearch界面Codex检索界面将包含来自订单应用程序的伪资源和典藏、知识库中的资源1022023年第10期工作探索目。图书馆基于Codex从联盟的FOLIO中获取资源以创建联合目录，并在平台运作过程中根据需要创建或添加应用程序，通过合理布局，尝试新的编目工作模式。4FOLIO编目业务的实现编目作为FOLIO元数据管理的核心功能之一，能够增强资源内容揭示和表达，推动知识组织与融合，有利于网络环境下的资源发现和信息资源共享。4.1Codex与编目的关系Codex与编目间存在双向流动关系。编目数据是生成Codex记录的基础；Codex揭示和索引各来源的编目数据并以全局视角进行管理27。FOLIO的编目与传统编目有很大不同：从编目的出发点和所处环境来看，FOLIO的书目数据大多迁 移 自 外 部 系 统，这 就 需 要FOLIO解决外部编目工具和书目格 式 不 统 一 的 难 题。现 阶 段FOLIO按工作场景分为内外编目两条路径，其中外部编目能有效利用平台外部现有的书目数据，这些非原生的书目数据处理后将被映射到Codex对应层次以在全平台发挥效用。4.2遵循RDA编目规则FOLIO在元数据管理中遵守国际标准，使用RDA辅助定义资源类型、格式类型和材料类型，使FOLIO按差异区分和过滤实例和单件等记录，实现高效检索。基于RDA面向全部类型的资源这一特点，假设MARC在某一字段描述内容类型，则该区域会过滤掉非内容类型的信息(如一张地图的图像)。格式类型对应 RDA 载体类型。同资源类型一样，格式类型允许添加额外的词汇表和自定义值。以上两种类型在实例级别实行映射操作。材料类型本质是一个特定于单件的值，在单件级别进行映射。不同的是，材料类型不需要从规范词汇表中派生，图书馆可以根据需要定义。4.3编目环境与编目工具FOLIO实现的编目功能包括但不限于管理物理或虚拟的资源集合、导入和导出书目数据、编辑MARC记录和创建实例、馆藏或单件记录28。实现上述功能依赖的FOLIO元数据管理环境和以BIBFRAME、MARC为代表的书目数据在各模块间流动，如图8所示。现阶段FOLIO除建设平台内的编目工具quickMARC、实体管理程序、源记录存储程序外，还借助外来编目数据和工具(如OCLC Connexion)实现编目功能，呈现兼容并包的态势。FOLIO编目功能的实现离不开多种内外部编图7基于Codex的信息资源共享功能的实现18图8FOLIO元数据管理环境29图书馆联盟Codex采购城知识库典藏图书馆ACodex采购域知识库典藏图书馆BCodex采购域典藏采购和公共服务等编目和元数据管理图书馆用户FOLIO采购域等典藏实例馆藏单件EMA代理类型地理主题作品其他实体源记录存储MARC BIBquickMARCquickMARCBIBFRAMEEditorSinopiaOCLCConnexionOCLCConnexionBlacklight发现&获取外部规范和实体数据(LCNAF、Getty等)103工作探索目工具的密切合作。按功能将编目工具归为实体管理类、内部编目类、外部编目类，如表5所示。其中，EMA会以集成FOLIO内外关联数据的方式与内外部编目工具交互，以实现内外实体管理。内部编目工具的关联主要有以下两种：一是数据更改发生于典藏或quickMARC时，更改同步到源记录存储；二是当有外部数据导入时，源记录存储和典藏会有相应的数据更新。此外，具有检索、浏览MARC规范记录的MARC规范控制应用程序(MARC Authority App，MARC规范控制App)需要借助quickMARC更改MARC规范记录。外部编目工具指非FOLIO平台所使用的编目工具，如OCLC Connexion、BF编辑器等。例如，Sinopia的BF编辑器将BIBFRAME记录映射到典藏以更新数据，同时未来需要与EMA集成以在FOLIO中管理外部实体29。随着图书馆管理平台的升级，图书馆的大量数据在迁移中，相比于重构支持不同书目格式的编目工具，更倾向于和外部成熟的编目工具兼容整合，这也是FOLIO的主流编码方式。表5编目相关程序与工具类别实体管理类内部编目类外部编目类编目工具或程序EMA、MARC规范控制App源记录存储、quickMARC和典藏各种书目格式编辑器4.4书目数据处理流程4.4.1数据导入数据导入的路径与数据格式相关。MARC书目数据导入策略，取决于图书馆存储需求。若选择源记录存储，导入的数据将被分解并用于创建不同类型的记录(如条码)，同时完整存储在FOLIO中22。若未选择源记录存储，数据导入应用程序根据MARC字段的映射配置，将导入记录的字段映射到对应应用程序，而不完整存储。非MARC格式的书目数据导入，需借助数据模型实现不同格式的映射转换。以BIBFRAME为例，在Sinopia与FOLIO结合的基础上，斯坦福大学图书馆在Sinopia的BF编辑器与FOLIO之间建立API以链接到FOLIO后端，并基于典藏数据模型将BF编辑器中的书目记录映射到典藏，以实现典藏对应记录的创建或更新30。根据图书馆的需要可以导入单条记录或基于API导入批量记录并传送到典藏中，如FOLIO当前支持集成OCLC的单记录31。4.4.2数据缓存平台内部完整详细的编目数据的源数据存储，目前仅支持MARC格式。图书馆可以使用quickMARC编辑目标MARC记录，其对应的源记录和典藏实例记录随即会被更新。位于业务记录层的典藏能通过实例的Metadata Source元素返回到位于正式记录层的源记录，也可以映射到位于统一记录层的 Codex 实例的 source 元素32。由此Codex记录可以基于source元素提供的指针，逐层向下深入到源MARC记录以查看完整编目数据。数据存储在保持数据完整性、实现规范记录同步和支持实体管理等方面有至关重要的作用。源记录存储中的规范记录不仅应与EMA中的匹配记录保持同步，还应自动标记新的实体记录以便EMA轻松审查。虽然当前的FOLIO仅支持MARC格式的数据存储，但未来图书馆可以重构FOLIO模块，设置不同书目格式的存储。例如，尽 管 现 阶 段 图 书 馆 还 需 借 助 Sinopia 存 储BIBFRAME记录，但后续有望将Sinopia API重构为FOLIO模块，将BIBFRAME格式的书目数据存储在平台中，以实现FOLIO内BIBFRAME记录管理33。4.4.3数据编辑FOLIO编目数据的编辑可按其工作场景分为FOLIO平台内、外部2种类型。内部的数据编辑，针对直接导入的MARC书目数据，FOLIO根据其有无底层MARC记录选定数据编辑软件。有底层源记录的，馆员应在编目域中使用quickMARC，所做更新将同步到Codex记录、典藏和源记录存储。无底层MARC记录的，馆员可直接在典藏中编辑。基于API创建的Codex记录，馆员根据外部知识库是否支持主记录编辑选择编辑方式。若支持，平台内外的记录均会基于API得以更新并达到同步。若不支持，图书馆可1042023年第10期工作探索以在不影响外部知识库书目数据的情况下创建自定义覆盖。同时，FOLIO会向外部知识库维护人员报告问题，告知其更改主记录以保障书目数据的一致。外部的数据编辑，现阶段有的图书馆借助OCLC Connexion 和 MARCEdit 在 FOLIO 外进行 MARC 格式的原始编目，并在 FOLIO 内借助 quickMARC 简 单 编 辑 书 目 数 据。同 时quickMARC 会与 MARC 规范控制 App 协同使用，支持图书馆搜索、浏览并在有需要时编辑MARC规范记录。如此不仅能够解决原FOLIO编目功能较弱的问题，还能够管理外部实体，实现规范控制。例如，理海大学使用了 OCLCConnexion并认为其可为每本书配备唯一对应的OCLC编号以实现书名一一对应34。4.4.4规范控制规范数据在书目数据迁移过程中的识别、定位、整合等环节发挥着关键作用。图书馆在系统升级和平台转换中，面临着多来源书目数据格式不统一、规范文档不一致、迁移后数据缺失或冗余、相同与相似资源无法关联整合等问题，都需要借助规范控制，通过实体管理来解决。目前FOLIO编目中规范控制由MARC规范控制App和EMA共同完成。前者将支持馆员查看已连接到规范记录的MARC书目记录，或删除MARC规范记录等，以满足馆员在MARC书目记录与MARC规范记录间建立关系，实现规范控制的需求35。除此之外，在FOLIO Orchid版本中有望实现MARC书目记录随MARC规范记录的更新而更新36。EMA跟踪内外部数据变化以保持内部数据的及时性和准确性，此处的内部数据指向存储在FOLIO中的数据，外部数据包括但不限于各类型主题词表。例如，典藏会为MARC字段提供“链接”选项37，以在无源记录的实例记录和EMA对应记录间建立关系。图9展示了各类书目编辑器和规范控制程序的关系。虽然MARC规范控制App和EMA均涉及实体管理，但二者发挥的作用有所差异。MARC规范控制App的规范记录(如标题等)除保存在源记录存储中，还保存在EMA中，即MARC规范控制App实现的规范控制功能实际上可视为FOLIO整体实体管理的重要组成部分。换句话讲，MARC规范控制App实现的实体管理功能只惠及与其存在交互关系的编目数据。而跨程序管理资源的EMA，则面向FOLIO内外各类实体管理。例如，导入OCLC Connexion的MARC格式的实体后，MARC规范控制App主要对MARC规范记录进行浏览等基本操作(如图9中的路线所示)，而quickMARC应当将实体的标题自动连接到EMA匹配记录以实现外部实体的规范控制(如图9中的路线所示)16。同时，随着FOLIO与外部环境的交互日益密切，EMA可有效实现外部编辑器的书目数据和规范记录同FOLIO的整合。EMA对书目格式的兼容性更高，“满足了基于实体的数据模型(如BIBFRAME)的需求”16(如图 9 中的路线所示)，支持非MARC格式的实体管理，这在一定程度上保留了尽量多的原有书目格式，避免格式变换中实体