Forum .LRN Q&A: SCORM runtime environment and IMS Simple Sequencing

Hi there,

For the past week of so, and given some of the tracking functionalities we have implemented on LORSm v0.2, Matthias Melcher and I have been discussing about the differences between SCORM runtime and other IMS specifications.

In order to invite others to the discussion -and hopefully to learn from each others needs and experiences- Matthias has asked me to post it on the forums. So here we go:

In terms of run-time environments, there's a quite a difference between IMS and SCORM. First, IMS doesn't provide one 😊

The pseudo-delivery environment that LORS has, it is based on the structure of content that is given in the imsmanifest.xml file, but IMS doesn't have (as far as I know) specifications on content delivery.

SCORM, however, does have a runtime environment based on AICC (Aviation Industry CBT Committee). That runtime environment specifies clear definitions on how content must be sent to the user, how it is to be sequenced and what variables must be passed from the server to the user.

For instance, is very common that in SCORM courses, you (as student) don't get access to the course structure. Usually the server sends you the first SCO, once you are done with it, then it send you the next one. But you don't get to "jump around" as we do with LORS between different content pages or units.

Now, since SCORM defines strict rules to runtime environment, content (webpages, flash animation, etc) must also include an interface to this runtime environment. So when you design a SCO, your content must contain (usually) a javascript that searches for the API (adapter) to
communicate with the server.

Now, having said that, what's the benefit of using SCORM compared to IMS? Well, it really depends on what you are deploying a course for. Usually SCORM courses are self-paced and meant to be used by single users to go thru online content in a specified sequence. (this is simplifying it a bit though). The SCORM runtime environment has quite a
number of variables that you can use: for instance, you can track down each student and their progress thru out the course, how long have they spent in each SCO (learning object), how many times have they seen it, whether they have "passed" the assessment for that SCO (so then the server can deliver the next SCO or sending back to the beginning), etc.

SCORM is a bit more rich in that sense, but again, these are things that I believe you can still do while implementing this functionality on your LMS. For instance, I've implemented some tracking capabilities for LORS. Of course, now with the aim of replacing SCORM runtime environment which is an e-learning standard in itself.

I hope that helps.

Ernie

Hi Matthias,

Thanks once again for your quick reply.

>In terms of run-time environments, there's a quite a difference between
>IMS and SCORM. First, IMS doesn't provide one 😊

Runtime in the more narrow sense - ok. But one may think of is just
a DELIVERY entity that acts "at run time"

Yes, after reading yout comments on IMS SS, I think you are absolutely right.

I think I was understanding delivery as "delivery environment".

But you are absolutely right in the sense that IMS SS does specify sequences and conditions for this sequences to ocurr within a delivery environment.

I still don't get rid of the impression that Scorm DOES have a slightly
different focus (more client - server division of labor than just on the
browser-to-webserver basis, more sophisticated production tools
necessary),

Yes, that's correct. In addition, you might want to take into account why SCORM wants to have such environment for delivering content and it has to do (I believe) with the fact that want to make sure their content runs in "every SCORM runtime environment" regardless whether the medium (a cellphone, or any type of browser as long as it has an applet that acts as underlying communicator between the browser functions (usually on javascript) and the back end server.

so I don't think we can say, IMS leaves the delivery
up to the competitor standard.

Yes, that is true. However, it is kind of difficult to me to put them both at the same level. SCORM uses IMS SS now (in version 1.3), so it is entirely based on IMS SS for the conditions of delivery of content.

However as you quoted before, IMS doesn't specify the underlying delivery mechanisms (which SCORM took from AICC)

Thanks,

Ernie

Hi Ola,

In fact, SCORM essentially just adds a strictly specified front-end
to IMS Simple Sequencing, which mandates a javascript client called
"runtime environment".

Yes. However, that is partially true.

SCORM uses an API adapter on the client side not just for IMS SS
purposes but also to manage most of its interaction between the user and
the course content. For instance, on startup the content looks for the
API adapter (which it could be a javascript, an applet, activeX, flash,
or whatever) to initialize the course delivery. Then the content "talks"
to the LMS only thru the API.

While it is correct to say that the API tracks the student progress and
delivers the content following the course sequencing, it also passes
score results, information about the user, etc back and forward from the
LMS and the user.

2) There is no reason to build this spec into the LORS package, since
simple sequencing isn't necessarily dependent on learning objects
being stored in this or that package - the simple sequencing package
has to be integrated with Assessment, too, for example.

Yeah, that is right. That's why LORS is a library of IMS specifications
(so far IMS CP and MD) available for all packages to be used.

Back in May 2003, I suggested you to do the implement IMS SS as a
library so other applications could make use of it, and this was your
answer:

Ernie: To answer your questions - no, I don't believe there will be a
public API to the simple sequencing engine. Since there is no
obvious client to the SS engine besides the Curriculum package, I
think it's quite clear that SS could as well reside within the
Curriculum package borders.

https://openacs.org/forums/message-view?message_id=102631

So, I'm happy you have changed your mind 😊

Do you think we can have an API for IMS SS soon?

Ernie

Malte,

Yes I was thinking outside integration through service contracts. The assessment package will have to be able to communicate a student's test result to the sequenced curriculum package. So I view the sequencing package as the client in this case. As Stan and the rest of us figured, it doesn't seem right to have Assessment using SS for its internal sequencing of its questions. SS is not a general sequencing service.

Ernie,

Regarding what I said over a year ago, you should have commented there and then if you didn't agree 😊 Anyway, it is still true that there is no need for a public API until someone develops a second "curriculum front-end" to SS in addition to the one that the SS package itself will have. If, however, you or anyone else decide to go ahead and build a client-side UI according to the SCORM standard the SS API will of course be made public, either by opening the SS Tcl API or by implementing service contracts.

As for LORS being a library for IMS specifications ... I'm sure the two specs that are in there are needed to make LORS the learning object repository that it is. This doesn't mean, of course, that it's motivated to put all present and future implementations of various IMS specs in there. In the case of the SS spec we actually have in mind building a separate package (which may or may not end up being split into several packages) with its own UI for designing sequences and also a navigation UI (toolbar) which will persist throughout your sequenced journey. Because SS will be made up of these integral parts and will not be a strict service it is not well suited to be contained in another package.

It appears to me you want to turn LORS into a "super package" covering all IMS and SCORM related features. I don't think this would be such a good idea. It would be better, I think, if LORS remains what it says it is: a learning object repository. As far as possible we want to modularize the toolkit functionality and instead assemble vertical applications like .LRN when there is such a need.

Matthias, I agree with you that the basic problem is that the .LRN sponsoring of Simple Sequencing (and Assessment?) is constantly behind the next corner. I can only note that these learning features are still not prioritized by the .LRN funders. However, IMHO, this doesn't justify starting on some half-hearted ad hoc implementation of these standard features (that's not what .LRN needs, anyway).

In the meantime you might want to install Curriculum and have your class admins organize their learning content that way ...

> Regarding what I said over a year ago, you should have commented 
> there and then if you didn't agree 😊

And I did:

https://openacs.org/forums/message-view?message_id=100674

That can hardly have been a comment on what I wrote since your message is dated 6 days earlier. In fact, my posting was an answer to your *question* in your posting (although in a new thread). And you never reacted on that answer.

Even I suggest you a way to implement an open API. In addition, 
I pointed out to you how the fellows from Carnegie Mellon have gone about implementing their own engine:

Yes you did, and I also explained to you why I didn't think it was *needed* to implement an open API. Carnegie Mellon has implemented SS, so what? We already have all the details needed in order to build an implementation from a canonical source, namely the original IMS SS spec.

What will you be sequencing? And why wouldn't this things that you will be sequencing and controling for, 
be acs_objects or content?

The general idea is that we will be sequencing "learning activities" which would indeed be either plain acs_objects or content_items and which would be mapped to one of several things: a learning object in the LORSm, a test in Assessment, or an "auxillary resource" (basically any URL), for example. (It is given by the IMS SS spec that you are sequencing "learning activities" which need to have a bunch of specific attributes that defines the sequencing rules. So you are not sequencing the content per se.)

If implemented like that, then you can abstract it to a point that anyone can
use it.

For instance, take the IMS MD specification in LORS. Any acs_object can
have LOM metadata. Is it needed? For sure not for all objects, but it is
open for people to use it.

The IMS CP implementation can be used by other packages. 

[...]

So basically any package can make use of the IMS specs. AND, LORS is a
set of libraries, that LORSm uses to implement a repository of learning
objects using the IMS specs given by LORS.

However, for some reason, I can't really understand why you think
otherwise about IMS SS.

As I've said before ... I recognize that it makes sense to gather the implementations of *those two* IMS specs in LORS but that the same is *not* the case with IMS SS, and here's why: SS is designed to handle learning sequences. Its rules and conditions are very specific to this purpose (not suitable for use in Assessment, for instance). We intend to build a navigation and user tracking UI (based on the principles of the Curriculum toolbar) which will display universally accross package borders. And, more importantly, We intend to build a central (within the SS package) front-end for designing learning sequences (that is, "curriculums", not courses) where we map content in different packages to learning activities in a sequence, defined as a branched hierarchical tree-structure with sequencing rules. This SS front-end would be canonical because there would be no need for other packages to have their own SS front-ends, specific only to their type of content. The central SS front-end would be able to handle the mapping of all content throughout the toolkit to learning activities. Hence there would be no obvious need for a public SS API ...

> It appears to me you want to turn LORS into a "super package" 
> covering all IMS and SCORM related features.

First, I never said that. Whether they are in one of 10 packages I
really don't really care. What I want to see is e-learning
specifications implemented and any packages being able to use them. One
package, 10 packages, I don't care.

Great. As you can see you will be able to use SS through the provided UI (but not through an API - unless of course you really need that. Then it could be refactored and "opened up").

> I don't think this would be such a good idea. It would be better, I
> think, if LORS remains what it says it is: a learning object
> repository.

