IBM Cloud Docs
アノテーションのセットアップ

アノテーションのセットアップ

対象の業界とその言語についての知識を持つユーザーは、文書にアノテーションを付ける必要があります。

ヒューマン・アノテーターがワークスペースにアクセスできるようにするため、以下の作業を実行します。

  • 使用している Knowledge Studio インスタンスに、対象分野の専門家を招待します。

  • ヒューマン・アノテーターと、彼らにアノテーションを付けてもらいたいアノテーション・セットとを関連付けます。

  • セット内の文書にアノテーションを付けるようにヒューマン・アノテーターを割り当てるタスクを作成します。

    ヒューマン・アノテーターにタスクを明示的に割り当てるまでは、アノテーターは Knowledge Studio にログインしてもワークスペースを見ることはできません。

ユーザー (ヒューマン・アノテーター) は、文書にアノテーションを付ける方法について詳しく説明されている『文書のアノテーション付け』をよく理解する必要があります。

モデルのライフサイクル

Knowledge Studio で作成するモデルは、自然言語処理 (NLP) パイプラインに組み込み可能なソフトウェア・コンポーネントです。

Knowledge Studio を使用して、新しい分野についてのモデルを作成、評価、および改善できます。 モデルは、自然言語コンテンツに含まれているテキストにアノテーション (メタデータ) を追加します。 アノテーションは、分野コンテンツ内の関心のあるエンティティーのメンション、エンティティー間の関係、および、同じエンティティーの複数のメンションの照応関係を示すものであり、アプリケーションはアノテーションを使用して自動的にテキストを分析および処理することができます。 アプリケーション・ユーザーには、意味の抽出、洞察の発見、および自然言語文脈での回答を入手できることで、このレベルの分析が効果的になります。

モデルの作成は、複数ステップの処理を反復することで行われます。この処理には、知識の整理、グランド・トゥルースの生成、モデルの開発、モデルの評価、およびランタイム・デプロイメントという段階があります。

分野適応の全体図

次の図は、モデル開発の 5 つの段階の相互作用と、各段階で発生する標準的なアクティビティーを要約したものです。

モデル開発の5つのステージと、各ステージで発生するアクティビティの要約。 図 2. モデル開発の5つのステージと、各ステージで発生するアクティビティの要約。

知識の整理

この段階は、Knowledge Studio の外部にあり、特定の分野に関連するコンテンツの選択、収集、保存、および保守を行うプロセスです。 知識の整理により、データは信頼できる情報および知識に変換され、データの価値が高まります。

グランド・トゥルースの生成

この段階では、特定の分野に Knowledge Studio ソリューションを適応させるために使用できる入念に吟味されたデータの集合を、Watson のツールおよびベスト・プラクティスを使用して生成します。 この入念に吟味されたデータはグランド・トゥルース またはゴールド標準文書 と呼ばれます。グランド・トゥルースの不正確さはそれに依存するアプリケーションにおける不正確さと相関するため、これが正確であることは大変重要です。

