When I first saw the title, I have the expectation to see some unique references to the special needs of military education/training. As I read through the article, the use of the word "military" in the three places I can find is completely unnecessary. The statement(s) apply to non-military situations as well.
That said, it is a good overview of the state of "learning object" - some times ago.
I believe that the military, at least the US, has standardised on SCORM. Hence, to the military, we can now narrow "learning object" to SCO - shareable content object in the SCORM palance.
In the SCORM context, the SCOs have solved ONE major interoperability issues: the ability of any SCORM-compliant content to engage a standardised usage tracking via the SCORM communication API with the learning management systems. Of course, any SCORM package should be able to be delivered by any SCORM compliant LMS.
I have solutions to two other impediments of reuse of SCO: the look n feel issue of SCOs in relationship with the new course in which it will be used, and hosting of SCO from machines/domains other than the that of the LMS. (see various papers in Implementation Issues of SCORM)
In a papers, we argued that reuse also depends on the role one takes in the production chain of courses. SCO is not an ideal unit of reuse for developers, but I would suggest it is a good unit for people responsible to assembling lessons into a course. For people responsible for creating a bundle of courses to meet an identified skill gap, finding SCORM courses may be a solution. In this case, the reuse unit is a course by itself.
That is the fundamental problem in finding things. If a repository claims to contain everything, it contains nothing useful. Consider two specialised repositories (assuming that they exist), one stores courses, and only SCORM courses, and the other SCOs. I would expect the schemas for them would be very different, with highly specialised tags and values catering for the need of the special users they each serve. As pointed out in the paper Single Instance Reuse of Sharable Content Objects, there are significant advantages in using a repository to store the SCOs of a course, hence the course repository I referred to above may actually not store any actual SCOs, but pointing to the SCOs selected by the course designers from the SCO repository.
Given the similarity of the underlying software to support resource discovery, there is no reason why an instance of a repository cannot be both a course repository AND a SCO repository. However, this conceptual partition (based on the role of the designer in the course design/assembling chain) be made clear. So, the fundamental problem I was referring to in the last paragraph is a logical/preception/schema issue, rather than a software implementation issue.
Susan Smith Nash also touched on the issue of "modifying learning objects". Again, if we boarden to address the yet-to-be-agreed learning object, we shall be going nowhere. Put in the context of military application, i.e. within the SCORM environment, it is an achievable goal and it also relates to the issue of course maintanence.
SCO is the basic unit of tracking by the LMS. It can be as large as a whole course (if you don't want to know anything about how a student is advancing within the course) or as small as a page. Up to SCORM v1.3, the LMS will only track one SCO at a time for each user (for an instance of a course). So the smallest unit of a SCO is a webpage. It is hardly the best reuse unit for course developer.
Technically, SCORM has solved the interoperability issue of SCOs, i.e. in the smallest unit sense, inter web-page interoperability. But it is completely silence on the interoperability of building blocks within a webpage, intra-page interoperability. I have proposed a "virtual apparatus" framework couple of years ago (and the website has disappeared too) which was based on "liveconnect" and some javascripts to support communications of web page building blocks created by common web-based technology. It has been a couple of years now. I suppose a better method of doing the same thing may be available today.
These are technical level interoperability issues. Nash pointed out that the "educational" and "culture" levels of interoperability have not been addressed. We shall leave for another occasion.
1 comment:
I really enjoyed reading this article and response to my posting on learning objects.
Yes, many issues can be solved through the suggestions you make -- and, you have some excellent insights about the state of SCORM compliancy and the progress that has been made.
I didn't really get into that topic in my article -- I was primarily thinking of "general education" courses delivered to the military. That's the initial promise of interchangeability -- of content -- really falls down.
And -- with the push to include hand-helds and CD-ROM deliverability as well as online, a new can of worms opens up...
Your article is great, and I'd really like to read your other thoughts as well, which further expand the topic.
all best,
susan
Post a Comment