标识符互操作性

数字网络中感兴趣的资源来源广泛，可能携带来自不同既定公共方案、官方标准、事实方案或私人编目编号的标识符，信息的重用和交换是为了让用户能够跨不同的应用程序重用这些标识符（及其相关数据）。标识符的这种互操作性不仅包括互操作性的技术方面，还包括对标识符使用目的和社区的考虑。

互操作性

互操作性是指独立系统交换有意义的信息并相互发起行动的能力，以便共同运作，实现互利。特别是，它设想了松散耦合的独立系统能够协作和通信的能力。标识符是词汇标记，表示参与这些系统的事物；referent是由标识符标识的事物。

一个资源可以是多个域的一部分，并且可以由不同的系统标识，因此有必要确保不同标识系统之间以及基于相同名称空间的实现之间的互操作性。标识符互操作性对于以下目的是必要的：

元数据互操作性（因为元数据是有人声称存在于两个引用之间的关系）；
创建标准机制，用于表达不同标准标识符的引用之间的关系；
创建多个系统通用的服务，例如发现“相关内容”项；编译多媒体对象等。

在一个上下文中指定的标识符可能会在另一个地点或时间遇到，也可能会在未咨询指定者的情况下重新使用。即使假定一个资源只属于一个域，但一旦可以识别，它就可以在另一个域中独立使用（并且可能有未公开的修改）。对于互操作性至关重要的是，其他遇到和使用标识符的人可能不知道分配标识符时的上下文和假设。例如，一个系统可能理所当然地认为其范围是抽象的工作实体；另一个可能只假设抽象作品的具体实现。如果独立系统彼此已知，他们可以同意提供关于这些假设的支持信息；但如果它们彼此不了解，则必须通过其他措施确保互操作性。

可以区分三种互操作性：

语法互操作性。系统处理语法字符串并将其识别为标识符（并启动操作）的能力，即使系统中出现多个此类语法。
语义互操作性。系统判断两个标识符是否表示完全相同的参照物的能力；如果不是，那么这两个指称是如何关联的。
社区互操作性。系统使用标识符进行协作和通信的能力，同时尊重与系统中标识符相关的数据使用的任何权利和限制。

这三个依赖于形式的层：只有确保语义互操作性，才能实现社区互操作性；语义互操作性只有在语法互操作性得到保证的情况下才可能实现。

语法互操作性

如果两个系统在处理标识符字符串时遵循相同的技术规范，则可以确保语法互操作性，其中可能遇到的标识符的范围是可以合理预测的。在某些情况下，可能存在将一个方案的标识符直接合并到另一个方案语法中的规则。

然而，互操作性可能范围很广，因此很难预测可能的范围：标识符可能会出现在网络标识符之外，例如网络电信和广播方案，以及其他全球唯一标识符，例如最初不是为数字用途设计的国际标准书号（ISBN）。如果标识符要用于不仅仅是一个简单的目录列表（例如，在都柏林核心方案字段“资源标识符”中），则必须定义或发现注册表方案和假设，如协议依赖性，DC元素语法：DC。标识符。不存在所有标识符的单一注册表。网络环境中的许多（但不是所有）感兴趣的标识符可以注册为URI方案，但有些方案可能是私有的，或者其可用性受到限制。类似于DNS域的唯一注册表命名空间是URN规范的一部分（尽管尚未广泛实现）。由于需要将公共名称空间指定为URI（作为纯标识符：即识别、而不是检索、去引用、定位等），信息URI方案是在图书馆和发布社区中开发的（特别是与OpenURL标准的开发一起）。其目的是定义URI以引用在公共名称空间中具有标识符但在URI分配中没有表示的信息资产，例如LCCN。

有些标识符纯粹是抽象的“表示”令牌（名称）；另一些则体现了对标识符的使用的假设，例如检索、去引用、定位等的解析。这些假设可能很深；例如，在URI规范中，假设URI将被解析，解析URI的网络路径隐式基于DNS：没有真正的规定来包含非基于DNS的系统。如果标识符显式包含或隐式假设特定协议，则可能需要提供代理机制（将一个协议转换为另一个协议）以确保语法互操作性。

语义互操作性

语义互操作性处理一个明显但困难的问题：即使两个标识符字符串可以在语法上一起处理，系统如何知道来自另一个系统的术语的含义？如果A说“所有者”，B说“所有者“，他们指的是同一件事吗？如果A说“发布”，B说“传播”，这两个词的意思不同吗？为了对实体进行有效的互操作管理：

唯一标识符必须与引用实体的描述相关联，使用一组结构化的元素来提供有关该实体的信息（即，标识符必须与某些结构化元数据相关联，以实现互操作）；和
明确决定一个术语是否与另一个术语含义相同的唯一方法是共享一个参考框架，而不管它的名称是什么。结构化本体论（一种明确的形式规范，说明如何表示假定存在于某个感兴趣区域的实体以及它们之间的关系），其底层模型允许生成一致的新关系，以及记录其条款包含在协议中的各方之间的协议的方法。