新しい分野について Watson に教えることの根幹は、その分野のコンテンツ内の関心のあるエンティティーについて、エンティティー同士の関係について、および、エンティティーが互いにどのように照応するのかについての知識を与えることです。 この知識の収集には以下のアクティビティーが含まれます。

  • 対象分野の専門家に参加してもらって、以下のリソースを作成するか、または、再利用できるか対象分野用に変更できる既存リソースを特定します。

    • 分野コンテンツ内の単語および文にどのようにアノテーションを付ければよいのかをヒューマン・アノテーターが学習するのを助けるためのアノテーション・ガイドラインおよび例。
    • テキスト分析を通して分野コンテンツ内で検出される可能性のある分野固有のタイプ (オブジェクト) および特徴 (データ種別) を定義するタイプ・システム。 タイプ・システムは、ヒューマン・アノテーターが文書に追加できるアノテーションのタイプを制御します。
    • 分野コンテンツにおいて等価の用語として扱われるべき用語の辞書。

  • 分野コンテンツの代表的な文書を集めたコーパスを作成します。

  • Knowledge Studio ワークスペースに追加する辞書に基づいて、文書に事前アノテーション付けを行います。 機械学習モデルを作成した後、そのモデルを使用して、コーパスに追加する新規文書に事前アノテーション付けを行うことができます。 事前アノテーションは、アノテーション付けに機械学習モデルを使用できるようになる前に可能な範囲で、文書に機械的にアノテーションを付けるプロセスです。 事前アノテーションを使用すると、ヒューマン・アノテーション作成の一部を、正確かどうかの検証が少なくてすむマシン・アノテーションで置き換えることによって、ヒューマン・アノテーションの作業量を減らすことができます。

  • ヒューマン・アノテーター間で文書を配分します。その後、ヒューマン・アノテーターは、それぞれが少しずつ文書を担当して、IBM Watson® Knowledge Studio グランド・トゥルース・エディター・ツールを使用して手動でアノテーションを追加します。

  • ヒューマン・アノテーション結果を比較し、競合を解決します。 このフェーズでの裁定は、正確で整合性のあるアノテーション付けが行われた文書がグランド・トゥルースにプロモートされ、機械学習モデルのトレーニングとテストに使えるようにするために必要です。

モデルの開発

この段階では、Knowledge Studio ツールを使用してモデルを作成します。 グランド・トゥルースが確立された後、ヒューマン・アノテーション結果を、大きな文書集合 (例えば、数百万の文書を含む集合) への自動アノテーション追加のアルゴリズムをトレーニングするために使用できます。

モデルの評価

この段階では、Knowledge Studio ツールを使用して、モデルを改良し、パフォーマンスを改善します。 モデルによって生成された結果が、グランド・トゥルース文書のテスト・セットに照らして評価されます。 正確度分析 は、アノテーションの誤りの原因を特定します。 ヘッドルーム分析 は、どの誤りに着目する必要があるのかと、モデルの改良が最大の影響をもたらす可能性があるのはどこなのかを査定するのを支援します。 満足できるレベルの正確さが達成されるまで、パフォーマンスを向上させるために繰り返し調整することができます。

モデルの展開

この段階では、モデルが機械学習ランタイム環境で実行できるようにコンポーネントをエクスポートし、他の Watson コグニティブ・アプリケーションがモデルにアクセスできるようにします。 例えば、IBM Watson® Natural Language Understanding サービスまたは IBM Watson® Discovery サービスで使用するために機械学習モデルをデプロイしたり、IBM Watson Explorer での使用のためにモデルをエクスポートしたりすることができます。

アノテーション・タスクの作成

アノテーション・プロセス管理者がアノテーション・タスクを作成した後でないと、ヒューマン・アノテーターは文書へのアノテーションの追加を開始できません。

Admin およびプロジェクト管理者は、グランド・トゥルース文書セットに直接アノテーションを付けることができます。 文書セットに直接アノテーションを付けるを参照してください。

このタスクについて

アノテーション・タスクは、どの文書にアノテーションが付けられる必要があるのかを指定します。 ヒューマン・アノテーターの作業成績を比較するため、および、彼らがどの程度の整合性でアノテーション・ガイドラインを適用するのかを確認するため、少なくとも 2 人のヒューマン・アノテーターをタスクに含める必要があります。 さらに、いくらかの割合の文書が、タスクに追加するアノテーション・セットのすべてに含まれている必要があります (アノテーション・セットを作成するときに重複パーセンテージを指定します)。

