Asking Qwiery to send mail will trigger a workflow which captures the info necessary to send a mail. The workflow can be interrupted and will be saved as a task. To continue the workflow you can simply click on the task and Qwiery will pick up where you stopped.
Workflows are custom answers which triger the creation of state-machines. These state-machines are fully captured in a bit of JSON and contain both the logic, the parameters and the state. A user can have multiple state-machines in his backlog and they are saved as tasks. Qwiery regularly reminds you of unfinished tasks by appending a reminder to an answer. How often Qwiery reminds you is a parameter of the engine.
Workflows are easy to develop and can engender custom services (e.g. domotics) or domain-specific knowledge repositories. Any type of information gathering or things that do not fit inside a single question-answer pair should be implemented via workflows.
If you tell Qwiery that a tree is a plant it will create entities ‘plant’ and ‘tree’ in the knowledge network and make a semantic link between them. Upon asking Qwiery what is a tree it will look up the tree entity and try to see if there are semantic relations explaining what a tree is. In this simple example it will answer that a tree is a plant and although it’s the same as the earlier input it is actually acquired via a semantic network search. The method is more general and is known as deductive reasoning.
Qwiery has a language recognition module tightly linked to the Qwiery template language (QTL). Via QTL Qwiery creates knowledge stored in a graph, called the semantic network (knowledge corpus or simply graph). Conversely, the graph allows to answer questions via semantic traversals. These induced answers are created by ‘thinking’ if you wish and are only triggered as parts of the larger process, called the pipeline.
Adding modules and ways to answers question or to acquire data is very easy in Qwiery. One can assemble custom logic and combine existing Qwiery services (graph service, personality service, emotional service and so on) to answer domain-specific question or achieve a particular type of behavior.
Answers can be user-specific and these custom answers can be automatically stored by Qwiery because you say so, because they have been programmed in this way or because of an emotional state of Qwiery. This effectively means that Qwiery can behave differently to different people and in different circumstances.
The emotional module and logic underpinning this feature can be tuned in various ways or can be turned off altogether. The language module can be a mixture of common answers and user-specific ones, it can be made dependent on the user’s personality, preferences and preferred topics…or it can be plain static. The possibilities are endless really.
Explicit knowledge creation
Entities in the semantic graph can be created/deduced by Qwiery via QTL but can also be explicitly created by entering things like add idea: knots and physics, add task: I need to clean post the tax papers and so on. One can effectively use Qwiery as a content management system if one wishes.
Entities are things like a task, a thought, a person’s address, an appointment and so on. These entities are created as part of Qwiery’s thinking and deductions. You can look them up explicitly, edit them, delete them, create them, link them and more. This knowledge is stored in a user-specific area of the semantic network that Qwiery maintains. Entities can be grouped into notebooks or workspaces which you can manage. You are free to delete everything and this would delete all the knowledge that Qwiery has acquired through conversations.
Shared and public knowledge
If you ask Qwiery what quantum theory is it will find the answer in a public part of its brain/knowledge. The semantic network is divided into workspaces (notebooks, if you prefer) which can be made public or shared. A public space means that the knowledge is available to everyone. A shared space is knowledge that a user shares with others.
All users have a default workspace where all knowledge of a user is stored unless the user explicitly tells Qwiery to use/create another space. A user always has at least one space but can have plenty of them. If a user tells Qwiery that a particular space is public it means that Qwiery will freely use that knowledge to answer questions of other users. So, if you create a public workspace with knowledge about e.g. dentistry then Qwiery will use this to answer other user’s questions about dentistry. If you don’t make this workspace public but you shared with another specific user then only that user will have access to the information. All of this effectively implements something like brain-sharing and public libraries.
Variations of the same question
There are many ways to greet: hi, hey, hello… and they all end up in the same answering logic. Qwiery uses redirections to answer variations of the same thing which ensures that one doesn’t have to implement the same logic in a thousand different places.
Mechanisms are in place to ensure that Qwiery does not loop endlessly. So, one doesn’t have to explicitly check that cycles do not occur in the answering logic and language module, they are interrupted if they occur at runtime.
Modulation of an answer
Qwiery uses various modules which can alter the answer returned: it captures the psychological profile of a user over time, it collects the topics discussed, it has itself an emotional state-machine, it uses randomness to vary the possible answers to a question.
People have for every answer probably a quasi-endless stack of variations depending on the person they talk to, the context, the emotional state, age and whatnot. Qwiery similarly has a series of parameters which tune the answers returned. It does not mean that every answer is constructed by taking all parameters into account but that all these services are in place if one wishes to modulate answers in function of them. The motional module for instance can be turned off and having a one-to-one relation between question and answer is fine as well.
Natural Language Processing (NLP)
Qwiery understands English synonyms, grammatical structures (part of speech), can summarize documents and extract keywords.
Understanding human language is not an easy thing and Qwiery uses (among other approaches) various NLP techniques to make sense of questions. This happens as part of the processing but you can also ask Qwiery explicitly about word definitions, synonyms and so on. See the Language Manual for concrete examples and ways to tell Qwiery what you are looking for.
Maths, plots, conversions and all that
Qwiery understands standard mathematical calculations, can plot things and relies on the R statistical package and Python for all the rest.
You can use Qwiery as a calculator or to plot math functions. If you need more power Qwiery allows you to hook up R or Python scripts (within a security sandbox of course). See the Language Manual for concrete examples and ways to tell Qwiery what you are looking for.
What you talk about tells a lot about who you are and Qwiery maps the topics you convey to a psychological profile. Qwiery uses the MBTI classification system to map your personality.
The psychological profile can be used to tune answers, to find other users (one could build a matching or dating service in this way for example) and is just one of the many services that Qwiery uses to be more ‘smart’.
If you tell Qwiery that you like pizza, ‘I live in Firenze ‘ or the Roling Stones it will be remembered in a user-specific dictionary which can be used later on to answer questions like where am I.
Certain things can be deduced from IP address, certain things from your psychological profile and so on. However, if you explicitly provide information about yourself then Qwiery will store this and use it in parametric answers later on. This info is not part of the semantic network and is always available to you; you can edit and delete as you see fit. Everything Qwiery knows about you is available to you.
Qwiery is a service you can integrate into any app
Qwiery is a REST service you can integrate in any mobile app, desktop app and server-side app.
Integration with external services
Upon asking what will be the weather tomorrow Qwiery will look up your location (either via personalization or IP address) and request the weather forecast for the location. Various other services (Wolfram Alpha, Bing, Yahoo Finance…) are integrated out of the box and it’s very easy to add new ones (e.g. enterprise or intranet services) to the pipeline processing an answer.
The processing pipeline makes it easy to integrate external services in Qwiery; you can turn Qwiery into a corporate product-answering machine, a personal assistant keeping track of your agenda, a chat UX, a rule-based expert system, an Evernote-like system, pretty much anything.
Agenda and time
If you tell Qwiery that tomorrow you’re going to the fitness then Qwiery will add an appointment to the integrated agenda module. The more specific you are the more precise the recording will be.
Appointments are just another type of entity that Qwiery knows about. The only thing that is special is the parsing of date and time as well as the presentation; appointment are shown in an agenda.
Tasks, addresses, ideas, favorites…
Various entities liks tasks and addresses are presented in a special way.
You can store any type of info in the semantic network but some entities have a special presentation. One can also easily create custom presentations of, say, a car entity. The default web-based client of Qwiery allows you do edit entities and are presented in various ways: mosaics, data grid, lists, agenda, Google maps and so on. All of this can be altered.
Emotions and personality
Qwiery uses the Pleasure, Arousal and Dominance (PAD) framework to emulate emotions and has its own preferences, taste and personality.
Just like the other services (topics, psychology…), the emo-service deals with the emotional state of Qwiery. Together with the predefined personality traits this turns Qwiery into a biased personality. The topics you use, the words you use and so on can alter Qwiery’s emo-state and the parameters related to this can be used to tune the answers into a particular direction. By default Qwiery will appreciate science and art, but will be less smiley if you discuss things like politics and sexual topics.
Smileys and other subtle hints reveal Qwiery’s emo-state.
Direct access and commands
Qwiery will try hard to make sense of input but at times you need to give a clear instruction. Commands are prefixes which instruct Qwiery to perform a particular task. For example, using search:alpha: coffee will search Wolfram Alpha for coffee, get: John Field will pick up the entity (a person entity) entitled ‘John Field’.
There are plenty of commands to gain direct access to the various services underneath Qwiery. Adding more is really simple as well.
Qwiery was developed with simplicity and extensibility in mind. The processing pipeline is based on a plugable system of modules which can extend the way Qwiery behaves. Part of this processing is also open to external processing and web services, so one can even fetch answers from outside the base framework.
Clean, tested and documented
The code and architecture was developed with love and care.
Plenty of hints and documentation in the code. Much care was taken to make things as plain as possible. Unit tests ensure coherence. Qwiery (both the enterprise version and the open source version) were developed with attention to details and towards a framework that appeals to experimentation and joy.