[Nepomuk] search client possibilities displaying results

[Sven Burmeister]

Hey Sebastian!

Am Donnerstag, 2. September 2010, 11:04:30 schrieb Sebastian Trüg:
> The problem is very complex. You cannot compare Nepomuk's search
> capabilities to kfind in this way. Theoretically our search engine (ie.
> the Virtuoso db) can return context but it is very hard to handle
> generically.
> The reason is that with Nepomuk you can do way more than just searching
> for a string. You can build very complex queries where strings are
> searched deeply in the query. Thus, one query can have multiple matching
> strings and the problem becomes: which do display.
> This is the reason it has no been exposed yet.
> I will, however, think a bit about the problem. Maybe a solution can be
> found where we only return context in certain situations, ie. when it is
> clear which context the user meant.

The reason I ask is as follows: everytime an openSUSE release approaches the 
question is whether to enable nepomuk/nepomuk+strigi by default or not. I 
personally am looking forward to a desktop search since KDE 4.0, yet until now 
every time I tried to use it, it did not help me to find things because a) 
unlike other (desktop) searches it does not display any context and b) it 
always crashed while indexing.

Now I know that I have made some mistakes already, i.e. if nepomuk provides 
the means to display the context it is mostly a search client issue rather 
than "it is not possible". And if it crashes it is mostly due to strigi or 
dbus. So recently I took some time to find out how to track down the crashes 
and find files that would help the strigi devs to fix their code. So by now it 
does not crash anymore and I have a 1.4GB database with information about 
~130000 files in it. Yet all I can get from this is a filelist.

This is where the comparison to kfind comes into place since from a user's 
point of view and for the use case of "find a file that contains string x" 
nepomuk+strigi and kfind do the same and provide the same result, i.e. a list 
of files which contains the string. Just that nepomuk+strigi used a lot of CPU 
and database space for it. And again I made the mistake to write that 
nepomuk+strigi do the same as kfind which is obviously wrong because they only 
index and provide information and it's the client that makes use of it or not.

So from a user's point of view the features and information within nepomuk's 
database regarding "find a file that contains string x" are those that kfind 
already had and thus nepomuk+strigi seem pretty useless.

Nepomuk+strigi does have an acceptance issue because there are people who 
dislike any kind of desktop search and there are those that know other desktop 
searches (and that's the name displayed in systemsettings and thus what the 
user expects) and compare nepomuk+strigi to those desktop searches they 
already know. Yet in fact they compare the clients and fail to see the 
potential features.

So IMHO nepomuk+strigi has a client problem and in order to gain acceptance 
this has to be solved. If it is partly nepomuk's fault because access to those 
features is too complex, it should be solved quickly and before more new 
features are added in order to get at least one client out of playground and 
into KDE. I know there is timeline:/ and I know there are tags etc. but IMHO 
krunner's and dolphin's handling of search results are not helping nepomuk to 
get acceptance as a desktop search, currently to the user it seems rather a 
kfind+tag search.

To sum-up this means that until there is no proper search client, there is no 
desktop search and thus its services will remain disabled by default for most 
users.

So what search client in playground is the one that one should watch to 
integrate into a distribution because it will bring nepomuk+strigi to the 
user? I want nepomuk+strigi to be enabled by default in the next openSUSE 
release and therefore try and test its desktop search capabilities.

Sven