重要

  • アノテーション・タスクは、ヒューマン・アノテーターたちが別々の場所でテキストにアノテーションを付けるのを許可するために存在する、一時的な概念です。 また、承認されたアノテーションのみがグランド・トゥルースにプロモートされることを保証します。
  • 複数のアクティブ・タスクが同時に同じアノテーション・セットを含むことはできません。 あるタスクに含まれているアノテーション・セットを別のタスクに追加するには、最初に、そのアノテーション・セットがアクティブであるタスクを削除する必要があります。
  • あるヒューマン・アノテーターのユーザー・アカウントを削除すると、そのアノテーターのアノテーションにも影響が及びます。 そのユーザーに割り当てられていたが、グランド・トゥルースにプロモートされなかった文書中のアノテーションは削除されます。
  • ヒューマン・アノテーション・タスクの作成後にタイプ・システムまたはグランド・トゥルース・エディターの設定が変更された場合、変更をタスクに伝搬するかどうかを決定する必要があります。 タイプ・システムの変更はアノテーションに影響する可能性があり、ヒューマン・アノテーターが文書のレビューと更新を行うことが必要になる場合があります。
  • 辞書が変更されても、その変更は現行のアノテーション・タスクには反映されません。 リソースの変更をグランド・トゥルースに適用するには、新しいアノテーション・タスクを作成する必要があります。
  • ワークスペース当たり最大 256 のアノテーション・タスクを作成できます。

手順

アノテーション・タスクを作成するには、次のようにします。

  1. Knowledge Studio 管理者としてログインし、ワークスペースを選択します。

  2. 「機械学習モデル (Machine Learning Model)」 > **「アノテーション (Annotations)」ページを選択し、「アノテーション・タスク (Annotation Tasks)」**タブをクリックします。

  3. **「タスクの追加 (Add Task)」**をクリックします。

  4. 記述タスク名を指定し、タスクの完了期限の日付を選択します。

  5. アノテーション・セットを利用できない場合、**「アノテーション・セットの作成 (Create Annotation Sets)」**をクリックします。

    1. 基本セットとして、アノテーション・セットに分割する文書セットまたはアノテーション・セットを選択します。

    2. 重複値に、各アノテーション・セットに含める文書のパーセンテージを指定します。 2 人以上のヒューマン・アノテーターが同じ文書にアノテーションを付けないと、アノテーター間合意スコアを計算できません。 例えば、30 文書を含むコーパスに対して 20% の重複値を指定し、コーパスを 3 つの文書セットに分割した場合、6 つの文書 (20%) にはすべてのヒューマン・アノテーターがアノテーションを付けることになります。 残りの 24 文書は、3 人のヒューマン・アノテーターに分配されます (それぞれ 8 ずつ)。 したがって、各アノテーターは、アノテーションを付ける対象として 14 文書を受け取ります (6+8)。

    機械学習モデルのトレーニングに使用する予定のアノテーション・セットには、アノテーションが付けられた文書が 10 以上含まれている必要があります。

    1. ヒューマン・アノテーターのリストからユーザー名を選択します。

    2. アノテーション・セットに名前を付けます。

      ヒューマン・アノテーターの作業をワークスペースの進行に応じて評価するための優れた方法として、アノテーション・セットには、そのセットに割り当てられたヒューマン・アノテーターを識別できるような名前を付けることをお勧めします。 アノテーション・セットの作成後に名前を変更することはできません。

      アノテーション・セット名の最大サイズは 256 文字です。

    3. **「生成」**をクリックします。

  6. 使用可能なアノテーション・セットのリストが、割り当てられたヒューマン・アノテーターの名前と共に**「使用可能なセット (Available Sets)」に表示されます。 アノテーション・タスクに使用可能なセットを追加するには、「タスクに追加 (Add to task)」**をクリックします。

  7. タスクに含めるすべてのアノテーション・セットが**「選択済みセット (Selected Sets)」に表示されていることを確認し、「保存 (Save)」**をクリックしてタスクを作成します。

次のタスク

タスクが作成されたら、「機械学習モデル (Machine Learning Model)」 > **「アノテーション (Annotations)」ページの「アノテーション・タスク (Annotation Tasks)」**タブに戻り、各ヒューマン・アノテーターの進行状況を表示できます。 また、以下のタスクを実行することもできます。

  • アノテーション・セット間で重複している承認済み文書を調べて、アノテーション競合を解決します。
  • アノテーション・セットを追加する先のタスクを開きます。 追加するアノテーション・セットが、元のアノテーション・セット内の文書と重複する文書を含んでいるようにします。

