Archive

作者存档

本博客转移到blog.baojie.org

2013/02/10 留下评论

请移步 http://blog.baojie.org/

以前在这个里发布的所有内容已转移到新博客空间

分类:流水帐

小可人儿妞妞

2012/12/13 留下评论

妞妞快三岁了。近期一些言论如下

1) 妞:爸爸你还没下班吗?你快回来吧,我想你抱我

2) 妞:爸爸给你吃

爸:为什么啊

妞:因为我喜欢你啊。我们是好朋友

3)妞(看电视):我不要老鼠(摆手),我要黑猫警长。黑猫警长是我的好朋友

4)妞:丫丫妹妹不要哭,姐姐帮你找牙齿

5)妞:我要吃棒棒糖!

妈:好,但只能吃一下。吃多了牙齿会长黑虫

妞(舔了几分钟):好了,我吃好了,你给我没收了吧

爸:妞妞这么乖啊

妞:我说了只吃一点点的

6)妞(看到抽屉里的蜡烛):等我过生日了,妈妈要给我买蛋糕,然后你们唱歌,然后我就吹蜡烛

爸:妈妈也要过生日了,要不要给妈妈买蛋糕?

妞:要啊。(唱)祝你生日妞妈,祝你生日妞妈…

爸:唱错啦,是祝你生日快乐

妞:没有错啊,妞妞和妈妈都要过生日(所以是“祝你生日妞、妈”)

7)爸爸站在椅子上挂墙钟。妞:爸爸要小心,不要掉下来了

8)爸爸下班回家都要和妞妞抱一抱,妞妞一般就粘在爸爸身上不肯下来。妈妈和妞妞说,应该让爸爸先吃饭。前天爸爸回家,妞妞:爸爸,你先吃饭吧,吃完了再抱我

9) 妞:你很乖,妞妞老师给你一个sticker

分类:妞妞

关于Graph Database的微博汇总

2012/12/03 留下评论

2012年4月到12月间一些关于Graph Database微博的汇总

http://www.weibo.com/xiguadawanzitang/profile?is_tag=1&tag_name=GraphDB

OWL推理一个思路是通过hypertableau,做模型构造。另一个思路是作为图论问题,通过图的
构造,最大化可并行性任务(如“或”)。在推理任务的另一端,简单如 semantic wiki的推理,我们
也发现推理的所有任务都可以归结到图的路径计算。http://t.cn/zjVMZsw 用图数据库做语义网的
数据平台是很自然的

我个人最喜欢OrientDB,知识建模灵活,内置推理,查询语法易懂。唯一的问题是那个公司太
小,还没有证明自己的稳定性,用的人很少。Titan如果发展好了,很有希望,阵容很强大,但
是现在还早了点。Neo4j用的人最多,不过能力最弱//@卢小东-知识梳理: 如果要兼顾语义知识
库管理的难度,不知道哪个更适合?

另外,图数据库往往和其他数据库结合,做多级存储,获得性能和表达力的折衷。其实数据库
的大部分并不需要图查询。搞大点的内存,用内存模式跑图数据库,持久化非图结构数据到其
他,比如mongodb或elastic aearh//@SiDT:使用Neo4j,规模大了,性能会有问题。ID不能指定,
有其他更好推荐吗

回复@SiDT:看你的规模有多大。几十万用户的话,做适当的数据分割,neo4j应该可以拿下。
orientdb的并行版本应该也可以。Titan并行支持最好,在cassandra和hbase上都能跑;不过太
新,文档不全,各种编程接口也很初级 //@SiDT:使用Neo4j,规模大了,性能会有问题。ID不能
指定,有其他更好推荐吗

关联图数据库和elastic search。甚至可能用gremlin或类似orientdb sql的语言直接检索索引
//@SiDT:存取和关系计算是强项,但检索是难点,有好的方案么

图数据库比语义数据库好的四个原因 1 构造更简单,对字符串更友好,避免过早优化 2 对大规
模并行支持好,有现成的解决方案 3 工具系统集成好,json数据交换 4 本身支持sparql甚至推
理,所以相对语义数据库并没失去什么

