[DCR] [Adaptive] Data model definition for adaptive dialog #2322
Comments
Adaptive dialog - data model definitionConcept of a dialog today broadly serves one of two main purposes -
Task completion style dialogs (#2 above) could benefit significantly by having the user either start with or provide a data model to enhance the capabilities that adaptive dialogs can provide. This document outlines the requirements and design considerations for a data model definition for Adaptive dialog. OpportunitiesA data model can help solve for a variety of core gaps we have today including but not limited to the following -
User scenarios
Example definition data modelHere's a conceptual example of a data model definition for an adaptive dialog that includes a definition for its inputs and outputs. I'd expect to be able to tie any adaptive dialog to this data model via a {
"$schema": "../../app.schema",
"$type": "Microsoft.AdaptiveDialog",
"generator": "common.lg",
"recognizer": "dialog.lu",
// Data model definition for this adaptive dialog
"dataModel": "dialog.model.json",
"$description": "Guesses the favorite movie given user's name, age and their favorite color"
}Variable definitionAt the core of the data model definition is units of information that are at play in the adaptive dialog. By design, I'm not calling this The subsequent set of examples use a simple scenario for an adaptive dialog that suggests a possible favorite movie title for a user given their name, age and favorite color. The adaptive dialog can accept values for name, age and color as input to the dialog and if missing will prompt user for that information. The dialog will finally return the favorite movie guess as a string back to the caller. Here's an example definition of the variables collection for this adaptive dialog. {
"$schema": "../../app.schema",
"$type": "Microsoft.AdaptiveDialog.DataModel",
"variables": [
{
"name": "userAge",
"type": "number", // possible types are string, number, dateTime, list, bool, object, array
"constraints": [ // Each constraint has a name and either an expression or values
{
"name": "minUserAgeReq",
"expression": "int(~input) >= 1" // ~input is a short hand for turn.value. May be turn.value should really be turn.recognized.<entityType> instead of turn.value?
},
{
"name": "maxUserAgeReq",
"expression": "int(~input) <= 150"
}
]
},
{
"name": "userName",
"type": "string",
"constraints": [
{
"name": "minLengthReq",
"expression": "length(~input) > 2"
},
{
"name": "maxLengthReq",
"expression": "length(~input) <= 150"
}
]
},
{
"name": "userFavColor",
"type": "list",
"enum": [
{
"value": "red",
"synonyms": "scarlet, vermilion, ruby, cherry, claret, blood"
},
{
"value": "green",
"synonyms": "greenish, viridescent, olive green, pea green"
}
],
"constraints": [] // no additional constraints specified.
}
]
}Using data model in LU, LG and dialogOnce I have the data model definition for my adaptive dialog, I should be able to immediately use it in LU, LG and dialog sub-systems. Use in dialogWith the above data model, I can immediately use it in dialogs. Here is an example of how this can be used in a choiceInput action that asks the user for their favorite color - {
"$type": "Microsoft.ChoiceInput",
// This will pull choices list from the data model and I do not have to define it inline.
"variable": "userFavColor",
"prompt": "What is your favorite color?",
// This corresponds to the LU model that automatically adds the variable as a list entity type.
// This is optional since the LU model will by default suggest an entity name that matches the variable name.
"value": "@userFavColor",
// This is optional once a variable is set. By default all variables value will go to $variableName
"property": "$userFavColor"
}Here's the number input - {
"$type": "Microsoft.NumberInput",
"variable": "userAge",
"prompt": "What is your age?"
// Constraints are automatically applied if defined in the data model.
// Any constraints locally defined in the input will be additive to what's defined in the data model
}Use in LUBy default for inputs, once a e.g. for choiceInput that is set to the $ userFavColor : red =
- scarlet, vermilion, ruby, cherry, claret, blood
$ userFavColor : green =
- greenish, viridescent, olive green, pea green
e.g. for numberInput that is set to the $ prebuilt : number Role = [userAge]
> I'd really like to simplify this to just this definition instead -
> $ number : userAge
For use cases outside of a visual authoring tool where we can automatically do this, we will update the .lu file format to natively support import of the .model file. [ModelDefinition](../../dialog.model.json)
> Once we have a model definition, we can simply add an entity of that type via this short hand and the parser will expand the description
$ userAge
Use in LGYou always will have access to the data model definition as a JSON object in all templates and expressions inside LG for that particular dialog, accessible via '$.variableName' Here's an example of constructing a suggested action based on the favorite color definition in the data model - # AskForColor
- What is your favorite color? [ColorSuggestions]
# ColorSuggestions
- ```
[Suggestions=@{join($.userFavColor.enum.value, ' | ')}
Call to Input and output definitionOnce I have the variables defined, I can define the structure of inputs and outputs for this dialog based on that information. Here's an example of that. {
"$schema": "../../app.schema",
"$type": "Microsoft.AdaptiveDialog.DataModel",
"variables": [
{
"name": "userAge",
"type": "number", // possible types are string, number, dateTime, list, bool, object, array
"constraints": [ // Each constraint has a name and either an expression or values
{
"name": "minUserAgeReq",
"expression": "int(~input) >= 1" // ~input is a short hand for turn.value. May be turn.value should really be turn.recognized.<entityType> instead of turn.value?
},
{
"name": "maxUserAgeReq",
"expression": "int(~input) <= 150"
}
]
},
{
"name": "userName",
"type": "string",
"constraints": [
{
"name": "minLengthReq",
"expression": "length(~input) > 2"
},
{
"name": "maxLengthReq",
"expression": "length(~input) <= 150"
}
]
},
{
"name": "userFavColor",
"type": "list",
"enum": [
{
"value": "red",
"synonyms": "scarlet, vermilion, ruby, cherry, claret, blood"
},
{
"value": "green",
"synonyms": "greenish, viridescent, olive green, pea green"
}
],
"constraints": [] // no additional constraints specified.
}
],
// Input definition for this dialog.
"input": [
{
"variable": "userName",
// %abcd is a short hand for dialog.options.userName -> value that is passed in to this dialog.
// It is conceivable that we could use expressions with prebuilt functions to walk incoming dialog.options object to find a specific value that meets the variable constraints
"value": "%userName",
"optional": true,
},
{
"variable": "userAge",
"value": "%userAge",
"optional": true
},
{
"variable": "userFavColor",
"value": "%userFavColor",
"optional": true
}
],
// output definition for this dialog.
"output": {
"variable": "favMovieGuess",
"optional": false
}
}Other capabilities listed in requirements should build on top of this core definition – e.g. multi-turn conversations just using the data model definition, etc. Pre-seeding actions based on data model definitionIt is conceivable that given just the data model definition, that a visual authoring tool would be able to automatically get the user set up with a series of actions that prompt user for required information. An experience like this could be backed by the Note: The initial botification from data model would be a one way street. As users continue to build out their actions, a visual authoring tool could prompt the author to consider adding relevant information from their actions collection into the data model. As an example, with the above data model, we should be able to generate the following adaptive dialog actions via the {
"$schema": "../../app.schema",
"$type": "Microsoft.AdapiveDialog",
"dataModel": "dialog.model.json",
"recognizer": "dialog.lu",
"generator": "common.lg",
"events": [
{
"$type": "Microsoft.BeginDialog",
"actions": [
{
"$type": "Microsoft.TextInput",
"variable": "userName",
"prompt": "e.g. give me a value for userName",
"invalidPrompt": "e.g. {turn.value} does not work. Give me a value for userName",
"maxTurnCount": 3,
"defaultValue": "'Human'",
"value": "coalesce(@userName, @personName)",
},
{
"$type": "Microsoft.NumberInput",
"variable": "userAge",
"prompt": "e.g. give me a value for userAge",
"invalidPrompt": "e.g. {turn.value} does not work. Give me a value for userAge",
"maxTurnCount": 3,
"defaultValue": "30",
"value": "coalesce(@userAge, @age, @number)",
},
{
"$type": "Microsoft.ChoiceInput",
"variable": "userFavColor",
"prompt": "e.g. give me a value for userFavColor",
"invalidPrompt": "e.g. {turn.value} does not work. Give me a value for userFavColor. \n \[Suggestions=@{join($.userFavColor.enum.value, ' | ')}\]",
"maxTurnCount": 3,
"defaultValue": "red",
"value": "@userFavColor"
}
]
}
]
}Generic FormInput actionWe could also replace the flat Note: the core data model does not contain any definition for conversation behavior. Those are always specified and managed at actions level to have clear separate between the constructs as well as have the core data model be reusable across functions. As an example, with the above data model, user should be able to add a {
"$schema": "../../app.schema",
"$type": "Microsoft.AdaptiveDialog",
"dataModel": "dialog.model.json",
"generator": "common.lg",
"recognizer": "dialog.lu",
"events": [
{
"$type": "Microsoft.BeginDialog",
"actions": [
{
"$type": "Microsoft.FormInput",
"slots": [
{
"variable": "userName",
"prompt": "what is your name?",
"unrecognizedPrompt": "Sorry, I do not understand '{turn.activity.text}'. What is your name?",
"maxTurnCount": 3,
"defaultValue": "'Human'",
"validations": [
{
// These named constraints come from the schema
"name": "minLengthReq",
"invalidPrompt": "Sorry, '{turn.value}' does not work. I'm looking for a value that is at least 3 characters in length. What is your name?"
},
{
"name": "maxLengthReq",
"invalidPrompt": "Sorry, '{turn.value}' does not work. I'm looking for a value that is up to 150 characters in length. What is your name?"
}
]
},
// configuration for additional slots.
]
}
]
}
]
} |
|
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days |
Today, the input/ output for an adaptive dialog is a black box which gets in the way of ability to effectively compose them as well as gets in the way of easily being able to define an adaptive dialog as a reusable component. Providing a clear interface definition of what the adaptive dialog expects and accepts as input as well as defining what the adaptive dialog would return as possible value and its structure + type information can help with composition as well as export/ import an adaptive dialog as a functional unit. We will need to invest in a data model definition for adaptive dialogs to enable that.
The text was updated successfully, but these errors were encountered: