GSoC: PIM, Nepomuk and Telepathy

So I've made it into GSoC this year and I'm very grateful to all those who put faith in my project proposal. For those not yet familiar with it, let me introduce it to you.

Nepomuk is being used more and more by applications and is becoming a corner stone of KDE. Simply speaking, Nepomuk is an independent storage service, where any application can save its data and any other app can access any data stored there. All data are "standardized" by ontologies - basically a dictionary with set of rules and relationships. So if one application stores for example emails into Nepomuk, another application can access all emails using an Email ontology. 

That's where Akonadi comes into play. Akonadi is a central storage service for PIM applications. It stores and manages your emails, contacts, calendar events etc. These are very important and useful data and it's highly desirable to make use of them in other parts of the system. Thus they are feeded into Nepomuk, which then serves as a point of entry for getting PIM data from another applications. Of course you could use Akonadi directly in your application, but since Nepomuk is becoming the "inter-app-storage-component" and it basically tries to model real world, it's a logical step to put them there.

Once the data are stored in Nepomuk, any application can make use of them. For example Telepathy, the IM framework - in your contact list you have bunch of people, with whom you can chat, send them files or make a video call. But we can also load PIM data for your contacts from Nepomuk and extend the capabilities to sending emails, creating a calendar appointment or whatever you imagine. And conversly, if we feed Telepathy data into Nepomuk, PIM can grab these data and show you presence status of your contacts in addressbook or in KMail.

All in all, you'll get a truly integrated desktop.

But the road there is still a bit long. Akonadi currently feeds into Nepomuk only raw contacts themselves - NCO:PersonContact in ontology language. Which is ok, but it misses something. NCO:PersonContact is just an information entity. And to have something more useful, you need to connect the corresponding entities which model one real-world object, into something higher. That's a PIMO:Person. Think of PIMO:Person as a real-world friend of yours. He has several emails, two IM accounts, three phone numbers and you also have his home address. And every single piece of these data are represented by one NCO:PersonContact. So you have about 10 entities belonging to the same person.

Part of my project is to find such entities and bring them together under one corresponding PIMO:Person. This is not an easy task for automated solution, because it may be very hard to find related entities or because the given entities does not really describe a Person (mailing-lists in your addressbook etc). So the automated part will do as much as it can (read "if we are completely sure these entities are related, we'll connect them"), the rest will be up to the user. There will be a GUI, which will allow you to view your NCO:PersonContacts and in a simple way let you mark them as one Person. You should also be able to remove entities from Person, which were wrongly associated.

Current state of things

Nepomuk in KDE 4.7 comes with new datamanagement api (DMS), which brings several cool features making life easier. So the first part is rewriting akonadi-nepomuk-contact-feeder to use the DMS. This is basically done and working, although it's not yet on par with the old implementation (some properties are currently missing).

Next step was Nepomuk service, which is running in background watching for new NCO:PersonContact coming from Akonadi. If it catches one, it queries Nepomuk for similar or same NCO:PersonContact which already exists. If there is one and both have the same email address, they are merged into one NCO:PersonContact. Then it looks for related contacts, currently it searches only by name. If we have two or more related NCO:PersonContacts, a PIMO:Person is created with these contacts. This is already working pretty nice, except the detection of new added contacts, this has still some problems.

Today I've written a very simple tool, which lets you browse your PIMO:Person and see all the contacts associated with it. It's basically a debug tool, but may possibly one day evolve into KAddressBook2. Although that would require a Nepomuk-Akonadi writeback feature, which is currently missing.

The future

The nepomuk service will keep expanding with more complex search rules than only a name. It will very likely be divided into a lib part and a service part. The lib will then be reused in the merging application, which I'm planning to start working on sometime next week. The library (and the service) will need some heavy thorough testing, so making this right will probably take most of the time.

...and Telepathy?

Here comes a real use case. In KDE-Telepathy we already started to put Nepomuk side of things into motion. We'll switch the list from Telepathy data to Nepomuk PIMO:Person data soon. You probably see the connection now. Yes, it is the same PIMO:Person which is being created by the Nepomuk service. The merging UI as well as the service will be able to merge a PIMO:Person coming from Telepathy with PIMO:Person coming from PIM and make them one, just like in real-world your IM contacts are the same as some of your PIM contacts. Therefore both sides will get features of the other side. Emailing from Telepathy and chatting from PIM. Well not exactly, but once you have the needed data, nothing is keeping you from opening a KMail window from your contact list or starting a Telepathy chat window from KMail. And that's not the end of it. Any third-party app can take these Persons and make other interesting things with them. For example a Person plasmoid, which will give you possibilities to write your friend directly from desktop. Or tagging these Persons on your photos from DigiKam. 

Give me the code!

All is in git.kde.org, but you need latest KDE compiled from git (with working Nepomuk, Soprano and all that fancy stuff), then you need to compile kdepim-runtime from my clone (branch nepomuk_feeder) and then you can grab the Nepomuk service from my scratch repo. And lastly, the PersonViewer (as I call it right now), is also in scratch repo. 

I wouldn't advise you to actually use it as it may currently make a bigger mess in your Nepomuk database :) But if you're brave enough, compile the kdepim-runtime, restart Akonadi, compile the service, restart Nepomuk Server (or just run the service by "nepomukservicestub nepomukpimmergeservice") and then you can open the PersonViewer to see any created Persons (works only if you have more contacts with the same name).

That's all for today, stay tuned..

Comments

[Venky80.wordpress.com]

hey that was an amazing article, cannot wait to test the person based contact list

[Kyriakos Brastianos]

Amazing Stuff! I Am very excited about this project. Cant wait. Do you think we will be able to see under a contact streams of updates from services like linkedin, facebook, twitter, identi.ca etc. with a combination of nepomuk zeitgest and telepathy libfolks?

[Marty]

@Kyriakos Brastianos - great use case! Basically yes, it would be possible, you would only need some services, which would feed this data into Nepomuk/Zeitgeist, then it's pretty easy to get them out for example in Telepathy :)

[www.facebook.com/profile.php?id=564946412]

hey...thats really a cool feature...I'm looking forward to it and can't wait :-)

[Eike Hein]

Thanks for this blog post - looks like this will be the future way of doing the KAddressBook integration we currently have in Konversation, KDE's dedicated IRC client.

In the KDE 3 days we also had similar cross-app presence stuff using the KIMProxy system, which sadly didn't make it to KDE 4.