5 Sharable Content Object Reference Model (SCORM)

							                                                                             Hinweis:
5 Sharable Content Object Reference Model (SCORM) [ADL, 2004a-d]             Beachten Sie die
                                                                             zusätzlichen Folien
Ziel:                                                                        zu SCORM!

− Sie können die Ziele von SCORM erläutern.
− Sie können die Erzeugung der Komponenten des „Content Aggregation Model (CAM)“
   und deren Verknüpfung erläutern.
− Sie können ein Manifest erstellen und seine Wirkung erläutern.


zusätzlich für Diplom-Studierende:
− Sie können die „Run-Time Environment (RTE)“ und das „Application Programming In-
   terface (API)“ mit API-Suche, API-Aufrufen und Datenmodell erläutern.
− Sie können „Sequencing and Navigation (SN)“ mit Inhaltshierarchien, Aktivitätsbäumen
   und Clustern erläutern.




S. Schubert                                                                        5/1
Literatur und Quellen
− Sharable Content Object Reference Model (SCORM) 2004 3rd Edition. October 20, 2006
   − [ADL, 2004a] SCORM 2004 3rd Edition Overview Version 1.0
   − [ADL, 2004b] SCORM 2004 3rd Edition Content Aggregation Model Version 1.0
   − [ADL, 2004c] SCORM 2004 3rd Edition Run-Time Environment Version 1.0
   − [ADL, 2004d] SCORM 2004 3rd Edition Sequencing and Navigation Version 1.0
   − URL: www.adlnet.gov
− [Graf, 2003] Graf, F.: Lernspezifische Sicherheitsmechanismen in Lernumgebungen mit modula-
   rem Lernmaterial. Dissertation, Fachbereich Informatik, Technische Universität Darmstadt, 2003,
   URL: tuprints.ulb.tu-darmstadt.de/304/




S. Schubert                                                                                    5/2
Einleitung
– Ziele von SCORM
   • R: reusable = wieder verwendbar → kostengünstiger
   • A: accessible = zugänglich → Verfügbarkeit von Lerneinheiten
   • I: interoperable = plattformunabhängig → Austausch von Lerneinheiten
   • D: durable = dauerhaft → kostengünstiger
   • Modularisierung und Metadaten
– Entwicklungsstand
   • Januar 2004   SCORM 2004 1st Edition
   • Juli 2004     SCORM 2004 2nd Edition
   • Oktober 2006 SCORM 2004 3rd Edition
– SCORM = Sammlung von Definitionen und Skripten (Programme)




S. Schubert                                                                 5/3
5.1 Content Aggregation Model (CAM)
– Zusammenfassung und Strukturierung von Ressourcen zu verteilbaren Lernpaketen
– Dateien der unterschiedlichsten Formate oder URLs
– Inhaltshierarchien (Organizations) = vordefinierte Reihenfolge der Komponenten
– Komponenten können mit Metadaten beschrieben werden, um Suche und Auffinden in
   Repositories zu ermöglichen und die Wiederverwendung zu unterstützen
– Manifestdatei im XML-Format („imsmanifest.xml“)


CAM:
1. Content Model: content components
2. Content Packaging: content structure
3. Meta-data: specific instances of content components
4. Sequencing and Navigation: rule-based model




S. Schubert                                                                        5/4
Content Model Components
– lower-level resources are aggregated into higher-level units
– basic form Asset
– Sharable Content Object (SCO)
   • collection of one or more Assets
   • the lowest level of granularity tracked by an LMS
   • IEEE ECMAScript Application Programming Interface for Content to Runtime Services Com-
      munication draft standard (JavaScript)
   • independent of learning content
   • different learning objectives
   • small units
   • no exact size
– any LMS can launch SCOs
– any LMS know when SCO has been started (when SCO has been ended)
– any LMS launch any SCO in the same way


S. Schubert                                                                              5/5
Inhaltshierarchien (Content Organizations)
– Activities = structured units of instruction
– Repräsentation des beabsichtigten Lehr-Lern-Prozesses
– Inhaltshierarchie zeigt, wie Aktivitäten miteinander zusammenhängen
– SCORM-Metadaten
Metadaten für            Zweck
Content Aggregation      − Auffindbarkeit ermöglichen
                         − Information über das Inhaltspaket als Ganzes bereitstellen
Content Organization     − Auffindbarkeit innerhalb eines Repositories ermöglichen
                         − Information über die Inhaltshierarchie als Ganzes bereitstellen
Activity                 − Zugriff auf eine Aktivität (Auffindbarkeit) innerhalb eines Repositories
                         − Beschreibung einer Hierarchie von Aktivitäten
SCO                      − Auffindbarkeit und Wiederverwendung ermöglichen
                         − Beschreibung eines SCO
