Make use of skip constraints

We introduced skip constraints briefly in our explanation of constraints. Here we want to go more into detail about specific queries that you can compose using this construct. Skip constraints basically allow you to find pairs of events in which one is a starting point and the other is an end point, with the end point holding some property. The two events you find may be located in the same or different transactions, but are guaranteed to be two different events. In the sections below we show the two different types of skip constraints, one allowing you to look backwards from an endpoint, and one that allows you to look forwards.

Skip backwards

A high level description of a skip constraint that skips backwards is as follows:

start -{end point constraints}> end point

A query to show all the non-empty user inputs along with the bot response that followed them would be written like this:

lu s.id, t1.e.userInput, t2.e.answerText :
    t1.e.type == "request",
    t1.e -{type=="response", answerText~=".+"}> t2.e,
    t1.e.userInput ~= ".+"

We are looking for a request event in the identifier t1 and a response event in the identifier t2. Normally t1 and t2 could be the same transaction or different ones and occur anytime during the session. By adding the skip constraint we require the answer text to immediately follow the user input, which by construction will always be in the same transaction:

t1.e -{type=="response", answerText~=".+"}> t2.e

You can interpret this as follows: t1.e will be the starting point and t2.e will be the point that ends with a non-empty reponse event.

The result of our query shows user input and bot response pairs: skip backwards

Skip forwards

A skip constraint that skips forwards can be represented as follows:

start -{start point constraints}> end point

Anolog to the previous query, this query shows us bot responses and the follow-up input given by the user:

lu s.id, t1.e.answerText, t2.e.userInput :
    t2.e.type == "request",
    t2.e.userInput ~= ".+",
    t1.e <{type=="response", answerText~=".+"}- t2.e

The bot response occurs at t1 while the user input occurs at t2. The constraint:

t1.e <{type=="response", answerText~=".+"}- t2.e

specifies that t1 will precede t2, and that the t1 event is to be the bot's response. Essentially this forces t1 and t2 to be consecutive transactions in which the output occurred in t1, while the user's response to the output occurs in the subsequent transaction t2.

The results of our query are shown here:

skip forwards

Was this page helpful?