Carole Eyssautier-Bavay

Stéphanie Jean-Daubias
email: stephanie.jean-daubias@liris.univ-lyon1.fr

²PMDL: a modeling language to harmonize heterogeneous learners profiles

Our work aim at proposing models and tools facilitating reuse and integration in a same environment and same profiles of heterogeneous profiles. In the research presented in this paper, we address the issue of heterogeneous profiles reuse by actors (human or software) different from their creators. These profiles can be pencil and paper or coming from software, they can be existing or to be created, and we don't know their structure. We adopt a generic approach that consists in a posteriori rewriting profiles to integrate in a same formalism: PMDL profiles modeling language. Throughout this paper, the example of an existing profile is used to illustrate our propositions.

Introduction

This research concerns the reuse of existing heterogeneous learners profiles. In this context we identify three major sources of profiles. First, national and international educational institutions are looking for common representations of data concerning learning activities. This is shown through numerous initiatives around skills frameworks, standardization works or portfolio. Then, some ILE (Intelligent Learning Environments) collect learning information in order to customize the system, to help the teacher or tutor in his follow-up task or to deliver a reflexive learning report to the learner. Finally, teachers collect information, often on pencil and paper, to evaluate learners, to propose individualized activities or to provide a view of the learning process to the learning situation actors. These various needs lead to different models of the individual information related to the learning that we call "learners profiles".

ILE designers and teachers build heterogeneous learners profiles according to each other needs. Currently, there is no generic method allowing to reuse various rich existing profiles -created by other systems, human or not -in different contexts or practices -mixing pencil and paper and computerized profiles. Our research aims to achieve this issue.

This paper first gives an overview on the issue of reusing heterogeneous profiles. Then we present our approach and show the profiles modeling language that we propose.

Heterogeneous Learners Profiles Reuse

We define a learner profile as information concerning a learner or a group of learners, collected or deduced from one or several pedagogical activities, computerized or not. Information contained in the learner profile can concern his knowledge, meta-knowledge, abilities, conceptions or his behaviour.

The heterogeneity of existing profiles, concerning both their structure and their content, makes difficult their reuse in various contexts. The profiles reuse requires harmonizing their structure: it consists in writing the various profiles according to a common formalism.

One way to solve the heterogeneity problem consists in defining a priori a set of information about a given learner. Normalization works have chosen this approach, like PAPI, IMS-RDCEO or IMS-LIP. However, these standards do not provide enough details to describe fine information about learner's knowledge. Moreover, existing standards are focused on storage and exchange of data in order to help in managing educational institutions. This explains why standards are not precise enough to describe learner profiles. Finally, this information is stored as free text making difficult data reuse by a computer system. This is a major limitation of this approach in our context of profiles reuse. Approaches based on ontologies [START_REF] Heckmann | GUMO -the general user model ontology[END_REF] or on the portfolio (Grant & Hubner, 1998) are also possible, but, as other a priori approaches, they require that learner profiles are written in a specified formalism.

Another approach (as proposed in this paper) consists in reusing external profiles within a common framework by rewriting them according to an internal formalism. ViSMod (Zapata-Rivera and Greer 2004) and DynMap systems [START_REF] Rueda | DynMap+: A Concept Mapping Approach to Visualize Group Student Models[END_REF]) allow the reuse of learners profiles built by an ILE. They rewrite on one hand the domain-centric data and on the other hand the specific learner data. [START_REF] Ramandalahy | An abstract modeling of learning environments to ensure tracking of learners[END_REF] propose a model of learners profile, that can be extended if necessary. But taking into account a new item in a profile requires modification in the model and the system. Other approaches are more generic as interoperability system for user models [START_REF] Celik | An Interoperability System for User Models in Adaptive Educational Hypermedia[END_REF], schema conversion [START_REF] Rahm | A survey of approaches to automatic schema matching[END_REF] or user modeling services [START_REF] Conlan | Multi-model, metadata driven approach to adaptive hypermedia services for personalized e-learning[END_REF].

But these different systems are not totally satisfying in the context of various existing learners profiles reuse. First, in order to encourage the integration of learners profiles in teacher's practices, we claim that it is necessary for him to be the major contributor in the whole profiles reuse process. This requires that he can be able to associate profiles he has created with other ones built by other teachers or by ILEs. Moreover, these systems do not adopt a generic enough approach to enable flexibility necessary to treat various rich profiles, as pencil and paper profiles. Finally, by reproducing domain specific data, previous systems do not allow to represent all information existing in learner profiles, such as free text (e.g. a comment), graphs with values suited to the links, or distribution lists.

Our approach consists in rewriting a posteriori the profiles in a common formalism, based on PMDL, the profiles modeling language that we present in this paper, thanks to semi-automatic processes. The harmonized profiles are then exploited in EPROFILEA, the environment we develop in two ways: profiles visualization and personalization of learners' activities [START_REF] Jean-Daubias | A model of learners profiles management process[END_REF]). We operationalized PMDL language in EPROFILEA environment, but it can be implemented in other systems or used in other contexts. In order to propose PMDL language, we first carried out a state of the art (Eyssautier-Bavay 2008). Studied profiles come from research works, marketplace and teachers practices. We have analyzed in depth 24 profiles, selected for their richness and variety. We proposed to classify contained data in five main categories from which we based PMDL profiles modeling language. For this study, we worked with seven teachers, coming from primary school to university and continuing education. The aim of this collaboration was to collect teachers and institutional practices about learners profiles.

General Structure of PMDL Language

Specifications of PMDL language are described in BNF (Backus Naur Form) formal notation. In this paper, in order to help understanding, a graphical notation1 is also given, based on the notation used in some IMS specifications. Figure 1 presents the general structure of PMDL according to the graphical representation.

In PMDL, a profile consists of a name, an ID, a creation-date, a structure part, a data part and an optional note. In a learner profile written in PMDL, its structure and the learner data are described separately. Several learners profiles can then have the same structure, but different data.

structure part consists of one or more general information about a learner: learner-datum. A learner-datum contains an ID (e.g. D1), a title (e.g. "living city") and either a type (in the previous example "string") or an enumerate list, enum (e.g. "Lyon, London, Geneva"). structure part consists also of one or more element. An element is made of a name (e.g. "algebra"), an ID, an optional note and a content. The content can be of four types: components_list, distribution_list, graph and text. These, plus learner_datum, corresponds to the five categories identified in the state of the art. PMDL defined specifications for each one of these categories. In this paper, as an example, distribution_list specifications will be presented.

data part consists of a set of data concerning a given learner, as well as one or more element_p. A learner_datum_p contains an ID (in the previous example: D1) and a datum_value (e.g. "London"). There must be as many learner_datum_p (respectively element_p) as learner_datum (respectively element) previously declared. In addition, for each ID of a learner_datum_p, a learner_datum having the same ID must be previously declared. Identically, for each ID of an element_p, an element having the same ID must be declared in the structure part. The type of content_p must also be the same than the content type previously declared for this ID. To illustrate PMDL specifications, this section presents an example of an existing profile rewritten according to PMDL. Figure 2 is part of MoreMaths profile [START_REF] Bull | Learner Models to Promote Reflection in Combined Desktop PC / Mobile Intelligent Learning Environments[END_REF]) that represents the distribution of learner answers between correct, wrong and unanswered items for components: "Introduction", "Polynomial division" and "Factorising polynomials". Here, each component has been assessed by 10 questions. For "Introduction", the learner had 4 correct answers, 6 wrong answers and 0 unanswered.

An Example of a Profile Rewritten in PMDL

To rewrite this part of MoreMaths profile according to PMDL, distribution_list element have to be used. Indeed, it allows representing the distribution of learner answers between some components: both for structure (figure 3) and data (figure 4).

Figure 3 shows the structure of MoreMaths profile rewritten according to PMDL. The two first lines give the element name (MoreMaths) with its ID (E1) and its type of content (distribution_list). In the MoreMaths example (figure 2), there is only one value linked to each subcomponent ("correct answers", "wrong answers" and "unanswered"). In accordance with PMDL specifications, the tag "number_of_values" precedes an integer, 1 in example . Then, the structure of the components tree  is rewritten according to PMDL specifications. At the depth 1, the components are described with an ID (e.g. E1_C1) and a title (e.g. "Introduction"). At the depth 2, subcomponents are described. leaf tags indicate leaf nodes in the tree. Following these tags, ID (e.g. E1_C4) and title (e.g. "Unanswered") can be found.

Figure 4 presents the data part of MoreMaths profile rewritten in PMDL. First line gives the ID of one element previously declared in the structure part of the profile (in this example E1, i.e. the MoreMaths element). Then, ID of each components declared in the structure part are listed. ID of components which have a depth 1 declared in the structure part (e.g. E1_C5) are followed by the tag "number_of_questions" and an integer. This indicates the number of questions in which the distribution is realized, 10 here . ID of components which have a depth 2 declared in the structure part (e.g. E1_C6) are followed by the value linked to the component in the profile . In the MoreMaths example, for subcomponents of "Introduction", value attributed to E1_C2 ("correct answers") is 4, E1_C3 ("Wrong answers") is 6 and E1_C4 ("Unanswered") is 0, and so on for the two other components. This data part gives the results obtained by the learner in example figure 2.

