maggtomic (metadata aggregation using the Datomic information model) 是一个旨在用于元数据管理的模块化系统。

主要短期用例是支持国家微生物组数据合作组织（NMDC）试点项目的元数据提交、处理和管理。该项目的一个重点是培养一个开放（由开源驱动的）数据生态系统。

开发状态

当前的开发状态是规划和预-Alpha的混合（如https://pypi.ac.cn/classifiers/所示）。

假设和设计考虑因素

maggtomic的一个重点是敏捷性。该系统必须易于扩展，以适应持续引入的各种数据源和目的地，所有这些都需要是可查找的、可访问的、互操作的，并且可重用的（FAIR）。

Datomic信息模型通过其单一的全关系促进了这种敏捷性。它扩展了W3C标准资源描述框架（RDF）信息模型，该模型旨在促进分布式数据的互操作性，同时使用最小的注释来支持ACID事务。这些事务被具体化为持久实体，因此可以标注来源，从而实现历史审计和有资格的可重复性。每个现在的事实（所谓datom）都记录为一个5元组：实体-属性-值的三元组、事务ID（作为单独的事实标注事务墙时间）以及事实是否为断言或撤回。

选择MongoDB和Python

为了在一个开源系统中实现Datomic信息模型，以支持近期的激励用例——支持NMDC试点项目——最关键的运营考虑因素是对所选技术的熟悉度和可管理性（见：熟悉度）。maggtomic选择MongoDB。为什么？

• NMDC的大部分基础设施支持位于两个美国能源部（DOE）用户设施：联合基因组研究所（JGI）和国家能源研究科学计算中心（NERSC）。JGI存档和元数据组织者（JAMO）使用NERSC的硬件和人员支持，通过MongoDB管理面向用户的元数据。
• 其他面向大型用户的基础设施也使用MongoDB通过NERSC进行（元）数据管理，例如先进光源（ALS）用户设施和材料项目（MP）。
• 另一个专注于生物元数据管理的大型项目，扩展数据注释和检索中心（CEDAR），使用MongoDB作为元数据存储库。

因此，在基础设施支持级别和适用于科学领域建模的适宜性级别，相关利益相关者之间都有很强的运营熟悉度。但是，关于支持Datomic信息模型充足性能所需的系统功能，又该如何呢？首先，maggtomic旨在支持试点项目的需求，因此“充足”是预期性能的重要限定词。其次，MongoDB有几个特性以及配置选项可以帮助解决性能问题

• 冗余索引以支持各种访问模式：Datomic以至少4种排序顺序冗余存储所有数据，包括一个覆盖子集datoms的索引以支持反向属性查找。这种冗余是为了在同一个系统中灵活支持键值存储、行导向、列导向、文档导向和图导向的访问模式。为此功能，MongoDB在一个集合上支持多个（覆盖）复合索引和部分索引。
• 压缩：因为（a）所有数据都冗余存储在几个索引中的每一个中，并且（b）所有数据都是不可变的（仅累积，非常适合历史审计和有资格的可重复性），Datomic索引段高度压缩。使用MongoDB（默认）WiredTiger存储引擎，支持所有集合和索引的压缩，有不同选项来权衡更高的压缩率与CPU使用率。MongoDB 4.2中可用的zstd库在这里似乎是合适的，其压缩率高于默认的snappy选项，并且CPU使用率（以及更高的压缩率）低于zlib选项（以前是snappy的唯一内置替代品）。此外，WiredTiger集合的索引默认是前缀压缩的：对索引的查询，包括覆盖查询，直接在压缩索引上操作——即，它在RAM中保持压缩。
• 固定空间标识符而不是冗余字符串存储：Datomic中空间减少的另一种机制是将实体引用作为数字存储而不是存储较大的字符串值。当使用RDF的分布式数据模型并使用完全限定名称时，这一点尤为重要。MongoDB支持这种空间减少策略，要么通过内置的12字节ObjectId引用类型，要么通过类似Crockford的Base32的替代策略，用于可序列化且适合人类阅读的数字实体ID。
• 事务：在性能方面是一个问题，因为数据丢失是较差的性能（！）自4.0版以来，MongoDB支持多文档事务（自4.2版以来，在分片部署中支持），并支持可配置的写入和读取关注级别。

此外，还需要支持Datomic模式、查询和事务函数的类似功能，这些功能反过来又支持与底层信息模型的有效和高效交互。《maggtomic》选择Python作为客户端接口的语言，因为这种语言被利益相关者广泛使用。

