LSID 最佳实践

生命科学标识（Life Science Identifiers，LSID）已经成为生命科学领域普遍认可的标识方案。熟悉创建 LSID 系统时的主要问题，了解使用 LSID 的最佳实践。

如果您负责项目的数据建模，那么利用 LSID 惟一地命名生物学重要资源的任务就落在了您的肩上。数据建模中的很多基本概念很好地映射到了 LSID 中，但是仍有一些因素必须仔细斟酌。其中包括命名、缓冲，数据与元数据的区别。本文将探讨这些方面，并讨论每个主题中的当前最佳实践。

LSID 命名约定
易于维护的系统的关键是把握好数据模型。虽然 LSID 被定义成语义不透明的，但是 LSID 解析服务的作者必须解释编码来分析并返回正确的数据。这一节描述一些常见的数据模型，希望这些例子能够给那些使用 LSID 的人一些启迪。

LSID 由三种范围划分机制组成：权限、名称空间和标识。还可以包含版本，由修订标识指定。这些部分按照下面的形式结合形成 LSID。

urn:lsid:authority:namespace:identifier:revision

命名基本模型
为 LSID 服务创建命名方案的第一步是选择一个权限名称。通常是用组织中注册的顶级域名（TLD），比如 example.com。因为 LSID 解析使用 SRV 记录，所以 TLD 不必指向 LSID 服务器的 IP。在大型组织中或者对于单独的项目，可以使用子域名作为权限，如 department.example.com 或 project.example.com。对项目使用单独的权限可以降低数据模型的实体与名称空间标识之间产生冲突的风险。

假设已经选取了一个权限字符串，它在新建的 LSID 服务器上是惟一的，下面举一个从数据模型映射到 LSID 空间的例子。假设数据模型包含三类实体：ResearchInstitute、Researcher 和 Paper。ResearchInstitute 用 ResearchInstitute ID 标识，Researcher 用 Researcher ID 标识，Paper 用 Paper ID 标识。该模型如图 1 所示。

图 1. 学术机构的实体-关系模型

关系数据库中的表如图 2 所示。

图 2. 学术机构的数据库表

在这个简单的例子中，每个实体都有惟一的标识。将该数据模型公开到 LSID 空间最简单的办法就是为每个实体创建一个名称空间，使用实体的标识作为 LSID 标识。

urn:lsid:example.com:researchinstitute:ibmresearch
urn:lsid:example.com:researcher:alice123
urn:lsid:example.com:paper:132187

注意，ResearcherPaper 表仅仅是一个多对多的链接，不是实体关系图中的一个实体。这个表没有向模型中增加新的信息，它创建的链接可以添加到 Paper 实例、Researcher 实例或者两者的元数据中。

Revision （修订）是可选的标识，用于标记发生的变动。假设一个名叫 Alice 的研究人员，她找到了自己的白马王子，姓氏改变了。结婚后的 Alice 作为个人而言没有变，改变的仅仅是关于她的某些信息。这种情况下需要保持原来的 LSID，仅仅修改 revision，如清单 3 所示。

urn:lsid:example.com:researcher:alice123:2

这样她的同事就会知道 Alice 仍然是同一个人，虽然她已经结婚了。

命名复杂的模型
更复杂的例子涉及到不止有一个惟一标识的实体。假设数据模型中的 ResearchInstitute 为 Researcher 分配了一个 SerialNumber。在所有研究人员中，SerialNumber 不一定是唯一的，因此在数据模型中，您会说，Researcher 由 ResearchInstitite 及其 SerialNumber 标识。这种模型如图 3 所示。

图 3. 复杂的学术机构实体-关系模型

现在要将该实体模型映射到 LSID 空间。映射多个标识有几种常见的解决方案。第一种办法是在 LSID 的标识部分包含所有的标识，使用分隔符分开，如清单 4 所示。

urn:lsid:example.com:researcher:ibmresearch_12345

