Proposal: Integration of libKMetaData into kdelibs

[Sebastian Trüg]

Hi everybody,

last Friday I discussed the new libkmetadata with Aaron Seigo. We agreed that 
it would be a good idea to have it in kdelibs so all KDE applications could 
benefit from it.

Let me summarize what libKMetaData is (taken from the libkmetadata 
documentation):

Three types of meta data can be identified:
* Meta data that is stored with the data itself and is available at all times.
  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 created by the user manually like annotations or tags that
  are assigned to files, emails, or whatever resources.
* Meta data that can be gathered automatically by applications such as the
  source of a downloaded file or the email an attachment was saved from or the
  original when copying a file locally.

Type 1 is already handled in many implementations. KDE itself includes the 
KMetaFileInfo classes that allow extracting this kind of meta information 
from files.
KMetaData is intended for meta data of type 2 and 3. It provides an easy way 
to create and read meta data for arbitrary resources (this includes for 
example files or emails, but also contacts or maybe even a paragraph in a pdf 
file).
The simplest type of meta data that can be handled with KMetaData is a 
comment. It is a simple string associated with a resource (a file for 
example). This comment is created by the user using an application that is 
based on KMetaData.
KMetaData's core is designed to allow arbitrary types of meta data, i.e. any 
resource can be related with any other resource or value by simply naming the 
relation and providing the value. The power of KMetaData, however, lies in 
that it provides a class for each type of resource. Each of these classes 
provide convinience methods to allow a simple handling of the meta data. For 
an example have a look at the File class.
The types of resources and their properties are defined in the The Nepomuk 
Desktop Ontology.
KMetaData is resource based. Thus, working with KMetaData is always done with 
instances representing a certain resource. This resource has a list of 
properties. Properties are named and have a certain type. The type can either 
be another resource (compare a file that was an attachment from an email) or 
a literal (this means for example a string, or an integer; the comment 
mentioned earlier would be a string literal). Each property can either have a 
cadinality of 1 (again a file can only be saved from one email) or greater 
than 1 (i.e. infinite, like one file can have arbitraty many associated 
comments).

(To get an even better understanding of KMetaData and how to use it please 
compile trunk/playground/base/nepomuk-kde and run doxygen on 
kmetadata/Doxyfile in the build dir.)


The proposal is to integrate libKMetaData into kdelibs. At the moment 
kmetadata has two dependancies:
* Soprano (aka QRDF) which can be found in trunk/playground/base/qrdf is used
  to parse the Nepomuk desktop ontology (which is not complete yet) during
  build time.
* The nepomuk-kde backbone lib is used to communicate to the local meta data
  store.
[* The Nepomuk-KDE core services provide a DBus interface to the soprano meta 
   data store that follows the Nepomuk standard.]

The last one is optional since it is a run-time dependancy which later can be 
replaced by virtually any Nepomuk storage service implementation. However, 
having a storage service in KDE would probably be a good idea.

Please consider libKMetaData as a first step towards a semantic KDE.

Next steps could include adding support for meta data of type 1 to 
libKMetaData, thus wrapping it all under one simple API.

Please discuss.

Cheers,
Sebastian