Chapter3 SCORM1.2概要ivory-zebra-409f9b960cb1d313.znlc.jp/date/scorm_text/...Chapter3:SCORM1.2...

SCORMアセッサ講習会テキスト

Chapter3

SCORM1.2概要

Chapter3:SCORM1.2概要

この章では、SCORM規格がどのように制定され、何を目指しているのか、SCORM準拠のコンテンツとは何を指すのか、また、SCORMはこの後どのように変わっていくことが予定されているのかを紹介します。さらに、SCORMの構成要素についても解説し、SCORMコンテンツの全体像を理解します。

この章の目的

この章を修了すると、・ SCORM1.2の仕様書 3編の概要が説明できます・ SCORM1.2コンテンツモデルの構成要素が列挙できます・ APIアダプタの遷移を順番に列挙できます・適合性要件と適合ラベルの関係について説明できます

前提知識

この章を学ぶ前に、以下の知識/スキルが必要です: ・ JavaScriptで書かれたプログラムが読める・ e-Learningにおける LMS、コンテンツ、ブラウザの役割を理解している

ノート

3-2


1. SCORMの概要

ここでは SCORMの概要として、どのような仕様書があり、何を定義しているのかを紹介します。

1-1. SCORMの構成

SCORMでは、e-Learningにおける学習コンテンツの共有化を図るため・耐久性・相互運用性・アクセス可能性・再利用性を実現する仕様の標準化を目指してアメリカのADL（Advanced Distributed Learning）が提示している規格です。

e-Learningコンテンツの流通のため、システムやソフトウェアのバージョンアップなどでも大きな修正の必要がなく（耐久性）、多くの OSやWebブラウザなどで学習可能で(相互運用性)、必要なときに学習教材が検索でき（アクセス可能性）、既存のコンテンツを容易に再利用して新規コンテンツの作成を可能にする（再利用性）ための規格と言えます。

SCORM1.2での規格化された仕様書は以下の３編から構成されています。・第１編：SCORM概要

(book1: Sharable Content Object Reference Model(SCORM)Version 1.2 The SCORM

Overview) ADL initiativeに関する概要、SCORMに関する技術仕様、ガイドラインに関する概要が記述されています。

・第２編：SCORMアグリゲーションモデル (book2: Sharable Content Object Reference Model(SCORM)Version 1.2 The SCORM Content

Aggregation Model) 学習コンテンツを識別し、組み立てるためのガイドラインが記述されています。ま

た、これらのガイドラインは、LTSC（IEEE Learning Tchenology Standards Committee）、IMS Global Learning Consortium,Inc、ARIADNE(Alliance of

ノート

3-3


Remote Instructional Authoring and Distribution Network)、AICC(Aviation CBT Committee)からの技術提供を受けまとめ上げられています。

・第３編：SCORMランタイム環境 (book3: Sharable Content Object Reference Model(SCORM) Version 1.2 The SCORM

Run-Time Environment) Webベース環境でのコンテンツ起動、通信、受講履歴に関するガイドラインが記述されています。このガイドラインは、AICC の”CMI001 Guidelines for Interoperability”をその起源としています。

では、どのような内容が書かれているのか、それぞれの仕様書の概要をご紹介します。

ノート

3-4


1-2. 「第 1編 SCORM概要」

第 1編の SCORM概要では、ADLの SCORMに対する取り組みやビジョン、SCORMの構成、第 1編から第 3編までの概要、SCORMを選択する理由(SCORMの必然性)についてなどが書かれています。はじめて SCORMコンテンツを作る場合、仕様書の全体構成や考え方を理解するのに有効です。

SCORM

BOOK 2: The SCORMContent Aggregation Model

BOOK 3: The SCORM Run Time Environment

Launch, Communication API (from AICC)

Data Model (from AICC)

BOOK 1: The SCORMOverview

Meta-data Dictionary (from IEEE)

