NEPOMUK-KDE next step and real KDE integration

Jos van den Oever jvdoever at
Thu Nov 23 20:44:31 GMT 2006

2006/11/22, Sebastian TrĂ¼g <strueg at>:
> Hello everybody,
> ** Please only discuss this matter on the nepomuk-kde list **
Ok, i'm being disobedient. I've not seen a single mail fly by on the
nepomuk list and would like the kde people to be aware of the efforts
done in this area, so i'm simply replying here.

> In the first phase it mainly communicates with a local RDF store (which is
> implemented as a NEPOMUK-KDE service). This store contains all the
> information. This also includes indexed data from strigi (Jos, I know you
> think the RDF store is too slow for your indexer but we have to keep the
> first phase simple to have results fast), contact information and so on (to
> the KDE-Pim guys: yes, I think for now we will simply duplicate the data you
> keep in Akonadi if necessary. We will have to talk about better solutions
> later). Semantic data for now means tags and annotations, i.e. comments for
> files, emails, contacts, and so on.
If you're intention is to change the store in the medium term, I'm
fine with this. How will you put the data in there? Will you implement
the store as a Strigi backend or use Strigi's xmlindexer?

> At aKademy in Dublin the idea came up to replace KMetaFileInfo with strigi. I
> think libksemantic could do a good job here. Just create the Resource object
> for the file and get all meta information gathered by strigi plus other
> semantic information.
Sounds good. Will you implement a kfile plugin that does this? That
would be a good light starting point. I'm working on making the
metadata extraction configurable in the sense that you can configure
which fields to get out and which not. One might consider adding a
specifier that says the maximal cost of the things to extract in a way
similar to how KFile does this. This is however not very important for
a first version of a nepomuk+strigi kfile. If the KFile works well, we
can start porting the existing kfiles to strigi's analyzers, so that
these properties may be indexed.

> Well, so much for the next step I have planned. As I would love to see this
> integrated into KDE, please comment, discuss, and provide ideas.

> ** Please only discuss this matter on the nepomuk-kde list **
Sorry ;-)

More information about the kde-core-devel mailing list