在您的权限实现中，应该将 LSID 标识分解开来，并从数据库中检索出正确的研究人员记录。必须保证选择的分隔符不能出现在第一个实体标识中。如果能够保证这一点，这是首选的办法。

第二种解决方案是在数据模型中赋予每个研究人员一个惟一的 id。从用户的角度来看，这可以透明地实现。因为 LSID 是语义不透明的，用户不需要知道您使用了一个惟一 id，可以照常使用您的数据。这个惟一 id 可以作为一个序列或者自动编号的列直接和数据存放到后端存储中。另一种办法是维护单独的映射，仅供您的 LSID 权限使用。无论哪种情况，都需要保证数据的改变能够反映到映射中。

urn:lsid:example.com:researcher:a23b32o21wq

Mapping table: 
+--------------------------------------------------------------+
| map.lsid_researcher | map.researcher | map.researchinstitute |
+--------------------------------------------------------------+
| a23b32o21wq         | 12345          | "ibmresearch"         |
+--------------------------------------------------------------+

数据模型到 LSID 的这些映射只是一个常见的实践，您可以任意选用权限、名称空间和标识定界，只要适合您的数据就行。

LSID 元数据

元数据还是数据？
使用 LSID 作为命名约定的主要好处之一是数据和元数据的清晰划分。这样也给 LSID 的实现者带来了一项任务，即确定什么是数据，什么是元数据。首先要认识到，虽然绝大多数 LSID 都有关连的元数据，但是很多 LSID 不一定与数据关联。

数据定义为不变的字节序列，比如显微图像、蛋白质序列、文本文件等。如果数据字节发生了变化，您有两种选择。一是创建一个全新的 LSID，二是增加 LSID 的 revision 号。根据系统的不同，您可能更倾向于其中的一种。要点是相同的：特定 LSID 的数据不能变。

既然很容易通过资源描述框架（Resource Description Framework，RDF）用元数据来提供，为何还要将蛋白质序列表示成数据呢？答案是，依赖的系统不同。实现者必须根据自己和用户如何使用该系统来作出选择。作出决策的时候，要记住元数据很可能被解析到 RDF 模型中，而数据用字节流的形式提供。如果不能从数据模型中确定哪些作为数据哪些作为元数据，可以遵循这条经验法则：大的字节序列作为数据更容易处理，而短的字节序列可以包含在数据或元数据中，也可以两种形式都提供。后面将进一步介绍。

附加的元数据
LISD 中包含附加的元数据，使您的数据模型能够发布到 LSID 空间。该发布建立了您的个人 LSID 与其他人的 LSID 之间的链接，形成了一个信息图，能够被机器解释。问题是：特定的 LSID 中应该包含什么样的附加元数据？

与命名一样，LSID 的附加元数据也大多来自数据模型。数据模型包含两种类型的描述符：属性和关系。这两种类型的描述符都进入元数据。属性多数变成了 RDF 文字，因为它们是基本数据类型。如果为每个实体创建了 LSID 的话，关系可能变成对其他 LSID 的引用。按照实体边界严格细分元数据的原因将在缓冲一节解释。我们再看一看学术机构的实体关系模型。

图 1. 学术机构的实体-关系模型

ResearchInstitute 实例的元数据包括三个文字值：研究所的 id、名称和位置。每一个都能用 RDF 文字表示。一个 ResearchInstitute 实例可以有多个研究人员。到 Researcher 实例 LSID 的联系应该作为 RDF 资源链接包含在元数据中。类似地，Researcher 元数据包含研究人员的 id、名和姓。这些都变成 RDF 文字，研究人员所属的研究所和论文应该作为 RDF 资源链接添加进来。

注意，对于每个关系，在两个方向上都添加了链接。这对于某些 RDF 专家来说看起来似乎有些多余，但是在 LSID 空间中这样做是必须的。因为 LSID 元数据是分布式的，可能只能看到全局的一部分。比方说，Alice 得到了同行研究人员的 LSID 链接，应该能够通过外向链接找到同行撰写的论文，但是不能确定其所在的研究所。发布双向链接的元数据可以解决这个问题。因此，为了便于解析，建议把链接做成双向的。

