Category Archives: TinCanAPI 翻訳資料

Tin Can API TinCanAPI 翻訳資料

もっと深く : Verbs

ステートメントへのインクルージョン

 動詞は、ステートメントの一部として必要で、動詞を含めることはとても簡単なことです。ある経験により発生する行動を示すステートメントの動詞オブジェクトを verb プロパティとして設定するだけです。 動詞オブジェクトは、URI(IRI) を示す一つの id プロパティで構成されます。例えばこのような形式です。

{
    id: "http://adlnet.gov/expapi/verbs/experienced"
}


 これだけでも十分ですが、人は多少なり自身の母国語に近いものを好むようです。そのため、id プロパティと同じように、display プロパティを含めてください。display プロパティの値は言語マップ(対応する文字列の値を持つ言語コードの一覧)であり、 Tin Can API を国際化させるために必要な相互運用性の中心となります。これは同じ意味を持つ動詞ですが、人間が読み取れる display 値となります。

{
    id: "http://adlnet.gov/expapi/verbs/experienced",
    display: {
        "en-US": "experienced"
    }
}


 言語値の追加は、RFC5646 の言語タグを使用して容易に言語マップに追加することができます。上記の “en-US” は、アメリカ英語の例です。

経緯

 仕様策定の初期段階において、あらかじめ定義された動詞セットがありました。0.95バージョンの仕様策定において、動詞は自由に作成できることが適切と考え、id の完全な URI を持つリストは、オブジェクト フォームに移動されて仕様の範囲外になりました。これらの動詞が他の目的でも、もう使用されることが無いにもかかわらず、ADLは特にラーニング コミュニティ向けにデザインされた動詞リストを、まだ維持しています。 しかし、「attempted」 (履修した)、「experienced」 (体験した)、「passed」 (合格した)、「failed」(失敗した)、「answered」 (答えた)、そして「completed」 (完了した) などの動詞は、(もちろん URI の形で)従来の仕様とうまく適合するため、Tin Can で利用される動詞の中でも、共通的に使用される動詞になっています。Tin Can を利用するコミュニティは、その実践コミュニティの中で、認知されて利用するような、独自の動詞をコミュニティ依存の動詞セットとして作り出すと予想していました。そして例外として、ステートメントが無効になる特別な役割を果たす、事前に定義された動詞が仕様内に1つ含まれています。ステートメントを無効にするには、http://adlnet.gov/expapi/verbs/voided の id を持つ特別な動詞を含む新規のステートメントを、ステートメントのリファレンス(詳細は今後の投稿で説明)とともに、そのステートメントを受信すると思われる LRS に送信します。

過去時制

 動詞は過去時制でなければなりません。Tin Can は本来、時系列に基づいて経験をトラッキングするように設計されています。ステートメントは経験のための記録(それは過去時制であり)したがって、動詞は過去の時制になります。直ちに記録された経験であろうとなかろうとも、体験そのものは既に過去のものでなければなりません。(これがステートメントがもはや「進行中」といったものを示さない理由の一つです。) 時間経過の概念は、一連の行動の繋がりの中で、潜在的には同じ体験内に存在します。それは積み上げられたステートメントから、意味を引き出すために必要とする相当量の複雑性がありますが、同時にコンテンツ作成者の想像力を高める柔軟性をもたらします。

実行可能性

 URI として動詞ID が持つ意味は、多くの動詞はロケーション(URL)を解決できること、そのときに、それらにメタ情報を追加できることです。メタ情報は、少なくとも JSON として要求されたとき、仕様に従い、「name」(名称)と「description」(説明)プロパティを持つオブジェクトを含む必要があります。これらのプロパティは特に、動詞そのものについての説明(「display」プロパティの目的といったもの)ではなく、動詞についての情報を与えるために使われます。これはよいスタートで、動詞と Tin Can が進化するにつれて、動詞(と URI を使用するほかのアイテム)に関する情報を拡張できる手段を持つでしょう。私の中で、インターネットの純正主義者の信念に従うなら、動詞はURI であり、そして URL になる URI を選べるならば、すべての動詞は解決すべきです。ですが仕様では、動詞は解決する必要はなくオープンです。(そのとおり、私は常に純正主義者というわけではありません)

動詞を作るか、作らないか

 本質的にそれは大した問題ではありません。最終手段として、どうしてもという以外は新しい動詞を作ることは避けてください。そうですね、Tin Can 導入がまだ時期尚早の段階で最終手段というのは、ちょっと言い過ぎかもしれませんが。動詞セットというものは、徐々に固定化されていくでしょう。Actor, Verb, Object のステートメントで利用する3つの構成要素を考えてみてください。このなかの動詞だけが、一貫して人々の経験を横断して一致させることができて、同じ actor の経験のさまざまな行動を示します。そのような2つの側面は、行動をレポーティングするときの基本であり、これから全ての新しい経験が、全く新しい動詞セットでレポーティングされてしまっては、その役割を果たすことができません。実践コミュニティが必要なのはこのためです。適応を通して動詞は牽引力を持ちます。動詞の自然な関連付けが増え、牽引力を持つようになるとシステム作成者は、Tin Can のような仕様が提供しようとしている相互運用性の基礎となるセマンティックな意味づけが頼りになります。ステートメントの作成者は、既に動詞がないかよく探して、あるならば活用すべきです。