Specifications of the distribution_list Element

This section presents the PMDL specifications of the distribution_list element used in the previous example. Structure part of the distribution_list element is shown graphically in Figure 5. Due to a lack of space, we don't detail graphical representation of the last element, non_weighted_components_list, but we give its details in BNF below. The first frame of BNF below gives the formal specifications corresponding to the figure 5. A tag "number_of_values" precedes an integer giving the number of values attributed to each component ( in figure 3). sep is a separator to distinguish the different elements. It can be for example instantiated in ";", or "crlf" (Carriage Return Line Feed). In the previous example, it was instantiated in crlf. An optional labels precedes non_weighted_components_list. There are no labels in MoreMaths example. labels is a set of pair <value_number> <label> where value_number is an integer and label consists of a tag "label" followed by a string. A label is used to give sense to the diverse values linked to a component: label "distribution value", label "success rate". This example means that the first value linked to a component is the distribution value and the second one is the success rate of the learner to this component. The frame below gives the BNF specifications for the element non_weighted_components_list which is a list of non_weighted_component ( in figure 3). This last one first gives the depth of the component in the tree of components. If the component is a leaf of the tree of components, a tag "leaf" precedes the component. If it is not a leaf node of the tree, there is no tag and the component is followed by its child nodes, non_weighted_subcomponents. An optional note can be linked to each component. A component is defined by an ID (e.g. E1_C3) followed by a title (e.g. "Wrong answers").

The structure part of the distribution_list element has been presented previously. Its data part will be presented in this section. First, figure 6 shows the graphical representation of distribution list data part: distribution_list_p. A distribution_list_p element may be of two types. The first one corresponds to the case of the values distribution on the components (depth 1), and the second one corresponds to the case of the distribution on the subcomponents (depth 2) (like the MoreMaths example figure 2). In the first case, the tag "number_of_questions" is followed by an integer in which the distribution is realized and by the list of components with their distribution values.

In the second case the number of questions (used to realized the distribution of the learner answers) is linked to the components which have been declared at a depth 1 in the structure part ( in figure 4) and the values are associated to the components which have a depth 2 ( in figure 4). comp_value_p is an ID of a component declared in the structure part followed by a list of values, rep_values. These values are void or integer (a distribution value is a count value so it is an integer). They can be linked to a note.

Concluding remarks

An application framework of PMDL language has been defined. It qualifies which type of information can be described with PMDL: for example, raw data (as log files) cannot be described with PMDL, while analyzed data about learner knowledge can. Ten criteria have thus been defined (raw data, temporality, time spent on activities, learner's behavioral model, peer's data, data from collaborative activities, learner's productions, domain model, relations between the profile items, analyzed data about learner). Then, PMDL language expressive power has been evaluated within this application framework, for the 24 studied profiles, as MoreMaths example presented in this paper.

All of these profiles consisted of at least one learner_datum element in order to identify the learner. components_list element is used in all studied profiles coming from teachers practices or from the marketplace. Indeed these profiles are based on skills frameworks which are lists of components. text element is used in teachers practices to add comments about a learner as well as in several profiles coming from research works (for example to describe misconceptions like in C-Polmile). graph element is used in a few profiles, mostly to represent Bayesian networks. Finally, distribution_list element is seldom used (only 2 profiles among 24). These last two elements only exist in studied profiles coming from research works.

The only data existing in the studied profiles which cannot be described with PMDL are set outside of our application framework. For example, profiles using Bayesian networks (like ViSMod), cannot be rewritten entirely with PMDL: indeed, PMDL allows describing learner data about knowledge, but not about the knowledge model which created them.

Many actors, human and systems, produce information about learning. But reusing and integrating in a same profile these heterogeneous data is currently difficult, particularly when learners profiles that have a rich content, a complicated structure and are different from each other. The platform-independent Profiles Modeling Language (PMDL) we propose aims to solve this problem. Based on a large state of the art, we use a classification of learners profiles data in five main categories to define PMDL. This language allows rewriting various learners profiles created by any systems, human or not. Existing profiles will now be able to be reused in transformations or exploitations purposes. In this paper, we illustrate the rewriting principle with an example of an existing learner profile.

First results of PMDL evaluations are promising for language expressive power point of view. From an operational point of view, we have implemented this language within a profile management system named EPROFILEA [START_REF] Jean-Daubias | A model of learners profiles management process[END_REF]. This implementation shows the feasibility of our approach as it allows the reuse of various heterogeneous existing profiles for profiles visualization and personalization of learning activities purposes. Experimentations prove that teachers can use the main concepts of the operationalized language in order to represent, combine and exploit effective data, digital or not, constituting learner profiles. The BNF formal notation used for the specifications of PMDL makes it usable in various contexts by different software. A potential use of this language is to format profiles as soon as they are created. Indeed, PMDL could also be used as a first proposition for future works on profiles standardization. But it should be extended to take into account evolutivity of profiles [START_REF] Ginon | Evolutive learners profiles[END_REF]

Figure 1 .

 1 Figure 1. General structure of PMDL.

Figure 2 .

 2 Figure 2. A part of MoreMaths profile (Bull et al. 2003).

Figure 3 .

 3 Figure 3. Structure of MoreMaths profile in PMDL.

Figure 4 .

 4 Figure 4. Data of MoreMaths profile in PMDL.

Figure 5 .

 5 Figure 5. Structure of distribution_list element.

Figure 6 .

 6 Figure 6. A part of distribution_list element in Bâtisseur.

In our case, graphical representation is less accurate than BNF notation, but easier for reading and understanding the concepts used.


Blandine Ginon
email: bginon@gmail.com

Stéphanie Jean-Daubias
email: stephanie.jean-daubias@liris.univ-lyon1.fr

Models and tools to personalize activities on learners profiles

In research on the open learner model, more and more ILE offer to learners interactive activities on their profile. These activities are based on the visualization of learners profiles: in particular, it may be a simple observation of a profile, but also the negotiation of this profile content, or a comparison with another learner profile. However, the visualization of profiles proposed by existing ILE is few customizable. In this paper, we present models to personalize activities on profiles, depending on the user type (learner, teacher...), on his knowledge, skills and capacities, but also on his preferences. We implemented these models to provide tools to teachers to prepare personalized activities on profiles; and to provide to each user type a unified environment proposing personalized activities on profiles.

Introduction

A learner profile is a set of computer data gathered from information, computerized or not, about a learner [START_REF] Eyssautier-Bavay | A model of learners profile management process[END_REF]). More specifically, the learning profile of a learner concerns specifically his knowledge and skills, such as his success rate to an exam. The capacities profile of a learner concerns his physical and mental capacities, like his hearing level or the average length of concentration that can provide on a pedagogical activity.

Learners profiles have many uses, which involve different actors of learning. They can be presented to teachers as assessment after an ILE session. They also highlight the strengths and weaknesses of a learner, and, in the case of evolutive profiles they show the progression of a learner. There are several aims for the visualization of profiles. First, visualize his own profile allows a learner to have a reflective approach (Bull & MacKay 2004), to pinpoint the knowledge and skills he should work in particular. What's more, learners become aware of what ILE perceives of their skills compared to their own perception. Some ILE propose a negotiation between the system and the learner about the content of their profile. Moreover, the visualization of learners profiles can help teachers to measure the level and the overall progression of their learners, to define remediation activities for some students in particular, or the class objectives.

Let's imagine this scenario: Alex is a teacher in a class of 5 th grade, he evaluates his pupils using a profiles structure named str_5. Lucas and Olivia are pupils of this class. Alex would like to propose different activities on profiles to his pupils. He wants Leo to visualize his profile, the evolution of his profile and to compare his profile to the class profile. Alex wants Olivia to visualize her profile and to establish objectives. In addition, Alex wants a personalized visualization according to the profiles content, but also to additional information his has. For example, for Lucas, he knows that his eyesight is 7/10, he prefers textual and symbolic representations, and his favorite color is cyan. About Olivia, Alex knows that her eyesight is 10/10, she prefers graphical representations and her favorite color is orange.

State of art