I think you are a bit confused:

  LORS = set of libraries that implement IMS CP and MD (no UI)
  LORSm = uses LORS to implement a repository of LOs.

This is what I would like to see:

  LORSm = LORS + IMS SS (from your package) to allow people to deliver
ordered and controlled sequences of learning objects.

OK then, *LORSm* should remain a learning object repository. As explained above, people will be able to deliver ordered and controlled sequences of learning objects but using a general SS front-end instead of a LORSm-tied one.

> As far as possible we want to modularize the toolkit functionality
> and instead assemble vertical applications like .LRN when there is
> such a need.

And that's the whole point! 

But I can't see how you want to achieve modularity if each package has to
implement the same methods and can't reuse them.

As said above, the very point is that each package *won't* have to implement the same methods (SS). As I said to Malte, no other package should need the SS methods for its internal operations. And if a user were to set up a learning sequence mapping only to LOs in LORSm (say) s/he would still use the central SS front-end to do this.

Again, if you don't think you can implement an IMS SS engine that people can
use... well, there's not much choice for us but to do it. 

Your arguments that it can't be done are just not good enough. The fellows from
Carnegie Mellon have outline all the specs for implementing it as an IMS SS
engine (that's the document I sent you over a year ago), so it can be
implemented

Your choice,

Ernie

This is really an amazing insult. I've never said we can't do things your way, I've only said I don't think it would be the right way to do it. We actually think we are able to write a SS package that people can use, but it is still not clear that code outside of SS needs to use it, that's all. You don't convince us with your arguments. You should focus on motivating why there is a need for a public SS API, why LORSm should be turned into a sequencing front-end, why there would be a need for multiple front-ends to SS, why a client-side front-end would be better, why we can't use the IMS SS spec itself as a blueprint for our implementation, etc., instead of trying to distort what we are actually saying.

Hi Ola,

Let me see if I can explain in simple terms what I mean about implementing IMS SS as an open API.

If you would implement an open API, then other packages could do this (LORSm for instance)

A professor uploads a course.

LORSm: "Hey, I just got a course and comes with IMS SS information, I can't quite read it, but I know that Polyxena-SS implementation can."

LORSm: "Hey Polyxena-SS, here's a bunch of XML with the definition for the sequencing course_id 102"

Polyxena-SS: "G'day LORSm, nice to talk to you again -how are the kids?. Yeah, thanks for that sequencing info. No worries. I'll take it from here."

LORSm: "Kids are good, thank you, but it's the steroids that are killing me these days 😉. Thanks for taking care of that. I give you a buzz when I need to render the sequence. Take care"

Then a student (random striker) request the course.

LORSm: "Hey Polyxena-SS, do you remember I gave you the sequence for course 102?, Well, Random Striker wants it so would you mind sending me the correct sequence I need to render?"

Polyxena-SS "LORSm, yeah, I got it right here. For user Random Stiker, all you got to do is to render the following sequence

    1.- Activity1
    2.- Activity2.

At the end of Act2 (which is a question), let me know what he answer since according it we will decide the following sequence"

LORSm: "What would I do without you Polyxena-SS mate?... You really simplify my life so much... really appreciate it. BTW, I heard that you are heading for Texas shortly"

Polyxena-SS "No worries mate, just buy me a beer next time. About Texas,  yeah I'll bring you back a cowboy hat"

Random striker finishes "Act2".

LORSm: "Random striker is done with Act2 and the score was 10. So what's next?"

Polyxena-SS: "Well, according to the score, Random Striker has to take the Act1 and Act 2 again. However, if he would have gotten 50 or more, we would have continue with Act3 and Act4... but oh well, maybe next time"

Same thing could happen with the Assessment package (since IMS SS and IMS QTI can be -but not always- used together).

Assessment: "Polyxena-SS, I need the sequencing for Section 1 of Test for User Random Striker"

Polyxena-SS "Well, Random Striker has already taken Section 1 and can't take it again, so the next sequence is Section 2 and here's the sequence of questions... let me know the answer of q23 as based on it we'll have a different sequencing"

So the implementation of IMS SS could definitely be used by other packages and not just Curriculum. LORSm for instance, won't require from IMS SS to deliver the content, but just specify how content (grouped in activities) is meant to be sequenced for delivery. Therefore LORSm, takes care of the rest.

And this is not only one way, since most likely the IMS SS would require to open IMS content packages. Using the LORS libraries, you can manage CP to extract the sequencing information you need, without having to implement the IMS CP again.

Additionally, it makes sense to implement IMS specifications as libraries because they tend to get updated quite quickly -as demand for new features and functionality increases. If each package has implemented different version of the specifications, then it will be nightmare.

Hopefully, this message explained in simple terms how IMS SS could be implemented and also ease up the tension a bit. I know it can be done, the paper mentioned above from the CM fellows has specs on how they have managed to implement IMS SS as web service, so therefore it should be very difficult to have a look at their experience to implement something  similar for OpenACS/.LRN.

Having said that though, I acknowledge that it is not easy to do so, but if .LRN is willing to fund this, an IMS SS implementation that can be used as a service will be much more beneficial for all.

Ernie