レジストリ

 私たちは、動詞(そして、ほかのURIベースのコンポーネント)リストのことを registry(レジストリ) と呼び、その動詞リストを一つ作成しました。具体的には The Registry というもので、ここで元となる「動詞」を見つけることができます。現状、The Registry は ADL の動詞リストから構成されていますが、相互運用性を低下させる動詞の激増を防ぐために、ユーザーがきちんと整備されたプロセスを通して新たな動詞を作成できるように、(ブログ記事を書いていないときに)機能性の向上について取り組んでいます。もちろん私たちは、人々が新しい動詞を作成して、その動詞を利用することを防ぐことはできません。そして新しい動詞は時間の経過とともに必要になるでしょう。私たちは、これらの動詞が永続的(ステートメント作成に必要であるため)に使われること、そして問題解決に役立つ事を望んでいます。そのため、URI ベースの id で利用するドメインの名前空間 id.tincanapi.com を立ち上げました。The Registry の中で作成された動詞(及び他のアイテム)は、仕様で定義される、動詞に関連するメタデータを提供する解決可能なURLを持ちます。

意味というのは単語でない

 動詞は手強いです。そして英語は(他の言語も、きっとそうだと思いますが)、それらの動詞を更に手強くする至上の言語です。これまでは、相互運用性を可能にするために、可能な場合は動詞を再利用すると言いましたが、しかしまた、独自の動詞セットを採用する実践コミュニティがあるだろうとも言いました。これらの2つのベストプラクティスは、相反する葛藤を含んでいます、それは一つの動詞がステートメントに応じて、異なる意味を持つ可能性があるということです。類義語と呼んでもいいでしょう。これがどれだけインパクトのあるものなのか、もう一つ言えば、動詞オブジェクトは、特定の単語ではなく、1つの意味に直接マップする識別子を持ちます。それゆえに特定のIDによる動詞オブジェクトの意味を見出すとき異なるケースでは、動詞の意味に一致する単語と意味が合わないことがあるということです。

 Fired という単語は、よく引き合いに出されます、それは恐らく、ひとつに指定される単語だからでしょう。Fired は、状況によっては全く違う意味になり得ます。その文面が表す状況により、意味合いが全く変わることから、その動詞ID の意味を作り出す単語が鍵を握っています。問題はどのようにその単語を識別するかです。例えば、fired a gun (銃を発射する) と fired a cannon (大砲を発射する) は異なった動詞でしょうか?両者ともに発射物が急速に弾き出て行く様を意味するものです。したがって同じ動詞である、と主張する人もいるでしょう。つまり、白黒がはっきりしないグレーゾーンが残り、その部分をはっきりさせるにはステートメントを処理するシステム、そして究極的には私たちのような不確かな人間が、難解な意味を持つ文脈の関係性を考慮しながら、判断を下し、言葉の意味付けをしていかなければなりません。動詞や類義語を新たに、そして正しく作成するには、時間そしてどの意味を採用していくか、この二つが本当に唯一必要なことなのです。

※ この記事は、CC BY 3.0のもと、tincanapi.com の Deep Dive: Verbs を翻訳したものです。意訳のため正確さを求める場合、原文を読んでください。
(原文) http://tincanapi.com/2013/06/20/deep-dive-verb/

TinCanAPI 翻訳資料

もっと深く : Actor / Agent

誰も経験者がいない場合、LRSにステートメントは記録されますか?


抽象的な概念に伴う問題

 Tin Can API は経験情報を記録するためにデザインされていますが、1つの前提条件として、個人あるいはグループが経験者として存在しなければなりません。アクタを書くことは、Tin Can のステートメント上、それは 「I (私)」 として扱われ、つまり文法的には主語になります。

 Tin Can ステートメントを作るとき、抽象的な概念がたくさん出てきます。そして、一見してステートメント 「I (私)」 の定義は単純にみえるため、手始めにそこから始めることは現実的です、しかし残念ですが実際は、そう単純ではありません。「私はいったい誰なのか?」という問いかけは、世代を超えて問われ続けるような大きなもので、Tin Can であっても小さくならない問いかけです。そのような問題と折り合いをつけるには、あなたが 「I (私)」(もしくは 「royal we(私たち)」)を定義するだけでなく、相手の誰かに自分が誰であったのかを伝えられなければなりません。そして、さらに問題を複雑にすることに、あなたは「 I 」を アクタとせず、あなたの仲間 「me」(あるいは何人かの仲間 「us」)をアクタとして定義するケースがあることです。 「 myself 」 もいいでしょう。さて、代名詞については十分話しましたので、アクタに話しを戻します。

 ステートメントの アクタの部分を理解するには、客観的に JSON オブジェクトの値(代入の右辺)に対する、キーやプロパティ(代入の左辺)が何になるのか、理解することです。最終的にステートメントは、値が代入されたプロパティの集まりから構成されます。アクタはそのようなプロパティの一つで、アクタは「 Agent 」(あるいは「 Group 」)でなければなりません。

