Archive

Archive for the ‘语义网’ Category

关于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,真是该有的全有了,该没有的全没有

Advertisements
分类:语义网

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网站。可能要过一阵子

分类:编程, 语义网

语义网是NonRDF: not only RDF

2012/09/14 1条评论

为什么会有人认为仅仅做个d2rq,rdf就能解决关系数据库不能解决的问题呢? 这种对rdf的迷信,恰恰是语义网迄今普及不利的原因。技术之间的竞争,往往不仅是能力的竞争,而是整个工具系统之间的竞争。语义网的rdf阵营,在工具系统上的劣势,不是几年能弥补上的

过高的期望自然导致失望。语义网的核心是结构化数据,高质量结构化数据,可以产生新数据的高质量数据(即推理)。在从其它格式到rdf的转换中,如果没有数据质量的提升,就期望解决诸如数据集成,语义理解之类的问题,那很典型的,一年以后项目就被砍掉或死撑。

工具系统的竞争,是一个复杂的系统工程,绝不是一个标准化组织能组织和规划的。而工具的产生和演进,又是和用户与工程师的需求,理解能力和使用习惯密切相关的。基于w3c规范的工具系统,往往有太浓厚的学术性,不太贴合普通web工程师的需求。其实广义上讲,语义网已经是现实了: 大家不都用json吗?

分类:语义网

语义网与HCI

2012/06/02 1条评论

胡乱写几句。不列推理过程,不列参考文献

貌似资本市场已经开始炒知识Web这个方向了。诸位语义网同仁的马甲大概快可以扒下来了

在今后1-2年内,语义网技术推向大众市场(企业市场和专有领域是另一会事),机会在哪里?我以为其一是智能界面,一些全新的服务形式。或许是,或许不是对现有服务,如搜索和社交网络,的扩展。更有可能不是。

Siri是一种,但不是唯一的一种。Tom Gruber说Intelligence at Interface (I@I),语音个人代理只是一种表现形式。

知识管理是所有人都需要的任务,是一个比现有的搜索更大的市场。现有的技术其实可以满足大多数人的需要,但是需要界面做一些paradigm shift。做一个每个人(很忙的,很闲的;男的,女的;要找饮食的,要找男女的)都需要的Evernote。

没有鼠标就没有Web。

没有表单就没有Social Web。

没有触摸屏就没有Mobile Web。

没有X就没有Semantic Web。这个X不是Siri,或者不仅是Siri。

考之于Web,Wiki,Facebbook的发明,X的产生大概也不需要火箭科技,可能就是对现有技术的工程组合,一两个人年的工作。

下一个GOOG或者FB,大概已经或者即将,在X方向上产生。

如果现在还在犹豫的,2013年再做的,就已经太晚了。

分类:语义网

语义网相关文章:一年汇总

2012/04/16 1条评论

今天整理了一下过去一年写的和语义网相关的一些博文。分类如下

为什么最近写的少了?两个原因

  • 最近3个月太忙,基本没有时间写长文;各种短的火花,都写在微博上了
  • 条条框框很多,带着脚镣跳舞,还不如不写
里面有些文章是坑。很抱歉,估计一时半会是填不了了。

目录

  • 1 形而上学
    • 1.1 旧讨论贴
    • 1.2 旧英文贴
    • 1.3 反思
    • 1.4 产业评论
    • 1.5 新思维
    • 1.6 新思维2
  • 2 工程实践
    • 2.1 问答系统
    • 2.2 会议元数据
    • 2.3 其他应用
    • 2.4 语义网语言
  • 3 产业化
    • 3.1 语义网的公司
    • 3.2 创业
  • 4 个人研究
    • 4.1 描述逻辑
    • 4.2 Context
    • 4.3 域态逻辑
    • 4.4 语义信息论
    • 4.5 语义维基
    • 4.6 Web Science
    • 4.7 咬文嚼字
    • 4.8 胡思乱想
  • 5 杂谈
    • 5.1 入门与普及
    • 5.2 八卦
    • 5.3 活动
    • 5.4 其他

1 形而上学

旧讨论贴

旧英文贴

反思

产业评论

新思维

新思维2

(暂时保护中)

2 工程实践

问答系统

会议元数据

其他应用

语义网语言

3 产业化

语义网的公司

创业

4 个人研究

描述逻辑

Context

域态逻辑

语义信息论

语义维基

Web Science

咬文嚼字

胡思乱想

5 杂谈

入门与普及

八卦

活动

其他