一个数据创业的小公司

今天去一个很有特色的小公司访问。本来想写一个长一点的,但没时间了,就随便写几句。小公司的ceo以前还开了一家,被大公司买了,非常成功,反正是一个 家喻户晓的成功产品。在大公司干了几年,想实现自己的理念,认为数据应该人人都可访问,就跳出来开了这家公司。又支持了几个开源项目也是这个理念。

小公司的ceo且称为A, 乍一看根本不象个亿万富翁,就和个数学系的研究生似的,和我们见面仿佛见教授的那种眼神。然后自我介绍,非常低调,说我上一个公司,也不知道自己能做什么,反正搞搞数学,试试。现在这家,也是想试试。压根就不提被大公司收购,挣了几亿刀的事。

开始他说他不搞lean startup, 先蒙头开发了两年。我问,你哪里来这么大的信心,就一定有人用你的产品。A说,其实开始我们也不清楚,捣鼓了很多各种数据。直到三年以后,有某大公司来找 我们,说喜欢某某数据,我们才发现市场在哪里。所以最后我们还是lean startup了。这个回答很诚实,很中肯。大赞

A的团队看起来很不错。一个产品主管一看就是个很有想法也了解技术的人,并不对CEO人云亦云。而CEO对平等的讨论看起来也非常习惯,想必日常就是这 样,思想碰撞,火花四射。营销主管也是个很聪明的人,知道怎么帮话,烘托气氛,又不喧宾夺主。低调的ceo加上有活力的中层,是公司能发展的良好兆头

还要赞一下小公司的办公室,沿着墙一周全是白板,几十米长。上面还有没擦掉的公式。此外整个布局就象一个家,有个晚餐桌,很舒服。

再八一句关于数据。A的公司是硅谷风起云涌的数据创业的一个代表。高质量数据,高可获得性数据,深加工的数据,其实不是什么大数据,一个手机都能装下。可 是这样的数据四两拨千斤,能把千万倍自身的其他数据增值。与其盲目地搞大数据,不如搞搞这样的小数据。莎士比亚全集才5M,可它的意义呢?

补充一下:怎么拿数据创业?现在的社交网络处于过服务状态,带来两个契机:一是利用产业需要模块化专业化的自然趋势,做好某区段或垂直市场的数据精加工。 另一个是利用服务过剩,推出针对低端或游离市场之外用户的精简产品。两者能做好的核心又都是建立自己的价值体系,不和大的数据提供商打阵地战

语义网不需要描述逻辑

写这个是因为被问到,为什么给描述逻辑,比如SHOIQ,加这个那个操作符,对于语义网的会议,在我看来是没有意义的事。

从接触描述逻辑(Description Logic, DL)到现在有差不多10年了,博士论文就是做描述逻辑。又在OWL Working Group工作一段时间,对描述逻辑还算是比较熟悉的。作为知识表现的工具,DL在某些领域是有价值的,特别是医疗等。但越深入了解这个工具,越觉得它对于语义网这个应用领域没有实际意义,是屠龙之技。

龙不存在嘛!

具体说,是三种复杂性。这三种复杂性决定了描述逻辑(其实任何一种稍微复杂的逻辑)在Web上目前很难被应用。

第一种复杂性是计算复杂性(Computational Complexity)。这个其实是DL研究界很熟悉的问题。本来DL的产生就是为了解决一阶逻辑的复杂性和不可判定性,作为一阶逻辑的一个可判定的子集而存在。可是到了OWL(SHOIN)和OWL2 (SROIQ),推理算法的复杂性达到了N2ExpTime (非确定二阶指数时间),这根本就没有实战意义了。OWL2里推出三个Profiles,可以做PTime(多项式时间)推理,想拿这个做卖点。可是你要在Web上用,多项式时间是远远不够的。当然,可以再简化简化,简化到某个LogTime, LogSpace,或 NLogSpace(比如Semantic MediaWiki)的子集。不过对那些子集,已经不能称为DL了。

