Create Good Subpatterns
Subpatterns are one of the most powerful NL recognition features in the BuddyScript language. They allow you to write efficient, reusable code. Many subpatterns are defined in various packages in the Vocabulary directories for each language in BuddyScriptLib. Have a look at the subpatterns created there before you create your own. Many general parts-of-speech and “chat” subpatterns, as well as subpatterns for industry-specific terminology, are defined there. Create subpatterns for anything else you foresee your end users chatting about – product names, peoples’ names, place names, etc.
NL-brick Subpatterns
When you define a subpattern as an NL-brick, every element of the subpattern that is recognized at maximum strength is a candidate to replace sections of your NL handles. This is a very useful property, but use it carefully. If you want only certain elements to replace the natural language in an NL-brick subpattern, make the other elements score lower.
Define subpatterns as NL-bricks by putting them within NL-brick zones. If your project is derived from the WLATemplate, add NL-bricks in “YourAgent/YourLanguage/CustomSubpatterns.pkg,” which already contains an NL-brick zone.
Example:
begin properties SubpatternsAreNLBricks // Start of NL brick zone
…
### “n” prefix: Noun Stems
subpattern nBike + (bike|bikes)
subpattern nMotorcycle
+ (motorcycle|motorcycles)
+ motor (cycle|cycles)
subpattern nMotorbike
+ (motorbike|motorbikes)
+ motor =nBike
### “ns” prefix: Noun Senses
subpattern nsMotorcycle
+ (=nMotorcycle|=nMotorbike)
+ =nBike {score=MACRO_ MEDIUM_SCORE}
…
end properties SubpatternsAreNLBricks // End of NL brick zone
In the above example, the word “motorcycles” in the natural language handle “? How much do motorcycles cost?” will be replaced by = nsMotorcycle, but the word “bike” in the natural language handle “? Can I ride my bike to work?” will not be replaced by =nsMotorcycle as “bike” does not match at maximum strength in the subpattern. Therefore, if the user types “How much do bikes cost?” it will match on “? How much do motorcycles cost?” (albeit with a lower score), but if the user types “Can I ride my motorcycle to work?” it will not match on “? Can I ride my bike to work?”
Example:
begin properties SubpatternsAreNLBricks
subpattern nsNewYorkCity
+ (new york [city]|manhattan)
+ nyc {spellcorrect=no}
return “New York City”
end properties SubpatternsAreNLBricks
subpattern ACity
+ CITY=NewYorkCity
+ CITY=SanFrancisco
+ CITY=Chicago
return CITY
In the above example, the =ACity subpattern should not be an NL-brick because you would not want “New York City” in a natural language handle such as “? What are some good restaurants in New York City?” to be replaced by =ACity (if it were, the user query “What are some good restaurants in Chicago?” would match on “? What are some good restaurants in New York City?”)
In general, specifying some subpatterns as NL-bricks and leaving others as non-NL-bricks (the default behavior) allows you great control over how subpatterns are used in your matching.
Binding Subpatterns to Variables
Bind subpatterns to variables whenever you need to use the value returned by a subpattern, either as a parameter in a data request, to store interesting user data, or simply to make the agent’s response “smarter.”
Example:
- Where do you live?
? I live in CITY=ACity
? CITY=ACity
STATE = GetStateForCity(CITY)
USER_LOCATION = CITY
- Wow! I love CITY! That’s in the state of STATE, right?
User: I live in nyc
Agent: Wow! I love New York City! That’s in the state of New York, right?