メインナビゲーションの**「設定」**タブから、以下の情報を指定できます。

  • グランド・トゥルース・エディターでカラーおよびキーボード・ショートカットを使用するための設定を指定します。
  • アノテーター間一致しきい値を指定し、その後で、タスクを開いて、複数のヒューマン・アノテーターが同じ文書にどの程度一貫したアノテーションを付けたのかを確認します。
  • アノテーション・ガイドラインをグランド・トゥルース・エディターに接続するための URL を指定します。

グランド・トゥルース・エディター設定の構成

プロジェクト管理者は、グランド・トゥルース・エディターでカラーおよびキーボード・ショートカットを使用するための設定を指定できます。

手順

グランド・トゥルース・エディター操作のビジュアル設定を指定するには、次のようにします。

  1. Knowledge Studio 管理者としてログインし、ワークスペースを選択します。

  2. 左側にあるナビゲーションから、「設定」>**「文書アノテーション設定 (Document Annotation Settings)」**を選択します。

  3. **「エンティティー・タイプ (Entity Types)」タブまたは「関係タイプ (Relation Types)」**タブを選択します。

  4. 変更したいエンティティー・タイプまたは関係タイプを選択し、**「キーボード・ショートカットおよびカラーの編集 (Edit keyboard shortcuts and colors)」**をクリックします。 各タイプに対して定義できる内容は次のとおりです。

    • キーボード・ショートカット。これは、ユーザーが<key>を入力して、強調表示されたテキストにタイプ・ラベルを適用できることを意味します。 例えば、o を ORGANIZATION のキーボード・ショートカットとして定義しておくと、ユーザーはテキストを選択してから o キーを押すだけで、強調表示されたテキストに ORGANIZATION エンティティー・タイプを適用できます。 大文字を割り当てる場合、ユーザーはShift+<key>を押す必要があります。
    • テキストの色。 テキストにラベルが付いた後でもテキストがよく見えるように、テキストの色と背景色が対照的になるようにしてください。
    • 背景色。 これは、アノテーションを付けた後にエンティティーに適用されるラベルの色です。

    ヒューマン・アノテーターは、文書にアノテーションを付けるときに、キーボード・ショートカットを使用してアノテーションを素早く追加できます。 アノテーション・ラベルの色とテキストの色は、ヒューマン・アノテーターが文書にアノテーションを追加した後にタイプを瞬時に認識するのに役立ちます。

    • ヒューマン・アノテーターによってメンションに割り当てられないようにしたいエンティティー・タイプまたは関係タイプがある場合は、グランド・トゥルース・エディターでそれらを非表示にすることができます。そうすることで、ユーザーに対して表示されるタイプ・オプションのリストが小さく単純なものになります。 これを行うには、タイプの**「アクティブ (Active)」**チェック・ボックスを選択解除します。

    新しいショートカットとカラーを割り当てるときに、変更をプレビューできます。

  5. 選択を強調表示する色のデフォルトを変更することもできます。 強調表示する色は、ヒューマン・アノテーターが選択したテキストの周囲に表示される枠の色です。 デフォルトの色はライトブルーですが、**「選択の強調表示 (Selection Highlight)」**タブで色を変えて、選択されたテキストの境界線をもっと識別しやすいものにできます。

IAA しきい値の設定

アノテーションが付けられた文書セットを受け入れるか拒否するかを決めるのを支援するため、アノテーター間一致しきい値を指定できます。 このしきい値は、アノテーター間一致が、システムが計算した IAA スコアと比べてどの程度適切なのかを比較するのに役立ちます。

このタスクについて

複数のヒューマン・アノテーターが同じ文書にどのくらい異なるアノテーションを付けたのかを比較するため、評価しきい値を指定します。 あるヒューマン・アノテーターによるアノテーションと別のヒューマン・アノテーターによるアノテーションが、低スコアという結果になるほど異なっている場合、それらのアノテーターは一致していないということを意味します。 不一致は調査して解決される必要があります。

