摘要 本文档提供了与 Web
数据发布和使用相关的最佳实践，旨在支持一个可自我维持的数据生态系统。数据应当能够被人类和机器发现和理解。无论数据由数据的原创者还是外部方使用，相关的使用方式也应当可以被发现，数据发布者的努力应得到认可。简而言之，遵循这些最佳实践将促进发布者和使用者之间的互动。
目录
1. 引言2. 适用对象3. 范围4. 背景5. 命名空间 6. 最佳实践模板7. 最佳实践摘要8. 最佳实践
8.1 运行示例8.2 元数据8.3 数据许可8.4 数据来源8.5 数据质量8.6
数据版本管理8.7
数据标识符8.8 数据格式8.9
数据词汇表8.10 数据访问
8.10.1
数据访问 API
8.11
数据保存8.12
反馈8.13
数据丰富和增强8.14
再发布
9. 术语表10. Web数据面临的挑战11. 最佳实践的益处12. 用例需求与最佳实践对照A.
致谢B. 变更历史C. 参考文献
C.1
补充参考资料
4.
背景本节为非规范性内容。
下图展示了本文档考虑的背景。通常，Web 数据发布和使用相关的最佳实践针对数据集 和
数据分发 。数据以不同的分发形式发布，每种分发是数据集的一种特定物理表现。所谓数据，指“可以被记录且具备隐含意义的已知事实” [Navathe
数据使用者 不论目的、对象、兴趣或许可都能利用数据集。鉴于这种异质性，以及数据发布者和使用者彼此可能并不知晓，需公开一些关于数据集及分发的信息，提升可信度和可复用性，如：结构元数据、描述性元数据、访问信息、数据质量信息、来源信息、许可信息和使用信息。
Web 数据发布和共享的一个重要方面，是 Web 架构本身 [WEBARCH
6. 最佳实践模板本节介绍用于描述 Web 数据最佳实践的模板。
最佳实践模板
最佳实践简要说明
为何如此 本节回答两个关键问题：
此做法为何与 Web 数据发布或复用高度相关？
它如何鼓励 Web 上的数据发布或复用？
也可补充完整文本说明最佳实践试图解决的问题。内容不限长短，但通常不会超过几句话。
可能实现方式 此处提供可实现该最佳实践的策略。本建议为编写时的最佳意见，实际情况可能需要采用更适合具体环境和未来发展的其他实现方法。
如何测试 介绍如何判定已达到本最佳实践。可能可由机器，也可能不可由机器测试。
证据 说明最佳实践的相关性。引用在《Web 数据最佳实践用例与需求》文档 [DWBP-UCR
益处 益处 代表数据集在 Web 上可用方式的改进。每条最佳实践可能有一个或多个益处。
可复用性
可理解性
可关联性
可发现性
可信度
可获取性
互操作性
可处理性
8. 最佳实践本节包含数据发布者所需遵循的最佳实践，帮助他们和数据使用者共同克服在 Web 上发布和使用数据时面临的各种挑战。每一个挑战（详见 Web
数据面临的挑战 ）都提出了一条或多条最佳实践。
每条最佳实践都对应《Web 数据最佳实践用例与需求》文档 [DWBP-UCR
8.1 运行示例Adrian 就职于 MyCity 的交通局，负责发布有关公共交通的数据。Adrian
希望为不同类型的数据消费者发布这些数据，如有兴趣开发应用的开发者以及软件代理。确保人类和软件代理都能轻松理解和处理这些数据同样重要，同时数据应保持最新，并易于在 Web 上被发现。
部分最佳实践的 RDF 示例展示了如何使用 Turtle [Turtle JSON-LD
8.3 数据许可许可 是附加到 Web 数据上的一项非常有用的信息。根据发布者采用的许可类型，数据共享和复用可能会有更多或更少的限制。在 Web
数据的语境下，数据集的许可信息可以在元数据中指定，也可以在外部的单独文档中指定，并通过链接关联。
最佳实践 4：提供数据许可信息
提供控制数据使用的许可协议的链接或副本。
为何如此 许可信息的存在对于数据使用者评估数据可用性至关重要。用户代理可以根据许可信息的有无，决定是否将数据提供给潜在用户。
预期成果 人类能够理解描述对特定分发所施加的可能使用限制的数据许可信息，软件代理能够自动检测分发的数据许可。
可能实现方式 数据许可信息可以通过指向人类可读许可协议的链接或嵌入副本来提供，也可以通过指向机器可读许可协议的链接或嵌入副本供处理使用。
可以使用以下包含用于链接许可属性的词汇之一：
还有许多机器可读的权益声明语言，包括：
示例 4
机器可读
公交车站点数据集（stops-2015-05-05.csv）的 CSV 分发将采用
知识共享署名-相同方式共享（CC BY-SA
3.0） 许可。属性dct:license被用来作为分发元数据的一部分记录许可信息。在此例中，该许可不是机器可读语言书写的，但dct:license属性允许软件代理自动检测分发的数据许可。
:stops-2015 -05 -05. csv
a dcat:Distribution ;
dct:title "CSV distribution of stops-2015-05-05 dataset" ;
dct:description "CSV distribution of the bus stops dataset of MyCity" ;
dcat:mediaType "text/csv;charset=UTF-8" ;
dct:license <http:
.
人类可读
分发数据许可信息的人类可读示例页面 。
如何测试 检查数据集本身的元数据中是否包含以人类可读格式呈现的数据许可信息。
检查用户代理是否能够自动检测或发现数据集的数据许可。
益处
可复用性
可信度
8.4 数据来源Web 汇聚了商业、工程、科学等社群，创造了以往难以想象的协作机会。Web 数据发布的挑战在于为数据来源提供适当的细节。
数据生产者 未必是数据发布者，因此收集并传递对应元数据尤为重要。缺少数据溯源 信息，数据使用者就无法本质上信任所共享数据的完整性和可信度。数据发布者也需了解潜在用户群体的需求，以确定应披露多少溯源细节。
最佳实践 5：提供数据溯源信息
完整提供数据的来源及您做过的任何更改的信息。
为何如此 溯源信息是数据使用者评判数据集质量的手段之一。了解其来源和历史，有助于判断数据是否值得信任，并提供重要的解释上下文。
预期成果 人类将知晓数据集的来源和历史，软件代理能够自动处理溯源信息。
可能实现方式 数据溯源的机器可读版本可以采用 W3C 推荐的溯源本体进行提供，例如 W3C 的 Provenance Ontology（PROV-O）[PROV-O
示例 5
机器可读
以下示例展示了公交车站点数据集的机器可读元数据及溯源 元数据。dct:creator、dct:publisher和dct:issued用于描述数据集的来源。prov:actedOnBehalfOf用于指示
Adrian 代表 MyCity 交通局执行操作。
:stops-2015 -05 -05
a dcat:Dataset, prov :Entity"Bus stops of MyCity" ;
dcat:keyword "transport" , "mobility" , "bus" ;
dct:issued "2015-05-05" ^^xsd:date ;
dcat:contactPoint <http:
dct:temporal <http:
dct:spatial <http:
dct:publisher :transport-agency-mycity ;
dct:accrualPeriodicity <http:
dct:language <http:
dct:creator :adrian
.
:adrian
a foaf:Person, prov :Agent ;
foaf:givenName "Adrian" ;
foaf:mbox <mailto:adrian@mycitytransport.org> ;
prov:actedOnBehalfOf :transport-agency-mycity
.
:transport-agency-mycity
a foaf:Organization, prov :Agent ;
foaf:name "Transport Agency of Mycity"
.
人类可读
公交车站点数据集的人类可读溯源信息示例页面 。
如何测试 检查数据集本身的元数据中是否包含人类可读格式的溯源信息。
检查计算机应用能否自动处理数据集的溯源信息。
8.5 数据质量数据集的质量会显著影响相关应用的质量。因此，在数据发布与消费流程中加入数据质量 信息至关重要。通常，质量评估涉及多种质量维度，每个维度代表对发布者和使用者来说重要的特征组。数据质量词汇（DQV）定义了测量和指标等概念，用于评估各质量维度的水平[VOCAB-DQV
最佳实践 6：提供数据质量信息
提供有关数据质量及其是否适合特定用途的信息。
为何如此 数据质量可能严重影响数据对特定应用的适用性，包括与其原始生成目的截然不同的应用。记录数据质量显著简化数据集筛选过程，提高复用概率。无论领域特性如何，数据质量应被记录，已知质量问题应在元数据中明确声明。
预期成果 人类和软件代理都能评估数据集的质量进而判断其是否适合自身应用。
可能实现方式 数据集质量元数据的机器可读版本可以采用 DWBP 工作组制定的数据质量词汇 [VOCAB-DQV
示例 6
机器可读
以下为公交车站点数据集 CSV 分发表的元数据，包含数据质量元数据，定义参考数据质量词汇文档。更多示例见 VOCAB-DQV。
:stops-2015-05-05.csv
a dcat:Distribution ;
dcat:downloadURL <http: //data.mycity.example.com /transport /dataset /bus /stops-2015-05-05.csv > ;
dct:title "CSV distribution of stops-2015-05-05 dataset" ;
dct:description "CSV distribution of the bus stops dataset of MyCity" ;
dcat:mediaType "text/csv;charset=UTF-8" ;
dct:license <http: //creativecommons.org /licenses /by-sa /3.0 /> ;
dqv:hasQualityMeasurement :measure1, :measure2
.
:measure1
a dqv:QualityMeasurement ;
dqv:computedOn :stops-2015-05-05.csv ;
dqv:isMeasurementOf :downloadURLAvailabilityMetric ;
dqv:value "true"^^xsd:boolean
.
:measure2
a dqv:QualityMeasurement ;
dqv:computedOn :stops-2015-05-05.csv ;
dqv:isMeasurementOf :csvCompletenessMetric ;
dqv:value "0.5"^^xsd:double
.
#definition of dimensions and metrics
:availability
a dqv:Dimension ;
skos:prefLabel "Availability"@en ;
skos:definition "Availability of a dataset is the extent to which data (or some portion of it) is present, obtainable and ready for use."@en ;
dqv:inCategory :accessibility
.
:completeness
a dqv:Dimension ;
skos:prefLabel "Completeness"@en ;
skos:definition "Completeness refers to the degree to which all required information is present in a particular dataset."@en ;
dqv:inCategory :intrinsicDimensions
.
:downloadURLAvailabilityMetric
a dqv:Metric ;
skos:definition "It checks if dcat:downloadURL is available and if its value is dereferenceable."@en ;
dqv:inDimension :availability
.
:csvCompletenessMetric
a dqv:Metric ;
skos:definition "Ratio between the number of objects represented in the cvs and the number of objects expected to be represented according to the declared dataset scope."@en ;
dqv:inDimension :completeness
.
人类可读
人类可读数据质量信息示例页面 。
如何测试 检查数据集本身的元数据中是否包含数据质量信息。
检查计算机应用能否自动处理数据集的数据质量信息。
益处
可复用性
可信度
8.6 数据版本管理发布在 Web
上的数据集可能会随着时间发生变化。有些数据集按计划定期更新，有些数据集则会因为数据采集方式改善而进行更新。为应对这些变化，可能需要创建数据集的新版本。不幸的是，关于什么时候数据集的更改应被视为全新的数据集、什么时候只是新版本，业界并无统一共识。下面我们介绍几种场景，多数发布者会认为应将其视为现有数据集的新版本。
场景 1：新建了一个公交站点，需将其添加到数据集中；
场景 2：已有公交站点被移除，需将其从数据集中删除；
场景 3：发现数据集中某公交站点有误，需要修正该错误。
一般来说，代表时间序列或空间序列的多个数据集，例如不同地区或不同年份的同类数据，不被视为同一数据集的多个版本。这种情况下，每个数据集对应不同的世界观察对象，应被视为新的数据集。对某城市每周气象预测数据集来说，每周都会创建新数据集存储该周的数据，也属于这种情况。
场景 1 和 2 通常涉及主版本变更，而场景 3
通常只是次版本更新。但将版本区分为主次并不如始终确保变更时递增版本指示器那么重要。即使是小的更改，也需要记录不同版本，以提升数据集的可信度。发布者需记住，某个数据集可能被多个数据使用者使用，发布新版本时应采取合理措施及时通知他们。对于实时数据，自动时间戳即可作为版本标识。每个数据集，发布者都应采取一致且具备参考性的版本管理策略，使数据使用者能够理解和适应数据的变化。
最佳实践 7：提供版本指示
为每个数据集分配并标注唯一的版本号或日期。
为何如此 版本信息让数据集的某一次修订具有唯一标识。唯一性可使数据使用者判定数据如何随时间发生变化，以及他们正在使用的数据集具体是哪个版本。良好的版本管理可以让使用方判断是否存在更高版本。显式的版本管理有助于研究复现、结果对比，并防止混淆。使用标准格式的唯一版本号也会让用户对版本变更有明确预期。
预期成果 人类和软件代理可以轻松确定正在使用的数据集属于哪个版本。
可能实现方式 具体如何提供版本信息需视情况而定，但可参考如下基本指南：
在数据集元数据中包含唯一的版本号或日期。
采用一致的编号方案，并采用有意义的数字递增方法，如 [SchemaVer
如果通过 API 发布数据，请确保请求最新数据的 URI
随版本变化不变，但需支持通过 API 请求特定版本。
采用 Memento 协议 [RFC7089
Web 本体语言 [OWL2-QUICK-REFERENCE PAV
示例 7
机器可读
下面的例子展示了公交站点数据集元数据中加入了版本元数据，owl:versionInfo 和 pav:version
属性用于标识数据集的版本。
:stops-2015 -05 -05
a dcat:Dataset ;
dct:title "Bus stops of MyCity" ;
dcat:keyword "transport" ,"mobility" ,"bus" ;
dct:issued "2015-05-05" ^^xsd:date ;
dcat:contactPoint <http:
dct:temporal <http:
dct:spatial <http:
dct:publisher :transport-agency-mycity ;
dct:accrualPeriodicity <http:
dct:language <http:
dct:creator :adrian ;
owl:versionInfo "1.0" ;
pav:version "1.0"
.
使用 Memento
假设：
http://data.mycity.example.com/transport/dataset/bus/stops 为“通用
URI”，总是可访问最新数据集版本
http://data.mycity.example.com/transport/dataset/bus/stops-2015-12-17
是当前数据集的版本化 URI
http://data.mycity.example.com/transport/dataset/bus/stops-2015-05-05
是此前数据集版本的版本化 URI
在 Memento 协议下，版本化 URI 通过 HTTP 响应头指明其版本时间和与通用 URI 的关系：
curl -I http:
HTTP/1.1 200 OK
Memento-Datetime: Thu, 17 Dec 2015 00 :00 :00 GMT
Link:<http: //data.mycity.example.com /transport /dataset /bus /stops >
通用 URI 提供 TimeGate 链接，可通过时间协商查看某时间点在线的数据集版本。通用 URI 本身不含版本时间：
curl -i -H http:
HTTP/1.1 200 OK
Link: <http: //data.mycity.example.com /transport /dataset /bus /timegate /stops >
版本化 URI 也可包含指向 TimeGate 的链接：
curl -I http:
HTTP/1.1 200 OK
Memento-Datetime: Tue, 05 May 2015 00 :00 :00 GMT
Link: <http: //data.mycity.example.com /transport /dataset /bus /stops >
客户端用如下方式确定 2015年6月20日 活跃的数据集版本：
curl -I -H "Accept-Datetime: Sat, 20 Jun 2015 12:00:00 GMT" http:
HTTP/1.1 302 Found
Vary: accept-datetime
Location: http:
Link: <http: //data.mycity.example.com /transport /dataset /bus /stops > "original"
人类可读
人类可读数据版本信息示例页面 。
如何测试 检查数据集/分发的元数据中是否以人类可读格式提供唯一版本号或日期。
检查计算机应用能否自动检测/识别并处理数据集或分发的唯一版本号或日期。
益处
可复用性
可信度
最佳实践 8：提供版本历史
提供完整的版本历史，以及每次更新的变更说明。
为何如此 在开发基于数据的应用时，了解数据随时间的变化性非常重要。理解数据的动态性也有利于正确解读数据。若没有变更摘要，则判断不同版本间的区别通常非常繁琐。
预期成果 人类和软件代理能够理解数据集的版本变化规律，以及任意两版本的具体区别。
可能实现方式 公布所有已发布版本的清单，并为每个版本提供变更说明，阐述该版本相较上一个版本的变化。可通过 API 用专用 URL 获取最新的完整历史信息。
示例 8
机器可读
假定新建一公交站点，并发布新数据集（stops-2015-12-17）以保持数据更新。新数据集是stops-2015-05-05
的新版本。新数据集的机器可读元数据如下，包括版本历史信息：
:stops-2015 -12 -17
a dcat:Dataset ;
dct:title "Bus stops of MyCity" ;
dcat:keyword "transport" ,"mobility" ,"bus" ;
dct:issued "2015-12-17" ^^xsd:date ;
dcat:contactPoint <http:
dct:temporal <http:
dct:spatial <http:
dct:publisher :transport-agency-mycity ;
dct:accrualPeriodicity <http:
dct:language <http:
dct:creator :adrian ;
...
dct:isVersionOf :stops-2015 -05 -05 ;
pav:previousVersion :stops-2015 -05 -05 ;
rdfs:comment "The bus stops dataset was updated to reflect the creation of a new bus stop at 1115 Pearl Street." ;
owl:versionInfo "1.1" ;
pav:version "1.1"
.
关于 Memento 的用法：
假定：
http://data.mycity.example.com/transport/dataset/bus/stops 为“通用
URI”，总是可查最新版本
http://data.mycity.example.com/transport/dataset/bus/stops-2015-12-17
为当前数据集的版本化 URI
http://data.mycity.example.com/transport/dataset/bus/stops-2015-05-05
为前一数据集版本化 URI
http://example.org/stops-2015-01-01 为该数据集首个版本的 URI
版本化 URI、通用 URI 和 TimeGate 可以链接到 TimeMap，后者列出所有历史版本：
curl -I http:
HTTP/1.1 200 OK
Memento-Datetime: Tue, 05 May 2015 00 :00 :00 GMT
Link: <http: //data.mycity.example.com /transport /dataset /bus /stops > "application/link-format"
TimeMap 的获取方式如下：
curl -I http://data.mycity.example.com/transport/dataset/bus/timemap/stops
HTTP/1.1 200 OK
Content-Type: application/link-format
<http: //data.mycity.example.com /transport /dataset /bus /stops > ;rel="original”,
<http: //data.mycity.example.com /transport /dataset /bus /timegate /stops > ;rel="timegate”,
<http: //data.mycity.example.com /transport /dataset /bus /timemap /stops > ;rel="timemap”;
type="application/link-format",
<http: //data.mycity.example.com /transport /dataset /bus /stops-2015-01-01 > ;
rel=“first memento"; datetime="Thu, 01 Jan 2015 00:00:00 GMT",
<http: //data.mycity.example.com /transport /dataset /bus /stops-2015-05-05 > ;
rel=“memento"; datetime=“Tue, 05 May 2015 00:00:00 GMT"
<http: //data.mycity.example.com /transport /dataset /bus /stops-2015-12-07 > ;
rel=“last memento"; datetime="Thu, 17 Dec 2015 00:00:00 GMT"
版本化 URI 也可以声明与其它版本的关联信息：
curl -I http://data.mycity.example.com/transport/dataset/bus/stops-2015-05-05
HTTP/1.1 200 OK
Memento-Datetime: Tue, 05 May 2015 00:00:00 GMT
Link: <http: //data.mycity.example.com /transport /dataset /bus /stops > ;
rel=“original”,
<http: //data.mycity.example.com /transport /dataset /bus /stops-2015-01-01 > ;
rel=“prev first memento";
datetime="Thu, 01 Jan 2015 00:00:00 GMT",
<http: //data.mycity.example.com /transport /dataset /bus /stops-2015-12-17 > ;
rel=“next last memento";
datetime="Thu, 17 Dec 2015 00:00:00 GMT"
人类可读
人类可读数据版本历史信息示例页面 。
如何测试 检查是否提供了所有已发布版本及详细变更记录。
益处
可复用性
可信度
8.7 数据标识符标识符有多种形式，在各种信息系统中被广泛使用。Web 上的数据发现、使用和引用，根本上依赖于 HTTP（或 HTTPS）URI：全球唯一标识且可通过互联网解析的标识符 [RFC3986
URI 是“哑字符串”，即不携带语义。它们仅用于标识资源。
虽然上点属实，但例如 http://example.com/dataset.csv 这样的 URI 返回的内容自然应是 CSV 文件，人类可读性很重要。
一个 URI 被解析时，可以根据 内容协商 ，返回多种格式的同一资源，如
CSV、JSON、XML 等。
一个 URI 可重定向到另一个 URI。
解析 URI 会触发服务器上的程序运行，该程序可简单返回静态文件，也可执行复杂处理。具体如何实现，与 URI 本身完全无关。
最佳实践 9：用持久性 URI 作为数据集标识符
为每个数据集分配精心设计、持久存在的 URI。
为何如此 采用统一的标识体系，让任何角色都可可靠地进行数据标识与比对。这是数据管理和再利用的前提条件。
开发者可能将 URI 固化在代码中，因此 URI 的持久性和解析结果长期不变非常重要，避免需人工干预。
预期成果 数据集及其信息在时间维度上可被发现和引用，无论其状态、可用性或格式如何变动。
如何测试 检查每个数据集是否使用了专为持久性设计的 URI。理想情况下，相关网站需说明其设计方案及若发布者无法继续维护时，保证 URI 继续有效的承诺。
最佳实践 10：在数据集中使用持久性 URI 作为标识符
在数据集中尽可能重用他人的 URI 作为标识符。
为何如此 Web
的力量源于网络效应 。第一部电话只有第二部诞生后，才具实际用途；第三部问世又让前两部更有价值。数据在关联他人数据后价值倍增，这包括相同对象、地点、概念、事件和个人等。实现这一点，需要跨数据集采用相同标识符，并让你的标识符可被他人引用。当这些标识符是
HTTP URI 时，可被解析且发现更多关联数据。
这些理念正是5 星关联数据 的核心——一个数据点链接另一个数据点，也是超媒体 中，链接可以指向更多数据或相关服务的实现基础。
这就是数据的 Web。
预期成果 数据项将在 Web 全网互有关联，构建全球信息空间，人机均可访问。
可能实现方式 此为独立专题，本文件仅能简要涉及。
开发者常知自己要解决的问题别人也许已解决。为国家、货币、学科、物种、蛋白、城市、地区、诺奖得主、产品等寻找标识符时，几乎总有现成 URI 可用，可参考 如何发现现有词汇表
[LD-BP
确保你用的 URI 集由权威机构/组织发布；
确保所用 URI 集本身具有持久性。
若找不到现成标识符集，你就需自行创建，并遵循 URI 持久性模式，让他人愿意通过链接为你的数据增值。
示例 10
前述最佳实践中的 URI 示例
(http://data.mycity.example.com/transport/dataset/bus/stops) 标识数据集。URl
的主体部分也可用于标识具体公交站、线路和车型，如适合“Airport - Bullfrog”线路的持久 URI 可为：
http://data.mycity.example.com/transport/route/bus/id/AB
其结构与数据集 URI 相同，但 /dataset 改为 /route，用户可知该 URI
标识公交线路；/id 表示标识非信息资源（实际无法直接获取），而 /AB 是具体公交线路的本地标识符。依据 GS1 的
SmartSearch 指南 [GS1 GTIN 标识产品时，推荐 URI 如
http://data.myproduct.example.com/gtin/05011476100885。解析非信息资源类型的 URI，应 303
重定向到如 http://data.mycity.example.com/transport/route/bus/doc/AB 的说明/描述页面（即将
/doc 替换 /id），Jeni Tennison 的 Data URL 文档对此有进一步阐述[URLs-in-data
注意，URI 可能很长，大型数据集里每个元素都存完整 URI 显然冗余且浪费。更好的方案是为每元素定义本地唯一 ID（如示例中的
AB），同时提供可将其程序化转换为全局唯一 URI 的方法。表格数据元数据词汇 [Tabular-Metadata about URL 属性）实现这一点。
如何测试 检查数据集中对诸如国家、地区、组织、个人等不变或缓慢变化对象的引用，是否使用了 URI 或可拼接到 URI 模板的短标识符。理想方案下，这些 URI
可解析，若不可解析，也因其全局唯一性仍具价值。
最佳实践 11：为数据集版本和系列分配 URI
为每个数据集版本和整体系列分配 URI。
为何如此 和文档类似，许多数据集自然形成系列。例如：
MyCity 的公交站点（会随时变化）；
MyCity 的当任官员名单；
文档的迭代版本。
有时需要引用当前状态（如当前公交站、现任官员名单等），有时则需引用特定时间下的状态。
预期成果 人类和软件代理可以明确引用数据集的具体版本、数据集系列、“最新版本”等概念。
可能实现方式 W3C 提供很好的示范。本文件的（持久）URI 为
https://www.w3.org/TR/2016/PR-dwbp-20161215/，该 URI 表示本文件发布时间同日的固定快照，而“最新版本”URI 为
https://www.w3.org/TR/dwbp/
，用于指代一系列随时间变化的相关文档。在文件发布之时，这两个地址均指向本文件；等新版本发布后，“最新版本”URI 则指向新文件，而带日期的 URI 保持不变。
示例 11
假设增加了一个公交站点。为保持 stops-2015-05-05
的及时性，创建了新版本数据集（stops-2015-12-17），其中包含上一个版本的全部数据及新增站点。两个版本可分别用如下 URI 标识：
http://data.mycity.example.com/transport/dataset/bus/stops-2015-05-05：首个版本的 URI
http://data.mycity.example.com/transport/dataset/bus/stops-2015-12-17：新版本的 URI
http://data.mycity.example.com/transport/dataset/bus/stops：总是指向最新版本，在
2015年12月17日 前，指向stops-2015-05-05，之后服务器调整该 URL 指向 stops-2015-12-17。
如何测试 检查每个数据集版本是否拥有专属 URI，同时是否有“最新版本”URI。
8.9 数据词汇表词汇表 用于定义某一领域中用于描述和表达信息的概念及其关系（亦称“术语”或“属性”）。它们用于分类可在特定应用中使用的术语、刻画可能的关系，并定义这些术语使用时的约束。词汇表的近义词还有本体、受控词表、主题表、分类体系、代码表、语义网络等。
这些名词所指的形式没有严格区分。但“本体”通常指的是用于构建（关联）数据集资源描述的类和属性的词汇体系。关系型数据库中，这对应表名和列名；XML 则对应 XML Schema
定义的元素。本体是语义网推理的核心构件。W3C 最初提供的本体构建方式是 RDF Schema [RDF-SCHEMA OWL2-OVERVIEW
与之不同，“受控词表”“概念系统”和“知识组织系统”主要用于枚举和定义可被上述词汇表用来描述对象的资源。例如，主题表中的“建筑学”可以作为图书描述中的主题字段值（而“主题”是在图书本体中定义的）。对于这些词表，通常无需复杂的形式化表达，因此诸如
ISO 25964 数据模型 [ISO-25964 W3C
简单知识组织系统 [SKOS-PRIMER
最佳实践 15：复用词汇表（优先用标准化词汇表）
采用共享词汇表（优先用标准化词汇表）中的术语来编码数据和元数据。
为何如此 使用他人已在用的词汇表能反映社区共识，促进互操作，降低冗余，也鼓励本身数据的再利用。尤其是在元数据（结构、溯源、质量、版本等）编码时共享词汇表更有利于数据与元数据的自动处理和比对。此外，引用标准的代码和术语能避免不同元素或取值间的歧义和冲突。
预期成果 增强数据发布者和使用者之间的互操作性和共识。
可能实现方式 W3C 关联数据发布最佳实践的词汇表 章节，介绍了发现、评估和选择现有词汇表的建议。
如开放地理空间联盟（OGC）、ISO 、W3C 、WMO 、图书馆与科研数据服务等机构，都为大家提供了可复用的代码表、术语表和关联数据词汇表。关键在于确保数据集或其文档为使用者提供足够人和机器可读的上下文信息，便于获得和利用标准取值的含义。在
Web 语境下，给标准词汇项指定无歧义的 Web URI 是实现该目标的高效方法，并允许附多语言标签提升跨境互操作性。如欧盟多语种主题表 Eurovoc 就是典范。
示例 15
DCAT 词汇表用于描述数据集元数据 [VOCAB-DCAT dct:title 等已有属性，而不新造如 dcat:title，使 DCAT 元数据可被任何能处理
DC 断言的应用读取和处理。
数字文化领域，Europeana 数据模型 (EDM ) 也大量复用 DC、FOAF、SKOS
等。其推广和采用使大批数据提供方采纳 EDM 并成为同领域最佳实践。例如 美国数字公共图书馆 的元数据应用配置文件 复用了
EDM，也就继承了其基础词汇表。这极大提升了本领域数字文化数据的互操作性，也降低了外部用户不熟悉图书馆、档案馆等传统模型和术语所遇的障碍。
美国国会图书馆将 ISO 639 语言表作为关联数据发布（见
[ISO639-1-LOC :stops
dct:language <http:
澳大利亚 陆地与环境网格 发布国际地层委员会时间表元素 URI 参考列表，如：
http://resource.geosciml.org/classifier/ics/ischart/Paleozoic（古生代）:dataset-005 a dcat:Dataset ;
dct:temporal <http:
Google 维护的通用公交数据规范 ，定义了发布公交信息所用字段如
route_short_name、route_type，并面向社区公开征求意见。定义里还包含了代码取值说明，如
route_type 的典型取值：0 - 有轨电车、轻轨等都市轻型地铁
1 - 地铁、地下铁路系统
2 - 铁路，跨城远程用
注意，该类字段和代码并无单独 Web 标识符或机器可读语义，需开发者依文档解析并实现各自的语义。
最佳实践 16：选择合适的形式化程度
选择符合数据和应用场景的形式化语义层级。
为何如此 爱因斯坦说过或没说过：要尽量简单，但不能过度简化。
形式化语义有助于严密规定数据语义，为推理等任务打下基础，但复杂的本体需更多精力构建与理解，可能妨碍其再用、比对和数据集间链接。
如果数据具备支持复杂研究的问题（如 A、B、C 成立但 D 不成立能推出 E），那应采用 OWL Profile 等 [OWL2-PROFILES
但公交车站点清单就没啥复杂性。
极简词汇表很吸引人，但若因简化而丢掉如地理位置等关键信息，也将导致使用场景受限。要做到既便于再用，也不失信息量。
预期成果 为目标应用场景以最简单的方式提供所需支持，不增加不必要的复杂性。
可能实现方式 多参考同行的做法，你会发现一些常用词汇表已能很好满足（或几乎满足）你的需求，那就优先选用它们。
如果你想复用某词汇表，但发现如领域或范围限制使它无法直接用，建议与词汇表发布者沟通。他们或许能移除部分限制，并告知更广泛的使用经验。
W3C 有邮件列表 public-vocabs@w3.org [存档 ]，可专门讨论词汇表使用与开发话题。
如需自建词汇表，语义约束只保留最必要部分，方便他人再用。以广泛采用的 SKOS 本体为例，作者会质疑所有建议的形式公理，许多都被拒绝采纳，以避免导致应用间用法不一致，从而破坏了 SKOS
的普适性。例如，skos:broader 属性没有被定义为可传递，是为兼容诸多本体需求 [SKOS-DESIGN
另一个“面向广泛重用”的典范是 schema.org 。该站自2011年6月上线后快速被业界采纳，一大原因就是其类型定义偏向说明性而非强制规定。例如 authorOrganization 或
Person 类型，但并不强制。其属性"可用于" CreativeWork 类型对象，但也非强约束。这让 schema.org
成为良好的数据分享词汇选择。
如何测试 这类判断大多主观，没有客观标准。一般可参考：
是否采用了 Dublin Core、schema.org 等常用词汇？
简单事实是否直白易取？
如用正式知识表达语言，用推理引擎处理该词汇数据后，不会出现太多非目标应用需要的语句。
8.10 数据访问为 Web 上的数据提供便捷访问，可以让人类和机器都能充分利用基于 Web 基础设施共享数据的好处。默认情况下，Web
通过超文本传输协议（HTTP）方法访问数据。这种方式提供了原子级事务的数据访问。可能是简单的批量下载文件，或者当数据分布于多个文件或需要更复杂检索方法时，通过 API 实现。这两种基本方式，批量下载和 API ，并不是互斥的。
批量下载方法下，数据一般在服务器端预处理，将多个文件或文件树合并成一个可下载的文件。当需要从非文件系统方案批量获取数据时，根据数据用户群体，数据发布者可以提供 API 以支持单次事务需要的检索操作序列。
对于实时或准实时生成的数据，数据发布者应使用自动化系统以实现对时效性强数据的即时访问，比如应急信息、气象预测数据、系统监控指标等。一般情况下，API 应作为自动检索和搜索这些数据的手段向第三方提供。
API 除了支持自动化实时数据流程，也适合所有类型的 Web 数据。虽然实现 API 要比简单发布下载文件更复杂，但发布者越来越认可投入到文档齐全、标准、稳定 API 的价值。
对于一些数据发布者，能够知道谁下载了数据、如何使用数据也很重要。有两种获取这种信息的方法。一是邀请 用户提供（用户的动力是可以促进数据持续发布，并提升自己的影响），另一种是要求注册后才能访问数据，两种方式都可以用数据集使用词汇
[VOCAB-DUV
最佳实践 17：提供批量下载
允许使用者用单个请求获取完整数据集。
为何如此 当 Web 数据分布于多个 URI，但从逻辑上属于同一容器时，批量访问非常有用。批量获取可让数据以整个数据集的方式统一处理。若每次请求单个资源再自行拼装，难度较大且方式不统一，易导致处理不一致。
预期成果 大文件传输如比常规用户可接受时间更长，可通过专用文件传输协议实现。
可能实现方式 可以根据数据类型和使用需求采取如下方式：
对于本身包含多个文件的数据集，预处理聚合成一个文件，并通过单一 URI 提供下载。对于大数据集可压缩文件。
托管提供批量下载能力的 API ，除动态查询外还允许整体下载，非常适合动态数据快照。
对于特别大的数据集，可借助 http 以外方式进行批量传输，如 bbcp 或
GridFTP 。
批量下载包应包含描述数据集的元数据，发现元数据 [VOCAB-DCAT
益处
可复用性
可获取性
最佳实践 18：为大型数据集提供子集
如果你的数据集很大，应让用户和应用容易获取有用的子集。
为何如此 大型数据集转移困难，用户存储或解析大数据也很麻烦。如果只需部分子集，则没必要下载完整数据集。Web
应用如能“懒加载”，只处理必要数据，性能会更好，子集能力也能让离线处理更高效。实时应用则能更快响应。
预期成果 应用和人能访问部分子集而无需下载整个数据集，并能让用户获取到最大比例的有用数据。静态大数据将可拆包下载。API 将能按领域或 Web 性能要求，提供适当粒度的切片或过滤子集。
可能实现方式 根据预期用例，分析哪些子集最有价值。API 最具灵活性，可自定义子集数据内容，颗粒度应适合 Web 访问速度。（API 调用能1秒内返回互动体验较好，10秒以上常让用户误以为出错。）
也可以把数据集直接切割为多个小单元，逐个开放下载/查看。
对有需要的领域，可以给数据集加标记，使任意“切片”能单独处理。比如用 RDF Data Cube
Vocabulary 定义切片。
示例 18
MyCity
交通局已多年采集乘客详细数据，数据量极大，内容涉及交通类型、线路、车辆、司机、上下车站点、票种、上下车时间等。不同利益相关方对不同子集感兴趣：系统管理者关心本系统数据，规划者只看站点上下车数，财务关注票种售出量等等。交通局网站允许用户选择感兴趣字段及取值范围，仅下载所需子集。
如何测试 检查是否可通过多次请求分别获取数据子单元，最终拼装还原全部数据集。
最佳实践 19：对多格式数据支持内容协商
对于多种数据格式，同时支持内容协商与文件扩展名。
为何如此 可用 RDFa 等方式在同一个 HTML 页面同时混合展示人类/机读数据。但如 Web 架构 [WEBARCH VOCAB-DCAT 同一个 URL 通过内容协商 返回合适版本（DCAT 称为 distribution）。当然，也可用特殊 URI
直接访问具体格式，绕过内容协商。
预期成果 内容协商可根据客户端请求返回不同资源或一资源的不同表现形式。
可能实现方式 可以将服务器配置为支持目标资源的内容协商。
资源具体格式既可通过 URI，也可靠 HTTP 请求的 Content-type 头部获取。
示例 19
公交车站点数据集根据 HTTP 请求头中的内容类型，可分别以 CSV 和 JSON-LD 形式返回：cURL 获取
http://data.mycity.example.com/transport/dataset/bus/stops 的 CSV 和 JSON-LD 表现。
curl -L -H "Accept: text/csv" http://data.mycity.example.com/transport/dataset/bus/stops
curl -L -H "Accept: application/ld+json" http://data.mycity.example.com/transport/dataset/bus/stops
如何测试 检查资源可用表现类型，尝试用 HTTP 请求头指定类型获取不同内容。
益处
可复用性
可获取性
最佳实践 20：提供实时访问
当数据为实时生产时，应尽量实时或准实时在 Web 上提供。
为何如此 Web 上提供实时数据可访问关键时效性数据，也能推动实时 Web
应用发展。实时访问依赖实时数据生产方及时向发布方供数。具体是否需要实时访问，需根据刷新频率、后处理延迟、基础设施和用户需求等因素判定。发布者还应补充说明数据缺口、错误、异常和延迟等信息。
预期成果 应用将能实时或准实时 访问关键数据，其中实时指数据生成后几毫秒到数秒之间。
可能实现方式 一种做法是发布方配置 Web 服务，当收到实时数据时即时推送给用户，可通过轮询或流式方式分发。
如果使用者访问不频繁，可以通过 API 按需轮询最新数据，发布方应为这类只读请求提供 API。
如果用户频繁获取数据，则建议用流式实现（如推送 API），虽然流式技术超出本最佳实践讨论范畴，但现有大量标准协议和技术，如 Server-sent
Events、WebSocket、EventSourceAPI，可用于服务器自动向客户端推送新数据。
如何测试 PROV-O
益处
可复用性
可获取性
最佳实践 21：保证数据及时更新
以最新方式发布数据，并明确说明更新频率。
为何如此 Web 数据的可用性应尽量与数据产生或采集时间同步，哪怕可能有一定处理延迟。将数据发布同步于更新频率有助于增强用户信心和数据复用。
预期成果 Web 上的数据将及时更新，确保线上能拿到的数据和其它渠道最新数据没有时间差。新数据一出来，能尽快发布到 Web。
可能实现方式 可按既定周期更新数据集，更新流程中将 Web 发布作为新数据版本的环节。将 Web
发布设为一项明确责任事项，可防止数据过时。为设定用户对更新节奏的预期，可用人类可读文本说明预期发布频率，并提供机器可读元数据描述频率。
示例 21
假设公交站点数据集每年更新一次。可用 dct:accrualPeriodicity 描述数据添加频率。新版本
stops-2016-05-05 对应最新更新。需要注意，虽可早于计划节点发布新版本，但发布者仍要及时 Web 上线新版本。
:stops-2016 -05 -05
a dcat:Dataset ;
dct:title "Bus stops of MyCity" ;
dcat:keyword "transport" ,"mobility" ,"bus" ;
dct:issued "2016-05-05" ^^xsd:date ;
...
dct:accrualPeriodicity <http:
...
dct:isVersionOf :stops-2015 -05 -05 ;
pav:previousVersion stops-2015 -12 -17 ;
rdfs:comment "The bus stops dataset was updated to reflect the creation of new bus stops since the last update and to follow the update frequency" ;
owl:versionInfo "1.2" ;
pav:version "1.2"
.
如何测试 检查有无更新频率说明，且最新发布版本不早于说明的更新日期。
益处
可复用性
可获取性
最佳实践 22：为不可用数据提供说明
对于不可用数据，应说明如何获取数据及谁有权访问。
为何如此 在线发布无法提供的数据说明，使发布者能明确指出知识空缺。这为用户社区提供了背景解释，也能鼓励他们利用那些可以 访问的数据。
预期成果 用户将知道当前数据集引用但实际不可用或仅特定条件下可用的数据。
可能实现方式 根据机器/人类上下文，可采用多种办法指示数据不可用。发布者可发布 HTML 说明页面解释不可用原因。机器接口可用合适 HTTP 状态码并附定制消息，如
303（另见）、410（永久移除）、503（数据服务暂不可用）等。
如何测试 若数据集内含已失效或非全部用户可用的数据引用，应有缺失说明和可行获取方法。请求不可用数据时应返回 400 或 500 段的合规 HTTP 响应码。
益处
可复用性
可信度
8.10.1 数据访问 API
最佳实践 23：通过 API 提供数据
如果条件允许，应通过 API
提供数据服务。
为何如此 API
为数据使用者提供了最大灵活性和可处理性。它可以实现实时数据使用、按请求过滤，并支持原子级别的数据操作。如果数据集规模大、实时更新频繁或结构复杂，采用 API 通常是数据发布的最佳选择。
预期成果 开发者可以通过编程方式直接访问数据，用于自己的应用，同时数据能自动获得更新而不需要使用者手动操作。Web 应用也能通过查询接口获取所需的具体数据。
可能实现方式 开发 API 比起直接提供文件下载更为复杂，需要一定 Web
应用开发经验。但通常不必从零开发，常见如 CKAN 等数据管理平台都可直接启用 API，许多 Web 开发框架本身也支持 API，此外还有专门为构建自定义 API 设计的框架。
Rails（Ruby）、Django（Python）、Express（NodeJS）等 Web 框架都可以用来搭建 API，常见的 API 框架还有
Swagger、Apigility、Restify、Restlet 等。
如何测试 检查是否可用测试客户端模拟调用并验证 API 返回的响应是否符合预期。
最佳实践 24：以 Web 标准为 API 基础
在设计 API 时，应采用基于 Web 技术本身的架构风格。
为何如此 基于 Web 标准的 API 能充分发挥 Web 优势。例如，采用 HTTP 动词作为方法、使用 URI 直观映射资源，能防止请求与响应强耦合，使 API
易于维护、开发者易学易用。Web 的无状态特性便于快速扩展，使用超媒体还能实现丰富的 API 交互。
预期成果 对已有 REST 等 Web 标准 API 经验的开发者，可以直接理解并快速上手。API 也易于后续维护。
可能实现方式 REST（表述性状态转移）[Fielding Richardson
还可实现超媒体 API——即除了数据还在响应中加链接。链接让 Web 真正成为“网”，API 返回的链接可指向其他资源、文档和导航信息，即使 API 不完全满足 REST
约束，只要响应中返回链接，也能提升自说明性和可用性。
示例 24
某公交线路的超媒体 API 响应示例如下：
{
"code": "200",
"text": "OK",
"data": {
"update_time": "2013-01-01T03:00:02Z",
"route_id": "52",
"route_name": "Lexington South",
"route_description": "Lexington corridor south of Market",
"route_type": "3"
},
"links": [{
"href": "http://data.mycity.example.com/transport/api/v2/routes/52",
"rel": "self",
"type": "application/json",
"method": "GET"
}, {
"href": "http://data.mycity.example.com/transport/api/v2/routes",
"rel": "collection",
"type": "application/json",
"method": "GET"
}, {
"href": "http://data.mycity.example.com/transport/api/v2/schedules/52",
"rel": "describedby",
"type": "application/json",
"method": "GET"
}, {
"href": "http://data.mycity.example.com/transport/api/v2/maps/52",
"rel": "describedby",
"type": "application/json",
"method": "GET"
}]
}
如何测试 确保服务未将 http 作为自定义方法的通道，且 URI 中不含方法名。
益处
可复用性
可关联性
互操作性
可发现性
可获取性
可处理性
最佳实践 25：为 API 提供完整文档
在 Web 上发布完整的 API
信息，并在增加新特性或变更时及时更新文档。
为何如此 开发者是 API 的主要使用者，文档直接影响其对 API
质量和实用性的判断。文档完备且易懂，会极大促进开发者继续尝试和使用。完整且集中的文档让开发者高效编程，突出变更还能帮助使用者充分利用新特性，并及时调整代码。
预期成果 开发者能查到每个 API 调用的详细信息，包括参数和期望的返回内容，即与 API 相关的所有信息。使用方法、近期变动、联系方式等也应易于浏览。同时也便于机器自动访问 API
文档，帮助开发 API 客户端软件。
可能实现方式 典型的 API 参考文档会给出所有 API 调用清单，说明用途、参数、返回内容，并给出示例。现代 API 文档常内嵌测试表单，开发者可自定义请求验证响应效果。主流文档自动化工具有 Swagger 、io-docs 、OpenApis 等。此外 API 还应具备自说明性，即调用响应应包含出错和用法提示。API
使用者应能便捷联系维护者反馈问题。
文档质量还取决于开发者的使用和反馈，建议持续收集文档建议。
示例 25
为方便开发者，交通局为公交站点和线路数据提供了完善 API 文档。API 文档 列出 API
支持的调用、参数和部分示例。
如何测试 检查文档是否描述了所有 API 支持的调用，明确每个调用的参数和返回结果。
测试达到首次调用成功（TTFSC，首次成功调用时间）的耗时，能在几分钟内完成则有助于开发者长期留存。
益处
可复用性
可信度
最佳实践 26：避免对 API 的破坏性变更
避免对 API 做出破坏现有客户端代码的更改，并在 API 发生演进时及时通知开发者。
为何如此 开发者实现 API 客户端时，会依赖你定义的内容（如 schema、响应格式等）。避免 API 破坏性变更可最大限度减少客户代码失效。及时沟通 API
变更，使开发者能充分利用新特性，并在罕见破坏性变更时有机会做适配。
预期成果 开发者代码可持续工作。开发者能及时获知 API 的改进和演变。API 很少出现破坏性变更，若出现，开发者有足够的信息和时间适配，避免服务中断，提升信任度。所有 API 变更都会在 API
文档页面公布。
可能实现方式 改进 API 时，优先采用新增调用或新增可选参数，而非修改已有调用行为。这样原有客户端可无须关注也能继续正常运行。
完全 RESTful 风格时，资源 URI 应保持不变，只在开发者未直接依赖的部分做调整。若架构本身无法拓展需做不兼容更改，可单独开发新版 REST API，换新 URI 提供服务。
如果无法避免的不兼容变更，应采用版本管理。将版本号反映在响应头，或在 URI 或 Accept header中指示版本（如通过内容协商），并保持旧版对还未适配新版本的开发者可用。
示例 26
以下变更属于 API 破坏性变更例子：
移除某调用；
调用方式变化；
调用用到资源 URI 变更；
为调用新增必须参数；
参数类型变更；
响应键名变更；
XML 响应结构变更；
返回值类型变更，如字符串变成数组；
假设交通局的 API
响应单个站点到站时间请求（http://data.mycity.example.com/transport/api/arrivals/buses/53/stop/12），如需支持区间站点查询，建议新增像
http://data.mycity.example.com/transport/api/arrivals/buses/53/stops/1-12
的新调用，而不是兼容性破坏地修改原有接口。
为直接通知用户变更，建议建立邮件列表，鼓励开发者订阅，实现变更通知和交流互助。
如何测试 在正式环境应用前，先将变更发布于测试环境，邀请开发者体验和反馈。
益处
可信度
互操作性
8.11 数据保存工作组认识到，假定 Web 上的所有数据在未来任何时间都能按需访问并不现实。数据发布者出于多种原因，很可能会希望或需要将数据从在线 Web
移除，这种情况下数据保存问题超出了当前工作的范畴，进入了数据归档领域。但本规范 范畴内的，是发布者应当如何指明数据被移除或归档。直接删除资源是一种不良实践。这种情况下，解析该 URI 只会得到
404 响应码，除了告诉用户“资源不存在”外没有任何信息。以下最佳实践提供了更有益的做法。
最佳实践 27：保留标识符
当数据从 Web 移除时，保留标识符，并提供关于已归档资源的信息。
为何如此 URI 解析是 Web 数据的主要接口。如果解析 URI 得到臭名昭著的 404（未找到），用户根本不知道资源不可用是永久还是临时，是计划之中还是意外。如果发布者或第三方已归档了数据，若原
URI 彻底失效，这些归档副本被找到的概率会大大降低。
预期成果 资源的 URI 总能解析到资源本身，或跳转到关于它的信息。
可能实现方式 有两种情况需要考虑：
资源已被完全删除，无法通过任何途径访问；
资源已被归档，仅能通过归档申请获取。
第一种情况，服务器应设置为返回 410（已删除） 。来自规范：
410 响应主要是为了方便 Web 维护，通知请求方此资源已被有意移除，服务器希望删除所有远程链接。
第二种，数据已归档时，更合适做法是跳转到说明该数据保存在何处以及如何访问的页面。
无论哪种情况，原始 URI 都继续作为资源标识符，并能引导用户获得有用信息，即使数据本身不再直接可用。
示例 27
Adrian 决定将已被新版本替代的公交站点数据，归档不少于一年，比如 2012-03-30 的版本。服务器配置成：对 2012 年 3 月数据集的请求，用 303
跳转到包含如下通知的网页。
已归档
您请求的数据已归档。这符合 MyCity 超过 12 个月即归档的政策。您可随时通过联系页面 申请拷贝。
如何测试 检查对于不可用数据集的 URI，解析时能返回当前状态和可获取性说明，并根据情形返回 410 或 303 响应码。
益处
可复用性
可信度
最佳实践 28：评估数据集覆盖范围
在保存数据集前，对其覆盖范围进行评估。
为何如此 Web 数据片段本质上依赖于完整的全球图。这个全局上下文会影响数据集内资源的描述语义。理想情况下，保存特定数据集也应保存其全部上下文，也就是整个 Web 数据网。
归档时需评估数据集快照与已保存资源的链接，以及所用词汇表。若大多数词汇或资源尚未归档，则该数据集应被标记为高风险。
可能实现方式 检查所用所有资源，确保已被别处保存，或一同随数据集归档保存。
示例 28
以下是待保存的 RDF 数据集三元组片段：
<http://data.mycity.example.com/transport/route/bus/ABtimetable>
a gtfs:Route ;
gtfs:color "ff0000" ;
gtfs:shortname "10" ;
gtfs:longName "Airport - Bullfrog" ;
gtfs:agency <http://data.mycity.example.com/transport-agency/DTA> ;
gtfs:routeType ex:three ;
ex:usualVehicleType dbpedia:Routemaster ;
foaf:isPrimaryTopicOf ex:Airport_Bullfrog
.
<http://data.mycity.example.com/ransport/route/bus/BFC>
a gtfs:Route ;
gtfs:color "ffff00" ;
gtfs:shortname "20" ;
gtfs:longName "Bullfrog - Furnace Creek Resort" ;
gtfs:agency <http://data.mycity.example.com/transport-agency/DTA> ;
gtfs:routeType ex:three ;
ex:usualVehicleType dbpedia:Articulated_bus ;
foaf:isPrimaryTopicOf ex:Bullfrog_Furnace_Creek_Resort
.
…
这些三元组用了“gtfs”词汇，以及测试域名“ex”下的自定义词，还有 "foaf"、"dbpedia" 和 "ex"。FOAF 和 GTFS
尽管不是正式标准，但被广泛应用并在多个网络库保存（如 LOV 仓库 ）。DBpedia 的实体也能通过其 Memento gateway
及归档快照被访问。因此依赖这些外部资源的归档风险很低。而 “ex”
这种本地自定义命名空间，若不与三元组一同保存，“ex:usualVehicleType”、“ex:Airport_Bullfrog”、“ex:Bullfrog_Furnace_Creek_Resort”
的具体语义就会丢失。尤其 "ex:usualVehicleType" 若不保存，公交线路与 dbpedia 资源间的联系也会对应用不可见（尽管人类直观能明白）。
据此评估，更合适用于归档的数据集应包括 "ex:usualVehicleType" 的定义：
<http://data.mycity.example.com/transport/route/bus/AB> a gtfs:Route;
gtfs:color "ff0000" ;
gtfs:shortname "10" ;
gtfs:longName "Airport - Bullfrog" ;
gtfs:agency <http://data.mycity.example.com/transport-agency/DTA> ;
gtfs:routeType ex:three ;
ex:usualVehicleType dbpedia:Routemaster ;
foaf:isPrimaryTopicOf ex:Airport_Bullfrog
.
<http://data.mycity.example.com/transport/route/bus/BFC>
a gtfs:Route;
gtfs:color "ffff00";
gtfs:shortname "20";
gtfs:longName "Bullfrog - Furnace Creek Resort";
gtfs:agency <http://data.mycity.example.com/transport-agency/DTA>;
gtfs:routeType ex:three;
ex:usualVehicleType dbpedia:Articulated_bus;
foaf:isPrimaryTopicOf ex:Bullfrog_Furnace_Creek_Resort
.
…
# 自定义词汇元素
ex:usualVehicleType
a rdf:Property ;
rdfs:subPropertyOf gtfs:routeType ;
rdfs:range gtfs:Bus
.
第二组数据集更完整，自说明性更强，且只使用了有保障的外部实体，因此更适于保存。
如何测试 未来 50 年哪些内容还可用无法判断。但可检查归档数据集只依赖通用外部资源和词汇。要确认所有独有或冷僻依赖都随数据归档保存。
益处
可复用性
可信度
8.12 反馈在 Web
上发布数据能够实现大规模数据共享，覆盖不同专业水平的广泛受众。数据发布者希望确保其发布的数据能够满足数据使用者的需求，因此用户反馈非常重要。反馈对于发布者和使用者都有好处：它能帮助发布者提升数据完整性，也促进新数据的持续发布。反馈让数据使用者可以表达他们的使用体验（例如数据驱动的应用）、偏好和需求。如果条件允许，反馈还应对其他数据使用者公开。反馈公开可以让用户了解到其它数据使用者的存在，支持协作环境，并帮助社区了解哪些经验、问题或疑问正在被关注。
从用户界面角度看，收集数据使用者反馈有多种方式，包括网站注册、联系表单、质量评级、调查问卷和评论框等。从机器视角，数据发布者还可以记录数据使用指标或有关具体应用的信息。这样的反馈建立了数据发布者与使用者的沟通渠道。公开的反馈应以人类可读的形式展示。
本节为数据发布者提出一些最佳实践，以便让数据使用者能够提供反馈。反馈可针对人类用户，也可针对机器。
最佳实践 29：收集数据使用者反馈
为数据使用者提供可方便发现的反馈渠道。
为何如此 获取反馈有助于发布者理解数据使用者的需求，也能促进发布数据质量的提升。同时，反馈机制让用户感受到发布方关心他们的需求，有助于增强信任。明确指出反馈渠道，也能降低用户找寻反馈入口的障碍。
预期成果 数据使用者能够对数据集及其分发表进行反馈与评分。
可能实现方式 为数据使用者提供一种或多种反馈渠道，包括但不限于联系表单、点击式质量评分按钮、评论框等。若想最大化反馈价值，建议配合工单系统将每条反馈存入数据库，便于量化与分析。也建议记录每条反馈的类别（如编辑、分类[评分]、评论或提问），这样每项反馈可用数据集使用词汇
[VOCAB-DUV
如何测试 检查是否至少提供一种反馈渠道且可被使用者便捷发现。
最佳实践 30：公开用户反馈
将数据集及其分发表的用户反馈向公众公开。
为何如此 公开反馈能向用户展示他们的关注被重视，也可避免重复上报同一问题。展示反馈还能帮助用户理解会影响数据可用性的相关问题，并营造社区氛围。
预期成果 使用者能评估影响数据集的各类问题，了解其他用户的使用体验，并确认发布方正积极应对反馈。同时也可判断自己的意见是否已被反馈，减少多余的 bug 报告，也为维护者减轻重复工单压力。
可能实现方式 反馈既可作为 HTML 网页内容公开，也可用数据集使用词汇 [VOCAB-DUV
示例 30
:stops-2015 -05 -05
a dcat:Dataset ;
dct:title "Bus stops of MyCity" ;
dcat:keyword "transport" ,"mobility" ,"bus" ;
dct:issued "2015-05-05" ^^xsd:date ;
dcat:contactPoint <http:
dct:temporal <http:
dct:spatial <http:
dct:publisher :transport-agency-mycity ;
dct:accrualPeriodicity <http:
dcat:theme :mobility ;
dcat:distribution :stops-2015 -05 -05. csv
.
:stops-2015 -05 -05. csv
a dcat:Distribution ;
dct:title "CSV distribution of stops-2015-05-05 dataset" ;
dct:description "CSV distribution of the bus stops dataset of MyCity" ;
dcat:mediaType "text/csv;charset=UTF-8"
.
:comment1Content
a oa:TextualBody ;
rdf:value "This dataset is missing stop 3"
.
:comment1
a oa:Annotation ;
a duv:UserFeedback ;
oa:hasBody :comment1Content ;
oa:hasTarget :stops-2015 -05 -05 ;
dct:creator :localresident ;
oa:motivatedBy oa:assessing
.
:comment2Content
a oa:TextualBody ;
rdf:value "Are tab delimited formats also available?"
.
:comment2
a oa:Annotation ;
a duv:UserFeedback ;
oa:hasBody :comment2Content ;
oa:hasTarget :stops-2015 -05 -05. csv ;
dct:creator :localresident ;
oa:motivatedBy oa:assessing
.
:localresident
a foaf:Person ;
foaf:Name "Alan Law"
.
如何测试 检查任一数据集/分发表的用户反馈都能被公开获取。
益处
可复用性
可信度
8.13 数据丰富和增强数据丰富是指用于提升、精炼或改进原始或已处理数据的一类操作。这个概念及相关技术让数据成为现代企业的重要资产，本身话题广泛，细节不在本文件范围。但值得注意的是，部分增强技术需谨慎使用，因为存在伦理风险。在科研中应避免因增强而扭曲统计结果，涉及个人数据时合并不同数据集可能引发隐私风险。例如，两个单独数据集都无法识别个人，但合并后可能泄露隐私。加之这些技术可大规模实施，因此更需警惕和规范。
本节为数据发布者就数据丰富和增强提供建议。
最佳实践 31：通过生成新数据丰富数据
如有助于提升数据价值，可通过生成新数据丰富你的数据。
为何如此 增强可以极大提升对非结构化数据的处理性。某些情况下可补足缺失数据，或据原始数据生成新属性和指标。还可采集补充数据或融合其它数据集。及时出版更完整的数据集，有助于建立信任（如方法符合学术伦理）。推导出具普遍价值的新数据也能节省用户时间、促进再用。智能化方法可让数据更具资产价值。
预期成果 缺失值的数据集被完整补足。如能补充关键属性，结构就会更清晰、用途提升，同时不损害统计分析结果和显著性。
可能实现方式 丰富数据的技术手段众多，超出本文范围，这里仅列部分方向。
可用机器学习等技术丰富数据，例如分类、消歧、实体识别、情感分析、主题提取等。也可通过对现有列做数学运算生成新字段，或人工检查提取空间数据特征、跨库查找人口统计信息。另有需求驱动的新数据生成，如缺失值自动计算或补全。
用推理类技术生成的新取值应加以标识；若覆盖了原数据，需能查回被替换的原值。
如许可证允许，建议公开丰富数据的相关代码，尤其对科研类数据尤其重要。
应优先考虑消费者价值和实施难度。如能量化需求（调查或记录请求量），优先满足高需求项，同时说明需求评估方式可凸显数据增值。
如你增强了他人的数据，也建议回馈给原发布者。
示例 31
MyCity交通局为每个公交站点都有街道地址，为便于用户与地图结合，新增了经纬度字段。
交通局收到大量乘客邮件，有表扬有投诉有咨询。交通局用情感分析和分类算法，为每封邮件提取交通方式、线路、用户态度等元数据，并形成半结构化数据集。
如何测试 检查数据集中是否已补全所有缺失值，以及是否已补充其他用户可能需要的字段。基于推理技术丰富的数据，要标明来源且原始数据能回溯。
最佳实践 32：提供补充性数据展示
通过可视化、表格、Web 应用或摘要等补充方式丰富数据展示，让数据更直观易用。
为何如此 在线发布数据旨在让他人充分了解数据内容。但若只提供下载或 API，用户需自己消化和分析。Web 为数据直观展现提供了绝佳机会，用户无需自建工具即可探索数据。
预期成果 补充性数据展示可让人类用户无需下载或分析即可直观理解数据内容。
可能实现方式 最直接的方法是在 HTML 页面发布分 析摘要。用图表或表格展示摘要数据能帮助用户快速浏览并理解数据含义。
有条件时可以开发交互式可视化或 Web 应用，让用户能自主探索和发现数据模式。这类方案还能证明数据具备良好的可处理性，进一步促进数据再用。
如何测试 检查数据集是否有无需下载或调用 API 即可获得的补充解读内容。
8.14 再发布复用数据本质上也是一种发布数据的方式，它就是再次发布数据。再发布可以表现为将已有数据与其他数据集组合，创建 Web 应用或可视化，或者以新形式重新包装数据，例如翻译。数据再发布者在 Web
发布时有一些独特责任。本节为再发布数据者提供相应建议。
最佳实践 33：向原发布者反馈
当你复用别人的数据时，通知原发布者。如果发现错误、有建议或好评，也要让他们知道。
为何如此 发布者通常希望了解自己发布的数据是否有用。此外，某些情况下他们需要汇报数据使用情况好为数据发布活动争取资源。汇报你的使用情况有助于他们证明数据发布工作的价值。反馈还能直接帮助发布者提升数据集质量，服务后续用户。
预期成果 更好的交流能让原发布者更容易了解数据被如何使用，从而为持续发布数据提供依据。发布者还能获知如何改进自己的数据。这将带来更多更好的数据。
可能实现方式 开始在新产品中使用数据集时，记下发布者联系方式、你用到的数据集的 URI 及联系时间，可以在代码注释中说明。按发布者指定方式反馈。如果没指定，查找数据网站的联系方式。
示例 33
# 调用 MyCity transit API, http://data.mycity.example.com/transport/api/docs/
# 由 MyCity Transit Agency 发布，
# 通过邮件 opendata@mycitytransit.example.org 通知其复用事宜
# Newton Calegari 于 3/24/2016
如何测试 检查你是否有至少一条告知发布方复用情况的沟通记录。
最佳实践 34：遵守许可条款
查找并遵守数据集原发布者的许可要求。
为何如此 许可为使用他人作品提供法律框架。遵守原发布者要求，有助于维护良好合作关系，依法使用也无需担心法律风险。明确原始许可，也有助于你为再利用选择合适的许可。
预期成果 数据发布者可以相信自己的成果被依法合规再利用，会更有意愿持续发布数据。数据再使用者能为自己的衍生作品选择合适的授权。
可能实现方式 认真阅读原始许可并严格遵守。如果许可要求衍生作品也应有特定授权，请选用兼容的许可证。如果没有明确许可，联系原发布者询问。
如何测试 逐条阅读原始许可证，确保你的使用未违反任何条款。
益处
可复用性
可信度
最佳实践 35：引用原始出版物
在元数据中注明数据来源。如果有用户界面，也应在界面上显著注明引用信息。
为何如此 只有值得信赖的数据才有用，说明来源能从两个层面提升可信度：用户可据来源判断数据本身的可靠性，引用来源也能证明你本身是可信的数据再发布方。除了告知终端用户，引用还可帮助发布者获得应有的认可，使其更愿意继续开放数据。引用还能维护数据的溯源，有助于他人后续处理。
预期成果 终端用户能够判断数据的可信性，原始发布者得到认可。Web 数据的溯源链条可以追溯到最初的发布者。
可能实现方式 你可在界面上以书目信息和有效链接形式注明数据原始来源。
示例 35
数据来源：MyCity Transport Agency. “Bus timetable of
MyCity”（系列1.2），MyCity，2015年5月5日。可获取自：http://data.mycity.example.com/transport/dataset/bus/stops。
如何测试 检查所有被复用数据的元数据都注明原始来源。检查所有用户界面上都能显著看到人类可读的引用。
A. 致谢编辑们衷心感谢工作组所有成员对本文档的贡献。特别感谢 Annette Greiner 的巨大努力以及 Antoine Isaac、Eric Stephan 和 Phil Archer 的贡献。
本文件受益于空间数据 Web 工作组众多成员的意见与输入。特别感谢 Andrea Perego、Dan Brickley、Linda van den Brink 和 Jeremy Tandy。
编辑们还感谢以下人员提供的评论：Addison Phillips、Adriano Machado、Adriano Veloso、Andreas Kuckartz、Augusto Herrmann、Bart van
Leeuwen、Christophe Gueret、Erik Wilde、Giancarlo Guizzardi、Gisele Pappa、Gregg Kellogg、Herbert Van de
Sompel、Ivan Herman、Leigh Dodds、Lewis John McGibbney、Makx Dekkers、Manuel Tomas Carrasco-Benitez、Maurino
Andrea、Michel Dumontier、Nandana Mihindukulasooriya、Nathalia Sautchuk Patrício、Peter Winstanley、Renato
Iannella、Steven Adler、Vagner Diniz 和 Wagner Meira。
编辑们也感谢本工作组的主席：Deirdre Lee、Hadley Beeman、Yaso Córdova 以及工作人员联系人 Phil Archer。
B. 变更历史自 上一个版本 以来的更改：
重组了引言并 略有扩展 ，以明确 DWBP
是一份总体性文档，并由更具体领域的工作作为补充。
为 SVG 图添加了额外属性以提高其可访问性。
在 命名空间表 中添加了描述性名称
运行示例中使用的名字 John 更改为更具性别中性的 Adrian。
↑
