Home
The Toolkit for Online Communities
17367 Community Members, 0 members online, 2243 visitors today
Log In Register
OpenACS Home : Forums : .LRN Q&A : Adding a run-time environment to LORS

Forum .LRN Q&A: Adding a run-time environment to LORS

Icon of envelope Request notifications

In the past few weeks SII (www.sii.it) has been working on an implementation of the SCORM 1.2 RTE. This should be seen as an extension of LORS (or rather LORS delivery). LORS currently provides an implementation of the Content Aggregation Model (Metadata and Content Packaging), not the run-time environment. We have already received guidelines from Ernie about this implementation and now we would like to share opinions with the rest of the .LRN community...

I think that having full conformance to SCORM 1.2 would be an important achievement for the .LRN project (as far as I know only another open source project can provide a certified implementation today).

Michele Slocovich will soon release the code which is partly based on a work done by Adam Ullman with WEG, which in turn is derived from the CTC implementation published by ADL (Java applet implementing an API adapter).

So far the requirement to have a SCORM RTE was not considered essential for the institutions using .LRN in production. It seems that it would emerge rather in "corporate" applications than in universities, and usually for self-paced courses...

Therefore we intend to have a solution that entails minimal changes in LORS as it is today: the storage of courses (packages) is not modified, but at delivery time a query should identify if a course is composed only of 'assets' (then it does not require the RTE) or if it contains at least one 'SCO' (learning object). Thus, an application which does not need the RTE could easily ignore the extended data model for the RTE.

What will be the possible use cases of the extended LORS delivery?
- record elements set at run-time by the SCO (timing, bookmark, scores, comments...)
- handle sequencing (check prerequisites before allowing a student to view an item)
- assign performance objectives to students
- select user preferences provided by the SCO (language, audio...)
- collect interactions (e.g. answers from students to a test)

Our objective is to meet the requirements defined by SCORM for LMS-RTE3, i.e. to support all mandatory data model elements and all optional elements. However the initial versions will be closer to LMS-RTE1, i.e. support of most of the elements grouped under cmi.core plus cmi.suspend_data and cmi.launch_data (the first features in the previous list).

One of the difficulties in the RTE implementation is related to the interaction between the SCO and the LMS done through an API Adapter which requires some Javascript calls (although the API Adapter itself may be written in Java). This may limit the portability across different browsers. We are still running some tests but we hope to come up with a solution at least for IE and Mozilla.