手順

アノテーター間一致しきい値を設定するには、次のようにします。

  1. Knowledge Studio 管理者としてログインし、ワークスペースを選択します。
  2. 「設定」>**「IAA 設定 (IAA Settings)」**タブを選択します。
  3. 0 から 1 までの値 (例えば、.5、.8 など) を指定し、**「保存 (Save)」**をクリックします。

アノテーション・ガイドラインへの接続

プロジェクト用のアノテーション・ガイドラインを作成した後、それらのガイドラインに接続するように Knowledge Studio を構成できます。 ヒューマン・アノテーターは、適用するアノテーションとして正しいものを選択するのに役立てるため、文書にアノテーションを付ける際にそれらのガイドラインを参照できます。 管理者も、重複文書中のアノテーション競合を解決する際に支援が必要な場合は、それらのガイドラインを参照できます。

手順

グランド・トゥルース・エディターおよび裁定ツールをアノテーション・ガイドラインに接続するには、次のようにします。

  1. Knowledge Studio 管理者としてログインし、ワークスペースを選択します。
  2. 「設定」>**「アノテーション・ガイドライン (Annotation Guidelines)」**タブを選択します。
  3. ガイドラインがホストされる URL を指定します。
  4. 保存 をクリックします。 グランド・トゥルース・エディターおよび裁定ツールがアノテーション・ガイドラインに接続されます。 ガイドライン作成時にユーザーに付与されたアクセス権によっては、ヒューマン・アノテーターおよびワークスペース管理者は、ガイドラインを開いた後に、説明と例を追加するなどの更新を行うことができる場合があります。

アノテーション・ガイドライン

ガイドライン文書化の書式は規定されていませんが、ガイドラインに詳細な例が含まれていることはとても重要です。 ヒューマン・アノテーターは、ある文脈でメンションにどのエンティティー・タイプを適用すればよいのかを理解する必要があり、また、特定のメンションのペアに対してどの関係タイプが有効なのかを知る必要があります。 正しいアノテーションの選択方法を最もよく伝えるのが分野コンテンツから取り出された例であることは珍しくありません。

アノテーション・ガイドラインは静的ではありません。 プロジェクトが進展するにつれて、ガイドラインに正確に取り込まれていないメンションおよび関係のインスタンスを発見するかもしれません。 複数のヒューマン・アノテーター間でのガイドラインの解釈方法に不整合を見つける可能性もあります。 状況に応じてガイドラインを更新することで、時間の経過とともにアノテーションの正確度と整合性が向上させることに役立つ可能性があります。

文書がグランド・トゥルースであると見なされるには、その前に、複数のヒューマン・アノテーターが同じ文書に付けた異なるアノテーション間の競合がすべて解決される必要があります。 競合を解決するために大事なのは、混乱の原因を議論して、その結果としてヒューマン・アノテーターが彼ら自身のミスから学ぶのを支援することです。 ガイドラインを改良して明確にすることは、競合の数を減らすのに役立ち、グランド・トゥルースにプロモートされるのが、正確で一貫したアノテーションが付けられた文書であることを確実にするのにも役立ちます。

ガイドラインを管理しやすくするため、長い文書になりそうであれば複数パーツに分割して、例えば、エンティティーのアノテーション付けに関するガイドライン、関係のアノテーション付けに関するガイドライン、メンションを照応させることのできる方法のアノテーション付けに関するガイドラインなどに分けることができます。 ある領域で変更を行う場合、それを評価して、別の領域で行う変更と調和させる必要があります。 例えば、エンティティー・タイプを追加する場合、関係タイプのアノテーション付けに関するガイドラインを検討し、新規エンティティー・タイプが他のエンティティー・タイプにどのように関係する可能性があるのかを指定します。

アノテーション・ガイドラインの例

ヒューマン・アノテーターがテキストのアノテーション付けを整合性を保って行えるようにするため、ほとんどのアノテーション・ガイドラインでは大量の詳細説明と例が必要です。

