NEPOMUK-KDE next step and real KDE integration

[Sebastian Trüg]

Hello everybody,

** Please only discuss this matter on the nepomuk-kde list **

it has been a while since my last announcement and we have done mostly 
backbone work which implements the basic communication defined in the NEPOMUK 
project.
Now I think we are at a point where we can take the next step and start the 
actual KDE integration.
What does that mean? Well, in my mind it looks something like this: 

libksemantic (or libsemanticKDE or semantiK ;) you choose
=========================================================
libksemantic is a library which allows each KDE application to create and 
query semantic and meta data on the desktop (and thus in the Nepomuk-KDE 
system).
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.

I imagine a very simple layout of the library (please see attached rough class 
diagram):
Everything is represented by a Resource subclass. A Resource has certain 
properties which represent the semantic and meta data. Each property is a 
QVariant (yes, too much detail ;) which can either contain a simple type or 
another Resource. Resources are identified by their URL (the final URL scheme 
is under heavy disucussion in the Nepomuk project at the moment and input is 
needed) and kept in sync all the time. That means if you create two Resource 
object referencing the same resource they share their data and changes.
Now creating semantic data is as simple as creating a Resource object with the 
URL of the resource and setting some properties. In the default scenario the 
information will be synced automatically. Retrieving information is as 
simple: just create the Resource, the information will be gathered 
automatically.

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.

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

Have a nice day,
Sebastian Trueg

http://nepomuk-kde.semanticdesktop.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: class diagram.png
Type: image/png
Size: 19505 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20061122/432eb13e/attachment.png>