Tag Archives: TinCan

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/

Tin Can API

セキュリティ/認証を必要とします

従来のeラーニングの仕様は、堅牢なセキュリティに欠いていることはよく知られています。LETSI RTWSは、セキュリティのためのソリューションを提供しており、これは、良いスタートです。

Tin Can APIは、RTWSのアプローチに基づいてます。認証の仕組みは、RTWSが認証する方法に似ていますが、より柔軟です。Tin Can APIにおいて、認証は、コンテンツではなくユーザーに結び付けられます。ユーザーは、ステートメントを送り出す、すべての人や物に当てはめることができます。ユーザーは、学習者、講師、あるいはソフトウェア·エージェントになります。そして、OAuthで認証を行うことができます。

Tin Can APIを用いると、コンテンツは、セキュアが確保され、eラーニングは、効果的なトレーニングのために使用することができます。


※ この記事は、CC BY 3.0のもと、Rustici Software 社の記事を翻訳したものです。
http://scorm.com/project-tin-can-phase-3-we-need-securityauthentication/

Tin Can API

自分自身のシーケンシングを自分でやりたい

人々はシーケンシングを思い通りに動かしたいという問題を抱えています、というのは、コンテンツとLMSの間で相互運用性の問題があることを意味しています。コンテンツ制作者によって作られたシーケンシングがLMSにより間違って解釈される多くの余地が常にあります。

問題は、たとえ複数のSCOの使用から得たたくさんのレポートを無視してでも、多くのコンテンツ制作者が流れるようなユーザエクスペリエンスを持つために、複数のSCOをひとつのSCOにまとめることが十分に広がっていることです。

どのように解決すればよいでしょうか?。私たちは、複雑なシーケンシングの必要性を取り除きます。

Tin Can APIは、シーケンシングをコンテンツ/アクティビティに残しています。LRSがシーケンシングを間違って解釈する余地はありません、なぜなら、LRSは決してそれに触れないからなのです。コンテンツ/アクティビティは、適正なタイミングで、LRSにステートメントをレポートするだけです。


※ この記事は、CC BY 3.0のもと、Rustici Software 社の記事を翻訳したものです。
http://scorm.com/project-tin-can-phase-3-i-want-to-do-my-own-sequencing/

NoraUsagiメモ:
「複数のSCOをひとつのSCOにまとめることが十分に広がっている」とは、Flashのような、1SCOのコンテンツを指していると思います。複数SCOにすれば多くのトラッキング情報が得られますが、操作性を優先して、1SCOにすることで得られる情報はわずかしか残りません。LMSがSCO単位で、「学習完了」などのフラグを管理していることが原因で、TinCanは、SCO単位という概念をなくし、コンテンツ側に託してしまうという意味だと思います。そのなかでは、複数の「学習完了」のフラグを設けても別に良いわけです。そして、LMSのシーケンシングの誤動作も防げるので、一石二鳥という感じでしょうか。

Tin Can API

協調学習とチームベースの学習

協調学習

Tin Can APIによる協調学習とは、複数の学習者が同じアクティビティを経験していることを意味します。学習者は、同じ場所にいる必要はありません。そして、同時にアクティビティを体験する必要もありません(そうすることもできますが)。学習者は、協調学習で何ができるのでしょうか?

  • 互いに質問をする。
  • 互いにコメントを残したり、コンテンツ/アクティビティの制作者にコメントを残す。
  • ほかの学習者の回答にコメントする。
  • 投票や評価そして採決のような新しい機能を実装できます。
  • 個人がどのくらいグループに貢献したか評価できます。

これらすべてのインタラクションは、LRSに送信されるステートメントとしてトラッキングすることができます。このような協調学習は、以前のeラーニングの仕様だけでは不可能なことでした。

チームベースの学習

チームベースの学習は、それぞれの個人と同じように、二人以上の人によって得られた体験のトラッキング結果を考慮に入れます。「チーム3は、特別な操作トレーニングを完了しました。」などの、ステートメントを使用することができます。チーム内でチームの成績や、個人についてのトラッキングおよびレポートが重要であるとき、これは役に立ちます。


※ この記事は、CC BY 3.0のもと、Rustici Software 社の記事を翻訳したものです。
http://scorm.com/project-tin-can-phase-3-collaboration-and-team-based-learning/

NoraUsagiメモ:
「協調学習」 (ylab 山内研究室 Blog)
http://blog.iii.u-tokyo.ac.jp/ylab/2009/11/post_195.html