ここに示す例は、交通事故レポートを含む小さい分野のために作成された単純なガイドラインです。

作業の目標

  • プロジェクト・メンバーとして、人手によるアノテーションおよび機械学習モデルを改良するための反復プロセスを理解します。
  • グランド・トゥルース・エディターを使用して自動車分野の文書にアノテーションを付け、それらのアノテーションを使用して機会学習モデルをトレーニングします。 エンティティー・タイプ、関係タイプにアノテーションを付け、必要に応じてエンティティーを照応させます。

ガイドラインの表記

  • 角括弧[ ] は、引用符で囲まれたテキスト全体より少ない場合にアノテーションを付ける範囲を示します。

    例えば [no injuries]ACCIDENT_OUTCOME のように、適宜否定を組み込みます。 タイプ・システムは、否定を表すためのエンティティー・クラスを使用しません。

エンティティ・タイプ

このタイプ・システムは、エンティティー・サブタイプもロールも使用せず、メンション・タイプもクラスも使用しません。

エンティティ・タイプ ガイドライン 例
事故の結果 事故の結果。 人間 (死亡など) と車 (へこみなど) の両方に適用されます。 ダメージの重大度の指標として "towed" (けん引された) および "air bag deployment" (エアバッグが開いた) を、負傷の重大度の指標として "transported
to hospital" (死亡ではなく病院に搬送された) を含むことができます。 否定を含むことができます。 「[死者あり]」、「[負傷者あり]」、「持続的[全損]」, 「[負傷者なし]」、「[障害をもたらす損傷による][牽引あり]」,「[牽引なし]」、「エアバッグが[開かなかった]」（この事故による怪我の深刻さに関連するエアバッグ自体は車の一部でなければならない）、および事故深刻度の表示
CONDITION 事故の起こりやすさに影響を与える可能性があり、日ごとに変化する可能性があるが、車または運転者に関するものではないという観点での、気象条件または道路条件。

運転者のミスまたは機械の故障であることも可能であり、問題があるように見えなければなりません。 STRUCTURE は除外するべきです。		 天候や道路条件には、「乾燥」、「降雨」、「工事」、「交通混雑」、「日射」などがありますが、「草深い」や「酩酊」はこれには含まれません。

「パンク」、「過修正」（ステアリングなど）、「居眠り」、「 酔っ払い」、「[カーブ]STRUCTUREでの[ハンドル操作ミス]」、「車線[逸脱]」などはインシデント（事故）の原因となります。
INCIDENT 衝突、不適切であることが明確であって破壊的な自動車の動き (道から外れての走行など)、または、その他の損害事故 (自動車火災など) についての実際のメンション。

"impacted"、"pushed rearward"、および "came to final rest" など、密接に関連するものであっても、互いに同一の動きを指していない動きを照応関係にさせないでください。

エクステントから STRUCTURE を除外します。例えば、「[が]INCIDENT in a [ditch]STRUCTURE」または「[remaining in contact]INCIDENT with the [guardrail]STRUCTURE」などです。
メーカー 車両を製造する会社 Toyota、Mazda、General Motors
MODEL 特定のメーカーによって作られた特定の種類の車両。 "LX" や "SE" など、余分な語を除外し、ライン標識を切り取ります (例えば、"Xterra SE" という句の "Xterra" のみにアノテーションを付けます)。 カムリ
MODEL_YEAR 自動車の名前の一部であるモデル年。 '99、2001
車の一部 事故に具体的に関係しているかどうかに関係なく、車両の内部または外部のパーツ。 そのようなパーツの機能リストは除外します。 パーツが自動車内のどこにあるかを示すもの、または、特定のパーツではなく車の一部を単に指しているものを含めます。

複数形が可能です。 車両内の位置の指定を含めることができます。例えば、「[ドライバー・エアバッグ]」、「[RF ドア]」(右前面を意味する)、「[RR] 乗客」、「[LF および RF エア・バッグ]」、「[最初の行パッシブ/自動制約]」、「EDR 機能付き[安全システム] 」などです。

