-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introduce context #39
Comments
Context handling as currently solved within one sentence and later for related sentences must be reviewed. A better solution could be to make use of constituent/phrase tagging (tags for question tests) to determine the reference of e.g. a pronoun. |
Context handling outside the scope of one sentence can only be solved if the system responses (with the result of the script execution) are also recorded in the db. For example: -List contacts with Alice! The relative pronoun 'that' refers to something that is out of the scope of the sentence. In the tutorial, the 'Relative clauses' section describes how a reference can be set within a sentence in cases like 'List files that are executable!" where 'that' refers to 'files'. The way of creating a semantic rule for setting up such references could be extended by adding a new root_type like 'C' (for Context) so that can be specified in the fields main_lookup_root or dependency_lookup_root. So when the semantic rule would combine the relative pronoun with the symbol of something else being out of scope to set up a reference, its root_type would be set as 'C'. That could then be handled in the sparser's is_valid_combination() function to look up the lexeme of that symbol being tagged with the relative pronoun in db table analyses_deps as close in time to the current utterance as possible. Although this could work, it poses a problem of interpreting the results of the scripts generated by hi which for example looks like in the previous example as:
One idea is to reuse the hi() API function by using the system user id 'hi' and passing in the result returned by the client system function that was indicated to be executed by the result the script execution returned. The functor returning the result from the script shall as well return a template to which the result of the client system function call result can be mapped. The template shall be in a form which is detailed enough and can be analysed by the interpreter. E.g. instead of returning just string(s) and number(s) like above, a json structure shall be returned like:
That can be analysed with a parser for the json language just like it's done for english or hungarian currently and the analysis would be put in the db tables as usual along with tagging the relevant values (or keys as well?) like "Alice" and "00 1 234 567 89" during interpretation. No functor implementations seem to be necessary for the json interpreter currently. Calling the hi() function this way means that the system response is not paired to the previous user utterance. Although its id (i.e. the analysis key) could be passed in if hi() had a corresponding overloaded interface or at least the user name to indicate whose latest utterance the system reponse shall be paired. Putting the analysis of the response in the db and tagging the numbers (not the word but the phone numbers) as c_values with relative pronouns like 'that' (besides the question word tags) would make it possible for a context search outlined above to find that number. This approach has the advantage that it can search in natural language contexts as well not only in system responses in a unified way. So e.g. if the user tells the number instead of the system, it shall also work: -The phone number of Alice is 00 1 234 567 89. What needs to be done is like: hints: |
Managed to parse a basic json like: |
After commit #595b090 to wip at least three known todos remain: |
Bringing it over here from #10.
The text was updated successfully, but these errors were encountered: