February 10, 2005
Distributed engagement with courses and other units of learning
I've picked up from a few places now an interest in exposing the functions of a course area or course site outside of the 'walled garden' of the LMS. RSS feeds provide a simple way of enabling distributed resources and reading lists, but by broadening the scope of specifications its possible to see how major portions of course functions can be exposed outside an LMS (or similar) as services and consumed by other kinds of eLearning systems. In this post I'll try to set out what should, could, and can be turned into services.
First of all, I'm afraid I'm going to have to introduce a new bit of terminology. From now on instead of courses I'm going to talk about shared learning contexts (SLCs). Courses are a good word to describe a lot of things in formal education, but isn't broad enough to cover similar groups of functionality in informal settings, so this is a new term to cover anything that provides a space where a group of people engage in learning, whether informal or formal, and wether or not there is any sort of assessed outcome.
So what does a SLC typically contain? Well, looking across the range of LMSs, course websites, and the like, I think a reasonable starting list would look like this:
- Timetables and schedules, for example lecture times, exams, tutor availability and so on.
- Blogs and discussion forums, places where you can read and post information with others in the SLC.
- News and announcements from the SLC host.
- Relationship of the SLC to a formal curriculum such as intended outcomes, competencies, accreditation and review information, units this SLC is part of, and units that are part of the SLC.
- Information about the people participating in the SLC, such as students, and tutors.
- Resources such as reading lists, links, and Learning Objects.
- Learning plans, such as Learning Designs, lesson plans, guides, or LAMS sequences.
- Tools like chat rooms, simulations, etc.
- Assessments that can or should be taken for the SLC, such as online assessments and essay titles
- Achievements that a participant has made within the SLC, for example competencies met, goals achieved, and results obtained.
This is quite a lot of features - I'm not sure this is anything like a comprehensive list, but I think it covers most of what the mainstream systems for setting up SLCs can provide.
From this list, its possible to start matching these features to types of services, in this case I'm going to use the ELF to help figure out what the service are, and what technologies can be used.
Calendaring services for timetables and schedules could most easily be represented using iCalendar, an open specification for transferring (and aggregating) calendars.
Both blogs and discussion forums can be represented using Atom. Atom is a useful choice because it has a REST protocol that supports posting to the blog or forum and not just reading the posts. (The Forum box in ELF currently covers both forums and blogs, by the way).
News and announcements is an obvious candidate for RSS. (This service is called Alert in the ELF model).
Curriculum information really doesn't have a home yet, but eventually the CourseInfo work will provide a vocabulary to use here.
Information about Persons can be shared using a number of specifications, including IMS Enterprise Person (either using SOAP, or the REST alternative I posted about earlier), Friend of a Friend (FOAF), and vCard.
Resource Lists are another RSS candidate, or for use with the IMS ResourceList specification, which is better suited to providing references to offline resources such as books and journals. Actual learning objects can be pointed to via URLs in the RSS or RLI, after which perhaps they could be transferred as SCORM packages.
Learning Flow is the ELF term for a learning design or lesson plan; IMS Learning Design is the only real game in town on this one, but an alternative is to point to a HTML or PDF document describing the learning design.
Tools are a tricky one, and I'd be tempted to think of syndicating tools just as an RSS feed pointing to the URLs where the tools are hosted. Similarly, I'd treat assessments in the same way.
Achievements can be exposed for inclusion in the learners ePortfolio using the IMS ePortfolio specification.
So taking all this together, we get this:
Discovery and use
Well, that gives us quite a range of services that can be provided for a course, but how could we discover these services if we wanted to use them? It would make quite a long list of little orange XML buttons!
The IMS Enterprise Services specification provides a handly method that can be used to gather the set of SLCs provided by an organisation; the command readGroupsForPerson will return an array of Group XML records for a given Person identifier; if you're using my REST binding this looks like:
... and will return an array of Group instances (each Group being an SLC). Each Group may contain a whole load of fields pointing to all the service endpoints for the other services of each SLC, for example iCalendar, FOAF, Atom etc.
Unfortunately, IMS Enterprise isn't really set up to contain this big bundle of service links, and so the only way to do this is to use extensions.
An alternative approach is to use web autodiscovery, and provide constructs in the home page for the SLC, as in:
<link rel="alternate" type="application/atom+xml" title="course blog" href="url/to/atom/file"/>
<link rel="alternate" type="application/rss+xml" title="RSS" href="url/to/rss/file">
There are conventions for some of the types of data we've discussed, but not for others, which is a hurdle. We're also assuming that the SLC has a web page where all this stuff can be included in the.
It doesn't have to be all or nothing, however; we can mix and match the IMS Enterprise and autodiscovery approaches, using the IMS Group 'url' field to grab the homepage of the SLC, and then from there use autodiscovery, or put the service links in both the Group XML and the STC page.
Or alternatively, how about UDDI? OK, maybe not :-)
Why would I do this?
OK, so far I've talked about how to turn a SLC into a set of services. Why would I bother? Well, I've got a few scenarios immediately in mind.
First off, consider the case of an employer who has an LMS which is used to manage training courses for employees, but who also sends employees on day release to local colleges and universities for some courses. In this case, it makes more sense for an employee to interact with the university course via the employer's LMS rather than have their training split across two different systems. So this scenario looks like:
Secondly, consider the case of a person who engages in SLCs from a range of sources, including both courses at (multiple) colleges, and informal activities on the web that that a learning aspect. They want to use a single set of tools that they are happy with to engage with these SLCs rather than have to use the systems at each location. There are any number of reasons why this may be desirable, from simple preference of particular tools they like, to specific accessibility requirements, to learning styles supported by specialised tools, such as using topic maps that overlay the information from all these different services. This scenario looks like:
Just two scenarios, I'm sure there are more; for example, this approach may be useful for pulling together an ePortfolio.