[Kde-pim] Nepomuk-KDE Meta Package 0.1 released

[Sebastian Trüg]

Hello everybody,

as a little introduction let me repeat my text from the last commit-digest 
(Thanks, Danny, great work):

================

There has been quite some progress in the Nepomuk-KDE project over the last
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.

The way I see it there are three types of meta data:
1. 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.
2. Meta data that is created by the user manually like annotations or tags 
   that are assigned to files, emails, or whatever resources.
3. Meta data that can be gathered automatically such as the source of a
   downloaded file or the email an attachment was saved from or the original
   when copying a file 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 application's scope.

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 convinience wrappers 
around it to access this data. The simplest method being the DBus interface.

But now to the actual progress: I just finished the unappropriately named
libKMetaData. KMetaData is a wrapper around the RDF services that allows very
easy handling of meta data of types two and three. Part of the Nepomuk project
is to create a desktop ontology that provides categories and classes of meta
data and their relationships. KMetaData contains a code generator that creates
convinience 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 want to add 
a comment (an 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 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 does not only work with files or annotations. Although at the moment
the Nepomuk ontology does not exist yet and I only created a placeholder one
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. Thus, 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 have then
all the information we need to help the user as good as possible in his or her
daily work.

================

Now that you hopefully know a little better what this is all about go ahead 
and get the Nepomuk-KDE 0.1 release from the Nepomuk-KDE Wiki [1].   

It is a meta package containing all the sub projects I am currently working 
on, KMetaData being probably the most interesting of all.

(You need a running KDE4 enviroment to fully test Nepomuk-KDE)

Have fun and please come on discussing on the nepomuk-kde mailing list [2].

Cheers,
Sebastian

[1] http://nepomuk-kde.semanticdesktop.org
[2] https://nepomuk.semanticdesktop.org/wws/info/nepomuk-kde
_______________________________________________
kde-pim mailing list
kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/