Among ILE proposing a visualization of learners profiles, many have chosen to use a simple and fixed profiles structure. Some ILE represent the structure of a profile as a non-hierarchical list of values. This type of representations would be inappropriate for profiles whose structure contains varied elements. Other ILE propose a visualization of profiles with a hierarchical form, which may be appropriate to more varied profiles structures. Nevertheless, we didn't find any system that allows the teacher to determine what should be viewable in a profile. Moreover, in many ILE, the profiles contain only elements sharing a same scale, associated with the same representation. Thus, for example, profiles of SQL-Tutor and e-Kermit [START_REF] Mitrovic | Evaluating the Effect of Open Student Models on SelfAssessment[END_REF]) contain only percentages represented by progress bars, and profiles of Sam Text Editor [START_REF] Kay | Learner Know Thyself: Student Models to give Learner Control and Responsibility[END_REF]) contain only elements that can be acquired or not acquired, represented by black or white boxes. However, by adopting a generic point of view, a profile must be able to contain elements associated with different scales. Furthermore, elements that share a common scale can be represented in several ways. This multiplicity of representations allows personalization of the visualization depending on the user type. For instance, Subtraction Master, intended for children from 8 to 9 years (Bull & Mackay 2004), proposes to teachers a graphical, numerical and textual visualization of profiles, while it proposes to learners a symbolic visualization of their profile, using smileys. However, the visualization is not customizable based on information about the user (knowledge, skills, preferences...), which would offers two users of the same type a different visualization, adapted to their individual needs.

If more and more ILE propose a visualization of learners profiles, sometimes customizable according to the user type, there is no generic approach that allows teachers to prepare activities on profiles by choosing which elements of a profile will be viewable by which user type and from which ways; this by offering a personalization of these activities depending on the user knowledge, skills and preferences.

Proposition

Our work is placed in the context of PERLEA project, which concerns the personalization of learning through the exploitation of heterogeneous learners profiles. This project adopts a generic approach which notably led to the definition of PMDLe, a profiles modeling language. PMDLe profiles are evolutive: they store information on different evaluation periods.

The work we present in this paper aims to propose a personalization of activities on profiles, depending on the user type, on his knowledge, skills and preferences, and appropriately to profiles with a generic structure described in PMDLe. For this, we propose a model to personalize activities on profiles. This model allows a teacher to prepare activities on profiles by defining views respecting vPMDLe model. A vPMDLe view consists of a set of associations between elements of a profile described in PMDLe and a set of profile elements representations described by rPMDLe model. Each of these representations may be subject to a set of conditions, respecting cPMDLe model of constraints on profiles [START_REF] Lefevre | Adapte, a Tool for the Teacher to Personalize Activities[END_REF]. If the teacher agrees, some representations can reflect the preferences of each user, in terms of colors and fonts among others. In addition, when visualize a profile, our personalization model takes into account user preferences, for example, to select representations that are best suited to a user, among those attributed to him by the view.

Models

A detailed study, conducted both by working with teachers and by a literature review allowed us to define a typology of reflective activities on learners profiles. These activities may concerns different actors of learning: learners, their families, teachers, researchers or institutions. Visualization of profiles must be personalized to these users type. Several categories of activities on learners profiles have been identified. Some activities concern the visualization of the profiles content, like the visualization of his profile by a learner, or the visualization of the class' profile by a teacher. Some activities aim at positioning a learner compared with others. For example, the family of a learner may compare his profile with the class' profile, or institutions may compare two groups' profiles from different regions. Some activities concerns the taken of stand on the content profiles. For instance, a learner can negotiate some element of his profile with his teacher.

Models of profile elements representations: rPMDLe

A learner profile respecting PMDLe formalism consists of a set of elements specified into components. Except for elements of comments type, all components are associated with a scale. This scale can be numeric (a note of 10 or 20, a percentage...), textual graduated (acquired / not acquired, systematically / sometimes / never, ABCDEF...) or textual not graduated (talkative / active / quiet...). In a PMDLe profile, only terminal elements, that is to say elements not containing another element, are associated with a value expressed in the scale corresponding to this element. It is nevertheless possible to obtain a value for a non-terminal element, performing an operation, sum or average, on values of the elements it contains. To enable personalized visualization of such profiles, we defined in rPMDLe representations for each type of scale, for all elements, whether terminal or not, and for comments.

To represent the value associated with an element, we offer three categories of representation: a representation for all types of elements, representations for elements associated with a numerical scale and representations for elements associated with a textual scale. Thereafter, elt is an element of the profile and s is a scale, f is a font associated with a name, a style, a size and a color and dev is a device of another type, for example a sound file or a device for taking account of disability (such as a Braille keyboard). An asterisk after an element indicates it is optional. Examples of each representations type are given in the next section.

To represent all types of elements, we propose a general representation, textual or numerical, noted Rgen (cf. Figure 1). This type of representations is used to associate to an element, and possibly to its scale, the formatting instructions that will be used to represent the value of this element, or the text of the comment. f represents the font and col the background color. The boolean disp controls whether or not we want to display the scale associated with the element; disp must be false if no scale is specified. As for all representations type, it is also possible to associate a set of dev to the representation, to allow for example a reading of the commentary or value of this element by a suitable device. For an element of numerical scale, a numerical representation RnSn allows to define a layout for each interval. A graphical representation RgSn allows associating to each interval a color col, a boolean grad indicating whether or not this color will be gradated, and a graphic object graph (progress bar, thermometer, counter...). A symbolic representation RsSn allows associating to each interval one or more images Img (smiley, arrow, medal...) associated with characteristics: number, size, and color (that can be the default color of the image: def).