• 对于模式支持，而不是翻译Datomic中使用的临时词汇，《maggtomic》旨在支持基于RDF的W3C Shapes Constraint Language（SHACL）标准的一个子集，虽然这个标准直到2017年才被正式确定为标准，而Datomic模式则更早推出。关键的是，Python工具如pySHACL可以用来验证SHACL形状图与数据图。可以检查各种SHACL节点形状，这些形状类似于JSON Schema文档，SHACL属性形状具有结构共享的优势，而等效的属性形状则需要为每个JSON Schema文档重新声明。通过这种机制，例如，一个元数据提交可以符合多个“模板”，并可以推导出建议，将提交符合提交者最初未考虑的一个或多个模板。
• 对于查询，《maggtomic》旨在利用MongoDB查询语言和MongoDB聚合管道的表达能力，提供类似于Datomic数据日志变体的查询接口。
• 对于事务函数，《maggtomic》旨在提供Python函数，例如返回与新的datoms、MongoDB聚合管道阶段相对应的字典列表。考虑到性能考虑，事务函数或查询谓词可能是任意的Python函数，因为它们的等价函数可能是Datomic中的任意Clojure函数，这可能会表现为中断MongoDB聚合管道。

当然，在《maggtomic》的alpha版本在生产性评估使用之前，不需要实现上述所有内容，但考虑选择Python和MongoDB实现（一个临时、非正式指定、充满错误、速度缓慢的实现，仅为一半的商业Datomic提供）的长期影响是很重要的，即使知道动机用途是为了在试点系统中的敏捷性，因此必须计划丢弃；无论如何，你都会这样做的。

最后，《maggtomic》旨在通过在JSON-LD序列化（因为JSON是利益相关者熟悉的一种格式）与对应于给定时间《maggtomic》数据库值的RDF图之间进行转换，来实现数据源和汇之间的互操作性。同样，Python工具对于这种转换至关重要，例如pyLD库是一个JSON-LD处理器，支持必要的操作，如扩展+扁平化（上下文注释的JSON-LD到RDF）和框架（+压缩）-- RDF到上下文注释的JSON-LD，这些操作可以利用规格，例如SHACL形状图和本体，作为现在数据库中作为事实安装。

数据流可能通过类似于材料项目maggma系统的“构建器”ETL过程来处理。尽管目前不属于短期目标，但可能构建一个及时数据流系统，以支持对《maggtomic》数据库体现的知识图进行足够性能的交互式查询。并行编程的元组空间模型（例如Linda）也可能在此取得成效。

为了支持元数据提交和搜索/检索的Web API，maggtomic旨在包含一个FastAPI服务器模块。对于基于浏览器的元数据提交和基本搜索/检索，maggtomic旨在包含一个（启用认证的）静态站点前端，该前端连接到Web API。

用户界面面包板

以下是maggtomic用户界面（UI）的面包板草图。每个位置都有属性，而连接线显示了属性如何将用户从一个位置带到另一个位置。此外，每个位置代表一个实体，面包板同时充当实体关系图（ERD），实体之间的实线边缘标注了关系多重性。例如：一个上下文与零个或多个（"0..n"）数据集相关联，一个查询与一个且仅有一个（"1"）上下文相关联等。

以下详细描述了这些实体，作为序列图展示的用例的一部分。

此外，实体及其关系的选取受到了data.world目录服务的影响。

用例“成功路径”的序列图

以下是核心用例集的序列图。每个图描绘了一个“成功路径”，可以用作spike的清单，其中图中每条箭头对应一个清单项。

创建新上下文

上下文可以比作“项目”或“分析”，因为它作为一种收集信息、对信息提出问题并传达答案的机制。它被称为上下文，因为（a）它并不局限于一个有开始、中间和结束的单一活动，就像项目或分析那样；并且（b）其意图与JSON-LD上下文类似。

当两个人互相交流时，对话发生在共享环境中，通常称为“对话的上下文”。这个共享上下文允许个人使用缩略词，如共同朋友的姓名，来更快地沟通，同时不失准确性。JSON-LD中的上下文也以同样的方式工作。它允许两个应用程序使用缩略词更有效地互相通信，同时不失准确性。

具体来说，maggtomic上下文用于映射与上下文相关联的数据集的术语和关系。以下图显示了创建新上下文的用户故事。

导入新数据集

数据集是一个RDF图，即一组实体-属性-值对，其中所有实体和属性都是URI，而值是URI或数据字面量（字符串、数字等）。数据集可以用于许多上下文中，上下文可以链接到许多数据集。

