SISR basics

If you have not yet done so, please read our Intro to Semantic Interpretation for some background information about semantic interpretation. This page covers some basic concepts and terms used by SISR.

Tags

Tags are how SISR is put into grammars. Tags usually contain ECMAScript. Any script inside of a tag is executed by the Engine when the part of a rule to its left is matched.

In an ABNF grammar, tags are noted by curly brackets: { and }. Because ECMAScript also uses the curly bracket as a reserved character for conditional statements, it is sometimes necessary to have curly braces within an SISR tag. In this case, you can denote an SISR tag with the following three-character sequence: {!{ will open a tag and }!} will close it.

In GrXML grammars, tags are enclosed within the <tag> element.

The following two grammar examples are equivalent. Both listen for the word "hello" and return the string "Hello, world." when matched.

ABNF:

Or, using the three-character identifier:

GrXML:

If there are multiple tags in a matched rule, they are executed in left-to-right order. If a rule contains multiple alternatives, tags enclosed within an alternative are executed only if the alternative is matched. For example:

If the user says "yes" only the first tag is executed, as the alternative was not matched. But consider another example:

In this case, if the user says "yes," both the first and second tags are executed, as the {out = "Definitely"} tag was not restricted to either alternative. Likewise if the user says "no," the first and third tags are executed.

Likewise, when using SI Script, commands inside of a tag are executed according to the normal ECMAScript rules, which is also left to right.

Rule Variables

Each rule in the grammar has a variable associated with it. This variable is called the rule variable. The SISR tags in a rule modify that rule's variable, and the rule variable for the grammar's root rule is what is returned as the interpretation for the grammar.

If a rule has no SISR specified, its variable is set to the raw text of the utterance, i.e. whatever the speaker said that matched the rule. As an example, consider the following rule:

The rule is matched if the speaker says "Robert," "Robert Smith," "Bob," or "Bob Smith." Since no SISR is associated with the rule, if the caller says "Robert Smith" the out variable for the rule is set to "Robert Smith." If the caller says "Bob," the out variable for the rule is set to "Bob."

Ultimately, the Engine returns the rule variable from a grammar's root rule. So in a sense, writing SISR is about writing tags that will affect the root rule's variable.

Tag Formats

There are two types of SISR. The first, called String Literals does not use ECMAScript. Instead, anything within a tag is put directly into the rule's variable as a string. For instance, using String Literals with the following rule would look like this:

Now, regardless of whether a speaker says "Robert," "Robert Smith," "Bob," or "Bob Smith," the grammar returns "Robert Smith" as a string.

This simplicity makes string literals a good choice for very simple applications where no logic needs to be performed on semantic interpretation information. For many applications, however, String Literals is not sufficient.

The downside of string literals is that there is no way to perform any sort of logical operations on rule variables. One cannot add variables, and thus if two rules in a grammar are matched there is no way to preserve the SISR information.

For this reason, SI Script, the other type of SISR is more promising. In this type, each tag contains ECMAScript that is executed when the tag's rule is matched. Though a little more cumbersome to write, SI Script allows for great control over rule variables.

You cannot mix tag formats within a single grammar.

A grammar that uses SISR must specify which tag format it is using in the header. In ABNF, this is done with a line called tag-format. In GrXML, this is done by setting the tag-format attribute of the "grammar" element.

LumenVox supports both the final recommendation for the 1.0 SISR standard and also older drafts. Because of this, the Engine deviates from the official SISR 1.0 recommendation in what it expects for tag formats when STRICT_SISR_COMPLANCE is disabled.

The W3C specifies using semantics/1.0 for SI Script and semantics/1.0-literals for string literals. However, when in backward-compatibility mode (STRICT_SISR_COMPLIANCE disabled), the LumenVox Speech Engine requires semantics/1.0.2006 and semantics/1.0.2006-literals be used instead (just using semantics/1.0 will revert to an older draft). See Tag Format for a list of acceptable tag formats.

ABNF Header Example:

GrXML Header Example:

To learn how to get started adding SISR tags, see Rule Variables.