当前位置：首页 → 问答吧 → 那个Nepomuk和Strigi是鸡肋吗

那个Nepomuk和Strigi是鸡肋吗

时间：2010-02-28

来源：互联网

前不久更新桌面后自动打开了Nepomuk和Strigi，这两个东西早有耳闻，据说是很NB的东西，语义搜索什么的，反正也没太懂，以为就是google desktop一类东西，但更精确，能理解用户的意思（所谓的语义），这只是我看了介绍后的想当然理解，肯定是有出入的，但网上也没找到更详细的或功能演示的介绍。当时也没在意，不过很快发现系统变慢了，仔细一看是在索引linux内核源码（我自己clone了一份），等了一会儿，终于忍受不了，移出了内核目录，为了测试，只指定了一个临时目录进行索引，里面只有百来个文本文件（包括几张图片和一些html），于是索引很快就结束了，引擎出于空闲状态，试着用那个快速起动器(alt+f2，还有其它测试方法吗）搜索了一下，结果大失所望，中文完全无视，英文似乎也不是全文索引，找一个英文readme中的英文人名也没有反应，似乎只有网址和链接的图片以及文件名有反应（的确体现了语义，但也太弱了），而且索引数据库还比源文件夹大的多，整个一鸡肋，现在我已经把它关了

总结一下：
1. 索引大量数据（如kernel源码）严重拖慢机器，
2. 索引效率也不高，数据库很大
3. 搜索能力弱（在kernel源码中找个函数也没搜到，当然也可能还没索引到，太庞大了）

这玩意难道只是看上去很美？

作者: allisfree 发布时间: 2010-02-28

http://bbs.archlinux.org/viewtopic.php?id=90960
不过我从来不用

作者: ashunter 发布时间: 2010-03-01

关于语义检索，就连理论上都未能有大的结论（比如内涵逻辑的研究），类似地，目前所谓的“语义网”之类的东东纯属噱头。

稍微“智能”一点的语义搜索，往往都采用统计数据。外国人做得也勉强倒还能接受了，但照搬过来换到中文环境，光切词（parsing）就费尽脑筋。

反正目前不要指望这个东西能很实用。

作者: sfbi 发布时间: 2010-03-01

我下载matlab光盘，下载成功之后系统瞬间失去响应，后来发现是strigi在索引，于是就关了~

作者: nolava 发布时间: 2010-03-01

谢谢大家，看了官网的讨论和诸位的意见，看来strigi的确没什么用，nepomuk可以使用元数据（tag），方便整理文档，就像图书馆的目录，还有点用，只是不知道这些元数据可以手工建立吗？

至于语义搜索，个人感觉有全文搜索就够了，前不久看到一篇关于谷歌搜索算法的文章，感觉这就很好啊，虽然不大可能用在google desktop中

作者: allisfree 发布时间: 2010-03-01

引用:

作者: sfbi

中文分词已经有研究了。有个python的切词工具的就还可以。不过纯粹切词，还不能有“智能”的吧。
总之，我只是开了nepomuk。另外那个Strigi太消耗系统性能了。

作者: dickeny 发布时间: 2010-03-01

引用:

作者: allisfree

dolphin里面就可以的哦，把信息面板打开，很明显的位置
参考：http://kde-video-tutorial.googlecode...deocapdemo.avi

作者: hurricanek 发布时间: 2010-03-01

从桌面语义学搜索的功能定义来看，它类似一个桌面版的“搜索引擎”，strigi在其中扮演网络蜘蛛角色，用于探测各种文件类型和进行深度搜索，而搜索结果存取由soprano负责，nepomuk的一些模块提供文件系统监测、搜索种类维护（例如tag,rate）、搜索调用接口等功能。

简单的说，若在 kdesc 桌面实现组合关键字查询，strigi、soprano和nepomuk都是不可或缺的，而功能实现的基础和网络搜索引擎需要维护庞大的索引数据库一样，监控设定的文件数目越多，数据索引量越大，相应的索引系统资源消耗也是越来越大，很直观的表象就是拖慢了系统的运行速度，这也是目前”语义学搜索“功能让很多人诟病的主要原因。

但不可否认的是，这种状况在一点点的改变，在效率上如virtuoso存储后端的使用，加快了数据存储的速度；越来越多的系统状态监控，分散了数据检索给系统资源造成的负担；数据检索功能的扩展（例如搜索移动存储介质，局域网文件、与akonadi的结合）增加了它的实用性；不断增多的功能定制，更是把选择权留给了用户。

另外strigi的功能除了数据检索之外，文件属性的一些信息也是由它来提供的

作者: dbhrscom 发布时间: 2010-03-01

nepomuk 不少程序需要它.

strigi,指定目录让它索引或关掉好了.索引kernel源码这样的大头.不是活受罪么.

strigi索引和akonadi我都是关掉的...akonadi好像只是kdepim组件用到它.

作者: zhong 发布时间: 2010-03-02

akonadi不得不不关（很绕……），要不然kmail就杯具了……

作者: hurricanek 发布时间: 2010-03-02

引用:

作者: dbhrscom

这里面的一个目前无解的理论问题是：语义检索某种意义上需要“理解”检索词和检索源中词句的“意思”。一个简单的例子比如搜索“中国”，则“其中国民收入达到。。。”不应该出现。要彻底解决这个问题需要在逻辑基础上加以改进，使用某种意义上的“内涵逻辑”。可是这方面目前是死胡同，稍微“智能”一点的逻辑全都复杂性超高，甚至不可判定。（当然我举的例子太简单，用统计数据进行分词可以处理地很好）

所以目前现实的做法全是采用统计数据的（至少统计数据占有重要作用），于是也需要索引数据，加以分析。可即使做到再好，也只能无限接近，而永远无法实现真正智能（比如达到普通人的水准）的语义检索。

作者: sfbi 发布时间: 2010-03-02

那个Nepomuk和Strigi是鸡肋吗

热门阅读

热门下载