第二种复杂性是工程复杂性(Engineering Complexity)。Web的特点是数据量极其巨大,几千台机器一起跑跟玩似的(Google里调用两千台服务器以下都不用审批的)。这么大的数据量,就是LogTime的算法也很难做到实时响应,各种分片,各种索引,各种缓存,各种并发,大数据各种工具,真是车载斗量。不要说描述逻辑,就是简单的为TF-IDF加上同义词关系和上下位概念关系,所需要的索引量就要大一个数量级——所以Google到现在不还没有支持这些在逻辑界看来简单到不能再简单的推理?更为复杂的推理,比如关系的包含,关系的复合,强逻辑非,势(cardinality),那需要的索引(不管是数据库索引还是搜索索引)都是天文数字,现在的工程平台一是办不到,二是不经济。很多搞逻辑的不写代码,也不参与工业实践,很难体会到工业界要规模化哪怕极小的语义关系(比如分类树)所面临的实际困难。

第三种复杂性是认知复杂性(Cognitive Complexity)。逻辑要能工作,对数据质量的要求极其得高,比数据库的要求高得多。产生高质量数据是一个昂贵的过程,产生一个triple人工操作要40美元,更贵的也不少见。我熟悉的一个项目,一个公理axiom或者模板template,要150美元或更多。这都是为了保证数据质量,要专家的缘故。那不用专家呢?各种collective intelligence的方法。很不幸,人一多,数据质量一定下降,各种混乱和不一致一定产生。普通Web 用户,连最基本的两个知识组织方法:给东西起名字(naming),把东西分类(classification),都搞不好。不信去看任何大一点的tagging系统,里面的概念混乱可以叫有逻辑洁癖的人抓狂。我在RPI的时候曾经做过一个有40个大学生参加的知识建模试验,把一群主要是计算机专业的本科生训练了6个小时,可是到最后还是很多人连最基本的concept和property的区别都无法实践。现实的Web上的数据质量,搞搞搜索还可以,拿来搞逻辑推理,根本没有实际意义。

上面说的所有问题,学术界都是认识到的,各种研究非常多。但是能成熟到被Web工业界使用的阶段,我估计2020年之前都很困难。当然其他领域还是需要逻辑的,我写这些并不是否定逻辑的价值。

瘦语义网的几点想法

2013-01-31 增补:整理了一个《Lean Semantic Web讲义提纲》, 提纲全文在Github上。

这一年多来在工业界的实践,我总结经验和教训为“瘦语义网”(Lean Semantic Web)。

顾名思义,这个说法是从“Lean Startup”(精益创业)引申出来的,或者说是Lean Startup在Semantic Web上的应用。所以Lean Semantic Web最合适的翻译还是“精益语义网”。不过“瘦”听起来简单点,就先这么叫吧。

leansemanticweb.com是今后系统总结这个概念的地方。现在还没有什么内容,等以后自由时间多了再去填坑吧。

这里只能简单的总结几点原则问题。

瘦的意思并不只是更简单、简化现有的语义网技术。它的核心思想是Making things people want,也就是为人民服务。(参前文《语义网是给人用的》2011-12-20)

人民不仅包括用户,也包括为用户服务的工程师们。语义技术不是万灵药,不是人工智能的什么突破,也不是从天上掉下来的。好的市场和技术都是演化出来的,很少是突然的革命。如何让开发和使用这个技术最符合工程师和用户的需要,如何从现实基础演化,是语义网的最关键问题。

由此引申一些想法。

首先是用户和市场的一些想法

a.  目前结构化数据,特别是高质量图结构的数据已经成为提升用户体验的核心问题

  • 机器学习的方法无法再深入提供结构化数据所能提供的效用。

b.  智能技术在过去的成功主要是做加法(提供给用户更多的内容,如推荐和广告)。语义网的优势在做减法

  • 拿语义网技术来接着做加法,如Knowledge Graph和Graph Search,是传统Web厂商的价值体系决定的。改变这种价值体系需要很长时间。

