You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I know the main contribution of the SMCalFlow is targeted in a new representation of dialogue state, but it seems the SMCalFlow seems to be a very complex scheme. It is true that by using Dataflow structure you can solve many hard problems in the dialogue like reference, but as you mentioned in the repository, all the data in the SMCalFlow is represented as lispress language. Both the generated prediction and the gold data are treated as a lispress program and will be executed using a parser to get the results, so it really makes me think a SMCalFlow is more like a Semantic Parsing task, which the goal is to translate the given user query to the lispress program, even though the program is intended to represent dialogue states, but the core is to translate user query to an executable format, whereas in conventional dialogue state tracking like MultiWoz or DSTC, the dialogue state is mostly represented as a multiple slot-value pair, which is mostly not executable as a program language. If possible, could you share some of your opinions about this?
The text was updated successfully, but these errors were encountered:
I know the main contribution of the SMCalFlow is targeted in a new representation of dialogue state, but it seems the SMCalFlow seems to be a very complex scheme. It is true that by using Dataflow structure you can solve many hard problems in the dialogue like reference, but as you mentioned in the repository, all the data in the SMCalFlow is represented as lispress language. Both the generated prediction and the gold data are treated as a lispress program and will be executed using a parser to get the results, so it really makes me think a SMCalFlow is more like a Semantic Parsing task, which the goal is to translate the given user query to the lispress program, even though the program is intended to represent dialogue states, but the core is to translate user query to an executable format, whereas in conventional dialogue state tracking like MultiWoz or DSTC, the dialogue state is mostly represented as a multiple slot-value pair, which is mostly not executable as a program language. If possible, could you share some of your opinions about this?
The text was updated successfully, but these errors were encountered: