Revisit Nepomuk

csslayer | 2011/12/05

虽然和早先的 http://www.ikde.org/tech/kde-tech-nepomuk/ 目的相同,不过我感到有必要重新介绍一下。

Nepomuk 是什么?

它是组织你数据的一种方式。

对于数据库专业的我来说,可能体会更深。比如大家熟悉的数据库,例如MySQL,或者SQLite。他们组织数据的模型直观理解就是一张表格,这种描述数据的方式可以方便的表达人类世界中的数据吗?实际上是有困难的。因为数据本身不是孤立而是相互联系的,举一个在讲述关系数据范式中最常见的例子来说,例如有一张工资表,记载了人和工资的级别。大家可能觉得这并没有什么问题,实际上在表达数据上是存在缺陷的。假设有A和B两个人,以及 800 和 1000 两个可能的工资级别,现在 A 是 800,B 是 1000,存储成一个关系表的结果就是

A,800

B,1000

假设现在B离开了,于是要从表中删除B的数据,这时问题就出现了。表中将不再存在工资级别为1000这一信息。于是在关系表内部的一个解决方法为,将工资级别另外存储一个表,然后人-工资这个表去引用这个表的级别,这样即使删除人-工资里面的一项,也不会丢失关于某一工资级别的信息。

但事情不总是可以这样解决的,尤其是在现实中的实体之间的关系无法简单的用几个表描述完整。

于是出现了各种各样为了解决对数据描述的方法的技术,其中之一就是RDF。RDF描述数据的方式最直观的介绍就是 Subject-Predicate-Object,在RDF中也被称作三元组,对于了解离散数学的人来说,也就是可以抽象为一个计算机科学中的图的概念,S和O对应边的两个顶点,P描述的是边上的信息。

在今年的一个介绍中,引用了1945年的一篇论文“As We My Think”,其中描述了人类的思维默认是关联的,在获取一条信息之后,大脑就会去寻找对应和它相关的信息。虽然现实中模拟大脑思维这一过程还距离我们很遥远,但是我们依然可以从中学习到一些事情。这也是 Nepomuk 的基础概念之一。

Nepomuk 的相关组件

一般来说 Nepomuk 使用的组件包括了 Strigi,Soprano,Virtuoso,Shared-Desktop-Ontologies。

分别介绍的话,Virtuoso就是最终存储Nepomuk数据的数据库,Soprano是访问RDF数据的一个Qt的库,Strigi是一个对文件元数据进行抽取的库,它本身也有索引功能(虽然在Nepomuk中不被使用),Shared-Desktop-Ontologies 则是数据的一些范式,也就是Nepomuk(不特指Nepomuk-KDE这一实现)本身的核心部分之一。RDF在描述数据时依然需要一些对于概念的定义。这部分也在不断进行扩充。

在KDE 4.7之后Nepomuk已经变得越来越稳定,我个人意见是欢迎大家去尝试使用。(如果文件索引在你的系统上出现问题可以考虑禁用……比如有个我很Care的Bug,但核心问题源头在glibc……)

另外,对于打包者(也包括Gentoo众),最重要的就是总是保持以上所有包都是最新的。

使用 Nepomuk 的项目

我目前想到的项目:

Dolphin:文件元数据浏览及搜索

Gwenview:图片元数据浏览

Bangarang:音乐/视频播放及音乐/视频元数据下载,一个有趣的功能是它可以从一些网站(Nihui 做了 Douban 支持,不过似乎还没合并?)下载数据并存储在 Nepomuk 当中。

Plasma Active:Activity 和 文件,URL的关联。

KGet:存储下载文件的原始地址

Nepoogle:使用类似 google 的方式搜索 Nepomuk 中的数据。

(还有的一些浏览Nepomuk的数据的目的也不是用于一般用户使用,我就不介绍了。)

帮助 Nepomuk 项目

Nepomuk是一个应当隐藏在幕后的项目,但现状是很多数据已经在那里,缺少的是一些能够使用这些数据的应用。这个想法在我自己购买了Nokia的N9之后越来越强烈,对于不了解这个手机的人来说,可能想象不到这个手机其实各方面采用的都是传统的Linux桌面中使用的技术,媒体播放采用的是GStreamer,联系人采用的是Telepathy,声音也使用了Pulseaudio,显示界面也是传统大家深恶痛绝的XServer,文档查看器是Calligra支持的(当然更别提Qt了)。

可以相信的是Linux最缺少的已经不是那些背后的技术,而是需要使用这些技术的应用。Plasma Active本身也是对使用Nepomuk的一个尝试。它尝试将Activity 和上面的文件关联起来(虽然个人认为目前看起来界面上有点怪怪的……)。

除了代码方面之外,3 个月前在 Pledgie 上 Nepomuk 的主要开发者Sebastian Trüg 发起了一项捐赠(P. S. 我之前也去捐了一些 🙂 ),目标是募集 9000 欧元(现已达成),不过理论上依旧可以通过上面的链接附加捐赠。(我不确定,但看起来是的)

关于可能出现的讨论

我想强调的一点是,如果你纠结于它的Bug,或者是性能这一类的问题,请不要在本文的评论中讨论(被我吃掉我可不管哦)。我的观点是 Bug 总可以解决,但 idea 却不容易诞生。

参考:

http://dot.kde.org/2011/09/21/nepomuk-stability-and-performance

Tags: ,

14 FEEDBACKS

  1. 我来坐沙发。nepomuk一般都是装好了KDE就关掉,原因是貌似除了占用大量资源貌似没什么用。不过现在我似乎应该打开它了。

  2. poet

    果断表示这篇文章看完了还是不知道 nepomuk 能干吗,怎么用。

    而且文章尾部指出了,后端的技术都已经存在,唯独缺乏一个能把它用好的软件。

    好吧,nepomuk 现在后端技术已经很牛了,咱们怎么用它呢?每人自己开发一个?

  3. 豆瓣支持在 bangarang 2.1 里面。

  4. 这篇写得还是不够通俗啊 geek 写出来的文章一般都比较 geek 哦~

  5. ark12211

    看完了,看起来很牛,但是我还是不知道自己应该用它来做什么OTZ

  6. @poet 准确的说不是“一个”而是“一堆”。由于可以采用同一个数据源,使用 Nepomuk 的程序也不应该是孤立的而应该是联系的。一个目前的最简单的例子就是,dolphin里面的打分,或者标签,和bangarang里面的是一致的。

    再比如说有一个隐藏很深的kio slave,名字是 timeline:/ 。它是利用nepomuk实现的,可以用于按时间浏览文件,不过如果我不说……恐怕没人知道还有这么个玩意吧?

    这个大概是我所知唯一一个可能用了 timeline:/ 的 http://www.ikde.org/app/rosa-launcher/

    说点子的话,比如一个就是: http://www.ikde.org/winmac/dolphin-and-explorer-exe/ 这里心之所在兄非常纠结的那个专辑浏览。

    @ark12211 现在怎么使用的答案只有上文中的 “使用 Nepomuk 的项目”

  7. @phoenixlzx 你不开文件索引不占用什么资源的。

  8. jack

    作为一个数据库,我想知道有没有清晰的备份、导入机制。设想我在dolphin中给很多文件加了标签,格式化home目录后固然可以重新索引,但我的那些标签该怎么找回来?如果手动重做的话就没意义了。

    我能不能将其它机器上生成的数据导入,虽然文件不在本机,但我想有个统一的地方搜索,比如我希望能在本机上查到a文件在b机器上

    也许我误解了nepomuk的应用场合?

  9. @jack 现在可以定时备份,手动备份,导入。不过这部分数据主要是备份手动创建的数据。 远程文件的这个……我不太清楚,感觉目前是不支持。不过存储在nepomuk内的数据当然不限于本地文件的数据。 不过现在支持移动媒体(移动硬盘,U盘上的文件索引)。文件的URL是通过磁盘的UUID加上相对磁盘的路径标识的。

  10. tmk

    移动文件或改名就杯具了。。。 他们说要实现kde程序中移到文件辨别,现在也没动作?

  11. cs杀手啊,你这两篇文章可以说适得其反了,原来对nepomuk还有点了解了,看了你这两篇文章之后如坠五里云雾中。

    工资表问题,我的理解是这样的: 1、因为简简单单存储了人+工资的信息,缺乏对数据的组织性,比如,500-1000工资级,也就是说,原来的表虽然基础数据存储充分了,但是太简单了,为了更好的检索,可能需要第二张表,就是用来存储工资级别的。 这是简单的一张表,但如果还需要添加更多信息,比如按姓氏(在统计处理中经常需要做这种事情),则表结构将趋于无限复杂,从而难以管理。 那么,是否有更优的解决方法呢?——这个问题可能需要从数据存储方式到组织管理方面的综合解决。 2、因为原有数据库对数据的存储方式,不够简明,或者说不够灵活、不够透明、和应用不一致、不够通用,就像黑箱,而且其存储方式非语义化(用二进制存储,因此只能实现简单的处理,而无法实现更加智能化的处理)。因此出现了更好的表示法,比如包罗万象框架(RDF resource description framework),因为使用主题-标签-内容的描述方式,从而可以实现更佳灵活和透明的表述。这种方式,在最顶层,实际上相当于只建立索引,而不对内容进行完整的索引——当然,如果内容也采用此种方式存储的话(图片、视频、音频方面比较难),那么可以最终做到对内容也完全索引,最终结果将非常透明一致、可理解、结构化,也因此能够实现更加复杂和智能化的处理(有个词,专门描述如何复杂处理的,叫数据挖掘;有个词可以描述其更优秀的应用的,叫智能化): 某文件-某类-文件所在 文件所在(标题-关键词-正文) 正文(正文标记名-格式类别-显示方式) ……

    根据这个结构,如何实现更复杂的处理呢? 1、数据挖掘:原先都是需要建多个表,对各个表的关系进行构建,使用人类本身大脑来分辨类别,并进行相关处理 而现在,则不需要如此,完全可以根据其标签类别,不需要人脑辨识,即可知道数据之间的关联关系,从而提高数据挖掘效率 2、智能化:通过改变数据存储方式,提升了电脑对世界的识别能力,从而可以让电脑更加智能化。 …… 哈哈,我真罗嗦

  12. elff

    @黑传说 Subject-Predicate-Object难道不是”主谓宾”的意思?

  13. 为了更好地理解这篇文章还专门看了看图论初步……虽然表示多年不动数学,数学能力已经丧失得差不多了。

    我个人的理解Nepomuk就是和新的数据结构(组织数据的方式)相适应的算法。传统的组织数据的方法是目录和文件形成的树,这个树肯定是有某种逻辑关系所确定。但这种一个维度的关系树是远远不够的,所有元素按照某一标准分类可以形成一个关系树,按照另一标准又是另一关系树。元数据就相当于Tag,标记了某一元素的若干特性。不同的文件通过共同的特性相互关联,形成一个彼此相关的网络。

    如果元数据包罗万象到足以描述整个文件的全部特性,树形目录甚至已经不需要了。把所有文件保存在一个文件夹下,只要知道我想找哪一种资料,计算机会自动筛选出所需要的结果。事实上现在的科学文献索引已经在这么干了。然而我觉得推广到个人PC上,即使不考虑性能、算法和软件支持的问题,还有一个最大的阻力就是计算机其实并不知道一个文件究竟意味着什么。现在的元数据还很粗陋,即使是手工创建,也远远不能真的阐明数据的全部意义。不过我相信这是一个好的开始,至少在可见的将来,性能、算法和软件支持的问题都是能够得到解决的。

  14. dbhrscom

    我对语义学桌面应用初浅的理解是树状文件系统的数据库化抽象,核心是基于标准本体(资源描述格式)的数据库,支持工具包括文件系统的监控和采集,数据库记录的维护和查询,因为它所采用的关系模型较为复杂,所以在用户层面上它的查询语法较难吸收和接受,所以影响了它的亲和力。但就它的数据组织原理来说,是可以提供多类型关键字组合查询的,只是这样的程序还没有出现!

Leave a Reply

Your email address will not be published. Required fields are marked *

Note: Commenter is allowed to use '@User+blank' to automatically notify your reply to other commenter. e.g, if ABC is one of commenter of this post, then write '@ABC '(exclude ') will automatically send your comment to ABC. Using '@all ' to notify all previous commenters. Be sure that the value of User should exactly match with commenter's name (case sensitive).