Events

ToDo

Nepomuk is a rather young project with a notorious shortage in developers. There are many tasks and subprojects to get ones hands dirty on. Unlike other projects like Plasma, however, developing for Nepomuk is not easy. One has to read up on a lot of things and fight some day-to-day annoyances. But: helping with the development will improve the situation in any case.

If you are interested in working on a task in this list, please contact Sebastian Trueg.

Junior Jobs

If you want to get into Nepomuk development quickly by taking over a small task have a look at our Junior Job page.

Low level Nepomuk Development Tasks

The low-level development tasks are those that are not directly reflected in the GUI or even in the API used by most developers. However, they are important in terms of performance, scalability, and compatibility.

Add Inference Configuration to the Virtuoso Soprano Backend

Virtuoso 5 provides inference on rdfs:subClassOf and rdfs:subPropertyOf. These are the most important ones and for now all we need in Nepomuk.

The current implementation of the Virtuoso Soprano backend does not enable inference. We need a configuration option to do exactly that. It could happen along the lines of the existing config options or with the introduction of dedicated inference configuration options on the Soprano::Backend level.

Soprano Transaction Support

Soprano is the RDF database framework used in Nepomuk. Currently Soprano does not support transactions, i.e. sets of commands that can be rolled back. An experimental development branch exists which already contains new API for transaction support (while keeping BC).

It still misses an implementation of the transaction support in Soprano backends (Sesame2 and Virtuoso) and in the client/server architecture.

Another idea is to create a new API based on the design that Sesame2 follows: Repository and RepositoryConnection classes. The former creates instances of the latter which then has all the actual data handling methods and acts as one transaction object.

General Nepomuk

Handling of external storage

We already have the removablestorage service in kdebase which handles USB keys and such to a degree.

A typical problem with the way Nepomuk handles files and file metadata are removable storage devices. They can be mounted at different paths on different systems. But still one wants to keep the metadata stored in Nepomuk. If possible one would even want to be able to search for files saved on an USB stick even if it is not plugged in.

However, one actually needs more. The system would have to be embedded into KIO to make sure the metadata cache on the removable storage device is always up-to-date. Also it is directly related to the problem of relative vs. absolute file URLs.

Nepomuk Backup Service

We need a backup solution. The idea is the typical one: have a Nepomuk service that allows to specify update intervals and manual updates.

The service should ignore all data extracted by Strigi, i.e. data that can be recreated deterministically. This can easy be determined by checking the context/named graph the data statements are stored in. Strigi stores all extracted data in one context which is marked as the http://www.strigi.org/fields#indexGraphFor for the file in question. Thus, a query along the lines of the following would work: