@type 的值域逻辑以及Taxonomy的处理

[lidingpku]

这个问题之所以重要，因为它涉及了cnschema数据模型的基本设定。 决定了cnschema的后续走向，给出唯一的规范的cnschema结构，有效对接JAVA等强类型开发语言，避免后续处理成本。希望大家对候选方案提意见，最终得出满足应用落地的候选方案。

背景

• Taxonomy 实体分类体系是知识图谱Schema的重要组成部分
  • 在实际应用中，通过实体分类可以说明该实体通常应当具备哪些属性，以及属性值应当满足哪些约束条件
• Taxonomy 在应用中存在两类实现方案
  • 分类树：Tree structure，（1）每个实体A都对应唯一的最细分类C，C是A的所有其他分类的子类 （2）这个概念对应JAVA 中Class 继承关系
  • 分类标签：directed acyclic graph (DAG) （1）每个实体A可以对应若干个分类C1，C2..., C1与C2 可以没有子类关系 (2)这个概念对应JAVA中Interface机制， 支持多继承与多态，这就是说，一个实体可以按照其所属的多个分类标签对外提供服务，应用中也可以按照每个分类标签看该实体是否符合cnschema规范。
• 领域特定的扩展schema会设定唯一的标准序列化机制（normalization），就是说每一个属性有唯一值域类型。这样确保POJO等强类型语言对象体系到JSON存在唯一映射，也进而支持有效的应用端数据validation e.g. { "byArtist" : { "name": "五月天"} } 而不是 {"byArtist"： “五月天"}

讨论

• 一个实体通常会被分到一个或多个分类，特别是在不同的领域无法保证同一实体会有相同分类。所以，数据融合容易发现多重继承现象。例如 MusicGroup无法区分人和乐队，而人物百科都是Person，这样 “周杰伦” 既可以是Person，也可以是MusicGroup。 同样一所医院可以是一个组织机构，也可以说是一个热门地点。
• 我们希望每个实体支持多个类型， 属性值的值域为 List of String e.g. { @type: ["MusicGroup","Thing"]}, 列表中第一个为缺省分类，也通常是指最细的分类。 根据我们历史的经验来看，分类标签结构在具体应用中有更加广泛的应用场景。
• @id @type @context 等属性值是JSON-LD( https://json-ld.org/ )的规范
• @type 有值可以，但是采用 list 结构，使用javabean不好对接
• @type 在实战中常用字符串，尚未见过list 结构的值域， 包括google KG API 也是这样的用法https://developers.google.com/knowledge-graph/

• 资料：json里使用@type 是与JSON-LD 一致的解决方案, schema.org 的讨论在这里 JSON-LD emerging best practice is to alias @type, @id (and other keywords) schemaorg/schemaorg#854
• 资料：fastjson FastJson的自省功能：@type如果没有在“{”之后的第一位，则反序列化得不到预计结果 alibaba/fastjson#406
• 资料：json schema: https://spacetelescope.github.io/understanding-json-schema/reference/type.html
• 资料：https://www.w3.org/TR/json-ld/#specifying-the-type
  

java中 JSON序列化策略

• 一种方案是直接对接JAVA bean， 要求 @type 为字符串
• 如果@type 的值是list , 且仍然依赖java类继承, 可以在序列化时通过注释调整，例如列表中第一个类型为缺省类型对应java class，导出时也要讲单值转化为列表
• 如果@type 的值是list，直接通过接口interface的方式来明确某一个实体的具体属性

候选方案

• 方案A
  • @type 值域设定为字符串，作为缺省类型
  • 增加 allTypes 字段，支持 List of string 的多类型语义
• 方案B （ 此方案与Google KG API 一致）
  • @type字段，支持 List of string 的多类型语义， 列表中第一个分类为缺省分类
  • optional，增加 mainType 值域为字符串，作为缺省类型

[lidingpku]

B 昊奋，华钧

遗留问题，选B是不错，但是我担心的问题是 （1）需要java序列化时做一些特殊的注释操作， @type通常是被认为是缺省的分类（2）与Google KG API有一定差异。 这样选A是否可行？

[lidingpku]

那我们就选择方案B，保持与google KG API 一致

[zjumper]

支持选方案B，而且建议mainType在@type值为list of string时为必要。出发点是考虑到JSON-LD最重要的是语义自解释性，不建议采用“约定第一个类型为缺省类型”这样的方法来解决问题，这很容易造成语义混淆和丢失。