Optional slots?

[Inviz]

Is your feature request related to a problem? Please describe.
I'm super impressed by your product. Really amazing offering, and great experience.

My question: is it possible to make slot optional for matching? I.e. allow the expression to be matched even if slot was not matched? My example

[open, extend, slide out] (the, a) $zone:zone (hydraulic, hydraulics, slide out, slide outs, room, section, slide, slides, cylinder, cylinders, areas, areas) (completely, entirely, fully, to the max, hundred percent, to the limit, as much as possible)

So I have only one meaningful $zone slot here, but also I have a set of words that I don't care that much for, but they can be in the command. Because i have a bunch of intents and commands reusing those sets, i'd love to turn them into slots for reuse, while basically ignoring them later. The problem is that I'd like the command to work even if they are not matched.,

Describe the solution you'd like
($zone:zone) type syntax for optional slots

Describe alternatives you've considered
I can use multiple separate commands with or without slots, but there's combinatorial complexity to support them all. I can also keep listing them as is which makes commands hard to parse visually

[Inviz]

This is what I'm doing right now, though adding extra optional keywords explode in complexity. I think I could do it on my end and post-processed export yaml... but I think the issue here is that this is mere annoyance, and not a show stopper to add that step to working with console.

I could use a single intent like this:

      - ($close:open|$open:open) (the, a) ($zone:zone|$all:all) ($term:term) ($min:state|$max:state|$mid:state)

[Inviz]

I wish slot expression would support aliasing as well... So that multiple values could be used, but they would match to one. I.e. if I used 50%, half-way, middle, 100%, fully, entirely, and 0%, minimum, none would be three options of a single slot, and so that alternative those values could be matched interchangeably, generating the same output value.

Unlike the filed issue this can not be handled with preprocessor of yaml, but need to be post-processed by whatever accepts intents. Which is also solvable, but it would be convenient if done in console

[kenarsa]

good suggestions. We keep them here and try to incorporate them into the roadmap.

[Inviz]

I wrote a small pre-processor that can expand expressions like this:

      - "$command:verb (the, a, any) $zone (and) ($zone:zone2) (and) ($zone:zone3) ($term) ($state, $percentage)"

with some slot aliasing:

    state:
      max:
        - completely
        - entirely
        - the max
        - fully
        - hundred percent
        - maximally
        - as much as possible
        - as little as possible
      min:
        - zero percent
        - none
        - a little
        - the min
        - minimally
      mid:
        - fifty percent
        - mid
        - mid way
        - half way
        - middle

into like... couple hundred expressions :D Though the speed of UI, training and recognition is superb. The size of the model is 100kb. I think doing aliasing of values by introducing a separate slot for each group of aliased values is not the best idea in terms of performance and model size. But the benefit was that I didn't have to have any knowledge of yaml file to produce clean results. I.e. the slots jsin would look like "stateXXXmid": "half way" which I could turn into "state": "mid" as post processing step. However I think I better avoid needles explosion of permutations and make post processing lookup values from the list instead.

Even though if this experiment was quite stupid, I can attest that the syntax becomes very expressive with optional/alternative keywords and slot aliases, and optional slot names. I really think it's a cheap way on your end to boost the power and conciseness of expressions

[ErisMik]

I'm happy to say that we've implemented two additional features that should help with some of your concerns. Firstly, the addition of "Macros", and secondly the ability to use both Macros and Slots in Optional and choice constructs. Full documentation is coming but in the meantime, some examples should be enough to get you started.

For the example you provided in the issue: [open, extend, slide out] (the, a) $zone:zone (hydraulic, hydraulics, slide out, slide outs, room, section, slide, slides, cylinder, cylinders, areas, areas) (completely, entirely, fully, to the max, hundred percent, to the limit, as much as possible)

You can now reduce it to something like: @openOptions (the, a) $zone:zone (@terms) (@stateMax)
with your YAML as so:

context:
  expressions:
    myIntent:
      - "@openOptions (the, a) $zone:zone (@terms) (@stateMax)"
  slots:
    zone:
      - zone one
      - zone two
      - zone three
  macros:
    openOptions:
      - open
      - extend
      - slide out
    terms:
      - hydraulic
      - slide outs
      - room
      - section
    stateMax:
      - completely
      - entirely
      - fully
      - to the max

Macros and Slots can be mixed and matched within the Optional and Choice constructs:

($close:close, $open:open, change) (the, a) [$zone:zone, all] (@term) (@minAliases, @maxAliases, $state:state)

These changes are live and hopefully this should help with more complex grammers like you have mentioned here. As usual, if you you run into any additional problems please feel free to open another issue.

[Inviz]

Amazing work! thank you. I'm curious to see what does output json looks like for cases where aliases are used (i.e. can i tell if it recognized @minAliases or @maxAliases). Will play with it soon!

[Inviz]

Oh yes... Optional slots and macros work perfectly, but it looks like macros are not represented in recognized object... that is unfortunately a bit limiting, as it only enables picovoice not to choke on extra words, but it doesn't allow making a decision on them.

But i guess it makes sense to use slots instead. Now with optional and alternative slots, we can use ($min:min, @max:max, $state:state) instead of (@minAliases, @maxAliases, $state:state)

Again, many thanks for your work. It is very smooth and complete. Good design!

[ErisMik]

Yes that is correct, Macros and Slots can be used in the same way throughout the expressions, and follow the same rules within Choices and Optionals. The only functional difference is if the matched value is present in the output. In your case with the min and max, since you want the output, Slots inside an Optional or Choice is definitely the way to go.

Macros are good to use as an alias for a Choice (eg. @brew instead of [make, brew, pour] ), to reduce writing the same entries in multiple expressions. But obviously because they can be embedded in other Choice and Optional constructs, they are quite flexible.