Active building blocks: Nepomuk

BlaBla

As said by the title of my last post, one of the things that we are trying to do with Active is “humanizing electrons”… make devices behave how people think instead of making people think like the implementation details behave.

To do that, it is necessary to phase out or better, demote and have in a less prominent way some of the concepts that always been with us, but not because they were good, because for tone technical reason or another 20 years ago we were forced to do this way.

Here we aren’t forced to follow the legacy, and the acquired skills that limit what can be changed on the desktop, on this kind of devices we have almost no legacy. (don’t worry, there won’t be a fresh start in the desktop, only continuous evolutionary changes)

  • Why I have to care what is a “file” and what it isn’t aren’t pieces of information all the same? i couldn’t care less if a contact or a bookmark are stored in a different way than a pdf.
  • Why I have to organize my things in a weird tree structure, data type that in the human brain simply doesn’t compute?
  • Why I see arcane names like /usr, /etc and /dev that are simply pointless in my day to day work?
  • Why if i subdivide my files by project, a file can’t be in two projects unless i do a copy that will go out of sync?
  • I want to be able to annotate every thing, to be able to remind me what this is about and why is there (informations that would be unwanted in the file itself tough)
  • Why if the mail application has informations about a contact, this information is buried in this application and everything else can’t have it?

nepomuk

This list could go on for many more points, but i think the concept is clear: while tools like the filesystem are awesome if well used, but aren’t enough anymore for the amount of data nowdays (yes i know, there will always be people that won’t need this, but this is true for any tool in existence).

In Plasma Active we base our graphical representation as much as possible on activities and on what “things” belong to an activity.

We try to make as less difference as possible between what is a file and what it isn’t.

This was only possible because one of the pillars of KDE: Nepomuk.

Nepomuk provides a metadata storage that is abstract enough to do almost everything you please with it. Everything can be a resource: being files, contacts, urls, places or activities. And everything can be related to everything, and here we have things related to activities, or between themselves (who sent to me this file as attachment?)

Sadly, in the desktop is still not used much, apart some pieces of ui to expose its features here and there (good news, getting better here too), but as Plasma Active shows, if the whole UX has its capabilities as the foundation, it can change the way the device is used in a way that surely wouldn’t be possible without it 😉

Another good news, is that while some pieces of Plasma Active are specific of a device UX, some other parts, like the enhancements to the activity manager are shared with the desktop, so should be easy to expect some of those features, like an UI for connection between resources and activities soon in the desktop as well.

