KDE 4.2, NEPOMUK and Linux distributions

published Apr 22, 2009, last modified Jun 26, 2013

NEPOMUK and Strigi do not work in the vast majority of Linux distributions. We'll see why, and how we can fix that.

KDE 4.2, NEPOMUK and Linux distributions
NEPOMUK would be fantastic... if it worked!

What NEPOMUK is about

The stable KDE 4.2 release is a phenomenal work of art that lets every application share and modify metadata using an unified ontology, all mediated through the great D-Bus protocol.  This is known as NEPOMUK and the way it works is as follows:

  • There is a daemon that starts up when your desktop environment starts.  This daemon (the NEPOMUK daemon) starts a bunch of little services -- storage backends, query server, indexer (known as Strigi).
  • This daemon latches onto the D-Bus session associated with your desktop environment.  It sits there listening to queries -- they can be questions in SPARQL, or method calls to get/set specific pieces of metadata.
  • The daemon mediates the job of searching the storage backends and manipulating the data.
  • Applications query it through D-Bus using a standardized interface that works for full-text-search queries and other sorts of metadata-related queries.

This provides a central location which applications can access the metadata, either directly through D-Bus or abstracted through the available application libraries.  It's a rather powerful idea, since applications no longer need to link directly to metadata libraries or use ad-hoc methods like stat calls to piece together metadata for files in your computer.

Couple this with a KIO slave called nepomuksearch:, and you have live searches or data feeds for your applications.  That's right, you can put a list of files tagged TO-DO or a list of files with the word rabbit right on your desktop.

Or at least you ought to be able to.

The problem

The problem is that NEPOMUK simply does not work in KDE 4.2 as it was supposed to work.

The database technology used in NEPOMUK is called Soprano.  It was chosen because it has several pluggable backends (sort of on-disk formats).  The problem with Soprano is that its default backend (the Redland one) does not support certain query methods on its database, methods that NEPOMUK requires.  So the NEPOMUK developers decided to use the Sesame2 backend, which is feature-complete and fast enough for their needs.

One problem, though: Sesame2 is a Java library that almost nobody in the distribution world has bothered to package for almost no distributions.  And with good reason too -- most distributions require a compilation from source, while the Sesame2 backend is being distributed as a JAR file instead.

The result is clear:  nepomuksearch: (the whole point behind NEPOMUK) does not work in any distribution except perhaps for Mandriva.

And, in that manner, the NEPOMUK developers royally tied themselves up into a Gordian Knot.

The fix

...is already deployed in the latest Fedora 15 and 16, which includes KDE 4.7 and a staggering number of bug fixes to NEPOMUK.