Comisión Régimen Interno de fecha 21 de agosto

To create a corresponding activity in a targeted VLE, like Plone1 _{or Moodle}2_{, a scenario} has to be “operationalised” to create an activity that will be executed. LDI is in charge of the operationalisation and the execution of the scenarios written in LDL. We have extended it to take into account the developments described above: the modelling of the activity supported by the services and the inferred LDL enhancement (the use-pattern concept).

The operationalisation and execution phases and their evolutions are presented in the following two sections.

4.1 Scenario operationalisation

The following steps describe the operationalisation phase of a learning scenario in which services are only referenced by their type. When the targeted VLE is chosen, this phase consists in:

• creating an activity from the scenario (this is a kind of instantiation);

• choosing the participants and attributing to them the roles foreseen by the scenario

(for instance, the role “learner” will be attributed to Paul, a student);

• selecting the services and contents required by the scenario with regard to their type

(for instance, the URL of a document to be read by the learners is given).

The operationalisation phase of “enriched learning scenarios” is more complex. In more detail than previously, figure 3 shows all the transformations of such an “enriched scenario” written in LDL. The steps are:

• Scenario rewriting: this consists in « exploding » the references to the re-used

patterns of service in the “enriched learning scenario”. The re-used structure and/or interactions from the referenced patterns are included in the current scenario.

• Instantiation: this consists in reifying the scenario. Its object representation is created

and initialised to build an activity.

• Initialisation: it is made up of three steps (cf. figure 4):

• Populating the activity: designating the participants and attributing their

roles.

• Location of the activity: “real” services have to be chosen in the knowledge

of the targeted VLE,. This requires a dynamic discovery of the adequate services available in the targeted VLE, i.e. those which support the corresponding activities modelled in the scenario. Then mapping tables are

1

http://plone.org/

2

built matching the concepts defined in the scenarios and the corresponding ones of the chosen service:

• scenario roles are mapped to the corresponding ones in the real

service and the method to initialise them is given;

• scenario arenas are mapped with the objects defined in the real

service. For instance, for the forum named PloneBoard in the Plone environment, one mapping is: the arena “comment” specified in the scenario is mapped to an object of type “PloneboardComment”;

• to each observed position, the corresponding method to be called to

obtain its value is defined. For instance, in the model of the moderated discussion activity, the position “the number of messages to moderate” is obtained by calling the method “Get_nb_to_moderate” of PloneBoard.

For the moment, service discovery is static and done “by hand”, as is the building of mapping tables.

• Instantiation, initialisation and configuration of the “real” service:

• An instance of the selected “real service” is created (an existing one

could be re-used) ;

• The roles and the associated rights are given to the corresponding

participants.

• The service is configured. For instance, for the moderated discussion

activity, the moderation features of the real service have to be activated if it is not done by default.

Christian Martel, Laurence Vignollet

Figure 3: The scenario life cycle

4.2

The activity execution

Afterwards, the execution can take place in the targeted VLE. For that purpose, the LDI infrastructure includes a player (equivalent to SleD1 for Copper Core) which allows each participant to interact with the others via Internet by using the services and the contents prescribed by the scenario.

1 http://sled.open.ac.uk/web/ Metamodel LDL Scenario LDL Scenarios specifying services Extended LDL scenario (including scenarios specifying services) Activity (object representation) Initialised activity Trails of the activity Activity running Uses Is conformed to Rewritting Instanciation Initialisation Start Produces Model of services Uses Conception Operationalisation Execution

Figure 4: Activity initialisation during the scenario operationalisation

5 Conclusion

The approach described in this paper attempts to address a paradox in the learning design field: the activity mediated by services can neither be prescribed nor observed. The proposed solution consists in re-using LDL to specify the activity supported by a service.

Following this approach, services that are used often can be modelled to constitute a collection that the learning scenario designer could re-use. The authors of LDL propose to add to the language the conceptual means to allow a reference in a learning scenario to an existing service activity model and its contextualisation. They have also extended LDI with the infrastructure in charge of operationalising and executing the scenarios. The approach respects SOA principles: the tools are considered as independent services with defined interfaces, which can be called in a standard way, to perform their tasks, without the service having foreknowledge of LDI, and without LDI having or needing knowledge of how the service actually performs its tasks. However, the work described in this paper is very recent investigation and there are obviously obstacles which still have to be overcome. The first of these is service discovery. Finally, the main problem is the automation of the construction of the correspondences between the LDL concepts used to specify the activity, and the APIs of the service which could mediate the specified activity. Indeed, the current APIs of services, which generally comply with WSDL and associated specifications, do not give all the information needed. Of course, LDL description could be used as an API of a service, but that stage has not yet been reached!

Other work seeks to improve the description of the services and their best possible integration in the teaching scenarios, but to date none proposes to re-use the meta- models dedicated to the modelling of the activities. For example, in (Vega-Gorgojo et al.,

Activity (object representation) Localised activity Populated activity Populates Localises

- Designation of the participants - Attribution of the roles

- Finding the model of service - Initialising the mapping tables - Service instanciation - Service configuration

Christian Martel, Laurence Vignollet

2006), they do not re-use IMS-LD, which they use to model the learning activities, but propose a specific meta-model to describe services.

References

Bézivin, J. (2004) ‘In search of a Basic Principle for Model Driven Engineering’, Novatica/Upgrade, vol. V, n°2, p. 21-24.

Koper, R., (2002) ‘Educational Modeling Language: adding instructional design to existing specifications’, Open University of the Netherlands, http://eml.ou.nl/eml-ou-nl.htm. Martel, C., Vignollet, L., Ferraris, C., David, J.P., Lejeune, A., (2006), ‘Modeling collaborative

learning activities on e-learning platforms’, ICALT 2006, p.707-709.

Nodenot T., (2005) ‘Contribution à l'ingénierie dirigée par les modèles en EIAH : le cas des situations-problèmes coopératives’, HDR.

Vega-Gorgojo, G., Bote-Lorenzo, M.L., Gómez-Sánchez, E., Asensio-Pérez, J.I., Dimitriadis, Y., Jorrín-Abellán, I.M., (2006) ‘Ontoolcole: an Ontology for the Semantic Search of CSCL Services’, CRIWG2006, Springer-Verlag, LNCS 4154, p. 310-325.

Vignollet, L., David, J.P., Ferraris, C., Martel, C., Lejeune, A., (2006) ‘Comparing Educational Modeling Languages on a case study’, Workshop at ICALT 2006, p.1149-1151.