This is an example showing how to make use of workflows. The question ‘What is the weather?’ is somewhat undefined because Qwiery does not necessarily know what your location is. Well, it would not be too difficult to include a service which picks up the IP address and through this the approximate location, but that’s another tutorial.

So, there are two possibilities:

  • you have told Qwiery before what your locations is (e.g. via things like ‘I work in New-York’) and this has been recorded in the Personalization data
  • it’s not part of your current Personalization and Qwiery needs to ask for some more info

In such a case a workflow is needed because it treats a question in a coherent set of data-gathering questions leading to an answer.

The workflow can be modeled as follows:

{
   "Id": "DLrrNEHNdR",
   "Grab": "What is the weather",
   "UserId": "Everyone",
   "Template": {
     "Answer": "ThinkResult",
     "Think": {
       "CreateReturn": {
         "Workflow": {
           "Name": "What is the weather",
           "SaveReminder": false,
           "IsActive": false,
           "Variables": {
             "Location": ""
           },
           "States": [
             {
               "Type": "PersonalizationCheck",
               "Name": "Checking the location of the user",
               "Variable": "Location",
               "ActivationResponse": "What is your current location or a place you'd like me to check?",
               "RejectResponse": "Sorry, an empty input is not valid.",
               "IsInitial": true
             },
             {
               "Type": "QA",
               "Name": "Check state",
               "IsFinal": true,
               "Execute": "getWeather",
               "ActivationResponse": "ExecuteResult"
             }
           ],
           "Transitions": [
             {
               "From": "Checking the location of the user",
               "To": "Checking the location of the user",
               "Value": false
             },
             {
               "From": "Checking the location of the user",
               "To": "Check state",
               "Value": true
             }
           ]
         }
       }
     }
   }
 }

 

  • Grab: is the question that Qwiery will catch with this template (QTL)
  • UserId: the template can be used to answer any user. If you want it only for a particular user you can specify it here.
  • Answer: setting this to ThinkResult means that the result of the thinking part of the template will be used as an answer.
  • Think: the CreateReturn goes hand in hand with the Answer set to ThinkResult. It means that the thinking will be processed and the result of this injected as an answer. Besides a Workflow type you can create a Graph here which creates additional data in the semantic network.
  • Workflow: this is a typical representation of a state machine. In this case just a tw0-state machine.
    • When the workflow is instantiated it will jump to the (unique) initial state.
    • The initial state has type PersonalizationCheck which checks stuff in the Personalization of the user. The Variable is both the bucket which holds the data and the parameter that will be checked. If the personalization is present the workflow will immediately continue to the next state. The transition with Value true tells which will be the next state.
    • If the the personalization is not found the workflow will stay in the initial state until an answer is returned. If the user uses a quit-like input (q, quit, never mind…) the workflow will halt. Because the SaveReminder is false this means that quitting will not save the flow for a later time. If you look up the ‘Send mail’ workflow in contrast you will see that the value is set to true and sending mail is hence a flow which can be halted and continued. The more simple case of fetching the current weather does not seem to be a useful thing to keep in the backlog.
    • The user’s next input will pass through to the workflow and set the value requested. One can insert at this place various validations (is it really a geographic location?) but that’s another matter.
    • After setting the variable the workflow will move to the next (final) state which also returns an answer. The workflow also keeps the newly discovered information in the personalization settings. This means that the question ‘What is your current location or a place you’d like me to check?’ will in any case be asked only once. This does not mean that you cannot ask about the weather elsewhere, you just need to use the ‘What is the weather in…?’ question instead of the less precise ‘What is the weather?’.
    • The Execute specifies a method which can be used to fetch the weather. It sits in the WorkflowActions.js but one can easily access things in other ways. It’s actually a good example of how one can use internal/corporate services to return answers.
    • The ActivationResponse set to ExecuteResult will trigger the execution and the return the result as an answer. In this case this will send a service response to the client which presumably will use Ajax to fetch a weather service (with the specified location as a parameter). The ReactJs ServiceComponent will do the rest. Of course, instead of asking the client to pull the weather you could push the weather directly. There is a lot of freedom here.

If in another situation the personalization service is not the (only) thing that needs to be checked you can easily add additional data types (next to the QA, PersonalizationCheck… types). This is really simple because (unlike strongly typed languages) in NodeJS it amounts to some strings and JSON. The workflow engine and QTL format as a whole is terribly flexible to use.