Web收割工具的描述型元数据功能评析*

臧国全 李 哲

（1 郑州大学信息管理学院 郑州 450001；2 郑州大学公共管理学院 郑州 450001）

1 引言

人类社会进入了因特网时代，Web资源已成为人们使用信息资源的主体。但是，因特网是一个动态网络，通过其发布和传播的Web资源随时可能消失，因此，保存Web资源的历史完整性和连续性就成为了因特网时代的一项社会职责。

目前，不少信息机构已开始履行这项职责，建立Web保存项目，长期保存这类数字化知识遗产。保存的前提是收割，保存的目的是供用户日后访问使用。收割需要使用Web收割工具，访问需要使用描述型元数据。如果Web收割工具可以自动生成描述型元数据以支持被收割内容的自动发现，不仅可以显著提高元数据的生产效率，实现元数据生产的规模化，也可减少Web保存的成本，甚至可提高Web保存信息的描述质量，高效地满足用户对它的发现与使用。

因此，我们有必要通过访问相关专业网站，考察Web收割工具描述型元数据功能的现状，评估收割过程对元数据功能的支持程度，并在此基础上，分析Web收割工具描述型元数据功能所涉及的一些基本问题，提出解决这些问题的基本思路。

2 Web收割工具描述型元数据功能的现状评估

2.1 方法

本研究中的Web收割工具选自国际因特网保存联盟（IIPC）2017年发布的《Web收割工具目录》[1]，选择的主要标准是具有描述型元数据功能。

评估项目有两个：一是工具的基本情况，包括主要作用、收割形成的文件类型、与其他工具之间的关系；二是工具的元数据功能，包括工具采用的描述型元数据方案、收割过程中自动抓取的元数据元素、用户可赋值编辑的元数据元素、可被输出应用的元数据元素。

评估过程分三个阶段：首先，访问网站，浏览分析有关收割工具的介绍；其次，下载安装或注册试用这些工具，对描述型元数据功能逐一考察；最后，联系工具创建者，征求其对考察结果的意见，核实实验准确度，完善实验结果。

2.2 结果

常用Web收割工具的描述型元数据功能考察结果见表1。

表1 常用Web收割工具的描述型元数据功能考察结果

Web Archive Discovery[9]功能：开源工具，主要功能是实施Web收割后，提供Web保存的全文检索。方法：使用WARC的索引工具分析以WARC和ARC格式保存的Web文件内容，将分析结果传送至Apache Solr服务器，生成索引；检索者通过客户端工具检索Solr索引，生成查询结果生成文件的类型：WARC和ARC格式与其他工具的关系：Solr索引，是实现该工具核心功能所需的外部工具采用的元数据方案：JSON。该工具将对WARC和ARC文件的解析结果生成JSON格式文件，用于SOLR检索可自动赋值的元数据元素：描述型有抓取日期、URL、内容类型等；管理型有来源文件、服务器、主机、hash函数等用户可赋值编辑的元数据元素：无。所有描述型元数据元素都可自动生成可输出被外部使用的元数据元素：所有的元数据元素都可被导出Web Curator Tool[10]功能：开源Web收割工作流程管理工具，包括收割内容的许可和授权、内容选择和范围划定、收割活动实施和质量检查以及存档保存等生成文件的类型：WARC和ARC格式与其他工具的关系：使用Heritrix 收割Web内容，使用WARC文件为最小保存单元，可结合使用Wayback Machine和Rosetta DPS采用的元数据方案：DC可自动赋值的元数据元素：抓取日期并自动计算记录在dc:date字段中。其他的描述型元数据元素需用户添加用户可赋值编辑的元数据元素：Web资源的名称、所有者、注释以及DC中描述字段中的其他基本元素可被外部使用的描述型元数据元素：所有元数据都添加到WARC和ARC格式的文件中。当这些文件被提交到保存系统中时，这些元数据也都将存储在提交信息包（SIP）中Webrecorder[11]功能：免费的社交媒体收割工具，可抓取用户的社交过程，包括交互内容、交流语境、动态多媒体、复杂JAVA脚本等；严格按照时序收割用户交流过程中涉及的Web页面和其他数字对象，保存用户的真实使用经历。收割结果以WARC格式文件保存。网站抓取和保存对象的回放使用同一软件，称为对称Web保存法生成文件的类型：WARC格式与其他工具的关系：无采用的元数据方案：JSON可自动赋值的元数据元素：描述型有创建者、标题、抓取日期/时间、存档文件格式、URL等用户可赋值编辑的元数据元素：无。该工具声明将开发这类元素可输出被外部使用的元数据元素：所有生成的内嵌于WARC文件中的元数据元素都可以被调用

