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