Nepomuk in the Google Summer of Code 2009


Like last year and the years before that KDE participates in the Google Summer of Code. And like before project ideas are gathered independent from the Google process on techbase. And like last year Nepomuk will be part of the KDE projects proposing ideas. This is where you come in! I already posted two ideas in the list (scroll all the way to the bottom). That is not enough. I will try to come up with more but I think you have way more ideas up your sleeves (I noticed that much in Oslo where we had a lively discussion about the topic).

So, this is the opportunity to comment on this blog post and give your ideas for GSoC Nepomuk projects. You can, of course, even post the ideas directly on the techbase page (but then you should be available to mentor, too ;)

Thank you for your input.

10 thoughts on “Nepomuk in the Google Summer of Code 2009

  1. As far as I can tell, Nepomuk does not index pdf documents. It would be great if th indexer could index pdf and other types of binary documents, such as compressed SVG (svgz) files (this would be easy, just gunzip then index). As webkit and opera now support svg fonts content creators may be creating more svg files.

    Thanks!

  2. Pingback: Projekty KDE na Goole Summer Of Code - Silezja.eu

  3. Alan: Nepomuk KDE uses the Strigi indexer for data extraction from files and it supports indexing PDF.

    It also supports files in archives (recursively). Not sure about SVG specifically, but XML should work as well

  4. Sebastian: Google hasn’t announced yet which projects will be able to participate in this years GSoC. Actually I think the project application phase hasn’t started yet.

    But I guess it is likely that KDE will be selected again.

  5. How about directly implementing strigi and nepomuk across all open and save dialogs as well as the main file browser (dolphin) so we no longer have to browse for flies and folders when doing stuff but jus quicky search for them

  6. Hi!
    I would like to see a bookmark plugin for konqueror, that creates a bookmark folder
    structure on the fly, out of the tags that are assigned to each bookmark-item.
    Something like a “tag cloud” found on some web sites but take it on the next level.
    A bookmark could be a local or remote file, of any cind: html/pdf/video/…
    The tags could either be assingned by the user(with a very simple/quick interface), or
    just indexed automaticly like strigi does.

    The folder->subfolder->file paradigm, is OK for placing files on a filesystem,
    but is a very broken way *IMHO* of categorizing and then trying to retrieve information.
    I guess this is what Nepomuk is for, right? ;)
    If you like me have a lot of bookmarks around [0] you know what I’m talking about.
    One could even use something ready like Lancelot as the GUI.

    So, what do you think?

    PS. Thank’s for asking!

    [0] $ grep HREF bookmarks.html|wc -l
    1413

      • Yes, exactly, a virtual folder structure that
        would replace the current bookmarks toolbar.
        Eg. I could find the digicam web page either like:
        Linux->KDE->multimedia->[digikam], or
        Photography->Programs->[digikam]
        Because the bookmark has all these tags:
        Linux,KDE,multimedia,Photography,Programs [0]

        An initial database could be created by importing
        the current bookmarks.xml file, using the
        directories as tags.

        That way, the bookmarks toolbar could be described
        as a point and click search engine with predefined
        results.

        What I said about Lancelot is really an extension
        of this idea to *any* cind of content that is
        indexable in Nepomuk. Something like a visual query tool for the database…

        [0] One could argue that to get to this bookmark
        I should give a “full path” like:
        Linux->KDE->multimedia->Photography->Programs
        which could be daunting. This is not necessarily
        true, because, if on the second or third level
        there are only, say 5-10 bookmarks left, you
        could just list them all flat, skipping the rest
        “unnecessary” subfolders.

  7. Hello, I think the main problem with Nepomuk right now is – there are too many files to tag.

    Perhaps some central database with simple
    hashmap plus some daemon geting and sending data from/to it will help?

    Of course there are many problems with this aproach (security and being anonymous), but it will be cool to have magically tagged all your not unique data.

Leave a comment