xAPI Standard Object

1 Initial Problem

xAPI takes into account a wide variety of learning experiences (simulations, collaboration, WBTs, etc.). If primarily one object for xAPI were used with the same icon and the same configuration interface, this would have two types of negative consequences:
• The orientation for users would be limited through the same icon - the icon would be thus meaningless
• The configuration would become unnecessarily complicated for many applications, with the result that incorrect settings could also cause increased support requirements.

For this reason, different sub-objects are being proposed for a display in xAPI, whereby one object should consist of all configuration options in order to display scenarios that were initially intended. This object is called xAPI Basic Object.

Basically, the various sub-objects could also be created via a configuration mask within the administration. However a defined set of objects appears more favorable when it comes to testing and support. In a later step, the free configurability could and should be added via an administration interface. In any case, the xAPI Basic Object provides all the configuration options and could be used as a sole starting point for a step-by-step development with very limited resources.

Another argument in favor of different xAPI sub-objects could be an easier assignment of developments to different service providers who, in some cases, already have relevant previous experience. This could also result in greater consistency when operating with ILIAS.

2 Conceptual Summary

Basically, this object should include all available options, as far as possible, so that unanticipated application scenarios are also possible to be run without restrictions. However, this does not mean that all options intended for xAPI are necessary for the xAPI base object right from the beginning. For starting without too many restrictions, the following basic functions and features are considered as being useful:

• Call settings with specification of the resource, the Activity Id and Key / Secret or Auth Base 64
• Upload Content
• Visual Appearance (Embedded, Current Window, New Window)
• condition for status completed (completed or passed or satisfied)
• Simple tool for capturing statements
• Basic data protection measures regarding restriction of personal data sent to the resource (first, last name, e-mail address)

3 User Interface Modifications

3.1 List of Affected Views

Administration » xAPI/cmi5
Administration » xAPI/cmi5 » LRS-Types
Administration » xAPI/cmi5 » LRS-Usages

3.2 User Interface Details

3.2.1 Administration

Because the xAPI specification does not know commands to delete statements, the solution is to separate LRS data. Learning Locker can create clients for this purpose. These clients might persist for a limited period of time or only for specific content and can be deleted as needed.
When creating an xAPI object, the LRS client must be selected in a first development step. Instead of LRS client the term LRS-Type is used, as it could also be different LRS.
In the administration, the LRS types are managed (LRS-Types) and the usage can be viewed including the last access. This supports the decision as to whether, for example, LRS clients in Learning Locker can be deleted.

Please note: It might be useful to distinguish between Typname and title, but it has turned out to be a bit confusing. Only title might be used.

3.2.2 Add New Item

In the first devellopment step (only xAPI Basic Object exists) the screen after clicking on 'Add New Item' and having selected Content->xAPI/cmi5 looks as follows:

First Screen after after selecting xAPI/cmi5

If further sub-objects (e.g. xAPI Learning Module Object) are develloped, Users should have the choice between others (= xAPI Basic Object with all options) and the specific Sub-Objects, which have a specific Icon (according to it's use for communication, content, assessment) and a subset of all the options which has the xAPI Basic Object. This improves usability in two ways: It is easier to add objects and because of the customized icons, orientation is easier for users. I wohld call the Sub-Objects 'Type' similar to SCORM Learning Modules.

Settings: Selecting LRS-Type

Only LRS-Types which are available for creation of objects are shown.

Settings: Options to start object

Settings: Options for display object

Settings: Options for data protection

Note: Default values are set via Administation->LRS-Types. It might be useful that users don't have choices to change settings here. Administrators should have the option to make setting for data protection not changeable.

Settings: Option for data reports

If option is selected a further option to add a link e.g. to Learning Locker Reports is shown. This link gives additonal information to the statement view which is displayed in a separate tab. Until now Users must have the right "View learning progress of other users" to see the statement view and data reports.

Options for Learning Progress

Note: Further feature requests are available for Learning Progress to be develloped in future steps:
xAPI: Avoid the deterioration of the achieved learning progress
xAPI: Configurator for determining Learning Progress

3.3 New User Interface Concepts

No new interface concepts.

4 Technical Information

The concept uses xAPI: LRS proxy. Technical implementations for the LRS proxy are described there.

5 Contact

• Author of the Request: Kohnle, Uwe [ukohnle]
• Maintainer: Kohnle, Uwe [ukohnle]
• Implementation of the feature is done by: Kohnle, Uwe [ukohnle], Schneider, Stefan [sschneider], Heyser, Björn [bheyser]

6 Funding

If you are interest in funding this feature, please add your name and institution to this list.

• DoD NL

7 Discussion

Kunkel, Matthias [mkunkel], 15 JUL 2019: Thanks for this feature suggestion. Some questions from my side:

• Screenshot 'LRS-Type Setting 1/2' in 3.2.1 says that only Learning Locker is supported as LRS-Typ. But on the screenshot above I can create several LRS-Types. I do not get this matched.
• Concerning supported learning progress status: am I right that "in progress" won't be supported? Is this a good idea? Don't we always have the requirement of knowing if a learning activity has already been started by a learner to intervene in case it has not been started yet?
• You do not want a "Passed" LP status for xAPI, right? Even if the connected external activity is something like a test (who supports "Passed" and "Failed".
• Can an xAPI basic object be a precondition for getting access to another object?
• What do I get when I export a course or a container that contains an xAPI basic object? And can I import it again?

Kohnle, Uwe [ukohnle], 22 JUL 2019: Further Question: Why do you need more than one LRS and why is the setting of the LRS bound to the object? Would not it make more sense simply to be able to enter a single LRS in the administration, which will then be passed on to the respective objects?
Answer: It does not need the support of multiple LRS types in every situation. In practice, however, there are good reasons for this:

• an already used application scenario determines that the content provider specifies the LRS specifically for the content it offers. This LRS is therefore not available for other objects.
• Test environments can be set up.
• Access to statements can be customized for the application scenario.

JourFixe, ILIAS [jourfixe], 15 JUL 2019 :  We highly appreciate this suggestion and schedule the feature for 6.0 with the following modifications / extensions:

1. Please consider to relabel this object as "xAPI Standard Object" to prevent that people think only basic functionality has been implemented.
2. Please remove the key-value "Name des LRS-Typ". No need for this information here. Please clarify in the feature description that every xAPI-compliant LRS is supported.
3. The question of custom icons for xAPI objects should be tackled in a separate feature request.
4. Please clarify in the description that the status "in progress" is supported. This status is set when the first user interaction has been reported by the activity object.
5. Learning status "Failed" should be supported as well. Please add sub-options for the related LP settings.
6. Object typ should support preconditions. ilConditionHandling should be used to trigger preconditions based on learning progress status.
7. The type selection should be moved to the create screen and could not be changed afterwards.
8. There should be notices for users at the Info page when "External LRS" has been tackled.
9. Please hint in the by-line, where "Hinweis an Benutzer" and where "Beschreibung" is displayed
10. Please clarify in the description that the data-protection-settings target the LRS as well as the Tool-Provider.
11. Please introduce a third option for user identification: "External ID". This requires an method to transform the external ID in a e-mail-look-like string.
12. Instead of the suggested "UserID+URL+Client"-ID we prefer to have a "User-ID + NIC-ID" string.
13. Please remove the section "Settings: Options for data reports" and handle this request in a dedicated feature request.
14. Please remove the height and width settings from the new window option.
15. Please clarify the RBAC permissions to be used, especially the ones that are not covered by the guideline for default permissions of a new object type.

8 Implementation

{The maintainer has to give a description of the final implementation and add screenshots if possible.}

Test Cases

Test cases completed on 2019-12-08 by Kohnle, Uwe [ukohnle]

• 32080: Einstellungen zum Datenschutz werden auf Info-Seite angezeigt
• 32131: Einstellungen zum Datenschutz werden beim Aufruf der Ressource berücksichtigt
• 32131: Einstellungen zum Datenschutz werden beim Schreiben von Daten in LRS berücksichtigt
• 32133: Benutzeridentifikation 'Externe Benutzer-ID' ist wählbar wenn externe Benutzer-ID verfügbar
• 32134: LRS-Typ und xAPI-Objekt anlegen/bearbeiten mit unveränderlichen Datenschutzeinstellungen
• 32135: LRS-Typ auf 'nicht verfügbar' setzen und xAPI-Objekte deaktivieren

Approval

Approved at 2019-11-26 by Bakker, Onno [onnobakker].