Stephen Downes

My first thought was that we could revolutionize education by treating students more like people and less like luggage. Students, for example, could pick their own learning 'destination' (though we may want to provide them with learning 'travel agents' to help them). They could choose their own time and mode of travel, paying for first class if they need the extra assistance and a pillow under their seat or economy if they just needed to get to there from here in a hurry. We could depend on students to find their own way to the learning 'gates' that would lead them to their destination. And while it may be a little more expensive to provide students with the infrastructure they need to make their own choices, the results would be better: they would be far more likely to arrive at their destination of choice instead of, say, Latvia.

But as much as I like my first thought - and I do like my first thought - I like my second thought better. Over the last five years or so we have all been struggling with the need to deliver educational content in chunks through a distributed learning network, an effort very similar to the airlines' handling of luggage. Our conception of a chunk of learning content - or a learning object, as the current jargon has it - is that it is about as intelligent as a piece of luggage. And like a piece of luggage, it sits there in a repository, waiting to be found, waiting to be directed, assembled, placed in its seat in the airliner of learning, waiting to be delivered to eagerly waiting students clumped together around the carousel on the concourse.

Learning objects are like luggage. I don't know if I've seen that exact analogy employed in any of the many papers on learning objects, but the descriptions I have seen suggest the metaphor. 'Digital images or photos, live data feeds (like stock tickers), live or prerecorded video or audio snippets, small bits of text, animations, and smaller web-delivered applications, like a Java calculator' [2] - doesn't this sound like 'socks and shorts, a toothbrush, camera and electric razor?' And doesn't 'webpages that combine text, images and other media or applications to deliver complete experiences, such as a complete instructional event' sound like 'suitcase, carry-on bag and backpack?'

Gerard's 1969 description of how 'curricular units can be made smaller and combined, like standardized Meccano [mechanical building set] parts, into a great variety of particular programs custom-made for each learner,' now cited with approval in contemporary learning object literature [3] points to the fundamentally stupid nature of learning objects as currently conceived, objects so stupid that they could not possibly function without a professional instructional designer and a six-figure LCMS in order to be of any use. 'They must be seen in terms of their place in an architectural hierarchy capable of finding, comparing, and selecting them and then joining them together to perform an orchestrated instructional function that requires more than a single object can accomplish unless it is a self-contained instructional product.'

