Randa and Ontologies and whatnot…

So I am back from Randa, the small town in the Alpes where roughly 60 KDE hackers (and 2 Gnome people) met to achieve great things. Before I start raving on about Nepomuk and ontologies and all that jazz let me thank Mario Fux and his family for the great organization and the fabulous food.

Now that the pink fluffy bunny part of the blog post is done I can get to the real thing: Nepomuk. The guys (Daniele E. Domenichelli from Telapathy-KDE, GSoC students Smit Shah and Martin Klapetek, Ivan Cukic, and Seif Lotfy and Trever Fischer from Zeitgeist) and me met in Africa (for the unaware: the rooms in the house in Randa are named after continents). I gave a few short tutorials on Nepomuk, its design, the basics like RDF and how it is used in Nepomuk, and the new Data Management Service (which I still did not blog about yet – but it will come, give it time). Then I answered questions and helped with the individual projects.

Apart from the discussions on KDEPIM and Telepathy integration two topics stand out: 1. The new and improved Documentation for the Shared-Desktop-Ontologies and 2. The integration between the KDE Activity Manager, Nepomuk, and Zeitgeist.

New and Improved SDO Documentation

One thing I wanted to do while in Randa was improving the documentation for Nepomuk. Well, we did not really look much into Nepomuk’s own documentation but Daniele E. Domenichelli (Telepathy-KDE hacker and former GSoC student) and myself finished what I started a while back. We finished the script which extracts all ontology entities from the sources and generates nice docbook references. We split the manually created docbook documentation into subfiles which are combined into one docbook chapter per ontology. Then the chapters are merged into one big file which is transformed into html via xslt. All is streamlined through the cmake build system’s “docs” target. Thus, everyone can easily create their own ontology documentation at home. If you do not want to do that but want to check it out anyway without waiting for an update on semanticdesktop.org just use the oscaf project’s page which now contains this documentation.

Integration Between KDE Activity Manager, Nepomuk and Zeitgeist

Zeitgeist is an interesting project which in its topic is closely related to Nepomuk: Zeitgeist tracks events on the desktop and stores them in a database which can then be queried by clients. This allows for example to see which files you touched in the last week and track the history of a single file (here “history” refers to the modification events, not the content). Lately Zeitgeist developers have moved closer towards KDE and shown a lot of interest to work with us. At Randa we finally came up with a good plan to do so.

The problem is that KDE already has a database to store all kinds of information including events: Nepomuk. And KDE has the KDE activity manager whose API is supposed to be used by KDE applications to inform about opened/modified/closed files. Thus, we had three things to bring together: Zeitgeist and its application plugins which inform Zeitgeist about events, the KDE activity manager which does the same thing for KDE applications, and Nepomuk as the one semantic database in KDE. Thus, Seif Lotfy (Zeitgeist founder), Trever Fischer (GSoC student doing a Zeitgeist GUI for KDE), Ivan Cukic (Author of the KDE activity manager), and myself discussed the different issues heatedly and actually came to a conclusion.

The basic design will be like this: KDE applications will use the KDE Activity Manager Daemon (KAMD) API to inform about opened, modified, and closed files. The KAMD will then send these events to Zeitgeist which will apply all its magic (blacklisting, geo location attachment, and so on). Finally Zeitgeist will store the events in Nepomuk. If Zeitgeist is not available KAMD will push the events to Nepomuk itself.

Integration between KAMD, Zeitgeist, and Nepomuk

This way we benefit from Zeitgeist’s additional event processing and its integration into applications like OpenOffice or even vim.

Update: Ivan told me that he has a much nicer diagram. And in fact he has. His looks like a mutated bunny with one Gnome and one KDE ear:

Ivan is the master of simple diagrams (mine are always too complex)

We also had to merge ontologies. Zeitgeist has its own event ontology which is built upon the Nepomuk ontologies. We tried to merge as much of it into SDO as made sense. The result can be seen as a separate branch in the SDO git repository. We decided to store usage events as follows:

