gabrielgatu/mozzie

A stupid and still in very alpha stage artificial intelligence

Mozzie

Mozzie is the core of an artificial intelligence I'm working on just for fun, and still in alpha stage, that takes a phrase and produces an equivalent intent, used by micro-controllers to execute the command parsed.

The logic behind is divided into 5 steps:

• 1: Phrase normalization
• 2: Language-detection and translation
• 3: Word parsing and categorizing
• 4: Intent creation
• 5: Dispatching

Contribution

Just open an issue/pull request and describe it in a detailed way. Always be polite and respect others work. I'll do my best to keep up.

Naming

Mozzie, from White Collar, obviously ;)

License

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

mozzie's Issues

[FEATURE] Support categorized opts in Intent

Currently word parsing is based on categories and types. When a word has a known and predefined type, like action or subject, then it will be put inside the relative field inside the Intent.

This is good for identifying the main subjects of the phrase, but it doesn't allow Mozzie to learn more about some specific words, like cities, playlist names, and so on... And, more important, it doesn't allow the handle_action inside services to correctly elaborate some intents (for example, when the user wants to play a specific playlist, how we know which is the playlist name inside the phrase?)

So, a possible solution is to allow other types, in addition to the predefined ones. And when a word with a "custom" type is encountered, put the word inside the others field in the Intent, but remember also the category it belongs to. If the type is unknown, then the key will be unknown.

• Transform the opts inside Intent into a HashMap<String, Vec<Word>>.

Second, a word could have multiple types. And for each type it has, clone the word and put it inside the relative field. An example could be:

• start: as the action to start and play a song

• start: as a playlist name normally played by a user

• Implement multiple types for words

[FEATURE] Remove unnecessary words from phrase

Given that the current Mozzie logic works through key words, some words like prepositions are not useful when analysing the intent of the phrase.

So, after the translation completes, and we have a plain english phrase, we can eliminate some words, to speed up and reduce the complexity of the next steps.

We could have a database table containing all the unnecessary words, then eliminate all the words matching with the values contained in this table.

[FEATURE] Write syntax extension for declaring actions for services

As viewed in Rocket and other rust projects, compiler plugins can be a useful tool for writing nice DSL's.
Currently in Mozzie there is not a way to efficiently declare action handlers. The solution for now could be to pattern match the intent arguments but I really don't like it and leads really fast to complex code.

A solution could be to have an extension to allow something like this:

#[action(actions=["play"], subjects=["song"], others=[])]
fn handle_action(intent: Intent) -> Outcome {}

As seen here, it's very similar to what Rocket is currently doing. Some code could be extrapolated from there and adapted to this scenario. I'm still learning how macros and plugins work in rust :)

Some link to not forget:

• https://alschwalm.com/blog/static/2017/03/07/exploring-dynamic-dispatch-in-rust/
• https://www.gulshansingh.com/posts/how-to-write-a-rust-syntax-extension/
• https://github.com/SergioBenitez/Rocket/blob/master/codegen/src/decorators/route.rs

[FEATURE] Add Outcome as a result of an Service handle_action and Intent as a arg

The handle_action function inside services currently take only a reference to self. We need to change this and support yielding an outcome from the function.

The Outcome value should allow us to represent these 2 states:

• Success
  • Action: name of the action that should be passed to the micro-controller
  • Opts: set of extra parameters to pass to the micro-controller
• Failure
  • Error: type of error found that prevented the handler to be completed

Failure

When a handle_action fails it would be nice to allow the service to communicate what caused the failure (for example, because it didn't found the playlist name to play). Currently we indicate just the type of error (something like Error::MissingArgument) but nothing more specific. I still need to think how this could be done.

Intent parameter

Finally, the handle_action function should take a reference to the Intent, in case there is the need to access some fields, like the others one.

Final result

fn handle_action(&self, intent: &Intent) -> Outcome {
  ...
}