Proposal: Integration of libKMetaData into kdelibs

[Kevin Ottens]

Le Lundi 18 Décembre 2006 17:44, Sebastian Trüg a écrit :
> Let me summarize what libKMetaData is (taken from the libkmetadata
> documentation):
> [...]
>
> 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.

Is there a way to make more complex queries? Or is that something planned for 
another library than libKMetaData?

> 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.

Just to be sure, is it the ontology.rdf available there?

> (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.)

I didn't get around to compile it yet because of soprano

> 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.

Note that it has some visibility issues, no class are exported in soprano 
which makes the tests linking to fail.

> * 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.]

As you already know, I've some concerns on using a RDF based storage regarding 
performances. Some more testing is probably required. What makes me ponder 
is: should we test this before including it in kdelibs? or, include the lib 
in kdelibs first and if performances are not good hope it'll improve?

Of course we can optimize our code, but since it's really tied to RDF, if the 
RDF storage is identified as the bottleneck we'll probably have a hard time 
improving the situation.

In any case, we need a very clear picture on the performance impact on using 
libKMetaData (and what will probably follow) for application developers. If 
it doesn't scale well enough it means that we'll probably be careful on how 
apps use it and how much data can be stored.

Btw, if I find time and can get both soprano and nepomuk-kde (urgh! this 
name... :) ) to build I'm willing to help with such testing.

> 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.

Indeed, if I get it right, it's like having Phonon or Solid shipped without 
any backend...

> 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.

Well, that would need to be done I guess. As a developer, I would find weird 
to use on API for some of the metadata and another one for more metadata...

Now I have a few questions and comments about the classes in this library.

I'm not exactly sure if the Ontology class is well named. AFAIU it, it allows 
to access only a part of the ontology, the other part (properties 
cardinality, inheritance tree, etc.) being in the generated classes.

Moreover, I wonder why you use QString everywhere in this class (and probably 
in others). At quite some places you need URIs, so why not use [Q|K]Url? 
AFAIK they should be suited for this.

Finally, I really ponder if your Variant class should be kept. It would 
probably be more consistent with the rest of kdelibs by using QVariant. If 
the only feature really needed is to store Resource instance in QVariant it's 
probably feasible.

Oh and before I forget. Thanks a lot for the good work you've done on this 
topic!

That was my 0.02€.

Regards.
-- 
Kévin 'ervin' Ottens, http://ervin.ipsquad.net
"Ni le maître sans disciple, Ni le disciple sans maître,
Ne font reculer l'ignorance."