50

Good ideas, BUT;

The first part, about applications. That is...too difficult for the base of Kiim as it stands, it would require packagers/programmers/distros to provide information about the purpose of their apps. That's far too much information needed to be given.

Your other two ideas are good, but are still above the baseline of first developing Kiim, keep them until Kiim herself has developers, and she is finished. Until then we're just piling on unesscery work.

Ok.

I must mentoin PackageKit will be using by all distributions. There's also KPackageKit project and KDE can more depent on PackageKit in future.

Indeed, PackageKit looks quite promising!

Hmmm, can someone suggest that to them? Storing semantic data about apps?

Not. Just write a plugin to asking PackageKit when some keywords appear.

That more or less complicates things, the amount of information about an app infrequently dosent state it's purpose.

Application specific questions aren't important for KIIM. Write a script communicating with KPackageKit, that's it. Then you can improve support. What's the problem?

The particular problem here is that developers do not add meta data about the uses and potentional uses of their apps. In Lachu's example, Kiim was able to 'know' that a particular program is installed that can convert FLV's to MP3's. In the 'description field' of PackageKit, what would happen if the description said 'cannot be used to transfer FLV's to MP3's? There is simply no fool-proof way of getting Kiim to deduct that. It can be done, yes, but it'll be limited and will give off many 'false positives'

There is an application missing in Kiim.
Then you write a short script and upload it.
Other Kiim users could download it - that's it. Automatic generation of program calls is of course not possible.

I didn't read all the 4 pages (only 2 and a half ) but did anyone already throw DBUS into the "mix"?

KIIM could link commands you tell her like "Show me my Plasma Dashboard" or "Pause the Audioplayback" to DBUS commands that can execute the latter "events".

btw: This sounds like a really really cool idea

@pano
Look at my attachment (it was on page 3).
DBus is most important for layer 4 (execution). All the other possible implementations of layer 4 would either use DBus or just be additional stuff.

@all
There's one problem with simple keyword-lookup:
It's no problem to search the word "install" or "show emails", but sequences like "the development packages for ruby" or "I've send yesterday to Bob" aren't keywords. There should be at least a detection of prepositions like "for", "for", "to" or "from".

Plain version (I don't know, maybe nobody uses Basket):
First Layer: Interface
-GUI
-CLI
-KRunner
-Kross (scripting in natural language)
-Multimedial (voice, video...)
Second Layer: Analyzation
-Extract keyword
-Analyze grammar (especially prepositions)
-Enable structured bash-like commands
(localization would be complicate)
Third Layer: Lookup
-Search for Keyword
-Other mathing-methods (like keyword-regexps (handling with keywords, not with single characters, which are language-specific), they would match a special grammatical structure)
-Reference to dictionary
-Database containing information how to execute the action
Fourth Layer: Execution
-Simple DBus-call, e.g.:
Input: "stop music"
Script: "org.kde.amarok.Player.stop()"
-Kross-Scripts, they can use DBus but they have also the features of the used language (computations can be done)
-KRunner, redirect an input to KRunner, which already provides a couple of services
-C++-KIIM-Plugins
-Call a program with command-line-parameters
Fifth Layer: Important Technologies
-DBus
-Kross
-KRunner
-Databases (but I don't think a normal SQL-database is good enough)
-Native program start
-KDE-C++-Plugins
-KNewStuff, it should be possible to download and upload scripts, KPackageKit could enable a dependency-check

I hope you'll understand it.

I don't agree about 3rd and 4rth layers (unless they are meant to work together).
In many cases the meaning of sentences depends on words, that can be multi-meaningful.
Sets say you tell: "Find me directions to Tom". You Human would understand, that Tom is a human name, but how KIIM would know if it is a human or a place or an street or a website or a POI etc.

Should asks about meaning of Tom?

Well, no. Lets say I have an application with 'Tom' in it's name. It's the only one and thus Kiim launchs it. Here we have a problem, we're running into areas which are not easy (or even possible) to solve.

Why do you think I have not suggested putting in a bot for Wikipedia, or other online services? Because it'd be too complicated "What is chocolate?" Would be a Wikipedia/Wordnet query, but "What is 2+2?" would also be treated as such a query and thus Kiim would be unable to see a difference.

Dante Ashton wrote:Well, no. Lets say I have an application with 'Tom' in it's name. It's the only one and thus Kiim launchs it. Here we have a problem, we're running into areas which are not easy (or even possible) to solve.

What about weights system?

Lets say we have a fixed number of search ares (like email, maps, google etc).

You ask for lets say "Find me directions to Tom". You have a contact called Tom and app called Tom
so KIIM adds something like [address book weigh]+= 20 [Application weigh]+= 20

When goes to keyword "directions". Keyword directions is mostly used in context of people. so it does [address book weigh]+= 15 [Application weigh]+= 0

In the end we would have
[address book weigh]= 35 [Application weigh]= 20
KIMM decides its talking about person, not app. Problem solved.

Also I dont see any problem If KIMM would ask me to clarify what I have in mind, especialy if those weights would be very same count.


As for google/wikipedia bot, they should exist, but only as second level backends and used only if you clearly ask to took at them (unless PC's will be capable to look anywhere ) like "Google me for Tom Edison" or "Wiki me What is chocolate". Otherwise they should be kept untouched

We should try to check if layer 2 and 3 could be seperated or should be only semantic seperation.
Layer 3 could be at least a database-system.

@Lukas
Weights are fine, but a detection of objects is simply necessary.