(Meta-data XML Binding and Best Practice (from IMS)

Content Structure (derived from AICC)

Content Packaging (from IMS)

図 1-1-1 SCORMの構成

ノート

3-5


第 1編の中には、SCORMのタイトルの変更についても触れられています。SCORM1.0のときには、”Sharable Courseware Object Reference Model”であったタイトルが、SCORM1.1では、”Sharable Content Object Reference Model”になったというものです。これは、SCORMの技術仕様が適用される単位を、明確にあらわしているものといえるでしょう。また、LMSとコンテンツの役割分担についても記述されています。SCORMでは、LMSは学習資源の集合(コース)によって定義されたルールを解釈し、学習資源の提供方法を決定するというものです。つまり、SCORMではコースが構成されてはじめて各学習資源の文脈が構成されるということです。ですので、学習資源をさまざまに組み合わせ、コース

を構成することで、既存の学習資源を活用しながら新しい意味をもったコースが構成でき

るわけです。これがまさに、SCORMのタイトルが変更された理由です。

1-3. 「第 2編 SCORMアグリゲーションモデル」

第 2編の SCORMアグリゲーションモデルでは、学習資源を集約してコースにするための過程について、・コンテンツモデル・メタデータ・コンテンツパッケージングの説明で構成されています。 SCORMの構成要素であるアセット、SCO、メタデータなどの用語についても説明されています。教材づくりという観点から、SCORM コンテンツを設計する場合に理解しておくべき事項がもりこまれています。

1-4. 「第 3編 SCORM ランタイム環境」

ランタイム環境とは、大雑把に言うと学習者に提供される学習環境のことで、学習者が

LMS を通して学習資源を活用(起動)し、学習状況の送受信（進捗管理）、終了するまでの一連の流れを提供する環境のことです。第 3編の SCORMラインタイム環境では、これらの流れを実現する仕組みと、そこで送受信されるデータの種類について説明しています。実際に SCORM APIをインプリメント

ノート

3-6


する場合にプログラマに必要となる情報であるとともに、教材づくりの上でも、どのよう

な管理情報を有効に使えるのかを知ることができます。

1-5. SCORMの変遷

SCORM は過去のいくつかのバージョンに変更点を加えていく形で進歩してきました。それぞれの仕様書の説明にもあるように、SCORM立案以前からあった、以下のような規格の影響を受けています。・ IEEE Data Model For Content Object Communication ・ IEEE ECMAScript Application Programming Interface for Content to Runtime

Services Communication ・ IEEE Learning Object Metadata (LOM) ・ IEEE Extensible Markup Language (XML) Schema Binding for Learning

Object Metadata Data Model ・ IMS Content Packaging ・ IMS Simple Sequencing

SCORM2004のリリースに合わせ、SCORMのバージョンに関する記述を変更し、各仕様書の保守・独立性を高めています。各仕様書に”Version1.3”のようなリリース番号を付けることとし、これにより、各仕様書バージョンのみが変更されていくこことなります。

ノート

3-7


SCORMバージョン 1.1

2001 年 1 月 SCORMバージョン 1.2

2001 年 10 月 SCORM2004

2004 年 1 月

コンテンツ・アグリゲーション・

モデル(CAM)

メタデータ＋バインディング


モデル(CAM)


追加：コンテンツ・パッケージン

グ、コンテンツ構成

RTE1.3


モデル(CAM)


追加：コンテンツ・パッケージング、コ

ンテンツ構成、仕様修正

CAM1.3

ランタイム環境(RTE)

ＡＰＩ＋データモデル

仕様修正

ランタイム環境(RTE)

ＡＰＩ＋データモデルランタイム環境(RTE)

ＡＰＩ＋データモデル

仕様修正

シーケンシング＆ナビゲーション

(ＳＮ)

ルール、性質 SN1.3

図 1-1-2 SCORMの進展

今後の SCORM新機能の候補として、・新しいランタイム及びコースデータモデルアーキテクチャの設計・シミュレーションオブジェクトとの統合・エレクトロニックパフォーマンスサポートオブジェクトの統合・ SCORMベースの知的学習支援機能の実装・新しいコンテンツモデルの設計方法・ゲーム用テクノロジーの追加が挙げられています。

ノート

3-8


2. SCORMランタイム環境

SCORM の規格が実際にコンテンツでどのように実現されているのかを理解するには、SCORM ランタイム環境を考えるとよいでしょう。ここでは、LMS モデル、アセット、SCOなど SCORMランタイム環境について説明します。

2-1. LMSモデル

企業や組織内での LMSを利用した e-Learningのモデルです。

ＬＭＳ

コース管理

サービス

コンテンツ管理

サービス

学習者プロファ

イルサービス

トラッキング

サービス

配信サービス

シーケンシングサービステスト／アセス

メントサービス

SCORM ＡＰＩ

インタフェーズ

ローカル・

コンテンツ・

リポジトリ

リモート・

コンテンツ・

リポジトリ

SCORM コンテンツ

アグリゲーション

SCORM コンテンツ

(SCO,Assets) SCORM ランタイム環境

選択

起動

図 1-2-1 LMSモデル

ノート

3-9


LMSモデルは、以下のようなサービスのコンポーネントで構成されます。・コース管理サービス複数のコースの開催などを管理する

・コンテンツ管理サービスコンテンツ資源を管理する

・シーケンシングサービス配信するコンテンツの選択

・トラッキングサービス進捗状況を管理する

・テスト／アセスメントサービステストの評価

・学習者プロファイルサービス学習者の識別

・配信サービスコンテンツの配信

ただし、SCORM はこれらのサービスの具体的な実装方法は定義しません。また、広くコンテンツが流通するために、LMSが備える個別の特徴や機能について関与しないことになっています。SCORM が定義するのは、これらのサービスを提供する LMS モデルが外部とやりとりするデータ形式です。

ノート

3-10


2-2. API と API Adapter

具体的な LMSとコンテンツの役割は次のようになります。・ LMSの役割・目次を提示する・学習者に選択された目次項目に対応する学習資源を配信する・進捗状況や得点などを受け取り格納する

・コンテンツの役割・学習者に学習画面を提示する・学習状況を判定する(修了・学習中など) ・LMSに学習状況を送信する・クイズの場合には、採点し結果を LMSに送信する

ここで示したように、SCORM ではなく LMS 固有機能に特化した多くのコンテンツの場合と、SCORM に準拠したコンテンツの場合での違いは、進捗判定にあると言えます。

SCORMコンテンツの場合には、学習者の状況をコンテンツで判断します。クイズの場合には、問題提示、学習者解答、採点もコンテンツ側の実装責任となるわけです。

進捗判定やクイズの採点などは、Webの一般的なプログラミング言語である JavaScriptなどが使われます。進捗判定やクイズの採点プログラミングについては、SCORMでは規定していません。ただし、進捗判定の結果を LMS へ送信する場合は、SCORM 規格に則り、SCORM APIを呼び出すことになります。

SCORM APIの呼び出しは、コンテンツから LMSへのサービスのリクエストですが、そのリクエストが具体的にどのように処理されているかについては、SCORMでは規定されていません。これらの実装は、LMSが提供する「API Adapter」に全て隠蔽されます。API Adapterの中に、履歴処理が JavaScriptの関数として呼び出せる準備がされており、その呼び出し規約と動作定義のみが SCORMの規格となるわけです。

ノート

3-11


2-3. アセットと SCO

SCORM では、LMS が学習資源を配信管理する一般的な方法は「起動(Launch)」で定義しています。

例えば、LMSは学習者の学習状況に基づき学習資源を起動する順序を決定する機能を持つ場合があります。このような場合、各種のイベントによりどの学習リソースを起動する

かの決定は、LMS（あるいは配信機能/サービス）の役割です。起動する適切な学習資源を決定する際、LMSは学習資源の起動ロケーションとして定義された URLを使って、学習資源を起動するか、あるいはその場所に存在する学習資源と現在表示されている学習資

源を置き換えます。起動方法は、LMSに任され任意の方法で起動を実装することができます。また、必要に応じて LMS のクライアントまたはサーバ側に起動機能を実装させることができます。現実的な起動方法としては，HTTPプロトコルが用いられ、起動ロケーションとして定義された学習資源が起動され、クライアント側ブラウザに表示されます。

LMSによって起動される学習資源には、「アセット」、「SCO」のふたつがあります。

図 1-2-2アセット(左)と SCO(右)のイメージ

アセット

Web Page アセット

WAV

アセット

Flash

アセット

Java Script アセット

Html

アセット

JPEG/GIF

<! --content.htm -->

api = getAPI();

var results = api.LMSInitialize(“”);

var val = api.LMSgetValue(“cmi.abc.xyz”);

アセット

Web Page アセット

Flash

アセット

Html

アセット

WAV

アセット

JPEG/GIF アセット

Java Script

ノート

3-12


アセットは、他の Web クライアントに配布可能なメディア、テキスト、画像、音声、Webページ、アセスメントオブジェクトなどの電子的な表現やデータの断片です。それ自体は動作の記録対象とはなりませんので、SCORM APIの実装は不要です。

SCO(Sharable Content Object)は、複数のアセットの集合体として、SCORMランタイム環境を利用してLearning Management Systems (LMS)と通信を行うものと規定されます。SCOは SCORMランタイム環境において LMSが動作を記録できる最少単位の学習資源となります。

また、LMS では一度にひとつの SCO だけが起動され、ひとつの SCO だけがアクティブになります。ですので、SCOが別の SCOを起動する(SCOの入れ子や SCOの制御による SCOの移動)はしてはいけません。

SCOは再利用を前提として設計をする必要があります。このため SCOは学習文脈から独立することになります。例えば SCO は異なるコンテンツ（教材）内において異なる学習目標のために使用することができます。複数の学習目標のために再利用できるよう、SCOは小さなユニットとして設計されます。しかしながら、SCORMでは SCOに関して正確な大きさについての制約をありません。

SCOの大きさを検討する場合、コンテンツ設計、作成の過程において LMSによって受講履歴を記録できる最少単位として論理的な大きさを検討する必要があります。コンテン

ツ設計者は、SCOの大きさとして、学習成果をあげるためにどれだけの情報（受講履歴）が必要なのか、どの程度の再利用性が将来求められるかによって決める必要があります。

ノート

3-13


起動

API (SCO、ＬＭＳ間通信)

サーバサイトクライアントサイト

データモデル：

ＳＣＯ、ＬＭＳ間で

やり取りされる

実際のデータ JavaScriptJavaScript

ブラウザ

SCO

LMSServer

Asset

LMSサーバ

API Ad teap r

API Adapter

Learning Management System (LMS)

図 1-2-3 SCROM ランタイム環境

2-4. API Adapter状態遷移

SCOはAPI Adapterを含んでいる子ウィンドウあるいはLMSウィンドウの子フレームであるブラウザ・ウィンドウで起動されます。ですので、SCO が起動された場合、API Adapterが見つかるまで，親およびオープンウィンドウの階層を再帰的に探索することが必要です。一度 API Adapterが見つかれば，SCOは API Adapterを経由して LMSと通信を開始することができます。

API Adapterには、以下のような状態遷移があります。・ Not Initialized(未初期化) ・ Initialized(初期化済) ・ Finished(完了)

ノート

3-14


API Adapterの状態遷移と、SCORM APIの関係を図で示します。

Finished

If LMSFinish returns false (only)

then the SCO can call:

•LMSGetLastError

•LMSGetErrorString

•LMSGetDiagnositc

SCO Launched

By LMS

SCO Responsibility:

Find the API

and Call

LMSInitialize

SCO can call:

•LMSGetValue

•LMSSetValue

•LMSGetLastError

•LMSGetErrorString

•LMSGetDiagnositc

•LMSCommit

•LMSFinish

LMSInitialize(“”) LMSFinish(“”) Initialized

nitializedNot I

図 1-2-4 API Adapterの状態遷移と SCORM API

ノート

3-15


Not Initialize(未初期化)は、SCOが実際に起動されてから、LMSInitialize (“”) API関数を呼び出すまでの状態に相当します。この状態において、SCO は，LMS によって提供されている API Adapterを探索／発見しなくてはなりません。いったん、API Adapterが見つかれば、SCOは以下の API関数を呼び出すことができます。・ LMSInitialize(“”) ・ LMSGetLastError() ・ LMSGetErrorString() ・ LMSGetDiagnostic()

Initialized(初期化済み)は、SCO が、LMSInitialize（””） API 関数を呼び出してから

LMSFinish(“”) API 関数を呼び出すまでの状態です。SCO が初期化済み状態であれば、LMSInitialize(“”)を除く全ての API関数の呼び出しが許されます。例えば、この状態のときに、・ LMSSetValue() ・ LMSGetValue() を呼び出して、SCOと LMSの間でのデータ送受信を行います。 Finished(完了)は、SCOが，LMSFinish(“”) API関数を呼び出した状態です。もし，APIアダプタが LMSFinish(“”)を呼び出した SCO に”false“を返した場合，SCO は以下のAPI関数を呼び出すことができます。・ LMSGetLastError() ・ LMSGetErrorString() ・ LMSGetDiagnostic()

なお、LMSFinish(“”)が“false”を返した場合、LMSが未知の状態であり、以降のいかなる API 呼び出しも、LMS によって処理されるか処理されないかが不明であることをSCOに示しています。

ノート

3-16


API Adapterはクライアントサイドで実行されますが、API Adapter自体は LMSより配信されます。

API Adapterを使用するための必要条件をまとめます。・ LMS は、API Adapter を含んでいる子ウィンドウあるいは LMSウィンドウの子フレームであるブラウザ・ウィンドウで SCOを起動しなければいけない。

・ LMSは API Adapterを提供しなければならない。・ SCO から API インタラクションのためにサポートされる唯一のメカニズムは，

ECMAScript(Javaスクリプト)呼び出しを経由する必要がある。・ API Adapterは“API”と命名されるオブジェクトとして DOMを経由しアクセス可能でなければならない。

例えば、API Adapterは以下のような署名を持つ Javaアプレットとして実装される場合があります。

public class API extends Applet

{

public String LMSInitialize( String parameter )

{ . . .}

public String LMSGetValue( String element )

{ . . }

public String LMSSetValue( String element, String value )

{. . .}

public String LMSCommit( String parameter )

{. . .}

public String LMSFinish( String parameter )

{. . .}

public String LMSGetLastError()

{. . .}

public String LMSGetErrorString( String errorCode )

{. . .}

public String LMSGetDiagnostic( String errorCode )

{. . .}

}

図 1-2-5 API Adapter記述例

ノート

3-17


次のコード例は、API Adapter を見つけるために SCO が使用することができるアルゴリズムを示します。

ノー

<SCRIPT LANGUAGE=JAVASCRIPT >

var findAPITries = 0;

function findAPI(win)

{

// Check to see if the window (win) contains the API

// if the window (win) does not contain the API and

// the window (win) has a parent window and the parent window

// is not the same as the window (win)

while ( (win.API == null) &&

(win.parent != null) &&

(win.parent != win) )

{

// increment the number of findAPITries findAPITries++;

// Note: 7 is an arbitrary number, but should be more than sufficient

if (findAPITries > 7)

{

alert("Error finding API -- too deeply nested.");

return null;

}

// set the variable that represents the window being

// being searched to be the parent of the current window

// then search for the API again

win = win.parent;

}

return win.API;

}

ト

3-18


データモデル

LMSが学習者の学習受講履歴を記録するためのデータの集まりが“データモデル”と呼ばれています。データモデルの代表的なものとして”AICC CMI data model”があります。このデータモデルによって、どのような学習履歴管理ができるかが決定されます。

SCORMでは、AICCデータモデルを基礎に SCORM独自のデータモデルを定義しています。そのため SCORMにおけるデータモデル名として“cmi”を使用します。例えば、今後、新しいデータモデルが開発されれば、”eLC”となることも考えられます。データモデルは、階層化されたデータエレメントから構成されています。このデータエ

レメントは、”LMSGetValue” “LMSSetValue”で呼び出されるパラメータとして動作します。

データモデルデータエレメント

cmi. core.session_time

cmi.student_data.mastery_score データグループ

図 1-2-5 データモデル関連図

データモデル要素は，「必須(mandatory)」と「オプション(optional)」の２つに分類できます。 AICC CMI001ガイドラインの相互運用性ドキュメントは、どの要素が LMSによる必須な実装を要求するか、そしてどれが任意かを規定しています。

SCORM に準拠する LMS は、必須データモデル要素をすべてサポートすることが必要です。さらに、オプションデータモデル要素については、すべてあるいは一部のデータモ

デル要素を実装することになります。 SCO からいずれのデータ要素を利用するかは自由です。SCO は API 関数

LMSInitialize(“”)および LMSFinish(“”)を使用しなくてはなりませんが、LMSSetValue()や LMSGetValue()は使用する必要はありません。SCO を非常に小さな単位や、詳細なトラッキングをしないようにも設計することができます。しかし、トラッキングする場合、

ノート

3-20


複数の LMS 環境にまたがって再利用が可能となるように、共通データモデルに適合していなければなりません。

リストや配列に現われるいくつかのデータ要素があります。１つの例として、“Objective（学習目標）”があります。コンテンツの中には複数の”学習目標”があるかもしれない。

また、学習者は“学習目標”を何回も経験してよいことになります。リストの値を取得・設定するために、インデックス値を利用することができます。イン

デックス値が省略できるのは、リスト中にメンバが 1つだけの場合です。インデックス番号付けは０からスタートします。値がリストに追加される場合、SCOは使用されている最後のインデックス値を知らなければなりません。新しい配列要素は、すべて連続するものとします。SCOは配列番号をスキップしてはならず、配列値のリストを作成するとき、空の配列要素を残してはいけません。_countキーワードは、リスト中のレコード数を決定するために使われます。例えば、現在格納されて

いる対象レコードの数を決定するために，以下の API呼び出しが使われます。 var numOfObjectives = LMSGetValue("cmi.objective._count"); 学習目標レコードの数が分からない場合、SCOが現在の数を０から開始してよいことになります。これは、第 1のインデックス位置に現在格納された学習目標に関する任意の情報を上書きできるということです。上書きするか、追加するかは、SCO 作成者によってSCO開発時に決定されます。リストの中の要素は，点-番号表記法（.nによって表される）で参照されます。たとえば，

SCOの最初の学習目標における状態要素の値は，"cmi.objective.0.status"で参照されます。第 4番目の学習目標の状態要素は，"cmi.objective.3.status"で参照されます。

ノート

3-21


3. コンテンツ・アグリゲーション・モデル

ここまで、SCO、アセットと LMSの関連を見てきました。e-Learningのコースでは SCOの起動順序などが目次として示されなければなりません。ここでは、学習教材としてどの

ように学習資源をまとめるのかについて説明します。

3-1. コンテンツ・アグリゲーション

コンテンツ・アグリゲーションは、学習資源をひとつにまとめた学習ユニット（コース、

章、モジュールなど）として組み立て、学習リソースを学習者に提示する学習順序の構造

やカリキュラムを定義するマップ（コンテンツ構造：学習リソースを定義）となります。

コンテンツ構造


学習リソース

学習リソース

学習リソース

学習リソース


学習リソース

ＳＣＯ

ＳＣＯ

アセット

ＳＣＯ

アセット

アセット

アセット

アセット

コンテンツ・アグリゲーション

図 1-3-1 コンテンツ・アグリゲーション

ノート

3-22


コンテンツ・アグリゲーションは、学習リソース（SCO/アセット）を、学習コンテンツを構築するために定義された構造（コンテンツ構造）に集約するプロセスです。

3-2. メタデータ

メタデータは学習資源の内容や特徴などを表現するデータです。コンテンツ・アグリゲ

ーションも、メタデータによって表現されます。また、SCOやアセットについても、メタデータを用いて表現されます。ただし、SCORM 規格では学習資源に対してメタデータを必ず付けるように規定していません。しかし、メタデータは、同一システム内やシステム間での学習資源の検索・発見

のために欠かせない情報です。SCORMの本来の目的である、学習資源の再利用性と流通性の実現のためには、メタデータを付けることが重要です。

SCORM では、LOM 規格に基づきメタデータでの用語を決めています。メタデータは

XML 形式で記述されます。XML は HTML 同様テキスト形式で記述され、事前に設計されたタグにより必要な情報を記述できるなどの点で、汎用性の高い記述方法です。

メタデータには、文脈依存メタデータと文脈非依存メタデータがあります。文脈依存メ

タデータは、特定の学習資源と他の学習資源との関連を記述します。コンテンツ・アグリ

ゲーションのメタデータは、この文脈依存メタデータとして記述します。一方、学習難易度や学習目標など特定の学習資源のみ（この場合は特定の SCO）の属性については、文脈非依存メタデータで記述することになります。注意すべき点は、SCOの属性として文脈依存メタデータを記述することは SCOの再利用性という面から避けなければならないということです。例えば、ある SCOが他の SCOへの分岐を含む場合、この SCOは分岐先の SCOが存在しない他のコースでは再利用できないことになります。このような状況は教材設計の時点で配慮し、SCOの独立性を高めるコンテンツ開発をしなければなりません。

コンテンツ・アグリゲーション、SCO、アセットのメタデータは、マニフェストファイル(imsmanifest.xml)に記述することができます。

ノート

3-23


4. SCORMコンテンツパッケージング

コンテンツ・アグリゲーションは、メタデータによってその属性が記述されます。しか

し、実際のコンテンツ流通のためには、属性を記したファイルや HTML ファイル、音声ファイル、イメージファイルなどデジタル化された学習資源を交換するための標準が必要

です。 SCORM コンテンツパッケージングでは、学習リソースの構造やパッケージング方法、パッケージング情報モデルなどが規格化されています。

4-1. コンテンツパッケージング

SCORMコンテンツパッケージングには、二つの主要な要素を含んでいます。・パッケージのコンテンツ構造とリソースを記述するマニフェストファイル

(imsmanifest.xml) ・ imsmanifest.xmlから参照される物理ファイル

Manifest

Meta-data

Organizations

Resources

(sub)Manifest(s)

コンテンツ・パッケージ

Manifest ファイル

(imsmanifest.xml) 物理ファイル：コンテンツ、メディア、アセ

スメント（テスト）等

図 1-4-1 コンテンツ・パッケージ概念図

ノート

3-24


パッケージは、利用（再利用）可能なコンテンツ（教材）であり、一般的にはコースに

対応することになります。このパッケージの中にはコンテンツ（教材）を学習するために

使用されるすべての情報を含んでいます。・ ”manifest” “manifest”は、XML で記述された学習リソース記述で、コンテンツを構成する学習リソースを定義しています。

・メタデータメタデータはデータに関するデータです。メタデータは，IMSコンテンツパッケージで定義された各種レベルでのメタデータを記述します。図 18 で示すメタデータはパッケージ全体の記述として使用されます。メタデータは、”organizations”、”resourses”、さらにこれらのサブ要素の記述として使用することができます。

・ “organizations” “organizations”要素は、コンテンツに構造を与えるために使用されます。典型的にはコンテンツ構造として、学習分類階層を定義するために利用され、必要な異

なる複数の分類を記述する手段となります。

・ ”resourses” “resourses”要素は、外部リソースやパッケージに含まれる物理ファイルを記述します。記述されるファイルは、メディアファイル、テキストファイル、アセスメ

ント（テスト）要素、その他電子的なデータです。”resourses”は、”organizations”要素の様々な箇所から参照されます。

・物理ファイル物理ファイル要素は”resourses”要素から参照される実際のファイルです。これらのファイルは、コンテンツパッケージに実際に含まれるローカルファイルや

URI(Uniform Resource Identifier)で参照される外部ファイルです。

ノート

3-25


・パッケージ交換ファイルパッケージ交換ファイル(Package Interchange File: PIF)は、コンテンツパッケージを zip、 jar、 cab、 tar、などのアーカイブ形式で表現したもので、システム間でコンテンツパッケージを転送するために利用される簡易な Web 配送フォーマットです。ただし、コンテンツパッケージを PIF形式で格納することは必須ではありません。

4-2. マニフェストファイルの記述例

マニフェストは、メタデータ（コース説明）、オーガニゼーションズ（コース構造）及び、

リソース（コース資源）を記述したものです。ファイル名は“imsmanifest.xml”です。マニフェストファイルでは、XML タグを用いて情報を記述していきます。ここでは、

SCOが一つだけの「コンテンツパッケージの説明」というコースについての記述例を説明します。

■ マニフェスト例

<?xml version = "1.0" encoding = "Shift_JIS"?>

<manifest identifier="ManifestSample" version="1.2"

xmlns="http://www.imsproject.org/xsd/imscp_rootv1p1p2"

xmlns:adlcp="http://www.adlnet.org/xsd/adlcp_rootv1p2"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://www.imsproject.org/xsd/imscp_rootv1p1p2

imscp_rootv1p1p2.xsd

http://www.imsglobal.org/xsd/imsmd_rootv1p2p1 imsmd_rootv1p2p1.xsd

http://www.adlnet.org/xsd/adlcp_rootv1p2 adlcp_rootv1p2.xsd">

ここは XMLを解釈するためのスキーマーについて記述しています。

ノート

3-26


<metadata>では、タイトルや説明、キーワードを記述しています。SCORM 規格では

必須ではありません。記述しない場合には<metadata/>となります。

<metadata>

<schema>ADL SCORM</schema>

<schemaversion>1.2</schemaversion>

<imsmd:lom>

<imsmd:general>

<imsmd:title>

<imsmd:langstring lang = "jp">

コンテンツパッケージの説明

</imsmd:langstring>

</imsmd:title>

<imsmd:description>

<imsmd:langstring Lang = "jp">

このコースはコンテンツパッケージについて説明してます。

</imsmd:langstring>

</imsmd:description>

<imsmd:keywords>


コンテンツパッケージ

</imsmd:langstring>


SCORM 1.2

</imsmd:langstring>

</imsmd:keywords>

</imsmd:general>

</imsmd:lom>

</metadata>

ノート

3-27


<organizations>では、コースの IDと SCOの IDをコース構造に基づいて記述します。ここでは、コースの ID として“SampleCourse”、SCO の ID として“SCO1”を定義しています。「 Sample Simple Single SCO Course」が章タイトル、「 An Introduction to

ContentsPackage」が節タイトルとなり、この節と SCOが関連付けれれます。

<resources>で物理ファイルの位置と<organizations>で定義した SCOの IDを関連付けます。

ノー

<resources>

<resource identifier = "SCO1" type = "webcontent"

adlcp:scormtype = "sco" href="start.html”>

<file href = "start.html"/>

<file href = "end.html"/>

</resource>

</resources>

</manifest>

<organizations default = "SampleCourse">

<organization identifier = "SampleCourse" structure = "hierarchical">

<title>

Sample Simple Single SCO Course

</title>

<item identifier = "course" identifierref = "SCO1">

<title>

An Introduction to ContentsPackage

</title>

</item>

</organization>

</organizations>

ト

3-28


コラムマニフェストの例では、<metadata>と<organizations>セクションに記述される情報が、コンテンツアグリゲーション・メタデータとなります。また、<resources>セクションに記述される情報が、SCO メタデータ、<files>サブセクションに記述される情報が、アセット・メタデータとなります。

ノート

3-29


5. 適合要件

SCORM1.2 には、さまざまな読者を対象とした大量の技術情報が文書化されています。したがって、製品ベンダーは、自社の学習製品を SCORM1.2 に準拠させるための情報を知っておかなければなりません。そのために必要な適合性要件に関して説明します。

5-1 適合分類と適合性ラベル

SCORM1.2に適合するためには、学習管理システム（LMS）、SCO、メタデータ、あるいはコンテンツ・パッケージが要件を満たさなければなりません。適合分類適合性要件データモデルの適合性適合性ラベル

最低条件 LMS-RTE1

最低条件＋オプション・データモデル要素

の一部

LMS-RTE2

学習管理システ

ム（LMS）

ランタイム環境準拠

（起動／ＡＰＩ関連適

合性要件）


のすべて

LMS-RTE3

最低条件 SCO-RTE1

最低条件＋必須データモデル要素の一部 SCO-RTE1+Mandatory


の一部

SCO-RTE1+Optional

SCO ランタイム環境準拠

（起動／ＡＰＩ関連適

合性要件）

最低条件＋オプションおよび必須データモ

デル要素の一部

SCO-RTE1+Mandatory

+Optional

最低条件 MD-XML1

最低条件＋オプション要素 MD-XML1+Optional

最低条件＋拡張要素 MD-XML1+Extensions

コンテンツアグリ

ゲーション

SCO

リソースメタデー

タ

メタデータ XML 準

拠

最低条件＋オプション要素・拡張要素 MD-XML1+Optional

+Extensions

コンテンツ・パッケ

ージ（リソースパッ

ケージ、コンテン

ツパッケージ）

コンテンツ・パッケ

ージ XML 準拠

ADLCP-PIF1

ノート

3-30


5-2 ＬＭＳ適合性要件

LMS が、SCORM1.2ランタイム環境への準拠と認定されるためには、SCORMランタイム環境に記載された実行環境をサポートしなければなりません。SCORM実行環境には下記の３つのコンポーネントがあります。・起動どの学習リソース（リソースまたは SCO）起動すべきかを判断することは、LMSの責任です。LMS は、状況に応じて自動的に学習リソースを起動することができます。あるいは別な方法として、メニュー、目次、または戻り／次へボタンなどユ

ーザー主導のナビゲーション制御を提供することもできます。現時点で唯一指定さ

れている要件としては、LMSが学習リソースを起動できるということです。LMSは、リソースあるいは準拠していることが分かっている SCO を起動しなければならず、その際学習リソースが IMS マニフェスト・ファイルに定義されている順番で行わなければなりません（順番を変えるための条件があらかじめ定義されている

場合を除きます）。・アプリケーション・プログラム・インターフェース（API）

SCORM1.2ランタイム環境の APIでは、SCOが LMSとデータを通信および交換するための一貫した手段を提供します。LMSは、SCORM1.2ランタイム環境に定義されている機能を有する APIアダプターをサポートしなければなりません。

・データモデルランタイム環境データモデルと API は密接に連携されています。データモデルには、LMSと SCOが APIを通して交換する情報が記述されています。

最低条件（LMS-RTE1）最低条件＋オプション・データモデル要素の一部（LMS-RTE2）最低条件＋オプション・データモデル要素のすべて（LMS-RTE3）

ノート

3-31


5-3 SCO適合性要件

SCOが、SCORMランタイム環境準拠と認定されるためには、SCORMランタイム環境に記載された実行環境をサポートしなければなりません。SCORM実行環境には以下のコンポーネントがあります。・起動・アプリケーション・プログラム・インターフェース（API）

SCO は LMS によって起動されたら、SCO は API アダプタを見つけ以下の API関数の呼び出しを正しく行う必要があります。

SCOが LMSとの通信準備ができたことを示す LMSInitalize(“”) SCOが LMSとの通信が完了したことを示す LMSFinish(“”)

・データモデル最低条件（SCO-RTE1）最低条件＋必須データモデル要素の一部（SCO-RTE1+Mandatory）最低条件＋オプション・データモデル要素の一部（SCO-RTE1+Optional）最低条件＋必須・オプション・データモデル要素（SCO-RTE1+Mandatory+Optional）

5-4 メタデータ適合性要件

メタデータ適合性要件では、リソース、SCO、コンテンツアグリゲーションメタデータXMLドキュメントに対する適合性要件を定義しています

最低条件”（MD-XML1）最低条件＋オプション要素”（MD-XML1+Optional）最低条件＋拡張要素”（MD-XML1+Extensions）最低条件＋オプション要素・拡張要素” （MD-XML1+Optional+Extensions）

ノート

3-32


5-5 コンテンツ・パッケージ適合性要件

現在定義されているコンテンツ・パッケージ適合性要件としては、以下の要件となりま

す。コンテンツ・パッケージ適合性要件に共通要件（ADLCP-PIF1）リソースパッケージ学習資源を含むパッケージ

コンテンツアグリゲーションパッケージ構造化された学習資源を含むパッケージ

5-6 SCORM1.2 コンフォーマンス（適合性）・テスト・スイート 1.2

SCORM1.2 に適合されているかの検証として、コンフォーマンス（適合性）・テスト・スイートがＡＤＬより提供されています。コンフォーマンス（適合性）・テスト・スイートでは、適合性要件の妥当性を自動的に検

査しますが、自動化されたテスト・スイートのみでは、すべての詳細な適合性要件の妥当

性を検査することは不可能です。SCOの構成に配慮し、適切な検査方法の選択とすべてのフローを確認するコンテンツの操作を行うことで、適合性要件の妥当性が正しく検査され

ます。

ノート

3-33


まとめ

SCORM(Sharable Content Object Reference Model)は ADLによって立案された、既存のいくつかの互いに関係する技術仕様とガイドラインを参照するモデルです。「SCORM 概要」「SCORMアグリゲーションモデル」「SCORMランタイム環境」の 3編の本で定義されており、それぞれ独立してメンテナンスされていく予定になっています。

SCORM は LMS と学習コンテンツがどのようにデータをやり取りするかについて、SCORM APIとデータモデルを定義しています。SCORM APIは学習コンテンツ中に記述された JavaScriptでコールされます。JavaScriptをコールし、LMSとデータをやり取りする学習資源を SCOと呼びます。LMSとデータのやり取りを行わない学習資源はアセットと呼びます。

コンテンツアグリゲーションでは、SCO、アセットと言った学習資源をコースとしてまとめる方法を定義しています。コースとしてまとめられた SCORMコンテンツには、その属性を示すためのファイルとして imsmanifest.xmlが必ずひとつだけ存在しています。

SCORM のデータモデルには必須とオプションがあり、どの程度まで実装しているかで適合性ラベルが分かれています。

ノート

3-34


自己チェック

1. SCORMの目的について説明されているのは？ □ 「耐久性」「相互運用性」「評価可能性」「再利用性」を目指している □ 「耐久性」「相互運用性」「アクセス可能性」「再利用性」を目指している □ 「耐久性」「相互運用性」「アクセス可能性」「拡張性」を目指している

2. API Adapterについて正しく説明されているのは？ □ コンテンツは LMS と通信するために API Adapterを JavaScriptで実装しなければならない □ LMSはコンテンツと通信するために API Adapterを提供しなくてはならない □ LMS とコンテンツは双方で API Adapterを提供し合い、通信を確立しなければならない

3. API Adapterの状態遷移として正しく説明されているのは？ □ 「Not Initialized」「Initialized」「Finished」で遷移する □ 「Found」「Not Initialized」「Initialized」「Finished」で遷移する □ 「Not Found」「Not Initialized」「Initialized」「Finished」で遷移する

4. LMSFinish(“”)を呼び出した後、呼び出せる APIは？ □ LMSGetValue □ LMSInitialize □ LMSGetLastError

5. 適合性ラベル SCO-RTE1+Mandatoryついて正しく説明されているのは？ □ LMSInitialize と LMSFinishのみコール SCOが該当する □ LMSInitialize と LMSFinish と LMSSetValueをコール SCOが該当する □ LMSInitialize と LMSFinish をコールし、LMSSetValue で“cmi.core.lesson_status”に学習状況を格納する SCOが該当する

ノート

3-35

Chapter3 SCORM1.2概要ivory-zebra-409f9b960cb1d313.znlc.jp/date/scorm_text/...Chapter3:SCORM1.2...

Documents

Transcript of Chapter3 SCORM1.2概要ivory-zebra-409f9b960cb1d313.znlc.jp/date/scorm_text/...Chapter3:SCORM1.2...