Asset                    − Auffindbarkeit und Wiederverwendung in der Produktionsphase
                         − Beschreibung eines Assets



S. Schubert                                                                                     5/6
Formale Regelungen zu Manifest und Inhaltspaket
– Manifest
   • Manifestdatei trägt den Namen imsmanifest.xml
   • imsmanifest.xml, benutzerdefinierte Strukturen / Erweiterungen (soweit in XML) sowie alle er-
      forderlichen Kontrolldateien zur Überprüfung der XML-Dateien (z.B. DTD) befinden sich im
      Wurzelverzeichnis des Pakets
   • alle Anforderungen der IMS Content Packaging XML Binding Specification werden eingehalten
– Inhaltspaket (Content Package)
   • Austausch als Package Interchange File (PIF) im Dateiformat konform mit RFC 1951 (z. B. ZIP-
      Format)
   • enthält Manifest und alle lokalen Komponenten des Pakets
   • externe Dateien mittels Uniform Resource Identifier (URI) referenziert




S. Schubert                                                                                      5/7
5.2 Run-Time Environment (RTE)
– Um Lerneinheiten (Content Packages) zwischen verschiedenen LMS auszutauschen,
   benötigt man einen standardisierten Weg (Skripten). SCORM verwendet dafür das un-
   ter Benutzung von JavaScript entwickelte „Application Programming Interface (API)“
   des „Aviation Industry Computer-Based Training Committee (AICC)“.
– Mit AICC wurde ein Datenmodell entwickelt, um Daten der Lernenden (z.B. die erreich-
   ten Punkte, eine andere Repräsentation des Lernstandes oder Präferenzen der Ler-
   nenden) im LMS zu speichern.
→ RTE sind Skripten für:
   • die Bereitstellung von Lerneinheiten (Content Packages) in einem LMS
   • die Reihenfolge der Ausführung von Lerneinheiten durch das LMS
– RTE wird auf dem Server des LMS installiert. Die Servlets (RTE) und die Skripten der
   Lerneinheit (Content Package) ermöglichen die Datenkommunikation mit dem LMS.
– Bestandteile der RTE sind Launch (Start und Anzeige), API und Datenmodell


S. Schubert                                                                         5/8
– Spezifikation von Mechanismen (Skripten)
   • Launch:
         • für Start von Lerneinheiten (Content Packages) mit Anzeige von Lernressourcen (SCOs,
              Assets)
         • SCOs enthalten JavaScript-Funktionen:
                - zur Navigation
                - zum Start des nächsten SCO
                - zum Verlassen eines SCO
                - zur zeitlichen Begrenzung
   • API:
         • zur Steuerung der Datenkommunikation zwischen Lerneinheiten und LMS
         • Zustand von SCO (initialisiert, Bearbeitungsstand, Fehlernachricht) wird an LMS gemeldet
– Spezifikation von Datenmodell: Satz von Variablen und deren Werte
   • zum Verwaltung der Benutzerdaten, die sich aus den Aktivitäten der Lernenden ergeben
   • Benutzerdaten zur Laufzeit: aktuelle Lernziele, Benutzerwünsche, Lernfortschritte



S. Schubert                                                                                   5/9
“The SCORM RTE book describes the Learning Management System (LMS) requirements in managing the run-
time environment (i.e., content launch process, standardized communication between content and LMSs and stan-
dardized data model elements used for passing information relevant to the learner’s experience with the content).
The RTE book also covers the requirements of Sharable Content Objects (SCOs) and their use of a common Ap-
plication Programming Interface (API) and the SCORM Run-Time Environment Data Model.




                 Key SCORM Technologies
                      • API
                      • API Instance
                      • Launch
                      • Session Methods
                      • Data Transfer Methods
                      • Support Methods
                      • Temporal Model
                      • Data Model
                           Figure 1.1a: The SCORM Run-Time Environment Book as Part of the SCORM Bookshelf”

[ADL, 2004c]


S. Schubert                                                                                                   5/10
               Figure 1.2a: SCORM Conceptual Run-Time Environment.

[ADL, 2004c]

S. Schubert                                                          5/11
– SCORM wendet an
   • IEEE 1484.11.2-2003 Standard für Learning Technology
   • ECMAScript Application Programming Interface for Content to Runtime Services Communica-
      tion (ECMAScript = JavaScript)
– Standard beschreibt die Interaktion zwischen Lerninhalt (SCOs) und Anwendungssoft-
   ware (Run-Time Services (RTS) = LMS)
– Interaktion zwischen API-Instanz und LMS wird im SCORM nicht spezifiziert; Ausges-
   taltung ist LMS-Entwicklern überlassen
– “The LMS must maintain the state of SCO’s data model elements across learner ses-
   sions, and the SCO must utilize only these predefined data model elements to ensure
   reuse across multiple systems.” [ADL, 2004c]




S. Schubert                                                                              5/12
Begriffe
– “Learner Attempt – A tracked effort by a learner to satisfy the requirements of a learn-
   ing activity that uses a content object. An attempt may span one or more learner ses-
   sions and may be suspended between learner sessions.
– Learner Session – An uninterrupted period of time during which a learner is accessing
   a content object.
– Communication Session – An active connection between a content object (i.e., SCO)
   and an application programming interface.
– Login Session – A period of time during which a learner begins a session with a system
   (logged on) until the time the learner terminates the session with the system (logged
   out).“ [ADL, 2004c]

“What the LMS does with the previous attempt’s data is outside the scope of SCORM. The LMS may
elect to store this data for historical purposes or for other purposes such as reporting, auditing, diag-
nostic or statistical. The LMS may elect to discard any run-time data collected during the previous at-
tempt. The LMS is only required to keep run-time data for the learner attempt if the learner attempt
was suspended.” [ADL, 2004]

S. Schubert                                                                                         5/13
Application Programming Interface (API)
– “An API Implementation is a piece of functional software that implements and exposes the func-
   tions of the API. How an API Implementation functions should not matter to a SCO developer, as
   long as the API Implementation uses the same public interface and adheres to the semantics of
   the interface. The LMS need only provide an API Implementation that implements the functionality
   of the API and exposes its public interface to the client SCO.
– An API Instance is an individual execution context and state of an API Implementation. The API
   Instance represents the piece of executing software that the SCO interacts with during the SCOs
   operation.
– A key aspect of the API is to provide a communication mechanism that allows the SCO to com-
   municate with the LMS. It is assumed that once the SCO is launched it can then store and retrieve
   information with an LMS. All communication between the LMS and the SCO is initiated by the
   SCO. There is currently no supported mechanism for LMSs to initiate calls to functions imple-
   mented by a SCO.“ [ADL, 2004c]
– “The name defined for the API Implementation is API_1484_11.” [ADL, 2004c]



S. Schubert                                                                                        5/14
– “Chain of Parents of the Opener:
   • In this case, the SCOs and Assets are being launched in a new window and the LMS has pla-
      ced the API Instance in a parent frame of the opener window.
   • The algorithm described in the IEEE standard will determine if the SCO was launched in by an
      opener window.
   • If so, the opener window will be searched for the API Instance.
   • If the API Instance is not found in the opener window, the algorithm determines if the opener
      window has a parent.
   • The algorithm is designed to search the parent window hierarchy until it either finds the API In-
      stance or determines that there are no more parent windows.” [ADL, 2004c]




S. Schubert                                                                                       5/15
Datenmodell




...


Werte dieser Elemente des Datenmodells können mit SetValue und GetValue zwischen
SCO und LMS ausgetauscht werden




S. Schubert                                                                   5/16
                  – “There are two important pieces of data that are required to be in the set of inter-
                    action data, an identifier (cmi.interactions.n.id) and the type of interaction
                    (cmi.interactions.n.type).
                  – The cmi.interactions.n.type data model element is required if the Interaction in-
                    cludes data pertaining to either the Correct Response or Learner Response.
– These two pieces of information are what distinguish the interaction data from other interaction
   data found in the set of interactions (considered the dependencies of the interaction data).
– The identifier uniquely identifies one interaction from another.
– The type uniquely identifies the type of interaction (true-false, matching, etc.).”
   [ADL, 2004c]


“cmi.interactions.n.timestamp
If a timestamp value is available for an interaction but no learner response data is available, it should
be assumed the interaction has been available to the learner but the learner did not respond to the
interaction.”
[ADL, 2004c]


S. Schubert                                                                                          5/17
“cmi.interactions.n.type
Value Space: The IEEE draft defines ten state values. SCORM binds these state values to the fol-
lowing restricted vocabulary tokens:
– “true-false”: The interaction has two possible responses. SCORM requires that the two possible
  responses be either “true” or “false”. No abbreviated versions or alternative forms (i.e., t,f,1,0) shall
  be permitted.
– “choice”: The interaction has a set of two or more possible responses from which the learner may
  select.
– “fill-in”: The interaction requires the learner to supply a short response in the form of one or more
  strings of characters. Typically, the correct response consists of part of a word, one word or a few
  words.
– “long-fill-in”: The interaction requires the learner to supply a response in the form of a long string
  of characters.
– “likert”: The interaction asks the learner to select from a discrete set of choices on a scale.
– “matching”: The interaction consists of two sets of items. Members of the first set are related to
  zero or more members of the second set.