2.3 结果分析

由表1可知，虽然不同收割工具的元数据功能不尽相同，但总体上对描述型元数据的支持程度都不高，具体表现在：

其一，大部分收割工具都获取并存储了技术型元数据，以便准确地重构和再现收割的Web信息资源，但获取描述型元数据的不多，因为收割的文件中描述型元数据本来就很少。因此，在工具内部甚至工具外部由人工创建描述型元数据就成为了常见的补充方法。

其二，除非原始网页的创建者在创建网页时就习惯性地在相应标签内（如HTML格式网页的meta标签）嵌入更多描述型元数据元素，否则自动生成这类元素比较困难。

其三，几乎所有收割工具都抓取网站标题和收割日期作为描述型元数据元素，但有时自动抓取的元素内容是无效的，比如，网站标题“主页”和“标题”等无实质内容描述。

其四，并不是所有的工具都以相同的方式定义描述型元数据，表现在两个方面：一是采用的描述型元数据方案不一样，有DC、JSON、CDX、WARC等；二是自动生成和人工赋值的元数据元素不尽相同。

如何提高Web收割工具的描述型元数据功能？笔者认为可从以下两个方面着手：

其一，针对Web特质，建立对其进行描述的元数据方案。据OCLC（联机计算机图书馆中心）考察，业已存在的描述型元数据方案对Web描述的支持都较差，还没有出现一个完全适合Web的描述型元数据方案。本文对部分收割工具的描述型元数据功能进行了考察，并征求收割工具开发者对考察结果的意见时，部分开发者表示要积极寻求用户反馈，以确定对用户有价值的元数据元素；另一些期望与图书馆、档案馆和博物馆等信息机构合作研究出一个适合Web描述的元数据元素集合；还有一些期望图书情报学界制定出台一个用于Web描述的元数据方案。实际上，这个元数据方案是收割工具提供元数据功能的前提，正是因为它的缺失，收割工具无章可循，各行其道，一方面导致混乱，另一方面其针对性和适用性无法得到保证。这是目前Web收割工具的描述型元数据功能欠佳的原因之一。

其二，收割工具自动抓取或产生元数据元素的描述内容，实现自动赋值。这里涉及三个问题：一是收割工具需设计该项功能，这是工具开发的技术问题；二是从Web网站和页面中自动抽取元数据的赋值内容，这是自然语言自动理解和多媒体的自动描述问题，也属于技术问题；三是Web页面的脚本标记中包含所需的赋值内容，比如Web页面源代码标记语言中的元数据标记（如HTML的meta）中包含元数据元素所需的赋值内容，这是规范使用Web页面的元数据标记问题，需要强化Web管理来规范Web内容创建者的元数据构建行为，属于管理问题。目前，上述三个问题的解决方案都不到位，不少收割工具的元数据功能设计欠佳，甚至缺失；自然语言自动理解和多媒体的自动描述技术仍不成熟，准确度还没有达到规模化应用水平；Web页面创建虽有技术规范，但管理规范仍然缺失。这是Web收割工具的描述型元数据功能欠佳的原因之二。

3 Web收割工具的描述型元数据功能分析

由上分析可知，Web收割工具描述型元数据功能的实现涉及两个问题：元数据方案的建立和元数据赋值的自动化。第二个问题的解决更多的不是依赖于图书情报学，而是依赖于技术和管理；第一个问题的解决则纯粹是图书情报学的任务。因此，本部分仅探讨第一个问题，即对构建适合于Web的描述型元数据方案所涉及的一些基本问题进行分析。

3.1 构建的基本原则

虽业已存在多个描述型元数据方案，如DC、MARC等，但均无法完全反映Web站点和专题Web站点集合的独特性质，比如URL、站点内容的动态性等。因此，Web描述元数据方案宏观上至少应该在以下几个方面有所体现：

形式上，独立于Web保存机构和现有元数据方案；但需与相关元数据标准兼容，以备交换元数据标引结果和细化元数据元素之需要；目的上，满足最终用户和元数据实践者（一般也是保存机构）对Web保存与检索的需求；内容上，定义了一套简洁的描述型元数据元素，并附使用说明以指导元数据标引实践；方法上，融合图书管理中的目录式描述方法和档案管理中的存档式描述方法，建立既可进行简单标引又可在需要之时进行详细描述的弹性实用的Web描述元数据方案；实践上，可实现大规模自动标引，这就要求既无需深度描述，也无需随着时间推移进行大规模迁移和转换，以满足标引对象数量巨大的要求。

