Information Technology Reference
In-Depth Information
the following. We propose to model clarification as an iterative process where the user
is questioned for each missing object. To generate the appropriate questions to the user
we make use of the information that has been extracted from the utterance already and
of the information stored in the ontology. Assuming that we know about the skill that is
being addressed we can look up the parameters required. Using a template that repeats
the user's request as far as it has been interpreted we can then pose an accurate question
and offer possible entities for the missing objects.
Consider that the user said “ Go! ” missing the required target location. So the target
location is what we want to enquire about. This can be achieved with using a generic
template as follows:
you want me to [ assumed action ][ assumed arguments ] .
[ preposition ] which [ attribute ]? [ list of entities ]”
where [ preposition ] is the preposition associated to the parameter in question and
[ attribute ] is one of the attributes associated to the parameter. Only including one of
the parameter's attributes seems incomplete, but suits the application, since it still leads
to linguistically flawless responses. Including [ assumed arguments ] in the response
indicates what the system has already managed to interpret and additionally reminds
the user of his original request. The system would respond to the utterance “ Go! ” from
above with “ You want me to go. To which location? kitchen or bath? ”, which is exactly
what we want.
To avoid annoying the user we put a limit on the number of entities to propose to the
user. If the number of available entities exceeds, say, three we omit it from the question.
Moreover, to improve on the response we add what we call “unspecific placeholders”
to the domain ontology. So for locations we might add “ somewhere ” and for portable
thing we might add “ something ” which are then used in the response at the position of
a missing object.
There might be cases where information is not missing but instead is either wrong or
the skills available to the robot do not allow for execution. Our system should provide
information on rejecting faulty or non-executable requests. Depending on the type of
error, we propose the following templates for explanation.
1. “ I cannot [spoken verb] .” if the verb could not be matched with any skill, i.e.
spoken verb
= nil .
2. “ I do not know what [next spoken object] is .” if the object could not be matched
with any entity known to the robot, i.e. spoken objects
= nil .
3. “ I cannot [assumed action] [preposition] [next assumed object] .” if the object
could not be assigned to a parameter of the skill that is being addressed, i.e.
assumed objects
= nil .
Note that [next some list] retrieves the next element from some list . Also note that the
fluent values we mentioned above are sound given our basic action theory since the
action reject sets the fluent finished to true and leaves the other fluents' values as they
were when the utterance was rejected.
4 Experimental Evaluation
To investigate the performance of our system we evaluate it along two dimensions,
namely understanding and responsiveness.
Search WWH ::




Custom Search