Back

Context Modeling and IMS Learning Design

During the weekend I worked on another technical paper on the architecture of the software I will use in my research. The focus of this paper is on using XML-formatted semantics for smart indicators. For some time I already thought about which standard would be appropriate for that. As I am with the OUNL, IMS Learning Design (IMS LD) was somewhat obvious to look at.

So my question was, how could aggregators or control strategies get modeled in IMS LD. It turned out that IMS LD is almost suitable for modeling strategies and aggregators for my smart indicator approach. As a consequence of the almost-part, it is not possible to model some learning scenarios or support activities using IMS LD. The claim that IMS LD is pedagogy neutral is thus incorrect.

Aggregator related problems of IMS LD

A major problem in modeling aggregators is that IMS LD supports neither data sets nor data lists. IMS LD allows properties to contain only single values (page 47 of the IMS LD Infoset specification). Thus, it is not possible to model rules that depend on data sets or data lists. Through this limitation, one can not time dependent aggregations on sensor information of the same kind. while simple aggregations like counting or summing up can be emulated, more complex operations are impossible to model. One of these operations is pattern analysis on a set of sensor data. Theoretically, one could model a property for each data entry of a data set; however, with very large or even unlimited data sets, this approach is not feasible.

If IMS LD would support data sets as a property type and specify some of the standard operations so they work with data sets as well, they could solve a lot of problems regarding modeling pedagogies that depend on learner adaption.

A second problem is the property handling in IMS LD. IMS LD has global and local properties, each of these two types can be either related to an individual, a entire role, or the Unit of Learning as such. The main difference between local and global properties is that global properties can be considered as constants in the scope of the Unit of Learning.

As a consequence of this limitation, it is not possible to share properties between Units of Learning (UoL). So, either a certain property is internal to the UoL or external to it. There is no way to specify, that certain properties should be exposed to a larger scope. Thus, IMS LD can model only the development of a learner that are bound to the limited context of a UoL. Even if a UoL is nested within another UoL it is not possible to model how the framing unit becomes aware of the results from the nested one.

This is not necessarily a problem for my project, since I can model a complete strategy as a single UoL. Nevertheless, in terms of scalability of learning designs this is a pretty stupid thing.

Understanding Context in IMS LD

What troubles me most with IMS LD on modeling adapation strategies is the limited scope of context the specification has. Not that any of the other specifications has a broader one but with regard to context dependent pedagogical scenarios IMS LD is pretty limiting. Examples for such scenarios are games, location aware training, or time dependent indicators.

Before I continue, I have to admit that probably one of the following examples has a work-around in IMS LD. However, working around any lead to the intended results but most often make life really difficult.

IMS LD is not completely ignorant regarding context, but the specification provides a fairly limited view on context. The only context IMS LD supports, I would call - partly due to the lack of better words - an instance context. An instance is a specific run of a UoL within a IMS LD-player. We can think of this context as of a course that is provided in a class, while the course concept is applied in many classes. Local properties are local to an instance of a UoL and are not shared between different instances.

Beyond this particular context there are three other types of context that - in my humble opinion - are relevant for didactical scenarios. The first type groups spatial contexts. For example a certain room offers a learner a set of learning opportunities (or in terms of LMS LD activities). The second type clusters temporal contexts. For example, for a certain time period certain activities or operations are possible. For example, students may submit their study papers only within the two weeks after a course has finished. Another example coming from my own research are aggregators that should operate only on data that is strictly bound to a temporal context (like in "during the last week"). Finally there are social contexts, which also gives different opportunities to the participants. One example are study groups or communities that define such contexts. Of course the social context can be partially modeled in IMS LD as long as the social context is subordinate to the instance context of a UoL. The other way is not possible.

There are some factors for contexts that IMS LD already allows to model. At least to a certain extend.

  • A context may have a set of possible activities.
  • A context may have a set of rule-sets to manipulate local and global properties.
  • A context can be defined by a set of properties, that might be shared with similar contexts.

Other factors are not considered by the specification. For example IMS LD does not allow contexts to overlap and to interfere with each other; or contexts might be nested but actions within one context does not take effect also in the super-ordinate context.

What needs to be done

In my opinion the properties are the biggest problem. So far, local properties are local to a context and can be edited within the context, while global properties are exposed from some higher level to a UoL.

What is missing are exposable properties, that are accessible from a higher level in order to find out what is actually going on within a UoL. That way it would become possible to model overlapping and interfering contexts.

Furthermore, IMS LD should provide a more flexible context model. So, different types of context can be modeled more explicitly. With regard to non-formal pedagogies or approaches of mobile learning it is necessary to overcome the dominance of the instance context in IMS LD.