To implement Roadie, the devices need to have knowledge about what the motivations, desires and goals of the users are. For getting this knowledge, we created a plan recognizer called EventNet. This plan recognizer uses knowledge mined from the OpenMind Commonsense knowledge base, a knowledge base of 770,000 English sentences describing everyday life, contributed by volunteers on the Web. We also use ConceptNet, a semantic network derived from parsing the sentences in OpenMind and applying a spreading activation algorithm. EventNet uses temporal knowledge from this corpus and spreading activation to infer a possible set of antecedent or subsequent actions.
この知識を得るために、私たちは EventNet と呼ばれるプラン認識機能を作成した。
このプラン認識機能は OpenMind コモンセンス・ナレッジベースから得られる知識を使う。
ナレッジベースは Web 上でボランティアの貢献を元に、日常生活で用いられる 770,000 の英文を集積している。
ここでは ConceptNet も利用される。ConceptNet は OpenMind での文の解析結果を元に構築されたセマンティック (意味) のネットワークであり、拡張活性アルゴリズムを応用したものだ。
EventNet は、後に続く可能性のある操作を推測するために、この集積された文書 (コーパス) と拡張活性から得られる一時的なナレッジを使用する。
ROADIE uses EventNet to infer the user’s goals from his or her actions, and proposes specific device functions that might accomplish the user’s goal. This is illustrated below in the scenario.
The user interaction module maps the actions, goals and desires of the user to a format that the device controller can understand. This component works as a complement to the normal device’s interface, sensing the user’s interactions with the devices. It uses EventNet to find the implications of the user’s actions. We also used the Web to automatically collect pairs of device actions linked by temporal relations.
これは、シナリオの中で例証されます。ユーザーインタラクションモジュールは、ユーザーの動作、目的と欲求を装置コントローラが理解することができるフォーマットに描き出します。この部品は通常の装置のインターフェースを補うものとして動きます。そして、装置でユーザーのインタラクションを感知します。さらに、私たちは、現在の関係によってリンクしたペアの装置アクションを自動的に集めるためにウェブを使用しました。
このシナリオでは下図のようになる。
ユーザー対話モジュールは、ユーザの操作、目的、要望を対応付け、デバイスコントローラが理解できる形式にフォーマットする。
このコンポーネントは通常のデバイスのインターフェイスとして動作し、ユーザーとデバイス間の対話を感知している。
ユーザー操作との関連を見つけるためには EventNet を利用してる。
一時的な関連によって紐付けられたデバイス操作の組み合わせを自動的に収集するために、Web も利用される。
ユーザーインタラクションモジュールは、デバイスコントローラーが理解できるフォーマットを作るため、ユーザーの行動、願望、目的を測定する。この構成要素は通常デバイスインターフェースの補助、ユーザーとデバイスの相互作用の感知として作動する。それには、ユーザーの行動に含まれる意味を見つけるため、EventNetが使用される。我々はまた、時間的順序によってリンクされるデバイス行動のペアを自動的に収集するため、ウェブを使用した。
For example, if the user plugs in his or her guitar, the system infers that it is likely that the user wants to play music. It is also responsible for providing an explanation about the behavior and functionality. The input nodes are calculated using templates with English descriptions of the device’s changes of state. Then the output nodes are matched against a text description of the available goals.
The planner is used to infer the set of actions needed to configure the devices to satisfy the user’s goal. The planner decomposes the desired states to single actions that the devices can execute and creates alternative actions when something unexpected occurs. Also, the planner keeps track of the recently performed actions and whether they succeed or not. If it is impossible to accomplish the goal, the system uses this information to provide the user advice to debug and potentially correct the problem. Roadie uses the standard Graphplan implementation.
プランナーは要求された状態を個別の操作に分解する。これは、予期しない状態が発生したときに、デバイスが代替の操作を作成したり実行したりできるようにするためである。
また、プランナーは最近実行された操作と、それが成功したかどうかを記録している。
もしゴールが達成できたら、システムはこの情報を利用して、デバッグや問題解決のためのアドバイスとしてユーザーへ提供する。Roadie は標準的な Graphplan の実装を利用している。
プランナーは、ユーザの目的を満たしデバイスを形成するのに必要とされるアクションを予測するために使用されます。プランナーは、予期しないものが生じる場合、デバイスが実行し代替アクションを作成できる唯一のアクションへ要望の状態を分析していきます。さらにプランナーは、最近行なわれたアクションおよび成功するかどうかの追跡調査を行います。目的を達成することができない場合、システムはその問題をデバッグし修正の可能性があるユーザ・アドバイスを与えるため、この情報を使用します。Roadieはスタンダード・グラフプラン・インプリメンテーションを使用します。
In addition, the planner’s goals serve as a model of the capabilities of the available devices. This knowledge helps to constrain the broad options provided by EventNet. If the user says that she or he wants to hear some music, EventNet might retrieve that dancing is related to music, but since no capabilities of the device relate to dancing, those irrelevant nodes will be filtered away. The planner is also responsible for finding the states of the devices that are conflicting with the desired goal.
The device interface is the module responsible for making the devices communicate with the rest of the system. It is responsible for controlling and monitoring the devices, querying EventNet and sending the goals to the planner. This module has a text string for each change in state of the device, like “turn on the device,” “I insert a music CD.” In addition, it has all the possible goals that might be reached with the current devices: both natural language, and as a planner goal with the slots and its acceptable types.
その責任とは、デバイスを制御し、モニターし、EventNet に問い合わせてゴールをプランナーに送信することだ。
このモジュールはデバイスの状態の変化ごとにテキスト文字列を持っている。
"turn on the device," (デバイスを起動)、 "I insert a music CD." (音楽CDを挿入する) のようなものだ。
加えて、デバイスインターフェイスは、自然言語と (スロットに受入可能なタイプの) プランナーのゴールとの両方の形式で
現在のデバイスで可能性のある全てのゴールを保持している。
For example, it has <”play the music CD”, (play-music-cd [cd- player-device] [speaker-device])> for playing a music CD. So, to set up the action play-music-cd it looks for CD players and speakers and sets those particular devices into the planner. Also, English templates for each possible planner step are used to create explanations in natural language. The matching between two phrases are made using EventNet’s semantic link algorithm.
We do not assume that action sequences will never fail. Problems inherent to devices - malfunctions or misunderstandings between the user and Roadie - might emerge. Debugging consists of looking for the causes of unexpected results. For each step, we can show why the step is important, how the user can perform the step, what the consequences are of not doing this step, what the results are of performing it, and the things that might go wrong while trying to perform the step. If the user does not find this information sufficient to solve the problem, the system can automatically send queries to online search engines, user manuals, user group forums, etc.
各ステップに関して、私たちはそのステップはなぜ重要か、、どのようにしてユーザはステップを行なうことができるか、そのステップを実行しないならどのような結果になるか、そのステップを実行すると悪い結果になるに違いない事など、を示す事ができる。ユーザがその問題を解決するのに十分なこの情報を見つけなければ、システムは自動的に、オンライン検索エンジン、ユーザ・マニュアル、ユーザ・グループ・フォーラムなどへ質問を送ることができます。
デバイスに問題はつきものだ - 調子が悪かったり、ユーザーと Roadie の間で行き違いが起きることも、ありえるだろう。
デバッグは、予期しない結果の原因を探すことである。
なぜこのステップが重要なのか、ユーザーはどうやってこのステップをは実行するのか、このステップを実行しなければどうなるのか、実行した結果はどうなのか。ステップを実行しているときに何かがおかしくなったかもしれない。そのそれぞれのステップを見ることが可能である。
もしユーザーが問題解決に至る情報を得られなかった場合、システムはオンラインのサーチエンジンや、ユーザーマニュアル、ユーザフォーラムなどに
自動的に問い合わせることができる。
Collaborative or mixed-initiative interfaces are software agents that cooperate with the user to satisfy goals. The outstanding system within this paradigm is Collagen. Collagen works by having two avatars, one representing an agent and the other the user. Both agents can communicate by directly manipulating a shared user interface. Task models are used to map high-level goals into concrete device operations. We were inspired by many of Collagen’s interaction features in the design of Roadie.
このパラダイムにおいて傑出したシステムは Collagen だ。
Collagen は二人のアバターを使って動作する。一人はエージェントを表し、もう一人はユーザーを表す。
両方のエージェントは共有のユーザーインターフェイスを通じて直接操作することにより会話できる。
ハイレベルなゴールと具体的なデバイス操作を対応づけるためにはタスクモデルが使われる。
私たちは Roadie の設計において Collagen の対話機能に大いにインスパイアされた。
Learning from user’s habits can be done in two ways. First, we can raise the weight of the links when goals are chosen and lower them when they are not chosen. Also, since Roadie can show the output of EventNet’s temporal traces, the user should be able to mark the output links that are incorrect. A learning facility would also allow us to streamline the interface in the case that the user wants to perform simple tasks that they already know how to do and the system behaves as expected.
申し訳ありません。
(誤) もしゴールが達成できたら、
(正) ゴールが達成できない場合、