Independent Submission H. Van de Sompel
Request for Comments: 8574 Data Archiving and Networked Services
Category: Informational M. Nelson
ISSN: 2070-1721 Old Dominion University
G. Bilder
Crossref
J. Kunze
California Digital Library
S. Warner
Cornell University
April 2019
Independent Submission H. Van de Sompel
Request for Comments: 8574 Data Archiving and Networked Services
Category: Informational M. Nelson
ISSN: 2070-1721 Old Dominion University
G. Bilder
Crossref
J. Kunze
California Digital Library
S. Warner
Cornell University
April 2019
cite-as: A Link Relation to Convey a Preferred URI for Referencing
引用为：传递首选URI以供引用的链接关系
Abstract
摘要
A web resource is routinely referenced by means of the URI with which it is directly accessed. But cases exist where referencing a resource by means of a different URI is preferred. This specification defines a link relation type that can be used to convey such a preference.
web资源通常通过URI进行引用，直接使用URI进行访问。但在某些情况下，通过不同的URI引用资源是首选的。本规范定义了一种链接关系类型，可用于传达这种偏好。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
这是对RFC系列的贡献，独立于任何其他RFC流。RFC编辑器已选择自行发布此文档，并且未声明其对实现或部署的价值。RFC编辑批准发布的文件不适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8574.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8574.
Copyright Notice
版权公告
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
版权（c）2019 IETF信托基金和被确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Persistent Identifiers . . . . . . . . . . . . . . . . . 3
3.2. Version Identifiers . . . . . . . . . . . . . . . . . . . 5
3.3. Preferred Social Identifier . . . . . . . . . . . . . . . 5
3.4. Multi-resource Publications . . . . . . . . . . . . . . . 6
4. The "cite-as" Relation Type for Expressing a Preferred URI
for the Purpose of Referencing . . . . . . . . . . . . . . . 6
5. Distinction with Other Relation Types . . . . . . . . . . . . 8
5.1. The "bookmark" Relation Type . . . . . . . . . . . . . . 9
5.2. The "canonical" Relation Type . . . . . . . . . . . . . . 9
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Persistent HTTP URI . . . . . . . . . . . . . . . . . . . 11
6.2. Version URIs . . . . . . . . . . . . . . . . . . . . . . 12
6.3. Preferred Profile URI . . . . . . . . . . . . . . . . . . 13
6.4. Multi-resource Publication . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . 15
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Persistent Identifiers . . . . . . . . . . . . . . . . . 3
3.2. Version Identifiers . . . . . . . . . . . . . . . . . . . 5
3.3. Preferred Social Identifier . . . . . . . . . . . . . . . 5
3.4. Multi-resource Publications . . . . . . . . . . . . . . . 6
4. The "cite-as" Relation Type for Expressing a Preferred URI
for the Purpose of Referencing . . . . . . . . . . . . . . . 6
5. Distinction with Other Relation Types . . . . . . . . . . . . 8
5.1. The "bookmark" Relation Type . . . . . . . . . . . . . . 9
5.2. The "canonical" Relation Type . . . . . . . . . . . . . . 9
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Persistent HTTP URI . . . . . . . . . . . . . . . . . . . 11
6.2. Version URIs . . . . . . . . . . . . . . . . . . . . . . 12
6.3. Preferred Profile URI . . . . . . . . . . . . . . . . . . 13
6.4. Multi-resource Publication . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . 15
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
A web resource is routinely referenced (e.g., linked or bookmarked) by means of the URI with which it is directly accessed. But cases exist where referencing a resource by means of a different URI is preferred, for example, because the latter URI is intended to be more persistent over time. Currently, there is no link relation type to convey such an alternative referencing preference; this specification addresses this deficit by introducing a link relation type intended for that purpose.
web资源通常通过URI进行引用（例如，链接或书签），直接使用URI进行访问。但是，在某些情况下，通过不同的URI引用资源是首选的，例如，因为后者的URI随着时间的推移更持久。目前，没有链接关系类型来传达这种替代参考偏好；本规范通过引入用于此目的的链接关系类型来解决此缺陷。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
This specification uses the terms "link context" and "link target" as defined in [RFC8288]. These terms correspond with "Context IRI" and "Target IRI", respectively, as used in [RFC5988]. Although defined as IRIs (Internationalized Resource Identifiers), they are also URIs in common scenarios.
本规范使用[RFC8288]中定义的术语“链接上下文”和“链接目标”。这些术语分别对应于[RFC5988]中使用的“上下文IRI”和“目标IRI”。尽管定义为IRI（国际化资源标识符），但它们在常见场景中也是URI。
Additionally, this specification uses the following terms:
此外，本规范使用以下术语：
o "access URI": A URI at which a user agent accesses a web resource.
o “访问URI”：用户代理访问web资源的URI。
o "reference URI": A URI, other than the access URI, that should preferentially be used for referencing.
o “引用URI”：除访问URI外，应优先用于引用的URI。
By interacting with the access URI, the user agent may discover typed links. For such links, the access URI is the link context.
通过与访问URI交互，用户代理可以发现类型化链接。对于此类链接，访问URI是链接上下文。
Despite sound advice regarding the design of Cool URIs [CoolURIs], link rot ("HTTP 404 Not Found") is a common phenomena when following links on the Web. Certain communities of practice (see examples below) have introduced solutions to combat this problem. These solutions typically consist of:
尽管关于CoolURI[CoolURI]的设计有很好的建议，但在Web上跟踪链接时，链接腐烂（“HTTP 404未找到”）是一种常见现象。某些实践团体（见下面的例子）已经介绍了解决这一问题的方法。这些解决方案通常包括：
o Accepting the reality that the web location of a resource -- the access URI -- may change over time.
o 接受资源的web位置（访问URI）可能随时间而变化的现实。
o Minting an additional URI for the resource -- the reference URI -- that is specifically intended to remain persistent over time.
o 为资源生成一个额外的URI——引用URI，该URI专门用于在一段时间内保持持久性。
o Redirecting (typically with "HTTP 301 Moved Permanently", "HTTP 302 Found", or "HTTP 303 See Other") from the reference URI to the access URI.
o 从参考URI重定向（通常使用“HTTP 301永久移动”、“找到HTTP 302”或“HTTP 303请参阅其他”）到访问URI。
o Committing, as a community of practice, to adjust that redirection whenever the access URI changes over time.
o 作为一个实践社区，承诺在访问URI随时间变化时调整重定向。
This approach is, for example, used by:
例如，这种方法用于：
o Scholarly publishers that use DOIs (Digital Object Identifiers) [DOIs] to identify articles and DOI URLs [DOI-URLs] as a means to keep cross-publisher article-to-article links operational, even when the journals in which the articles are published change hands from one publisher to another, for example, as a result of an acquisition.
o 使用DOI（数字对象标识符）[DOI]来识别文章和DOI URL[DOI URL]作为保持跨出版商文章到文章链接运行的手段的学术出版商，即使在发布文章的期刊从一个出版商转手到另一个出版商时，例如，由于收购。
o Authors of controlled vocabularies that use PURLs (Persistent Uniform Resource Locators) [PURLs] for vocabulary terms to ensure that the URIs they assign to vocabulary terms remain stable even if management of the vocabulary is transferred to a new custodian.
o 受控词汇表的作者对词汇表术语使用PURL（持久统一资源定位器）[PURL]，以确保分配给词汇表术语的URI保持稳定，即使将词汇表的管理转移给新的保管人。
o A variety of organizations (including libraries, archives, and museums) that assign ARK (Archival Resource Key) URLs [ARK] to information objects in order to support long-term access.
o 各种组织（包括图书馆、档案馆和博物馆）为信息对象分配ARK（档案资源密钥）URL[ARK]，以支持长期访问。
In order for the investments in infrastructure involved in these approaches to pay off, and hence for links to effectively remain operational as intended, it is crucial that a resource be referenced by means of its reference URI. However, the access URI is where a user agent actually accesses the resource (e.g., it is the URI in the browser's address bar). As such, there is a considerable risk that the access URI instead of the reference URI is used for referencing [PIDs-must-be-used].
为了使这些方法所涉及的基础设施投资获得回报，从而使链接有效地保持预期的可操作性，通过引用URI引用资源是至关重要的。但是，访问URI是用户代理实际访问资源的位置（例如，它是浏览器地址栏中的URI）。因此，使用访问URI而不是引用URI进行引用存在相当大的风险[PIDs必须使用]。
The link relation type defined in this document makes it possible for user agents to differentiate the reference URI from the access URI.
本文档中定义的链接关系类型使得用户代理能够区分引用URI和访问URI。
Resource versioning systems often use a naming approach whereby:
资源版本控制系统通常使用命名方法，其中：
o The most recent version of a resource is always available at the same, generic URI.
o 资源的最新版本始终在相同的通用URI中可用。
o Each version of the resource -- including the most recent one -- has a distinct version URI.
o 资源的每个版本（包括最近的版本）都有一个不同的版本URI。
For example, Wikipedia uses generic URIs of the form <https://en.wikipedia.org/wiki/John_Doe> and version URIs of the form <https://en.wikipedia.org/w/index.php?title=John_Doe&oldid= 776253882>.
例如，Wikipedia使用这种形式的通用URI<https://en.wikipedia.org/wiki/John_Doe>和表单的版本URI<https://en.wikipedia.org/w/index.php?title=John_Doe&oldid= 776253882>.
While the current version of a resource is accessed at the generic URI, some versioning systems adhere to a policy that favors linking and referencing a specific version URI. To express this using the terminology of Section 2, these policies intend that the generic URI is the access URI and that the version URI is the reference URI. These policies are informed by the understanding that the content at the generic URI is likely to evolve over time and that accurate links or references should lead to the content as it was at the time of referencing. To that end, Wikipedia's "Permanent link" and "Cite this page" functionalities promote the version URI, not the generic URI.
虽然资源的当前版本是通过通用URI访问的，但一些版本控制系统遵循有利于链接和引用特定版本URI的策略。为了使用第2节的术语来表达这一点，这些策略打算将通用URI作为访问URI，将版本URI作为参考URI。这些策略是通过理解通用URI中的内容可能会随着时间的推移而变化，并且准确的链接或引用会导致内容在引用时的状态。为此，维基百科的“永久链接”和“引用此页面”功能提升了版本URI，而不是通用URI。
The link relation type defined in this document makes it possible for user agents to differentiate the version URI from the generic URI.
本文档中定义的链接关系类型使用户代理能够区分版本URI和通用URI。
A web user commonly has multiple profiles on the Web, for example, one per social network, a personal homepage, a professional homepage, a FOAF (Friend Of A Friend) profile [FOAF], etc. Each of these profiles is accessible at a distinct URI. But the user may have a preference for one of those profiles, for example, because it is most complete, kept up to date, or expected to be long lived. As an example, the first author of this document has, among others, the following profile URIs:
web用户通常在web上有多个配置文件，例如，每个社交网络一个配置文件、个人主页、专业主页、FOAF（朋友的朋友）配置文件[FOAF]等。这些配置文件中的每一个都可以通过不同的URI访问。但是用户可能更喜欢这些配置文件中的一个，例如，因为它是最完整的、最新的，或者预期寿命很长。例如，本文档的第一作者拥有以下配置文件URI：
o <https://hvdsomp.info>
o <https://hvdsomp.info>
o <https://twitter.com/hvdsomp>
o <https://twitter.com/hvdsomp>
o <https://www.linkedin.com/in/herbertvandesompel/>
o <https://www.linkedin.com/in/herbertvandesompel/>
o <https://orcid.org/0000-0002-0715-6126>
o <https://orcid.org/0000-0002-0715-6126>
Of these, from the perspective of the person described by these profiles, the first URI may be the preferred profile URI for the purpose of referencing because the domain is not under the custodianship of a third party. When an agent accesses another profile URI, such as <https://orcid.org/0000-0002-0715-6126>, this preference for referencing by means of the first URI could be expressed.
其中，从这些简档所描述的人的角度来看，出于引用的目的，第一URI可以是优选简档URI，因为域不在第三方的保管之下。当代理访问另一个配置文件URI时，例如<https://orcid.org/0000-0002-0715-6126>，可以表示通过第一个URI进行引用的这种偏好。
The link relation type defined in this specification makes it possible for user agents to differentiate the preferred profile URI from the accessed profile URI.
本规范中定义的链接关系类型使得用户代理能够区分首选配置文件URI和访问的配置文件URI。
When publishing on the Web, it is not uncommon to make distinct components of a publication available as different web resources, each with their own URI. For example:
在Web上发布时，将发布的不同组件作为不同的Web资源提供并不少见，每个组件都有自己的URI。例如：
o Contemporary scholarly publications routinely consists of a traditional article as well as additional materials that are considered an integral part of the publication such as supplementary information, high-resolution images, or a video recording of an experiment.
o 当代学术出版物通常包括一篇传统文章以及作为出版物组成部分的附加材料，如补充信息、高分辨率图像或实验录像。
o Scientific or governmental open data sets frequently consist of multiple files.
o 科学或政府开放数据集通常由多个文件组成。
o Online books typically consist of multiple chapters.
o 在线图书通常由多个章节组成。
While each of these components is accessible at its distinct URI -- the access URI -- they often also share a URI assigned to the intellectual publication of which they are components -- the reference URI.
虽然这些组件中的每一个都可以通过其不同的URI（访问URI）进行访问，但它们通常也共享分配给它们所属的智能发布的URI（引用URI）。
The link relation type defined in this document makes it possible for user agents to differentiate the URI of the intellectual publication from the access URI of a component of the publication.
本文档中定义的链接关系类型使得用户代理能够区分智能出版物的URI和出版物组件的访问URI。
4. The "cite-as" Link Relation Type for Expressing a Preferred URI for the Purpose of Referencing
4. “引用为”链接关系类型，用于表示用于引用的首选URI
A link with the "cite-as" relation type indicates that, for referencing the link context, use of the URI of the link target is preferred over use of the URI of the link context. It allows the resource identified by the access URI (link context) to unambiguously link to its corresponding reference URI (link target), thereby expressing that the link target is preferred over the link context for the purpose of permanent citation.
具有“cite as”关系类型的链接表示，对于引用链接上下文，使用链接目标的URI比使用链接上下文的URI更可取。它允许由访问URI（链接上下文）标识的资源明确链接到其相应的参考URI（链接目标），从而表示出于永久引用的目的，链接目标优先于链接上下文。
The link target of a "cite-as" link SHOULD support protocol-based access as a means to ensure that applications that store them can effectively reuse them for access.
“引用为”链接的链接目标应支持基于协议的访问，以确保存储它们的应用程序能够有效地重用它们进行访问。
The link target of a "cite-as" link SHOULD provide the ability for a user agent to follow its nose back to the context of the link, e.g., by following redirects and/or links. This helps a user agent to establish trust in the target URI.
“引用为”链接的链接目标应为用户代理提供跟踪链接上下文的能力，例如，通过跟踪重定向和/或链接。这有助于用户代理在目标URI中建立信任。
Because a link with the "cite-as" relation type expresses a preferred URI for the purpose of referencing, the access URI SHOULD only provide one link with that relation type. If more than one "cite-as" link is provided, the user agent may decide to select one (e.g., an HTTP URI over a mailto URI) based on the purpose that the reference URI will serve.
由于具有“cite as”关系类型的链接表示用于引用的首选URI，因此访问URI应仅提供一个具有该关系类型的链接。如果提供了不止一个“引用为”链接，则用户代理可以基于参考URI将服务的目的决定选择一个（例如，相对于mailto URI的HTTP URI）。
Providing a link with the "cite-as" relation type does not prevent using the access URI for the purpose of referencing if such specificity is needed for the application at hand. For example, in the case of the scenario in Section 3.4, the access URI is likely required for the purpose of annotating a specific component of an intellectual publication. Yet, the annotation application may also want to appropriately include the reference URI in the annotation.
如果手头的应用程序需要这种特殊性，那么提供带有“cite as”关系类型的链接并不妨碍使用访问URI进行引用。例如，在第3.4节中的场景中，可能需要访问URI来注释知识出版物的特定组件。然而，注释应用程序可能还希望在注释中适当地包含引用URI。
Applications can leverage the information provided by a "cite-as" link in a variety of ways, for example:
应用程序可以通过多种方式利用“引用为”链接提供的信息，例如：
o Bookmarking tools and citation managers can take this preference into account when recording a URI.
o 在记录URI时，书签工具和引用管理器可以考虑这一偏好。
o Webometrics applications that trace URIs can trace both the access URI and the reference URI.
o 跟踪URI的WebMetrics应用程序可以跟踪访问URI和参考URI。
o Discovery tools can support lookup by means of both the access and the reference URI. This includes web archives that typically make archived versions of web resources discoverable by means of the original access URI of the archived resource; they can additionally make these archived resources discoverable by means of the associated reference URI.
o 发现工具可以通过访问和引用URI来支持查找。这包括通常通过存档资源的原始访问URI使web资源的存档版本可被发现的web存档；此外，它们还可以通过关联的引用URI使这些存档资源可被发现。
Some existing IANA-registered relationships intuitively resemble the relationship that "cite-as" is intended to convey. But a closer inspection of these candidates provided in the blog posts [identifier-blog], [canonical-blog], and [bookmark-blog] shows that they are not appropriate for various reasons and that a new link relation type is required. The remainder of this section provides a summary of the detailed explanations provided in the referenced blog posts.
一些现有的IANA注册关系直观上类似于“引用为”旨在传达的关系。但是，对博客文章[identifier blog]、[canonical blog]和[bookmark blog]中提供的这些候选人进行仔细检查后发现，出于各种原因，这些候选人并不合适，需要一种新的链接关系类型。本节剩余部分提供了参考博客文章中提供的详细解释摘要。
It can readily be seen that the following link relation types do not address the requirements described in Section 3:
可以看出，以下链接关系类型不满足第3节中描述的要求：
o "alternate" [RFC4287]: The link target provides an alternate version of the content at the link context. These are typically variants according to dimensions that are subject to content negotiation, for example, the same content with varying Content-Type (e.g., application/pdf vs. text/html) and/or Content-Language (e.g., en vs. fr). The representations provided by the context URIs and target URIs in the scenarios in Sections 3.1 through 3.4 are not variants in the sense intended by [RFC4287], and, as such, the use of "alternate" is not appropriate.
o “alternate”[RFC4287]：链接目标在链接上下文中提供内容的替代版本。这些通常是根据要进行内容协商的维度的变体，例如，具有不同内容类型（例如，应用程序/pdf与文本/html）和/或内容语言（例如，en与fr）的相同内容。在第3.1节至第3.4节的场景中，上下文URI和目标URI提供的表示不是[RFC4287]所期望的变体，因此，“替代”的使用是不合适的。
o "duplicate" [RFC6249]: The link target is a resource whose available representations are byte-for-byte identical with the corresponding representations of the link context, for example, an identical file on a mirror site. In none of the scenarios described in Sections 3.1 through 3.4 do the link context and the link target provide identical content. As such, the use of "duplicate" is not appropriate.
o “duplicate”[RFC6249]：链接目标是一种资源，其可用表示形式是与链接上下文的相应表示形式逐字节相同的，例如，镜像站点上的相同文件。在第3.1节至第3.4节中描述的任何场景中，链接上下文和链接目标都不提供相同的内容。因此，使用“复制”是不合适的。
o "related" [RFC4287]: The link target is a resource that is related to the link context. While "related" could be used in all of the scenarios described in Sections 3.1 through 3.4, its semantics are too vague to convey the specific semantics intended by "cite-as".
o “相关”[RFC4287]：链接目标是与链接上下文相关的资源。虽然“相关”可用于第3.1节至第3.4节中所述的所有场景，但其语义过于模糊，无法传达“引用as”的具体语义。
Two existing IANA-registered relationships deserve closer attention and are discussed in the remainder of this section.
两个现有的IANA注册关系值得密切关注，本节剩余部分将对此进行讨论。
"bookmark" [W3C.REC-html52-20171214]: The link target provides a URI for the purpose of bookmarking the link context.
“书签”[W3C.REC-html52-20171214]：链接目标提供一个URI，用于为链接上下文添加书签。
The intent of "bookmark" is closest to that of "cite-as" in that the link target is intended to be a permalink for the link context, for bookmarking purposes. The link relation type dates back to the earliest days of news syndication, before blogs and news feeds had permalinks to identify individual resources that were aggregated into a single page. As such, its intent is to provide permalinks for different sections of an HTML document. It was originally used with HTML elements such as <div>, <h1>, <h2>, etc.; more recently, HTML5 revised it to be exclusively used with the <article> element. Moreover, it is explicitly excluded from use in the <link> element in HTML <head> and, as a consequence, in the HTTP Link header that is semantically equivalent. For these technical and semantic reasons, the use of "bookmark" to convey the relationship intended by "cite-as" is not appropriate.
“bookmark”的意图与“cite as”的意图最接近，因为链接目标是链接上下文的永久链接，用于书签目的。链接关系类型可以追溯到新闻联合的早期，在博客和新闻提要具有永久链接以识别聚合到单个页面中的单个资源之前。因此，它的目的是为HTML文档的不同部分提供永久链接。它最初与HTML元素一起使用，如<div>、<h1>、<h2>等。；最近，HTML5对其进行了修订，专门用于<article>元素。此外，它被明确地排除在HTML<head>中的<link>元素中使用，因此，它也被排除在语义等价的HTTP链接头中。出于这些技术和语义原因，使用“书签”来表达“引用为”所表达的关系是不合适的。
A more detailed justification regarding the inappropriateness of "bookmark", including a thorough overview of its turbulent history, is provided in [bookmark-blog].
[bookmark blog]中提供了关于“bookmark”不恰当的更详细的理由，包括对其动荡历史的全面概述。
"canonical" [RFC6596]: The meaning of "canonical" is commonly misunderstood on the basis of its brief definition as being "the preferred version of a resource." The description in the abstract of [RFC6596] is more helpful and states that "canonical" is intended to link to a resource that is preferred over resources with duplicative content. A more detailed reading of [RFC6596] clarifies that the intended meaning is that "canonical" is preferred for the purpose of content indexing. A typical use case is linking from each page in a multi-page magazine article to a single page version of the article provided for indexing by search engines: the former pages provide content that is duplicative to the superset content that is available at the latter page.
“canonical”[RFC6596]：“canonical”的含义通常被误解，因为它的简短定义是“资源的首选版本”。[RFC6596]摘要中的描述更为有用，并指出“canonical”旨在链接到优先于具有重复内容的资源的资源。[RFC6596]的更详细阅读阐明了其意图是为了内容索引而首选“规范”。一个典型的用例是从多页杂志文章中的每页链接到由搜索引擎索引的文章的单页版本：前一页提供的内容与后一页提供的超集内容重复。
The semantics intended by "canonical" as preferred for the purpose of content indexing differ from the semantics intended by "cite-as" as preferred for the purpose of referencing. A further exploration of the various scenarios shows that the use of "canonical" is not appropriate to convey the semantics intended by "cite-as":
“canonical”作为内容索引首选的语义不同于“cite as”作为引用首选的语义。对各种场景的进一步研究表明，“canonical”的使用不适合传达“cite as”的语义：
o Scenario of Section 3.1: The reference URI that is intended to be persistent over time does not serve content that needs to be indexed; it merely redirects to the access URI. Since the meaning intended by "canonical" is that it is preferred for the purpose of content indexing, it is not appropriate to point at the reference URI (persistent identifier) using the "canonical" link relation type. Moreover, Section 6.1 shows that scholarly publishers that assign persistent identifiers already use the "canonical" link relation type for search engine optimization; it also shows how that use contrasts with the intended use of "cite-as".
o 第3.1节的场景：打算随时间持久化的参考URI不提供需要索引的内容；它只是重定向到访问URI。由于“canonical”的含义是为了内容索引的目的而首选，因此不适合使用“canonical”链接关系类型指向引用URI（持久标识符）。此外，第6.1节显示，分配持久标识符的学术出版商已经使用“规范”链接关系类型进行搜索引擎优化；它还显示了该用法与“引用as”的预期用法的对比。
o Scenario of Section 3.2: In most common cases, custodians of resource versioning systems want search engines to index the most recent version of a page and hence would use a "canonical" link to point from version URIs of a resource to the associated generic URI. Wikipedia effectively does this. However, for some resource versioning systems, including Wikipedia, version URIs are preferred for the purpose of referencing. As such, a "cite-as" link would point from the generic URI to the most recent version URI (that is, in the opposite direction of the "canonical" link).
o 第3.2节的场景：在大多数情况下，资源版本控制系统的管理员希望搜索引擎索引页面的最新版本，因此将使用“规范”链接从资源的版本URI指向关联的通用URI。维基百科有效地做到了这一点。但是，对于某些资源版本控制系统，包括Wikipedia，版本URI是首选的，用于引用。因此，“引用为”链接将从通用URI指向最新版本的URI（即，与“规范”链接的方向相反）。
o Scenario of Section 3.3: The content at the link target and the link context are different profiles for a same person. Each profile, not just a preferred one, should be indexed. But a single one could be preferred for referencing.
o 第3.3节的场景：链接目标的内容和链接上下文是同一个人的不同配置文件。每个配置文件，而不仅仅是首选配置文件，都应该编制索引。但是，可以选择一个作为参考。
o Scenario of Section 3.4: The content at the link target, if any, would typically be a landing page that includes descriptive metadata pertaining to the multi-resource publication and links to its component resources. Each component resource provides content that is different, not duplicative, to the landing page.
o 第3.4节的场景：链接目标处的内容（如果有）通常是一个登录页，其中包括与多资源出版物相关的描述性元数据及其组件资源的链接。每个组件资源提供的内容与登录页不同，而不是重复。
A more detailed justification regarding how the use of "canonical" is inappropriate to address the requirements described in this document, including examples, is provided in [canonical-blog].
[canonical blog]中提供了关于如何使用“canonical”来解决本文档中描述的需求（包括示例）的更详细的理由。
Sections 6.1 through 6.4 show examples of the use of links with the "cite-as" relation type. They illustrate how the typed links can be used in a response header and/or response body.
第6.1节至第6.4节展示了使用“引用为”关系类型链接的示例。它们说明了如何在响应头和/或响应体中使用类型化链接。
PLOS ONE is one of many scholarly publishers that assigns DOIs to the articles it publishes. For example, <https://doi.org/10.1371/ journal.pone.0171057> is the persistent identifier for such an article. Via the DOI resolver, this persistent identifier redirects to <https://journals.plos.org/plosone/doi?id=10.1371/ journal.pone.0171057> in the plos.org domain. This URI itself redirects to <https://journals.plos.org/plosone/article?id=10.1371/ journal.pone.0171057>, which delivers the actual article in HTML.
《公共科学图书馆·综合》是众多为其发表的文章指定内政部的学术出版商之一。比如说,<https://doi.org/10.1371/ journal.pone.0171057>是此类文章的持久标识符。通过DOI解析器，此持久标识符重定向到<https://journals.plos.org/plosone/doi?id=10.1371/ journal.pone.0171057>在plos.org域中。此URI本身重定向到<https://journals.plos.org/plosone/article?id=10.1371/ journal.pone.0171057>，以HTML格式提供实际文章。
The HTML article contains a <link> element with the "canonical" link relation type pointing at itself, <https://journals.plos.org/plosone/ article?id=10.1371/journal.pone.0167475>. As per Section 5.2, this indicates that the article content at that URI should be indexed by search engines.
HTML文章包含一个<link>元素，其“规范”链接关系类型指向自身<https://journals.plos.org/plosone/ 文章？id=10.1371/journal.pone.0167475>。根据第5.2节，这表明该URI处的文章内容应该由搜索引擎索引。
PLOS ONE can additionally provide a link with the "cite-as" relation type pointing at the persistent identifier to indicate it is the preferred URI for permanent citation of the article. Figure 1 shows the addition of the "cite-as" link in both the HTTP header and the HTML that results from an HTTP GET on the article URI <https://journals.plos.org/plosone/article?id=10.1371/ journal.pone.0167475>.
PLOS ONE还可以提供一个带有指向持久标识符的“cite as”关系类型的链接，以表明它是文章永久引用的首选URI。图1显示了在HTTP头和HTML中添加的“cite as”链接，该链接由文章URI上的HTTP GET生成<https://journals.plos.org/plosone/article?id=10.1371/ journal.pone.0167475>。
HTTP/1.1 200 OK
Link: <https://doi.org/10.1371/journal.pone.0171057> ; rel="cite-as"
Content-Type: text/html;charset=utf-8
HTTP/1.1 200 OK
Link: <https://doi.org/10.1371/journal.pone.0171057> ; rel="cite-as"
Content-Type: text/html;charset=utf-8
<html>
<head>
...
<link rel="cite-as"
href="https://doi.org/10.1371/journal.pone.0171057" />
<link rel="canonical"
href="https://journals.plos.org/plosone/article?
id=10.1371/journal.pone.0167475" />
...
</head>
<body>
...
</body>
</html>
<html>
<head>
...
<link rel="cite-as"
href="https://doi.org/10.1371/journal.pone.0171057" />
<link rel="canonical"
href="https://journals.plos.org/plosone/article?
id=10.1371/journal.pone.0167475" />
...
</head>
<body>
...
</body>
</html>
Figure 1: Response to HTTP GET on the URI of a Scholarly Article
图1：一篇学术文章的URI上对HTTP GET的响应
The preprint server arXiv.org has a versioning approach like the one described in Section 3.2:
预印本服务器arXiv.org有一种版本控制方法，如第3.2节所述：
o The most recent version of a preprint is always available at the same, generic URI. Consider the preprint with generic URI <https://arxiv.org/abs/1711.03787>.
o 预印本的最新版本始终以相同的通用URI提供。考虑具有通用URI的预印本https://arxiv.org/abs/1711.03787>.
o Each version of the preprint -- including the most recent one -- has a distinct version URI. The considered preprint has two versions with respective version URIs: <https://arxiv.org/ abs/1711.03787v1> (published 10 November 2017) and <https://arxiv.org/abs/1711.03787v2> (published 24 January 2018).
o 预印本的每个版本（包括最新版本）都有一个不同的版本URI。所考虑的预印本有两个版本，分别具有版本URI：<https://arxiv.org/ abs/1711.03787v1>（2017年11月10日发布）和<https://arxiv.org/abs/1711.03787v2>（2018年1月24日出版）。
A reader who accessed <https://arxiv.org/abs/1711.03787> between 10 November 2017 and 23 January 2018, obtained the first version of the preprint. Starting 24 January 2018, the second version was served at that URI. In order to support accurate referencing, arXiv.org could implement the "cite-as" link to point from the generic URI to the most recent version URI. In doing so, assuming the existence of reference manager tools that consume "cite-as" links:
访问的读者<https://arxiv.org/abs/1711.03787>2017年11月10日至2018年1月23日期间，获得了预印本的第一版。从2018年1月24日起，第二个版本在该URI上提供。为了支持准确的引用，arXiv.org可以实现从通用URI到最新版本URI的“引用为”链接。在此过程中，假设存在使用“引用为”链接的引用管理器工具：
o The reader who accesses <https://arxiv.org/abs/1711.03787> between 10 November 2017 and 23 January 2018 would reference <https://arxiv.org/abs/1711.03787v1>.
o 访问的读者<https://arxiv.org/abs/1711.03787>2017年11月10日至2018年1月23日期间，将参考<https://arxiv.org/abs/1711.03787v1>.
o The reader who accesses <https://arxiv.org/abs/1711.03787> starting 24 January 2018 would reference <https://arxiv.org/ abs/1711.03787v2>.
o 访问的读者<https://arxiv.org/abs/1711.03787>从2018年1月24日起，将参考<https://arxiv.org/ abs/1711.03787v2>。
Figure 2 shows the header that arXiv.org would have returned in the first case, in response to a HTTP HEAD on the generic URI <https://arxiv.org/abs/1711.03787>.
图2显示了arXiv.org在第一种情况下返回的头，以响应通用URI上的HTTP头<https://arxiv.org/abs/1711.03787>.
HTTP/1.1 200 OK
Date: Sun, 24 Dec 2017 16:12:43 GMT
Content-Type: text/html; charset=utf-8
Link: <https://arxiv.org/abs/1711.03787v1> ; rel="cite-as"
Vary: Accept-Encoding,User-Agent
HTTP/1.1 200 OK
Date: Sun, 24 Dec 2017 16:12:43 GMT
Content-Type: text/html; charset=utf-8
Link: <https://arxiv.org/abs/1711.03787v1> ; rel="cite-as"
Vary: Accept-Encoding,User-Agent
Figure 2: Response to HTTP HEAD on the Generic URI of the Landing Page of an arXiv.org Preprint
图2:arXiv.org预印本登录页的通用URI上对HTTP头的响应
If the access URI is the home page of John Doe, John can add a link with the "cite-as" relation type to it, in order to convey that he would prefer to be referenced by means of the URI of his FOAF profile. Figure 3 shows the response to an HTTP GET on the URI of John's home page.
如果访问URI是John Doe的主页，John可以向其添加一个带有“cite as”关系类型的链接，以表示他更愿意通过其FOAF配置文件的URI被引用。图3显示了对John主页URI上HTTP GET的响应。
HTTP/1.1 200 OK
Content-Type: text/html;charset=utf-8
HTTP/1.1 200 OK
Content-Type: text/html;charset=utf-8
<html>
<head>
...
<link rel="cite-as" href="http://johndoe.example.com/foaf"
type="text/ttl"/>
...
</head>
<body>
...
</body>
</html>
<html>
<head>
...
<link rel="cite-as" href="http://johndoe.example.com/foaf"
type="text/ttl"/>
...
</head>
<body>
...
</body>
</html>
Figure 3: Response to HTTP GET on the URI of John Doe's Home Page
图3:JohnDoe主页URI上HTTP GET的响应
The Dryad Digital Repository at datadryad.org specializes in hosting and preserving scientific datasets. Each dataset typically consists of multiple resources. For example, the dataset "Data from: Climate, demography, and lek stability in an Amazonian bird" consists of an Excel spreadsheet, a csv file, and a zip file. Each of these resources have different content and are accessible at their respective URIs. In addition, the dataset has a landing page at <https://datadryad.org/resource/doi:10.5061/dryad.5d23f>.
位于datadryad.org的Dryad数字存储库专门负责托管和保存科学数据集。每个数据集通常由多个资源组成。例如，数据集“来自亚马逊鸟类的气候、人口统计和lek稳定性数据”由Excel电子表格、csv文件和zip文件组成。这些资源中的每一个都有不同的内容，可以通过各自的URI访问。此外，数据集在以下位置有一个登录页：<https://datadryad.org/resource/doi:10.5061/dryad.5d23f>.
Each of these resources should be permanently cited by means of the persistent identifier that was assigned to the entire dataset as an intellectual publication, i.e., <https://doi.org/10.5061/ dryad.5d23f>. To that end, the Dryad Digital Repository can add "cite-as" links pointing from the URIs of each of these resources to <https://doi.org/10.5061/dryad.5d23f>. This is shown in Figure 4 for the csv file that is a component resource of the dataset, through use of the HTTP Link header.
这些资源中的每一个都应通过永久标识符永久引用，永久标识符作为知识出版物分配给整个数据集，即<https://doi.org/10.5061/ dryad.5d23f>。为此，Dryad数字存储库可以添加指向每个资源的URI的“引用为”链接<https://doi.org/10.5061/dryad.5d23f>. 图4显示了csv文件，该文件是数据集的组件资源，通过使用HTTP链接头。
HTTP/1.1 200 OK
Date: Tue, 12 Jun 2018 19:19:22 GMT
Last-Modified: Wed, 17 Feb 2016 18:37:02 GMT
Content-Type: text/csv;charset=ISO-8859-1
Content-Length: 25414
Link: <https://doi.org/10.5061/dryad.5d23f> ; rel="cite-as"
HTTP/1.1 200 OK
Date: Tue, 12 Jun 2018 19:19:22 GMT
Last-Modified: Wed, 17 Feb 2016 18:37:02 GMT
Content-Type: text/csv;charset=ISO-8859-1
Content-Length: 25414
Link: <https://doi.org/10.5061/dryad.5d23f> ; rel="cite-as"
DATE,Year,PLOT/TRAIL,LOCATION,SPECIES CODE,BAND NUM,COLOR,SEX,AGE, TAIL,WING,TARSUS,NARES,DEPTH,WIDTH,WEIGHT 6/26/02,2002,DANTA,325,PIPFIL,969,B/O,M,AHY,80,63,16,7.3,3.9,4.1, 14.4 ... 2/3/13,2013,LAGO,,PIPFIL,BR-5095,O/YPI,M,SCB,78,65.5,14.2,7.5,3.8, 3.7,14.3
日期、年份、地块/步道、位置、物种代码、带数、颜色、性别、年龄、尾巴、翅膀、跗骨、鼻孔、深度、宽度、体重2002年6月26日，丹塔，325，皮菲尔，969，B/O，M，AHY，80,63,16,7.3,3.9,4.1,14.4。。。2013年2月3日，拉戈，皮菲尔，BR-5095，O/YPI，M，SCB，78,65.5,14.2,7.5,3.8,3.7,14.3
Figure 4: Response to HTTP GET on the URI of a csv File That Is a Component of a Scientific Dataset
图4：对作为科学数据集组件的csv文件URI的HTTP GET的响应
The link relation type has been registered by IANA per Section 2.1.1 of [RFC8288] as follows:
IANA已根据[RFC8288]第2.1.1节的规定对链接关系类型进行了登记，如下所示：
Relation Name: cite-as
关系名称：引用为
Description: Indicates that the link target is preferred over the link context for the purpose of permanent citation.
描述：表示为了永久引用的目的，链接目标优先于链接上下文。
Reference: RFC 8574
参考：RFC 8574
In cases where there is no way for the agent to automatically verify the correctness of the reference URI (cf. Section 4), out-of-band mechanisms might be required to establish trust.
在代理无法自动验证参考URI正确性的情况下（参见第4节），可能需要带外机制来建立信任。
If a trusted site is compromised, the "cite-as" link relation could be used with malicious intent to supply misleading URIs for referencing. Use of these links might direct user agents to an attacker's site, break the referencing record they are intended to support, or corrupt algorithmic interpretation of referencing data.
如果受信任的站点被破坏，“引用为”链接关系可能被恶意使用，以提供误导性URI供参考。使用这些链接可能会将用户代理指向攻击者的站点，破坏他们打算支持的引用记录，或者破坏引用数据的算法解释。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom Syndication Format", RFC 4287, DOI 10.17487/RFC4287, December 2005, <https://www.rfc-editor.org/info/rfc4287>.
[RFC4287]诺丁汉，M.，Ed.和R.Sayre，Ed.，“原子联合格式”，RFC 4287，DOI 10.17487/RFC4287，2005年12月<https://www.rfc-editor.org/info/rfc4287>.
[RFC5988] Nottingham, M., "Web Linking", RFC 5988, DOI 10.17487/RFC5988, October 2010, <https://www.rfc-editor.org/info/rfc5988>.
[RFC5988]诺丁汉，M.，“网络链接”，RFC 5988，DOI 10.17487/RFC5988，2010年10月<https://www.rfc-editor.org/info/rfc5988>.
[RFC6249] Bryan, A., McNab, N., Tsujikawa, T., Poeml, P., and H. Nordstrom, "Metalink/HTTP: Mirrors and Hashes", RFC 6249, DOI 10.17487/RFC6249, June 2011, <https://www.rfc-editor.org/info/rfc6249>.
[RFC6249]Bryan，A.，McNab，N.，Tsujikawa，T.，Poeml，P.，和H.Nordstrom，“Metalink/HTTP：镜像和哈希”，RFC 6249，DOI 10.17487/RFC62492011年6月<https://www.rfc-editor.org/info/rfc6249>.
[RFC6596] Ohye, M. and J. Kupke, "The Canonical Link Relation", RFC 6596, DOI 10.17487/RFC6596, April 2012, <https://www.rfc-editor.org/info/rfc6596>.
[RFC6596]Ohye，M.和J.Kupke，“规范链接关系”，RFC 6596，DOI 10.17487/RFC6596，2012年4月<https://www.rfc-editor.org/info/rfc6596>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC8288] Nottingham, M., "Web Linking", RFC 8288, DOI 10.17487/RFC8288, October 2017, <https://www.rfc-editor.org/info/rfc8288>.
[RFC8288]诺丁汉，M.，“网络链接”，RFC 8288，DOI 10.17487/RFC8288，2017年10月<https://www.rfc-editor.org/info/rfc8288>.
[W3C.REC-html52-20171214] Faulkner, S., Eicholz, A., Leithead, T., Danilo, A., and S. Moon, "HTML 5.2", World Wide Web Consortium Recommendation REC-html52-20171214, December 2017, <https://www.w3.org/TR/2017/REC-html52-20171214/>.
[W3C.REC-html52-20171214]福克纳，S.，艾霍尔茨，A.，莱塞德，T.，达尼洛，A.，和S.文，“HTML 5.2”，万维网联盟建议REC-html52-20171214，2017年12月<https://www.w3.org/TR/2017/REC-html52-20171214/>.
[ARK] Kunze, J. and R. Rodgers, "The ARK Identifier Scheme", Work in Progress, draft-kunze-ark-18, April 2013.
[ARK]Kunze，J.和R.Rodgers，“ARK标识符方案”，正在进行的工作，草稿-Kunze-ARK-18，2013年4月。
[bookmark-blog] Nelson, M. and H. Van de Sompel, "rel=bookmark also does not mean what you think it means", August 2017, <http://ws-dl.blogspot.com/2017/08/ 2017-08-26-relbookmark-also-does-not.html>.
[书签博客]Nelson，M.和H.Van de Sompel，“rel=bookmark也不是你认为它的意思”，2017年8月<http://ws-dl.blogspot.com/2017/08/ 2017-08-26-relbookmark-allow-does-not.html>。
[canonical-blog] Nelson, M. and H. Van de Sompel, "rel=canonical does not mean what you think it means", August 2017, <http://ws-dl.blogspot.nl/2017/08/ 2017-08-07-relcanonical-does-not-mean.html>.
[canonical博客]Nelson，M.和H.Van de Sompel，“rel=canonical并不代表你认为它的意思”，2017年8月<http://ws-dl.blogspot.nl/2017/08/ 2017-08-07-relcanonical-does-not-mean.html>。
[CoolURIs] Berners-Lee, T., "Cool URIs don't change", World Wide Web Consortium Style, 1998, <https://www.w3.org/Provider/Style/URI.html>.
[CoolURI]Berners Lee，T.，“酷的URI不会改变”，万维网联盟风格，1998年<https://www.w3.org/Provider/Style/URI.html>.
[DOI-URLs] Hendricks, G., "Display guidelines for Crossref DOIs", March 2017, <https://blog.crossref.org/display-guidelines/>.
[DOI URL]Hendricks，G.，“交叉参考DOI的显示指南”，2017年3月<https://blog.crossref.org/display-guidelines/>.
[DOIs] ISO, "Information and documentation - Digital object identifier system", ISO 26324:2012(en), 2012, <https://www.iso.org/obp/ui/ #iso:std:iso:26324:ed-1:v1:en>.
[DOIs]ISO，“信息和文档-数字对象标识符系统”，ISO 26324:2012（en），2012<https://www.iso.org/obp/ui/ #iso:std:iso:26324:ed-1:v1:en>。
[FOAF] Brickley, D. and L. Miller, "FOAF Vocabulary Specification 0.99", January 2014, <http://xmlns.com/foaf/spec/>.
[FOAF]Brickley，D.和L.Miller，“FOAF词汇规范0.99”，2014年1月<http://xmlns.com/foaf/spec/>.
[identifier-blog] Nelson, M. and H. Van de Sompel, "Linking to Persistent Identifiers with rel=identifier", November 2016, <http://ws-dl.blogspot.com/2016/11/ 2016-11-07-linking-to-persistent.html>.
[标识符博客]Nelson，M.和H.Van de Sompel，“使用rel=identifier链接到持久标识符”，2016年11月<http://ws-dl.blogspot.com/2016/11/ 2016-11-07-linking-to-persistent.html>。
[PIDs-must-be-used] Van de Sompel, H., Klein, M., and S. Jones, "Persistent URIs Must Be Used To Be Persistent", February 2016, <https://arxiv.org/abs/1602.09102>.
[必须使用PIDs]Van de Sompel，H.，Klein，M.和S.Jones，“必须使用持久URI才能持久”，2016年2月<https://arxiv.org/abs/1602.09102>.
[PURLs] Wikipedia, "Persistent uniform resource locator", September 2018, <https://en.wikipedia.org/w/index.php?titl e=Persistent_uniform_resource_locator&oldid=858558072>.
[PURLs]维基百科，“持久统一资源定位器”，2018年9月<https://en.wikipedia.org/w/index.php?titl e=持久性\u统一\u资源\u定位器&oldid=858558072>。
Acknowledgements
致谢
The authors would like to thank the following individuals for their comments and suggestions: Martin Klein, Harihar Shankar, Peter Williams, John Howard, Mark Nottingham, and Graham Klyne.
作者要感谢以下个人的评论和建议：马丁·克莱因、哈里哈尔·尚卡尔、彼得·威廉姆斯、约翰·霍华德、马克·诺丁汉和格雷厄姆·克莱恩。
Authors' Addresses
作者地址
Herbert Van de Sompel Data Archiving and Networked Services
Herbert Van de Sompel数据归档和网络服务
Email: herbert.van.de.sompel@dans.knaw.nl
URI: https://orcid.org/0000-0002-0715-6126
Email: herbert.van.de.sompel@dans.knaw.nl
URI: https://orcid.org/0000-0002-0715-6126
Michael Nelson Old Dominion University
迈克尔·纳尔逊旧自治领大学
Email: mln@cs.odu.edu
URI: http://www.cs.odu.edu/~mln/
Email: mln@cs.odu.edu
URI: http://www.cs.odu.edu/~mln/
Geoffrey Bilder Crossref
杰弗里·比尔德交叉参考
Email: gbilder@crossref.org
URI: https://www.crossref.org/authors/geoffrey-bilder/
Email: gbilder@crossref.org
URI: https://www.crossref.org/authors/geoffrey-bilder/
John Kunze California Digital Library
约翰·昆泽加利福尼亚数字图书馆
Email: jak@ucop.edu
URI: https://orcid.org/0000-0001-7604-8041
Email: jak@ucop.edu
URI: https://orcid.org/0000-0001-7604-8041
Simeon Warner Cornell University
西蒙沃纳康奈尔大学
Email: simeon.warner@cornell.edu
URI: https://orcid.org/0000-0002-7970-7855
Email: simeon.warner@cornell.edu
URI: https://orcid.org/0000-0002-7970-7855