c. 在语义网上实现突破的必然是小公司(The Next Big Thing)。现有的大公司很难服务好早期核心用户。

  • 早期的语义应用按传统价值体系来衡量性能是下降的。需要切入一个对新价值系统敏感的早期核心用户市场。
  • 大公司内部的政治结构不利于语义网技术的采用。
  • 快速验证用户需要只能由小公司来完成

d. 语义技术的突破点看似不会在继续深化社交网络(social network)这种关系上,虽然这个还很热。信息网络(information network)是个高质量数据更丰富的世界。

  • 语义网的早期核心用户可能在不活跃使用Facebook的那个人群中

e. 语义数据到目前为止还都是小数据。市场潜力最大的是小而高质量数据的集合。不要迷失在大数据的各种buzz和hype里。

  • 兵贵精而不贵多,数据也一样。认为自己数据多就能投鞭断流,是幻想。

其次是技术上的一些想法

1. 语义就是关系,知识是用来发现新关系的数据。语义数据的核心问题是数据质量。知识是数据中质量较高的部分。

  • 当前最成熟的关系表示工具是图(Graph)。树(Tree)和文档(Document)是图的特例
  • 推理是图上的运算,是添加新边和新节点的方法。

2. 实践中的语义网是NonRDF: Not-only RDF。不要拘泥于RDF这种交换格式和它的种种变化(如RDFa, Microformat)

  • 对RDF的迷信是现实扭曲力场(Reality Distortion Field)。这种迷信往往导致对迷信的失望从而否定语义技术——那也同样是一个现实扭曲力场。
  • 把其他格式数据转化为RDF而不做质量提升的工作,不能解决垃圾进,垃圾出的问题。这就是我认为LOD和开放政府数据中相当部分其实无工程意义的原因。

3. 目前阶段最有工程基础的语义数据交换格式是JSON。数据交换格式和数据存储格式可以分离。

  • 即使交换格式使用RDF,并不需要在内部存储中使用triple store
  • NLP, ML, IR, Database, Reasoner都适用这个原则

4. URI做资源寻址方式是昂贵和不符合用户需要的。字符串在大多数情况满足大多数用户的需要。

  • URI命名的成本不足以justify它带来的定位唯一性的好处。何况唯一性在Web应用中并不总是重要问题
  • HTTP URI是结果而不是原因。不要对LOD产生迷信,或教条理解TBL说的四个原则。事实是,LOD虽然已经简化了,但对工业规模化还远远不够。

5. 凡是不能做到(用户感知到的)常数时间响应的系统都是胡扯

  • OWL 2 profile所设计的多项式时间子集没有在Web上的实践意义。
  • 其实整个OWL都没有Web上的实践意义。
  • 常数时间响应是通过大规模索引,大规模分布式数据分片、计算分片来实现的。

6. 语义网技术并不是单一的数据交换格式和查询。完整的应用系统,几乎都要包括自然语言处理,信息检索,结构化数据存储,结构化数据查询,数据质量的提升,隐含关系的发现(机器学习或推理),探索或启发式用户界面等模块的集成。

  • 没有单一方法能解决语义网面临的问题。做有价值的系统集成是现实选择。在微观技术(如名词提取)和宏观技术(如语义搜索)层面上都是如此。
  • 深入理解现有系统(如数据库和全文索引)对图结构化数据支持的瓶颈有利于理解语义网技术的局限和现实可行范围。

7. 现阶段能规模化的语义关系很浅,只有同义关系、分类树关系、传递关系(transitive property),至多加上路径查询(path query)。这是数据库和信息检索的基础设施决定的。先规模化这些关系,循序渐进才能处理更多的关系

8. 弱耦合的系统构架。尽可能重用现有成熟技术。尽可能利用好云计算基础设施

  • 现有的学院派语义网研究很少满足这个要求。LarKC也和工业界要求差距很远。
  • 强耦合的,Cluster的模式,如YarcData的uRiKA,适用于大企业市场,也就是SEMANTIC web市场,而不是更广阔的semantic WEB市场
  • 多层次模块化(hierarchical modularization  )

