在知识表示这三个层面上，从开始的命名到元组，到本体，我们都需要考虑这三个因素。
先讲命名的问题，这里要引用另外一位大师的话： 计算机科学里只有两个困难的事情：缓存失效和起名字 。
在做基于RDF的建模的时候，每一个实体和每个关系都用URI网址的方式命名，这种方式有好处也有坏处。跟它对应的是用字符串进行命名。用URI命名是高成本的方式，维护成本和构造成本都会比较高。字符串成本相对小一点。URI是一个全局的东西，URI是唯一的：因为它是唯一的，它也是全局的。所以在全球任何一个地方的浏览器的你都可以得到同样一个资源。字符串是多义的，也是上下文相关的。 “苹果”这个词在不同的context下面，它的意义是不一样的。URI是面向机器的，机器可读，人很难去记下来一个很长的URI。人是可以读字符串的。URI的好处是便于互联，所以linked open data强调用URI。字符串是难以互联的。另外还有一点是政治上的考虑，每一个URI都是有主人的，因为它有一个domain(域名)，每一个domain都是有组织或者个人去拥有它的，字符串没有主人，要相对自由一些。
所以在怎么去对资源进行命名的问题上面，我们要综合考虑。很多情况下可能URI是一种过早的优化，如果我们能够用字符串保持尽可能长的时间，会降低我们的构造成本。URI的另外一个问题就是它承载了两个功能，一个就是命名(Naming)，还有一个就是寻址(Addressing)。命名一个资源然后找到一个资源，其实这两件事情相互之间是冲突的。
最近我在看一篇文章，叫Reference by Description，知识图谱之父Guha写的，他提出来一个解决方案，之前我也想到过类似的这种方法，牺牲命名的一致性。有时候允许我们犯一点点错误，也许我们找URI、找一个资源找错了，但是因为我们牺牲了这个唯一性，我们获得了系统构造成本的极大降低和可维护性的极大提高。其实这也是当年NoSQL兴起的时候的一个想法，因为以前数据库里我想要强一致性，就带来很多问题;NoSQL兴起以后，我们不要强一致性，只要最终一致性(Eventual Consistency)，也行。所以我觉得现在从URI往前走，可能到另外一种新的知识表示的方法。这种牺牲URI，牺牲这个一致性，来换取工程上的极大的好处，这个很值得去看一看。
第二点就是元组，我们有了实体之后，我们把实体关联在一起，形成一个结构。我们最常用的就是主语-谓语-宾语(s p o)这种结构，我们把它称为一个三元组，就是RDF或者现在的知识图谱大家都经常用的。但是长期以来我们知道，三元组非常难以表达定语、状语和补语。林老师早上提到了这个Marriage建模，我为什么不直接说张三和李四的关系呢，然后非要构造Marriage这个关系，因为Marriage它有一个时间的这个状语，就是说什么时间到什么时间。我们在传统的这种建模里面，为了表达三元组以上的东西，这个四元组、五元组的话，我们会用reification，这种奇技淫巧，这种东西会极大地降低我们的知识库的可维护性和可读性。所以我称 三元组是尼安德特人的语言 。这什么意思?我们在座的都是智人，如果有尼安德特人举个手——感觉没有 :D。为什么呢?因为他们被我们吃掉了。语言学家有一个假说，为什么我们智人会把尼安德特人给消灭掉?尼安德特人其实也有语言，也有宗教什么都有。但他们的语言有一种本质的缺陷，他基本上只能说主语谓语宾语。我们”清华打北大“，他可以说这句话对吧。但是我们智人可以说得更完美，说我们”清华的学生，我们明天早上8点钟，每人带根棍子，到北大去“。这样的语言，是尼安德特人没有办法说的，因为是超出主语谓语宾语。所以RDF是尼安德特人的语言，也是为什么我们智人用它非常地别扭。
可能的另外一种解决方案我认为是JSON，特别是现在有了JSON-LD，融合了JSON和RDF的优点，部分地弥补了他们的缺点，形成了一个在表达力和可读性、可维护性之间的一个折衷。这个东西也是刚刚开始兴起，本身它还有很多不足的地方，也还没有成为一个特别被广泛应用和支持的格式。但是我认为这是一个方向。还有就是一些Document Graph Database，就是能够支持JSON的图数据库，我认为值得看一看的。因为它可以有效地降低输入输出的成本和理解的成本，而且我们又可以获得图数据库的各种各样的优势。比如OrientDB就支持这种。这些数据库比较新，也有种种问题，我并不推荐大家在生产系统中用。但我觉得很值得去探索一下。也可能有其他的解决方案，在后面我也会继续提到。