回复@个体小知: pregel和hama之类,表达力有限,一般适合传统图论操作,和titan, orientdb,
neo4j这种图形数据库比,上面还要再包装一层属性图查询语言才能好用。但是这种包装现在还
没有。Titan在大规模分布式上已经做得很好了 //@个体小知:所以适合不大不小,夹在中间的公
司使用

在各种图数据库里,Titan是个新生,不过貌似潜力惊人 http://t.cn/zlboiMo 。作者Marko
Rodriguez就是图数据库标准Blueprint的奠基人

其实在这个三个里面, OrientDB算是最容易用的,。pregel现在支持硬盘模式吗?对小公
司,prege,hama这些都有点重了。 //@个体小知: 貌似是夹在中间,论成熟文档易上手不如
neo4j,论性能强大灵活不如pregel

OrientDB文档通读了一遍。几个感想1) 比Neo4j灵活,强大,但是文档不够全,bug不知道会不
会多 2) 貌似比neo4j更能支持cluster,节点自动组网,每节点可以每秒15万条插入,100万用户
以下应该都够用 3) 适合不懂语义、图DB,只懂SQL的程序员来学习 4) 内置推理,连推理机都
不用了。 5)SPARQL可以去死了

RDF数据库由于三元组的无组织性(organization, context),索引结构不免复杂和冗余。同样规模
的数据,triple store和图数据库比,磁盘空间消耗常大10倍,相应的I/O和网络消耗都大,性能
上不能满足需求也就可以理解了

数据冗余和实时一致性在Web应用中通常都不是问题。在数据源分布、用户行为被验证之前就
明确(符合第三范式的)数据schema本质上是一种过早优化。RDF引入schema,特别是OWL,
是推理的过早优化。图数据库则把存储结构和推理变成逐步验证的过程,优化用户需要部分,
很适合lean startup的原则

RB+-tree在图形数据库中做索引,做局域索引,据说上可以和图本身的大小无关。很神奇

Web 1.0的模型是普通图。Web 3.0的模型可能是属性图(Property Graph)。肯定不是RDF Graph

其实RDF1.1努力的方向就是把RDF变得更像一个图数据库(graph database)语言。那为何不直接
用图数据库呢?工程的稳定性还更好些。Freebase底层就是图数据库

到底是OrientDB好呢,还是neo4j好?纠结,纠结

不允许字符串做主语subject是RDF让人很不爽的一个地方。有这限制是为了模型论语义——这
是整个W3C体系的一个问题: 工程的方便性让位于模型论语义的精确性。在RDF OWL RIF
SPARQL里我们反复看到这个主题。这大概是非W3C的graph database后来居上的原因吧

RDF用URL做节点和关系的名字困惑了很多人。很多场合下,没必要精确到URL这个级别,字符
串就很好了。Property graph在这点上比RDF GRAPH方便很多

什么是图形数据库? 本质上是分布式索引。

最近在看Graph Database, 不禁想,搞这个的,其实也就是一小群hacker,和美国欧洲各大学校
+公司+W3C不能比,结果两三年的功夫,把多少亿美元投入、成千上万的研究人员、上十个工
作组在“语义网”上的工作生生得给比下去了。什么叫实事求是的力量啊,这就是

例证:http://t.cn/zOKYqXR 在Google Insights里,neo4j一家就单挑triple store和SPARQL了。

Blueprint技术堆栈比语义网的W3C蛋糕模型看起来要靠谱得多。 http://t.cn/zOKYPma 现在用
Blueprint方案数据库的用户(比如neo4j)要远远多于RDF triple store。这还只是多种非W3C路
线的语义网解决方案的一种。

更正:Neo4j的商业版本也要2.4万美元一年(或者AGPL,最严格的开源协议)。我一开始以为
是免费的。

从web到semantic web,从数学上讲不过是从single relation graph到multi-relation graph。可这么
一个”简单”的进步,在工程上大概要花30年才能完全实现。这个世界的进步,并没有想象的那
么快

