追溯资料里的Schema、Context与Ontology，为什么不能当成同一种附件

一份农产品追溯技术材料附上数个GS1文件名，可能都被简写为“标准附件”。但GS1的EPCIS/CBV 2.0.1配套目录把它们分在不同栏目，并逐项说明用途。[1] 对需要阅读系统资料的农业服务机构，先辨认附件负责什么，比把所有链接视作同一种证明更有帮助。

目录将epcis-json-schema.json列在数据校验文件中，用途是校验JSON或JSON-LD格式的EPCIS数据。相邻的epcis-shacl.ttl同样是校验资源，描述的格式范围为JSON-LD。[1] 它们的介绍关注数据按相应格式接受校验，没有在这张目录页中承诺某条实际业务记录必定真实。

epcis-context.jsonld位于另一栏目。目录说，它支持把JSON格式的EPCIS数据转换为JSON-LD和链接数据RDF三元组。[1] 因而，Context在这里负责的是表达转换所需的上下文，不应仅因为扩展名带jsonld，就把它改称与前述Schema完全相同的校验文件。

Ontology又有不同的定义对象。EPCIS本体的JSON-LD和RDF Turtle文件，被说明为EPCIS术语中类与属性的链接数据定义；CBV本体文件则描述代码表与代码值。[1] 两者都属于术语资源，但前者所列的类和属性，与后者的代码取值体系并非一个栏目换两种名称。

目录同时保留了XML路线：其中列有EPCISDocument、EPCISQueryDocument和EPCISMasterDataDocument对应的XSD文件。另有OpenAPI接口及SOAP/WSDL接口定义。[1] 这些相邻条目说明，文件用途还要连同数据格式或接口背景读，不能只凭“来自GS1”便认定某个文件适合解释所有资料。

可以设想，一份追溯软件介绍只附有Context链接，却宣称已证明每次收货的真实发生。目录本身没有提供这样的证据。Context的转换角色、Schema的校验角色与真实业务凭证处于不同层次；这个假设用于说明附件用途的边界，不是本文检查过某个企业系统的结果。

本篇实际完整阅读配套目录提取文字，未下载各文件逐行分析、运行校验或读完体积过大的EPCIS标准正文。页面标题为EPCIS/CBV 2.0.1，标准链接另列CBV 2.0.0，首次发布日期未确认。文章不提供系统部署、接口调用、追溯法律义务或农产品放行判断。把校验、转换和术语定义分清，可以让技术附件回到各自支持的任务，而不会由一个文件名推成完整追溯能力的保证。