| TOC |
|
内核元数据是一个小的规定性词汇表，旨在支持高度统一但最小的对象描述，以实现有序的集合管理。内核词汇表，基于都柏林核心的子集™ （DC）元数据元素集，旨在描述任何形式或类别的对象，但其范围仅限于少数基本问题，如谁、什么、何时、何地。电子资源引文（ERC）也是本文档中指定的一种对象描述，它使用内核和其他元数据元素来解决这四个问题。
内核元数据旨在通过支持创建简短但高度统一的对象描述来帮助有序的收集管理，这些对象描述可以在正常的收集维护和故障排除活动中高效地列出、调查和搜索。这些描述用作对象代理，便于自动排序和筛选操作，并且在无需专用显示软件的情况下也具有肉眼可读性。内核元数据的目标是平衡对表达能力、非常简单的机器处理和直接人工操作元数据记录的需求。
内核元数据基于都柏林核心™ （DC）元数据元素setRFC5013（Kunze，J.和T.Baker，“都柏林核心™ 元数据元素集，2007年8月），由都柏林核心™ 元数据倡议DCMI（都柏林核心™ 元数据倡议，“DCMI元数据术语”。内核元素是识别各种对象属性的描述符。原则上，它们适用于宇宙中的任何对象，无论是数字对象、物理对象还是抽象对象，遵循RFC3986的传统（Berners Lee，T.，Fielding，R.和L.Masinter，“统一资源标识符（URI）：通用语法”，2005年1月）。这种对象的极端多样性是通过一个假设来实现的，即高度可变和丰富的对象描述可以在四个基本要素（谁、什么、何时、何地）的水平上直接进行比较，这四个基本要素适用于一种行为表达对象。这个序列是内核中一个反复出现的主题。在对“如何”、“为什么”和“嗯”的未来扩展的预期中，我们将前四个元素称为“四个h”（它们的共同点是一个初始吸气的“h”音，也比“w”短）。
基于内核的描述使得比较一组极其多样化的对象成为可能。即使有许多其他元素与内核元素共存，或者当其他元素中的少量信息与内核元素信息重叠时，也可以进行比较。无论对象是否被烟熏、磨损、导航，或以任何其他方式与之交互，其基于内核的描述确保以容易隔离的内核元素的形式存在一些可预测的公共点。内核元素在广泛的对象描述范围内提供了可互操作(或至少是可比的)元素的简洁交集。
内核是元数据元素的词汇表，其中元素将标签与值配对。作为词汇表，内核提供但不强制使用其术语。内核指定了元数据元素以及元素中特定数据值的结构。这些规则可以由其他公约补充（例如AACR2（美国图书馆协会，“英美编目规则”，2007年），尽管这不是必需的。与大多数词汇表一样，元数据创建者对创建连贯和合理的描述负有最终责任。
本文介绍的电子资源引文（ERC）是一种对象描述，必须使用四个基本核心要素。标准编码方法，如RDF（W3C，“资源描述框架”）和XML（W3C，“可扩展标记语言（XML）1.0（第四版）”，2006年8月）可用于格式化ERC和内核元数据。还可以使用其他方法对内核元素值的修改形式进行编码，如MARC（国会图书馆，“机器可读编目”，2007年）或MODS（国会图书馆，“元数据对象描述模式”，2006年6月），尽管在这一过程中可能会丢失一些信息粒度。使用内核元数据ARERK的两个应用程序（Kunze，J.和R.Rodgers，“ARK持久标识符方案”，2007年7月）标识符和Namaste（名称为文本）标记SNAMASTE（Kunze，J.，“带有Namaste标记的目录描述”，2009年4月）。
与内核元素一起使用非内核元素的做法是正常的：内核元素可能与来自其他词汇表（如Dublin Core）的元数据出现在同一记录中™ 和PREMIS（OCLC和RLG，“PREMIS数据字典，版本1.0”，2005）。至少使用四个基本内核元素（四个h）的要求是在完整ERC记录的上下文中特别提出的，例如，
erc：谁：吉本，爱德华什么：罗马帝国的衰亡时间：1781年在哪里：http://www.ccel.org/g/gibbon/decline/
四个h提供了一组价格合理的可比较元素，这些元素与各种不同的元数据和对象类型通用，但不会限制记录的表达范围。
内核有一个“故事”的概念，这是一个组织原则，将谁、什么、何时、何地的问题应用于对象描述的不同方面。所需的四个核心元素处理一个特定方面——对象“讲述”的故事——这样做形成了类似于传统引文的东西：
- 谁“告诉”它（来自DC创建者、贡献者和发布者），
- 什么“讲述”被称为(来自DC标题)，
- 当它被“告知”(来自DC Date)，并且
- 哪里可以（从DC标识符）找到“告诉”。
（对于这个比喻来说，如果不与现有的书目术语相冲突的话，像“表达”这样的词比“讲述”更有效。）
一个描述性记录可能包含同一对象的不同形式的故事，例如，其数字和物理形式。根据物体的类型——物品、照片、舞蹈、化石——一个物体的“讲述”可能意味着完全不同的事情，比如它的出版、安装、表演或发现。一个描述性记录还可能包含几种不同类型的故事，例如对象是关于什么的（“关于”），记录本身的起源，托管组织对对象的支持，以及关于寄存者的信息。在首先描述锚定描述性记录的故事之后，将给出有关这些故事类型的更多信息。
在对象的描述性记录可能包含的所有故事中，有一个故事是内容寄存者（例如，贡献对象的人）被认为是有序管理馆藏中物品的最合适的基本参照物。有许多不同类型的储户，从托管机构雇用的获取物品的数字图书馆专家，到创建物品并希望保存这些物品的学科专家，再到机构雇用的管理人员监控由机构创建并保存在基于机构或学科的存储库中的对象。因此，对于最合适的基本参照物，会有许多不同的意见。
核心元数据主要是支持有序的收集整理，作为对象存放者和存储库管理员之间的伙伴关系。这并不意味着存放者或管理员（他们之间将进行大部分对象管理）在书目描述或收集主题领域受过任何培训ct引发系统异常或在面向储户的资产报告中显示不正确，内核元数据旨在允许任何一方形成足够清晰的思想图景，以便就此展开电话对话。
锚定故事是一个“非专业”描述，旨在支持此存款人-经理合作关系。如果没有其他元数据，锚定故事应该足够了。如果元数据更多、更丰富，则仍必须为那些缺乏专门人员资源重新编目或开发的存储库创建锚定故事“交叉行走”，将更丰富的元数据转换为锚定故事。这个锚定故事通过四个h的需求来表达，即存款人报告、系统日志、对象“墓碑”（对象被提取时留下的内容）以及对象在respository中的出生（到达）记录。锚定故事可以被认为是诞生石元数据。
存款人在选择其锚定故事方面有很大的自由度，但它应该首先作为一种对象摘要出现在记录中，这种对象摘要可以很容易地被人眼隔离（记录中任何地方出现的内核元素都可以很容易地被自动化过程隔离）。如果记录只包含一个故事，那么锚定故事就是它，并且记录只包含四个h。born digital文档的典型锚定故事是文档在网站上发布的故事，其中“where”元素根据当前存储库中对象的标识符进行调整（存放后）。
对于由创造性行为（书籍、雕像、照片等）产生的实物，四个h中的前三个应偏向于原始行为的故事，而“讲述”的位置“如果可能的话，应该是对象数字体验的机器可操作标识符。这提供了一个层描述，方便在线访问，同时避免了关于谁对对象进行了数字化、何时扫描等繁琐而无趣的细节。”。一个对象只有一个物理实例的状态是transisient；最有趣的物理对象通常离创建对象的某种数字体验只有几个周期的时间。如果有必要和负担得起，可以在记录的其他地方讲述衍生和原始对象的完整和纯粹的故事。
锚定故事不一定是ERC（或任何其他）记录的中心描述目标。例如，博物馆储户可以为一幅画的数字化照片创建ERC，但选择将其锚定在原画的故事中，而不是电子肖像的故事中；尽管ERC可能通过其他故事被证明与描述电子相似性密切相关，但存款人可能选择了这个特定的锚定故事，以便以最自然的方式让客户看到ERC（谁会在达芬奇的统治下找到蒙娜丽莎，比在拍照或扫描照片的人的名字下找到蒙娜丽莎更快呢）。在另一个例子中，为一部戏剧制作一个ERC作为抽象作品的寄存者的任务是描述一件无形的知识产权。为了将这个抽象的对象锚定在具体的世界中，如果只是通过衍生形式，提供者有必要选择一个合适的戏剧在线版本来告诉读者为ERC合唱故事。
本节包含当前定义的故事类型列表，以及正在开发的其他故事类型。如下所示，内核中使用类似命名的元素来处理对象内容的故事、其支持、元数据记录本身的来源等。完整（非存根）只需一个故事ERC，并且只有四个元素必须存在。
谁：负责人或一方（必需）什么：名称或其他面向人的标识符（必需）何时：对象生命周期中的重要日期（必需）何处：位置或面向系统的标识符（必需）如何：（正在构建）正式类型指标
另一个故事是对象的内容。
关于谁：信息内容中的人物或当事人关于什么：信息内容中的主题或主题关于何时：信息内容涵盖的时间段关于地点：信息内容涵盖的地点或地区关于如何：信息内容的描述
另一个故事是元数据记录本身的起源。
元谁：负责记录元的人或一方什么：记录元标识符的简短形式何时：记录元的最后修改日期何处：记录最完整形式的位置
另一个故事是对一个对象的支持承诺。
支持对象——谁:对支持对象负责的人或方——什么:对支持对象作出的承诺的简短形式——何时:承诺的最后修改日期——在哪里:承诺的最完整形式的位置
另一个故事是关于储户的。
存款人谁：负责存款的人或一方存款人什么：存款人在存款组织中的角色存款人何时：存款人在该角色中的任职日期存款人何处：唯一的机器可读存款人标识符
每个内核元素标签都有一个编码的同义词（下面的SYN列），由字母“h”和数字组成，如h1、h2、h3等。下表按“故事”组织，总结了内核元素和都柏林核心之间的大致对应关系™ 元素；本文档的词汇部分详细介绍了真实的对应关系和元素限制。
故事内核标签SYN都柏林核心近似erc:*谁h1创建者/贡献者/发布者*对象的h2标题*何时h3日期“讲述”.*何处h4标识符（永久）何处h5（保留类型限制**）关于erc：关于谁h11主题（人物）关于h13覆盖时对象的h12主题的故事（时间）内容。关于h14覆盖范围（空间）关于h15描述如何支持erc：支持谁h21（无等效物）支持什么h22（无等效物）的故事当h23（无等效物）支持时对象的支持。支持何处h24（无等效物）元erc:meta who h31（无等效物）meta who h32（无等效物）的故事此记录的元当h33（无等价物）“告诉”。元当h34（无等价物）元存款人：存款人谁h41（无等价物）存款人的故事什么h42（无等价物）对象的存款人当h43（无等价物）存款人。存款人哪里h44（无等价物）*完整的ERC需要此元素的非缺失值。**正在开发中。
内核元素映射到都柏林核心的位置™ （DC）元素，地图大致是一对一的，但有几个显著的例外。
内核元数据目前与Dublin Core™元数据保持基本的互操作性。在正式的术语中，它符合“Level 1”互操作性DCMI - IL(都柏林核心™元数据计划，“都柏林核心™元数据互操作性级别”，2008年11月)。正在寻求更高级别的互操作性，例如Kernel元数据到RDF的“Level 2”映射，并可能在后续规范中建立。
此表说明了内核中的故事概念与ERC之间的紧密联系。虽然内核是一个词汇表，但ERC带来了关于所需元素的假设。不包含所有四个h的ERC仍然是一个有用的容器，就像在构造描述时一样，但它被分类为“存根ERC”。对于存根，例如，
erc:什么:数字困境哪里:http://books.nap.edu/html/digital%5Fdilemma
“erc:”标签表明内核词汇表元素是预期的，随后的检查表明该erc是不完整的。
任何故事的缩写形式都可以使用故事标签作为元素标签给出，然后通过列出每个故事元素的值来构造一个长值，顺序如上图所示，用solidus（“|”）分隔.由于该复合值会去掉组成值标签，因此必须严格遵守顺序，以便准确识别相应的元素。第2节示例的缩写形式为：
erc:吉本，爱德华|罗马帝国的衰亡| 1781 | http://www.ccel.org/g/gibbon/decline/
出现时没有值的故事标签在视觉上勾勒出记录的某个区域时可能很有用，但在其他方面没有意义。一个例外是“erc”标签（有或没有伴随值）充当一种记录标签，将对象描述声明为erc。
任何故事标签都可以引入简短的故事形式，例如，
元erc:NLM | pm9546494 | 19980418 |http://ark.nlm.nih.gov/12025/pm9546494?? 关于erc：|双谱；非线性；癫痫；协作性；硬膜下；海马
对于这些故事标签的缺失值没有一般要求（与“erc”标签不同）。复合内核元素通常使用子元素顺序来构造，子元素顺序与熟悉的who、what、where模式相呼应。
内核的未来版本可能会用两个额外的但非必需的元素来扩展这四个h:如何和为什么。这些元素名是保留的，但正在构造中。
表示ERC的一种方法是使用ANVL（一种名称-值语言），这是一种简单的基于文本的记录语法，传统的互联网协议如RFC2822（Resnick，P.，“互联网消息格式”，2001年4月）。以下是ERC作为ANVL记录的示例：
erc:who:Lederberg，Joshua what:人类家族遗传连锁研究时间：1974年，地点：http://profiles.nlm.nih.gov/BB/AA/TT/tt.pdf 注：这是一个小的描述性记录内的任意注释。
使ANVL记录成为完整的ERC记录的是“ERC:”标签和四个必需元素的存在。
只要遵循元素标签和值的核心规则，就可以用许多不同的编码（例如，具有特定模式的XML）表示ERC。内核规则与ANVL标签和值的规则一致。由于ANVL简洁易读，我们将在本文档的示例中继续使用它。
作为ANVL记录，ERC是一系列元素，以“ERC:”开头，以空行结尾（一行中有两个换行符）。虽然ERC在其他编码中看起来不同，但在ANVL中，
因此，一个值可以跨多行折叠。跨几行折叠的元素值被视为在一条长线上连在一起;因此，上面的“note”元素被认为与
注：这是一个小的描述性记录内的任意注释。
这就是本文档关于ANVL的全部内容，ANVL规范ANVL（Kunze，J.和Kahle，B.，“名称-值语言”，2005年2月）中详细介绍了ANVL的完整描述。
独立于ANVL或任何其他编码，任何具体语法中都有编码ERC的规则。在内核元素标签和值中，这些规则恰好与ANVL元素规则一致。保存内核元素的任何格式的基本特征是：
除这些要素规则外，只有当“谁”、“什么”、“何时”和“何地”这四个要素均不存在缺失值时，ERC才被视为完整的；这四个h分别具有编码的同义词h1、h2、h3和h4。如果尽最大努力提供一个值失败，则必须在其位置上提供一个标准值（如下所示），指明缺失值的原因。
如前所述，内核只是一个词汇表，ERC对所需元素进行假设。四个h可以使用缩写形式ERC提供隐式标签。在这种情况下，必须严格遵守元素顺序，如
erc: Lederberg, Joshua |人类家族遗传连锁研究| 1974 http://profiles.nlm.nih.gov/BB/AA/TT/tt.pdf注释:这是一个小描述性记录内的任意注释。
没有全部四个h的记录被视为“存根ERC”。存根对于保存正在施工中或需要自动完成过程的记录可能特别有用。
虽然ERC是一个用于交换资源描述的通用容器，但它并不规定数据提供者或接收者必须如何对记录进行内部存储、布局或组装。任意的内部描述框架可以通过映射（如按需）来支持ERC本地记录保存到ERC容器中并可供导出。因此，为了支持ERC，数据提供程序无需将内部数据转换为ERC格式。
本文档的其余部分涉及独立于ERC的内核元数据。尽管如此，将继续使用ANVL/ERC格式给出示例。
内核元素标签是以字母开头的字符串，该字母可以包含字母、数字、连字符和下划线（“\ux”）的任意组合。保留句点（“.”）以将名称空间指定与标签分开，否则必须编码为“%pd”。因此，元素标签与XML规则（W3C，“可扩展标记语言（XML）1.0（第四版）”，2006年8月）名称相当一致。
与XML的一个不一致之处是，内核标签可能用空格输入。在这种情况下，所有空间序列都被视为等效于单个空间，然后该空间（用于匹配和导出为XML）被视为等效于下划线。在处理标签之前，任何初始和最终空间都会被剥离。
为了便于比较，元素标签也被认为不区分大小写;换句话说，标签的输入和显示可能会有大小写差异，但当将空格和大写规范化为下划线和小写时，在幕后就不可能发生冲突。例如，这些规则防止任何版本的内核将它们作为两个不同的元素，
marc_856马克856年
出于显示目的，元素标签视为区分大小写；换句话说，在显示时应保留大写和小写的区别。
元素标签也可能伴随着其编码的同义词。在ANVL中，同义词紧跟在标签后面并用括号括起来（例如，在XML中，同义词可能是XML属性）。事实上，如果存在官方编码的同义词，则标签本身可以用任何UTF-8 RFC3629（Yergeau，F.）。，“UTF-8，ISO 10646的转换格式”，2003年11月。）表格（例如，本地翻译），方便记录的本地观众，如，
erc:wer（h1）：米勒，爱丽丝（h2）：我是安防战争二子洪（h3）：1983年我（h4）：http://www.amazon.com/exec/obidos/ASIN%{/0374522693/thenaturalchildp%}Titel（h501）：（英）为了你自己的利益：养育子女中隐藏的残忍和暴力的根源
在本例中，标签是针对本地受众的，编码的同义词允许软件进行明确的解释，该软件可以显示为其他受众翻译的标签。
元数据标准原则上可以指导记录的创建，这些记录在按标题、日期和作者等进行排序时会产生合理的顺序，但是，有些标准在这方面没有规定（例如，都柏林核心数据库）™ RFC5013（Kunze，J.和T.Baker，“都柏林核心区™ 元数据元素集（2007年8月）。此外，当接收到的元数据来自各种各样的源和域时，如在“语义web”应用程序中，不兼容的创建实践使得很难生成完全可理解的顺序。
对于内核元数据，需要考虑一组值（例如，在一组记录中找到的作者姓名）sort-friendly如果一个简单的词法排序会导致对用户有意义的排序。虽然这个定义为创作实践中的主观性和可变性留下了空间，但它要求每个本地实践中的一致性。更重要的是，如果没有领域或源知识的好处，任何使用最简单工具的接收者都有可能实现sort这些值是合理的，即使它们来源于其他非常不同的实践。例如，通过任何一种元素形式进行简单的词汇排序，
谁：汗，哈希姆什么：认真的重要性，时间：19580924
将通过“最重要的单词”或按时间顺序创建字母顺序。这一易于理解的结果表明，由每种形式表示的值集都是排序友好的。相比之下，通过这些表格中的任何一种进行简单排序，
谁：哈希姆·汗什么：认真的重要性何时：1958年9月24日
将创建按给定名称、第一个标题词（是否重要）按字母顺序排列的订单，或月名。对于一些特殊应用程序，这可能是预期效果，但在大多数情况下，这将是不利于排序的值的标志。在西方语言中，排序友好值和自然语序之间存在紧张关系，下一节将讨论这一点。
假设内核元数据的创建者已经尽了最大努力以友好的方式包括日期、标题、名称和其他值。这并不能解决创建完全可排序的、跨域记录的困难的一般问题，但它是实用的第一步。排序友好的值对于内核和非内核元数据同样有用。
有时，创建排序友好的价值观的愿望会与自然的词序发生冲突，就像西式的人名和语法冠词一样，不太重要的词放在更重要的词之前(从排序优先级中窃取)。为了减轻这种冲突，值可以选择以“，”(逗号)结尾，指示如何恢复自然的词序。它的工作原理大致如下:如果值中存在其他非结尾逗号，它们将标记倒序点，软件(或人眼)可以使用这些倒序点来重新排列值中的单词。例如,
世界卫生组织：梵高，文森特，世界卫生组织：豪厄尔，三世，博士，1922-1987年，瑟斯顿，世界卫生组织：Acme火箭工厂有限公司，世界卫生组织：胡锦涛，
可以通过将由内部逗号隔开的值的最后一个非空部分放在开头来恢复自然的词序。注意，如果根本没有逗号或只有一个逗号，则没有指示倒装点。
如果需要两个倒装点，则在一行中用两个逗号结束该值。这在有三个级别的单词意义时会有所帮助，就像西方的敬语一样。两个倒装点的位置使倒装点的第二到最后一部分用作第二排序键，最后一部分用作第三排序键。要恢复自然的词序用逗号括起来的值的倒数第二个非空部分放在开头，前面是最后一个非空部分。例如，在这些情况下，
世卫组织：麦卡特尼，帕特，女士，世卫组织：麦卡特尼，保罗，先生，世卫组织：麦卡特尼，佩特拉，博士，什么：美国政府卫生和公共服务部，，
恢复自然语序的方法是：首先去掉最后一个用逗号括起来的非空部分，应用以前的规则（将现在的最后一个非空部分移到开头），然后将以前的最后一个部分加回到开头。上述两组示例中的值具有以下自然语序。
Vincent van Gogh Thurston Howell，III，博士，1922-1987 Acme火箭工厂有限公司胡锦涛帕特·麦卡特尼女士保罗·麦卡特尼爵士佩特拉·麦卡特尼博士美国政府卫生和公共服务部
如前所述，此功能可用于以姓氏命名顺序表示西式人名。上面的最后一行显示，它也可以用于自然语序可能会使用朴素排序软件产生意外结果的任何地方，例如当数据包含标题或公司名称时。
虽然内核元数据创建者应该尽最大努力生成与其他记录中的相同元素相比排序友好的值，但如果不这样做，则不必停止元数据的生成。为元素提供值比抑制值更有用，因为不确定该元素是否能很好地排序.
由于需要排序友好性，通常内核值由自由文本组成。异常由结构化标记触发，这些标记可能出现在值内的任何位置，也可能仅出现在值的开头。
可能出现在值中任何位置的标记：
- ";“因为重复值和
- “为了子值
仅出现在值开头的标记：
- “（：…）”用于特殊用途价值指标或
- 其中一个字符”；“，”或“，”稍后解释。
下面将解释这些结构标记。
分号(";")用于分隔重复的"peer"值，这些值可以等价地表示为多个元素，每个单独的值都有重复的标签;用程序员的术语来说，“;”是一种大堆元素分隔符。例如,
世卫组织：史密斯，J；王，D；汗，H
是更短的表示方式吗
谁：史密斯，J谁：王，D谁：汗，H
solidus（“|”）用于分离对总值具有不同类型“非对等”贡献的组件子值；这支持具有子结构的图元。例如
in:EEG临床神经生理学| v103，i6，p661-678 | 19971200
如果一起使用，“；”会比“|”更紧密地保存其邻居（具有更高的分组优先级）。例如，在这个“erc”元素中
erc:Smith，J；黄,D,；汗，H |鸡尾酒餐巾图| 2 | 1969 |（：unv）在19690401年泄漏期间被销毁
有四个子元素，第一个子元素有三个重复值。
其优先级甚至高于“；”is”（=）”，后者用于分隔一个特定值的替代版本。例如，在
世界卫生组织：法国国家图书馆；法国国会图书馆
两个重复值中的第一个包含了一个机构名称，先是法语，然后是英语，最后是首字母缩写。在第二个重复值中是两个交替值。
内核值通常以自由文本开始，但当值的第一个字符以单个操作字符“;”、“|”或“，”开始时就会出现例外。当在值的开头识别出一个字符时，将采取适当的操作，删除该字符，并继续对其余字符进行处理，直到看到不属于这三个字符之一的字符为止。例如，一旦SPACE字符或"(:…)“结构(一个特殊的值指示器)已经被识别，没有进一步的初始单个字符处理发生。
当一个值或子值以“；”开头时，它会“引用”任何内部出现的“；”，换句话说，它会关闭“；”将一个值或子值划分为重复值的特殊功能。当一个值以“|”开头时，它会“引用”任何内部出现的“|”，换句话说，它会关闭“；”的特殊功能|将一个值分成子值。类似地，当一个值或子值以“，”开头时，它会关闭结尾处“，”的特殊功能，以指示字序反转点，如前所述。
以“(:…)”开头的值表示一种标准化(受控)值代码，通常短而精确，被设计为软件可读。这样的价值代码通常只构成价值的一部分。一个值的开头可能出现多个值代码。
特殊值代码有不同的用途。代码可以指示单个特定值，剩余值文本提供人类可读的等价物；例如
谁：（：unkn）匿名
告诉软件元素值是官方未知的，而另一个文本则告诉可能需要作者姓名的英语读者同样的事情。代码还可以指示该值位于剩余文本（应该是一个可操作的标识符，如URL）给定的位置，并且在其他情况下不存在；例如
who:Wong，D who:（：at）http://example.org/abc/def/ghi.txt 权利：（：at）http://example.com/rights/123.html
可用于表示第一作者、单独文件中列出的65名合著者以及公司网站上发布的版权声明。
这里总结了一些特殊的值码。除后四个外，其余都表示不同类型的“缺失值”:
- （：unac）暂时无法访问
- 不允许的，故意压制的
- （：unap）不适用，没有意义
- (:unas)未分配的值(例如，Untitled)
- (:unav)值不可用，可能未知
- （：unkn）已知未知（例如，匿名、不知名）
- （：none）从未有过价值，也永远不会有
- （：null）显式且有意义地为空
- （：tba）待分配或稍后公布
- （等）数不胜数。
- （：at）实际值位于给定的URL或标识符处。
通常重复出现的值类型是日期，它可以后跟时间。TEMPER (Blair, C.和J. Kunze，“时态枚举范围，”2007年8月)格式比w3cdtf (Wolf, M.和C. Wicksteed，“日期和时间格式(ISO8601的W3C概要文件)，”.)格式更受欢迎，w3cdtf格式在表示范围、列表、近似和BC日期方面有限制。内核日期可以采取下列形式之一:
1999（四位数年份）20001229（年、月、日）20001229235955（年、月、日、时、分、秒）
保留连字符和逗号以创建日期范围和列表，例如，
1996-2000（四年范围）1952、1957、1969（三年清单）1952、1958-1967、1985（日期和范围的混合清单）20001229-20001231（三天范围）
近似日期和BCE日期也可以表示为，
1850年（大约1850年）公元前1212年（拉美西斯大帝之死）公元前551年（孔子诞生）
注意，公元前5世纪的日期本质上是反向排序的。但是因为“BCE”首先出现在TEMPER值中，所以简单的排序软件首先将所有BCE日期放在一起作为一个组，然后通过简单干预逆转组的顺序就可以实现正确的时间顺序。
需要出现在元素值中的某些字符可能与用于构造值的特殊字符冲突，因此需要有一种方法将它们作为文字字符包含，以防止特殊解释。这是通过一种类似于URI处理程序所熟悉的编码机制来实现的。
值编码机制也使用' %'，但它不接受后面的两个十六进制数字，而是接受两个不能被误认为十六进制数字的字母字符或一个非字母数字字符。它的设计不会与正常的web样式的%-编码相混淆。特别是，可以在不冒正常%-编码数据被意外解码(这会导致错误)的风险的情况下对其进行解码。下面是扩展的内核编码扩展，中间的列给出了等价的和通常的十六进制编码。
代码十六进制用途-----------------------------------------------------------------%sp%20解码到空间%ex%21解码到！%dq%22解码到“%ns%23解码到#%do%24解码到$%pe%25解码到%%am%26解码到&%sq%27解码到“%op%28解码到（%cp%29解码到）%as%2a解码到*%pl%2b解码到+%co%2c解码到，%pd%2e解码到。%sl%2f解码到/%cn%3a解码到：%sc%3b解码到；%lt%3c解码到<%eq%3d解码到=%gt%3e解码到>%qu%3f解码到？%at%40解码到@%ox%5b解码到%ls%5c解码到\%cx%5d解码到%vb%7c解码到\%nu%00解码到null%%%25将用作语法填隙的非字符解码为%%\n/a%{n/a开始扩展块的非字符%}n/a结束扩展块的非字符
元素值中一个特别有用的构造是一对表示“扩展”块的特殊编码标记（“%{”和“%}”）。它们包含的任何字符串都将被视为没有包含的空格（空格、制表符、换行符）这对于以可读的方式编写长的、由多部分组成的URL非常方便。例如，中的值
哪里：http://foo.bar.org/node%{？db=foo&start=1&end=5&buf=2&query=foo+bar+zaf%}
被解码为等效元素，但具有正确且完整的URL：
哪里：http://foo.bar.org/node?db=foo&start=1&end=5&buf=2&query=foo+bar+zaf
http://dot.ucop.edu/specs/erc-old-02-diffs.html
此词汇表包含内核元素、值和概念的混合体。在下面的定义中，“资源”一词与“对象”同义“。每个词汇表元素标签都有一个简短的编码同义词，由字母“h”和数字组成，如h1、h2、h3等。每个词汇表元素还有一个长的全局唯一标识符，该标识符是由http://n2t.info/ark:/99152/后跟短同义词；例如，
关于何时（h13）-->http://n2t.info/ark:/99152/h13
在一些冗余的代价，它还包括基本的15都柏林核心™ （DC）元素定义，因为（a）DC元素可以在ERC记录中使用，而无需名称空间限定；（b）内核为它们分配编码同义词（h501-h515）。
- 关于erc（h10）：
- 一种复合元素，按四个h结构，用于描述对象的内容。如果没有值，它是一个标签，用于在记录中直观地设置区域。
- 关于什么（h12）：
- 资源的主题。DC映射：主题
- 关于何时（h13）：
- 资源的时态主题。DC映射：覆盖范围（时间）
- 关于何处（h14）：
- 资源的空间主题。DC映射：覆盖率（空间）
- 关于世卫组织（h11）：
- 作为资源主题的人物的名称。
- 关于如何（h15）：
- 对资源的描述。DC映射：描述
- 投稿人（h506）：
- 负责对资源作出贡献的实体。贡献者的示例包括个人、组织或服务。通常，贡献者的名称应用于表示该实体。
- 覆盖范围（h514）：
- 资源的空间或时间主题、资源的空间适用性或资源相关的管辖权。空间主题和空间适用性可以是一个命名的地方或由其地理坐标指定的位置。时态主题可以是命名的时段、日期或日期范围。管辖区可以是指定的行政实体或资源适用的地理位置。推荐的最佳实践是使用受控词汇表，如地名词典TGN。在适当的情况下，可以优先使用命名的地点或时间段，而不是数字标识符，例如坐标集或日期范围。
- 创造者（h502）：
- 主要负责制作资源的实体。创建者的示例包括个人、组织或服务。通常，创建者的名称应用于表示该实体。
- 日期（h507）：
- 资源生命周期中与事件关联的时间点或时间段。日期可用于表示任何粒度级别的时间信息。推荐的最佳实践是使用编码方案，如ISO 8601 W3CDTF的W3CDTF配置文件。
- 存款人erc（h40）：
- 一种复合元素，按四个h结构，用于描述对象的存放者。
- 存款人（h41）：
- 负责押金的人或一方的姓名。
- 存款人什么（h42）：
- 存款人在存款组织中的角色。
- 存款人（h43）：
- 存款人在存款机构中担任存款人的任期日期。
- 存款人（h44）：
- 存款人的唯一机器可读标识符。
- 说明（h504）：
- 对资源的描述。描述可能包括但不限于：资源的摘要、目录、图形表示或自由文本说明。
- ERC
- 电子资源引用，一个对象描述，至少使用基本的内核元素，谁，什么，何时，在哪里处理对象的“讲述”。
- erc（h9）：
- 一种复合元素，按四个h结构，描述资源的“说明”。如果没有值，它是一个标签，声明记录为ERC，它的完整实例要求四个h中的每一个都不缺少值。
- （：etal）
- 一个空元素术语，解释该值是太多而无法列出的其他值的替代项（等等）。
- 格式(h509):
- 资源的文件格式、物理介质或维度。维度的示例包括大小和持续时间。推荐的最佳实践是使用受控词汇表，如Internet媒体类型列表。
- 四个h
- 四个基本内核元素——谁、什么、何时、何地——通常用于构造复合内核元素“表示表示该特定序列的子元素序列；对于缺少显式标签的缩写表单元素，这是一个重要的记忆辅助工具。这些标签的文字形式本身就说明了“讲述”一个对象的故事，在这种形式下，它们是每个完整的ERC所必需的。内核的未来版本可能会使用非必需元素“how”、“why”和“huh”扩展四个h的顺序。
- 识别码（h510）：
- 在给定上下文中对资源的明确引用。推荐的最佳实践是通过符合正式识别系统的字符串来识别资源。
- 在（h602）中：
- （正在构造中）为引用所述对象出现在其中的系列出版物的复合元素保留。该元素的结构松散地类似于四个h，表示序列名、卷/期/页、日期和期URL。DC映射：关系
- 如何(h5):
- (正在构建中)为表示对象的编码值保留。
- 嗯(h7):
- （正在构造中）保留以指示元数据记录的字符集编码和语言。
- 语言（h512）：
- 资源的一种语言。建议的最佳实践是使用受控词汇表，如RFC 4646 RFC4646。
- 元数据
- 结构化数据，通常描述给定对象或资源，或与给定对象或资源相关。结构化数据至少有明显的起点和终点，并且可能有明显的标签。
- 元erc（h30）：
- 一种复合元素，根据四个h构成，用于描述此（包含）记录的“说明”。如果没有值，它是一个标签，用于在记录中直观地设置区域。
- 元什么（h32）：
- 记录标识符的简短形式。
- meta-when (h33):
- 记录的最后修改或审核日期。
- 其中（h34）：
- 记录最完整形式的位置。
- meta who（h31）：
- 负责记录的人或当事人。
- （：无）
- 一个空元素术语，解释元素从来没有值，也永远不会有值。这是一种更强的形式：unas。
- 备注(h601):
- 关于记录的自由文本注释。
- （：null）
- 解释值显式为空的空元素术语，其中空值在使用该元素的上下文中具有明确定义的含义（不一定明显）。
- 对象
- 可以应用元数据的任何内容。同义词：“资源”
- 出版商（h505）：
- 负责使资源可用的实体。发布者的示例包括个人、组织或服务。通常，发布者的名称应用于表示该实体。
- 资源
- 可以应用元数据的任何对象。同义词：“对象”
- 关系(h513):
- 相关资源。推荐的最佳实践是通过符合正式识别系统的字符串来识别相关资源。
- 权利(h515):
- 有关在资源中或在资源上拥有的权利的信息。通常，权利信息包括与资源相关的各种产权的声明，包括知识产权。
- 来源（h511）：
- 从中派生所述资源的相关资源。所述资源可以全部或部分地来自相关资源。推荐的最佳实践是通过符合正式识别系统的字符串来识别相关资源。
- 受试者（h503）：
- 资源的主题。通常，主题将使用关键字、关键短语或分类代码来表示。推荐的最佳实践是使用受控词汇表。要描述资源的空间或时间主题，请使用Coverage元素。
- 支持erc（h20）：
- 一种复合元素，按四个h结构，描述提供者对对象的支持承诺。没有值，它是一个标签，用于在记录中直观地设置区域。
- 支持什么（h22）：
- 对对象作出承诺的缩写形式。
- 支持（h23）：
- 对目标作出的承诺的最后修改或审查日期。
- 支持（h24）：
- 对该对象作出承诺的最完整形式的位置。
- 支持世卫组织（h21）：
- 对物品负责的人或当事人，如保存或存取服务的提供者。
- 存根伦理委员会
- 不完整的ERC记录。如果不完整，则四个h（元素谁、什么、何时、何地）中的一个或多个缺失或缺失值就足够了。
- （：待定）
- 一个空元素术语，解释值将在以后分配或宣布。
- 标题（h501）：
- 给资源的名称。
- 类型（h508）：
- 资源的性质或类型。推荐的最佳实践是使用受控词汇表，例如DCMI类型词汇表DCTYPE。要描述文件格式、物理介质或资源的维度，请使用format元素。
- （：unac）
- 解释该值暂时不可访问的空元素术语。例如，这可能是由于系统中断造成的。
- （：unal）
- 一个空元素术语，解释该值是不允许的或被有意抑制的。
- （：unap）
- 一个空元素术语，解释没有值是适用的或没有意义。
- (una):
- 解释从未赋值的空元素术语。无标题的绘画就是一个例子。
- （：联安核查团）
- 一个空元素术语，解释该值因某种原因不可用。与：unkn相比，该术语对值的不存在没有特别的信心。它可能起源于尚未进行彻底调查的收集，也可能出现在重新包装收到的缺少元素的记录的中间系统中。
- (: unkn)
- 表示未知值的空元素项。与:unav相比，这个术语表达了更大的信心和权威，即任何人都不知道所描述的对象的适当价值。一个例子是关于作者身份的“匿名”专家评估。
- 什么（h2）：
- 资源的一个面向人的名称，或资源的“说明”的名称。与“where”元素（也是一种名称）相比，“what”元素更适合人类使用。DC映射：Title
- 何时（h3）：
- 资源生命周期中与事件相关联的时间点或时间段，通常在事件被表达、创建或可用时。DC映射：日期
- 其中（h4）：
- 为资源指定的面向访问的名称，或表示此资源的位置。是通过符合正式标识系统的字符串或数字来标识资源。与“what”元素（也是一种名称）相比，“where”元素更适合自动访问。DC映射：标识符
- 世卫组织（h1）：
- 负责表示对象的实体，如创建对象或使对象可用。“谁”的例子包括个人、组织或服务。DC映射：创建者，但如果没有创建者使用Publisher，则使用Contributor
- 为什么(编辑):
- （正在建设中）保留用于元数据记录中必须出现的所需法律语言，包括版权和免责声明。
| AACR2 | 美国图书馆协会，"英美编目条例," 2007 (HTML). |
| ANVL | Kunze, J.和Kahle, B.名值语言，“2005年2月(PDF). |
| 方舟 | Kunze，J.和R.Rodgers，“ARK持久标识符方案，“2007年7月(PDF). |
| DCMI | Dublin Core™元数据计划，”DCMI元数据术语" (HTML). |
| DCMI-IL | Dublin Core™元数据计划，”都柏林核心的互操作性级别™ 元数据，“2008年11月(HTML). |
| 马克 | 国会图书馆，"机读编目," 2007 (HTML). |
| 插件 | 国会图书馆，"元数据对象描述模式，" 2006年6月(HTML). |
| 纳马斯特 | Kunze，J.，”带有Namaste标记的目录说明，“2009年4月(HTML). |
| 普莱米斯 | OCLC和RLG，”PREMIS数据字典，1.0版2005年,“(PDF). |
| RDF | W3C。”资源描述框架" (HTML). |
| 脾气 | Blair，C.和J.Kunze，“颞列举范围，”2007年8月(PDF). |
| W3CDTF | Wolf，M.和C.Wicksteed，“日期和时间格式（ISO8601的W3C概要文件）" (HTML). |
| XML | W3C。”可扩展标记语言（XML）1.0（第四版），“2006年8月(HTML). |
| RFC5013 | Kunze, J.和T. Baker， "都柏林核心™ 元数据元素集，“RFC 5013，2007年8月(文本). |
| RFC2822 | 雷斯尼克，P.“互联网信息格式，”rfc2822，二零零一年四月(文本). |
| RFC3629 | 叶尔乔，F.，”UTF-8是iso10646国际编码标准的转换格式，STD 63，RFC 36292003年11月(文本). |
| RFC3986 | 伯纳斯·李，T。,菲尔丁，R。,马辛特, "统一资源标识符（URI）：通用语法，“STD 66，RFC 3986，2005年1月(文本,HTML,XML). |
| John a . Kunze | |
| 加利福尼亚数字图书馆 | |
| 第20街415号，4楼 | |
| 94612年奥克兰 | |
| 我们 | |
| 电邮： | (电子邮件保护) |
| 阿德里安·特纳 | |
| 加利福尼亚数字图书馆 | |
| 第20街415号，4楼 | |
| 94612年奥克兰 | |
| 我们 | |
| 电邮： | (电子邮件保护) |