年/モデル/メーカーが別の、けん引されているボート、タンクなど (セミトレーラーを除く) を含めます。		 cross-section、front plane、tire、steering wheel、airbag など。
PERSON レポートの事故場面に記述されている人 (車両の運転者または乗客、歩行者、目撃者など)。

形容詞にアノテーションを付けないでください。したがって、「a [69-year-old] ■ 運転」にアノテーションを付けずに、「a 69-year-old [オス] 運転」にアノテーションを付けます。 複数形にすることができます。たとえば、LRおよびRF[Occupants（同乗者）]のように。 インシデント後に到着した人を除外します。

>「動物」エンティティー・タイプがない場合は、PERSON を使用して、衝突の原因となっている野生動物にタグを付けます。移動する機能により、STRUCTURE ではなく PERSON のようになります。

注:「旅客用エアバッグ」は PART_OF_CAR; であり、個人が存在することを意味するものではありません。
STRUCTURE 道路の上または近くにあるか、または道路の一部である構造体。 事故の構成に関連する可能性がある特定の道路形容詞を含めます。他の形容詞は省略します。 [2車線、両方向道路]、[左車線]、東行き[車線]、2フィートの[溝]、 [右車線]、[ランプの出口]、 [電柱]、 [樹木]、急勾配の[盛り土]
車両 MODEL、MANUFACTURER、および MODEL_YEAR 以外の車両への参照。 複数形が可能です。
その場合、照応の可能性は低くなり、グループの一部という関係はありません。 「[トラック]」、「[乗用車]」、「[V1]」

関係タイプ

このタイプ・システムは関係タイプを使用しますが、関係クラスや他の関係属性は使用していません。 否定は関係クラスによってエンコードされるのではなく、言及の範囲によってエンコードされます。たとえば、関係タイプによってリンクされた2つの言及を持つ[同乗者]は[入院]していません。

最初のメンションに可能なエンティティー・タイプ 関係タイプ 2番目のメンションに可能なエンティティ・タイプ
車両、モデル、メーカー2 hasProperty MANUFACTURER、MODEL、MODEL_YEAR
PERSON occupantOf 車、モデル、メーカー、モデル年1、車の一部、構造
人物、車の一部、構造、車、モデル、メーカー、モデル年1 sufferedFrom 事故の結果
車両 driveUnder CONDITION、ACCIDENT_CAUSE
車の一部 locatedOn 車両、モデル、メーカー、モデル年1
事故の結果 outcomeOf INCIDENT
INCIDENT causedBy 条件、事故の原因、（注意：因果関係のテキストによる証拠が必要）
INCIDENT impactPoint 事故に見舞われた、または事故に巻き込まれた人、車の一部、構造体、車両、メーカー、モデル、またはモデル年1。構造体の衝

撃点は、その構造体に関係しない衝撃の場所の単なる指定を含みません。従って、[点交差]構造体で衝突した2台の車には適用されませんが、[盛り土]構造体に衝突した車両には適用されます。

表の注記

  1. VEHICLE/MODEL/MANUFACTURER/MODEL_YEAR という表記は、車両のメンションを指します。 最後の 3 つは、それぞれ、"the Accord"、"the Honda"、または、まれにしかありませんが "the '99" のようなことがテキストに書かれている場合のためのものです。 これら 4 つのエンティティー・タイプは、優先順位の順番になっています。したがって、"the driver of the '99 Honda Accord" では、driver (PERSON) occupantOf Accord (MODEL) という関係になります。この場合、Accord は Honda と '99 の両方と hasProperty 関係を持ちます。
  2. MODEL と MANUFACTURER が hasProperty の第 1 引数になることができるのは、名詞として出現する (車両を指す) 場合のみです。 "the '99 Honda Accord drove" でのように、MODEL は、MANUFACTURER および MODEL_YEAR への hasProperty 関係を持つことができます。 "the '99 Honda drove" でのように、MANUFACTURER は、MODEL_YEAR への hasProperty 関係のみを持つことができます。