纯nerdness:Gremlin是一个图灵机完备的查询语言。从表达力上讲,啥都可以说。定义个
SPARQL到Gremlin的转化理论上是可以做到的。所以所有的graph database都是SPARQL-ready

RDF Virtual Machine by Marko A. Rodriguez http://t.cn/zOK7kFT 有点意思。这位老哥是图形数据
库的主要人物之一,Germlin的发明人。

语义网的数据库也该考虑支持支持Gremlin

Neo4j让我特别满意的一点是支持SPARQL。这样RDF数据库的灵活性和图数据库的强大性都有
了。AllegroGraph也可以同时做到这两点,就是商业版本贵点。

开始:忍受不了RDB僵硬的表结构=>使用键,值数据库;发现完全没有结构也不好=>使用文档数
据库;发现文档结构其实也很讨厌,特别是没join => 使用图数据库;发现其实上述其实都是
图,但很快就有越来越多复杂的路径查询=>把这些查询写死在代码里;能不能不写死呢 =>恭
喜,您现在是语义网的程序员了

最近在看AffinityDB和Neo4j。这些都可以算W3C路线之外的语义网的实现方法。特别是
AffinityDB,真是该有的全有了,该没有的全没有

分类:语义网

Microdata, RDFa, 语义超摩尔定律

2012/11/28 留下评论

HTML Working Group和RDFa主席反对Microdata的文章: Objection to Microdata Candidate Recommendation

Microdata是schema.org的数据格式。几个有趣的论点:1)Microdata和RDFa基本重叠,而RDFa已经是标准 2)除了Google,几乎没有人用Microdata(<1%)。我的观点:其实,不是已经有JSON了?

Peter Mika和Tim Potter今年关于Web上元数据统计: Metadata Statistics for a Large Web Corpus

30%的网页有语义元数据。几个主要的元数据网站是Facebook, tabelog,venere, yahoo, tripadvisor(含中文网站daodao), answers, myspace。基本就是两个领域:交友和旅游。从数据总量看,Facebook和tripadvisor是两个最大的语义网上的公司

到2012年1月,搜索引擎可见的语义网的规模有多大?Peter Mika报告说:至少170亿三元组,其中10%由Facebook产生。17b数据,估计放在内存里也就几个T,在大数据里算是很小的数字

不过根据我的不完全统计,语义数据在最近5年的发展,大体上每年涨一个数量级,远超内存的增长——我称之为语义超摩尔定律。具体统计数字现在不在手上,以后补上。 估计三到五年后,语义数据的分析和使用将面临很大的大数据挑战。这都是高质量数据,不是打酱油数据,意义很大。

分类:语义网

语义网的高级语言

2012/11/27 留下评论

在谈论语义网的时候,要和RDF路线区分开来。

和一些人谈到语义网,他们说:“语义网死了”。如果从RDF的角度来说,是的——虽然W3C路线的支持者还不承认。

但是这种观点,就如同计算机在只有机器语言,没有高级语言的时候就断言:“计算机死了”。

我大胆提出两个假设

  • RDF是一门低级语言,只适合机器使用——如同机器语言或者汇编语言
  • 语义网需要一门高级语言,面向工程师(人),用来做大规模知识库的写作、重用

为什么说RDF是低级机器语言?

  • 用URL来寻址并不错。但是把精确寻址的任务交给人,要求人来设计URL,就如同在C编程中要求人对每个变量赋予内存地址。
  • RDF是一个“平坦”(flat)的语言,缺少内部的组织单元。有很多建议,引入诸如package, named graph这样的组织单元,但目前还没有达成共识或广泛采用。
  • RDF的语法,即使是Turtle,也没有可读性,理解和重用起来非常困难。
  • RDF缺少“宏”或者构造高层次组织的能力。其实SPARQL弥补了一点,就是graph pattern;一些语言如SPIN,把graph pattern作为可重用的单元,甚至可以生成新的数据。如果把这个能力作为RDF原生的能力就好了。

2010年RDF Working Group开预备会议,我也与会了。现在回来看,我那时的想法是错误的:为RDF引入更精确的语义,基于上下文(context)的组织和寻址,并不合适——虽然Pat Hayes后来很喜欢这个想法并在工作组内推一个类似的想法

