Ignacio Serantes wrote:Well I must prepare a test case about inconsistencies in query system and report as a bug but I really can't call bugs because I don't know if really are. For example, rating is a numeric value but:

query: nepomuksearch:// rating=1
result: nothing

query: nepomuksearch:// rating:1
result: correct

If one way works, the other not, you can most likely be sure that the working one is indeed intended. If it is logical or not, that is maybe another question. But it is consistent, think of nepomuksearch://hasTag: Ok, these are numerics, but you call the resource "hasTag" or "rating" with a value.

for me this is wrong but I'm not sure, could be a feature.

About queries, sometimes a query that fails minutes later works. I'm not sure how can I report this as a bug.

About Gwenview, add a tag named "Tag that really don't works, seriously", assign to as many files as you like and try to use it. If you do the test don't forget that there is not a method to delete a created tag .

That maybe indeed a bug, but not in nepomuk, rather in the client apps.
Just don't forget, nepomuk service/integration is still under heavy development.

neverendingo wrote:About Gwenview, add a tag named "Tag that really don't works, seriously", assign to as many files as you like and try to use it. If you do the test don't forget that there is not a method to delete a created tag .

That maybe indeed a bug, but not in nepomuk, rather in the client apps.
Just don't forget, nepomuk service/integration is still under heavy development.

About Gwenview I do a reply about a great support of nepomuk offered by that program. Of course, my example is a Gwenview bug, it creates a wrong query, and not a nepomuk search bug.

Don't worry, I don't forget it. I'm trying use Nepomuk since KDE 4.1 and I'm not capable. I thought that with KDE 4.3 Nepomuk developers must take a break, stop adding new features, a lot of problems and a new database was added, and coding something for users.

Perhaps for KDE 4.5 or 4.6.

The problem is that there is only one developer fully working on it, Sebastian Trueg. Part of the reason I wrote the document was to get other interested devs donating their skills to it. Yes, there are others on the nepomuk dev mailing list. But Sebastian has pointed out to me that these people do seemingly little coding.

This is personally worrying for me, as you might of guessed.

Dante Ashton wrote:The problem is that there is only one developer fully working on it, Sebastian Trueg. Part of the reason I wrote the document was to get other interested devs donating their skills to it. Yes, there are others on the nepomuk dev mailing list. But Sebastian has pointed out to me that these people do seemingly little coding.

This is personally worrying for me, as you might of guessed.

As I told in a previous entry if there is only one programmer he is trying to hadle to much work so there is a big problem with planification. For me, add strigi integration was a big mistake.

I think that a correct aproach would be:
1) Tagging, scoring an comment support and only one dabase backend. Redland is slow, well, with only this kind of ontologies does not matter, DB would be small. Functions to delete and rename tags must be code.
2) Powerful query system designed with user in mind (kio_nepomuk and KRunner plugin). Programs like digikam, gwenview and amarok could have a good nepomuk integration and not duplicate the work. Actually only Gwenview is using nepomuk and integration has problems.
3) Nepomuk disabled by default. Is slow and people don't understand it so why must be enabled?
4) A document with user in mind presenting Nepomuk benefics. If people like can enable nepomuk and do a try.
4) KDE 4.1 or 4.2 released.
5) Add strigi support (and improve strigi because has encoding bugs) and add new dabase backends to suppor all de data recollected by strigi.
6) Improve query system if was neccesary.
7) KDE 4.2 or 4.3 released.
8 ) Improve nepomuk.
9) KDE 4.4 or 4.5 released.

The basic problem with Nepomuk development is that seems nobody thinks in Nepomuk from a user point of view.

I know that sounds very critical, but if I'm criticized because I think that Nepomuk is the best function added to KDE 4, yes even better than Plasma or Phonon, and do not try to disparage, let alone the great work Trueg. I'm trying to make a constructive criticism and hope that anyone who reads this will understand this.

So I will try to contact with Trueg and talk with him about write a document with query syntax and with some recomendations of usage, for example, enable strigi if you have files with asian characters is a waste of space and time.

I mentioned it to him, he admitted the documenation was something that should be done.

We simply need more people, lots more, working on this. Otherwise, by many people's opinion, it will be considered a failure and thus dropped from development.