Usage Events in Nepomuk

If looking at the example of a file being opened NUAO models one main event which stretches from the time the file is opened to the time it is closed. This is described via nuao:UsageEvent and the properties nuao:start and nuao:end. During the time span of this event the file can be in the focus of the user or not. This is modelled via nuao:FocusEvent instances that describe when a file was in focus.

Since the action of modifying a resource is a very foggy concept and hard to fit into an event with start and end time it was decided to instead only store a timestamp for each modification of the resource. This is described via nie:modified and nie:contentModified. For file modifications one would typically use nie:modified.

Storing all focus events in Nepomuk will most likely result in an ugly amount of data which does not provide any really useful information besides the total time a resource was in focus. Thus, we introduced nuao:totalFocusDuration which allows Zeitgeist to compress all focus events and attach this resulting duration to the enclosing nuao:UsageEvent.

Well, that is it for today. Aaron urged me to write a dot article about Randa so I will probably try to do that (he says vaguely).

The Next Nepomuk Event – It Is About Time

The last Nepomuk sprint was a rather long time ago. And as the title says it is time for a new event. You want to learn about the benefits Nepomuk and the semantic desktop could bring to your application, what new types of applications and tools could be built on top of Nepomuk, and how to use Nepomuk in general as a develop? Then you should register for Randa 2011 and join us from June, 1st to June, 7th in Randa, Switzerland.

Learn about storing and querying metadata, about remembering usage statistics, about using Nepomuk as your application data storage, about integrating Nepomuk in simple scripts, and more.

Mario Fux is the one organizing this joint-event which will host tracks on Amarok and KDE multimedia in general, KDevelop, Nepomuk, and Platform 11.

The full schedule and list of talks and workshops is not complete yet but will be released soon.

What happens if Mr. Nepomuk meets a bunch of Telepathyans?

A fun and very productive weekend is what happens!

Yesterday evening I came back from Cambridge where I attended the Telepathy-KDE sprint (note to self: never again fly with easyJet) which was smoothly organized by George Goldberg. A lot has already been said about the work at the sprint: Daniele “drdanz” Domenichelli provided us with nice pictures (I am looking really weird in the group photo), George Kiagiadakis gave a nice overview, and George G. himself spammed identi.ca with tons of comments on the sprint. Thus, obviously I will focus on the Nepomuk parts of the sprint.

Since George G. and, thus, Telepathy-KDE is one of the most fearless (as in: does not fear to try all the broken Nepomuk features and then ask me to fix them) Nepomuk users/developers he had a list of topics for me to look at. There was the issue that the query service did not scale since it created a separate thread for each query. I quickly fixed that using QThreadPool and a predefined number of query threads which made the contact list populate correctly.

Apart from that George has his own extensions to NCO which provide everything Telepathy-KDE needs to store all (!) its data in Nepomuk. He wanted me to review them again along with the data libktelepathy creates in Nepomuk. Most of it looks very good – but as I said George has been spending quite a lot of time understanding Nepomuk – not only at the two sprints. Thus, we should merge those extensions into NCO as soon as possible.

But his biggest problem was a missing GUI tool for debugging the data in Nepomuk. Thus, I sat down and fixed Nepomukshell. And as soon as I decided that it should be a developer tool and not an end user targeted application things got very easy. Nepomukshell is now “NepSaK – The Nepomuk Swiss Army Knife” (with a capital K because sometimes I like to be old-school) and has three modes: resource browsing, SPARQL querying, and resource editing. The code can still be found in playground – I will try to release that soon – and it depends only on the nepomukextras library. Since we all like looking at pictures I will show you some instead of explaining the features in detail.

It will eat your cat!

Browse resources via the class tree

Quick and dirty SPARQL querying - sopranocmd in a GUI