RDF的问题不是逻辑太少了,而是逻辑太多了。

知识工程的问题往往是太多考虑机器的需要,而不太考虑人的需要。而知识工程的瓶颈,又恰恰在人而不在机器。

RDF 1.1现在的几个努力方向:JSON语法,Named Graph, Turtle Syntax,这些都是好的。但是还不够。我甚至怀疑,在RDF框架内能不能达到易用性的目的。

因为从一开始,RDF就被设计成machine understandable语言。这本是好的,至少在1999年。但是一个缺少高级语言的情况,就好像编程语言的早期。结果就是知识工程的人月神话。

现在的情况也很象Web发明的时候:在Internet上,TCP/IP是面向机器的低级语言,而HTML和URL是面向人的高级语言。我觉得,现在有一个强烈的需要来设计一个Semantic Web的高级语言。

这样的高级语言要有什么特征呢?我觉得大体有这样几点

  • 支持多粒度的知识/数据组织和重用
  • 用字符串而不是URL来寻址。不追求addressing uniqueness, 而是probable and eventual addressing uniqueness
  • 支持知识的分布式传输(按一定粒度)
  • 使用目前主流程序员熟悉的语法形式。
  • 尽可能少重新发明轮子——比如rdf:plainLiteral(我是作者之一)这样的字符串类型就没什么必要
  • 支持结构化和非结构化数据的混合表达(RDF有Literal,不过,那个太局限了)
  • 这个语言的文档不要提什么“语义”(有几个程序员关心SQL的语义?),不要规定什么schema
  • 把推理转化为图的操作或者编程语言内置的运算。在这之外的推理都先不考虑。
  • 从一开始就设计成在cluster上能运行的语言
  • 拜托,用程序员看的懂的语言和例子写文档。

其实这样的语言雏形的一些部分,在不同的技术平台上都已经自发出现了。语义维基,图数据库,新一代检索引擎,都包含了上述部分概念。有心人要做的,就是一个有机的组合。我想,在我写这一段的时候,大概已经有人开始做了。

P.S. 我甚至觉得,都没有必要引入一个新的高级语言语法,就在现有的某种贴近RDF的编程语言里,做少量的增加就能实现目的。最理想的就是Python。为什么这么说?JSON本身就是Python的数据结构。而几乎所有的数据API都吃JSON。Python的类与属性定义与关系就是RDF的翻版。

其实更合适的是Lisp。但是Lisp对抽象思维要求太高,社区又太小。做面向Web的开发,为了工程经济性(人力上的),还是Python比较合适。

分类:语义网, 流水帐

一个个人知识管理系统

2012/11/26 1条评论

今天看这篇文章:《个人提升方法三部曲:行动,记录、总结

过去这半年来,其实我一直在按这篇文章说的步骤来管理自己的知识。开发这个系统用了我大概一个月的业余时间,随时记录,每天生成总结。现在已经完全离不开它了。

基本技术路线:用semantic wiki做数据录入,用Python API(mwclient)做报表、分析。一点点自动化,每个知识点还是要人产生摘要,然后就可以用各种预先定义好的graph pattern推送到各个页面去。有一点点entity extraction,算是知识提取自动化。语义查询、检索、faceted browsing,可视化,支持知识的进化和重组。这些是知识管理的基本功能。半年多下来,大体每天能积累7-8个新的知识点,现在有上千个了。

知识就是一个点,一个点就是一句或者几句话。几个点可以组织在一个页面上,也可以通过查询流动到其他页面上。日历任务提醒现在已经做进去了,每天一个提醒邮件(当然也可以更频繁)。是一个Web应用,在浏览器里用。基本使用不需要编程。如果想定制,可以通过Python或者SMW

@Alisoncastle问:你的对于没知识体系的人来说适用吗。