3.2 在线站点的描述与存档站点的描述

不少图书馆和档案馆等信息机构同时建有实体（存档）Web数据库（如Archive-It）和虚拟（在线）Web数据库（如学科导航），既需要描述存档站点，也需要描述在线站点，因此Web描述元数据方案应兼顾这两类站点。但是，我们需在元数据设计时考虑两类站点的不同之处。

价值上。在线站点提供最新信息，具有现实价值；存档站点提供历史信息，具有长期的研究价值。如，收割美国白宫网站的不同内容版本并存档，可以用来研究美国近三届政府在环境保护政策方面的不同之处。

访问链接上。在线站点元数据描述的是当前版本，随着站点消失，其访问URL将导致死链。但是，当在线站点被收割存档后，其访问链接指向存档版本，既不会消失也不会产生死链。

日期记录上。在线站点元数据的记录日期可能是它被描述时的浏览日期，或是首次上线的日期。但存档站点的抓取日期很重要，应在其元数据中予以描述。当收割并存档一个站点的所有不同内容版本时，可根据抓取日期浏览该站点的演变历史。

访问限制上。绝大部分在线站点均可公共访问，且无访问限制。但存档站点的访问权限取决于存档机构，在访问机制建立前，存档站点一般仅供现场访问。

因此，同一个站点的在线版本和存档版本的元数据描述不完全一样。如果一个机构期望两个版本同时被描述从而提供用户访问，可设计一个元数据方案，但须兼容两者的不同之处，比如稳定的访问URL。从成本效益角度来看，这种方案可能是一个比较理想的选择。

3.3 目录式描述与档案式描述

前者主要用于图书馆对馆藏数字资源的著录，著录内容来自描述项内容的抽取，主要元素有标题和主题词。后者一般是一组来源相关的未公开发表信息资源集合存档的一种描述方法，标题是基于存档内容概括设计出来的，而不是抽取出来的，且常常使用大量文本型注释描述存档内容的语境。许多存档Web资源集合都是专题性Web资源选择与收割的结果。

两种描述方式的一些元素是相同的，尤其是检索点，比如，主题词、Web信息资源的类型、人名、组织机构名、地理名称等。

图书馆和档案馆是实施Web保存的主要信息机构，目前这两类机构的Web存档实践是目录式描述和档案式描述共存，它们的描述方式由来已久，不易改变。因此，Web描述型元数据方案设计应该考虑图书馆和档案馆的实践惯例，同时满足目录式和档案式描述的需要。

3.4 站点式描述与集合式描述

前者的描述对象是单个站点，后者是多个站点的集合，且站点之间一般具有相关性，比如一个专题的所有站点。

选择策略。两种描述方式都可用于Web存档内容，选择哪种方式取决于Web保存机构和可利用的人力资源等。目前，图书馆常采用站点式描述方法建立在线单站点的元数据记录，通过检索系统提供用户访问；相反，档案馆几乎都采用集合式描述方法将收割的专题性Web站点集合作为一个描述单元构建元数据，供长期保存之用。很明显，站点式描述对于收割大量站点但人力资源不充足的机构是一个沉重负担，尤其是要求详细描述的情况。因此，根据保存目的、Web资源属性和人力资源情况选择描述方式是一种常见策略。

集合式描述的优势。按照专题收集Web站点，比如记录一个重要事件或向已建立专题添加Web站点，这种Web存档采用集合式描述比站点式描述更具成本效益性。另外，集合式描述可通过记录集合的范围、作用和共同的主题特征等提供语境信息，这是站点式描述无法实现的。集合式描述是资源发现的基础，可辅助于单站点描述，比如，在集合式描述的基础上，辅助于各个站点的标题和URL，可同时提供宏观和微观两个层级Web存档的标引。但这种方法的使用要有“度”，比如，当存档Web集合包含大量站点时，列出一个冗长的URL清单可能作用不大，也容易产生混乱。