– “performance”: The interaction requires the learner to perform a task that requires multiple steps.
– “sequencing”: The interaction requires the learner to identify a logical order for members of a list.
– “numeric”: The interaction requires a numeric response from the learner. The response is a simple
  number with an optional decimal point.
– “other”: Any other type of interaction not defined by the IEEE draft standard.”
  [ADL, 2004c]

S. Schubert                                                                                          5/18
“cmi.interactions.n.result
Value Space: The IEEE draft defines five state values. SCORM binds these state values to the fol-
lowing restricted vocabulary tokens:
– “correct”: The learner response was correct.
– “incorrect”: The learner response was incorrect.
– “unanticipated”: The learner response was not expected.
– “neutral”: The learner response was neither correct nor incorrect.
– real (10,7): A real number. This result provides the capability of reporting a numeric estimate of
  the correctness of the learner response.” [ADL, 2004c]

“Example “matching”:
– SetValue(“cmi.interactions.0.correct_responses.0.pattern”, “1[.]a[,]2[.]c[,]3[.]b”)
– This is an example of a matching interaction where the correct responses collection has one pat-
  tern. The API method call indicates that the correct response is:
              Source               Target
              1        → matches → a
              2        → matches → c
              3        → matches → b
– The SCO is responsible for understanding the significance of the correct response and its con-
   stituent source/target pairs.” [ADL, 2004c]


S. Schubert                                                                                      5/19
5.3 Sequencing and Navigation (SN)
– Achtung! Annahme eines lehrenden Systems
– Die Reihenfolge der Präsentation von Lerninhalten und von Aktivitäten der Lernenden
   wird festgelegt.
– verschiedene Lernpfade in Abhängigkeit vom Lernerfolg
– Steuern der Reihenfolge
   • Aktivitätsbäume (Struktur von Lernaktivitäten)
   • Strategien für die Reihung
   • vordefinierte Reaktionen auf Ereignisse
– Navigation
   • Auslösen und Verarbeiten von Navigationsereignissen
   • erfordert Benutzungsschnittstelle für Interaktion
   • Definition eines Laufzeitdatenmodells, mit dem ein SCO eine Navigationsanforderung an LMS
      übertragen kann




S. Schubert                                                                                5/20
Beispiele für LOM in SCORM

<lom>
      <general>
            <identifier>
                    <catalog>URI</catalog>
                    <entry>http://www.adlnet.org/content/CO_01</entry>
            </identifier>
            <title>
                    <string language="en">Title for the learning object</string>
            </title>
            <language>en</language>
            <description>
                    <string language="en">Textual description</string>
            </description>
            <keyword>
                    <string language="en">learning object</string>
            </keyword>
            <coverage>
                    <string language="en">Circa, 16th century France</string>
            </coverage>
            <structure>
                    <source>LOMv1.0</source>
                    <value>atomic</value>
            </structure>
            <aggregationLevel>
                    <source>LOMv1.0</source>
                    <value>2</value>
            </aggregationLevel>
      </general>
</lom>


S. Schubert                                                                        5/21
4.2.6.3. <interactivityLevel> Element
The <interactivityLevel> represents the degree of interactivity characterizing the SCORM Content
Model Component. Interactivity in this context refers to the degree to which the learner can influence
the aspect or behavior of the component. XML Namespace: http://ltsc.ieee.org/xsd/LOM
– XML Namespace Prefix: lom
– XML Binding Representation: <interactivityLevel>
– SCORM Requirements: The multiplicity requirements for the <interactivityLevel> element are de-
   fined in the table below:


SCORM Meta-data Application                  Meta-data Multiplicity
Profile                                      Requirements
Content Aggregation                          0 or 1
Content Organization                         0 or 1
Activity                                     0 or 1
SCO                                          0 or 1
Asset                                        0 or 1


S. Schubert                                                                                      5/22
– Data Type: The <interactivityLevel> element is represented as a Vocabulary element (Refer to
   Section 4.2.11.3: Vocabulary Data Type for more information).
– Vocabulary Tokens: SCORM defines the <interactivityLevel> element as a Restricted Vocabulary
   element. SCORM requires the use of the vocabulary defined by IEEE 1484.12.1-2002. The valid
   set of tokens defined by IEEE is: very low, low, medium, high, very high
– These values, inherently, are meaningful only in a context of a community practice. At this time
   the ADL Community has not defined this scale. If the ADL Community wishes to define this scale,
   this information should be brought forward to the ADL Technical Team. At this time, this scale is
   left to organizations to define.
– Example:      <lom>
                     <educational>
                           <interactivityLevel>
                                 <source>LOMv1.0</source>
                                 <value>very low</value>
                           </interactivityLevel>
                     </educational>
                </lom>


S. Schubert                                                                                      5/23