50

I think Kiim should have more access to information, like in one of the examples I gave above, Kiim (or KDE) knows where the user's location is, to expand upon that, she could also know where you work...

I think the social/semantic desktop is a great idea, and I (personally) think KIIM could be the most useful interface to it.

Thank you, Lukas! Your right, this is no simple feat (though, as I've said, we're already leaps and bounds beyond closed-source AI as they often have to 'reinvent the wheel')

There was plenty of research on an interface like Kiim. There is one still active today, called UltraHAL (though Kiim is, at least on the drawing board, far more advanced).

Doing it in a FOSS environment not only saves us time, it'd also mean the system is extensible. Also, no real time-limit, no need to rush it in order to make money for further development...FOSS is perfect for something like this!

PDF almost done.

PDF done and uploaded to Google Docs.

http://drop.io/w3yk5wf


Sorry about that.

Sorry, the page (or document) you have requested is not available.

Please check the address and try again.

@Dante Ashton
Nearly everything is possible using DBus and Kross.
Special integration into other programs is not necessary.
There is already access via DBus, Akonadi and Nepomuk.

PS:
I can't open your file.

Address altered, sorry about that, ladies and gents, forgot G-Docs sometimes throws a tantrum.

I think there should also be a bash-like input message using clear command sinstead of real language. That's often easier than writing essays.

PS:
I've created a Basket-basket for the interial structure. I think such layers would be very useful to make it universal and flexible.
http://drop.io/kiim_basket

APPEND;

I just found another useful tidbit for the Search bots (under potentional uses)


http://en.wikipedia.org/wiki/Multi-docu ... marization

@The User; too true, my friend, too true :P
Hopefully Kiim would be able to understand both without querying which type of input I meant.

I need multi-document summarization for those Wikipedia articles.

Dante Ashton wrote:Analyzing sentences is possible, but heavy on the CPU (that is, if you mean a complete analysis where all possible data is extracted) so I can't really see how something other then keywords would be helpful.

Wouldn't some sort of learning-mechanism alleviate that problem somewhat? Even better: provide both a learning-mechanism coupled with a corpus database and preferably one that's semantically tagged. Add some statistics and probability computation into the picture, and it would lower the CPU load. It would still be heavy though, but not as much. Besides, in a scenario such as this: I'm not convinced a complete analysis would be necessary.

User don't needs quick answers.

Well, as far as I'm aware, there are two methods for 'learning'.

1. Neural networks, fun little things (the odd thing is that no one is 'quite' sure how they work).

2. Semantic learning. Technically possible, it would most likely require a large Ontology, and techniques in order to extract data from sentences.


The trouble with both of those is that they are not very easy to create, nor control, nor repair.

Semantic learning systems can suffer from what I like to call the 'Cascade Effect'; if, say, some untrue information finds it's way into the system, it could wildly corrupt any data gathered from that point. Snowballing, basically, as one bit of data 'trusted' enough by the system could damage it. The more advancd the system, the more damage is done. To a lesser extent, it could cause some bother;

Lets say, for instance, I tell Kiim about a friend of mine, but I accidentally mispell his name. Any data referring to this misspelt contact could not be linked to other data about the same friend, effectively 'ghosting' that person. That's easy enough to solve, providing you know there is a problem.

@Kryten, yes, your right, it wouldn't be such a load, but I'm sure I don't need to tell you how much work would need to go in for such potentiality little reward. In the future, that could reap huge benefits, but I'd rather like to wait until a good part of the world has processing capacity to spare :P

Let's start with the deeper layers and use simple keywords and a CLI. Then you can add analyzation to the second and learning to the third layer.

Hmm...well, how about this?

Start off with keywords, not full, natural langauge, just the keywords.
Link into basic programs (without feedback) like K3B, allowing basic control.
Complete keyword system, work on parsing it through 'junk'. (IE: Excess language)
Output through Festival

(Just seen the 16 votes at the top, thank you, everyone, for your votes! )

It should start by +- documenting some sort of API. KIIM is going to be a project containing code from many sources and clear layer of communication is a must, at least i think so

It could be like a 2D layout

from top to bottom (from left to right):
*Input (Voice2text, text input, triggers from other apps etc engines)
*Processing && Feedback (Analyzing data, talking back engines)
*Actions (Talking to apps)

It should be replaceable - any module should have possibility to be replaced by any other or used 2+ modules in parallel. Also modules should have ability to get feedback form others (to use dbus?)

I concur; Kiim's natural langauge module is going to have to be easy to replace, as well. For localization.