知识图谱的命名方法

[lidingpku]

知识图谱目前看来还算是一种符号体系，对图谱节点和属性达成一致的命名算是知识图谱复用的关键，而且属性名和分类名又是重中之重。类名，属性名都是知识图谱应用中很常用的词汇，如何明确这些词汇的定义，以及能否支持这些词汇的自然语言接口（词汇的多样化，多语种说法）是应用的关键。

拿“籍贯”这个属性来说，我们至少有四种属性名命名方式：

• 沿用中文名称， 人工填表当然是看见这个
• 使用汉语拼音，
• 使用英文翻译，这是schema.org的思路，当然这个属性只有中国人有，所以schema.org没有收录。有些中文属性更难翻译，另外还要考虑下划线分隔，驼峰分隔。
• 使用数字标识,然后给出多语种的文字label 这个是wikidata的思路， https://www.wikidata.org/wiki/Property:P66
  在实际应用中，如果混搭上述任意两种或更多的命名方式， 例如 {"name":"张三", "籍贯":"北京"}， 也会给开发者带来困惑。那么还有没有其他解决方案？这些方案能不能混搭？如果只能选一个，哪一个更好呢？

另外要区分两个问题

• schema linking 映射两个属性
• property naming 类似变量命名方式

[lidingpku]

这个问题可能会进一步细化到 （1）属性名，类名 （2）实体名 。实体名这边其实还是有不少数字化命名的成功案例，如DOI， RRID。但是属性名／关系名／类名这一块问题就相对多了。一方面写Wikidata query 的难度还是蛮大的， 一方面schema.org也难覆盖"籍贯"。 对于数据发布者而言，一方面是没有限制，另一方面则是要给出指导（很多人在设计API时其实是希望有参考的）。此外，提供映射关系也是知识工程师或者OpenKG的专业服务。

1. 数据发布者自主定义schema
2. 我们作为专家还是要给出推荐
3. 实用不实用还是要使用者说了算，那我们站在真实的实用场景中到底对数据发布者有什么要求呢

[lidingpku]

程龚：
我觉得，内部用用的话，直接中文，有歧义的时候，sense用中文再加在后面，不要怕名字长，总比看不懂、理解错要强。英文特别是领域术语，很多开发者看不懂的。至于复用schema这个事情，最好别直接用（以后他一演化你就栽了），可以借鉴过来然后自己本地化一下，最后link回去就完事。

同意@鲍捷-文因互联 的观点，能不限制就不限制。如果schema linking对发布者自己有好处，发布者自己会去做的。如果对自己没好处，对别人有好处，那就有market了，自然会有第三方（比如openkg）去做。

[lidingpku]

张林
可以参考术语标准化的做法，比如 IHTSDO SNOMED CT等临床术语标准的命名与编码策略
基本原则可以参阅如下ISO标准及其相应的国标

ISO/TS 17117:2002 Health informatics - Controlled health terminology - Structure and high-level indicators

核心的概念标识符应采用无含义的唯一性标识符

当然，可以同时配有便于导航之类不同用例的标识符

可读性可以利用其他编码来体现

同时可以结合使用命名空间标识符

NLM UMLS以及NCI EVS就是管理众多不同本体的范例

API方面可以参考OMG CTS2

[lidingpku]

王昊奋

对于汉语拼音我是直接Pass掉
多语种表示如果不做多语言数据的展示浏览（如Wikidata），那么也不建议在URI上做显式区分
如果全部是内部定义的，为了兼容，可以考虑用英语名+senseID形式
其实就是一种类似identifier convention
一般由于会从外部获取在没有进行完全合并前一定是混用的
这个时候以一种作为标准，逐步映射即可
ID化对于去歧义是好滴，但是丧失了可读性
但是混用的风险在于如果你发生变化
就是在作为API中
如果是Json返回，你对于解析程序有修改风险
需要额外提供映射服务
让调用者添加这个一直维护的映射服务
这样就可以做到通用了
@張林-BIPH 是这样的，所以其实你维护了两套编码，在有多套的时候就会存在不一致，额外维护负担，以及数据更新同步等工程问题

这里一定不是追求统一标准而是best practice
我觉得其实有必要整理成一篇技术文档来告诉大家 华钧，建议放在OpenKG下来做

还是以string为主，只是对于特定领域的可能就ID化了，其实人也不是按照ID来记忆的

[lidingpku]

鲍捷

我倾向于不对发布者做约束。其实上，提高发布者负担的shcema是很难被应用的
w3c也有一大堆best practices，大多无疾而终
我觉得一小群人关起门来讨论的东西，都很难被实际使用

http://baojie.org/blog/2011/12/12/schema-org-challenges

[lidingpku]

陈华均

还要考虑bot的需求吧，还不是给人看的，人方便bot不方便，bot方便人就不方便

限制有限制的好处，很多时候不是不想限制，只是暂时还做不到或者驱动力不够，但我觉得在未来凡是涉及众包模式获取高质量的知识图谱的场景，都会增加约束和增强限制，限制不了的也会给推荐的方案。

[wangzigo]

1. 关于属性命名

我个人更倾向于使用数字标示加多rdfs:label的方式，实际上在12年我们第一次构建xlore知识图谱，对于概念、实例和属性都使用这种方式。比如：

http://xlore.org/property/13 rdfs:label “Native name”@en .
http://xlore.org/property/13 rdfs:label “外文名”@zh .

这个例子中外文名和Native name是一个属性，这也是跨语言知识图谱中一个有趣的现象，单从名称翻译来说二者似乎不同，但在语言环境下二者的确是一个语义单元。我个人觉得从label出发定义一个唯一的URI本身就不是完备、合理的，一个语义单元的各类label都应该关联到一个ID中，包括正式的“别名”也应该是一个rdfs:label。另外，许多属性本身可能以一个匿名结点存在更为合理，比如欧美明星的“妻子”这个属性，很多情况下，这个属性可能会包括具体是谁、第几任、时间范围，单纯依靠label定义这类匿名属性似乎不太容易。

对于知识图谱的初衷——“机器可读”而言，数字ID并无太大问题；另一方面就是用户阅读的问题，基于数字ID的URI对于用户的可读性太差，当然在DB中同样存在这个问题，其解决思路也类似：

结果展示可以直接展示rdfs:label结果，对于用户阅读来说，uri似乎没有很大的价值；写SPARQL Query时一种可行的思路是知识图谱发布者提供一个从label索引ID的接口，比如我们在写一个属性的URI时，当键入类似“\property_with_label{外文}”时，应给出label包括该字段的所有属性URI，同时对每个属性有一个简单的预览，类似于我们在写latex的时候，添加一个引用：（当然在大规模知识图谱中可能会存在很多索引相关的工作来提高效率）

2. 关于Schema复用和Linking
   以知识图谱目前的发展现状和面向应用的不同需求，我觉得各个知识图谱发布者势必会保留自己的Schema。目前看只有发布者有内部需求，才会考虑去复用其他schema或者提供linking自身schema的API。这个问题在openKG中感觉只能对发布者提出一定的规范要求，才有可能比较好的解决。