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! ;)

14 thoughts on “The First Nepomuk Workshop – It’s a Wrap

  1. It sounds like the workshop was a great success. It seems many minds were infected/enhanced with semanitic memes. I’m sure this will lead to some great software.

  2. Sweet!

    I’m especially excited about Daniel and Marcel’s work. I love Digikam. I love nepomuk. It was sounding slightly scary that they might not end up talking to each other. Thrilled to hear that Nepomuk will be integrated where it makes sense to the Digikam developers. Yay!

    When Daniel’s removable storage devices work is done, is the milestone I’ve been waiting for to consider my personal desktop search done and ready. \o/ (Though I must say I’m loving it even now… could we have a way to see more than 10 results?)

    Anyway, great work guys. Thrilled to hear that one of the most innovative parts of KDE4 is steaming ahead.

  3. A few questions on the resource URI work:
    “1. All files will have a random URI that never changes.”
    Is this only for files on removable devices or all files on non-removable devices as well?

    “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.”

    Will we have to reconstruct the absolute path to the file with something like nfo:mountPoint + nfo:relativeUrl?
    Will the resource URI for files available via kio slaves continue to use the normal http:/, fish:/, ftp:/, etc.?
    I suppose all apps (including my own) that expect the resource URI will locate the file will have to be updated. Perhaps they could be made backward compatible with an OPTIONAL on the nfo:mountPoint and nfo:relativeUrl in the SPARQL query and little smarts to handle if they’re not available. We might take a hit on the return and display of results though.

    “4. All files will have a link to their storing file system.”
    Could you explain this one a little more?

    Thanks for all your hard work on nepomuk Sebastian!
    :-)

    • 1. yes, all of them.

      3. Yes, this is a little overhead that we will wrap in a nice little class which will cache the information from the service. Also the Nepomuk::Resource class will handle that transparently. So yes, apps need to be ported. I am sorry about this but we figured that the number of apps using their own sparql queries for files are not that many yet. Thus, the advantages outweigh.
      And, no, file resource URIs will be random, thus they cannot be used via the kio protocols. But that should not be a big deal since the file URLs are available and for example the kio search slave will return those.

      4. Well, all I mean is that the file resources in Nepomuk are linked to the file system resources. It actually is a no-brainer.

    • Mhh,

      Sebastian answered already, but anyway:

      ftp:/und http:/ and the like will not get changed, as they are not “local” files. It is only for files with file:/ meaning all under / of the “local” file system (also nfs mounts and so on).

      And hopefully there are nearly no changes needed for most of the Nepomuk using applications. And if so, they should be quite easy. (I am willing to help on that if there are problems).

      If you still have questions or concerns on that, please explain further how you use Nepomuk (why sparql queries and for what) on the Nepomuk-KDE mailing list. Hopefully we can find a way to make the transition easier for you. (and it could help to better understand where there might be problems)

      Daniel

  4. Pingback: Chimaera & Bellerophon » Blog Archive » E due!

  5. Pingback: Raptor & Nepomuk-Meeting « Boom1992’s Weblog

    • English when speaking to a group where at least one could not speak the speakers native language.

      When only speaking with someone who speaks the same language their native language (German mostly here, because about the half of us were german).

      So, if that is your question: You do not need to know german to go to such an event. But well, you need at least some basic english.

      Btw: I still feel a little insecure when speaking english. So I am more quiet than usual in such situations. (and a few beers or free tequilas can help there *g*)

  6. About the digikam integration, it’s great that someone works on it, but what happens if I directly modify the digikam database? (without using the digikam interface). Would that require another step to request a synchronization to nepomuk?

  7. Pingback: Chimaera & Bellerophon » Blog Archive » GSoC, week 4: minor improvements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s