Edit resources without any clutter (or convenience for that matter)

This little tool should make life for us a bit easier. And it will probably grow over time providing all kinds of debugging and maintenance features.

Gran Canaria Desktop Summit 2009 – The Nepomuk Perspective

Now I can look back and say: “I have been there. I have witnessed the first joint conference of the two biggest players in open-source desktop software: KDE and Gnome.” And I can tell you: it was good. I personally think it makes a lot of sense to have the conference together. After all it helps a lot in creating inter-desktop relationships and projects. A topic that is especially interesting to me since the Tracker project is also going towards the semantic desktop these days (and dare I say it is as a result of our work?) and carries in its wake projects like Beagle or Zeitgeist. Thus, the GCDS was an opportunity to meet with people from Tracker to discuss some of the many topics we deal with every day. I also had the opportunity to meet some KDE newbies, eager youngsters wanting to work on KDE and also Nepomuk. I was, of course, delighted. One idea floting around at a party in the evening was the smarter caching of thumbnails using Nepomuk information.

Anyway, I am a technical blogger, a geek struggling to deliver the cold facts (and failing later down this very page). So let’s look at the GCDS from a more technical point of view:

Shared/Desktop/Nepomuk Ontologies – In Agreement

I meantioned already that I met with a bunch of the Tracker guys and had some nice chats (this is really not a cold hard fact now, is it?). We discussed a possible shared D-Bus API for metadata storage on the desktop which looks like a project for next year and we also discussed and agreed on the shared ontologies project. Now, the ontologies have been a problem for a long time. I already blogged about how the Nepomuk vs. Xesam discussion was settled. We discussed the problem in length on the Xesam mailing list. We created the OSCAF project on sourceforge and even moved over the Nepomuk ontologies from the Nepomuk dev server. But there was no consensus so far. No real development took place. At the GCDS we fixed that. We agreed on a layout for the subversion repository, on a packaging structure, on a file format, and even on a name for the package (we will call it shared-ontologies to match the already existing shared-mimetypes package). After we settle the last tidbits we can start tackling those problems we already have in the bug tracker and get the Nepomuk ontologies ready for shared usage in KDE and Gnome.

A Talk About Practical Nepomuk

At Monday evening I had my talk about Nepomuk. I tried to give a more practical talk which followed a simple outline of three main points:

1. Why should I use Nepomuk?
2. What should I use Nepomuk for?
3. How should I use Nepomuk?

I think this went quite well except for the fact that I am pretty sure that I was robbed of a couple of minutes. I don’t think that I spoke for half an hour. So we did not have much time for questions in the end which was a pity. I am pretty sure we could have had a nice discussion. Well, there will be more possibilities for that soon (see below). Apart from my talk Laura Dragan gave two lightning talks about Konduit and Semnotes and a talk on her new project: semantic context menus in KDE.

The Place of Nepomuk in KDE’s Future

Nepomuk was mentioned in quite a few talks. It seems people are slowly adapting to the ideas and wanting to integrate Nepomuk features (not only the almighty Akonadi-front). This was also backed by Sebastian Kügler’s keynote on The Momentum of KDE. He talked about the achievements of the KDE project in the last year and what is targeted for the coming year. He mentioned a survey Aaron made and which included that roughly half of the KDE projects he interviewed have plans to integrate Nepomuk in some form. And then suddenly there was one slide which had only two things on it: 1. the Nepomuk logo and 2. the words “Semantic Desktop”. And as if that was not already enough of a booster for my ego he asked me to stand up so everyone could see me. Now this is the part where I derive from my righteous path of hard cold facts and wander into a realm of egomania: it felt good.

Well, come back down here brain. Let us tell the nice readers the really good part: there is funding for one or two more Nepomuk workshops this year! I am very excited about that and cannot wait to get started with the planning for the next one (probably sometime in September taking place in Paris). So if you missed the first workshop or thought it was not for you, maybe the second one is!