缓冲

缓冲概述
LSID 缓冲是解析方案的核心概念之一。使用全球可解析的标识并不意味着总是进行全球解析。随着解析数量的增长，利用请求的暂时性和网络本地性，通过一些技术可以大大降低通信量和权限服务器的负载。缓冲涉及到查找、存储和清除，可用于数据和元数据，有三种不同的方法：在权限服务器上、在缓冲代理中、在客户机栈中。

考察各种缓冲情形之前，首先分析一下要存储到缓冲区中的内容。可以缓冲 LSID 调用的数据和元数据。数据缓冲非常简单，因为数据被定义成不变的字节序列。缓冲区中的数据以整个 LSID 作为键，可以无限期地保存在缓冲区中。所谓无限，是说在缓冲区达到存储清理阈值之前可以一直存在。

缓冲元数据更加复杂，因为不能保证元数据是惟一的，也不能保证元数据不变。当前所用效果最好的系统以发布权限和 LSID 作为缓冲的元数据的键值。权限可以在元数据中放上一个超时值，告诉缓冲区元数据保持准确的大致时间。如果元数据处于不断变化的状态，权限可以规定不能缓冲该元数据。也可以部署或者可能已经部署了更复杂的元数据缓冲方案如 pubsub，但是这超出了本文的范围。

设计数据模型的命名约定时必须考虑到元数据缓冲。在 LSID 合成的 RDF 元数据文档中包含关于相关实体的附加元数据可能是明智的做法。这是一种危险的做法，因为元数据被缓冲了，以后对相关实体的更新不一定能正确地传播到客户机。基于这个原因，必须只把关于 LSID 的主要元数据放到 RDF 元数据文档中。相关实体应该通过到相应 LSID 的链接来引用。记住关于数据和元数据缓冲的这些概念之后，我们看一看三种不同的缓冲方法。

权限缓冲
作为 LSID 权限的维护者，您希望服务器或者服务器集群能同时处理尽可能多的请求。服务请求的过程中可能有两个瓶颈：后台存储和将元数据转化成 RDF。LSID 权限可以使用任何可能的存储设备，常用的有关系数据库管理系统（RDBMS）和 Web 服务。虽然很多程序员在不知疲倦地提高 RDBMS 和 Web 服务的性能，但是相对于权限任务的所有其他方面而言，它们仍然落后了。既然权限创建者关心的是速度，就应该尽量减少与后端的接触。

降低后端延迟和提高执行速度最好的办法就是使用权限缓冲。这种功能已经包含在 LSID 服务器参考实现中。发生正常的查找之后，可以使用目录和文件结构将结果缓冲起来。后续的数据和元数据请求中可以使用这些缓冲的副本。

缓冲代理
使用来自不同权限的 LSID 时，您和同事很可能需要解析一组类似的 LSID。有数十亿的 LSID，但是请求的只有一小部分。而且很可能过一段时间后还要重复解析同一些 LSID。了解了这些事实之后，可以为您的工作组、组织或者两者组成的体系建立 LSID 缓冲代理来改善解析过程。代理可以提高服务的质量，因为它在地理上与终端用户离得很近，减少了需要的外网带宽，缩短了完成解析需要的总时间。还可以降低主权限服务器的负载。这有助于避免可能影响其他解析的上游权限的阻塞。

客户机缓冲
客户机缓冲与缓冲代理的存在原因相同。它进一步缩短了完成解析的时间，降低了上游缓冲代理和权限服务器的负荷。客户机缓冲与代理缓冲之间有一个区别需要指出。代理缓冲返回的元数据文档与从权限检索的文档相同。客户机缓冲可以保存该文档，也可以存储到持久性的 RDF 模型如 jena 中。在这种情况下，客户机负责保证元数据是最新的。这是另一种这样的情形，即包含非基本元数据的 LSID 被缓冲而相关 LSID 的更新不能正确反映。权限的实现者必须保证只包含基本的元数据，确保能够正确地处理。