It seems like a lot of work. In order to use a learning object you must first build an educational environment in which they can function. You need, somehow, to locate these objects, and then arrange them in their proper order, according to their design and function. In certain cases - as for example when the object is a Flash animation or a chunk of streaming media - you must arrange for the installation and configuration of appropriate viewing software. And you're still not finished: the objects must now be delivered in some sort of instructionally appropriate context - a problem solving environment, say, with expert models. Sure, it's a lot easier to do all this with learning objects (indeed, we wouldn't dream of doing it without them), but can't we manage learning without having to build the online equivalent of an international airport? Sure we can. We just need smarter learning objects.

So what would it take? We need to stop thinking of learning objects as chunks of instructional content and to start thinking of them as small, self-reliant computer programs. This means more than giving a learning object some sort of functionality, more than writing Java calculators or interactive animations. When we think of a learning object we need to think of it as a small computer program that is aware of and can interact with its environment. This is the purpose of what the authors of SCORM call a 'wrapper,' a set of 'functions that encapsulate the functionality that an AU might use to communicate with the LMS (Learning Management System).' [4] The idea here is that a learning object is more than just data being pushed around by an LMS, but rather, a piece of computer code that plugs into and actually works with the LMS - or whatever environment it may find itself in.

So how do we move from the concept of a wrapper - which is still pretty primitive - to the concept of a smart learning object? 'Know thyself,' according to Socrates, is the first step on the road to intelligence. As a learning object is being created, it should be created in such a way that the wrapper can learn for itself who the author is, what company or institute the author works for, what day it is, what its name or title is, what format it is, and more. No author should have to type endless fields of metadata; a wrapper, when first created, should initialize by detecting its environment and the nature of its contents. Just as Microsoft Word automatically embeds the authors name, institution, date and other information into each document it creates, so also the wrapper should obtain similar data and create some metadata tags on its own.

When launched, the learning object advances to the philosophy of Rene Descartes, asking, 'what kind of being am I?' A quick scan of the first few lines of content should be sufficient to tell the object that it is a PDF file, or a GIF image, or a Flash animation. It should also be able to find its own size (or dimensions) as the case may be and write a few more lines of metadata. In an ideal world, the learning object would then search through its environment for an appropriate player. If it is a PDF reader, for example, it locates an Acrobat Reader and bundles it with itself. In the same way that a piece of software can be stored as a self-extracting zip archive that automatically installs itself when activated, so also can a learning object become a self-contained executable file that contains everything it needs to run properly.

And so, thus equipped, the learning object is cast into the air (or ether, as it were). From a short list provided, it seeks out the nearest learning object repository. Each learning object repository indexes data its own way, of course (people long having since abandoned the foolish notion of there being one and only one set of metadata standards for the entire world). It identifies the fields required by the repository and then consults the recommended application profile to learn what possible values could fill those fields. The learning object isn't so smart that it can know what those fields actually mean - after all, what is the Dewey Decimal System to a small chunk of code? - but it knows that if it submits to a scan by the library association's auto-summarizer it can obtain legal values for the repository's DD field. It does this for each field in turn - check the field, check the parameters, then access a web service to fill in the appropriate for itself. After a long, laborious process (almost a whole minute, an eternity for a learning object), it generates a new metadata file, checks a copy of itself into the repository, and then moves on to the next repository in the system where the process is repeated.

Once the learning object has checked itself into a few major repositories it goes to sleep. The metadata it generated sits in the repository, ready to generate a response to a request. Since the learning object repositories are networked, a request from anywhere in the system will eventually reach the learning object. Because the learning object generated detailed metadata, it will be exactly what the searcher was looking for. Nudged into wakefulness by the repository, the learning object sends a message to the searcher volunteering its services. It also checks the repository to see if any reviews have been written or whether it has achieved certification, and if so, offers that information to the searcher as well. It makes some enquiries of the user's system. Does the user have any credit with the appropriate commercial broker (if not, then propose a commercial transaction)? Does the user have the appropriate prior learning (if not, generate another request and then go back to sleep).

Serendipity! The learning object is exactly what the user wanted, and the user is qualified to download and run the learning object. Without waiting for any further instructions, it fires a copy of itself to the user's computer. A quick scan: what language is the user using? Spanish? Quick, access an auto-translation service and reconfigure. Next, obtain the user's preferred font styles and sizes, colours and other environment parameters. Then look at the parameters of the request: send your metadata, says the request, to the following program address. Here's what I am! The learning object proudly announces to the system, and when you need me to start up, just send the following command!

Obviously in this short article I have glossed over many of the details. But the main point of this article is to show that, if we made learning objects a little smarter, they could perform many of the tasks we now envision the hiring of minions of baggage handlers to accomplish. There is no in principle reason why we could not develop smart learning objects: if we can write self-extracting executables, self-pacing audio streams, or applications that report back to Microsoft when you use bad words, then we can write learning object wrappers that perform basic self-analytical tasks, scan the web for web services, and learn about their new environment.

What's more, once we develop an architecture of smart learning objects, we are no longer constrained by the bounds of 'supported' data formats. Should a developer want to deploy a previously unused 3-D multimedia file format, the developer need not wait until the learning management system has built in support or until the user has downloaded a plug-in: everything that's needed ships with the learning object. Should developers become dissatisfied with Adobe's or Microsoft's file formats (or pricing structures), they can simply write their own presentation application.

Smart learning objects. So much more than learning luggage.

The article appeared in the April edition of The Learning Place

[1] Attendre le suitcase . . . By Espen Andersen, Ubiquity, April, 2002. http://www.acm.org/ubiquity/views/e_andersen_2.html

[2] Connecting learning objects to instructional design theory: A definition, a metaphor, and a taxonomy. David A. Wiley, in The Instructional Use of Learning Objects, David A. Wiley, ed. http://www.reusability.org/read/chapters/wiley.doc

[3] The Nature and Origin of Instructional Objects. Andrew S. Gibbons, Jon Nelson and Robert Richards, in The Instructional Use of Learning Objects, David A. Wiley, ed. http://www.reusability.org/read/chapters/gibbons.doc

[4] Sample learning Management System - Version 2.0. Advanced Distributed Learning. http://www.flextraining.com/ADL_SCORM_readme.htm