9. 懒(lazy)系统. Just-in-time knowledge, just-in-time computation, pay-as-you-go benefit,减少初始投资要求

  • 懒的核心思想是减少浪费。
  • 相关概念是lean(精益)和agile(敏捷)
  • 局域化
  • 允许系统的快速演进。减少传统知识工程中的鸡生蛋,蛋生鸡的建模问题。

10. 工具系统建设是瓶颈。成熟好用的NonRDF语义网工具生态系统可能还需要5-10年的建设时间。

  • 现阶段要不耻于写小工具,写各种插件。少发明轮子,多改进轮子。
  • 特别是用好现有语言和它们的工具,比如Python和Javascript。(参《语义网的高级语言》2012-11-27)

先就抛砖引玉胡说这几句,求教于方家。

Facebook Graph Search笔记

摘抄了一些新闻。尽可能过滤buzz, hype和口水

2013-02-16: 根据Reddit访谈增补了内容: Unicorn, Query Syntax, Question Understanding (NLP)

Source

Facebook’s Bold, Compelling and Scary Engine of Discovery: The Inside Story of Graph Search

中文翻译:Facebook社交搜索Graph Search的幕后故事

Under the Hood: Building Graph Search Beta

Facebook Graph Search: https://www.facebook.com/about/graphsearch

A really tiny explanation of how Facebook’s Graph Search works

What

成为一款发现工具

利用庞大的结构化数据库开发一个完全不同的搜索引擎,从而带来巨大价值

扎克伯格表示:“我最喜爱的搜索关键词与招聘有关。我们可以尝试查找Facebook工程师在谷歌的工程师朋友。

斯托基随后尝试了一个查询请求——“住在我附近的单身女性。”

随后,他们又展示了推荐功能.如果你来到任何一个城市,都可以向好友或好友的好友征求美食建议。还可以向那些自称美食达人或专业厨师的人寻求建议。你甚至可以随意搜索各种有趣的信息,例如:喜欢米特•罗姆尼(Mit Romney)的人都喜欢看哪些书。

If it fails, it might refer people to Bing

History

在发布之初,Graph Search仅面向一小部分用户开放。扎克伯格认为,到面向全球上亿用户全面开放时,Graph Search将得到极大的改进

Graph Search的开发从2011年春季开始

Toward the end of summer 2012, Graph Search was starting to take shape.

Released on 2013-01-15

Who

http://www.linkedin.com/pub/lars-rasmussen/5/519/16

Lars Rasmussen。以前在Google

  • 成功的项目是谷歌地图
  • 失败的项目是Google Wave (2500万美元和60名工程师)

http://www.linkedin.com/in/tomstocky

2011年夏季,拉斯姆森的项目有了一名合作领导者汤姆•斯托吉(Tom Stocky)

这一项目共有50名工程师,其中包括两名语言学家,负责让搜索引擎理解人类语言。

facebook graph search team

照片里一共73个人。印度人很多

但是据说核心团队不大,不超过10个人

How

2011年夏季 扎克伯格当时的反应是:“不可能。你可以输入任何希望的关键词,而标题中含有这一关键词的页面将弹出。无人能使自然语言以这种方式工作,或编目所有这些内容。在Facebook上有超过1万亿个用户关系。编目所有这些关系并使其提供服务将是一个巨大的技术挑战。”

为了形成足够复杂的搜索关键词,Facebook会猜测用户试图搜索的信息

Challenge number one: scale. More than 1 billion people use Facebook each month, they have shared more than 240 billion photos on the site, and formed more that 1 trillion connections of thousands of different types

Secondly, we owned too much code running too many services already.

But we needed the system also to find answers more than a single connection away, such as “restaurants liked by my friends from India.” Here we were in luck: one of our three existing systems, Unicorn, was designed exactly with this in mind.