允许在共享参考框架中进行此类比较的两个主要本体倡议是CIDOC概念参考模型和源自基于<in_d_ecs>的语义互操作性项目（如ONIX）的应用程序系列。这两者以及图书馆界的FRBR模型有很多共同点。词汇映射框架建立在允许所有这些模型共存的本体方法之上，通过提供来自所有领先内容元数据标准和专有方案的词汇的广泛和权威映射，提供了支持跨社区互操作性的工具。VMF不是任何现有标准的替代品，而是对互操作性的帮助。本体尚未广泛用于完全自动化的事务（如语义网中所预见的那样），但在大多数重要的多媒体元数据和消息传递方案中使用，为术语的明确、可扩展和精确定义提供了基础。

社区互操作性

标识符方案可以对与这些标识符相关的数据的使用进行权限和限制。标识符注册机构需要考虑在什么基础上能够与其他方案合作，或公开其数据；即使这在语法和语义上是可能的，开放互操作性也可能存在障碍。特定标识符的分配和使用可能涉及数据所有权、数据质量、数据维护、治理和参与要求；这些限制可能适用于商业和非商业环境。

使用映射到通用本体框架的语义互操作性需要两个方案之间达成双边协议，以确认彼此识别的准确意图（如果是单方面的，请注意映射因此未经一方确认）；这也为考虑此类映射的社区义务提供了机会。

每个标识符注册中心都有义务向其用户社区a保证其数据的准确性；因此，它不能依赖于没有质量控制的其他人的元数据。每个标识符注册中心还需要确保其标准通过业务模型实现：元数据具有业务价值，为注册中心实现其标准提供支持；因此，不能期望注册中心将元数据移交给与其没有业务关系的人。如果双方同意，可以起草一份双边协议，规定合作的性质（例如，适当的登记机构可以同意共享或比较随附元数据的值和更新过程）。如果双方不同意，就没有互操作性的义务。识别方案应通过提供关于权利和义务的明确指导来鼓励这种合作；这些通常是正式标准化过程的要求。

持久性和互操作性

持久性与互操作性密切相关：持久性是“与未来的互操作性”，即能够相互交换有意义的信息和启动操作的独立系统按时间分开。

可以针对特定有效但相对短期的需求（例如，社交网络上的流式订阅视频）建立一些标识符方案；其他人关注持久性和保存，同时致力于维护注册表方案和元数据。应用程序设计者需要考虑基于特定方案的应用程序的好处，并尽可能避免设计不符合其基本目标的方案。URL通常被引用为最常见的“标识符”（例如DC：标识符定义：“用于唯一标识资源的字符串或数字。默认为资源的URL”），尽管事实上URL是一个位置的标识符：由于最常见的单一重定向到一个URL的模式，这两者很容易混淆，标识符和referent之间的链接不是直接的，因此很容易断开。URL的进入和使用壁垒低，但持久性期望低。首选使用机制补充URL进程（PURL、ARK、N2T）或避免URL进程（Handle、DOI）的标识符方案。

已经开发了一种专门用于支持互操作性的机制：在Kahn/Wilensky数字对象体系结构中，引用（作为“数字对象”）携带元数据和到存储库的链接。这些数字对象并没有取代现有的格式和数据结构，而是提供了一个通用的框架来封装这些格式和结构，允许对它们进行统一的解释，从而可以在不同的异构信息系统中移入移出，也可以跨系统随时间的变化进行移动。虽然有一些实现，但尚未被广泛采用（尽管此体系结构的一部分Handle标识符本身也被广泛使用）。

实施者的经验教训

避免重复使用轮子：如果您似乎需要设计一个新的标识符方案，请检查是否可以通过重新使用现有标识符来避免此问题。
如果需要新的方案，请考虑是否可以利用现有的协议或标识符注册表来实现您的方案。
使用适当的公共命名空间声明注册您的方案。
通过指定格式良好的元数据方案并发布它，为语义映射提供简单的链接。
考虑社区和业务对可能需要使用您的方案的其他人的影响。
就使用方案的权利和义务提供明确的指导。
采用标识符和确保持久性的机制。

资源

<in_d_ecs>项目（电子商务系统中数据的互操作性）。元数据框架：原理、模型和数据字典。[ https://www.doi.org/resources/indos_framework_2000.pdf ]

标识符互操作性：关于最近两次ISO活动的报告。D-Lib杂志2006年4月。[ https://doi.org/10.1045/april2006-paskin（帕斯金） ]

RDA/ONIX资源分类框架。D-Lib杂志2007年1月/2月。[ https://doi.org/10.1045/1月2007-dunsire ]

CIDOC概念参考模型。[ http://cidoc.ics.fort.gr/index.html ]

数字对象架构。Kahn R.E.&Wilensky R.《分布式数字对象服务框架》。[ https://hdl.handle.net/4263537/5001 ]

此情况说明书的早期版本由发布欧洲数字保护.

资源

概况介绍