鉴于上述分析，Web描述元数据方案应该既适合于站点式描述也适合于集合式描述，但在一些易产生歧义的元素标引上应辅助说明。比如，单个网站的标题常常是站点中重要文本内容的转录，而一个Web集合的标题常由收集机构设计；单个站点的创建者容易被识别，除非有意匿名，而一个聚焦在当前某一事件或主题的Web站点集合很少存在一个整体上的内容创建者；针对一个主题的Web资源集合式描述，其日期记录可以是收割的时间跨度，但一个单独在线站点的日期记录只能是被浏览且描述的时间或上线时间。

3.5 满足最终用户的需求

根据OCLC的调查[12]，Web保存的最终用户主要集中在各学科的科研人员，且主要需求有：①除了用于Web存档内容发现所需的描述型元数据元素外，还需存档Web的语境信息，比如：来源信息，选择收割站点和构建Web资源集合的决策信息，Web资源集合的收割完整性和收割站点的内容变化历史轨迹等。②相对于开放的在线Web访问上的便捷性和普遍性，存档Web资源的访问限制（如局限在图书馆内部现场浏览）是用户使用的障碍之一。③用户使用存档Web资源存在可获得性障碍，比如：访问系统复杂性，界面缺乏友好性，缺乏用户支持服务项目等。

为此，Web描述元数据方案在设计元素时应标引下列内容：Web存档资源的出处、收割的完整性、站点内容改变记录、存档Web的知识产权、访问限制等。

3.6 满足元数据实践者的要求

元数据实践者主要有：学者出于研究目的构建个人Web资源库；图书馆使用RDA和MARK，寻求用于描述Web资源的相关元素；档案机构将其采用DACS和EAD标准描述的档案映射到结构更加简单的Web工具（如Archive-It）中；保存系统对Web收割内容进行元数据标引。

根据OCLC的调查[13]，元数据实践者的相关需求主要有：①元数据标引应该大规模自动化，因为大多数机构从事这项工作的人力资源非常有限；②与图书馆和档案馆现行的Web存档描述标准相兼容；③目前，目录式、档案式和混合式描述方法同时使用，需要寻到一种解决方案将上述三种方法有效结合；④目前的Web存档描述标准及应用高度不一致，不仅体现在元数据元素上，还表现在元素的内容赋值上，故应建立统一的Web存档描述标准；⑤描述存档Web的元数据标引结果需在多个Web保存系统之间交换甚至共享，应制定这类元数据的跨系统再利用协议。

因此，为了满足元数据实践者的上述需求，Web描述元数据方案应该遵循以下原则：简单高效，以实现规模化自动化标引；分析吸收现行的元数据方案，以实现元数据方案之间的兼容性；具有一定程度的可扩展性，以包容目录式和档案式两种描述方法；标准化，以实现元数据元素及其赋值规则的统一化；协议化，以实现跨系统的交换和共享。

3.7 元数据元素的选择

我们应针对Web特质选择元数据元素，所选元素均应适用于Web描述，包括单站点和专题性的多站点集合两个层级的描述，且使用说明也应完全体现Web描述的特质。

元素选择应遵循的原则有：适合于规模化赋值；既可独立使用，也可结合图书馆和档案馆现行标准一起使用，以提供细粒度描述；元素名称和定义应尽可能采用现行元数据标准，以增强各标准间的兼容性和描述的一致性；各元素的使用说明应为标引者提供帮助，且标引结果不产生歧义；应包含常用元素（如贡献者、日期、主题词、标题等），这些元素对所有类型信息资源的识别和发现至关重要；其他元素须适用于存档Web站点的描述，比如产权和URL等；应适用于各层级的描述，如单站点描述、专题性的多站点集合描述等，这种描述应遵从存档标准中（如DACS和EAD）的多层级描述原则。

我们选择元数据元素一般分四个步骤：首先，基于目前广泛应用的数字资源描述标准DC、EAD、MARC21、MODS和schema.org等，选择通用元素，如贡献者（Contributor）、创建者（Creator）、日期（Date）、描述（Description）、语种（Language）、关系（Relation）、主题词（Subject）、标题（Title）等；其次，针对Web特质，设计其他候选元素，如收割者（Harvester）、范围（Extent）、类型（Genre/Form）、产权信息（Rights）、URL等；再次，针对每个候选元素，界定含义、辅助使用说明以及与其他主要描述型元数据方案之间的映射；最后，采用德尔菲法，征询业内专家、Web资源描述实践者和最终用户的意见，并进行一定规模的试标引，完善所建立的Web描述元数据方案。

（来稿时间：2018年5月）