外部权限通知
外部权限（Foreign Authority）是一种 LSID 权限服务，指向 LSID 元数据，而不是任何 LSID 中的“权限字符串”所定义的实际权限。这些元数据服务是单独提供的，通常是作为实际权限提供的服务的补充。比如，外部权限可能返回包含关于 LSID 附加元数据（如注释）的元数据服务端点，而自身并不是这些 LSID 的权限。

生命科学标识规范中现在提供了惟一命名数据对象和协议的方法，通过协议，客户机软件可以检索那个数据对象或者那个数据对象的元数据信息。也可以使用同样的协议从称为外部权限的第三方检索数据对象的元数据信息。

很多人感到疑惑的是，既然 LSID 命名对象的权限和希望为命名数据对象提供自己的元数据（比如已有信息的第三方注释）的任意的第三方之间一般没有联系，那么 LSID 客户机软件如何动态发现和检索第三方（不是权限）收集的 LSID 信息呢？

当前的规范没有定义这种功能，我们只能说可能依赖于“Big-Google”这样的统一爬虫/索引服务，来发现提到某个 LSID 的所有地方，或者靠某种“神奇的”常识查询合作者提供的 LSID 解析服务或其他“众所周知的元数据资源”，但是要等到这样的服务出现才行。这些解决方案都不能彻底解决这个问题。

外部权限通知框架提供了正式的方法，第三方提供关于自己的信息的指针，按照生命科学标识权限提供的元数据可以检索到这些信息。

如果 LSID 权限服务希望同时实现 FAN，还可以用另外两种方法：

notifyForeignAuthority(String lsid, String authorityName)
revokeNotifcationForeignAuthority(String lsid, String authorityName)

可选的通知方法向任何 LSID 的权限注册外部权限服务的细节，这些外部权限服务也知道 LSID 的某些信息。通知的接受和存储完全交给 LSID 权限来处理。这些映射的实现也留给权限服务的实现者。

但是，所有发布的 LSID 映射必须通过实际权限指向的某个元数据服务来返回，并同时返回 getMetaData() 方法调用中的其他元数据。元数据语言建议使用 RDF。建议使用如下所示的 RDF 断言表明作为 LSID 的元数据返回了一个外部权限：urn:lsid:i3c.org:predicates:foreignauthority。目前还没有决定断言的右侧应该是什么。初步的实现中可以返回权限字符串。但是，更完善地实现可以返回一个 LSID 表示权限本身，并链接到关于外部权限本身的语义信息。如果存在映射的话，revokeNotification 方法将删除它。

使用元数据返回外部权限，因为这样可以使用现有的基础设施，特别是 getMetaData() 方法调用。此外，可以包含关于外部权限的丰富的元数据，提供关于外部权限的可信性或者上下文信息。将返回 LSID 权限名称，这样客户机可以知道外部信息的来源，判断可信性。任何 LSID 第三方元数据的用户都需要知道，他们看到的某些信息来自 LSID 权限，另一些则从其他的第三方返回。所有这些不同的来源，包括原来的权限，在用户看来很可能有不同的可信级别。

其他候选者包括实际的权限端点和实际的元数据/数据服务端点。权限端点被排除掉了，因为端点可能变化，而权限名称是固定的。实际的服务端点被排除掉了，因为这些端点没有资格。此外，外部权限可能添加服务，这样需要重新注册。最后，权限名称是确定 LSID 信息来源最一般、最灵活的方式。

FAN 服务 notifyForeignAuthority 调用不包含访问限制的内置方法。可使用身份验证、可信 Web 或者其他方法控制访问，留给 FAN 服务的实现者决定。下面提出一种建议的方法供讨论：