Tin Can API

指導者・その他は、トレーニング中、観察・対話をする必要があります

eラーニングは、とても孤独な体験です。そして、コースやテストを受けて評価されます。Tin Can APIは、そのようなやり方から離れ、アクティビティの開発者が、学習者と講師との間でインタラクションの新しい方法をクリエイトできるようにして、新しい可能性を広げることができます。

どのようなユースケースがあるでしょうか?

  • 講師は、記述中の論文の評価ができて、コメントや提案を付けることができます。
  • 指導者は、シミュレーションを観察して、その場でシナリオの調整をすることができます。
  • 学習者の行動を、詳しく観察することができ、コンテンツの最適化が可能になります。
  • インストラクターは、評価するまでもなく、ほぼリアルタイムにフィードバックの回答をすることができます。
  • 講師は、学習者がつまづくかもしれない迷いを、解くために、コース/テストの中にコメントを残すことができます。
  • アクティビティ中、指導者と学習者は、チャット/ビデオで会話をします。

アクティビティ/コンテンツが、上記の機能を提供するためには、LRSで、Tin Can APIを使用してトラッキングする必要があります。


※ この記事は、CC BY 3.0のもと、Rustici Software 社の記事を翻訳したものです。
http://scorm.com/project-tin-can-phase-3-instructorsothers-need-to-observeinteract-during-training/

NoraUsagiメモ:
このような、チャットやビデオシステムは昔からあり、それ自体に目新しさは感じませんが、独自システムの中で完結しているものがほとんどです。そのようなやりとりを、LRSでトラッキングできること、さまざまな形態のコンテンツのレポートを一元して扱えるところが、すごいところなのです。

Tin Can API

SCORMのユーザーインターフェイスの要件は、相互運用性を達成していない

eラーニングの仕様の中心となるものは、相互運用性ですが、既存の仕様にはいくつかの問題が残っています。Tin Can API は、現在の仕様で残る多くの相互運用性の問題解決を図ります。

目次を表示する

従来のeラーニングの仕様では、目次を表示すべきかは、必ずしも明確ではありませんでした。そのLMSは、目次を表示するのか?、またコンテンツだけなのか?複数のSCOが、目次に表示されているとき、問題はもっと難しくなります。

どうすればいいか? Tin Can APIでは、目次を表示したいなら、コンテンツ/アクティビティに、目次を表示します。コンテンツ/アクティビティは単独で動作します。そして、必要なときLRSにステートメントをレポートします。

コンテンツを起動する

混乱しやすいもう一つの分野は、実際のコンテンツの起動です。ウインドウサイズはいくつで開くべきでしょうか?フルスクリーンで起動しますか?

テーマ設定

これは、現在存在する共通する問題の間接的な対処です。LMSの中のコンテンツは、独自のスタイルが作られて、LMS自体も独自のスタイルで作られています。時には、これらのスタイルは衝突して、学習の邪魔をすることが起こりえます。

LRSからコンテンツ/アクティビティを切り離すことで、テーマ設定/スタイル設定は、提供者の好きなようにコンテンツ/アクティビティを設定できます。コンテンツは、さまざまなLMSの中で、どのように見えるか考える必要はなくなります。


※ この記事は、CC BY 3.0のもと、Rustici Software 社の記事を翻訳したものです。
http://scorm.com/project-tin-can-phase-3-scorm-user-interface-requirements-dont-achieve-interoperability/

NoraUsagiメモ:
SCORMでは、このあたりのことは規定されていないため、LMS側にパラメータを設定することがあります。印象としては、中途半端にLMSがコンテンツにあれこれ介在している感じでしょうか。

Tin Can API

相互運用性の向上

eラーニングの仕様の中心となるものは、相互運用性です。よくできていると思いますが、私たちは、いくつか改善の余地を見つけました。Tin Can APIは、現在の仕様に残る、多くの相互運用性の問題解決を図ります。しかし、私たちは、落とし穴を見つけるには、あなたの支援が必要です。

ユーザーインターフェイスの問題

LMSは、すべて独自のユーザーインタフェースを持っています。可能な限り多くLMSと互換性を持たせたコンテンツを作成する場合、LMSが持つユーザインターフェイスの、すべてのバリエーションを考慮することは、必ずしも可能ではありません。Tin Can APIでは、ユーザインタフェースを、コンテンツ/アクティビティ側にゆだねます。こうすることで、コンテンツ/アクティビティの開発者が意図したとおりに、そのコンテンツが経験されるよう保証することができます。