two-stage approach:

  • first build out Unicorn to manage all the existing search experiences on the site
  • and then, build out Unicorn further to meet all the requirements of Graph Search

At a very rudimentary level, Rasmussen in a call later explained that when we type a query, say, “Restaurants liked by my friends from India in San Francisco,”

  • an aggregator tool using natural language processing takes the query and parses it into keywords
  • against which searches are conducted. So “Restaurants,” “San Francisco,” and “Friends from India” become queries
  • whose results are fetched and further sorted to give us the final answer.

A big infrastructure challenge. Want to keep the latency to below two seconds

Unicorn

Unicorn是什么?貌似网上没有公开资料

Quora上有人在问:What exactly is Facebook Unicorn?  目前还没有答案

2013-01-19 Aditya Tayade and Tudor Bosman在Quora上回答

Aditya: With S-expressions you can traverse the graph to multiple depths in one shot. For example you can query for something like — a list of all the fans of all the pages that your FoFs have liked, and so on.

Tudor: I wrote a large fraction of the Unicorn code.  Unicorn processes queries that select a section of the social graph.  Unicorn is essentially built like a standard search engine that maps terms to sets of documents; unlike a text search engine, the terms aren’t words, but connections in the social graph (for example, “friend:4″ maps to the ids of all users who are friends with the user with id 4; we have similar terms for “photos taken by user id 4″, “users who like page with id 25″ etc).

2013-02-15 Mike Curtiss from Facebook’s search infrastructure said on Reddit

We have an inverted-index system called Unicorn that we use to select nodes in the social graph based on edge-relationships to other nodes. Unicorn is akin to document search systems for other contexts like email, webpages, or files on your computer; but it also has some graph-centric features that make it especially useful for searching over the social graph. For example, we don’t index the lists of friends-of-friends for every user (friends only), but our system makes it possible to retrieve friends-of-friends by executing a single query.

Just like the rest of Facebook, we try to use (and contribute to) open source technology when possible. So we use Hadoop in our pipeline for building search indices.

Writes Soren Lassen, who heads up he search infrastructure team:

We use a combination of Hive, Hadoop, and HBase to convert database contents into an inverted “base” index on a regular basis, and then we send messages to the index servers with realtime updates to the base index.

Query Syntax

The are 3 level of query languages in Graph Search.

  • The natural language that users type into the search field,
  • a semantic language that describes our interpretation of the natural language,
  • and then further down in the stack we use an s-expression syntax to retrive potential results from an inverted index.

For example, if you look for

My friends who live in Sydney, Australia

the corresponding semantic is

intersect(friends(me), residents(110884905606108)),

where 110884905606108 of course is a unique id for Sydney, Australia. You can see the expression in the result page URLs, encoded in a reverse-polish style:

https://www.facebook.com/search/110884905606108/residents/me/friends/intersect

The corresponding s-expression looks roughly like this:

(and friend:767560056 city_to_user:110884905606108)

Where 767560056 is my unique id. In practice, we often re-write the s-expression several times to a sometimes much more complex one that make retrieval more efficient.

Question Understanding

