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

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

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:

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

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.

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

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. For instance, I
wanted to export about 8000 pictures I have in a photo-album instance on
a OpenACS 4.6 server I have. Using the IMS CP library, I managed to
export all the content and put it in a content package, than then I can
import into LORS, or even better, I could write an interface for
photo-album so it can process IMS CP packages directly.

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.

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.

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.

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.

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