0

数値相互作用タイプの可能な応答パターンに関して、私の理解では、可能な組み合わせは 4 つあります。

'2[:]4' // would mean a minimum of 2 and a maximum of 4 (response in the range of 2 to 4 would be correct)
'4' // (no delimiter) means there is a single correct answer of 4
'4[:]' // this means a minimum of 4 and no maximum (response in the range of 4 or above would be correct)
'[:]4' // would mean no minimum but a maximum of 4.

私の質問は最後の例に関するものです。0 (ゼロ) または負の数の答えは受け入れられるでしょうか? 標準はそのような状況を規定していないようであり、ゼロ以下の値が仕様の起草者の意図の範囲内であったかどうかは不明です. 応答パターン'-2[:]4'は SCORM クラウド LRS で機能しますが、他の LRS が負の範囲値を受け入れるかどうかはわかりません。

4

1 に答える 1

1

これは実際にはいくつかの部分に分かれており、どの値がどの仕様に準拠しているか、どのようなユースケースが意図されているか、そして市場で実際に見られるものです。

1) これらのデータに関する xAPI 仕様は非常に緩いです。厳密に言えば、厳密な (MUST に従う) xAPI の目的では、任意の文字列値が配列result.response内の または 項目として受け入れられます。より厳密にしたい場合correctResponsesPatternは、LRS の実装に任せます。以下を参照してください。

LRSは、有効なinteractionTypeを消費すると、相互作用アクティビティに指定された残りのプロパティを検証することができ、残りのプロパティが相互作用アクティビティに有効でない場合、400 Bad Requestを返すことができます。

(参照: 2.4.4.1 https://github.com/adlnet/xAPI-Spec/blob/master/xAPI-Data.md#requirements-4 )

SCORM クラウドは厳密なモデルに従っているため、これらのプロパティが文字列であることのみを検証し、それらの文字列の内容に対してそれ以上のアクションを実行しません (現時点では)。他の LRS は、上記の値についてより厳密である場合とそうでない場合があります。

ここでの運用テキストは次のとおりです。

これらのタイプの相互作用は、SCORM 2004 4th Edition ランタイム環境の「cmi.interactions.n.type」で許可されている相互作用のタイプに基づいていました。

(参照: https://github.com/adlnet/xAPI-Spec/blob/master/xAPI-Data.md#interaction-types )

そして、そこにある重要なフレーズはもともと に基づいていました。つまり、LMS ベンダー間での CMI データ モデルの採用の程度と、当時の状況を支配していた対応するコンテンツを考えると、少なくともそれらの使用を容易にすることが重要であると判断されました。 、xAPI が提供する拡張されたスコープを妨げません。

2) SCORM 2004 第 4 版はより厳格です。RTE リファレンスには次のように記載されています。

インタラクションには、学習者からの数値応答が必要です。応答は、オプションの小数点付きの単純な数値です。

後に次のように述べています。

文字列値が数値範囲の場合、次の形式を示す必要があります。ここで、<min> と <max> は両方とも実数 (10, 7) データ型です。

したがって、数値は のセットで表す必要がありreal(10, 7)ます。他の場所で次のように参照されています。

real(10,7) データ型は、有効桁数 7 桁の精度を持つ実数を表します。

(この後に SQL を使用して値を格納する方法と、その指定が ISO 11404 に対応するという注意事項があります)

そのため、SCORM 2004 情報モデルで使用するデータをキャプチャしようとしている場合は、使用をその範囲の値に制限する必要があります。

3) これまでの市場では、合理的にキャプチャする必要があるものをキャプチャする人がほとんどで、cmi.interactions は単純なケースに使用されていますが、それ以上のものはほとんどありません。LRS は通常、文字列の内容から意味を導き出そうとすることを避けることを好み、(厳密な仕様の観点から) LRS がそのような検証を提供する理由はあまりないため、文字列の内容自体の強力な検証は期待できません。ダウンストリーム システム (LMS やレポート ツールなど) は、認識したデータを適切に処理することをお勧めします。

于 2017-02-22T15:44:46.940 に答える