see  LarsRasmussen on Reddit 2013-02-16

  • At the core of the system sits a Context-Free Grammar
  • a Parser attempts to find the queries from the grammar that most closely matches
  • Part of the parsing involves searching for people and entities
  • When the user clicks one of the suggested queries, we proceed to resolve the corresponding semantic.here are three steps to this part: 1) we retrive candidate answers from an inverted index (http://en.wikipedia.org/wiki/Inverted_index), then we 2) filter out anything the searcher does not have access to, and finally we 3) order them according to a great many criteria in the way we think is most interesting to the searcher.
  • Lastly, we display the results.

Graph Database?

They don’t use, e.g., Neo4j or Titan permalink

Market Impact

Yelp股票应声跌了8%

对于在线招聘网站Monster和职业社交网络LinkedIn来说,这都不是一个好消息。

除了屏幕左边展示的结果外,右边还提供了很多选择,帮助我进一步提炼或调整搜索请求。图谱搜索团队称之为“能量棒”(Power Bar)。譬如,如果你要查找尚未在Facebook上建立联系的大学同窗,便可进一步搜索与你同年毕业于同一专业的校友。

  • 根据目的不同,你或许还可以将搜索结果限制为单身人士。
  • Facebook已经为广告主提供了这种“细致定位”功能

Graph Search是Google Search杀手吗?看来不是

Privacy

他强调说,图谱搜索尊重用户施加的所有限制。“如果用户对信息施加了限制,就不会显示在搜索结果中。

Graph Search can find only content that someone has shared with you and that you could already see on the site.   permalink 2013-02-16

Future

图谱搜索目前不会索引Facebook中最重要的功能:帖子和状态更新。要整合这类内容,需要复杂的技术,还会耗费巨大的资源。但Facebook已经开始攻克这一难关。

他们的另一项重要计划是融合第三方应用产生的海量数据。例如,使用Spotify了解你的扩展队列中有谁特别喜欢听劳拉•奈罗(Laura Nyro)的歌。或者使用健身应用寻找与你路线相同、速度相当的慢跑搭档。

目前的图谱搜索还缺乏另外一个重要元素:广告。但它可能不会缺席太久,

Facebook还将在移动应用中整合搜索功能

质疑

Graph Search’s Dirty Promise and the Con of the Facebook “Like” by steve cheney 2013-01-16

  • data is dated 
  •  You simply can’t role up recommendations for people, places, and interests into a service that’s one size fits all.
  • Graph Search is no more a slam dunk for local / interest intent harvesting than me yelling across an auditorium for which doctor I should see for my cough.
  • 为什么说社交搜索价值被高估?首先,社交搜索肯定是有独特价值的,主要有两点:一个是对信息的可信性通过社交关系进行了过滤;第二个是可以通过社交网络起到发现引擎的作用。但是缺点也是很明显的。
  • 社交搜索对应的缺点是:首先搜索是个主动行为,社交搜索能够发挥作用的query占用户信息需求比例应该非常低;另外一点,如果社交网络不够大的话,仍旧无法获取足够多的信息,

2012年语义网相关领域新成立的公司

在CrunchBase上做了一个搜索 http://www.crunchbase.com/search/advanced/companies/1869976 (结果中有些和语义网无关的,过滤了)

有这么一些2012年成立的,和语义网切实有关的公司

  • Meronymy:高性能SPARQL数据库,创始人Inge Henriksen
  • Silk:数据质量提升,结构化数据
  • Comenta.TV: 用本体做电视内容导航。BTW, 这个Google也在做,NoTube结束后Dan Brickley就去了Google
  • SindiceTech:这个不是新产品了,DERI的好东西,RDF数据存储和检索
  • SpazioDati: 数据集成与curation
  • Modusly: 又一个用语义技术的客户关系管理CRM公司
  • SQMOS: 客户建模,做移动平台上的精准广告投放

当然,这肯定是一个不完全统计。单是在SemTech 2012上出场的几家公司就没有被包括进去。总的来说,语义网领域的创业还在早期阶段,不过重点已经从早年的提供工具为主转向为具体的问题域提供解决方案。这是个可喜的变化。

稳扎稳打,相信在Siri, Knowledge Graph这些样板的示范效应下,2013年会有更多的语义网的——特别是非W3C路线的——创业公司出现。

关于Graph Database

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, 语义超摩尔定律

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

语义网的高级语言

在谈论语义网的时候,要和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比较合适。

P.S. 2 2013-03-04 最近在用PyDatalog和Fuxi,两个Python的推理工具。感觉有了PyDatalog,真的可以用Python直接表达语义数据了,各种传统RDF/OWL/RIF的弱点都被克服了。我fork了一份PyDatalog在Github上 https://github.com/baojie/pydatalog

一个个人知识管理系统

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

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

基本技术路线:用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

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

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

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