从文件搜索到语义学桌面

普及概念，分享下 nihui(我) 对 nepomuk 以及其它相关组件的理解。降低技术性门槛，希望大家能看得明白  ^^:)

第一阶段：文件搜索

按照文件名、创建时间、修改时间、文件类型。按照文件内容只能针对文本文件。文件名是唯一直观表达文件实质内容的方式，而文件内容搜索有局限性，而且速度慢。如今的 dolphin 依旧保留了这种原始的搜索方式。

第二阶段：KDE3 的 kfile 插件

kfile 插件的用途是从文件中解析出元数据，比如图片的分辨率，音乐文件的标签等。这些信息能够在 KDE3 的 konqueror 中显示和编辑，但是无法依据这些元数据搜索。kfile 只是一个元数据读写器。KDE4 中已经完全被 strigi 取代。

第三阶段：strigi 文件检索

为了可以依据元数据进行搜索，strigi 就诞生了。strigi 最初就走和 kfile 插件不同的路线。strigi 不仅可以解出元数据，还会解出更多，最重要的一点就是文件实质内容，比如 pdf 文档内容，压缩归档内的文件。当然，还是仅限于文本方式的检索。因为每次检索文件实质内容都相对较慢，所以 strigi 会偷偷地将信息缓存在本地磁盘里，缓存越来越大之后，磁盘可能用完哦。

第四阶段：nepomuk 检索器和存储方案

从这个阶段开始，nepomuk 来了。nepomuk 为了避免遭遇缓存文件太大的问题，自己另外实现了一套检索器。检索器本身依然是使用的 strigi 分析器来解出元数据和文件内容，但对这些信息进行更精细的分类，比如把音乐文件的标签分类到 ID3 类别，把图像文件的 EXIF 分类到 EXIF 类别，甚至不针对文件本身的、抽象的联系人类别和任务类别等。这些类别通常有许多字段定义着各个信息，像专辑名称、人物姓名、照片拍摄日期、任务起始时间等。这些字段就是所谓的 ontology，用于描述信息标记的代言词。经过检索器检索后，文件的元数据和内容信息就被提取到 nepomuk 的存储中，大多数情况下以 ontology 存于 virtuoso 数据库里。nepomuk 取代了 strigi 原有的检索器和存储方案并扩展了信息检索理念。

第五阶段：基于 ontology 的信息检索

ontology 不仅可表示文件本身的元数据和内容信息，还表示了一些附加的信息，可以将文件关联于某个任务或者某位联系人，同样也可以附加额外的标签和评分。至此，搜索可以基于所有的 ontology，如基于评分或者某位联系人，查找相关的文件或抽象信息，而这一切在前面阶段都是做不到的。

第六阶段：桌面环境集成化

事实上，单纯的文件并不能涵盖所有可能，许多信息的产生并非依靠文件的创建或者修改保存。用户在操作应用程序的过程也会产生很多有用的信息，如用户使用 kget 下载的文件和下载链接是有联系的，回复的邮件和邮件线索是有联系的。非依赖于文件本身的关联也会被记录成 ontology 进行检索，而解出信息只有通过更深入的桌面环境集成才能做到。这种深入的集成只有达到一定应用程序数量级时才能看到更多方便之处，目前依然有大量的应用程序使用传统基于文件的操作，基于 ontology 的好处并不能直观感受到。

第七阶段：nepomuk 和语义学桌面

何谓语义学，按照人类思维方式，即依据信息之间的关联性。nepomuk 的终极目标就是让用户能按照和人类思维相似的方式取得和存放信息的关系。强调一下，文件只是信息的一种表达方式而已。文件存在哪个文件夹，存在本地还是存在移动硬盘，甚至是否真的存在已经不再重要，重要的是文件和其它信息之间的关系，通过关系是否可以获得相对应的文件。nepomuk 存储的根基就是关系，技术上实现为 RDF，也是为何首选 virtuoso 的原因。