これはアクタは、あとから値が決定されるプレースホルダー(あるいはポインタ(参照))のため、それ自体に特別な意味を持たないためです。

 言い換えれば、私たちはアクタを意味を持った名詞、あるいは、何らかのオブジェクトタイプであると考えてはいけません。アクタは特定の値を指しているポインタ(参照)として考えます。また、ステートメントのプロパティとプロパティが保持する値の形式は、(小文字の)「 actor 」と大文字の「 Agent 」を使い区別している点に気が付いてください。ただ私の妻は、セマンティックスを振り回しているだけと私に指摘するのですが、もし彼女が開発者なら、セマンティックスは、私(私達)の作業にとって非常に重要なことで「正しいことだ」と、言い返したいところです。(ただ、彼女は開発者ではないので、すべて言い返すようなことはしません、頭が上がらない立場なので。)

エージェントとグループの定義

 エージェントとは、オブジェクトタイプの一つで確実に言えることは、逆関数識別子で表現しなければならないため一貫性があり、同一のエンティティ(実体)までトレースバックできる一意の ID を指します。逆関数識別子は、エージェントを表すいくつかの形式をとることができ、メールアドレス(またmbox)が最も分かりやすい形式です。人であれば読み取れるメールアドレスに加えて、1つのエージェントは、メールアドレスに含まれる SHA1 ハッシュによって指定することもできます(ハッシュは IRI でなければならないので、「 mailto 」の部分も含まれます。)

{
        mbox: "mailto:info@tincanapi.com",
        objectType: "Agent"
}


{
        mbox_sha1sum: "f427d80dc332a166bf5f160ec15f009ce7e68c4c",
        objectType: "Agent"
}


 電子メールアドレス以外にも、エージェントは OpenID の URI を利用して一意に指定することができます。電子メールが、まだかなり広く受け入れられている状況でも、 OpenID は、いくつかの領域でうまく行っています。仕様書では、エージェントは対象システムが持つ固有識別子で特定できるコンビネーションを使い、多くのシステムが持つ特有のバリエーションを使用することができます。Twitter.com で言えば、「Twitter handle(ツイッター ハンドル)」が、そのシステムでの固有表現になり、そのコンビネーションは、単に「 Account(アカウント)」として知られているものです。いくつかのシステムが、現れては消えていくなかで、やがて電子メールアドレスの終焉を目にするかもかもしれません、システムの固有IDに加えそのシステムのエンテイティ(概念としてのアカウント)の固有ID の概念は、その仕様が存在する限り十分に柔軟性を持たせる必要があります。


{
    account: {
        homePage: "http://twitter.com",
        name: "projecttincan"
    },
    objectType: "Agent"
}


 注意すべき重要な点は、エージェントは、利用可能な複数の逆関数識別子を持つことができたとしても、エージェントオブジェクトが、逆関数識別子にリンクして関連を持つことで、プライバシーの理由などから LRS が要求を拒否してしまうことを避けるためにも、一つだけを含むべきです。また、私たち人間がもっと簡単に利用しやすくするために、エージェントに「 name(名前)」を関連付けることが出来ます。


{
    mbox: "mailto:info@tincanapi.com",
    objectType: "Agent",
    name: "Info at TinCanAPI.com"
}


 上記の例では、明示的に ObjectType プロパティを Agent にしました。そのプロパティは、Agent か Group かの、いずれかである必要があり、また初期値が Agent の場合は、いつでも省略することができます。( actor プロパティの オブジェクトタイプみたいなものです。)

 グループは、エンティティ(実体)を表現するオブジェクトタイプという点で、エージェントによく似ていますが、構成の全て、または一部、特に member プロパティを、列挙できる追加プロパティを持ちます。グループは、objectType プロパティに、グループ値を与えなければなりません。そして グループには、2つの種類があり、指名と未指名(匿名)があります。前者の場合、指名グループは、エージェントのように、逆関数識別子(または、固有識別子)を持っていて、member プロパティを含んでも含まなくても構いません。また指名グループが、リストを持つ member プロパティを含んでいても、それが完全なリストであると判断すべきではありません。これは、あるステートメントが、経験したメンバーエージェントの特定のサブセット(一部の人)のみ呼び出すことがあるためです。(おそらく、著名なメンバーエージェントや、最大寄与数を持つメンバーエージェント、最も整理されているメンバーエージェント、または、最初に到着したメンバーエージェント。)後者の例では、未指名、つまり匿名グループは固有に指名された情報との関連付けがありません。そのために逆関数識別子を持ちませんが、member プロパティを含まなければなりません。バージョン1.0.0 の時点での仕様では、この場合のメンバーリストは完全なリストである必要はなく、オープンなままをベスト·プラクティスとしています。これは、ほかのメンバーエージェントとステートメントのその部分を関連させる方法がないからです。未指名グループを、同一のグループとして同じ一組のメンバーエージェントと関連付けることは自然と成りうる傾向ですが、仕様上、実装するシステムは、このような想定を行うべきではないことに注意してください。更に言えば、どちらの種類のグループメンバーリストもエージェントのみ含むものでなければなりません。そのため、グループを入れ子にすることはできません。

{
    mbox: "mailto:info@tincanapi.com",
    name: "Info at TinCanAPI.com",
    objectType: "Group",
    member: [
        {
            mbox_sha1sum: "48010dcee68e9f9f4af7ff57569550e8b506a88d"
        },
        {
            mbox_sha1sum: "ca3ffdb44c4727137e29ebf42ee80c2afdd8d328"
        },
        .
        .
        .
    ]
}