And finally: the social aspect

I told you I would fail. I simply have to tell you how nice it has been to see so many familiar faces, to meet so many new people and to finally have a face connected to an irc nick or an email address. I am sorry that I could not properly say goodbye to all I would have liked to. So please know that I was happy I was to see you and hope to see you again soon. Maybe at the next Nepomuk workshop.

Sharing my Brain – Another Result of the Nepomuk Workshop

If I learned anything at the Nepomuk workshop it is that too much information is just in my head and nowhere else. I tried to share it by writing API documentation and tutorials and blogs. But it never is enough. So today comes another dump from my brain: Nepomuk tips and tricks, a new chapter in the Nepomuk tutorial series. I hope it helps you to make more of the technologies Nepomuk provides.

The First Nepomuk Workshop – It’s a Wrap

The first Nepomuk workshop and the first KDE workshop held in Freiburg ever is over. It was great but short. I could have worked on with these guys for much longer. It was a lot of fun to explain the Nepomuk ideas directly and having people not only listening but also understanding and realizing them.

On Friday we started out slowly. Due to different travel times and also some stupidity from travel agencies and German bus drivers we were only complete at around sixish. To get in the mood I had everyone explain what they wanted to achieve over the weekend or what they thought could be interesting to work on with Nepomuk. The beginning was not easy, at least I feared that we would have trouble to actually getting to work. After all, you do not start to work with Nepomuk just like that. It is too confusing and different for that. But the ideas were very good and the people very interested and eager.

So on Saturday my fears of me not being able to handle it were vanished. I explained about PIMO (just to confuse everyone for real) and showed what I had done with respect to NLP in the Scribo project (Tom already mentioned it in his blog although he confused it with PIMO. No big deal, there are way too many project and technology names to get mixed up). Sebastian Faubel showed his very interesting work on a replacement for the Gnome open and save file dialog. He also uses RDF to store meta data and then based on that decides on a location for the documents in a fixed (not really fixed but based on a template) folder tree. After that coding began.

What did we do?

Well, I did not really code anything. There was no time for that. I was too busy discussing with and helping the others. And they did do cool stuff. Let me start by mentioning my hero of the weekend: Tobias König aka tokoe. He wanted to improve the performance of the Akonadi Nepomuk feeder agents which export contact and email meta data from Akonadi to Nepomuk. He did that by introducing a new fast mode into the nepomuk resource generator. Now he would not be tokoe if he would not have been shocked by the hack that is rcgen. So over the weekend he cleaned it up. He cursed, he sweated, he nearly went mad, but he did it! And since we defined it as a bug fix it is even in 4.3. Great work, Tobias.

Then there was Tom Albers. Now he already blogged about what he did himself. But I will summarize it anyway: he actually dared and integrated the Scribo-based annotation suggestions into Mailody. I will blog about details on that later. But the idea is that the email body is analysed and a plugin system generates possible annotations such as dates, cities, persons, and also possible events that are mentioned in the email. Not only did he integrate it into Mailody, he also found two bugs that would have been showstoppers for the Mandriva Scribo demo yesterday. So thanks a lot, Tom.

Raptor. Now Raptor is a cool project. Raptor sets out to replace or provide an alternative to Kickoff. And their idea for Nepomuk integration is to remember the launches of applications. For starters “only” when an application was launched. This then allows to show more frequently used applications with bigger icons. But it will not stop there. Application launches can be linked to the current context (or the current Plasma activity). I might use KPresenter at work all the time but never at home. Also it would be possible to link files to the application launch that was used to open them. And so on. Alessandro, Francesco, and Lukas quickly understood how to create and ontology and use it in KDE. They now have their dedicated application launch ontology and use it via the Nepomuk libs in Raptor. I hope that the ontology can at some point be made into somewhat of a standard in the desktop ontology project.

Daniel, while normally being an Amarok developer (he did the Nepomuk integration in the GSoC last year), was very eager on making Nepomuk really useful on the basic level. So we discussed handling of removable storage and nicer resource URI design a lot. In the end we decided:

1. All files will have a random URI that never changes.
2. All file systems will be represented in Nepomuk with their mount point and their mount status (Daniel already started working on the service that handles that. Also the tracker guys are working on something similar. Matching the ontologies should be fairly easy as the concepts are the same.)
3. All file URLs will be relative.
4. All files will have a link to their storing file system.

This helps in solving a bunch of problems. Files on removable storages like USB sticks which can be mounted in different places are handled the exact same way as files on local file systems. Moving a file in most cases only means to update one property: the relative URL. Only if the file is moved to another file system that link has to be changed, too. Through the mount state flag on the file system in Nepomuk it is very simple to see if a file is currently available or not. A search client can simply tell the user that they have to mount the file system in question to access the file. I think this is a fine solution and since I tried to design everything without relying on the file resource’s URI being the file’s URL the transition should be fairly simply. A goal for 4.4.

George already blogged about his Nepomuk integration work with Telepathy. What is so great about his work is that he actually uses PIMO in a productive way: one PIMO Person represents one person that can be contacted via Telepathy. And this one pimo:Person has a set of occurrences being the actual contacts like jabber accounts and so on. Thus, if you want to chat with a person you simply click their icon and Telepathy will open one of the available systems, depending on their online status. One could even think of email as a fallback. I find this especially interesting since it so clearly uses the two different layers of information defined via the PIMO ontology: on the lower level we have all the desktop resources like files and emails and jabber accounts and so on. And on a higher level we have all the real world entities like the actual person or a project or a city represented by PIMO concepts. I hope that we will see more integration like this is the future. (I know, I know, I need to write better documentation on this.)

Marcel worked on the Nepomuk integration in Digikam. Since the Digikam team does not want to entirely rely on Nepomuk yet (with it being optional and all) he created a Nepomuk service that keeps the Digikam database and Nepomuk in sync. So rating and tagging your images in Digikam would directly be reflected in Nepomuk and the other way around. Very nice. I hope to see this hitting a stable release soon.

I had hoped to have more time to work with Peter on the meta data display in Dolphin. But sadly that dropped under the table a bit. But I was at least able to show him my crappy formatting rule system I drafted a while back and we cleaned up the display a bit: nicer labels and less useless properties shown.

What did we look like?

What about the future?

I hope that we can do this again soon. I think it was really worth it and am very happy to have done it. Thanks again to all of you. You made this a successful event.

PS: I wanted to blog earlier but first I had to sleep for two days straight. I am too old for this shit! ;)

It is About Time – The Nepomuk Coding Sprint

The title says it all: it is about time we had a Nepomuk workshop. As I already wrote on Monday I am planning a Nepomuk coding sprint. The idea of this sprint/workshop is to invite developers looking to integrate Nepomuk into their application. It is not intended for people who are “just” interested in the technology. A really focused and productive workshop with roughly 10 developers is what I have in mind.

Goals I would want to achieve in the Nepomuk sprint:

• Useful Nepomuk integration into all attending developers’ applications
• Attending developers become Nepomuk “experts”
• A How-to for other developers to integrate Nepomuk in applications (based on examples)

The workshop will take place in Freiburg:

Don't miss a trip to Freiburg

No final date has been set yet. Possible dates include 29.05.-31-05. or 13.06.-14.06. But this is still open and can be discussed once a list of participants has been gathered.

If you are interested in participating in the workshop, please subscribe to the Nepomuk-KDE mailing list and give the following information:

• Application affiliation (it is important that apart from Nepomuk there is nothing that you need to learn in order to work on the app)
• Preferred date (if none is suitable propose another)
• Do you need funding for travel and accommodation?
• Are you interested in a social event on day four (rock climbing or something similar in the black forest)?