要将新数据集导入到maggtomic中，用户从工作上下文中进行操作；其他上下文以后也可以链接到并因此使用该数据集。数据集可以上传，或提供HTTP端点信息。例如，可以输入一个URL进行简单的GET请求。还可以支持更复杂的端点注册，例如使用POST请求，提供认证和其他头信息，要求通过端点定期重新获取数据集等。

用户可以导入非RDF格式的数据集，例如TSV表集合或JSON文档集合。在这种情况下，数据集将被原子化，即分解为实体-属性-值形式的原子语句。新原子化数据集的实体和属性的URI使用用户的maggtomic用户/组织名称和上下文的slug作为前缀，例如http://maggtomic-host.example.com/awesomeorg/my-great-context，类似于GitHub代码仓库的命名空间。

下图显示了导入新数据集的用户故事。

导入新规范

规范（代表“规范”）是提高数据集FAIR性的增强功能。规范也是一个RDF图，可以表示“应用”到数据集上的内容，意味着在此上下文中从数据集中推断出额外的事实——也就是说，在验证数据集不包含与规范相矛盾的事实之后。这种类型的规范也称为本体。

规范还可以是用于验证数据集是否符合规范的某些内容，例如模式（在SHACL中称为形状）。数据集不需要与上下文中所有此类链接的规范都符合；相反，链接它们可以帮助maggtomic系统生成建议映射。每个上下文都有一个“本地”规范，用户可以使用上下文的命名空间来管理受控词汇（术语字典）和术语之间的映射。通过这种方式，用户可以确保数据集符合感兴趣的规范。

这里的“规范”概念受到clojure.spec的启发：与数据集表示相似，并且比静态类型系统更具动态性和灵活性。

maggtomic的一个核心设计目标是促进将导入的数据集映射到共享规范。因此，用户应该能够进入一个上下文，导入他们的数据集，导入同事共享的规范（例如，来自导入数据集上下文的NMDC Schema），并建立术语之间的映射。如果其他用户已经导入了一个感兴趣规范，该规范可能可以从其他上下文中链接。

下图显示了导入新规范的用户故事。流程与导入新数据集类似，但在此情况下不需要原子化，因为假设规范以RDF序列化形式导入。

建议映射

为了支持跨数据集的查询，用户必须确保其工作上下文链接的数据集和规范之间的术语映射（除非数据集已经通过使用相同概念（URI）的相同术语进行链接——这是Linked Data的梦想！）。想象一个简单的上下文：一个数据集和一个规范：一个用户导入了一个他们希望与社区分享的新数据集，并已将之前导入的推荐规范链接到导入数据集的上下文。现在怎么办？

用户可以向maggtomic系统请求映射建议。首先，系统应确保根据上下文链接的数据集和规范，已确定并持久化所有推断。推断是在应用用户提供的本体规范到用户提供的数据时由用户提供的规范所蕴涵的实体-属性-值语句。换句话说，推断是用户提供的已知内容中已经明确暗示的映射，因此将这些映射作为建议提供，供用户在他们的上下文本地规范中确认和显式包含，将是多余的。

下图显示了请求应用于上下文本地规范的映射建议的用户故事。

应用映射

用户可以管理上下文，提供术语和映射的数据字典，这有助于简化跨数据集的可读查询构建。映射可能由maggtomic建议，或手动输入，但都由用户应用。

由于数据集和规范都表示为RDF，用户可以将规范语句作为数据集本身的一部分进行更新，使其更易于互操作。为Linked Data欢呼！

下方的图示展示了将映射应用于上下文本地规范的用户故事。验证步骤确保与链接规范的可蕴涵性保持一致。

创建查询

RDF数据集之间查询的标准协议和语言是SPARQL，它通过URI术语的前缀映射实现可读的查询。可能需要另一种查询接口/语言，特别是基于数据字面量而不是字符串的语言，如Datalog的Clojure/EDN基于的数据逻辑。可能值得调查的另一种数据逻辑变体是Eve语法。对于maggtomic，MongoDB的基于JSON的查询和聚合语言可能对适应很有帮助。

查询用自然语言问题标记，以方便用户导航和搜索相关查询，这些查询将用户引向相关上下文和数据集。

下方的图示展示了在工作上下文的一个或多个数据集中保存和运行查询的用户故事。

创建洞察

洞察是对上下文的一种轻量级注释，它传达了某些结果及其重要性。它是用户的一个“帖子”，包括文本和可能包含的以例如PNG图像形式存在的可视化内容。理想情况下，洞察链接到一个或多个支持洞察的具体上下文查询。

尚未显示创建洞察的序列图，因为这尚未被视为maggtomic最小可行产品（MVP）演示的核心用例。因此，现在绘制演示此功能的清单并非至关重要。