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

lidingpku commented 7 years ago

这个问题之所以重要，因为它涉及了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/

一种方案是直接对接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 commented 7 years ago

B 昊奋，华钧

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

lidingpku commented 7 years ago

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

zjumper commented 7 years ago

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