适用。本来我的计划就是让知识能演化。每个点开始就是一句话,一个链接,一条微博。慢慢随着需要增长。增长的过程中结构出现。到一个知识点过大的时候就分裂成几个,通常是按其内部结构自然分割。然后到某个时候几个知识点需要汇总,就链在一起。并不需要一开始就有体系,体系是在发展中自然形成的。

链在一起主要还是靠人工。也可以预先写一个查询,满足某个条件的,比如提到某类词的(不是tagging),都汇总在一起。语义wiki这点还是很给力的。

@Alisoncastle又说: 我懒不喜欢人工,靠人工知识点多了后就一定会出问题 我就是多了后不知道该怎么并,于是就干脆不并。这是个很难的问题,如果能找到一些合理的自动规则,如同算法一般那就帅啦

我也没有好办法。要解决这个可能得开个公司专业搞。我觉得应可能的比例是60%统计+20%本体与NLP+20%启发式HCI。

目前组织大都还是手工,而且要求使用者自己有良好的记录习惯。我不管是看文章,开会还是写代码,潜意识里假设记下的每段话将来都可能长成新的知识点。但是妞妈就觉得这很别扭,还是用email管理方便

和Evernote比,界面当然不能比。主要的优势是每个知识点都有元数据(有一个很简单的表单),可以查询,可以用来做统计,生成图表,按日、按周做报表,提醒到期任务。可以让知识在页面之间流动,细粒度引用比较方便

当然现在还是太简陋了,界面惨不忍睹,只有绝对geek才能忍受。向妞妈推荐,被斥之以鼻。向周围一堆人推荐过了,几个项目里的合作伙伴,到现在没第二个人用。

开源问题:等我整理一下,建一个demo网站。可能要过一阵子

分类:编程, 语义网

通信的语法,语义和语用层次:一封推荐信

2012/11/22 留下评论

以前在研究“语义信息论”(Semantic Information Theory)的时候,涉及到通信的三个层次:技术的,语义的和效果的。这个层次划分是(Weaver 1949)说的。香农的传统信息论只涉及技术这个层面。

从语言学的角度,这三个层次可以大致对应于语言的语法Syntax、语义Semantics和语用Pragmatics三个层次

今天在看《语言本能》(The Language Instinct)这本书,里面举了个很有意思的例子,可以做这三个层次的范例

一封推荐信:

亲爱的平克教授:

我非常高兴能向你推荐厄文×史密斯先生。史密斯先生是一个模范学生。他衣着整齐,而且非常守时。我认识史密斯先生已经三年了,我觉得他在各方面都是最合作的人。他的太太很迷人。

真诚的约翰×琼斯教授

语法层面:用某种NLP工具,比如Stanford parser,可以分析句子结构。比如这样的语法树

(ROOT
  (IP
    (IP
      (NP
        (NP (NR 史密斯))
        (NP (NN 先生)))
      (VP (VC 是)
        (NP
          (QP (CD 一)
            (CLP (M 个)))
          (NP (NN 模范) (NN 学生)))))
    (PU 。)
    (IP
      (NP (PN 他))
      (VP
        (VP
          (ADVP (AD 衣着))
          (VP (VA 整齐)))
        (PU ,)
        (CC 而且)
        (VP
          (ADVP (AD 非常))
          (VP (VA 守时)))))
    (PU 。)))

语义层面:基于背景知识,我们知道史密斯先生是个男人,他已婚,他至少已经三岁了(呵呵)。所谓的语义信息论,就是不仅局限于句子本身出现的符号(如“先生”),而是把它们与未出现的符号(如”男人”)也关联起来,通过出现的符号来推导出未出现的符号的一些信息。

语用层面:琼斯教授在使坏,在说史密斯的坏话,虽然一个负面的词都没有用。因为推荐信理论上是要讲被推荐人的专业素养,琼斯教授只说了一堆不相干的话。在这个特定的通信实例里,其实有一个“封闭世界假设”:如果推荐人没有说到专业素养,那说明这个专业素养是不值得提的。这种语用的信息,是基于信源和信宿共用的背景知识(如文化)和一些约定的规范(如推荐信的内容)。一些特定的场合,语用应该也是可以数学描述或近似的。留待以后有空来捣捣浆糊。