Test and update the intents in the JavaScript code

[Perevalov]

Context

For each component, implement a unit test by calling the Dialogflow API and activating the corresponding intent. The response result has to correspond the expected result within the context of the intent.

DoD

• welcomeIntent
• dbpediaInfoIntent
• dbpediaContributeIntent
• activeComponentsIntent
• resetComponentsListIntent
• deactivateComponentIntent
• activateComponentIntent
• activeQanaryIntent
• activateProfileIntent
• componentStartwithIntent
• showRDFGraphIntent
• createProfileIntent
• addComponentsToProfile
• removeComponentFromProfile
• componentInformationFromProfile
• helpIntent
• Emptycomponentlist
• AskQanaryIntent
• fallBack

[anbo-de]

@UditArora2000 Each live end-to-end test should ensure the following requirements:

• one PyUnit test function is dedicated to only one intent
• the process should be something like the following:
  • first, send messages directly to the Google Dialogflow API
    • for simple intents (like helpIntent or dbpediaInfoIntent) just one request would be required
    • for more complex intents (like activateComponentIntent) several requests to Dialogflow are required
      • e.g., for testing the showRDFGraph intent:
        • request answer to question Y (AskQanaryIntent)
        • request RDF graph
  • second, check the results of this action (or these actions)
    • for some intents, you can just check the values of the Dialogflow response message (JSON), e.g.:
      • welcomeIntent
      • showRDFGraphIntent
      • helpIntent
    • to test others, new intents need to be implemented to provide the validation information (luckily this directly improves the explainability of the Question Answering process), for example:
      1. activateComponent for component DBpediaSpotlight-NED
      2. activateComponent for component SimpleRealNameOfSuperHero
      3. AskQanary for "What is the real name of Batman?"
      4. explainInvolvedComponents for getting the list of Qanary components that were used during the previous process (i.e., ID of the previous process needs to be sent to the backend)
      • explainInvolvedComponents would be a new intent

Conclusion: If a test seems not to be possible, then probably an intent is mussing that would be required anyways to improve the explainability. Hence, implementing these tests will have a two-fold impact: We check the quality and extend the explainability.

[UditArora2000]

@Perevalov Hi, I am a little confused because there is no intent on Dialogflow named - AskQueryIntent, so how should I test that intent? Similarly, there are many intents that are missing on Dialogflow.

[Perevalov]

@Perevalov Hi, I am a little confused because there is no intent on Dialogflow named - AskQueryIntent, so how should I test that intent? Similarly, there are many intents that are missing on Dialogflow.

Hi, at first check whether it is present in the previous year's version

[anbo-de]

@UditArora2000 Let's stop this task to follow a more productive path.

[UditArora2000]

@Perevalov @anbo-de I was working on making the functions, but I am stuck on the following - when I need to fetch the components from qanary (link), I need to wait till all components are fetched, but this all happens inside a request to the call_recognition function (link), which probably itself uses asyncio.run() and we can't be having two event loops in the same thread according to the documentation, so I don't know any workaround for this. I idea I can think of is making another thread and get components on that thread and wait till the thread completes execution.

[Perevalov]

@Perevalov @anbo-de I was working on making the functions, but I am stuck on the following - when I need to fetch the components from qanary (link), I need to wait till all components are fetched, but this all happens inside a request to the call_recognition function (link), which probably itself uses asyncio.run() and we can't be having two event loops in the same thread according to the documentation, so I don't know any workaround for this. I idea I can think of is making another thread and get components on that thread and wait till the thread completes execution.

@UditArora2000 What's the point of making getQanaryComponents() async? In this situation I'd just make it as a sync function since the code is not making advantage of async.

[UditArora2000]

@Perevalov Sure, then I'll proceed with making it a sync function.

[UditArora2000]

@anbo-de Could you provide what the role of these intents is in regards to their implementation on Dialogflow:

1. emptyComponentsListIntent
2. askQanaryIntent
3. createProfileIntent
4. addComponentsToProfile
5. removeComponentFromProfile
6. componentInformationFromProfile
7. activateProfileIntent

Additionally, what is the difference between the intents - emptyComponentsListIntent and resetComponentsListIntent. Does the reset intent default the components to a pre-defined list of components?

[anbo-de]

@anbo-de Could you provide what the role of these intents is in regards to their implementation on Dialogflow:

@UditArora2000 In the following, I will define the behavior as I understand it.

1. emptyComponentsListIntent

• User story: As a user, I want to remove all components from the current profile, i.e., for the current session of the user all currently activated components are removed.
• Examples:
  • "empty component list"
  • "reset component list"
  • "remove all components from the current configuration"
• Expected outcome: the list of components of the current profile of the current user is empty. If the user has not switched to a new profile, then the default profile is active.
  • Requirement: Only the profiles of the current user can be influenced by the commands of the current user.
• Response to the user: "Your profile $NAME$ does contain no components, now." (where $NAME$ is the profile name)

2. askQanaryIntent