{
    objectType: "Group",
    member: [
        {
            mbox_sha1sum: "90f96ca8c3ae315f0e40df4e16772eb6d05e3937"
        },
        {
            mbox_sha1sum: "ca3ffdb44c4727137e29ebf42ee80c2afdd8d328"
        }
    ]
}


ステートメントに話を戻して

 さて、ここまで、私たちは Agent/Group オブジェクトについて学び、actorプロパティのオブジェクトと理解したところで、次を見てみましょう。※ただ、ステートメント内には他にも、同じようにエージェントを使用することがあります。例えば、前述した“me 私”の例では、“ Sam (エージェント1) helped me (エージェント 2) ”(サムは私を助けた)といった同じようなステートメントを作るために、object プロパティの中に自身の Agent または Group (“us”) を置くことができます。その場合は、そのステートメントは、2つのエージェントを使用します、actorプロパティは、今までどおり1つ含み(この場合 Sam )、object でもう一つ使います(この場合 Brian(または me ))。エージェントやグループはステートメントの” instructor “としてステートメントの ” context ” の中に含めることができます、そうすることで、Brian (アクタ) learned Tin Can from Ben ( instructor ).”(「ブライアン(アクタ)はベン(instructor)から Tin Can について学んだ」)というステートメントを作ることができます。また、context は team プロパティをも含めることができますが、その場合は Group である必要があります。

 最後に、エージェントはステートメントの authority プロパティを設定するために利用されますが一般的にステートメント作成でその記述がない場合、それは LRS によって作成されます。(” authority “(認証)に関しては今後詳述します)

ステートメント以外のこと

 エージェントはステートメント構造において、最も重要な役割を果たす部分であり、クエリ可能である必要があります。エージェントオブジェクトは、 actor や object プロパティに一致するステートメントを取得するために、エージェントのクエリパラメータを通じてステートメント API に渡されます。他の可能性がある場所として1つでもエージェントが存在するステートメントを見つけるために「 related_agents 」のクエリフラグをオンにしてリクエストを送ってください。エージェントは、Agent Profile として呼ばれる、独自のAPIメソッドを持つすばらしいものです。Agent Profile は将来に向けて自分自身のポストを保証するものですが、今は LRS において特別なエージェントと任意のデータを関連付けることができることを知っておけば十分でしょう。1つのユースケースでは、ユーザプリファレンスを格納しています。Agent Profile と共に、エージェントはまた、API ステートコールに組み込まれています。

潜在的な問題

 多くの場合、たくさんのグループに所属するだけでなく、最近では、人はいくつもの逆関数識別子を持っています。私は個人的に、Eメールアカウント3つ持っていますが用途に応じて使い分けてをしています。ひとつは個人用で、もうひとつは仕事用、そして最後のひとつが、いろいろな用途に使うものです。それらは技術的にドメインエイリアスを持っていて、約10個のドメインネームがあります。これらはそれぞれ、別個の逆関数識別子と考えることができ、そうすると、私は単にEメールだけでも約30 もの識別される手段を持っていて、そして、さらに少なくとも10もの公開しているプロフィール( Twitter、Github、 Facebook、 LinkedIn、 Google+ など)を持っています。それら、全てが「アカウント」という概念を持ち、Tin Can APIとのやり取りで利用できます。そして、それらは公共のものです。ここで重要な点は、Tin Can API で動作するシステムは、実際のところ「人」の特定識別子をいくつでも有することができる点を考慮する必要があります。

 それに加えて、すべての逆関数識別子の場合において、私たちは Eメールアドレスあるいはアカウントが共有されているかどうかまで知ることはできません。そのため、エージェントが人とゆるく結びついている可能性がある一方で、一つのアカウントがひとりの人間を表現していると想定すべきではないのです。このことから私たちは、アカウントはひとりの人であると決めてかかるべきではないでしょう。さらに時間の問題やメールアドレスやアカウントは、所有者が変更される可能性があるという現実があります。例えば “ info@tincanapi.com ” というメールアドレスはあらゆる人に送信することができますが、“ brian@example.com ” というメールアドレスは Brian Miller から Brian Smith に所有者が変わるかもしれません。結局、それが timestamp プロパティが存在する理由のひとつになります。しかしそれについては後の記事で触れようと思います。
さあ、ステートメントを作ろう!。

※ この記事は、CC BY 3.0のもと、tincanapi.com の Deep Dive: Actor/Agent を翻訳したものです。意訳のため正確さを求める場合、原文を読んでください。
(原文) http://tincanapi.com/2013/06/05/deep-dive-actor-agent/

TinCanAPI 翻訳資料

第4レイヤー : トレーニングに相関するジョプ・パフォーマンス

 Tin Can APIは、アクティビティストリームと呼ばれる仕様をベースにしています。これは、GoogleやFacebook、Microsoft、IBMなどの企業により形成された、ソーシャル・ネットワーク上のアクティビティの記録に用いられるフォーマットです。

 アクティビティストリームは人の行動をすべて記録することができます。Tin Can APIは、学習体験を収集しやすいように、アクティビティストリームの仕様を拡張したものです。 Tin Canステートメントの中心的なオブジェクト Actor、Verb、Object(“I Did This”(私はこれをやりました))というものは、中核をなすアクティビティストリームの仕様から由来しています。

 Facebookのウォールを見ると、そこにはアクティビティストリームの一連のステートメント(だれそれが何をした)があります。例を挙げてみると。

  • 「マイクは写真を投稿した」
  • 「ティムはマイクの写真にコメントをつけた」
  • 「ベスがマイクの写真について「いいね」を付けた」

 アクティビティストリームは、ソーシャルネットワーク、企業の双方で、人々のアクティビティを収集する方法として注目を集めています。言い換えるなら、実際 仕事のパフォーマンスデータとトレーニングデータは同一に収束していきます。私たちは、学習体験のデータ収集に、企業がそのほかの体験を収集する手段と同じやり方を用いています。これは大きな強みです。

 アクティビティストリームの例を挙げてみると。

  • 看護師ジュディーは、eラーニングモジュールの「CPR(心肺蘇生法)の原則」を修了しました。
  • 看護師ジュディーは、ダミーを使い、心肺蘇生のシミュレーションを修了しました。
  • 看護師ジュディーは、12回中9回の心肺蘇生に成功しました。

 これらのストリームを企業間で、もしくは産業界全体で収集を開始することで、どのようなトレーニングパスが最も良い結果を生み出すかを見極めることができます。言い換えるなら、もっとも問題のあるトレーニングパスを見極めることができるのです。現在、トレーニングプログラムの有効性を決定し ROIの効果測定を行うことができるのです。

そのほか考慮すべき含み

  • Yammerのような内部ソーシャルネットワークからのアクティビティストリームとTin Canのアクティビティストリームを組合わせると、どうなるでしょう?学習体験と同僚との会話を基にして、私たちは組織内で専門家を見つけることができます。
  • 組織でもっとも成功したパフォーマのアクティビティストリームを見て、若手社員が見習うべきモデルとして、それらを活用することができるでしょうか?逆に、失敗した人が辿ってきた道を危険信号として見ることができるでしょうか。

 これらのビジョンが完全に達成されるには長い道のりが必要でしょう。Tin Canはその実現に必要な基礎をレイアウトして、制約を取り除こうとしています。

 しかし、もちろんそれだけではありません。まだ他に何ができるのか誰も気付いていないだけです!Tin Can APIは大きな新しい可能性を切り拓きつつあります。eラーニングを画期的に変えてくれることは間違いありません。5年後にどうなっているかは誰にも予想できませんが、楽しい旅になるのは間違いありません。一緒に歩んで行きましょう。

※ この記事は、CC BY 3.0のもと、tincanapi.com のLayer 4: Correlate Job Performance with Trainingを翻訳したものです。意訳のため正確さを求める場合、原文を読んでください。
(原文) http://tincanapi.com/layer-4-correlate-job-performance-with-training/

TinCanAPI 翻訳資料

第3レイヤー : データを開放する

 今までに、SCORMのデータが、どこかのブラックホールに入り消えてしまったと、思うことはなかったでしょうか?。SCORMは、とにかくLMSにデータを送ることが仕事でした。LMSが、それをどのようにデータを利用しようと、表示しようと、レポートしようと、規定はありません。Tin Canも、そのようなシステム上の規定はありませんが、決定的に違うことがあります。それは Tin Can は、LRSのデータにアクセスできることを要求している点です。

 そのため Tin Can API は、LRSへのデータ書き込み・読み取りの双方が可能です。書き込みしたものは、読み取ることができるのです。LRSは、レポーティング・ツールや分析ツール、また他のLRSとの間でデータのやり取りができます。この機能は、自身で構築するシステムをどうするか、共有データをどうするかといったシステム構成に、重要な意味を持ってきます。

 LMSのレポーティング・ツールに満足している人は、まずいないでしょう。一般的なレポートでも、十分な場合もありますが、別の方法でデータを細分化したり分けたくなるときもあります。業界が異なれば、ニーズも異なり、用いる用語、順守すべき要件も変わってきます。Tin Can APIなら、どのようなLRSからもデータを引き出せるため、高度なレポーティング・ツールを開発することが可能です。これらのツールは、特定のビジネスインテリジェンスツール向けであったり、さまざまな種類の学習体験、異なる業界向けなど、カスタマイズすることが可能なのです。データはアクセス可能なので、好きな方法で分析することができます。

 コンテンツの作成者は、教育効果を評価し、欠点に対処して、そして改善策を講じる手段を常に模索してきました。改善すべき部分を見つける唯一の方法は、学習者がコンテンツ自体にどのような関わり方をしているか理解することです。実際、何が起こっているのかを理解しなければ、作成者には、不備のある箇所が見えてきません。Tin Canは、コンテンツの分析ツールにより、LRSから実際の利用データを抽出し、情報に基づいた判断を行い、インストラクショナル効果をより上げるために、作成者に必要な情報を提供することができます。

 システム間の通信に加え、Tin Can APIは、一つ以上のLRSに対して、ステートメントをレポートすることが可能です。LMSと学習体験との間には緊密な相互依存関係がないため、学習体験の情報伝達は、制約なく複数のLRSにステートメントを自由に送ることが可能です。

 マルチLRSのレポート機能で、もっとも興味深い使い方は、「パーソナルデータロッカー(学習者個人が所有するクラウド上のストレージ)」の活用です。学習者が一つのトレーニングを受ける時、なぜ学習体験は、雇用者のLRSだけに記録されてしまうのでしょうか?。その学習体験は、他の事柄や今後の仕事に関連することはないでしょうか?なぜ、その学習体験は、学習者に帰属されないのでしょう?Tin Canを使えば、学習者は学習体験を雇用者にレポートするだけでなく、同時にこのイベントを「パーソナルデータロッカー」に記録することができます。

 論理的に次の思考を考えると、なぜ学習体験は、一番に学習者の「パーソナルデータロッカー」に記録されないのでしょう?まずは、学習者に自身のデータを所有させて、そして次に、そのデータを共有する相手を決めてみては。

 学習体験の記録は、履歴書よりもその人の経験を多く語ることになりませんか?

 学習体験を公開することで、助言、質問、仕事さえも求められたり、特定の分野で専門家であることを知ってもらうのに役に立ちませんか?

 あなたの組織は、その仕事についてだけでなく、一個人として学んだこと全てを知ることで、利益になりませんか?

 このビジョンを達成するには、さまざまな課題を乗り越えなくてはなりません(技術的にも制度的にも)。しかし、Tin Canは、こうした課題全てを克服して、それ以上を達成するための基盤となるでしょう。


 少し驚きましたか?潜在的に持つ変化の可能性に?Tin Canは、今後 産業を再形成するでしょう。しかし、もちろん、それだけではありません…


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

TinCanAPI 翻訳資料

第2レイヤー : すべての学習体験の記録 (インフォーマル・ラーニング)

 あなたの学習体験の何パーセントが、フォーマル・ラーニングで行われたものでしょうか?そして、そのうちの何パーセントがeラーニングだったでしょうか? おそらく、多くはないでしょう。

 何か知識を付けたいと思うとき、あなたならどうしますか?。それに合ったコンピュータベースのトレーニングを求めてLMSを利用しますか? きっと、そんなことはしないでしょう。

 Google、Youtube、Twitterを利用したり、または同僚に聞くこともあるでしょう。もしかしたら、講座受講の申し込みをするかもしれません。私たちはトラッキング可能な学習体験というと、なぜフォーマルなeラーニングコースを想像して狭めてしまうのでしょう?

 Tin Canならそれらすべてを変えることができます。学習はどこでも出来ますし、多くのシステムが理解できる方法でトラッキングすることができます。あなたが今、このページを読んでいることも、とても意味のある学習体験です。Tin Canを用いれば、その体験を記録することができます。

 カーンアカデミーのビデオを視聴することも学習体験になります。Tin Canを利用すれば、その体験をトラッキングすることができます。ある会議のセッションに参加することも学習体験であり、Tin Canを利用すれば、それもトラッキングできます。

ソーシャルネットワークにアドバイスを求めること ・・・ Tin Can APIのアクティビティになります。
専門家から助言を受けること ・・・
宿題を提出すること ・・・
誰かのメンターになること ・・・
ブログに記事を投稿すること ・・・
授業に出ること ・・・
本を読むこと ・・・

 私たちは、毎日さまざまなことをしますが、それは学習体験となります。Tin Canでは、それらをトラッキングすることができます。

 Tin Canがあれば私たちは、個人の学習体験の全体像を作り出すことができます。これは現実の世界では、どのように見えるでしょう? LMSを使わずに、人々の活動を効果的にトラッキングするには、どうしたらしたらいいでしょうか。私たちは、まだこの問いに対するすべての答えは持っていません。Tin Canは、まだ未成熟ですが、面白いアイデアや、初期段階としての利用法を持っています。

 Tappestryを見てみてください、このモバイルアプリは「学習したことを登録する」というもので、Tin Can LRSに記録されます。


 Tin Can bookmarketというものがあります。それは、「I Learned This」(これを学びました)ボタンをブラウザのツールバーに搭載し、ウェブサイトをブラウジングしている間に見つけた関連学習項目を記録することができます。

 book scanner app(Android)をダウンロードしてみてください。これは、ちょうど読み終わった本のバーコードをスキャンして、学習体験として記録します。

 学習体験のデータを受動的に取り込む方法は、まだまだたくさんあります。

想像してみてください

  • 出席のTin Canステートメントで作るコンファレンスセッションの登録システム
  • Google Calendarの「学習イベント記録」ボタンは、イベントに招待される人全員にステートメントする
  • 知識習得を発言したり、関連スレッドでアクティビティに基づいた共有を体験する企業イントラネットのディスカッションボード

 これらはまだ始まりにすぎません。私たちは電子機器が生活に溶け込んだ世界で生きています。これらのシステムを使えば、私たちの学習体験すべてを補足することができます(それを望むならば、ですが。ただし多くのセキュリティーとプライバシーにかかわる問題があり、学習体験をトラッキングすることの価値と秤に掛ける必要があります。ですがこれは、また別の記事で。)

 Tin Can APIが持つ機能には、いくつか重要な革新性があり、以下のインフォーマルな学習体験をトラッキングできます。

  • LRSは、事前にアクティビティを認識させておく必要がありません。SCORMでは、コンテンツを配信してトラッキング可能にするには、あらかじめLMSにコンテンツをインポートして登録しなければなりません。これでは、LMS管理者が事前に登録したeラーニングコンテンツしかトラッキングできません。つまり、それは私たちの学習体験のごく一部でしかないのです。Tin Canなら、最新のカーンアカデミービデオがリリースしたら同時にトラッキング可能な学習イベントになります。
  • トラッキングされる学習体験の配信元は、LMSである必要はありません。SCORMでは、学習体験をトラッキングする唯一の方法は、LMSにログインして、事前に選択するeラーニングコースが登録してある状態で、LMSから、そのコースを起動します。Tin Canでは、学習体験を始めるのに時間や場所は問いません、すべてトラッキング可能です。洞察力の深い TED Talkの視聴を終えたら、“I Learned This”(これを学びました)のbookmarkletをクリックすると、あなたの学習体験はすぐに記録されます。
  • 学習体験のコンテンツとデータレポートは、今では分かれます。SCORMでは「学習体験の結果レポート」は、常にその体験そのものからレポートされなければならず、SCOは、教育的なコンテンツと学習体験のデータレポートという両方の機能を兼ね備えていました。コンテンツはスマートである必要がありますが、意識的にSCORMの機能を有効にするために加工しなければなりませんでした。Tin Canは、学習体験そのものがデータレポートを行う制約を取り除きます。

 どうですか、いいでしょう?
 インフォーマルラーニングをトラッキングすることは大きなパズルのピースを埋めていくようなものです。個人の学習体験の詳細な記録は、成功を大いに予兆するもので、レディネス(準備ができている状態)を評価するカギとなる要素となりえます。

この第2レイヤー自体は、私たちの産業の非常に大きな前進の一歩を象徴するでしょう。しかしもちろん、さらにあります・・・

※ この記事は、CC BY 3.0のもと、tincanapi.com のLayer 2: Record Any Learning Experience (Informal Learning)を翻訳したものです。意訳のため正確さを求める場合、原文を読んでください。
(原文) http://tincanapi.com/layer-2-record-any-learning-experience-informal-learning/

TinCanAPI 翻訳資料

第1レイヤー : SCORMの現代版

 SCORMは既に10年以上に渡りeラーニング業界に貢献してきました。当時としては先見性のある技術でしたが、テクノロジーの世界では10年は、永遠のような時間です。SCORMは、アップデートされるべき時をとうに過ぎています。

簡単に言うとTin Can APIは、eラーニングの最新テクノロジーを相互運用可能な形で利用できる、次世代SCORMです。

技術オタク(ギーク達)へのセクション

 ギーク達にとっては、Tin Can API とは、RESTfulウェブサービスです。このサービスは、JSON形式でデータを扱い「Learning Activity Provider」は、一連の「ステートメント」を作成して「Learning Record Store (LRS)」にデータを送ります。各ステートメントは、学習体験を説明するもので、「Actor」、「Verb」、「Object」から構成されます。例えば、ステートメントは、「マイクは、RESTの概要を合格した」といったデータを送ります。Tin Can APIがどのように動くのか、もっと深く掘り下げたいギーク達は、Tin Can API 開発者セクションから始めると良いでしょう。


 そのほかの方にとって、Tin Can API は、今までSCORMが邪魔して上手くできず、さまざまなやりたかったことを、学習プログラムに組み込むことを可能にしてくれます。

Tin Can API は、トラッキングに適しています。

  • モバイルラーニング
  • シリアスゲーム
  • シミュレーション
  • インフォーマルラーニング
  • 現実世界の行動

Tin Can API は、どこでも使えます。

  • インターネットに、接続してない、または常時接続ではない環境
  • どのデバイスにも (例: スマートフォン、潜水艦のソーナーシステム)
  • どこのサーバーからでも(独自にコンテンツをホストすることができ、クロスドメインの問題は気にする必要なし)
  • ウェブブラウザー以外からも (例: ネイティブiPhoneアプリ、F-16フライトシュミレーター)

Tin Can API は、SCORMでは簡単にはできなかったこと、不可能だったことができます。

  • LMS 以外からコンテンツを起動できます。
  • コンテンツ配信とユーザー体験の完全な制御を維持できます。
  • 学習者は、異なるコンテンツを自由に操作することができます。
  • ユーザーが不正行為をできないようにセキュリティが付け加えられます。

Tin Can API を使えば充実した教育体験を届けることができます。

  • インタラクティブ、アダプティブラーニングの体験
  • マルチモーダルな学習経験(例:テキストメッセージを一新して、CBTを強化できます)
  • ブレンディッドラーニング
  • 長期間に渡る学習体験

Tin Can は、SCORMを用いた場合に上手くできなかったデータレポートを可能にします。

  • チームベースのトレーニング
  • 1つのコースに複数の得点を付けること(事前テストと事後テスト)
  • 複数に渡るの学習開始(いつ初回学習を始めるかは、あなたがコントロールできます)
  • 詳細なテスト結果
  • 他にもたくさん(SCORMから改善した部分を記載しています)

 良いでしょう?これは本当のことです。また、前向きな開発ベンダーは、Tin Can API を利用しています。第1レイヤーだけでも産業界にとっては、特筆すべき飛躍です。Tin Can APIが、斬新的な可能性を引き出しますが、もちろん、それだけではないでしょう。


※ この記事は、CC BY 3.0のもと、tincanapi.com のLayer 1: A Modernized version of SCORMを翻訳したものです。意訳のため正確さを求める場合、原文を読んでください。
(原文) http://tincanapi.com/layer-1-freeing-us-from-the-constructs-of-old/

TinCanAPI 翻訳資料

Tin Can オニオンの層

 Tin Can は、多くの人に興味を抱かせる面白さがあり、簡潔に答えることは難しいものです。レイヤー(層)で分けて、Tin Canを説明することが分かりやすいでしょう。

 表面上、Tin Can は、多くの機能を持つことで、あなたを新しい世界へと導き、理解を深めさせることから、とても興味深いものです。だけど始めてみると、表面下に隠された、もっとたくさんの面白みに気付くはずです。

このセクションでは、レイヤーごとに「Tin Can APIとは何か?」の問いについて答えていこう。

tamanegi

ここでは、興味を掻き立てるために簡単に、それぞれのレイヤーについて紹介します。

  • 第1レイヤー:Tin Can API は、SCORMの現代版であり、時代遅れの旧式から、私たちを解放してくれます。
  • 第2レイヤー:Tin Can API によって、ちょっとした学習も含め、あらゆる学習体験の記録を可能になります。それによって私たちの学習計画のイメージがより描きやすくなります。
  • 第3レイヤー:Tin Can API は、あなたのデータを、孤立化した(サイロ化した)LMSの制約から解放します。
  • 第4レイヤー:Tin Can API は、仕事のパフォーマンスと学習反復データを関連付けて学習の成果を測定することによって、さまざまな教育研修部門が探し求めていた最高目標の達成を可能にします。


※ この記事は、CC BY 3.0のもと、tincanapi.com のLayers of the Tin Can Onionを翻訳したものです。意訳のため正確さを求める場合、原文を読んでください。
(原文) http://tincanapi.com/the-layers-of-tin-can/

TinCanAPI 翻訳資料

Tin Can API とは何ですか?

※ この記事は、CC BY 3.0のもと、tincanapi.com の概要ページの一部を翻訳したものです。意訳のため正確さを求める場合、原文を読んでください。
(原文) http://tincanapi.com/overview/

 Tin Can APIは、(たまに Experience API や xAPIとも言われます)、eラーニング技術の最新規格で、個人が持つ幅広い経験(オンライン・オフライン双方の)データを収集することを可能にします。このAPIは、多くの技術を用いて、個人やグループのアクティビティデータを一貫した形式を用いて収集します。Tin Can のシンプルな語彙を用いて、この一連のアクティビティを保存し共有することで、全く異なったシステムと安全に通信することが可能になります。

 以前の仕様は、難解で制限がありましたが(Tin Can vs SCORMを参照)、Tin Can APIは単純化されており、柔軟性があります。それは、過去にあった多くの制限を取り除いたものです。Tin Can APIの活用例として、モバイルラーニング、シミュレーション、仮想世界、シリアスゲーム、現実世界のアクティビティ、体験学習、社会学習、オフライン学習、そして協調学習などがあり、上手くやり取りすることができます。

 重要なことは、Tin Can APIが私達(Rustici Software社)の所有物ではないことです。ADLは仕様作成の幹事役であり、ADLが私達に開発を依頼してきたので、この部分をよく知っているだけです。Tin Can APIは、コミュニティを前提としたもので、実用はフリーです。

Tin Can APIはどのように動くのか

  • 人は、他者とのやり取りや、コンテンツなど様々なところから学びます。こうした行動は、どこでも起こり得るもので、その後の学習行動のきざしとなります。こうしたこと全ての行動を Tin Can API で記録することができます。
  • アクティビティを記録する必要がある場合、アプリケーションが「主体」「動作」「対象」の形式、あるいは「I did this(私はこれを行った)」という形式の、定まったメッセージが、Learning Record Store(LRS)に送られます。
  • Learning Record Storeは、アプリケーションで作られたメッセージ全てを記録します。LRSは、こうしたメッセージを他のLRSと共有することができます。LRSは独立して存在するもの、LMSに組み込まれているものがあります。

Tin Can APIの自由度

  • ステートメントの自由度 : 主体、動作、対象を用いた「ステートメント」の構造は、利用者のほぼ全てのアクティビティを記録できます。参考:「I did this.(私はこれをした)」
  • (学習 / 行動)履歴の自由度 : Tin Can APIは、LRS同士の通信を許可しています。LRS同士は、データや記録をお互いに共有することができます。そうすることで、あなたの経験は一つのLRS(または組織)から他のLRSに伝播されていきます。学習者は、その中の個人の学習情報を、自身の「personal data lockers(クラウド上の様々な情報を格納する場所)」に持つことができます。
  • デバイスの自由度 : 全ての利用可能なデバイスに、Tin Can APIステートメントを送ることができます。(携帯電話、シミュレーション、ゲーム、CPR(心肺蘇生法)のダミー、その他いろいろ)ネットワークは常に接続していなくてもよく、随時接続できれば問題ありません。
  • 学習ワークフローの自由度 : 学習時のイベントトラッキングは、1つのLMS内で起動・終了する必要がありません。学習者が始めたいと思った場所であればどこでも、どのデバイスを使っても開始できます。利用者のコンテンツは、1つのLMSに縛られることはありません。
TinCanAPI 翻訳資料

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メールの最新版を購読してください。

TinCanAPI 翻訳資料

Tin Can API 0.9 (REST + JSON binding) クライアント クイックスタート

tincanapi.com で公開されている、Quickstart Guide 「Tin Can API 0.9 (REST + JSON binding) Client Quick Start」 を翻訳いたしました。ご参考程度にどうぞ。