Projects/Nepomuk/Ideas

    From KDE TechBase
    Revision as of 12:39, 23 August 2012 by Vishesh (talk | contribs) (Remove redundant information)
    (diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

    Ideas

    There are many ideas on how to improve the Nepomuk system or on how to use it. This is the place to list them all.

    Feel free to add your own ideas. Please leave your name in case someone wants to contact you for details or a discussion of the idea.


    Tool to gather annotation statistics about selected files

    Quoting blog comment as an example: "I am using Nepomuk to tag/rate schoolwork from my students. For every paper/file I tag it with seen/unseen and rate it with the actual grade I want to give (0-5). When I have seen them all, I collect the results into a spreadsheet. It would make my life (even) easier if, by selecting a bunch of file I could have a summary (one I could save in some text form) of all ratings/tags for each file in the selection."

    One could think of an action in Dolphin (for a first prototype this is always a good idea) which triggers a collection of all metadata which is then layed out according to the user's wishes: html, plain text, odt, whatever.

    Add support for qualified links/relations

    This is a somewhat low-level idea with no visible results as long as applications don't use it, but I think that having it implemented would allow for some nice possibilities.

    Basically, the goal is to have some generic way of attaching a "quality" to any “thing -- property” assignment, in order to cope with the varying credibility/certainty of different meta-data collection methods such as user input, heuristic algorithms, circumstantial guesses, etc. in a transparent and unified way.

    This would among other things allow implementing many automatic-data-collection ideas like NLP-support in a more user-friendly (that is: non-intrusive) fashion.

    For more details & discussion see Projects/Nepomuk/Qualified Relations Idea.

    Folder Cloud in Dolphin/KDirOperator

    Using information from the Nepomuk DB about usage frequency of folders (or the files within) it would be nice to have the folders be presented in a cloud. More often used or more important folders would appear bigger.

    This is a nice idea originally posted on kde-look.org.


    File Boxes

    There is a nice idea about file boxes which allow to temporarily group files to perform some actions on them here: http://bugs.kde.org/show_bug.cgi?id=200461

    This could be done using Nepomuk. I am not sure, however, if Nepomuk is really the correct choice here. Maybe a simple kded service and a KIO slave nicely integrated into Dolphin and the file dialog would be sufficient.

    Categorize new files

    'We already have the fileannotation service in playground. This is the basis for the idea below as it already implements parts of it.

    Let Strigi emit a D-Bus signal on new files (only after the initial indexing so we do not get signals for all files) that appear in typical document folders (so we do not get signals on temp and log files and the like).

    When a new file appears propose to relate it to the current Nepomuk context (the context service is in playground: a very simple one only maintaining one URI which is the current context and can be any resource. Typically, however, it would be a project or task or event).

    Also use the information extracted by Strigi (mostly nie:plainTextContent and nie:description and nie:name) to generate annotation suggestions through Scribo and propose them to the user, too. This could be done via notifications (in a first version) and later in a nicer plasma GUI.

    Here rating of the suggestions is important. Nepomuk::Annotation already provides a relevance() method but most plugins' relevance generation code is rather simple and could use improvement.

    Hints:

    • If the above "Add support for qualified links/relations" idea were implemented, the user would not have to be bothered to confirm the relation of the new file to the current context. You could just add it as a weak relation ('found by circumstancial evidence'). The user could always confirm it at a later point (e.g. in dolphin) to turn it into a strong relation.

    FIXME: add your own ideas

    Linking between documents

    I usually deal with lots of scientific papers in the form of searchable pdf's. My idea is twofold: 1) Have a 'Google scholar' type search that allows me to see the relations between papers and retrace an idea to its original author. 2) Each paper refers to a few other that I might have already on disk. My idea is to have okular integration such that when I click on a reference it opens the respective file based on author, date, journal, etc.

    Push tag clouds on the web

    I'd like to save my tag cloud on the web so that when I change computers, I still have my tags. There should also be serveral projects which wikify tag cloud creation and which would serve updates via some kind of RSS feeds. Think of it as some sort of Digg for both online and offline desktop items.

    Augment menu toolbars with semantic search

    Ideally, eliminate the use of menu toolbars, rather have a powerful semantic search to query for a given functionality/action etc.

    Pure semantic desktop environment

    A minimalistic desktop environment solely based on semantic search. Ideal for small screens (e.g. netbooks/smartbooks), all functionality is accessed via semantic search, rather than the usual assortment of menus or application icon panels. A rather intuitive UI. The user 'talks' to the computer. In essence this takes the idea of beagle/krunner/gnome-go like idea to the next level. Combined with the replacement of toolbar menus, it makes for an efficient use of screen space with an uncluttered UI, plus shifting the input method more to the keyboard side, which can be beneficial to netbooks/laptops on the move (when you don't want to rely on a mouse)

    Automatically annotate system files

    The example is wallpapers. Installed wallpapers could automatically be marked as begin of type "Wallpaper". This would also require an ontology which includes the term Wallpaper based on PIMO.