There's needs to be a more complete and usable gui for Nepomuk for it to be useful and also a better query languge incorporated like Nepoogle http://kde-apps.org/content/show.php/Ne ... 31ae0a9339 (appears there is some collaboration here but not sure what and when)

The old Dolphin interface appears much functional then the current one .

Another possibility would be to add meta data functionality to Kfind or to just create a gui from scratch.

Not sure that Dolphin should be the primary access point, maybe a Kio could be created for access in Dolphin.

Obviously not a new idea

I don't see any need to make a decision about which application/utility should act as a gui starting point for Nepomuk queries.
Code a query interface and a result canvas as a widget (or even alternative ones) and offer them as KParts. Then the maintainers of individual applications can chose to integrate those, thus enhancing their application. And nothing speaks against using those KParts in a new, standalone gui frontend.

google01103 wrote:There's needs to be a more complete and usable gui for Nepomuk for it to be useful and also a better query languge incorporated like Nepoogle http://kde-apps.org/content/show.php/Ne ... 31ae0a9339 (appears there is some collaboration here but not sure what and when)

Nobody is collaborating in Nepoogle and the SPARQL Engine is designed by me, and don't use Nepomuks's API at all, but I'm a sort of counselor about queries. I don't known, and I don't like, C/C++ so it's really a pain for me reading and coding in this language.

The reason to develop my own SPARQL Engine is because in KDE 4.6 Nepomuk queries are totally broken for encoding bugs, my metadata are in Spanish, Japanese and Korean, and because the new search interface added to Dolphin is, and obviously this is my personal opinion, a totally mess and unusable.