Add a "context time"

[ibobo]

This could be related to #90, but more "static".

Now there's the "reference time", the time where the user lives in the present, so "today" is the day of the reference time. What would be very useful to have is a "context time", a time referenced earlier in the conversation so that some expressions could be added to it.

For example:

• User: "what will be the weather like next sunday?"
• Bot: answers
• User: "and the next morning?"
• Bot: answers about monday morning
• User: "and in the afternoon?"
• Bot: answers about monday afternoon

(I wanted to add the enhancement label, but maybe I'm not allowed to)

[patapizza]

How would Duckling figure out which one to use?
It seems like the solution here would be to update the reference time accordingly. Am I missing something?

[ibobo]

I still can't grasp all the details of this change, but what I envision is that there are a number of rules that need to follow the "context time", if present, and many other would always follow the reference time. For example "yesterday", "today", "tomorrow", "this something" always refer to the present day (reference time), things like "6 pm", "next day", "after 1 week" refer to the context time.

I think there could be some rules that are ambiguous under this description of the problem: these could be solved with your probabilistic approach and some always fallback to the context time, since that feature can be left unused by not populating the field in the call/request.

This also answers your solution that uses the reference time: what I propose here is not solvable by the reference time alone, since it influences constructs that need to always look at the present time (reference time) like "today".

[patapizza]

Ok I think I understand better.

It looks like that providing a "context time" would only solve an instance of a more general problem.
For example, in "tomorrow or the day after" we would expect "tomorrow" to resolve with the reference time, and "the day after" with a dynamic "context time" which would be "tomorrow (reference-time) + 1 day".

Thanks for bringing this, it seems like an interesting problem to solve.

cc @ar7hur

[ibobo]

Yes, by solving this you would have a starting point for solving #90, or the converse. As you put them, the two issues are one and the same.

[pimente]

Yes, this would be great to include this in duckling!

I had a similar requirement requirement and roughly solved it outside duckling the following way:

• Maintain a context time evolving with the entities parsed by duckling
• Maintain a list of ambiguous expressions
• When we match an ambiguous expression, and duckling returns multiple candidates, choose the one which is closest to the context time.

Another approach I tried was to call duckling twice (once with the reference time and once with the context time) but the context time is not an absolute lower bound like the reference time.

For example (reference time is Saturday the 4th of February) :

• User: What it the weather in two weeks ?
• Bot answers: The weather the Saturday the 18th of February is cloudy (context time becomes Saturday the 18th of February)
• User: And on Friday ? (Friday refers here to the 17th of February and is before the context time)

The first approach works (if duckling returns enough Friday candidates). The second does not.

In all cases, this is quite ugly to treat these ambiguities outside ducking because we write and maintain the ambiguous rules twice.