Campbell - Content Aggregation Issues

John has nailed the problem on our existing practices for content aggregation in SCORM 2004 - the trend line for "size" (number of files and bytes) is headed for a train wreck in impacting LMS performance, increasing content development time with complicated and unnecessary work around and increasing the downstream cost for the maintenance of content as well as unnecessary versions caused by bureaucratic practices.

I like John's idea of "breaking content packages into pieces" and his concept of "resource packages". As a potential solution, I was reminded of some work that Dan Rehak had done with Nina Pasini Deibler and Bill Blackmon on CORDRA and unique identifiers. Dan, Bill and Nina had taken reference material/resources (technical manuals and Field Manuals) associated with a SCO, gave them unique identifiers and then placed them in a registry and repository. At run time the SCO dynamically found the resource and displayed it in the browser as part of the SCO. This solved the problem of hard coding a URL link that ends up broken or reference materials that change and then require a rework of the original SCO.

The down side of this approach is that it requires a registry for the resources unique identifier and that the user has permission to access the resource's repository. An implemented single sign on (SSO) and implementation of CORDRA, should mitigate these downside issues.

I see two ways for the standard to address this issue.

The first would touch on what John, Don and Frank suggest and essentially force LMS's to implement some kind of registry and repository functionality. When new content is imported, it can reference identifiers of resources it expects to already exist in the LMS and it would then be up to the LMS to include these in the imported package.

The second solution might lie in solving the cross domain problem thus allowing content to all live in once place and be reused in many different contexts simply be URL reference.

I have two related comments to make:

 1) When content has to be physically delivered from point A (e.g., content publisher) to point B (e.g., content services provider or LMS, etc) then it would be great if SCORM2 would also look at this request-for-enhancement as well: http://www.letsi.org/letsi/download/attachments/327693/02012008+CA+Workshop+Shota+Aki.doc. This paper discusses a need for allowing multiple content packages to share a large resource (like a fat client) without having to have a copy of the resource in each package.

2) When content does not have to physically delivered, see references to Referral Objects in  http://www.letsi.org/letsi/display/nextscorm/Aki+-+OLSA+Asset+Integration. Essentially Referral Object are about just passing URLs to content as mentioned by Mike in the previous comment.

Thanks

An interesting exchange. I agree that a course should be separable from its content. Doing this should naturally include sharing resources among courses, for a course can be the only course "sharing" its own resources. The objective is to separate the course structure and sequencing from the resources. The problems are much the same.

 Manifests can be made that contain only resources. This method has been proposed in IMS for shipping around learner profiles in bulk. The same thing applies to any "bulk" materials. The problem, as noted, is addressing the content. The Resources element in a manifest contains an attribute of "base" providing a directory offset to resources. Could this be a variable? Could it be an indirect pointer? Then only the external indirect pointer needs to have its base value changed. A "smart" LMS could pre-fetch for performance if the content is off site. One might also consider the use of (sub) manifests to ship content that is included by reference at the LMS. Again, (sub) manifest can be located elsewhere. They are a natural way to reuse structured course chunks. A problem is that there is poor support for (sub) manifests just when they are needed. I don't know why they are hard to support. (sub) manifests fit a rough pseudo-object model.

 Versioning will always be an issue when content is shared.  Perhaps this can be accommodated though an external base value, too.

The use of base: just a thought.

 --Tom

I have a problem, but no solution. Cross domain, URLs with the content to be fit into a framework - - none of this will work within the DoD security settings. There are plenty of ways to connect across the Internet, but many of those methods will never be allowed on a DoD Network.

And don't think this only a DoD issue. Network security is a Money Issue for Business.

So the paper's more limited solution is for an LMS to also be a fully functional LCMS, thus allowing content within the Product to be referenced and used.

I agree with the last 2 posts. In my ideal world, content would not need to be "packaged", nor uploaded to the LMS.

Although the content needs to be controlled and tracked by the LMS, the requirements of the content - I guess I should call it the "resources" actually - are not aligned with the needs of the LMS application.

"Packaging" and uploading the manifest may make sense, but uploading the content doesn't really, since that often needs to be an application or combination of applications in its own right.

LCMS's are ok, but in my experience, the instant we choose something standard to use, someone comes in the next day asking for something that requires another tool or custom development.

Also in my fantasy world, the entire cross domain issue would be eliminated, at least on "friendly" servers, using some kind of standard policy file or other means of telling the server and all browsers to trust the content.