Sebastian Trueg, a key architect of the NEPOMUK-KDE collaboration, explains the
NEPOMUK concept and its relation to the future KDE desktop:
There has been quite some progress in the NEPOMUK-KDE project over recent weeks. But before I dive into that, it is probably a good idea to explain the purpose of the NEPOMUK-KDE project again. I won't explain the whole
NEPOMUK project here since it is far too much for this text (and for me as well ;). Thus, let me just give a rough image of what I am working on right now.
As far as we can determine, there are three types of meta data:
- Meta data that is stored with the data itself and is available all the time. This includes id3 tags, the number of pages in a PDF document, or even the size of a file or the subject of an email.
- Meta data that is manually created by the user, like annotations or tags that are assigned to files, emails, or whatever resources.
- Meta data that can be gathered automatically such as the source of a downloaded file, the email an attachment was saved from or the original location of a file copied locally.
The first type of meta data is already widely handled. Desktop search engines like
Strigi index this information and we can always look at the meta information in the nice KFile dialog. But what about the other two types? Type three can be found in some applications like photo managers but their extra meta data never leaves the scope of the application.
This is where the current work in the NEPOMUK-KDE project comes in. We store arbitrary meta data in a local RDF store and provide convenience wrappers around it to access this data. The simplest method being the D-Bus interface.
But now to the actual implementation progress: I just finished the inappropriately-named libKMetaData. KMetaData is a wrapper around the RDF services that allow very easy handling of the meta data of type two and type three. Part of the NEPOMUK project involves creating a desktop ontology that provides categories and classes of meta data and their relationships. KMetaData contains a code generator that creates convenience classes from this ontology which can then be used to read or write meta data.
Let me give an example: Say we have a file, /home/trueg/foo.bar and we want to add a comment (annotation) to it. We simply create an instance of Nepomuk::KMetaData::File and use its methods like so:
Nepomuk::KMetaData::File f( "/home/trueg/foo.bar" );
f.setAnnotation( "This is just some test file I use to present this feature");
and we are done! KMetaData takes care of syncing this information into the local RDF store. Now any other application can access this data the same way:
Nepomuk::KMetaData::File f( "/home/trueg/foo.bar" );
myDisplayLabel->setText( f.getAnnotation() );
Simple as that. I have created three tools that use KMetaData: the simple annotator, the simple tagger, and a Strigi plugin which allows to search this manually created meta data. Thus, tag your files and find them again with Strigi by using the tags.
And this works beyond merely files and annotations. Although at the moment the NEPOMUK ontology does not yet fully exist - with only a placeholder that defines annotations and tags - libKMetaData is already very powerful and extensible: all classes like File are based on the generic Resource class and only use its setProperty and getProperty method to change values. Therefore, one can even create and read data of unknown resources (although in the future I hope to cover almost everything with our ontology).
I hope that in the future this technology can be integrated into KDE in order for each application to create meta data for arbitrary resources. We then have all the information we need in order to help the user as much as possible in their daily work.