内容の提出(送信)

Tin Can APIでは、学習者にとって「提出(submit)」とは、
「終わりました(I’m done) これを提出して評価される準備ができている」という意味です。

SCORMには、「提出完了(submitted)」や「提出しない(not submitted)」という概念がありません。(「サスペンド(suspend)」は、入りません)SCORMを使用する場合、データの損失を避けるために自身をサスペンドする必要がありますが、コンテンツが完了してから、サスペンドした場合、LMSはコンテンツが評価される準備ができていると判断します。

もし、LMSが、評価される準備ができたと判断せず、学習者が戻り、完了したコンテンツを見直したい場合はどうなるでしょう。TinCan APIは、LMSが完了・提出で起こしかねない想定すべてを取り除きます。この問題は、「提出完了」または「提出しない」の概念を導入することで解決できます。学習者がコンテンツを完了したことや、提出する準備ができていること、または、コンテンツを完了し戻りたい、提出して評価される前に、見直すといったことをLMSは、判断することができます。

シーケンシング

SCORMでは、LMSで、シーケンシングを行うことは難しく、混乱しやすいです。Tin Can APIは、完全にLMSからシーケンスを取り除きます。LMSは、正しくシーケンス処理をしていないことより、それ以上に相互運用性に問題があります。コンテンツ/アクティビティは、単独で動作します。もし、それがコンテンツ開発者のもとで動作すれば、誰であっても動作しなければなりません。

APIのシンプルさ

一般的に、Tin Can APIは、不明瞭な領域を減らすことができます。推測に頼ることがずっと少なくなります。LRSは推測や想定に頼る必要はありません。全て、明記されており、そうあるべきです。ここでのTinCanAPIの弱点は、動詞の変化ですが、それにはいい解決法を考えています。もうひとつの弱点は、異なる方法でレポートしたユーザーが、本当は同一ユーザだと識別する処理が、LRSに対して負担が増してしまうことです。これは、「activity definitions agreement(アクティビティ定義の合意)」に関することで、それに私たちも、解決法を提案しています。


※ この記事は、CC BY 3.0のもと、Rustici Software 社の記事を翻訳したものです。
http://scorm.com/tincancapabilities/project-tin-can-phase-3-better-interoperability/

Tin Can API

プラットフォームの移行

Tin Can APIは、学習者に対して一つのプラットフォーム上(例えば、自宅のコンピュータなど)でアクティビティを開始した後、(モバイルフォン上のネイティブアプリのような)異なるデバイス上で、そのアクティビティを継続することができます。これはシンプルですが、強力な新しい機能です。そして、従来のeラーニング規格ではできませんでした。

レポートは、アクティビティを試行した箇所に基づいて引き出せるように、LRSには十分なデータを格納できるようにします。このアクティビティの20%は、ネイティブのAndroidアプリで経験され、70%がWindows7のInternet Explorerで経験されたなど。レポーティングは、このような細かな情報を取得する必要はありませんが、それができると親切でしょう。一つ言えることは、プラットフォームの移行が可能になり、コンテンツがLMSに格納されないことです。

アクティビティの開発者は、使用する可能性のあるプラットフォームごとにアクティビティの異なるバージョンを作成して、配信をコントロールできます。コンテンツとアクティビティの開発者は、適切なバージョンを提供するために、LMSに依存することはありません。どのように動作するのか? そう思うでしょう。

“state” APIは、アクティビティが利用する数の key/document をストレージに残すことができます。”state” は、異なるデバイス上の同一アクティビティ全体で、共有する仕組みを作ることができます。プラットフォーム移行のインスタンスにおいて、Tin Can APIは、 LRSに対して、論理的に同一アクティビティの異なるデバイス上の学習活動を確認できるようします。

これは、学習者が1つのデバイスから、同一のアクティビティを持つほかのデバイスに移行したり、アクティビティ全体を通じて、レポーティングしたり、どこで、どのようしてアクティビティを経験したか確認することが可能になります。


※ この記事は、CC BY 3.0のもと、Rustici Software 社の記事を翻訳したものです。
http://scorm.com/project-tin-can-phase-3-platform-transition/

Tin Can API

オフライン/実行時間の長いコンテンツをトラッキングする

