BioThings Explorer: A platform for distributed knowledge integration across biomedical APIs

BioThings Explorer：跨生物医学 API 的分布式知识集成平台

• 批准号: 10333462
• 负责人: ANDREW I SU
• 金额: $ 88.08万
• 依托单位: SCRIPPS RESEARCH INSTITUTE, THE
• 依托单位国家: 美国
• 财政年份: 2020
• 资助国家: 美国
• 起止时间: 2020-01-24 至 2022-01-23
• 项目状态: 已结题
• 来源: https://reporter.nih.gov/project-details/10333462
• 关键词: Address; Adoption; Automation; Bypass; Client; Communities; Data; Databases; Ecosystem; Failure; Gatekeeping; Individual; Infrastructure; Knowledge; Methods; Modeling; Output; Provider; Pythons; Registries; Resources; Running; Schedule; Semantics; Source; Structure; System; Thinness; application programming interface; base; data ingestion; data integration; data resource; improved; knowledge graph; knowledge integration; non-compliance; web app

This proposal describes the BioThings Explorer (BTE) platform as an Autonomous Relay Agent (ARA). Most data integration efforts (including many being pursued within Translator) are based on building centralized data resources. These efforts typically involve building resource-specific data ingestion parsers, the outputs of which are assembled into knowledge graphs and loaded into a local database (with neo4j being a popular option within Translator). The BTE platform takes a complementary approach to data integration, focusing on a distributed network of knowledge providers connected by application programming interfaces (APIs). A proof-of-concept implementation of BTE is now complete (with demos available in [1,2]). This implementation has three components (Figure 1): a distributed knowledge graph (distributed-KG) based on many individual web APIs "in the wild", a meta-knowledge graph (meta-KG) that describes compatibility of inputs and outputs between each API, and a BTE python client that automates the planning and execution of queries across the API network. Relative to centralized solutions, this distributed model offers several advantages. First, the API ecosystem is easily extensible by the community since there is no gatekeeper controlling access to a centralized resource. The scope and output of the BTE system will continuously and automatically improve as the community-maintained registry of API components continues to grow. Second, the data retrieved are always up-to-date with the source and not dependent on having a frequent synchronization schedule. Third, the distributed model is more scalable to heavy usage since the BTE client is run on each user's own computing infrastructure, bypassing any centralized component that could become a single point of failure. BTE also distinguishes itself from other federated API solutions by using semantically-precise annotations of APIs as they exist, rather than mandating any changes to the API itself. These API annotations describe API inputs and outputs in enough detail to support initiating the API call and interpreting the result. In contrast, other federated approaches (including some within Translator) require APIs to conform to a common API structure. However, requirements like these have historically been significant barriers to widespread adoption, and thin API "wrappers" around non-compliant APIs introduce additional complexity and technical points of failure. The strengths of the current BTE implementation are the ease of adding new resources and the automation of the query planning and execution. The critical challenge that we address in this proposal is developing new methods to rank and sort the query path results that are retrieved from BTE queries.

该提案将 BioThings Explorer (BTE) 平台描述为自主中继 代理（ARA）。大多数数据集成工作（包括在 Translator 中进行的许多工作）都是 以构建集中化数据资源为基础。这些工作通常涉及构建特定于资源的 数据摄取解析器，其输出被组装成知识图并 加载到本地数据库（neo4j 是 Translator 中的一个流行选项）。 BTE 平台采用补充方法进行数据集成，重点关注 通过应用程序编程接口连接的分布式知识提供者网络 （蜜蜂）。 BTE 的概念验证实施现已完成（可在 [1,2]）。该实现具有三个组件（图 1）： 分布式知识图 （分布式 KG）基于“野外”的许多单独的 Web API，一个元知识图 （meta-KG）描述每个 API 和 BTE 之间输入和输出的兼容性 python 客户端，可自动规划和执行跨 AP​​I 网络的查询。 相对于集中式解决方案，这种分布式模型具有多个优点。一、API 由于没有看门人控制，生态系统很容易由社区扩展 访问集中资源。 BTE 系统的范围和输出将持续不断地扩大 随着社区维护的 API 组件注册表的不断完善，自动改进 生长。其次，检索到的数据始终是最新的源数据，并且不依赖于 有频繁的同步计划。第三，分布式模型更具可扩展性 大量使用，因为 BTE 客户端在每个用户自己的计算基础设施上运行，绕过 任何可能成为单点故障的集中式组件。 BTE 还通过使用语义精确来区别于其他联合 API 解决方案 对现有的 API 进行注释，而不是强制对 API 本身进行任何更改。这些 API 注释足够详细地描述 API 输入和输出以支持启动 API 调用并解释结果。相比之下，其他联合方法（包括一些内部方法） Translator）要求 API 符合通用的 API 结构。然而，像这样的要求 这些在历史上一直是广泛采用的重大障碍，而薄 API“包装器” 不合规的 API 会带来额外的复杂性和技术故障点。 当前 BTE 实施的优点是易于添加新资源以及 查询计划和执行的自动化。我们在此解决的关键挑战 提案正在开发新方法来对检索到的查询路径结果进行排名和排序 来自 BTE 查询。