Make "known" values implicit when a value is changed to anything other than "none"

[beckydvn]

When explicitly defining an action, the known value has to be stated explicitly when a value is updated. Take this example from plan4dial's bank_bot:

  offer-new:
    type: dialogue
    message_variants:
      - Would you like to create a new account?
      - I can also create a new account for you. Would you like to do that today?
    condition:
      tried-create:
        value: false
      task:
        known: false
    effect:
      start-task:
        oneof:
          outcomes:
            want-create:
              updates:
                task:
                  known: true
                  value: create account
              intent: confirm

It's a small change, but it would be less mental overhead for the user if the system could infer that known be set to true when the value is updated to something other than none.

[haz]

What happens when you don't specify anything? I.e., what's the default behaviour?

[beckydvn]

Depends on if the "known" status is needed in another action or not 😉 In most cases the "known" setting is used as a precondition,, meaning that (currently) without adding it explicitly, the planner will likely not be able to find a plan. If it isn't needed, nothing would change, but in that case the context variable shouldn't have a "known" parameter. However, there is no harm to having one (just extra fluents for the planner to look at).

[haz]

No, not the downstream implications -- more directly to the value. Is the the known property just whatever it used to be?

[beckydvn]

Not sure I understand-- the "known" property is added (or omitted) by the user. If they added it with no value, the YAML wouldn't compile 🤔

[haz]

I mean if they didn't include the known property at all, what would the impact of the action be? To retain whatever the know property was before the action was executed?

[beckydvn]

Ah! I see what you mean. Yes, the previous value would be maintained, at least in terms of the plan generated. (I believe Hovor has some internal structure of "knowledge"-- e.g. IIRC if you set a "known" to False it automatically sets the value to null), but we want to make sure the plan itself takes knowledge into account

[haz]

Ah, got it. Then I'd flag this as a bug ;).

[beckydvn]

When Plan4Dial becomes something more than just a YAML file, I imagine a system where they specify the context variable, and based on that they get the appropriate drop-downs ("known" = True, False, [or Maybe]) whenever they want to change the value 😉 But that's far and away...