Proposal: move libKMetaData (aka Nepomuk-KDE) into kdelibs

[Sebastian Trüg]

Hi guys,

it took way longer than I hoped but finally KMetaData has reached a state that 
allows a move to the kdelibs. There is still some work to be done and not 
everything is final but I think it is time that more people have a look at it 
and find weaknesses through usage.


What is KMetaData?
==================

libKMetaData [1] is the wrapper library to use the current core component of 
the Nepomuk-KDE project: the generic metadata store which provides a nice 
D-Bus interface [2].
Metadata in Nepomuk-KDE is categorized and defined via ontologies which are 
described using RDF/S (and NRL which is a description language somewhat equal 
to OWL). Anyway, this allows to define classes and properties for metadata 
categorization and field definition.
KMetaData contains a simple ontology parser which then generates C++ classes 
from the RDF/S classes.

A simple example:

We have a class "File" which has the property "location" which defines the 
local path to the file. This property is of type "string". Then the class 
generator will generate a C++ class (pseudocode)

class KMetaData::File {
  QString getLocation() const;
  void setLocation( QString path );
}

The framework will take care of loading and saving the properties. The 
advantage is that KDE applications can create and read metadata very easy.


Use cases
=========

Once of the first usages that I have in mind is a generic KDE tagging, 
commenting, and rating of files (or any resources like emails). Applications 
like Amarok and Digikam already support tagging and rating but their metadata 
is restricted to the application itself. That means that there is no relation 
between audio files tagged "foobar" to image files tagged "foobar". KMetaData 
changes that. It will allow to query arbitrary resources based on these tags 
(and much more in the future).

Dolphin, the new filemanager in KDE4, already has very basic KMetaData support 
which is awesome. I already created a patch which improves this to implement 
the mentioned file rating and tagging. I will provide that soon.


Some GUI treats
===============

I also finally created some GUI elements. Well, some is a big word here. 
Actually, I create two so far: the rating widget which is simply the nice 
star rating from Amarok in a widget and the much fancier KMetaData tag cloud. 
I think many of you know the tag clouds as last.fm or flickr provide them. 
Now we have a KDE widget that displays all KMetaData tags in a cloud which is 
weighted according to how often a tag has been used (future improvements may 
include frequency or most recent used tags).
Please find attached a screenshot of the tag cloud in action (not that many 
tags yet ;)


We should have a fancy name!
============================

Now that we have such fancy names like Plasma, Oxygen, Solid, or Phonon, I 
think the new KDE metadata framework needs a fancy name, too. So please let's 
see if we can come up with a nice new name before the move into kdelibs 
(which I hope you will agree to).


Dependancies
============

I think this is interesting, too. KMetaData has mainly two dependencies: the 
Nepomuk-KDE backbone library [2] and the RDF storage based on Soprano [3]. 
Soprano is a QT lib for accessing RDF stores. At the moment a backend for 
redland aka librdf exists. Since it is not dependant on KDE it would probably 
make sense to put it in kdesupport.


Next steps
==========

Next steps I have planned include (some ideas flying around in my head):
* Putting a little KMetaData tutorial online on techbase.kde.org
* Have Strigi store its crawled metadata into the RDF metadate repository
* Replace the Amarok collection with the KMetaData store (this will give a 
desktop wide access to the information created with Amarok like rating, 
tagging, most frequently listened, and so on)
* Have Digikam store its data in the KMetaData store
* Create a fancy Plasma applet that displays the tag cloud
* KDE-Pim/KMetaData integration: this is a big topic, there is a lot of 
information to be gathered and to be reused. This is one of the main topics 
of the Nepomuk project.


Thanks for reading this far and your comments.

Have a nice day,
Sebastian Trueg


[1] KDE playground svn: trunk/playground/base/nepomuk-kde/kmetadata
[2] KDE playground svn: trunk/playground/base/nepomuk-kde/backbone
[3] KDE playground svn: trunk/playground/base/qrdf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tagcloudtest.png
Type: image/png
Size: 4203 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070312/7f97054c/attachment.png>