Rgen(elt, s*)=(disp, f, col, {dev 0 , …, dev m }*)
RnSn (elt, s) = (([a 0 , b 0 [, disp 0 , f 0 , col 0 , {dev 00 , …, dev 0j }*), …, ([a k , b k ], disp k , f k , col k , {dev k0 , …, dev km }*)) RgSn (elt, s) = (([a 0 , b 0 [, col 0 , grad 0 , graph 0 , {dev 00 , …, dev 0j }*), …, ([a k , b k ], col k , grad k , graph k , {dev k0 , …, dev km }*)) RsSn (elt, s) = (([a 0 , b 0 [,{img 00 , …, img 0i }, {dev 00 , …, dev 0j }*), …, ([a k , b k ], {img k0 , …, img kl }, {dev k0 , …, dev km }*))

Figure 2: Formal definition of representations of elements associated with a numerical scale

To represent elements of textual scale, we offer three types of representations (cf. Figure 3), similar to the three representations types for elements of numerical scale: textual representation RtSt, graphical representation RgSt, and symbolic representation RsSt. The difference between the representations for elements of numerical scale and those of textual scale is that there are n scale levels lev, and not intervals. In addition, to represent graphically the level of a textual scale, it is necessary to specify an integer that corresponds to this level, which is equivalent to convert a textual scale to numerical scale.

RtSt(elt, s) = ((lev 0 , disp 0 , f 0 , col 0 , {dev 00 , …, dev 0j }*), …,(lev n , disp k , f k , col k , {dev k0 , …, dev km }*))

RgSt(elt, s) = ((lev 0 , col 0 , grad 0 , graph 0 , {dev 00 , …, dev 0j }*), …,(lev n , col k , grad k , graph k , {dev k0 , …, dev km }*))

RsSt(elt, s) = ((lev 0 ,{Img 00 , …, Img 0i }, {dev 00 , …, dev 0j }*), …,(lev n , {Img k0 , …, Img kl }, {dev k0 , …, dev km }*))

Figure 3: Formal definition of representations of elements associated with a textual scale For non terminal elements, it is also possible to represent the elements they contain. For this, we have defined in rPMDLe a representations type, noted Rcomp (cf. Figure 4), allowing for example to represent a non-terminal element of a profile by a chart (bar chart, spider web chart, pie chart, areas chart...), examples of such representations are given in Figure 5. For these representations, type is the type of composed representation, dim is an integer representing the number of dimensions (2 or 3), eff3D is a boolean that indicates for a 2D chart if it has a relief effect, bar represents the type of bars (blocks or cylinders) and orient indicates for a bar chart whether the bars will be horizontal or vertical. In addition, tit i is a string that specifies the name of the subtitle i; col j is the color of the serial j, rbgcol is the representation background color, cbgcol is the chart background color, gcol is the grid representation color, pref is a boolean indicating whether or not we allow the taken into account of user preferences for colors, f i is the font of the subtitle i.

Formal definition of conditions on learners using cPMDLe model

The models we have presented allow the creation of many varied representations for each element of a profile, terminal or not. However, to personalize the visualization of profiles for each user, it is necessary to associate conditions to these representations in order not to offer the same representations to all users regardless of their knowledge and capacities. Thus, we will not offer the same representation to a learner who can read and a learner who cannot read, or to a blind user and a sighted user. What's more, representations should allow for example to highlight the positive points of a profile to encourage a learner in difficulty, but also to highlight the points that can still be improved for a learner with excellent results. To allow such personalization, we have identified three types of conditions that may be associated with a representation: conditions on a learners list, on the learning profile and on the user capacities profile. For conditions on learning or capacities profiles, we chose to use the model of constraints on profiles cPMDLe [START_REF] Lefevre | Processus unifiés pour la personnalisation des activités pédagogiques: méta-modèles, modèles et outils[END_REF]. This model allows constraining PMDLe profiles. In the case of a numerical scale, we indicate an interval which the value of the element must belong to. In the case of a textual scale, we specify what should be the level of this element. For example, cPMDLe allows selecting the learners whose score in history is between 65% and 80%, and those who master the skill poetry. Using cPMDLe on a capacities profile will also for example selecting the profiles of users whose hearing is greater than 6/10 and those whose level of use of the mouse is "rarely".

We completed cPMDLe by conditions on a learners list llist (cf. Figure 6), by associating to a set of students l i a boolean inout indicating whether it is a condition of exclusion (inout = false) or a particular condition (inout = true). It is possible to define the conditions ((Julie Thomas), false) which means "all students except Julie and Thomas", and ((Alice), true) which means "only Alice".

Cl(llist)=((l 0 , …, l n ), inout)

Model of views on profile: vPMDLe

To propose to every users type personalized activities on profiles, we need to determine which activities will be proposed to which user type. Moreover, in order to personalize these activities based on visualization of profiles for each user, it is necessary to determine which elements of a profiles structure will be viewable and how. For this, we need to associate to these elements zero, one or several representations, themselves possibly associated with a list of conditions. It should also be possible to rename an element so it appears to the user with another title. For this, we propose a model of views definition, vPMDLe (cf. Figure 7), for a learning profiles structure strLP described in PMDLe, a capacity profile structure strCP described in PMDLe, a user type userT, a learners list llist and an activity act. This model associates to elements elt of the profiles structure one or more representations R, respecting rPMDLe. Each representation R may be associated with a set of conditions C on the learner list, or on learning or capacities profile. An example of view is given in the next section.

View(strLP, strCP, userT, llist, act) = ((elt 0 , R 00 {C 000 , …, C 00k }, … R 0l {C 0l0 , …, C 0lm }), …, (elt n , R n0 {C n00 , …, C n0p }, … R nq {C nq0 , …, C nqs }))

Figure 7: Formal definition of views

Model to personalize activities on profiles

To allow a teacher to propose personalized activities on the profiles for each user, we have defined vPMDLe model (cf. Figure 8). On one hand, vPMDLe allows the teacher to express his preferences for the visualization of a profiles structure described in PMDLe for a users type. These choices represent a view that defines which elements of the profile will be viewable by which users and how (cf.  Figure 8). On the other hand, vPMDLe allows the taken into account of the user choices and preferences. Indeed, according to the view defined by the teacher, zero, one or several representations of an element elt of the profile are enabled for a user. These representations are those defined by the teacher with rPMDLe for this element, and where the potential conditions are verified. Each of these enabled representations is then associated with a priority degree deg reflecting the user preferences (cf.  Figure 8). Finally, the n representations of highest degree are used to represent the element, n is an integer expressed in the user preferences (cf.  Figure 8).

Implementation EPROFILEA environment

We implemented these different models in EPROFILEA environment. EPROFILEA concerns the different actors of learning, even if it is intended primarily for teachers. It contains three parts, composed of several modules (cf. Figure 9).

The first part of EPROFILEA, the profiles preparation, consists to establish the structure of the profiles that we want to handle, before integrating data from external profiles to build learners profiles in accordance with the teacher's wishes and respecting EPROFILEA formalism. PMDLe language is operationalized in Bâtisseur module that allows defining learners profiles structures in a unified formalism. Profiles structures from Bâtisseur will be completed in data integration modules: Prose and Tornade. Prose module helps teachers to enter data from paper and pencil profiles of each of their pupils according to the profiles structure defined in    Bâtisseur. To integrate external software profiles (from outside EPROFILEA), Tornade module allows experts to set up parsers, then to teachers to use this parsers to integrate data from corresponding profiles to profiles respecting EPROFILEA formalism.

The second part of EPROFILEA is dedicated to profiles transformations. These transformations may relate to operations on their structure or their data (Group module allows among others establishment of a group profile from the profiles of learners in the group) or prepare the visualization of profiles (Regards module enables a teacher to define different views on profiles).

The third part of the environment, the profiles exploitation, offers personalized activities on the profiles, with Perl, and personalized pedagogical activities with Adapte. The objective of Perl is to enable interactive visualization of profiles by the different actors according to the views defined by the teacher in Regards. It also proposes to learners, in addition to visualization of profiles, activities on their profiles (rewording, negotiating elements of the profile...) allowing the learner to enter into a reflexive approach in relation to his learning, and so better assimilate and exploit the information provided to him. Adapte module aims to give teachers the means to personalize the pedagogical activities proposed to their students according to their needs based on his pedagogical choices [START_REF] Lefevre | Adapte, a Tool for the Teacher to Personalize Activities[END_REF].

Regards module

Regards module allows the teacher to define views on the profiles for each activity and each user type. For this, Regards implements vPMDLe view model, which assigns to each element of a given profiles structure for an activity, some representations, possibly associated with a list of conditions which may relate to the learners list, to their learning profile or to the user capacities profile. In addition, Regards allows the teacher to define personalized representations respecting rPMDLe.

Let's come back to our example. With Regards, Alex defines several representations. He defines two general representations: Rgen1 and Rgen2, whose definitions are given in Figure 10. These representations are very similar: they make it possible to write text in Arial black on a white background; only the font size varies from one representation to another, 12 for Rgen1 and 16 for Rgen2. Figure 11 gives an example of their use. Alex also defines three representations adapted to elements of scale mastery(three levels), formally defined in Figure 12, and illustrated in Figure 13. The first representation, RtSt, is textual. It can textually represent the level of mastery of a learner for an element as text formatted as specified: the level will be displayed in green if the element represented is mastered or partially mastered by the learner, in red if not.

Moreover, the level mastered will be in bold type. The second representation, RgSt1, is graphic. It can represent the level of mastery of a learner for an element with a blue progress bar. This progress bar will be filled to 100% if the element is mastered, to 50% if it is partially mastered and to 0% if it is not mastered. The third representation, RsSt1, is symbolic. It allows associating to an element a traffic light, green if the element is mastered, orange if it is partially mastered and red if it is not mastered.

RtSt1(elt, mastery(three levels)) = ((mastered, false, (Arial, bold, 14, green), white), (partially mastered, false, (Arial, normal, 12, green), white), (not mastered, false, (Arial, normal, 12, red), white))

RgSt1(elt, mastery(three levels)) = ((mastered, 100, blue, false, progress bar), (partially mastered, 50, blue, false, progress bar), (not mastered, 0, blue, false, progress bar) In addition, Alex defines four representations adapted to elements of scale note(0, 20), formally defined in Figure 14 and illustrated in Figure 15. The two first representations, RnSn1 and RnSn2, are numerical. RnSn1 focus on points to improve, representing in red bold notes below 10, while RnSn2 highlight positive points, representing in green bold notes above 10. The third representation RgSn1 is graphic. It is used to associate to each note a progress bar, filled in proportion to the note and which color depends on the interval in which the note is. The fourth representation, RsSn1 is symbolic. It allows associating to an element a smiley or two. It will be a smiling smiley if the note of the learner for this element is greater than 10, a sad smiley if not.

RsSt1
RnSn1(elt, note(0…20 = (([0,10[,true,(Arial,bold,12,red), white), ([10, 20], true, (Arial, normal, 12, black), white)) RnSn2(elt, note(0…20)= (([0,10[,true,(Times,normal,16,black), white), ([10, 20], true, (Times, bold, 16, green), white)) RgSn1(elt, note(0…20)= (([0, 6[, red, false, progress bar), ([6, 10[, orange, false, progress bar), ([10, 14[, light green, false, progress bar), ([14, 20[, green, progress bar)) [0, 6[, smiley1(2, 1, def)), ([6, 10[, smiley1(1, 1, def)), ([10, 14[, smiley2(1, 1, def)), ([14, 20[, smiley2(2, 1, def))) Finally, Alex defines a composed representation Rcomp1, whose formal definition is given in Figure 16. Rcomp1 allows representing a set of elements with a 3D bar chart with horizontal cylinders bars. For colors, Rcomp1 takes into account user preferences. If the user has no preferences, default colors will be used. Rcomp1 = (bar chart, 3, null, cylinder, vertical, ("",""), (green), white, white, light gray, true, (Arial, normal, 16, black))

RsSn1(elt, note(0…20)= ((

Figure 16: Formal definition of representation Rcomp1

Alex also defines two conditions, formally specified using cPMDLe (Figure 17). The condition Clp1 concerns the learning profile and selects learners whose average for the component Mathematics is equal or greater than 10. Ccp1 is a condition on the capacities profile that selects users which eyesight is greater than 8. After defining personalized representations and conditions he will use, Alex defines a view for learners for the activities he wants to propose to them. For example, for the activity of visualization of their profiles by learners, Alex defines with Regards the view View5, formally represented on Figure 18 and synthetically on Figure 19. For the component English, View5 associates to Grammar, Conjugation and Spelling the representations RtSt1, RgSt1 and RsSt1. Conjugation is composed of two elements (regular and irregular), so the value associated with Conjugation is the average of the values of these elements. Let's note that Comments, regular and irregular are not associated with any representation, so they will not be visible by learners during the activity of visualization. For the component Mathematics, View5 associates to the whole component the composed representation Rcomp1. It will represent its constituent elements, Calculation and Algebraic exercises (element of Comments type cannot be represented by a composed representation). View5 associates with Comments the representation Rgen1 if the user's eyesight is greater than 8/10, and the representation Rgen2 else. Calculation is associated with RsSn1, as it is a non terminal element, its value will be the average of the values of its sons Additions and Multiplications. Additions, Multiplications and Algebraic exercises are associated with RgSn1 and with RnSn1 if the average of the learner for Mathematics is equal or greater than 10, with RnSn2 else. What's more, Algebraic exercises will be presented to learners with the name Problems.

With Regards, Alex defined personalized representations, conditions, and a view for a profiles structure, a user type and an activity. This view can now be used in Perl to provide each user with personalized activities on profiles, taking into account the choices of teachers and the user knowledge, skills and preferences.

Perl module

Perl uses views defined in Regards to propose to a user personalized activities, among those identified in our typology of activities. Depending on the teacher's choices expressed through a view, an activity is proposed or not to the user. Thus, the proposed activities will depend on the user type, but may also vary between two users of the same type. Each activity proposed by Perl is based on the visualization of profile. This visualization is personalized for the user using the view defined by the teacher in Regards. For each viewable element of the profile, Perl generates a list of representations associated with this element and for which the conditions are verified by the user. Then these representations are ordered according to the user's preferences, to suggest representations that suit him the most among those available for him. However, the user is informed Let's come back to the example of Alex's class of 5 th grade, for which he created several views. Perl module provides each pupil of the class activities on the visualization of profile. For example, Lucas can view his profile, the evolution of his profile or compare his profile with the profile of the class; Olivia can view her profile and define objectives. Let's look at the visualization of their profile by Lucas and Olivia (Figure 20). For the element Comments of Mathematics, a single representation is available for Lucas whose eyesight is below 8: RtSn2 (cf. left part of Figure 21). For Olivia whose eyesight is over 8, the only available representation is RnSn1 (cf. right part of Figure 21). For Calculation, a single representation is available for each pupil: RsSn1. For Additions, Multiplications and Algebraic problems, the representations proposed for Lucas are RgSn1 and RnSn1 because he has an average of 14.25 in Mathematics, while RgSn1 and RnSn2 are proposed to Olivia who has 9.5. Let's note that Algebraic exercises is visible under the title Problems, according to the choice of Alex expressed in the view. For Mathematics, the composed representation Rcomp1 is also proposed for Lucas and Olivia. They can click on an icon (cf.  Figure 21) to see a bar chart that represents the elements that compose Mathematics. This representation takes into account user preferences for colors. Therefore, the bars of the chart are cyan for Lucas (cf. left part of Figure 22) while they are orange for Olivia (cf. right part of Figure 22).

Conclusion

In this paper, we have presented a model of personalization of interactive activities on learners profiles. This model allows proposing to each user personalized activities on his profiles according to the teacher's choices, and to his own knowledge, skills, capacities and preferences. This model uses vPMDLe views model. vPMDLe allows associating to an element of a PMDLe profile a list of representations respecting rPMDLe representations model and possibly depending on a list of conditions respecting cPMDLe constraints on profiles model.

In addition, we have implemented this generic model in EPROFILEA environment. Regards module allows the teacher to define personalized representations and views, in order to prepare activities on the profiles. Then, Perl module allows each user of each type accessing available activities on the profiles, on a fully personalized manner, taking into account of his knowledge, his skills, his capacities and also his preferences.

We have illustrated this process by a running example. Our example shows the needs of a teacher concerning preparation of activities on learners profiles. This example also demonstrates how our models, implemented in EPROFILEA environment, satisfy this need, while proposing personalized activities on profiles, respecting the teacher's choices and each user's preferences.

Experiments of Regards and Perl modules are planned soon, in order to verify firstly that Regards effectively enables teachers to express each of their choices, and secondly that Perl allows offering to all users activities truly adapted to them.

Our approach allows using these activities on profiles with various kinds of profiles, from different sources, paper and pencil or from ILE. But these activities have been created to be done after learning activities. They cannot be done during the activity of the learner, for instance by teachers to monitor them.

Figure 1 :

 1 Figure 1: Formal definition of general representations To represent elements of numerical scale, we offer three representations types (cf. Figure 2): numerical representation RnSn, graphical representation RgSn, and symbolic representation RsSn. In each case, the representation allows defining any number of numerical intervals [a i , b i ] or [a i , b i [ covering the definition interval [min, max] of the scale s associated with elt, with a 0 =min, b n =max, b i =a i+1 , a i <b i and 0<i<=k, where k is an integer.For an element of numerical scale, a numerical representation RnSn allows to define a layout for each interval. A graphical representation RgSn allows associating to each interval a color col, a boolean grad indicating whether or not this color will be gradated, and a graphic object graph (progress bar, thermometer, counter...). A symbolic representation RsSn allows associating to each interval one or more images Img (smiley, arrow, medal...) associated with characteristics: number, size, and color (that can be the default color of the image: def).

  Figure 4: Formal definition of representations for non termianl element

Figure 6 :

 6 Figure 6: Formal definition of conditions on a learners list

Figure 8 :

 8 Figure 8: Model to personalize activities on profiles

Figure 9 :

 9 Figure 9: Architecture of EPROFILEA

Figure 10 :

 10 Figure 10: Formal definition of representations Rgen1 and Rgen2

Figure 12 :

 12 Figure 12: Formal definition of representations RtSt1, RgSt1 and RsSt1

Figure 14 :

 14 Figure 14: Formal definition of representations RnSn1, RnSn2, RgSn1 and RsSn1

Clp1Figure 17 :

 17 Figure 17: Formal definition of conditions Clp1 and Ccp1

Figure 18 :

 18 Figure 18: Formal definition of View5 Figure 19: Synthetic representation of View5

Figure 20 :

 20 Figure 20: Lucas' and Olivia's profilesFor the component English, Grammar, Conjugation and Spelling are viewable. For these three elements, the available representations for both Lucas and Olivia are RtSt1, RgSt1 and RsSt1. Lucas prefers textual or symbolic representations, so RtSt1 and RsSt1 are proposed to him (cf. left part of Figure21). Olivia prefers graphical representations, so RgSt1 is proposed to her (cf. right part of Figure21). However, both Lucas and Olivia can choose themselves another combination of the three available representations if they wish.

Figure 21 :

 21 Figure 21: Visualization of their profile by Lucas (left) and Olivia (right)

Figure 22 :

 22 Figure 22: Composed representation associated to Mathematics for Lucas (left) and Olivia (right)


Blandine Ginon
email: bginon@gmail.com

Stéphanie Jean-Daubias
email: stephanie.jean-daubias@liris.univ-lyon1.fr

Marie Lefevre
email: marie.lefevre@liris.univ-lyon1.fr

Evolutive learners profiles

If the concept of learners profiles is now well known and treated in various ILE (Interactive Learning Environments), the taking into account of evolution in profiles do not benefit from the same advances. The subject of this paper is to define this notion and to show how it is taken into account in ILE researches. After a definition of the concept of evolutive learners profiles illustrated with examples, we show how this concept changes the models of our project, notably the evolution of PMDL profiles modeling language to PMDLe, that take into account the evolutivity of profiles. Then we present the consequences and benefits of these changes in the different modules of EPROFILEA environment that implement our models.

Introduction

A learner profile allows gathering information on knowledge, skills or behavior of a learner, information collected from a pedagogical activity, whether computerized or not [START_REF] Eyssautier-Bavay | A model of learners profile management process[END_REF].

These learners profiles are at the heart of many ILE (Interactive Learning Environments), they are also used, explicitly or not, consciously or not, by all teachers and all learners. Finally, they are also wanted by institutions. However, the different existing profiles are too often under-exploited: they are only used in their context, while their interest may go beyond. Figure 1 shows two examples of learners profiles. SQL-Tutor profile [START_REF] Mitrovic | Evaluating the Effect of Open Student Models on SelfAssessment[END_REF] provides a report of knowledge studied and acquired by the learner at a given time (see left part of Figure 1). The second example is an extract from a pencil and paper learner profile, used by teachers of 3 to 6 years old pupils of a French infant-school (cf. right part of Figure 1). This profile shows to teachers, family and eventually the pupil him-self the level of mastery of different skills targets by the learner. In the work presented here, we focus on the reuse of existing heterogeneous learner profiles by actors other than their authors, in particular to promote the use of profiles beyond the context of their creation.

The reuse of profiles requires a harmonization of the profiles. It can be made by several approaches. A priori approaches, based on standardization (PAPI, 2007), (IMS LIP, 2011), on ontologies [START_REF] Heckmann | GUMO -the general user model ontology[END_REF] or on the portfolio (Grant & Hubner, 1998) require that the learner profiles are initially written in a specified formalism. The fact whether they are a priori approaches is a limit to a large exploitation of tools based on these works. Indeed, only profiles that respect the specifications could be treated, while the existing profiles are very heterogeneous and most of them do not respect such specifications.

As for a posteriori approaches, they involve rewriting profiles in their own formalism in order to treat them, such as DynMap + [START_REF] Rueda | DynMap+: A Concept Mapping Approach to Visualize Group Student Models[END_REF] or VisMod [START_REF] Zapata-Rivera | Interacting with Inspectable Bayesian Student Models[END_REF]. The main limit of systems that adopt this approach is their lack of genericity: they only know how to rewrite the profiles from identified sources. (Ramandalahy et al., 2009) adopt a more flexible approach.

In our work, we adopt a generic approach: we provide an environment able to rewrite all kinds of existing profiles which we know neither the structure nor the data, without imposing any a priori formalism. This approach relies on a generic environment without any content that users will complete with the information they need: it is the users who add their own semantic to the system, in contrast to a priori approaches in which semantic is given and imposed.

In this paper, we focus specifically on the taken into account of evolution in the learners profiles. Getting information about the evolution of profiles allows keeping trace of previous states of knowledge for future exploitations: either for diagnosis in ILE or learners following by different actors (teachers and institutions, but also families and learners in a metacognitive context). Thus, an ILE can use the evolution of mastery of a given knowledge to adapt the level of proposed exercises, a teacher will not only be interested in the learner mastery level, but also in this level evolution since the last evaluation. For this, the profiles should include the concept of evolutivity.

Let's take an example of evolutive profile, translated from a pencil and paper profile used by teachers from a French infant-school. This profile is used to follow the pupils competencies during three years (small section -SS-, middle section -MS-and high section -HS-). Each year includes two evaluation periods. The profile extract presented in Figure 2 concerns the section "Discover the World", composed of three topics themselves composed of different components to evaluate. The rating scale used by this school is textual and graduated: an element evaluated over a period may be associated with "not acquired" (NA), "being acquired" (BA), or "acquired" (A). The level "being acquired" is divided in BA-and BA + and for a greater accuracy in the evaluation. In our example, "Knows the main spatial concepts" is a skill acquired for each evaluated period. An element of the profile may not be evaluable over a period, then it is associated with a black box. In the example of Figure 2 "Compares collections and arranges them according to quantitative criterion" is not evaluable in small section. It also happens that learners are not evaluated for an element over certain periods, in this case the element is associated with an empty box for the corresponding period. This is the case for example on the profile of Figure 2 for the first periods of small and medium sections for the element "Makes a collection containing the same number of objects as a referent collection". In existing works providing tools for profile management, evolution in learner profiles is currently not taken into account or not in a satisfactory manner. It is thus currently not possible to manage in a rich manner evolutive profiles such as the one presented in our example (cf. Figure 2).

Regarding a priori approaches, some standards take into account the time (like PAPI and IMS LIP which allow storing information on learner performance for different periods). The portfolio also keeps trace of several periods of learning, indicating the evaluation date. Let's remember however, that these approaches have a significant limitation: they only apply to profiles that respect their own formalism.

Regarding a posteriori approaches, among the works we have cited, only DynMap+ takes into account evolution in profiles. But let's remember its lack of genericity: it covers only the learners profiles as Bayesian networks.

In the rest of this paper, we show how we take into account the evolution in learners profiles in our approach. After this introduction, we first present the context of this research, PERLEA project, and then the models proposed in this context, including the PMDL profiles modeling language and its extensions, and their implementation in EPROFILEA environment. We present in the paper heart how we have changed these models and tools to take into account evolution in profiles. We conclude by referring to the exploitations that may be made of these profiles now evolutive. We illustrate these different parts with examples.

Context

PERLEA project focuses on learning personalization through exploitation of learner profiles. It aims to provide models and tools for re-use of heterogeneous learners profiles without distinction of level or discipline, existing or future, pencil and paper or software, in different contexts and by actors other than their author.

PERLEA project has resulted in the specification of REPro model (Reuse of External Profiles), a profiles management process model which runs from the creation of learners profiles to their uses (cf. bottom of Figure 4 for an overview and [START_REF] Eyssautier-Bavay | A model of learners profile management process[END_REF] for a more detailed presentation). This model, beyond a preliminary profiles constitution stage, highlights the need to harmonize structure and data of profiles to provide a unified representation, before possibly transform, then use these profiles. For harmonization, REPro is based on a formalism describing profiles to make external profiles reusable.

PMDL language (Profiles Modeling Language), that is used as pivot language between external profiles that respect various formalisms and reusable profiles rewritten in a common formalism, is a profiles modeling language that describes the structure of a profile in order to express different heterogeneous profiles in a same formalism [START_REF] Eyssautier-Bavay | A model of learners profile management process[END_REF]. For this, PMDL distinguishes in a learner profile its structure part, which may be common to several profiles, from its data part, containing information specific to each learner. Thus, PMDL is a theoretical model that defines basic elements that a teacher can instantiate and combine to form the profiles model that he would like to manipulate, model which we call profile structure. This profiles structure, common to several learners, will be instantiated to contain the data corresponding to each learner profile.

PMDL language is described formally in a BNF notation, coupled with a more accessible graphical representation (cf. Figure 4), the one used in this paper. PMDL allows describing the profiles structure at the harmonization step. This language, independent of any platform and therefore reusable, can express to the same, that is to say without loss or corruption of information, most existing profiles according to the same formalism, whether these profiles come from software or pencil and paper practices. A profile described with PMDL is composed of information about the learner, with a structure part and a data part. The profile structure, independent from data that it contains, includes a set of elements (for instance "mathematics" or "grammar"). There are four types of content for an element: components_list, distribution_list, graph and text (see Figure 3). These four types of content allow the creation of profiles which structure can vary in order to answer to teachers' needs. However, PMDL does not represent evolutive learners profiles. We defined PMDL application context and the language expressivity in this context. PMDL application context accurates information that the language takes into account or not. We then evaluated PMDL expressivity within this application context while expressing different profiles with PMDL, in order to test the limits of its expressivity. The main limits of the language revealed by the evaluation are its inability to take into account evolution in profiles, time spent on activities, the link with the activities at the origin of evaluations and the profile's elements organization. On the contrary, some limits, such as not taking into account traces are related to the nature of the learner profiles and do not need to be removed.

PERLEA project also resulted in the development of an ILE, EPROFILEA environment that implement models defined in PERLEA. EPROFILEA concerns the different actors of learning, even if it is primarily intended for teachers. It has three parts themselves composed of several modules (cf. Figure 4). The first part of EPROFILEA environment, the part of profiles preparation, consists to establish the profiles structure we manipulate, before we integrate data from external profiles in order to build learners profiles in accordance with the teacher's wishes and respecting the formalism of EPROFILEA. PMDL language is operationalized in Bâtisseur module that allows you to define the structure part of learners profiles in a unified formalism. Profiles structures from Bâtisseur will be completed in the data integration modules: Prose and Tornade. Prose module helps the teacher to enter data from each student pencil and paper profiles according to the profile structure defined in Bâtisseur. To integrate external software profiles (from educational software outside from EPROFILEA), Tornade module allows experts to create conversions profiles systems, which teachers can use to integrate data from the corresponding profiles to profiles respecting EPROFILEA formalism. Profiles thus formed may be hybrid: they may come from different sources whether they are pencil and paper or software. A profile part can come for instance from the use of an ILE of algebra, another from an ILE of grammar and the rest of the profile can come from evaluations made by hand by a teacher.

The second part of EPROFILEA is dedicated to profiles transformation. These transformations can be related to their structure or their data (Groupe module allows among others the constitution of a group profile from the group's learners profiles) or prepare profiles visualization (Regards module enables teachers to define different profiles views and to specify which views are accessible by which actor, teachers, learners, families...).

The third part of the environment, the part of profiles exploitation, offers from one hand activities on the profiles, with Perl module, and on the other hand personalized pedagogical activities defined based on the learners profiles content with Adapte module. Perl module will enable interactive profiles visualization by the different actors according to the views defined by the teacher in Regards. It also offers learners, in addition to profiles viewing, activities on profiles (rewording, negotiating profile elements...) allowing the learner to enter into a reflexive approach relative to his learning, and thus to better assimilate and exploit the information provided to him. As for Adapte module, it aims to give teachers the possibilities to personalize pedagogical activities proposed to their students according to their needs based on their pedagogical choices (Lefevre et al., 2009).

Evolution in PERLEA models

Until now, even if it was one of the initial objectives of PERLEA project, models and tools of the project do not take into account evolution in profiles. In this section, after defining the concept of evolution in learner profiles, we show how we made change models and tools of PERLEA project so they support evolution in profiles management.

The concept of evolutive learners profiles

In PERLEA project context, a hybrid and evolutive learner profile refers to a file collecting various information about the learner. This information may relate to his knowledge, skills, conceptions, behavior, or metacognitive information. Such a profile can include information from different sources that can be heterogeneous: we call it hybrid profile. Information that it contains can also cover different periods for a single element evaluated: we call it evolutive profile. Thus, evolutive profiles notion refers to the evolution of learner data in his profile.

Let's take again the example of the pencil and paper profile of an infant school pupil of Figure 2. This profile is evolutive: it keeps the results of all evaluations made during the six evaluation periods in infant school, in order to follow the learner's skills evolution. Thus, we see that the learner's knowledge rose in small section year for the element "counting small quantities" for the topic "approach of quantities". Indeed, this competency was "being acquired" for the first evaluation period and "acquired" during the second period. On the contrary, the learner has declined in middle section for the element "Makes an assembly of simple objects using a template" for the topic "Domain of forms and sizes", as it was "being acquired +" during the first period and "being acquired -" during the second period. Unlike this example, especially in ILE, most profiles are not evolutive, like the profile of SQL-Tutor (cf. Figure 1). For these profiles, it is not possible to identify fields in which the learner has achieved consistent results and those in which it has risen or declined.

Extension of PMDL language in PMDLe

Taking into account the concept of evolution in learners profile has caused the modification and extension of PMDL profiles modeling language to PMDLe, for PMDL evolution.

In its graphic representation that completes the definition in BNF, each element of PMDL is represented in a framework with a white part and a gray part. The white part contains the element name. If the element is terminal, that is to say if it is not composed of any other element, the gray area contains the element type, this field is empty otherwise. The diagrams of this graphical representation are tree structures that must be read from left to right. Elements on the left side of other elements and connected to them by a line contain them. Thus, the symbol < represents a logical OR relationship, [ represents a logical AND relationship, * means the element can be present from 0 to n times, + means the element can be present 1 to n times, ? means the element can be present 0 or 1, that is to say, it is optional. The absence of symbol before an item means it is present exactly once. To respect the concept of evolution in learners profile and thus allow a profile to contain information on different periods for a single evaluated element, it is necessary to keep in the learner profile data part each value and comment, by associating them with a date and possibly a source of evaluation. That is why some elements of PMDL have been modified, whether they concern the structure part or the data part [START_REF] Ginon | Étude du concept de profils évolutifs dans le cadre du projet PERLEA[END_REF]. Thus, the content of value_p of PMDL, has been modified in PMDLe (cf. Figure 5). It now contains zero, one or more evaluation. The evaluation contained in value_p elements is associated with a date, a value and possibly a source. This allows associating a new value with value_p, without deleting the previous ones. The optional comment element is replaced in PMDLe by the optional comments element. In PMDL a value_p contains a single comment as string: thus, each new comment associated with a value_p replaces the previous one, which is totally deleted. On the contrary, comments of PMDLe contains zero or more comment. Each comment of PMDLe is associated to a date, a text that aims to contain the comment and possibly a source, which allows associating a new comment with value_p without deleting the previous comment. A concrete example illustrating the interests of the change is in next section.

By defining PMDLe, we also completed PMDL beyond that required the taken into account of evolution by allowing for example to associate with a profile as much information about the learner the user wants, structured as he wishes, and not just a name and a surname, as it was the case in PMDL, or by adding the source of the evaluation concept that was missing until now. Thus, PMDLe can now represent not only the personal learners data (whether they are behavioral, cognitive or metacognitive), but also allows taking into account temporality, time spent on activities and links towards the productions associated with the evaluations.

We evaluated PMDLe expressivity in its application context, while studying changes in comparison to PMDL expressivity. The results are logically close to those of the evaluation of PMDL expressivity. Indeed, all profiles supported by PMDL are also naturally supported by PMDLe. Most profiles outside PMDL application context can be supported by PMDLe. Concerning the profiles based on a Bayesian network, resulting profiles can be represented without problem, but the Bayesian network itself can only partially be represented by PMDLe. A profiles modeling language does not aim at modeling the profiles formation stage, but profiles themselves. So, the representation part of the resulting profiles is sufficient for the validation of PMDLe. Thus, in its application context, PMDLe allows representing all profiles that we studied. PMDL language is completed by operators that define the possible profiles transformations. These operators can answer to the needs of profiles modification, after their creation, whether these needs relate to their structure or their data.

These operators on PMDL profiles have been defined in a semi-formal manner. They allow for example to read the comments in the text elements, add or delete an element to a profile, create a group profile from the profiles of several learners with the same structure: the resulting profile will have the same structure that learners profiles from which it was created, but the values it will contain will be calculated from the values contained in the individual profiles.

Operators on profiles respecting PMDL formalism are still suited to evolutive profiles respecting PMDLe formalism. But thanks to new opportunities provided by PMDLe, new operators can be defined. For instance, synthesis operators by average or sum (cf.  and  Figure 6) allow reducing an element by replacing all evaluations which the date is within a certain interval with an evaluation that has for value the average or the sum of the replaced evaluations. These operators take as input the profile, the element and a set of two dates making up an interval. One or all of these two dates may be null: it would compress all evaluations before or after a given date. The operator returns a profile with the same structure as the initial profile, but in which the specified element has been compressed. This can be used to keep trace of the progress of a pupil over months, without keeping each intermediate result in his profile. Evaluations intersection between 2 profiles, according to an interval all  InterEvalP Evaluations intersection between 2 profiles all Figure 6 : New evolutive profiles operators.

Operator

Let's take again the example of the evolutive profile of an infant-school pupil, given in Figure 2. Some evaluated elements have the same title for the three sections of infant school, while they do not correspond exactly to the same exercises. For instance, for element "knows the numeric song", the numeric song has 5 numbers in small section, 10 in middle section and 30 in high section. To know the learner evolution for this element, it is important to consider only the evaluations related to the same year of infant school. Indeed, we observe that for the second period of evaluation in small section, the learner had "acquired" this skill when it was only "being acquired" for the first evaluation period in middle section. However, this is not a regression; the numeric song is longer and thus more complex when the learner moves into a higher section. In these conditions it is necessary to use a filtering operator in order to keep only the evaluations of a same year before seeking to determine the learner for a given element.

cPMDL constraints on profiles model defines the various constraints that may be associated with a learner profile defined by PMDL formalism (Lefevre & al., 2009). Three types of constraints are defined by cPMDL: constraints on profiles on a value, on an element and on a number of occurrences. In order to exploit new possibilities offered by PMDLe, we defined three new types of constraints added to cPMDL to expand it in cPMDLe for cPMDL evolution: constraints on profiles on value evolution, on a value, an element or a number of occurrences. These types of constraints correspond to the existing types in cPMDL, which are still valid with evolutive profiles, but focus specifically on the evolutive nature of profiles.

These new constraints allow studying the learners results evolution for an element of a given profile and a given period to determine if the learner has risen, regressed or if he has obtained stable results. cPMDLe makes it possible to study the regularity of the learner's evolution.

Evolutivity in EPROFILEA environment

The implementation of the concept of evolutive profiles in PERLEA project, apart from changing the affected models, has caused the modification of various modules of Eprofilea environment (cf. Figure 4). Indeed, changes in the profiles modeling language have had effect in its operationalization in EPROFILEA, for the profiles structures definition, their completion, their possible transformations and their exploitations.

So we needed to modify the module of profiles structures description. Bâtisseur module allows the teacher to describe the structure part of a learner profile through an interface; the result (the profiles structure) is stored in a file respecting PMDL operationalization (cf. Figure 7). <brick id="7" type="0" name="Discover the world"> <comments/> <tree_of_components> <component name="Approach of quantities"> <subcomponent name="Knows the numeric song"><value/></subcomponent> <subcomponent name="Makes a collection "><value /></subcomponent> … </component> </ tree_of_components > </brick> <brick id="7" type="0" name="Discover the world" indice="6" comment="Good work" > <tree_of_components> <component name="Approach of quantities"> <subcomponent name="Knows the numeric song"><value>NA </ value></subcomponent> <subcomponent name="Makes a collection"><value>BA-</value></subcomponent> … </composante nom> </tree_of_components> </brick> Bâtisseur allows the creation or modification of profiles structure, which may be common to several learners profiles, usually at least one class. In EPROFILEA environment, profiles structures and learners profiles are stored in XML files, the doctype of these two files types has been modified to fit the definition of evolutive learners profiles described with PMDLe. Bâtisseur has been modified so that profiles structures files that it creates are in conformity with the new doctype (cf. Figure 7). <brick id="7" type="0" name="Discover the world" indice="6"> <comments > <comment date="2009/06/11" source=" semester2SS">Good work for the whole year </comment> <comment date="2010/06/18" source=" semester2MS">Good work</comment> </comments> <tree_of_components> <component name="Approach of quantities"> <subcomponent name="Knows the numeric song"> <value> <evaluation date="2009/01/21" source="semester1SS">BA+ </evaluation> <evaluation date="2009/06/07" source="semester2SS">A </evaluation> <evaluation date="2010/01/23" source="semester1MS">BA-</evaluation> <evaluation date="2010/06/05" source="semester2MS">BA+ </evaluation> <evaluation date="2011/01/15" source="semester1HS">NA </evaluation> </value> </subcomponent> <subcomponent name="Makes a collection"> <value> <evaluation date="2009/06/07" source="semester2SS">NA</evaluation> <evaluation date="2010/06/05" source="semester2MS">NA</evaluation> <evaluation date="2011/01/15" source="semester1HS">BA-</evaluation> </value> </subcomponent> … </component> <tree_of_components> </brick> Figure 8 and Figure 9 show an extract of the same learner profile which structure is given Figure 7: the part corresponding to the component "approach of quantities ", of the brick "Discover the world". In Figure 8 this extract is written in PMDL and gives only the last value for each element of the profile, in Figure 9 it is written in PMDLe and therefore allows to see the students' evolution.

Comparing these two extracts, we notice that the first profile can only contain information related to a single evaluation for the sub-component "knows the numeric song" of the component "approach of quantities" NA (cf.  Figure 8). In case of further evaluation, this information will be lost and replaced by a new one. In contrast, in the second profile which is evolutive, information related to each evaluation is kept, modifiable and reusable (cf.  to  in Figure 9). For instance, Figure 14 shows in  that the learner had level BA+ for the sub-component "knows the numeric song" in the evaluation from 2009/01/21, then in  he has the level A for the evaluation from 2009/06/07. This information would not have been kept by the non-evolutive profile. In addition, the non evolutive profile kept neither the date nor the source of evaluations, in contrast to evolutive profile. As well, we see that the second profile keeps each comment, unlike the first. Thus, in our example, the learner had on 2009/06/11 as commentary related to the brick "Discover the World", "Good work the whole year"  while on 2010/06/18, the comment was "Good work". Again, the evolution is meaningful and interesting for the different actors of learning. The main change is thus the fact that Bâtisseur operationalizes now PMDLe, and not PMDL, allowing it to integrate the notion of evolutive learners profiles. These modifications have repercussions on all EPROFILEA because the other modules of the environment handle learners profiles with a structure defined with Bâtisseur.

We also needed to modify the module of profiles keyboarding. Prose module allows the teacher to complete learner profiles corresponding to a structure of profiles from Bâtisseur, and create at first the profiles if they do not already exist, this transparently to the user. This module allows completing the data part of a profile in PMDLe, part specific to each learner. In Eprofilea, a learner profile is store in a XML file that follows the same doctype as the profiles structure files. Learners profiles changed to satisfy the concept of evolutive profiles, so Prose has been modified accordingly. Thus Prose now allows capture in profiles for different periods. To take into account the new possibilities enabled by evolutive profiles, the interface has also changed to allow the teacher to choose between adding a new evaluation for selected profiles and modify its previous evaluations. These changes make Prose fully able to handle hybrid evolutive profiles.

We needed to modify the module of external data integration too. Tornade module makes it possible to complete the data part of a profile, described in Bâtisseur based on an operationalization of PMDLe, using data from external software, and if necessary, to create previously the profiles transparently to the user. Tornade has been modified in order to take into account the concept of evolutive learners profiles. For this, we first modified the parser structure created by Tornade. The parser is a conversion system for data integration from an external ILE profile, in a profiles structure respecting EPROFILEA formalism, based on PMDLe. The parser structure is similar to the profiles structure which it relates, with the difference that evaluations and comments nodes do not contain text or integers representing values for a pupil, but information allowing to identify how to properly complete these nodes from the external software data for the considered learner. The parser structure is now based on those of evolutive profiles. Thus Tornade, as Prose, can now manage learners profiles not only hybrid, that is to say containing information from different sources, but also evolutive, that is to say keeping trace of different values of successive states for profiles.

Finally, we needed to modify the module of personalization of pedagogic activities. Adapte module allows the creation of worksheets and pencil and paper sequences of personalized activities in different ILE according to each learner profile, to teaching strategy and its context of use defined by the teacher. For this, the generation stage of worksheets to print or personalized activities sequence needs the definition of rules for allocation of pedagogical activities to learners. These rules are based on profiles constraints defined using the profiles constraints model cPMDL (Lefevre & al., 2009).

As PMDL has been extended in PMDLe, we have modified in Adapte the profiles consultation functions that find in the learner profile the value associated with an element, to determine the value associated with the latest evaluation on this element, thus making Adapte compatible with evolutive profiles.

Moreover, the notion of evolutive learners profile allows increasing the possibilities of Adapte by extending cPMDL to cPMDLe. The teacher can also personalize learners' learning, based not only on their knowledge but also on this knowledge evolution. cPMDL extension allows affecting for example review exercises to learners whose results have fallen, or upper level exercises for students whose results are always excellent. If a more systematic study is needed to identify all the constraints considering evolutivity, we have already created several constraints that we have implemented in Adapte. Thanks to one of these new constraints, the teacher can notably select the profiles of learners who progressed in an element, and has been regular during a given period, that is to say their result has increased with each new evaluation in this period. The teacher can also select the profiles of learners whose results were globally stable, that is to say the gap between the best and worst evaluation in this period belongs to a small interval specified by the teacher.

Let's go back to our example of the evolutive profile of a pupil given in Figure 2. We have seen that in middle section, the learner has regressed for the element "compares and arranges objects according to size criteria" in the "Field of forms and sizes". The teacher may decide to start the session with a small section exercise for students in this case, to put them in trust for the rest of the session. For this, the teacher must create an evolution constraint for the element "compares and arranges objects according to size criteria" and the period of middle section, to assign to this students a review exercise in the beginning of the session.

Conclusion and perspectives

In this paper, we discussed the concept of evolutive learners profiles, and its taken into account in both models and tools of PERLEA project, maintaining the generic approach claimed in the project. After defining the concept of evolutive learners profile, we firstly show how we modified the profiles modeling language PMDL to PMDLe, which supports the evolutive nature of profiles. This has resulted in the modification of the different representations of the language: BNF notation and graphic representation, which we added a XML representation, more convenient for the operationalization of the language. Thus, PMDLe allows keeping in the learner profile, if the teacher wishes, each evaluation result and each comment by associating them with information such as date and source of evaluation. Integrating the concept of evolutivity allows keeping information on learner progress.

Moreover, to highlight the various possible uses of the formalism described by PMDLe, we defined eight new profiles operators respecting this formalism, suitable for all profiles described in PMDLe. In addition, we extended the profiles constraints model cPMDL in cPMDLe for cPMDL evolution. We have defined five new types of constraints allowing the user to constrain the evolutivity of learner profiles. We then implemented some of these evolution constraints in Adapte module of EPROFILEA environment.

We also showed how we have implemented PMDLe in EPROFILEA. This operationalization has resulted in the modification of all existing modules of the environment. The whole EPROFILEA environment thus allows to manage not only hybrid, but now also evolutive learners profiles. Profiles structures and profiles used in EPROFILEA must now respect PMDLe formalism. Nevertheless, to ensure compatibility with non evolutive profiles, it is possible to use Tornade to insert the information they contain in an evolutive profiles structure.

The taken into account of the concept of evolutivity for learner profiles management opens new perspectives. First, the evolutivity of a learner profile should be taken into account when viewing this profile. Indeed, an evolutive learner profile will allow not only viewing the profile, but also the learner's progress. It will also allow, beyond different planned activities on profiles, to create activities around the concept of evolutive learner profile, such as goals definition for the learner. Thus, a teacher may, for example, define a goal with a learner, and then view with him the results he has achieved, and thereafter determine whether the goal has been met or not and even surpassed. Then, taking in account the evolutivity of profiles in EPROFILEA extends the possibilities of personalization of pedagogical activities permitted by Adapte.

This work shows first the feasibility of taken into account the evolutivity of learners profiles in a generic approach, and also makes possible particularly rich exploitations of these evolutive profiles, increasing the already significant possibilities proposed by EPROFILEA environment.

Figure 1 :

 1 Figure 1 : Profiles examples, one from SQL-Tutor and one from Antoine Remond infant-school.

Figure 2 :

 2 Figure 2 : Extract from pencil and paper evolutive profile from Antoine Rémond infant-school.

Figure 3 :

 3 Figure 3 : content of a profile in PDML.

Figure 4 :

 4 Figure 4 : Architecture of EPROFILEA.

Figure 5 :

 5 Figure 5 : Graphical representation of value_p in PMDL (on the left), and in PMDLe (on the right).

Figure 7 :

 7 Figure 7 : Extract from an evolutive structure of profiles outcome of Bâtisseur.

Figure 8 :

 8 Figure 8 : Extract from a file of non evolutive profile in EPROFILEA.

Figure 9 :

 9 Figure 9 : Extract from a file of an evolutive profile in EPROFILEA.