外部权限发布时，实现可以真正尝试解析该外部权限，并检查是否包含给定 LSID 的元数据服务。这样虽然没有解决外部权限提供伪造元数据，或者其他方未经该第三方许可创建通知的问题，但是可以保证所有注册的权限都提供他们所宣称的元数据。第二种安全方法可以保护发布服务本身，只有授权的参与方才能发布映射。

数据

数据概述
介绍在 LSID 上提供数据的最佳实践之前，重温一下 LSID 数据的特性有助于展开讨论。从本质上说，LSID 数据就是简单的字节序列。该数据表示一个文本文档，或者是某个作者写的，这类信息通常属于元数据。这些元数据可能经常编码在数据中，比如 Microsoft Word 文档保存了文档作者的姓名。但是，LSID 数据总是被看作不透明的一组字节，只有特定的应用程序能够理解这些数据。相反，RDF 元数据可以被各种通用的 LSID 应用程序理解。其次，要记住 LSID 数据是不变的。一旦某个 LSID 分配了一个字节序列，这些字节就不能再变了。如果数据被更新，应该用新的 revision 提供新的 LSID。

返回数据
因为给定 LSID 的数据仅仅是一个字节序列，确定数据服务对一个 LSID 返回哪些字节通常很简单。比如，LSID 可能是一个 JPEG 图像，那么返回的就应该是 JPEG 文件的字节。但是，确实有时候不清楚应该为 LSID 返回什么数据。比如，表示短基因序列 GATTACA 的 LSID，这个 LSID 的数据应该是序列的某种表示。一种可能是返回包含字符串“GATTACA”的文本文档，另一种可能是返回标准 FASTA（读作“fast A”）格式的序列。除了其他字符之外，FASTA 文件包含一个标记为 ->' 的前导行，如清单 7 所示。

>gene1 This is a gene we found after hours of research
GATTACA

最后，要注意某些 LSID 可能不含数据。这样的 LSID 通常是只包含元数据的抽象 LSID（或者概念 LSID）。这类元数据可能引用包含数据的 LSID。下一节将详细介绍如何使用表明格式的元数据，并提供抽象 LSID 与具体 LSID 之间的联系。

数据上下文

数据格式
消费 LSID 数据的客户机应用程序必须理解数据的格式。LSID 数据格式帮助应用程序处理 LSID，就像 MIME 类型帮助浏览器将数据分发给适当的应用程序一样。因为 LSID 不依赖于传输，所以不需要依靠 MIME 类型这类传输专用属性来确定数据格式。某些 HTTP 数据服务为了方便起见可能会选择包含 MIME 类型，有些 SOAP 数据服务可能希望包含 SOAP 头。但是，应用程序不应该依赖这种结构。相反，应该使用 RDF 元数据来描述数据格式。元数据一节中提到过，在需要发明一组新的 RDF 断言的场合，应尽量遵循现有的本体论。该例使用 http://purl.org/dc/elements/1.1/#format，记为 dc:format。

 
<rdf:Description     rdf:about="urn:lsid:ncbi.nlm.nih.gov.lsid.biopathways.org:genbank_gi:30350027">
 <dc:format rdf:resource="urn:lsid:lsid.biopathways.org:formats:fasta" /> 
</rdf:Description>

清单 8 表明，Genbank 核苷可以作为 FASTA 基因序列检索得到。目前，还不存在所有数据格式的 RDF 资源。服务实现者应该对 dc:format 语句的对象使用已有的 URI 如 URL。该例中不存在这样的 URL，于是我们（作者）发明了一个合理的 LSID 来表示 FASTA 格式。

抽象 LSID
LSID 背后的数据可能以多种数据格式存在。一种办法是使用单个 LSID，将所有不同实例迭加在一起，用某种记号划分不同的格式。这种解决方案不太好，原因有多种，主要是客户必须下载所有的格式。最好的办法是为每种数据格式创建单独的 LSID，然后用一个抽象 LSID 将它们联系起来。

