This paper reports on the research conducted by a team from the France-Quebec research project TEEC, and its advances. This team is responsible for modelling and designing of a context gap calculator, the MazCalc. The MazCalc is a computer artifact aimed at measuring the effects of two distinct context with the same object of study. In a Context-Based Teaching project such as the one presented in this paper: Context Modelling is essential in identifying the context parameters needed to include in the design of the context gap calculator in order to predict context differences; At the same time, measurements provided by the MazCalc are essential to guide the design of learning scenarios aiming to produce context effects among learners. The article is divided into three parts. First, the contextual modelling is presented, then we discuss the design of the MazCalc, and finally, we address the challenges of this research, namely: (1) the definition of the didactic context and its modelling, leading to the identification and the prediction of context deviations; and (2) the articulation of this modelling with the specifications of the MazCalc artifact. Context modelling is done using an ontological approach. While the iterative design of the MazCalc in connection with the realization of design experiments is conducted according to the Design Based Research method. At the end, we discuss the next steps to be taken.
Context effects are pedagogical event occurring when there is a clash between student’s conceptions, coming from distinct environmental contexts, and about a shared topic being studied. These effects can arise during communications between individuals involved and it allows them to realize the differences that exist in their conception of a same object depending on the context in which it is studied. Context effects can lead to the construction of richer and more complete conceptions on a given subject. The prior identification of differences in contexts relative to the object of study in the two contexts makes it possible to create collaborative learning scenarios aiming to produce context effects [1]. This model is called the CLASH model [1], and the TEEC project wants to test this hypothesis and validate the model using the Design Based Research (DBR) methodology described in [2]. In order to predict the potential emergence of context effects, a computer artifact was designed to parameterize contexts and calculate their differences. The ultimate ambition of this artifact is to provide input needed for the design of learning scenarios based on the effects of contexts.
Context modelling involves conceptualization, and abstraction; where concepts are specified with their components, properties and relationships among each other. It is, for each iteration of the DBR methodology, the first link in the chain that should produce context effects. The context model therefore, guides the learning scenario which in turn determines the (didactic) design experiments for data collection. It enables the researcher to contrast and contextualize and identify parameters. The first instrument used to model the context is the Meta model (ontology). The second is the context gap calculator which informs the specification of the parameters needed for computing the differences. This paper addresses two questions, then it looks at the challenges of this research, namely: (1) the definition of the didactic context and its modelling leading to the identification of parameters to be used in the prediction of context deviations; and (2) the articulation of this modelling with the specifications of the MazCalc artifact. Furthermore, the context modelling is done using an ontological approach. Finally, the next steps and problems addressed in both the ontology-based context modelling and the design of the MazCalc are discussed. 2
Ontological modelling dealing with contextual issues is a well-studies research topic[3-7]. However, so far, none of already existing studies have met the challenge of modelling the didactic context. The didactic context of a learning scenario is influenced by sociolinguistic, environmental or socioeconomic factors and their subsequent impact in the learning process. The theoretical framework of the didactic context has been described in [8]. In the TEEC project, our focus has been on studying the external context which concerns the impact of the environment and authentic situations on learning.
Vision and purpose of ontological engineering. Although ontology was initially defined by Gruber as “an explicit specification of a conceptualization” [9], other authors have sought to emphasize essential features of ontology that we feel are important to recall. First, we agree that an ontology be “a formal system with an explicit specification of a shared conceptualization” [10]. This means that an ontology is an abstract model of a world phenomenon whose appropriate concepts are identified (conceptualization). The type of concepts used and the constraints related to their use are defined declaratively (explicitly). In addition, ontology can be translated into interpretable language by a (formal) machine. Finally, an ontology captures consensual knowledge, that is, not reserved for a few individuals, but shared by a group or community (shared).
Moreover, when we speak of articulating ontology to the digital artifact design
model, it is to these two definitions that we refer: “an ontology is a hierarchically
structured set of terms for describing a domain that can be used as a skeletal foundation
for a knowledge base” [
Ontological Modelling Process. The goal of this article is not to explain the ontological engineering method used. We rely on the MI2O method [14].
Among preliminary pilots, we selected geothermal energy as a topic that was subject to a detailed analysis [8] and led to MazCalc 1 (1st generation). This created a list of candidate terms. These terms discussed with the team were retained or not depending on their potential to correctly represent the field, that is, to become concepts. At this point, they were inserted into a concept dictionary (Table 1).
Context It is part of Context of study. It is a parameter non-exclusive set of context cluster parameters from various themes. It
was formally called: Family.
Learning Example: geothermal energy, Domain language.
Object of It is related to the learning domain study and theme. It is dependent on the domain but not on the theme. e.g. in the domain of biology, an object of study is “frog”, and a theme is “nutrition”.
Context A set of context parameters defines a parameter context of study (the state of the context). Each context parameter belongs to one or more clusters. e.g.
Property (part-of) Has set of context parameters.
Has set of context parameters.
Relation (is-a) Is a Context.
Is created by someone Is related to a learning scenario.
Is a Didactic Context.
Has one or many Is an External context parameters Context. clusters.
Has one or many Is a (sub) Context of context parameters. study.
Has many Object of Is a Domain study Has one or many themes.
Is a (sub) Domain Has many contexts of study.
Has a list of possible context parameter values. Concept Context gap
Definition In the domain of geology, a context parameter is “type of roc.” It is the gap between two context parameter values due to two distinct given contexts. Context Gap is the result of gap computing.
Property (part-of) Has many types.
Has computed values
Relation (is-a) Is a gap
It should be noted that ontological engineering does not consist of creating a collection of terms (which are polysemous), but rather in extracting the concepts (which are explicit). This is an abstraction exercise that is essential for ontological modelling, and it involves the specification of concepts with their properties, as well as their relationships with other concepts within a conceptual network. In parallel to this process, several versions of an initial conceptual ontology (Figure 1), in the sense of [13], were created using GMOT software [15] and shown to experts in different didactic fields (geothermal energy, socio-history, language/French, environment and sustainable development [ESD]). It should be recalled that four design experiments are context modelling based.
The evaluation of the conceptual ontology was completed through several collaborative activities with different stakeholders. First of all, the ontology was explained to the content experts in order to verify that we had a common representation of the didactic context. Then, we addressed their feedback on the contextual representation of their didactic domain by replacing the ontology concepts by instances taken from the different versions of MazCalc 1 (MazCalc 1 applied to geothermal energy 2, language, socio-history and ESD). We also consulted about the ontology with the analyst responsible for the MazCalc 2 specifications. This third phase’s purpose was to compare the MazCalc 2 class diagram, a kind of skeleton of its database, with the ontology.
Consistent with Tchounikine’s [16] views, MazCalc can be considered as a component of an intelligent tutoring system (ITS) [17] called CAITS, given that CAITS is “a system that works on knowledge,” those specific to setting the context of an object of study in a given context, and “that manipulates symbolic representations.” In this sense, the problems related to the design of the MazCalc are ITS engineering problems. It is therefore from this angle that we approached the design of the MazCalc and the challenges that flow from it.
process was carried out in conjunction with design experiments in a connected classroom with collaborative learning, in order to test it. Several iterations of design and design experiments were set up jointly and informed the knowledge used to guide the project. Four phases illustrating the evolution of the project are detailed here.
Phase 1—Ideation during the GOUNOUIJ project: First design experiment whose scenario was based on differences in conceptions of the frog between primary school pupils in Guadeloupe and Quebec [18].
Phase 2—First iteration of MazCalc: MazCalc prototype, the MazCalc 1. First development of a computational tool in the form of a spreadsheet. This prototype enabled the creation of a learning scenario about geothermal energy during the GEOTREF project [8].
Phase 3—Second iteration—alpha version of the MazCalc: Launch of the TEEC project [2]. Creation of a web version of the MazCalc 2 (alpha version).
Phase 4 — Third iteration — MazCalc Beta version (in progress) : MazCalc 3.
MazCalc 3 Modeling. MazCalc 3 is a web computer tool that has been proposed to calculate the differences between contexts and predict their effects. But to successfully design such a tool, context modelling is very necessary to cover all cases and states of any context. The more detailed and clear the specifications, the higher the quality of the software.
Design specification. The specification definition consisted of describing the actors who will use this artifact (Table 2) and three types of design models: the use case diagram, the class diagram (Figure 2) and the sequence diagrams. The use case diagram showing how each actor is involved in a specific part of the calculator development and implementation. The class diagram shows all the objects that the MazCalc 3 tool will contain. The starting point of our work was to consider the assertion [19] that “the context of the study is described using context objects”. Thus, modelling a study object amounts to modelling a context relative to its object (Table 2).
Actors Actor 1: Cognitionist Actor 2: Expert Designer of the Study Object Actor 3: Specialist of the object of study in its context Actor 4: Instructional Designer
Model an object of study (related to the didactic field); Specify the parameters of an object of study; Specify the properties of parameters; Update the parameters of a study object.
Instantiates an object of study in a given context = create a context; Assigns parameter values for a context model; Add a context parameter Update the values of the parameters.
Access the deviation calculation of each parameter;
Access the result of the global calculation of the difference between the contexts.
Class diagram. The diagram that has caught our attention the most is the class diagram, as we see it as the design model for an ITS [16]. This model is the most important, it is the one that will be used as a comparator with the ontology of the didactic context, and how the two can be linked (see section 4). The object of study is defined by a set of parameters. These parameters are of the “qualitative” or “quantitative” type with “continuous” or “discrete”, “bounded” or “not bounded” values. Each parameter belongs to one or more clusters (families). It can have a list of possible value. A parameter can derive from another parameter [8]. These specifications have been grouped into “Models” and “ModelParameters” tables, as well as their link with the “Family”, “paramfamily”, “paramValueTypes” and “ParamPossibleValues” tables (Figure 2). The table “Models” represents the model of an object of study and not its instance (with actual values). That is to say, Model is the skeleton of an object of study only. The field referenced in the “ModelParameters” table refers to its parent parameter. Here, the model of an object of study is constructed independently of the context to be studied.
The object of study in a context must have only one value for each parameter. Therefore the model is developed to produce to an object of study defined in the “StudyObjects” table, which is relative to a context. This relationship is respected by the link between the “Models”, “StudyObject”, and the “Contexts” tables (figure 2). Each parameter of the model of an object of study must have a unique value among its list of possible values. This value, for each parameter, is stored in the “StudyObjectParameters” table and is extracted from the existing values in the “ParamPossibleValues” table. This explains the link between the “StudyObjects”, “StudyObjectParameters”, “ModelParameters”, “ParamPossibleValues” tables (Figure 2).
MazCal 3 Conception and Implementation. The MazCalc 3 database is created based on the class diagram. It allows to define, via MazCalc 3, all types of study objects independently of the context, which makes MazCalc a generic tool. It allows to create several objects of study, and to instantiate several contexts in relation to a single object of study. In order to calculate the difference between two contexts, we calculate the difference between each parameter of these two contexts. The formulas for calculating the context gap are under discussion.
The MazCalc 3 tool is still under development. And, yet many tasks have been completed. For instance, the database is implemented, but it can evolve according to the evolution of the modelling of the objects of studies as well as the formulas for the gap computing, as stated by the DBR methodology [2]. The main human-machine interfaces have also been created: the one for the generation of models, one for the definition of parameters and their value types, one for the definition of all possible values for each parameter as well as the instantiation of contexts with respect to the object of study. 4 4.1
On the one hand (Challenge 1), we had to model to understand what is meant by “didactic context” in order to serve the needs of the TEEC project, i.e. to measure contextual gaps. Starting from the concept dictionary (Table 1), we now wish to give an overview of the discussions conducted to reach a consensus during the modelling. Especially around terms which have been difficult to define such as the term “Family”.
For some members of the Modelling team, “Family” was understood as a theme, a learning area, or a scale. But, for others, it was seen as a grouping of context parameters. For them, the concept of “Learning Domain” which is a well-defined concept, could not be associated with “Family”, since in an ontological view, it is quite clear whether a term corresponds to a concept or not: one tries to construct the specification with components, properties and relationships, and if one does not succeed, then this term probably does not have the status of a concept in this ontology. Thus, if the term does not pass the test of conceptualization, this is probably because it is already taken into account somewhere else with another label.
Let us take the case of the design experiment “Language”. This experiment is experimental in the sense that it is more difficult than others to quantify in order to calculate the differences in context. Thus, we encountered the problem of representing the “quantification” of context parameters in order to calculate the context gap.
Other very beautiful problems of transposition of theories into models have also arisen. For example, the “oral nature of the narrative situation” cannot be modelled as a sub concept of “Intrigue”. We must therefore find another idea to place orality in ontology. To better understand the problem, let us try to explain it differently: in ontology, we have the concept “object of study”. In the case of the didactic situation Language, perhaps the object of study is “the story”. For the “object of study” concept to respond well to the principles of ontological engineering, a sub concept of the “Object of study” concept would have to be created. Concept = Object of study= tale; o Subconcept = oral story (=orality, event, actors, space-time dimensions, unforeseen); o Subconcept = written story (=document, whether or not a transcription of the oral story).
With this example, we see that we can, in the written tale, make a reference to the oral tale. It must therefore be included in the ontology so that it is representative of all possible cases of the target domain to represent. The two previous examples clearly show the similarity between the modelling problems of the class diagram and those of ontological modelling. This brings us to our challenge: articulating these two types of resulting models. 4.2
On the other hand (Challenge 2), we had to define and model the design intent of the artifact [16]. This is software engineering work leading, among other things, to the production of a class diagram.
(context implied)” class. One of the main problems encountered concerns the modelling of context parameters, the latter leading to the calculations of context deviations. In particular, we have tried to answer the following questions: What defines a parameter? What are its attributes (type, nature, properties)? Should the parameters be prioritized? Should parameter values be differentiated according to their type (constant or variable)? 4.3
Articulate models to understand theory and models to design the artifact (challenge 3) [20]. The difficulty was to completely transpose the “theoretical” model, the ontology resulting from the work of the “Context Modelling” team, to the design model, the class diagram, resulting from the “Context Calculator Development” team. However, we soon realized that we were facing the same modelling problems. Before we spoke, we had encountered problems in representing certain concepts/classes. A concrete example of a common problem we faced was to represent the concepts of “Context parameter”, “Parameter value” and “Possible parameter value”. Questioning each other and sharing our representations has allowed us to improve both models. 5
the Context Modelling team and the design Experiment teams is still to be developed in TEEC. It is a weak link in the TEEC project, which is engaged in a chain of production of context effects: modelling with calculation of the gap and probability of context effects, learning scenarios, experiments and data analysis. Fortunately, with the DBR methodology, we are able to deal with “real life” and learn from each iteration of the production chain for the next.
In addition to the context ontology, we plan to construct a domain ontology for each contextualized domain. Next, the line between the meta-model (ontology) of the context and the domain model must be drawn. Normally, ontology governs models as instantiation, which inherit them. If this is not possible, it is because either the Meta model has a flaw, or the domain model must conform to it.
We also plan to build an ontology of context effects. Next, the line between the metacontext model and the meta-context effects model must be drawn.
developed as an independent tool, and will remain like this until its design and implementation are completed. But ultimately it will be part of a context-sensitive learning software suite (with authoring and tutoring services), and it is the core of the CAITS, a “Context-Aware Intelligent Tutoring System” [21]. The CAITS comprises three main components: The Context-Sensitive Domain Model (CSDM); the ContextSensitive Teaching Model (CSTM) and the Context-Sensitive Learner Model (CSLM). MazCalc will share its results with the CAITS component by connecting with its CSDM; this connection will make it possible to provide the ITS with context effect information which will drive the domain model behaviour [22]. This is why the MazCalc 3 was designed as an API web application (to exchange services to the CAITS), rather than a simple web application.
Ultimately, once the development of the MazCalc is completed, it should be able as well to provide a service to the learning designer to specify and adjust the instructional scenario (Actor 4); and serve as a reference in the analysis of experimental data to validate the CLASH model [1]. Indeed, one of the mandates of the Data Analysis team is to detect weaknesses in the elements of our causal chain that are supposed to produce context effects: the context modelling for each iteration, the scenario, the experimentation, and the data collection device. So, the quality of the MazCalc is essential, since it conditions the other elements. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22.