In a way Nepomuk in KDE is still a rather young and experimental project. We are still using a java storage backend since the Virtuoso one is not stable yet, we cannot track all file operations which can lead to orphaned meta data, applications so not use the theoretical full power of the framework, etc.
But I think this is OK. Nepomuk creates a new way of dealing with desktop data, even a new way of development (including ontologies). It is bound to take time, also because development it is not as fancy as for example Plasma and also a lot more complex. Thus, we should see the achievements so far positive. Apart from the existing frameworks and application integration there seems to be a trend towards semantic desktop ideas in general which is also an achievement of the Nepomuk project. There surely is a lot of potential.
On a more practical note there is one thing that has been missing for a long time: a starting point for developers wanting to help with Nepomuk. Sure, we have the tutorials which describe the system and how to use it. But no list of possible small or big projects to work on. Until now:
I already added a few todo items (mostly those I already discussed in previous blog posts) and ideas. I will continue to add items but I also urge you to add your own Nepomuk ideas.
(Why did I not use the KDE brainstorm forum? Because I need a dedicated Nepomuk page to keep an overview and track more complex tasks. The forum is a bit too scattered for my taste.)
Trueg's Blog 
Need to check out that site.
I have hoped that nepomuk gets nice movable search bar on Dolphin and other applications.
And then I found one great feature on Windows 7 on the search bar.
When you start typing, the box comes littlebit down and shows you a few suggestions what to add. Example:
[ ]
Then you type something like “foobar”:
[ foobar ]
[Date: Type: Tags: Rating:]
And when you click example the “date” link, it drops down that box to calender view where you can select day/multipledays. If you click “Type” you can select on list “Video, music, pictures” etc. If you click “Tags”, you get tag list (this situation the could) and when clickin “rating” you get 0-5 stars to choose.
And before you do the search, you can mix these together. Like first select last week, then type “images” and rating “3 or more” and then hit enter or click search.
And when adding those metadatas, they get added after the searchtext like
[foobar date: type: rating:]
and you can see what you have wanted to include there.
Basically I would be pleased if I would have a basic desktop search in 4.3. It is not relevant how it works, it just should be able to find my files. I don’T know what you did to get nepomuk to work, but on my 4.2 it sucked massive power usage and never stopped indexing. Even after 24 hours it wasn’t finished. Anway it doesnt matter since I couln’d find a search bar like spotlight to search for files.
So I am glad you are still playing around with your technology, but it would be awesome if people like me could really use that advanced technology. Maybe you need help implementing it. I need:
-less permanent scanning
-more speed
-krunner integration
-search bar on desktop and dolphin
-autotagging
-non-KDE-app support, like bookmarks in firefox
So I hope, some of that things will be adressed in 4.3. KSearch(or how that KDE3-port of search is called)is slow and inflexible.
I have some movies and series on my computer. It will be nice, when you tag the latest view and I can show where I’ll stop looking.
Thanks
I don’t really understand what you are saying.
Sorry.
Do Nepomuk know when you see the picture/movie/whatever the last time.
Normally you can see the last time you save a file. It will also be nice to see the last view of the file. I would like to use this for movies but also for audio files.
I’ll hope you understand me.
That’s an attribute of a directory (which was the last seen movie). This value might default to last accessed time or there could be a more sophisticated tag (eg, the last movie where you made it past the first minute or into the second chapter/scene/etc).
In fact the property might not “belong” to a directory nor to a file, but, like data in a database, is simply data that can be associated with many things at once (eg, through different tables or object relationships).
Thus other applications can leverage that information. A movie viewer configured to your liking would search for that tag.
And the tags can be more complex.
Now, a video player might already maintain this information you asked about. The idea would be to standardize these semantic bits so that other video players and other apps could leverage this same information.
And things can get complex because you can associate more properties with this, eg, last movie of a certain type seen to the minute mark using X type of viewer on a weekend.
Yes, I’m describing a universal database of metadata to describe all aspects of the system/desktop.
Well, that is my view of things. I have no idea how close Nepomuk comes to this.
I want projects to tag themselves like crazy to ultimately enable a lot more sophisticated and user-focused real-time distro generation.
The KDE desktop people will probably be focused on some subset of semantics.
Distro people would focus on distro-related tags.
It’s up to those with expertise in specific app domains to focus on the tags that would derive from and be used in environments that overlap with those domains.
Also, efficiency will be an issue if everyone wants to use this system. Perhaps a distro focused on some domain (focused on certain types of apps or tutorials etc) will turn on and off different semantic usage for performance reasons.
You also might want a highly indexed fast database for reading and maybe write to a log (perhaps with some items getting high priority status, eg, if they can be shifted out of order to be processed first). A background process can worry about updating the database. [A high prio background processes might deal with the time-critical content.]
For multimedia creations (almost anything can fall under the “multimedia” category, btw), I think we c(sh)ould leverage SMIL. [It too leverages RDF, btw]
I want smart and active desktops. I want integrated desktop and app storylines that leverage tags in all sorts of files and actions. I want everything to be part of a presentation/animation/tutorial at some level. Our apps and libraries (the engines) will focus on running the configuration data (the actual app/ applet), eg, “rendering”/”performing” a highly extended SMIL file. The desktop experience will be about having these (eg) SMIL files and fragments being run and activated throughout the session.
One application that I really want to get started with guides you through FOSS codebases. A general engine for this use case can then teach you source code suitably tagged. Thus, the project’s devs/artists/etc will build the “walk through” by leveraging this particular tag language. [BTW, such a tag language has not been created, best I can tell, at least not for public/std consumption.] Of course, other apps can leverage these same tags. The tags would be entered into the system and be usable to make all sorts of decisions. [Some tags would be focused specifically on guiding a multimedia “presentations-interaction-demo” for that project — that’s the feature from my wish-list that I’m talking about specifically, but many of these tags would serve other roles as well in ways that could be leveraged by other parts of the system. Eg, you would have: version tags, authors by lines tag, license by lines tag, implements X tag, depends on tag, can use port range tag, is Y type of file tag, is Y type of procedure/module/etc tag, section written in Z language tag, executable recipe tag, resource has W ACL properties tag, can resolve conflict of type V tag, etc.]
Note that to teach anything, you want the user to have interactive control (pause and lookup X on demand; choose your own adventure; etc); you want rich multimedia capabilities; you want a coherent storyline; you want many views into the objects (eg, to see a source file in various ways); you want to be reminded of many relationships and past lessons learned (but the level of this verbosity would be configurable); etc. Maybe have sections of code (fake) run in a visual fashion (like a sophisticated visual debugger). You want the person to be able to create tests and experiment seamlessly. You want the learning curve to be low, and this is helped the more multimedia aspects that exist and the better tagged that is the code. Ideally the tagging would happen in a different file from the source (to not dirty the source proper) that references the parts of the project as necessary (in fact, code test suites can be done externally this way as well instead of inlined in the main code body). I think you want the equivalent of a very sophisticated IDE but extended with video clips, animations, and sounds, and extra automation and guidance — all leveraging the tagging system. Again, some of these tags would be used by other parts of the system as well or by related applications.
Thankfully, we need not depend on the good graces of proprietary vendors to pull off a winning experience (that will attract many users and developers) because all levels of the stack will be needed to carry this out and these all exist as FOSS — customizable all the way up to the distro level.
In fact, having access to (signed) source code and code diffs (ie, forks/branches/customizations) enables a very sophisticated system where the apps are actually just some XML that is then run in engines/plugins/etc that leverage the tagging system, are included in the distro or whose parts can be downloaded and have an instance be (re)build on demand based on the needs/specs of the app (ie, based on the blueprint that is the XML app). The XML might include a reference to a well-defined (unique and online accessible) patch to a well-known code base. The system would build the required app/engine to run the XML suitably. Yes, security is a real concern, but since we rely on open source and can rely on trust networks, I think this can be made to work out. The driver is open source and a rich semantic structure that pervades everything.
I know, I may have stopped making sense a few paragraphs back. Sorry.
>> One application that I really want to get started with guides you through FOSS codebases.
Let’s look at an example of the “Source Teacher” in action.
You see a list of lessons after you navigate to the project you downloaded to disk. You click on a lesson. Then you get an image of all the files from the project lined up as icons/quickview. Each file that is related to that lesson (or concept or category or association X …) appears slightly yellow with tiny highlighted pieces within the icon/preview. Then the unrelated files fall under a shadow so the the relevant ones stand out well. These relevant files then float up and line themselves up. In some configurable order of presentation, each slides out and blows up in size. The view moves to the highlighted areas (or subareas of the highlights). All the while this is going on, the tutorial is explaining (via audio) the relationships (eg, going over the lesson or showing how these lines of code implement some concept or whatever association X is). At any point in time the user can essentially modify or stop the presentation by making his/her own selection (even things that are not highlighted can be chosen) and querying more or just changing the order of the “tutorial”. It’s like a choose-your-own-adventure. It “runs” until you impact the system. Then it adjusts but within the constraints and goals implied by the tagging.
So do we see the value in tagging? We can build an engine/Tutorial IDE/Source Teacher which behaves that way automatically when run on a particular project. How does it know what associations to make and how to step through things? Because the project was tagged. We define tags with semantics that lead to just this behavior but depending on the parameters of course. What did we tag and tie together and of what type and what presentation approach did we pick and did we create the audio files, etc? The tags are designed to enable this format, where presentation bits run and other context develops but guided by the user’s actions. The tags are designed to define all of these possibilities. [That is, we’d design with semantics that would enable such a Source Teacher app to be constructed and essentially run interactive tutorials automatically on properly tagged source code.]
[Recap:] We tag the source base as necessary (to our liking) after designing these interesting semantics. We build a sort of new “HTML” but with the semantics useful for making tutorials, presentations, etc. Likely we would leverage SMIL by adding a bunch of specialized tags. Then we create instances of pages using this new “HTML”. The behavior described above might be one example of running that page — something that was done automatically by the Source Teacher when a new project was opened. Also, like ordinary HTML, there are HTML fragments and these all come together. There are implicit linking among the fragments (if/when necessary based on flow of control of the “presentation”/”browsing”) because the semantics would be designed such to make this possible (like makefiles in subdirs being related and leverageable by the parent makefiles). This “HTML” can involve any and all parts of a distro (though this particular case is focused on “source code” tutorials).
Different project devs not finding within the standardized set of tags the tags they want to use can create their own engine code snippets (libraries, scripts, plugins, whatever, depending on what they were integrating to) and matching tags, then use these tags. Source Teacher would know to look for the “plugins” to interpret the new tags (assuming such plugins existed for Source Teacher.. all of this would be directed by another set of tags — the standardized Extension Tags).
What is tagged then are files and projects and lines of source and audio clips and config files and whatever.
Other apps might leverage this information. Eg, doxygen might use it to augment the webpages it generates. Some other app might create auto youtube demos. An editor-app might allow rewriting the notes/documentation associated with various associations.
I still don’t know if I’m coming across clearly.
As another example of the use of tagging, our hypothetical Source Teacher might show how source repository branches might morph into each other. It all might be coordinated with explanatory information and maybe shown as the calendar days flip by (and with a picture of authors making notable changes). Of course, such a versioning system is already tagged in a number of ways, but we’d add more tags externally and maybe run a script (during “make”) that generates tags from the internal repo components.
So the key is to design interesting and powerful tag semantics. If we build it, the apps will be able to come.
[Forgive my spamming of this webpage. The potential gets me very interested. I have thought out some parts of this, but I haven’t been able to dedicate time to it.]
Connection to Nepomuk?
Well, the XML files create the relationships. These get digested by the system (eg, a Nepomuk helper). Internally, the system (eg, Nepomuk) might convert to object-value pairings, tables, or whatever other association mechanism is within the Nepomuk implementation. Nepomuk can still maintain its current interface.
The Source Teacher example ( https://trueg.wordpress.com/2009/05/21/your-our-nepomuk-ideas/#comment-471 ) was described as if it itself interprets the XML info, but it could have possibly gotten all of this info by querying Nepomuk instead (the XML file info would have to be digested by Nepomuk in order to produce the query results).
Why go through Nepomuk? [Ie, is there a reason to go to a central source of some sort?] Eg, the system (Nepomuk) might already have overrides in place for some of these Source Teacher features. Eg, the user might have set up to have audio converted to visual when the volume is below a certain level or when s/he wants that effect. This might be carried out by a different tag (“convert audio to text in presentations….”) associated with the grandparent directory of where the FOSS project tar.gz was downloaded. Or this behavior might simply be a system behavior applicable to all audio being heard. Naturally, it’s best if the applications would recognize the instructions and implement them (eg, the project might provide text equivalents to the audio as a backup for scenarios such as this, and Source Teacher might pull those texts instead of the audio clips and display the text as is done with closed captioning).. though, instead, there might be interceptors at the system level (eg, a real-time audio to text mapper). The project might actually not even have audio files but only text files, and Source Teacher might do the voice synthesizing if appropriate. In any case, a central authority (or equivalent effects) is a good idea for improving the user experience.
You mentioned the “Remember download locations” in the project page. Does that include saved attachments from emails, too? That would be also very useful for me. (Often I remember the person who send me the file, but not the filename.)
Thanks for your work so far.
@Burke:
“Anway it doesnt matter since I couln’d find a search bar like spotlight to search for files.”
You can right, now as far I know, search your files few ways.
1) Krunner interface (Alt+F2) if you have enabled (should be by default) Nepomuk plugin. You just type what you search to that line and you get files shown.
2) Type to dolphin/konqueror addressbar a nepomuksearch:/ and you get few folders.
3) Type nepomuksearch:/tag: and you get files what are tagged with .
4) Add a folderview-widget to desktop and set from its configurations it to show the 3) tag-search filter as places by manually. Then it will show all files on that folderview-widget what has such tag. If you want the folderview-widget name removed, just rename that widget from it’s settings to empty by adding one space (it can not be empty).
5) Create a new entry to Dolphin places-sidepanel as 3) and you get fast way to open/see files what has that wanted tag. Still not possible to save as such.
These I have found so far and I think they are only ones on 4.2.
I have tried to find a way to search by ratings or someway join these queries.
I would like to see autotaggin someway, like user sends the file via kopete/email and it gets tagged by that name/address but I think that is somewhere on nepomuk and made little different way to get the semantik search work.
Hey Burke,
Most of the stuff you mention has been fixed in 4.3. Not all – no autotagging, but there is a searchbar in dolphin, and krunner also searches properly in Nepomuk. Also it is faster and doesn’t hang as much as it did for you. But to fix the hang I had to remove the current storage.
One thing I have always wanted is for the search bar in the KDE Menu to also display nepomuk search results. From what I have tested, nepomuk seems more than ready to start being used, and I would really like to start doing so!
Hello, I would like to integrate KDE Plasma Activities and resources with Nepomuk to make widgets behaviour context aware. I started a little document as a base that should grow up by sharing ideas about that goal at the address below, since I don’t want to modify directly techbase.kde.org pages without being explicitly invited.
http://docs.google.com/Doc?id=dcp4ww55_76gdhhk6ch
I am interested to write code too.
bye
This is great. Sorry for the late reply. I had your ideas page open in Konqueror all that time. I just could not remember where I got that link from. :P
Now that I “found” you again, how about we discuss this some more. Drop me a line at trueg@kde.org, please.
I think this is a great piece of software that deserved a bit more visibility. For the time being it is in playground due to being young but it also has the side effect that distributions will not pick it up easily and it will not be tested and criticized by average users. There should be a way to press distributions to build playground as experimental features. Or am I missing something here.
On another note, the thing that I miss the most in a (any) desktop is the ability for it to distinguish between content types among similar file types. For example, I have a bunch of jpg’s. Some are photos, some are drawings, some are screenshots. Another example is that of pdf’s. Some are books, some are research papers, some are something else completely. A photo has people in it, a screenshot doesn’t. A research paper has an abstract, a book doesn’t.
Does this make sense for Nepomuk?
It makes perfect sense. This is a big part of it, saying that a document has a certain type (independent of its file type) is one goal.
That is the idea of PIMO actually. We make a distinction between the file and the “thing” the file represents. The first would be an image file, the second would be a holiday photo or a screenshot or a CD cover.
The same goes for text documents which could represent a letter or an invoice or a project description or whatever.
We “only” need to integrate this into some guis…
Oh. And one more suggestion. 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.
nice
One approach is to write a patch/extension/plugin to the file manager or to the editor or create a new distinct app through which you do the selection and which understands what you want and does it (based on the tags it finds). So you need to define the tags, use them, and write the code that carries out the full semantics you want.
However, the more we standardize on tags, the more likely you will have others write the code or libraries for you which would be usable within many apps/scenarios. One app might use a visual folder view and allow you to use lassos to more quickly tag things or invoke certain effects/actions based on these tagged files. Another app/plugin/script might do more than what you just asked. Other people will think of other things that can be done with such tags and create the FOSS for others to leverage… This can be done if we standardize precisely. And the different bits of semantics we would like is almost infinite. We need to get started!
andreas_k: I think I got it. I added an entry. :)
Thanks.
I love KDE and the team behind kde.
Hi,
How about updating the Nepomuk User documentation to:
1. Describe the point to nepomuk.
2. Explain why it takes up so much memory.
3. Explain why it uses so many services.
4. Tell people how to uninstall it.
5. Tell people how to disable it.
6. Tell people how to remove all related dependencies.
Thanks!
Heard. It may be the greatest things since sliced bread, but not everybody wants an indexer siphoning private data from everywhere into a database stored in a non-customizable, unknown, discretely chosen (by who knows who) location, performed by a daemon that is silently enabled because the distributor couldn’t figure out how to turn it off.
Others simply don’t care for the feature and would rather live without the performance hit.
From a packaging point of view, there should in general always be an order where peripheral features depends on core stuff, but existing packages does not start depending on peripheral stuff. Otherwise it becomes impossible to build a basic system without including every single package in the repository. Nepomuk is still peripheral, not a core feature (sorry), but seems to be nonetheless impossible to turn off and non-dynamically linked in into KDE.
Yeah.. So in short, please provide a way for those of us who don’t need or want nepomuk to disable and remove it. Thanks!
Oh, and great work by the way. Lovely for those who actually needs desktop search and non-exchangeable metadata.
Reminds me, haven’t the metadata thing been done a few times before? I seem to remember various desktops / GUIs shipping with various operating systems, which built similar features on top of attributes stored in NTFS alternate streams, Macintosh HFS+ resource forks, HPFS EAs, etc. I would love if someone could tell me how Nepomuk is new and different from these earlier attempt.
(Right now the only major feature/accomplishment I can put my finger on is that the project managed to lift a couple of million US$ from the EU ;-). Hehe…)
Sigh. I don’t know why I even bother with you people.
Anyway, first of all: Nepomuk is optional in KDE. Thus, disabling it in packages is simple.
Disabling it when built is simple, too. There is even a GUI for that. So stop whining.
Second: as far as other attempts go: do your homework, try understanding the whole thing a bit by reading the information that is there. The indexer is only a side product and not the main feature. And, no, I won’t explain it to you again since you do not seem to care anyway.
Don’t bother indeed, sebastian. Most of us know and respect you and the great vision you and the Nepomuk project brought KDE!
Well, and how about the people that want to run only a subset of the “full” tagging, so as to avoid the issues you mentioned, except to the limited extent where they feel they are getting the bang for buck?
Reply comment 467 (by Jose_X) was in reply to 423 (by wingdings). I’m not sure why it was posted off. In fact, my replies above have gotten misaligned I think.
Also, I do think there should be on/off for different features.. in an attempt to keep performance, privacy, whatever, under better control.