従来のeラーニングの仕様のほとんどは、コンテンツをトラッキングするために常時接続を必要とします。

コンテンツは、中断や後で再開することができますが、中断している間、コンテンツをオフラインで体験することはできません。ユーザーがオフラインコンテンツを体験できるように、LMSは、APIのオフラインバージョンを提供することもできますが、しかし、それはLMSのために余分な仕事を必要として、すべてのLMSがこの機能を提供しているわけではありません。

LETSI RTWS (run-time web services)では、通信処理をするため、コンテンツプロキシを作成することで、この制約を回避して、プロキシがLMSと通信を行います。これはエレガントなソリューションですが、それには1つわずかな制約があります。コンテンツは、オフラインなる前に接続された環境で起動する必要があります。

この分野で、Tin Can APIを用いて行った仕事は、以前のRTWSの進捗に、直接もとづいたものです。Tin Can APIはRTWSと同じ機能を提供していますが、さらに2、3歩先を進んでいます。Tin Can APIを使用している、コンテンツ/アクティビティの一部は、スマートに、それがネットワーク接続されているかどうかを検出することができます。

もし、ネットワークに接続できず、コンテンツ/アクティビティが、独自のストレージを持っている場合、ローカルにデータを格納して、接続状態になったとき、LRSに戻し送信することができます。加えて、アクティビティは、RTWSとは異なり、オフラインで起動することができます。

Tin Can APIの特徴はまた、一度に数週間の間、SCORMのセッションを維持するのが非現実的なところでは、長時間実行されるコンテンツをトラッキングできることは、優れたところです。シミュレーションまたはシリアスゲームを考えると、ユーザーは数日、数週間にわたってインタラクションが続けられるかもしれません。そのため、各インタラクションごとに、LMSからそのつど起動すべきではありません。Tin Can APIは、この問題に良いソリューションを提供することができます。


※ この記事は、CC BY 3.0のもと、Rustici Software 社の記事を翻訳したものです。
http://scorm.com/project-tin-can-phase-3-tracking-offlinelong-running-content/

NoraUsagiメモ:

LETSI RTWS (run-time web services)
http://scorm.com/rtws/

Tin Can API

デジタルだけでなく現実世界のアクティビティをトラッキングする

従来のeラーニングの仕様は、コースが完了したときなど、デジタルのアクションをトラッキングします。

誰かがスキル学習をしているだけでなく、それを確認したい場合はどうしたらいいでしょうか、現実世界でそれを行うことができるでしょうか?(eラーニングに限らず) 現実世界において授業への積極性など、イベントを記録したい場合、どうしたらいいでしょうか?Tin Can APIは、デジタルの学習を用いた現実世界のアクティビティを統合するための方法を提供しています。

良い例は、地域のコミュニティセンターでは、CPR(心肺蘇生法)の認定が受けられます。コンピュータ上でトレーニングや、さらに一部は、テストを受けることができます。しかし、CPRは、さまざまなダミーを手にとって行う実技テストがあります。SCORMでは、このような一部 実技が入るテストをトラッキングする方法は提供していませんが、Tin Can APIでは行うことができます。

実際、あなたのクリエイティブ次第で、現実世界のどんなアクティビティでもLRS上で、Tin Can APIを利用して個人をトラッキングして記録することができます。

現実世界のトラッキング可能なアクティビティのそのほかの例:

  • 手入力で、「トランスクリプト・レコーダー」に入力できる情報
    • 誰かが、講義に出席
    • 誰かが、ダイビング機材を使用
    • 誰かが、ギリシャ語で会話
  • 授業出席率
  • 授業への積極性(参加状況)

もっとも簡単な実施は、ユーザーが特定のアクティビティを完了したことを、インストラクターがLRSに通知することです。より複雑な例では、トレーニング装置が(少なくとも、時々)ネットワークに接続され、ユーザがそれらの資格情報を用いてデバイスにログインします。現実世界のアクティビティが行われると、デバイスはLRSに結果をレポートします。

あなたが望むものはどんなものでも、デバイスにすることができるでしょう、CPRのダミー、フォークリフト、超音波機器など。私たちは、あなたがクリエイティブになることを期待している領域です、そして、それは間違いなく革新の領域です。


※ この記事は、CC BY 3.0のもと、Rustici Software 社の記事を翻訳したものです。
http://scorm.com/project-tin-can-phase-3-track-real-world-activities/