GTS 图传输

GTS（Graph Transport Substrate） 是一种与本体无关的二进制容器与传输格式，用于 RDF 1.2 数据集与内容寻址的二进制载荷。PurRDF 托管其参考 Rust 引擎 purrdf-gts（重新导出为 purrdf::gts）。

本章是面向用户的导览。线格式本身由 docs/GTS-SPEC.md 规定——分帧、折叠语义、注册表与一致性类别请查阅该规范；此处任何内容都不取代它。

容器模型概览

GTS 文件是由一个或多个只追加段组成的 CBOR Sequence。每个段是一个确定性的 CBOR 头，后接由 BLAKE3 内容标识符串联起来的确定性 CBOR 帧。逻辑数据集通过对段序列进行确定性折叠得到：四元组、具体化节点、注解与二进制 blob 都成为折叠后容器图中的行。

这一设计自然带来的性质：

内容寻址且只追加——历史从不被改写；抑制本身也是一条追加的记录。多段文件通过简单拼接即可组合。
部分可读，读取器是全函数——读取器校验 BLAKE3 链并折叠它能处理的内容；无法解码的帧（未知编解码器、无密钥的加密帧）会降级为_不透明节点_加一条诊断，而不是中止。
二进制载荷随行——图所引用的 blob 与其位于同一文件中，与其他一切一样按内容寻址。
原生 RDF 1.2——规范形式化了三元组项与 rdf:reifies 的映射、空节点作用域以及多段值的并集。

从 Rust 读写

容器引擎（purrdf-gts）负责线格式的全部机制——读取器、写出器、折叠、校验、COSE、信任策略：

#![allow(unused)]
fn main() {
use purrdf::gts::reader;
use purrdf::gts::{model::{Graph, Term}, writer::Writer};

let mut source = Graph::default();
source.terms.extend([
    Term::iri("https://example.org/alice"),
    Term::iri("https://example.org/knows"),
    Term::iri("https://example.org/bob"),
]);
source.quads.push((0, 1, 2, None));
let bytes = Writer::deterministic(&source, "example-profile")?.into_bytes();

// 把 GTS 字节折叠为容器图模型，同时校验 BLAKE3 链。
let graph = reader::read(&bytes, /* allow_segments */ true, /* expected_head */ None);

// 折叠是全函数：四元组、具体化节点、注解与 blob 都是行，
// 任何无法解码的内容都会保留为一个不透明节点加一条诊断。
println!("{} quads, {} blobs", graph.quads.len(), graph.blobs.len());
assert_eq!(graph.quads.len(), 1);
assert!(graph.blobs.is_empty());
assert!(graph.diagnostics.is_empty());
assert_eq!(bytes, Writer::deterministic(&graph, "example-profile")?.into_bytes());
Ok::<(), Box<dyn std::error::Error>>(())
}

写出器编写帧，并生成逐字节确定性的单段快照（Writer::deterministic）——GTS 写出器与每个 PurRDF 序列化器受同一确定性不变量约束。

RdfDataset 的导入/导出路径位于上一层：总括 crate 的 gts 模块把容器引擎与 RDF 层适配器（快照组合、内容链校验）结合起来，因此面向 RDF 的 GTS 工作直接经由 purrdf 完成。

签名与加密

帧可以用 COSE 签名与加密；基于 OpenPGP 的检查以及信任策略层也是引擎的一部分。所有密码学实现都是纯 Rust——不依赖 C 工具链、线程或系统调用——这正是整个引擎能保持 wasm 友好的原因。无法解密的加密帧在折叠中只是一个不透明节点：容器仍然可读。

仅限 Rust 库：压缩证书、证明与密钥环校验

除读取、写入与折叠之外，purrdf-gts 与总括 crate 的 gts 模块还带有一套其他任何接口都无法到达的校验栈——CLI、Python、wasm 与 C 都不行：

带证书的可流式压缩——compact_streamable 把一个累积式日志重写为一个按交付顺序排列的段（前置流索引、尾部偏移页脚、带内字典），而 compact_and_certify / verify_compaction / compose 绑定一个内容投影，使压缩前与压缩后的容器折叠出逐字节相同的规范内容；校验器用其自身的密钥环从压缩前的字节重新计算。压缩从不改变内容，也不生成任何内容签名。
Merkle 山脉（Merkle mountain range）证明——mmr::{root, prove, verify_proof, prove_file}（gts-mmr-proof-v1），以及 verify_content_chain，后者依次走过 COSE 签名 → 链头（head）重放 → 摘要包含性。不存在透明日志，也不存在签名检查点服务。
OpenPGP 传输密钥——ASCII 铠装的 Ed25519 证书与未加密的私钥（parse_transport_key、parse_secret_signing_key），并用 verify_file_with_keyring 支持轮换；其他算法、加密的密钥以及 v5/v6 数据包都会被拒绝，且不存在密钥环存储或吊销存储。

原生单元测试覆盖文件媒体类型映射以及 tar/PAX 的序列化与解析。冻结向量以及压缩/认证测试夹具还覆盖其他路径。这些检查仅证明其所述用例，并不意味着文件 profile、嵌套的 GTS-in-blob 读取器、信任策略或 ULID 行为都已得到完整覆盖。上游 gmeow-gts 规范与冻结向量仍是线格式的权威。

一致性向量

GTS 一致性依据一个冻结的、与语言无关的向量语料（仓库中的 vectors/）定义，并在其他语言的兄弟 GTS 引擎之间逐字节共享。这些向量从不在本仓库中重新生成或被「修复」——该格式由 gmeow-gts 项目管理，规范与其他参考引擎也在那里。

对一个含引用三元组/具体化节点绑定的数据集，GTS star 层往返（转换）经由内核的 to_gts → read_graph → import_gts_graph 路径成功完成，与不含 star 的往返相同；crates/rdf-capi/tests/abi.rs 中的 gts_star_roundtrip_preserves_the_statement_layer 固定了这一点。参见入门：C。

The PurRDF Book