aehm, sorry to interrupt you, but I still did not get it. what is nepomuk for? a desktop search engine? why do you think I (kde user) should want it? thats a point I still did not get.

samhain wrote:aehm, sorry to interrupt you, but I still did not get it. what is nepomuk for? a desktop search engine? why do you think I (kde user) should want it? thats a point I still did not get.

Well, nepomuk is more than a search engine. Is a system that offers you functions to classify and organize all the information in your hard drives.

If you are using Amarok or Digikam, you probably are tagging and scoring your music and your pictures. With Nepomuk this feature was developed at desktop level so, this information was available to your desktop and to all programs that supports it.

An easy example is with videos. You can have a video but if you want tagging (director, year, actors, genre) and scoring it you need a program designed to do it. With Nepomuk this features are system available and even you have cross referenced with other kind of files.

For example, imagine a tag like "Elvis Presley", you can launch a search in your system and locate movies, photos, audio and books and documents easily all about "Elvis Presley", or all music from Elvis published before 1959 and many many more queries.

You must read Dante's document if you are looking for deep information about Nepomuk.

Of course, there will be people to whom this would not be interested in the slightest, but in my case, is something that gives me an amazing chance of sorting and organizing my hard drives.

I've read Dante's paper, but I could not figure out what works or what not or how.

If it's all about tags and tags I have to give then it's quite useless for me. Can it extract "important" information from lets say pdf files? Can it handle technical documentation like the handbooks for atmels atmegas and do something meaningful with it? Can it classify images?

The data extraction is done by Strigi I believe. Unfortunately this is one of the under performing components of Nepomuk currently ( or more correctly, Soprano which is where redland / sesame2 / Virtuoso come in )

hm. is there a paper somewhere that tells me what it actually can do? not the things it will do some day far far away?

What it can do right now is....nothing.


At least, so far as 4.2 and 4.3 are concerned. There are plenty of interesting little things, like Scribo, in the NEPOMUK playground.


I would like to point out that whilst NEPOMUK would operate on tags, we need people to develop systems to automatically tag data. Otherwise it's quite silly and we're just making even more work for the end user, instead of taking work off of them.

This is why I've been pushing left and right to get face detection and recognition in KDE. That technology means that my system knows who's in my photos, and as a knock-on affect, it could be used as part of the KDM, or for security checking (if you really have stuff on their you need to put a biometric lock on)



samhain; to answer your questions in order;

"Important information", well, Strigi can search by topic, as the screenshot in the article showing the Scribo shell listing topics shows.

To extract information the system could consider valuable to certain topics, we'd need Scribo and a summarization system.

Classifiying images; face detection is being...looked on. Provided we get more people working on it (unlike the current situation, where we just have many people sitting on the NEPOMUK-dev mailing list talking instead of coding) the system should be able to answer a query like "Show me all photos taken in Germany" due to the metadata some cameras provide, or that is added.

You'll have to tell me fully what you meant by 'classify'.

"What it can do right now is....nothing."
oops. why is it then running?

hm, face detection is not the bid deal (opencv has it built in and it works quite well). face recognition is hard, as I see it. well, I would love it. I have to admit I was hoping nepomuk provides someting like that already. I would even be pleased by a system that could search all sunsets in a picture library without spitting out all pumpkins.

"classify": well, the taging system is classification by hand. i some way it is comressing (big) text like technical documentation to a small summary.

bcooksley wrote:The data extraction is done by Strigi I believe. Unfortunately this is one of the under performing components of Nepomuk currently ( or more correctly, Soprano which is where redland / sesame2 / Virtuoso come in )

Yes, automatic data straction is strigi job but, actually, strigi is not doing this work very well so you are not sure if really all your files are indexed .
And some of performance problems probably would be solved with Virtuoso DB.

I dunno, Strigi is pretty reliable for me: if you install Redland/Raptor AND sesame backends for Soprano, you shouldn't experience any difficulties.

Oh, and KDE 4.3 adds a search field to Dolphin that uses Nepomuk to search your files and display your tags. This functionality has already been in Krunner since 4.2.

Is there any way to achieve that in Debian (MEPIS). I have been doing some searching, but apparently the Debian packagers are not inclined to create a Sesame backend package, apparently because of the intricate structure.

If I can get some binaries or (easily) compilable sources, I would want to have a go at it myself.