Tin Can API: Statements 101 日本語訳

この記事は、CC BY 3.0のもと、記事を翻訳したものです。意訳のため正確さを求める場合、原文を読んでください。
(原文) http://tincanapi.com/statements-101/


 Tin Canの技術導入にあたり、私たちは、いくつか基本的なステートメントのコンセプトを示しました。ここでは、ステートメントの構造を深く掘り下げて、事例を見ながら、その有用性を見てみましょう。

補足:TinCanステートメントを書くとき、「Tin Canレジストリ」は、貴重なリソースになります。これは解決可能なURIを含む、TinCanステートメントの構成サンプルです。レジストリ内で捜しているものが見つからない場合は、私たちに知らせてください。共にレジストリが更新されるように取り組みます。

 最も単純なTin Canステートメントの構造は、「actor(主体)、verb(動作)、object(対象)」の形式で表すことができます。このようなステートメントで1つの例を挙げるならば、 「Sally experienced ‘Solo Hang Gliding’(サリーは、ソロハンググライダーを経験した)」という表現ができます。技術的に、JSON形式で表現するなら、このようになります。

{
    "actor": {
        "name": "Sally Glider",
        "mbox": "mailto:sally@example.com"
     },
     "verb": {
         "id": "http://adlnet.gov/expapi/verbs/experienced",
         "display": {"en-US": "experienced"}
         },
     "object": {
   "id": "http://example.com/activities/solo-hang-gliding",
   "definition": {
      "name": { "en-US": "Solo Hang Gliding" }
        }
    }
}


TinCanステートメントの構成要素

Actor
Verb
Object
Verbs vs. Activities
Context
Result
Extensions
その他のステートメントフィールド
その他の情報

Actor(主体)

 私たちは、Project Tin Can に関わる調査を行ったところ、産業界のリーダー達との対話の中で、何度も耳にした言葉は、次のようなものでした。「学習は、ますます人を中心(個人に依存)したものになり、またそうなるべきです。私たちは、企業ではなく、個人が長期的に経験や成果を積むことに、関心が高いことが分かりました。」

 Tin Can では、利用者が特定のシステムやIDで縛られる必要はありません。それが人を中心に据える、Tin Can の重要なステップなのです。あなたと繋がりを持つすべてのシステムでアクティビティが、統合されている状態を想像してみてください。ツイッターであなたが、ハンドルネームを使いツイートすると、あなたのアクティビティ全体を見ることで、どのような経験を経てきたかが分かり、同一の「あなた」が、ソロハンググライダーの飛行をしたとか、ハンググライダーの訓練マニュアルを読んだとか。プライバシーの問題から、各ステートメントで含まれる「あなた」という記述は一度だけですが、レポートシステムによって複数の人物は、同一人物とみなされ集約されるでしょう。

こうした説明を念頭において、Actorオブジェクトの例を見てみましょう。

{
    "actor": {
        "name": "Sally Glider",
        "mbox": "mailto:sally@example.com"
     },
     "verb": {
         "id": "http://adlnet.gov/expapi/verbs/experienced",
         "display": {"en-US": "experienced"}
         },
     "object": {
"id": "http://example.com/activities/solo-hang-gliding",
        "definition": {
            "name": { "en-US": "Solo Hang Gliding" }
        }
    }
}


 この Actorオブジェクトは、2つのプロパティ”name”と “mbox”を持ちます。唯一 “mbox“のみ、このsally(サリー)を特定できる固有な記述をしています。そこには、サリーという名前を持つ人が、ほかにも多くいるかもしれませんが、その中の一人が、メールアドレス sally@example.com を所有しています。
サリーを表現する、別の方法を考えてみましょう。

{
   "name": "Sally Glider",
   "account":{ 
       "accountServiceHomePage": "http://twitter.com",
       "accountName": "sallyglider434"
    }
}


 この場合は、ハンドル名 “sallyglider434” を持つ、ツイッターアカウントでサリーを特定しています。人を識別するための、このような柔軟性は、Tin Canの重要な特徴で、このあたりについては「Deep Dive: Actor/Agent」の記事で、深く読むことができます。私たちは、(人ではない)表示システム、そしてActor(アクタ)としてのグループについても触れています。現状、このような詳細については、Tin Can APIの仕様書に記載されています。

Verb(動作)

 Tin Canでは verb(動作) は URI あり、簡潔な表示文字列と組み合わせます。これらはステートメントの重要な要素であり、ステートメントのactor(主体)とobject(対象)との間で、何が起きているのかを説明します。Tin Can の仕様(この記事の執筆時点は1.0.0)では、任意の完全URIをverb として使用することができます。私たちは、verbのURIを解決する場所とともに、verb(動作)を追加して格納する場所としてTin Can API レジストリを作りました。そこでは、ADLにより公開されたverb(動作)の初期セットがあり、Tin Canレジストリの中で、あなたはそれらの動作を見つけることができます。独自に創り出す前に、少なくとも、これらのverb(動作)を検討することは、もちろん良い考えです。

 そのリストには、次のものが含まれます。experienced(経験した)、attended(出席した)、attempted(試みた)、completed(完了した)、passed(合格した)、failed(失敗した)、answered(回答した)、interacted(相互作用した)、imported(インポートした)、created(作成した)、shared(共有した)、voided(無効になった)。verbの詳細については、私たちのdeep-dive記事のVerbsを確認してみてください。

Object(オブジェクト)

 コアステートメント構造の最後として、”object(オブジェクト)” フィールド について考えてみましょう。一般的に object(オブジェクト)はTin Can のアクティビティになりますが、ほかの Actor (主体)になるケースや、何もしなかったり、そのほかのステートメントになることがあります。ここでは、object(オブジェクト)としてのアクティビティについてフォーカスを当ててみます。

 Tin Canでは、大抵 actor(主体)は、現存する人に関係を持ち、verb(動作)は、はっきりした存在意義を持つ傾向のなかで、アクティビティはステートメントをレポートするシステムによって定義され提供される可能性があります。すべてのアクティビティは、URIにより一意に定義される必要があり、必要に応じて説明的な情報を含めることができます。次の例文から、オブジェクトを別の視点で見てみましょう。

{
"id": "http://example.com/activities/solo-hang-gliding",
    "definition": {
       "name": { "en-US": "Solo Hang Gliding" }
}


 これはIDフィールドにより、一意に識別されるアクティビティです。Tin Can の重要な原則に、2つのアクティビティは、同じIDから参照されることはありません。定義により、1つのIDは、識別する理論に合ったアクティビティに1対1で対応します。識別子が不適切な場合(例:hang gliding(ハンググライダー乗り)、swimming(水泳)、question #4(質問4番))、このアクティビティの論理上の定義のせいで戸惑うことがあるかもしれません。このような理由から、アクティビティーIDの作成者は、自分が管理するドメインを用いて、アクティビティーIDを作成するか、あるいはアクティビティIDにドメインにあるパス (Path)を付与して管理できるように注意する必要があります。そして、そのドメイン内で、一意性を持たせるためのスキームをきちんと定める必要があります。
 ここでは、example.com を使用していることに注意してください。誰かに実在する意味を伝えることが目的ではありませんので、例文作成をしている場合を除き行わないでください。

 アクティビティオブジェクトの定義は、時間をかけて改良することができます(ただし、他のいくつか新しいアクティビティだったものを記述するなど、大幅な変更はしないほうがいい)アクティビティ定義における description フィールドは、Tin Canの国際化をネイティブにサポートします。例として、オブジェクトにいくつか詳細情報を追加してみましょう。

{
  "id": "http://example.com/activities/solo-hang-gliding",
  "definition": {
    "type":"course",
    "name": { 
        "en-US": "Solo Hang Gliding",
        "es":"Solo Ala Delta"
     },
     "description": {
         "en-US":"The 'Solo Hang Gliding' course provided by The Hang Glider's Club",
         "es":"El curso de 'Solo Ala Delta' siempre por el Club de Planeadores Hang"
     },
     "extensions": {
         "http://example.com/gliderClubId":"course-435"
     }
}


 ここに、このアクティビティが一人用ハンググライダーのコースであることを示す、type フィールドを追加しました。また、description フィールドも追加しました。ここには、その名前から予想される通り、コースについて簡単な説明を記載します。name と description には、スペイン語バージョンを追加しました(Google 翻訳を使用)。このようにして、レポートツールやその他の表示レイヤーで、ユーザの設定に基づいて出力言語を自動的に切り替えることができるようになります。

 また、extension フィールドも追加し、ここには、特定用途(または規約)向けに合わせてカスタマイズした任意のキー(URI)/値のペアを設定します。extension については、後で詳述します。アクティビティ定義の詳細については、Tin Can API の仕様を参照してください。

Verbs vs. Activities(動作 vs アクティビティ(活動))

 時として、verb (動作)とobject (対象)の境界は、曖昧になりがちです。Sallyに関する例文中の、「Solo Hang Gliding(ソロハンググライダーの飛行)」には、1つとして適切に定義されたアクティビティ(活動)であることが読み取れます。おそらく、example.com からのハングライディングスクールの講習やテストのことでしょう。しかし、「Sally hang-glided over Mount Magazine(サリーはマウント・マガジンをハンググライダーで飛行した)」と言いたいときはどうだろう?「hang gliding over Mount Magazine(マウント・マガジンの上をハンググライダーで飛行)」としたら、Sallyが「経験する」の特定のアクティビティ(活動)になるだろうか?それとも、Sallyは、このステートメントのobject(対象)として「マウント・マガジン」の上を「ハンググライダーで飛行した」ことになるだろうか?

  通常、このあいまいさを取り除くには、どのようにデータをレポートしたいかという意図と、この部分が他のステートメントとどのような関係にあるかにかかっています。マウント・マガジンに関する多くのアクティビティー(活動)を扱うシステムでは、マウント・マガジンをひとつのオブジェクトとに分けることでデータが向上するかもしれない。「ハングライダーで飛ぶ」という動作をもっと細かく分類して定義できれば、Sallyがハングライダーで飛ぶという体験をもっと分かり易く独立したものとして、他の多くのオブジェクトとは区別して扱うことができるようになるかもしれない。

 別のケースでは、「hang gliding over Mount Magazine(マウントマガジンの上でハンググライダーで飛ぶ)」という叙述は、ある組織や仕様によって定義されていれば、きちんとした活動として意味を持つ場合も考えられます。そして、その意味は、利用する器具や飛行経路などの点から、非常に具体的なものを意味するかもしれません。その場合、重要なことは、「“Sally experienced ‘Hang Gliding over Mount Magazine’”(サリーは『マウント・マガジンの上でハンググライダーで飛ぶ』を経験した)」ということです(たとえばハンググライダー・クラブの最初のハンググライダー・テストとして具体的に定義されていることです)。

Context(関連情報)

「context (関連情報)」は、ステートメントにいくつか関連情報を追加する場所を提供します。インストラクターの経験がチーム活動の一部として得られた場合、その情報を追加したり、ある経験がその他の幅広い活動にどのように属するかなどの情報を追加できます。

これらの要素のいくつかを、次のステートメント例で確認してみましょう。

{
   "actor": {
       "name": "Sally Glider",
       "mbox": "mailto:sally@example.com"
    },
     "verb": {
         "id": "http://adlnet.gov/expapi/verbs/experienced",
         "display": {"en-US": "experienced"}
    },
    "object": {
        "type":"course",
        "id": "http://example.com/activities/solo-hang-gliding",
        "definition": {
            "name": { "en-US": "Solo Hang Gliding" }
        }
    },
    "context": {
        "instructor": {
            "name": "Irene Instructor",
            "mbox": "mailto:irene@example.com"
         },
         "contextActivities":{
             "parent": { "id": "http://example.com/activities/hang-gliding-class-a" },
             "grouping": { "id": "http://example.com/activities/hang-gliding-school" }
         }
    }
}


 この例では、「コンテキスト」オブジェクトをステートメントに追加してあります。
ここで記載されていることは、「Sallyは『ソロハングライダー』コースを受講していて、そのインストラクターはIrene(アイリーン)で、そして、そのコースはハングライダー・クラスAの一部であり、ハングライダー・スクールに組み込まれていること」です。さて、もうこれで十分と言いたい所ですが、他にもいくつか役に立つ情報を追加しておきました。こうしたcontext(関連情報)のピースは、ステートメントをグループ化してレポートするとき、特に役に立ちます。

 Tin CanのネイティブクエリーAPIを利用すれば、アイリーンの指導を受けた人のステートメントを抽出して、見直しができるだけなく、ハングライダー・クラスAの参加者のあらゆるステートメントや、ハングライダー・スクール内部のすべてのステートメントを見ることもできます。より洗練されたレポートツールならば、これらの要素は、もっと簡単にデータを論理的にグループ化することができるでしょう。

 ここでは説明していませんが、コンテクスト・オブジェクトには「拡張」フィールドを設けることもできます。そしてそこに任意のデータを付加して、そのステートメントのためのコンテクストとすることも可能です。その場合、このデータは特定の目的のためのレポート・ツールの中で利用することができます。その際には、そのステートメントを検索するわけです。以降では、拡張についてさらにお話しましょう。コンテクスト要素を扱うすべてのセットは、Tin Can APIの仕様書の中で説明されています。

Result(結果)

 ステートメントはまた、ある測定の結果として終わることがあるかもしれません。例えば、もし「ソロハンググライディングの飛行」がコースや1つの評価であれば、「サリーは95%の合格点で”ソロハンググライダーの飛行”を完了した」または、「サリーは6点中2点の不合格で”ソロハンググライダーの飛行”を完了した」さらに「サリーは4時間で”ソロハンググライダーの飛行”を完了した」ということを表現できるでしょう。例文のステートメントに1つのresult(結果)を加えてみましょう。

{
   "actor": {
       "name": "Sally Glider",
       "mbox": "mailto:sally@example.com"
    },
     "verb": {
         "id": "http://adlnet.gov/expapi/verbs/completed",
         "display": {"en-US": "completed"}
    },
    "object": {
        "id": "http://example.com/activities/solo-hang-gliding",
        "definition": {
            "name": { "en-US": "Solo Hang Gliding" }
        }
    },
    "result": {
        "completion": true,
        "success": true,
        "score": {
            "scaled": 0.95
        }
    }
}


 ここでは「サリーはソロハンググライディングの飛行を95%の合格点で完了した」ということを記しました。「completion(完了)」フィールドは、サリーの行いであることを示し、「成功」フィールドは、彼女が合格したことを示しています。そして「スコア」フィールドには、95% 取得したことを意味します。「スコア」の場合、実際のところ値には、スコアオブジェクトであったり、代わりに最小値、最大値といったもの、値そのもので表されるかもれません。これは得点が6点中2点であること、最低点0、最高点6、数字そのもので2という風にレポートできることを意味します。

 また結果の持続時間を記録することができます。それにより、結果に至るまでの活動に対して、実際にかかった時間を知ることができます。そして、actor(主体)とobject(対象)間で相互作用を記録するステートメントの場合は、result (結果)は、actor(主体)の応答を持つことができます。 相互作用するアクティビティと、その応答に関する詳細は、Tin canの仕様書に目を通せば分かります。ここで再びTin Canは、「extensions(拡張)」フィールドを追加することができます。このときのresult(結果)オブジェクトは、アプリケーション側で、独自のresult(結果)を定義させる感じでしょうか。

Extensions(拡張)

 Tin Canステートのツアーを通じて、いくつか「拡張」フィールドが出てきたことに気が付いたでしょう。「拡張」は、アクティビティの一部、ステートメントコンテキストの一部として、またはステートメントの結果の一部として利用することができます。いずれの場合も、ある特定用途のために、自然な形でそれらの要素を拡張するための、手段の提供を目的としています。これらの拡張コンテンツは、特定のアプリケーションによっては重要になることや、コミュニティ全体で利用されることがあります。

 「extensions(拡張)」フィールドは、任意のデータを持たせることができることから、ステートメントの表現に際限がない高い柔軟性を持っています。しかし、古い諺にあるように「大いなる力には 大いなる責任が伴う」。責任を持って拡張を使うことは、いくつかの意味があります。

 1つ目に、多くのアプリケーション固有データを拡張に入れることができたとしても、必ずそうしなければならないことではありません。ステートメントは、その拡張により全ての定義がなされるべきではなく、そうなると意味がなくなってしまいます。Tin Canのステートメントは、actor(主体)とobject(対象)間の経験を記録することで、Tin Can準拠のツール間の相互運用性を活用するためにも、できるだけ多くの情報を対応づけるよう常に努力すべきなのです。

 2つ目に、拡張は、存在するステートメントの一部に、論理的に関連していなければなりません。ステートメントのコンテキスト内の拡張は、中心となる経験にコンテキストを与える必要があり、何らかの結果に関連した要素を提供しなければなりません。活動に関しては、いくつかのカスタムアプリケーションや、コミュニティーの中の活動を定義するのに役立つ追加情報を提供すべきです。

 最後に、拡張キー/値の組み合わせキーは、ちょうどverb(動作)またはアクティビティIDのようなURIでなければなりません。verb(動作)やアクティビティIDのように、それは一意であるものとして定義され、自分が拡張「キー」を使う場合、他の誰かがそのキーを用いるときと同じ意味を持つと、自分で主張していることになります。

これらのことを念頭に置いて、ステートメントの例にいくつか拡張を与えてみよう。

{
   "actor": {
       "name": "Sally",
       "mbox": "mailto:sally@example.com"
    },
     "verb": {
         "id": "http://adlnet.gov/expapi/verbs/completed",
         "display": {"en-US": "completed"}
    },
    "object": {
        "id": "http://example.com/activities/solo-hang-gliding",
        "definition": {
            "type": "assessment",
            "name": { "en-US": "Solo Hang Gliding" },
            "extensions": {
                "http://example.com/gliderClubId": "test-435"
            }
        }
    },
    "result": {
        "completion": true,
        "success": true,
        "extensions": {
            "http://example.com/flight/averagePitch": 0.05
        }
    },
    "context": {
        "extensions": {
            "http://example.com/weatherConditions": "rainy"
        }
    }
}


 この場合、ハングライダー・クラグでの「ソロハングライダーの飛行」の評価を「gliderClubId」フィールドを用いて定義するため情報を追加しました。私たちは「weatherConditions」フィールドの形式の、この経験についてのコンテキストが重要な断片であることに注目しました。そして、最後に「averagePitch」フィールドを使用したステートメントの結果に、特別な測定基準を含めました。これらの情報の追加部分がなくとも、中心となるステートメントは、「サリーはソロハンググライディングの飛行に合格した。」という意味を持ち続けます。追加情報は、特別な環境において、より多くの意味を持たせることを可能にします。


その他のステートメントフィールド

 Tin Canステートメントの中で、主要な要素を見てきました。ここでは、そのほか細かい所ですが、しかし重要なステートメントについて簡単に確認してみましょう。

 「timestamp」と「stored」フィールドはステートメントの重要な要素です。「timestamp」は、経験が発生したとき記録を行い、「stored」は、 このステートメントが格納されている Tin Can LRS に経験が追加されたときを記録を行います。したがって、「stored」フィールドは常に LRS によって設定され、「timestamp」フィールドは、ステートメントの発行元システムによって設定されます。

 このフィールドの値は「actor」で、「Sally」や「Irene」のような人を表したり、「The Glider Field Application(グライダーフィールドアプリケーション)」などの物を表す場合もあります。ステートメントの作成者を知ることは、ステートメントの妥当性を見る上で非常に重要な情報であり、また、追跡記録の 1 つの形式としても役に立ちます。許可、認証、および権限に関する説明は、今後発表される『Tin Can Security 101』の記事で紹介される予定です。より詳しい情報は、Tin Can の仕様書に詳細が記載されています。

 最後に、ステートメントの「voided」フィールドは、このステートメントがもう有効な情報でなくなったかどうかを示します。Tin Canの分散型の性質をサポートするために、ステートメントは論理的に不変であると考えられます。しかし、すべてのステートメントが一度作成された後、有効であり続けるという要求は、難しいことです。このため、間違ったステートメントの無効化をサポートするために、Tin Can には新しいステートメントを使用して以前のステートメントのいくつかを無効にするためのメカニズムが用意されています。ステートメントの無効化の詳細は、Tin Can の仕様書に記載されています。

 これでTin Canステートメントのツアーは、終了です。ステートメントを自分で簡単に作成したい場合は、Statement Generator もチェックしてみてください。それでは、次のステートメント例の情報パックバージョンを紹介してこの説明を終わりにします。以前は、訳が分からなく見えたこのステートメントも、内容が分かるようになったのではないでしょうか。

{
   "actor": {
       "name": "Sally Glider",
       "mbox": "mailto:sally@example.com"
    },
     "verb": {
         "id": "http://adlnet.gov/expapi/verbs/completed",
         "display": {"en-US": "completed"}
    },
    "object": {
        "id": "http://example.com/activities/hang-gliding-test",
        "definition": {
            "type": "assessment",
            "name": { "en-US": "Hang Gliding Test" },
	"description": { "en-US": "The Solo Hang Gliding test, consisting of a timed flight from the peak of Mount Magazine" },
            "extensions": {
                "http://example.com/gliderClubId": "test-435"
            }
        }
    },
    "result": {
        "completion": true,
        "success": true,
        "score": {
            "scaled": 0.95
        },
        "extensions": {
            "http://example.com/flight/averagePitch": 0.05
        }
    },
    "context": {
        "instructor": {
            "name": "Irene Instructor",
            "mbox": "mailto:irene@example.com"
         },
         "contextActivities":{
             "parent": { "id": "http://example.com/activities/hang-gliding-class-a" }
             "grouping": { "id": "http://example.com/activities/hang-gliding-school" }
         }
        "extensions": {
            "http://example.com/weatherConditions": "rainy"
        }
    },
    "timestamp": "2012-07-05T18:30:32.360Z",
    "stored": "2012-07-05T18:30:33.540Z",
    "authority": {
        "name": "Irene Instructor",
        "mbox": "mailto:irene@example.com"
    }
}


その他の情報

 今後の記事では、Tin Canの認証処理について詳しく見ていき、Tin Can APIのほかの部分のツアーをやってみましょう。これまでと同様に、あなたがTin Canを深く掘り下げるなかで、私たちにあなたの考えや質問を送ってください。私たちは、可能な限りさまざまな回答の提供を惜しみません、Tin Canを採用したアプリケーション調査の進捗状況について聞いてみたいと思っています。最新のTin Can APIの知らせが欲しい方は、私たちからeメールの最新版を購読してください。