KDE 的下一代语义学搜索

说下一代语义学搜索前，要知道上一代语义学搜索是什么。说上一代语义学搜索前，要知道 KDE 下的语义学搜索的结构是怎样的。那就让苏在升级 KDE 4.13 的垃圾时间里为大家灌输一些「无用的知识」吧！

KDE 的语义学搜索是这样组织的：strigi 是一个文件内容搜索引擎，它从用户的文件中提取出语义学数据，然后把语义学数据灌给 nepomuk。nepomuk 是 KDE 下访问语义学数据的函数库，使用 soprano 来存储这些语义学数据。soprano 是一个访问语义学存储（RDF）的 Qt 库，就跟 Qtsql 一样，它有三种后端：redland、seasame2 和 virtuoso。

之前记得我说过 KDE 下的卡机三架马车就是 strigi、nepomuk 和 virtuoso。之所以会产生这样的结果，是因为：strigi 在索引文件的时候非常之吃 CPU; 然后 virtuoso 呢，soprano 一共三种后端：redland 是 c++ 写的，但它的检索速度非常之慢，满足不了 nepomuk 的要求;seasame2 是 java 写的，不可能 C++/Qt 的 KDE 的「非常重要」（官方是这么看的，我不这么看，我一般语义搜索都不用）的功能去依赖 java; 于是 KDE 领衔开发了一个据说是「c++ 写的，检索速度达到 seasame2 同等甚至更高的水平」的 virtuoso，先不说它「永远处在积极开发中」吧，就看它的设计目的你也能够猜想到结果，那就是永远满足不了它的设计目的，不然最初 redland 和 seasame2 就根本不会出现啊。

再来说 nepomuk，它基本和 strigi 是一对基友，只不过 strigi 解决的获取原始数据的问题，而 nepomuk 解决的是读取语义数据的问题。当然了，按照大家一贯的认知，你见人的脸都没洗，怎么能奢望你洗脚。nepomuk 读取的速度也是非常之慢的。

而神一样的 KDE 4.13 为大家带来的最重要（似乎是唯一一个？）特性就是：使用 baloo 替代了 nepomuk。baloo 是重造轮子的 nepomuk（代码复用，功能相同），那么可想而知，它应该也是很卡的，不然如果存在一种神一样的技术能解决了 nepomuk 的问题，nepomuk 完全不会被 baloo 替代还复用了那么多代码。

但是据我个人的使用经验（1TB 7200 转硬盘，用了 5 年的 openSUSE，想象一下里面攒了多少文件，尤其我还是一个没有廉耻的开发者和发行版的打包者，算是傻逼级别的程序员了吧？）来看，baloo 它，不，卡，了！！！

究竟是为什么呢？答案是 baloo 限制了功能。上游做了研究，并识别出了语义搜索最重要的使用场景有三种：

* 基于文件内容查找文件
* 存储和获取最简单的对象，比如歌曲评分、标签。
* 存储和通过最简单的关系来查找文件，比如：属于 marguerite 用户的歌曲。

于是呢，baloo 只需要把那三种用例的逻辑做好优化好就行了。天哪！之前开发者们你们在干什么，拍脑袋吗？现在终于意识到了用户根本不需要搜索：我在大概半年前的半夜写的某段代码忘了加分号这种 case 了吗！

Anyway，不去黑开发者这种挖坑挖太深爬不上来，只好给自己找个梯子爬上去重新挖的故事了。baloo 能够给你我这样的用户带来的好处是：

* KDE 开发者终于管我们的死活了！终于照顾我们的电脑 CPU 了！终于知道做调查了！
* 索引的时候不卡了，我 1.7Ghz 的 CPU 大概索引时占用 3% ～ 4% 左右的 CPU 资源，在使用据说 bug 很多的 firefox 29 上面使用，没有影响到我发这篇文章。
* 搜索据说能够即时显示了（我还没索引完所以没法测试给大家），这几乎就是 Linux 下的 everything 啊。

或者这么说吧：今天我给大家带来一个好消息！KDE 的语义搜索终于能够给人用了！（原文是说 KDE 终于从学术神坛走向真实世界了）。

但是，很显然要有但是的嘛！

从 nepomuk 到 baloo 需要迁移数据。所以就算是 openSUSE 这样女仆的发行版也给出了一个像 Arch 那样的升级提示（这是不多见的！我们就算 sysvinit 迁移 systemd 都没有给出这样需要特别注意、手动干预的升级提示）：

1. 升级前要打开桌面索引（系统设置 – 桌面索引 – 打勾），除非你从第一天就没有用过它。反正就算是我这种常年不用的，当年也尝过鲜，谁知道有没有残留数据，所以保险起见是打开。

2. 升级安装软件包过程中不能卸载 nepomuk 的相关包，baloo 会自动安装。一定要确保安装了 baloo-file 这个包。（openSUSE 下，别的发行版自己找啦）

3. 升级完毕后，注销重新登录，baloo 会发现 nepomuk 的数据库并自动触发迁移工作。

4. 等到迁移结束（别问我我也不知道什么时候结束，所以我等到了 baloo 第一次索引完成完全看不到 baloo_file_extractor 进程了，或者我再给出个可操作性强的，升级完三天后），baloo 会自动停止 nepomuk。

5. 这个时候就可以卸载 nepomuk 了。比如 nepomuk-core, libnepomukwidgets, soprano*, strigi, virtuoso 和 shared-desktop-ontologies。

6. 依然有一部分 KDE 应用程序还在依赖 nepomuk，比如 bangarang, kweshtunotes 等等。估计也是很少人在用的。

再讲一下使用：

baloo 跟 nepomuk 是完全相反的使用逻辑。nepomuk 是你可以选择要索引的文件夹，baloo 是你可以选择要排除的文件夹。

baloo 默认的检索对象是你的 /home，其它文件夹全部自动排除。

再讲一下完全禁用：

把你的 /home 添加到排除列表。baloo 就不会运行了。

这个时候把 baloo 相关软件包卸载掉。

再讲一下一些杂项和已知问题：

* baloo-pim 不装没法索引邮件，你的 Kmail2 要是不使用邮件索引功能的话，可以不装。
* 除了 dolphin 以外，还可以使用 milou 专门进行搜索。milou 可以放到面板上，但是不能放到系统托盘里，不然你的 plasma 在开机登入时会崩溃。
* 要是有超大的文本文件的话，比如源代码…索引很吃 CPU（这本来就是 nepomuk 时代就有的毛病），所以要么认栽我等，要么排除掉。
* nepomuk -> baloo 迁移过程不完美：电邮是要重新索引的，文件与活动之间的关系会被丢弃。

参考文献：

* http://thomasmcguire.wordpress.com/2009/10/03/akonadi-nepomuk-and-strigi-explained/
* http://dot.kde.org/2014/02/24/kdes-next-generation-semantic-search
* https://www.dennogumi.org/2014/04/kdecurrent-and-4-13-packages-for-opensuse/