Another monday and again the Nepomuk-KDE question

[Sebastian Trüg]

On Tuesday 24 April 2007 18:19:14 Dirk Mueller wrote:
> On Monday, 23. April 2007, Sebastian Trüg wrote:
> > again I am asking if we can merge the Nepomuk-KDE core parts into
> > kdelibs/kdebase. All krazy issues have been solved and during the merge I
> > would remove the rcgen run from the build and just add the few basic
> > generated sources to the svn.
>
> I've not being able to find a high level technical description of how the
> stuff is going to work, so any judgement about wether this fits or not fits
> inclusion quality is going to be difficult. From looking at the installed
> header files, there are no obvious major things to fix, and it looks clean
> and nice to me.

sounds like a good start already. ;)

> From the previous discussion, I was under the impression that you have no
> idea if it is going to remain source or binary compatible over the time of
> KDE 4.x. Is that still the case? This question doesn't seem to be answered

To be honest: I don't know if it will stay compatible. We could certainly try 
enforcing it and only improve on the inside and by adding new stuff.

> right now. If you don't know, I would again recommend to not include it in
> the set of API that is guaranteed to stay binary compatible with the
> release of 4.0. That doesn't mean it can not be a dependency for some KDE
> application though.
>
> > * libKMetaData into the kdelibs (metadata creation and query library for
> > usage in applications)
>
> What can it do right now? What does it depend on? Which parts of kdelibs
> will depend on it in the future? It seems to link kdeui and knepomul right
> now.

It is a convenience library for the creation and querying of arbitrary 
metadata related to some resource. In general you create an instance of a 
class that relates to the resource you are handling and then use the set and 
get methods to work with the metadata. Be aware that I am not necessarily 
talking about the metadata that can be extracted from files (i.e. what strigi 
is handling) but about whatever one can come up with. However, all this 
metadata is intended to be structured according to certain ontologies that 
define which classes (or types) can have which properties or relations to 
other classes.

The idea is to let applications create a graph of metadata (as compared to the 
set of property sets that tools like strigi create) that defines non-obvious 
relations between resources.

Back to KMetaData: all this can in theory be done using RDF by each 
application but that is very error-prone and a lot of code in each app. So 
KMetaData takes care of all the type conversion and proper URI naming and so 
on.

I hope this helps a little in understanding.

> > * RDFRepository service into kdebase/runtime (a Nepomuk-KDE core-service
> > which provides the RDF storage for all metadata)
>
> how does the data storage work?

It uses Soprano to provide an RDF API over D-Bus which basically means adding 
of RDF statements (quadruples in this case, standard RDF triples + named 
graph URI which is also called context), removing, listing, and query 
language support. Yet to do are an integration of a lucene index for fast 
full-text search.

> > * libSoprano into kdesupport (RDF QT/C++ wrapper library, currently using
> > a redland backend)
>
> This will be a hard dependency then for knepomuk and therefore for kdelibs,
> right? How much of nepomuk will work without it? Can applications discover
> existance of the nepomuk service at runtime or is it a compile time
> dependency?

Services can be discovered at runtime and in theory you can do it using plain 
D-Bus. But using knepomuk as a compile dependancy allows to use its simple 
API to access and use the services much easier.