采用抽象方案的好处是，它允许 LSID 不命名实际的数据字节，而仅仅提供元数据文档。这些 LSID 可用于表示抽象概念，如基因和蛋白质，可以有很多具体的表示。与抽象 LSID 相关的元数据文档可以包含多个关系，指向命名数据字节的 LSID。

这样，研究人员可以使用一系列的 LSID 创建互相联系的元数据图，来命名具有多种表示的对象。抽象 LSID 为软件和用户提供了锚点，以探索元数据，并获得指向所有具体 LSID 引用的指针。这些具体 LSID 引用包含数据以及数据与抽象概念之间的具体关系。这个间接层次非常强大，下面是一些应用的例子。

多种数据格式
这种方法的细节最好用一个例子来说明。再考虑上述 Genbank 核苷的例子，假设还有一种存储格式是碱基对字符串，没有 FASTA 头或者其他内容。创建两个新的 LSID，每种数据格式一个，然后用清单 9 所示的断言联系在一起。

urn:lsid:ncbi.nlm.nih.gov.lsid.biopathways.org:genbank_gi:30350027-fasta
urn:lsid:ncbi.nlm.nih.gov.lsid.biopathways.org:genbank_gi:30350027-string

urn:lsid:lsid.biopathways.org:predicates:storedas denoted bpw:storedas 

后缀 -string 和 -fasta 仅用于命名约定。要记住 LSID 被定义成不透明的。应用程序不应该尝试从名称推断数据格式。相反，两个数据 LSID 包含以下元数据：

<rdf:Description     rdf:about="urn:lsid:ncbi.nlm.nih.gov.lsid.biopathways.org:genbank_gi:30350027-fasta">
 <dc:format rdf:resource="urn:lsid:lsid.biopathways.org:formats:fasta" /> 
</rdf:Description>

和

<rdf:Description     rdf:about="urn:lsid:ncbi.nlm.nih.gov.lsid.biopathways.org:genbank_gi:30350027-string">
 <dc:format rdf:resource="urn:lsid:lsid.biopathways.org:formats:string" /> 
</rdf:Description> 

为了将其联系在一起，请创建一个抽象 LSID lsid:ncbi.nlm.nih.gov.lsid.biopathways.org:genbank_gi:30350027，它没有关联的数据，但是它的元数据将其链接到包含数据的具体 LSID。

<rdf:Description     rdf:about="urn:lsid:ncbi.nlm.nih.gov.lsid.biopathways.org:genbank_gi:30350027">
 <bpw:storedas rdf:resource=" urn:lsid:ncbi.nlm.nih.gov.lsid.biopathways.org:genbank_gi:30350027-string" /> 
 <bpw:storedas rdf:resource=" urn:lsid:ncbi.nlm.nih.gov.lsid.biopathways.org:genbank_gi:30350027-fasta" />
</rdf:Description>
 

为了提高效率，抽象 LSID 可以包含具体 LSID 的 dc:format 三元组，这样客户机很容易就能根据格式选择具体 LSID ，而不需要首先解析所有格式。

数据版本
数据更新后使用 LSID 很容易重新组织。假设抽象 LSID 中的一个链接是“最新版本”关系。比方说，蛋白质可能表示成 FASTA 序列、mmCIF 数据块、特定解析中的 jpeg 图像或者一系列发布的引用。随着时间变化数据不断修正，这些格式都可能有多种版本。赋予包含正确数据的 LSID 一个新的版本，抽象 LSID 可以被更新以指向这个新版本。要引用数据的实例，必须解析抽象 LSID 并检索它的元数据。这些元数据用于发现最新数据版本的 LSID，然后依次解析并检索数据。

结束语
深思熟虑的 LSID 实现是充分发挥 LSID 解析网络协作和数据联邦潜能的先决条件。数据模型的形式和规模可能相差很大，这些最佳实践不一定适用于每种情况。尽管如此，如果实现 LSID 系统时认真考虑本文提出的要点，您的组织就能够从 LSID 的自然数据共享能力中获益。