• User story: As a user, I want to ask a question to the currently active profile (configuration) of the Qanary system.
• Example: "What is the real name of Batman."
• Expected outcome: An actual answer is expected, which is calculated using the current profile. If no named profile is defined, then the default profile is used.
• Response to the user:
  • The answer of the Question Answering process.
  • If no answer could be retrieved, then answer "Sorry. There was no answer to your question retrievable."

3. createProfileIntent

• User story: As a user, I want to create a named profile which will be used for storing a configuration of components.
• Examples:
  • "create profile with the name $NAME$"
  • "create new profile $NAME$"
• Expected outcome: A new profile with the name $NAME$ is available for the current user session. The new profile does not contain any components after this initialization.
• Response to the user:
  • If the profile already exists, then "The profile $NAME$ already exists. You can switch to it using the command ..."
  • If the profile doesn't exist, then "The profile $NAME$ was created. You can switch to it using the command ..."

4. addComponentsToProfile

• User story: As a user, I want to append a named component to a named profile. The named component needs to be available in the current component list of the Qanary system.
• Examples:
  • "add component $COMPONENT-NAME$ to the profile $NAME$"
  • "add $COMPONENT-NAME$ to the profile $NAME$"
  • "add $COMPONENT-NAME$ to $NAME$"
  • "add component $COMPONENT-NAME$" (here the default profile is used)
  • "add $COMPONENT-NAME$" (here the default profile is used)
  • "add $COMPONENT-NAME$ to the default profile" (here the default profile is used)
• Expected outcome: The profile with the name $NAME$ contains now the component with the name $NAME$ (i.e., one more component).
• Response to the user:
  • If the component exists, then "The component $COMPONENT-NAME$ was added to the current profile $NAME$.".
  • If the component doesn't exist, then "The component $COMPONENT-NAME$ could not be found."

5. removeComponentFromProfile

• User story: As a user, I want to remove a component from a named profile.
• Examples:
  • "remove component $COMPONENT-NAME$ to the profile $NAME$"
  • "remove $COMPONENT-NAME$ to the profile $NAME$"
  • "remove $COMPONENT-NAME$ to $NAME$"
  • "remove component $COMPONENT-NAME$" (here the default profile is used)
  • "remove $COMPONENT-NAME$" (here the default profile is used)
• Expected outcome: If the component list of the named profile does contain the component with the name $COMPONENT-NAME$, then all appearances of the component in the component list of the profile with the name $NAME$ are eliminated (i.e., the component list does not contain any of such components)
• Response to the user:
  • If the component was in the component list of the profile, then "The component $COMPONENT-NAME$ was removed from the profile $NAME$."
  • If the component wasn't in the component list of the profile, then "The component $COMPONENT-NAME$ was not contained in the profile $NAME$. Nothing was changed."

6. componentInformationFromProfile

• User story: As a user, I want to see the current profile information. As a minimal output, I want to see which components are in the component list.
• Examples:
  • "show configuration of profile $NAME$"
  • "show configuration of $NAME$"
  • "What is the configuration of $NAME$"
  • "What is the configuration of the current profile?" (here the currently active profile is used)
  • "What is the current profile?" (here the currently active profile is used)
  • "What is the active profile?" (here the currently active profile is used)
• Expected outcome: A list of all components (minimal: names of components) is shown.
• Response to the user:
  • If the component list of the named profile is empty, then "The profile $NAME$ does not contain any components.".
  • If the component list of the named profile is not empty, then "The profile $NAME$ contains the components ...".

7. activateProfileIntent

• User story: As a user, I want to switch to the profile with the name $NAME$.
• Examples:
  • "Activate profile $NAME$"
  • "Activate $NAME$"
  • "Switch to profile $NAME$"
  • "Switch to $NAME$"
• Expected outcome: The currently active component is now the one with the name $NAME$. If such a component does not exist, then it is created and thereafter activated.
• Response to the user:
  • If the component list of the named profile is empty, then "The profile $NAME$ is now activated. It does contain no component.".
  • If the component list of the named profile is not empty, then "The profile $NAME$ is now activated (it contains ... components).".

Additionally, what is the difference between the intents - emptyComponentsListIntent and resetComponentsListIntent. Does the reset intent default the components to a pre-defined list of components?

IMO the purpose is the same. As far as I remember, our earlier intention was to distinguish the intents between asking from the component perspective and the profile perspective.

• User story: As a user, I want to remove all components from a named profile, i.e., for the current session of the user all currently components in the component list of the profile $NAME$ are removed.
• Examples:
  • "reset profile $NAME$"
  • "reset $NAME$"
  • "reset component list of profile $NAME$"
  • "reset component list of $NAME$"
  • "remove all components from the profile $NAME$"
  • "reset the profile $NAME$"
  • "reset $NAME$"
• Expected outcome: the list of components of the named profile of the current user is empty.
• Response to the user: "Your profile $NAME$ does contain no components, now." (where $NAME$ is the profile name)