8 thoughts on “Active building blocks: Nepomuk

  1. .wu

    “Why I have to organize my things in a weird tree structure, data type that in the human brain simply doesn’t compute?”

    Then I’m not human, because for it’s very useful (I have a mild case of OCD) and…

    “This was only possible because one of the pillars of KDE: Nepomuk. […] Sadly, in the desktop is still not used much”

    I don’t use Napomuk (hate it!) because it’s simply gets in my way (it’s there even despite my complete detest for it without any means to eradicate it)…

  2. renoX

    Frankly I think that you should be more careful about this kind of post, it looks like you’re overselling nepomuk:

    > aren’t pieces of information all the same?

    No they aren’t because some program understand piece of informations stored in a specific format but not in another format. Like all the applications, nepomuk have the same issue.

    > Why if i subdivide my files by project, a file can’t be in two projects unless i do a copy that will go out of sync?

    Well there are things called links (hard/soft) for this..

    That said, I agree with you that the tree hierarchy is not a good thing and that it should be replaced by tags.

  3. Dion Moult

    I find myself wondering why Plasma Active gets the priority for useful semantic features and KDEPIM app development rather than the Plasma Desktop.

    Plasma-desktop itself needs a bugfixing sprint just as the semantic tech currently is.

  4. Philippe Clérié

    Hello,

    (Sorry! Long post)

    First, let me say that I appreciate very much the work that you and others are putting in KDE. I should know. I’ve been using it for the past 10 years or so, since, I think, version 1.1. I recall compiling that on a Leading Edge 486-33 computer. I’m still using KDE. I even submitted myself to the early pain of the 4.x series. However I am preparing to choose my poison: KDEPIM for example is not in my future because of Akonadi and Nepomuk. At least for the time being, neither has been any use to me at all. Nevertheless, KDE developers are betting a lot on these technologies, and, it seems to me, if I am to have any future with KDE, then perhaps I should at least speak up.

    You ask some great questions that probably go to heart of what Nepomuk is all about, but I still have some problems with them.

    Files? I will concede that at one level any piece of information is just a blob of bits, and any meaning they have is what we impose upon them. At this point in time, to any OS, a file is just that: a blob of bits. One way or another, you too will have to store these bits. So why is the file not up to the job? It obviously is!

    But you are not interested in the bits; you are interested in whatever they mean. That’s what you really want: extract the meaning of the bits and store that somewhere. You call the meaning metadata and you have rules to extract it, and finally you store it as… another blob of bits, that has to managed, indexed, updated, deleted and understood. For that you use a database which itself uses… files.

    The database introduces a level of indirection that may or may not be useful. It’s just that I’ve never had a use for it, so I don’t much care to have something running on my computer that I have no use for. It’s been argued that Nepomuk is optional. But it’s also very much a goal of at least some KDE developers to deeply embed it in KDE. It sounds like it’s required for Plasma Active.

    Furthermore, for Nepomuk to be at all useful, it seems to me that the user should make the effort of tagging the files. Otherwise, any search is bound to return mostly irrelevant data, much like Google does. On the other hand, tagging might not be any better, because relevant data may not be returned because it wasn’t tagged properly. Whatever the case, manual tagging would make the database considerably more valuable, because, who’d want to do the tagging all over again in case of database corruption or loss. Somehow I don’t think a simple file copy, as in any use of tar or rsync, would do the job. Here, I am really confessing my fears rather that something I know. I haven’t seen this addressed anywhere yet, that I am aware of.

    Pending a better solution, that tree structure you dislike is quite useful. And for the purposes of Nepomuk, those arcane names should be outside its sphere of control. It only needs to concern itself with what in the home directory of the user, and any other place designated by the user. System directories should not be part of what Nepomuk indexes. Here again, I have yet to see a convincing explanation of just how Nepomuk is going to make things better.

    As for file annotations, I see no reason at all why they could not be stored with the file itself. As a matter of fact, it’s been my understanding that the extended file attributes features in the newer filesystems could very well do that job. The trouble is that the standard utilities don’t make use of xattrs so we just aren’t used to them. I don’t really know what the limitations are. I would argue however that annotations, tags, metadata and what have you are better placed within the file rather than in a separate database. Then, the metadata would move with the file instead of being a distinct operation.

    Having said that, I should add that I have been using computers for all of 35 years. That dates me and I have no doubt that age is at least in part a reason for resisting Nepomuk and Akonadi. They do challenge my esteemed habits and at this point, I’d much rather coast along using what I already know.

    A second caveat is that I do believe you should continue work on these technologies. They may yet turn out to be the great stuff you think they are and at the very least Nepomuk is an idea that is worth exploring. What I would ask though, is that you remember those of us who are comfortable with the old ways. Please make sure they are optional.

  5. Guillaume Ponce

    I’m really interested in this facet of KDE because I feel that it’s where it (KDE) is really leading innovation, all plateforms considered, free or proprietary.

    On what you wrote about tree structures, I totally agree with you.
    I regularly wonder how I should organize my home directory, if those XDG recommended directories for documents, music or whatever are relevant to me.
    Basically, the conclusion is always that I’m trying to fit a graph into a tree… which is not without caveats.

    As I don’t own a device suitable for Plasma Active, I’m experimenting with what is available as in Plasma Desktop.

    Still I have some concerns. As one of the previous commenters in this post mentioned, manual tagging is investment (you invest time and you invest the fact that you adapt your workflow to rely on it).
    So I’m concerned with the perenity of this investment.

    What if I have to reinstall my computer? I’d really like to be able to back-up all those wonderfull metadata, so that I can restore my workflow as well.

    And what if I have several computers with, partially, the same pieces of information? It would be nice too be able to share these metadata with my different system.
    The answer might be convergence with ownCloud?

    Nevertheless, I am confident that solutions will come as those technologies mature.

    Thank you for making all this happen, we sure live interesting times for anyone interested in UX innovation.

  6. Essay Examples

    Well there are things called links (hard/soft) for this..
    I would just add that Sebastian Trueg needs some help to continue the development of Nepomuk. See his blog post here:

Comments are closed.