In this paper we present an approach to support selfregulated learnflows in the collaborative environment Metafora. In this environment students construct Visual Language Plans. Those plans model workflows of learning activities, which the students execute to solve complex learning scenarios across different tools. Visual Language plans were already used in the context of different pedagogical studies but have no formal syntax or semantics, yet. In this paper, we present the syntax of Visual Language Plans and develop a mapping from Visual Language Plans to Petri net defining semantics. With the help of this semantics, the environment can support the students executing their learnflows. If students execute activities given in a Visual Language Plan which are not enabled in the corresponding Petri net, feedback messages occur guiding the students. Students can refine their Visual Language Plan during execution. If a plan changes the corresponding Petri net model also changes. Analyzing the newly generated Petri net model can help to uncover faulty states of the learnflow model.
On the one hand, most schools and universities use traditional eLearning systems like Moodle or Ilias. These eLearning systems, which work like Groupware systems in industry, support workflows and offer a lot of evaluation tools, but miss most of the Web 2.0 features and collaboration. On the other hand the students use interactive and collaborative Web 2.0 systems like Facebook or Twitter. New pedagogical approaches try to close this gap and benefit from supporting collaboration between students.
The Metafora project [
In the Metafora system a group of students gets a challenge which they solve
collaboratively. Therefore the students build a Visual Language Plan, consisting of different
cards and arcs. This plan describes and documents their approach to the challenge.
Teachers can create new challenges. A step of creating a challenge is to select the set
of available cards [
The Visual Language Plans have a graphical representation and consists of nodes
and arcs. This nodes are cards. Different types of arcs connecting these cards. A card
represents a learning activity. Cards are in one of the three states idle, started or finished.
The Visual Language Plan depicted in Figure 1 was developed by students solving the
challenge The bouncing cannon ball [
Although the Visual Language is very intuitive, it does not have a formal syntax
or semantics. Both are essential requirements to support the students by modeling a
Visual Language Plan. The papers [
We organized the paper as follows. In Section 2, we give the required definitions of Petri nets and in Section 3 we develop a mathematical founded syntax for Visual Language Plans. Section 4 describes the mapping of Visual Language Plans to Petri nets and Section 5 shows our use cases for the new semantics of Visual Language Plans. In Section 6 we sum up our work. 2
In this paper we use the following notations. With N0 we denote the non-negative
integers, i.e. N0 = 0, 1, 2, . . . and with |S| we denote the cardinality for a finite set S. Petri
nets [
In graphical representations, we draw the transitions as squares and the places as circles. If an edge between a place and a transition exists, we draw an arrow. We show the marking for a place with small dots drawn in that place. To define the semantics of a Petri net, we use the preset and postset of a transition.
Definition 2 (Pre- and Postset). Given a Petri net N = (T , P, F, m0). The preset of a node n 2 (T [ P ) is the set •n := {n0 2 (T [ P ) | (n0, n) 2 F }. The postset of a node n 2 (T [ P ) is the set n• := {n0 2 (T [ P ) | (n, n0) 2 F }.
In a Petri net, enabled transition has only marked places in its preset. Only enabled
Transitions can occur. If a transition occurs the marking of the Petri net changes. The
transition consumes marks from its preset and produces new marks in its postset.
Definition 3 (Occurrence Rule for Petri nets). Given a Petri net N = (T , P, F, m). A
transition t 2 T is enabled, iff for all places p 2 • t : m(p) > 0 holds. The occurrence
of t yields the new marking m0 : P ! N0. This marking is:
m0(p) :=
In this section we will introduce and explain the elements of Visual Language Plans.
During the Metafora project pedagogues and psychologists of the University of Exeter
developed this Visual Language Plans and pedagogues and teachers of the Hebrew
University of Jerusalem and the National and Kapodistrian University of Athens evaluated
it. There are several pedagogical studies [
To solve Metafora challenges students build their own Visual Language Plan which describes their approach to the problem. Such a Visual Language Plan consist of nodes and different types of arcs. Nodes of a Visual Language Plan are cards. The meaning of a card depends on their label and this label belongs to the Visual Language. At the moment, the Visual Language has about 60 labels and it allows teachers to add further labels. The Visual Language divides those labels into 7 disjoint categories and this categories belong to different detail levels. We use the categories to define the syntax and semantics of the Visual Language. The 7 categories of the Visual Language are Activity Stage, Gate, Activity Process, Resource, Role, Attitude and Other. Activity Stage Cards labeled with an Activity Stage model main steps. Some available
Activity Stage labels are explore, define questions and find hypothesis. Gate Cards labeled with a Gate direct the control flow between cards labeled with an
Activity Stage. The Visual Language contains gates for and and xor.
Activity Process Cards labeled with an Activity Process model the actions which students do. Some available Activity Process labels are simulate, discuss and make notes. This cards model the activities required for solving a card labeled with an Activity Stage.
Resource Cards labeled with a Resource label are links to persistent instances of
microworlds and tools integrated in Metafora. For example, there are labels for the
physics pirate game PiKI, the algebraic pattern tool eXpresser and for the graphical
discussion environment LASAD [
Role Cards labeled with a Role annotate required roles for other cards. Some available
Role labels are note taker, evaluator and manager.
Attitude Cards labeled with an Attitude annotate required mind-sets. Some available Attitude labels are rational, critical and creative. Other Cards labeled with Other labels annotate domain specific information. At the moment the only available Other labels are the generic labels text card and blank card. to cards modeling activities. This relation connects cards labeled with an Activity Process, a Role, an Attitude or a Resource with each other or with cards labeled with an Activity Stage. If it connects a card with a card label with an Activity Stage the students must finish this card before they finish the card labeled with the Activity Stage.
The collaborative web application Planning Tool implements the Visual Language
and is part of the Metafora system [
a finite set C of labeled cards and 4 relations.
The set C is the union of the pairwise disjoint sets CAS , CG, CAP , CRe, CRo, CAt and CO, where CAS is a set of cards labeled with an Activity Stage, CG is a set of cards labeled with a Gate, CAP is a set of cards labeled with an Activity Process, CRe is a set of cards labeled with a Resource, CRo is a set of cards labeled with a Role, CAt is a set of cards labeled with an Attitude and CO is a set of cards labeled with an Other label. Further, the set CG is the union of the finite disjoint sets CGand split , CGand join ,
The 4 relations are a directed is next to relation Rnext ✓ ((CAS [ CG) ⇥ (CAS [ CG)) [ (CAP ⇥ CAP ) [ (CRe ⇥ CRe) [ (CRo ⇥ CRo) [ (CAt ⇥ CAt), a directed is needed for relation Rneed ✓ ((CAP [ CRo [ CAt [ CRe) ⇥ (CAS [ CAP )) [ ((CRo [ CAt) ⇥ (CRo [ CAt [ CRe)) [ (CRe ⇥ CRe), a directed is input for relation Rin ✓ ((CAP [ CRo [ CAt [ CRe) ⇥ (CAP [ CRo [ CAt [ CRe)) and a symmetric is linked to relation Rlink ✓ (((C \ CG) ⇥ (C \ CG)) \ (CAS ⇥ CAS )).
A 4-tuple (C, Rnext, Rneed, Rin, Rlink) is called Visual Language Plan Structure.
This definition for the syntax of Visual Language Plans is incomplete. It allows modeling splits and joins without using cards labeled with Gates and it does not enforce that a Visual Language Plan is weakly connected. We extend this definition to get a unique behavior of the model, avoid error-prone plans and enable validity checking. Therefore, we need the preset and postset of cards.
Structure P = (C, Rnext, Rneed, Rin, Rlink). The preset of a card c 2 C is the set of cards •c := {c0 2 C | (c0, c) 2 (Rnext [ Rneed)}. The postset of a card c 2 C is the set of cards c• := {c0 2 C | (c, c0) 2 (Rnext [ Rneed)}
The information preset c := {c0 2 C | (c0, c) 2 Rin} of a card c 2 C is the preset only considering the is input for relation.
We call a card labeled with an Activity Stage c 2 CAS with no other card labeled with an Activity Stage in its preset an initial card and a card labeled with an Activity Stage c0 2 CAS with no other card labeled with an Activity Stage in its postset an end card. To ensure a unique meaning, we demand that a Visual Language Plan fulfills following properties:
Structure P = (C, Rnext, Rneed, Rin, Rlink). We call P valid if it fulfills all the following properties: (I) A visual language plan has one initial card ci 2 CAS, i.e. •ci \ CAS = ; , and one end card ce 2 CAS, i.e. ce • \ CAS = ; . All other cards c 2 CAS have one incoming is next to arc and one outgoing is next to arc, i.e. for all other cards c 2 CAS \ {ci, ce} exist two unique cards c0, c00 2 CAS such that (c0, c) 2 Rnext and (c, c00) 2 Rnext hold. (II) All cards c 2 CGand split [ CGxor split have one incoming is next to arc and two outgoing is next to arcs, i.e. for all c 2 CGand split [ CGxor split exist 3 unique cards c1, c2, c3 2 CAS [ CG, c2 6= c3, such that (c1, c) 2 Rnext and {(c, c2), (c, c3)} ⇢ Rnext hold. (III) All cards c 2 CGand join [ CGxor join have two incoming is next to arcs and one outgoing is next to arc, i.e. for all c 2 CGand join [ CGxor join exist 3 unique cards c1, c2, c3 2 CAS [ CG, c1 6= c2, such that {(c1, c), (c2, c)} ⇢ Rnext and (c, c3) 2 Rnext hold. (IV) The number of and splits is equal to the number of and joins, i.e. |CGand split | = |CGand join |. The number of xor splits is equal to the number of xor joins, i.e. |CGxor split | = |CGxor join |.
Property (I) ensures that a Visual Language Plan has a unique card labeled with an
Activity Stage as start for the execution and all properties together define a very strict
structure for the abstract learnflow model. They are implicit contained in the Guideline
for the Visual Language [
ture P = (C, Rnext, Rneed, Rin, Rlink) and a set of arcs A ✓ Rnext [ Rneed [ Rin [ Rlink. A directed path in P within A from a card c1 2 C to a card cm 2 C is a sequence = c1, . . . , cm of cards ci 2 C such that for 1 i m 1 : (ci, ci+1) 2 A holds. A undirected path in P within A from a card c1 2 C to a node cm 2 C is a sequence = c1, . . . , cm of cards ci 2 C such that for 1 i m 1 : (ci, ci+1) 2 A or (ci+1, ci) 2 A holds.
In a Visual Language Plan, a card c 2 CAS labeled with an Activity Stage is usually refined with the help of other cards. Those other cards are direct or indirect connected to c with is needed for or is linked to arcs. We call a card which refines a card labeled with an Activity Stage a subordinated card. From the idea of refinement of cards follows that a card can only be subordinate to one card labeled with an Activity Stage. Definition 8 (Subordination). Given a valid Visual Language Plan Structure P = (C, Rnext, Rneed, Rin, Rlink) and a card labeled with an Activity Stage c 2 CAS . We call the set of nodes S1,c := (•c \ CAS ) [ { c⇤ 2 C | (c⇤ , c) 2 Rlink} the set of first order subordinated cards to c. A card c0 2 C is subordinated to c if a card c00 2 S1,a and a undirected path within Rnext [ Rneed [ Rlink from c0 to c00 exist such that does not contain the card c. Sc is the set of all subordinated nodes of c.
While executing a plan, students often need achievements from earlier stages to solve later stages. They can use the is input for relation to propagate a resource to a later card. This requires that they finished the earlier task before they can start the later task. Further, we demand that the connected cards refine different cards labeled with an Activity Stage.
Definition 9 (Visual Language Plan). Given a valid Visual Language Plan Structure P = (C, Rnext, Rneed, Rin, Rlink). We call P a Visual Language Plan, if it fulfills all the following properties: (V) P is weakly connected, i.e. for each two cards c, c0 2 C exist an undirected path within Rnext [ Rneed [ Rin [ Rlink from c to c00. (VI) Each card not labeled with an Activity Stage or a Gate is subordinated to precisely one card labeled with an Activity Stage, i.e. for all cards c 2 C \ (CAS [ CG) a unique card c0 2 CAS exist such that c 2 Sc0 holds. (VII) Each is input for arc connects cards which are subordinated to different cards labeled with an Activity Stage, i.e. for all (c1, c2) 2 Rin, c1, c2 2 C, unique different cards c0, c00 2 CAS exist such that c1 2 Sc0 and c2 2 Sc00 holds. (VIII) The is next to, is needed for and is linked to relations only connect cards not labeled with an Activity Stage which are subordinated to the same card labeled with an Activity Stage, i.e. for each pair of cards c1, c2 2 C \ (CAS [ G) with (c1, c2) 2 Rnext [ Rneed [ Rlink exist a card c 2 CAS such that c1 2 Sc and c2 2 Sc holds. 4
In this section we will define the semantics of a Visual Language Plan with the help of Petri nets. A card is in one of 3 states idle, started or done. A card shows its state with its coloring. The coloring of an idle card is grey, the coloring of a started card is yellow and the coloring of a finished card is green. Through this coloring, the students are able to see what they did and what is next. This is important because most of the Metafora challenges need more than 4 school lessons and include homework sessions. The set of the state of all cards is the state of the plan. This state function maps the set of cards C to {1, 2, 3}. With this notation 1 means idle, 2 means started and 3 means finished.
P = (C, Rnext, Rneed, Rin, Rlink). The state of P is a function s : C ! { 1, 2, 3}. We call a card c 2 C idle iff s(c) = 1, started iff s(c) = 2 and finished iff s(c) = 3. We call a Visual Language Plan finished, if its end card is finished.
In the Planning Tool, a card change its coloring if a student select this card as
started or finished. If a student select a card labeled with a Resource as started the
linked tool opens in a new Metafora tab. Still, Metafora does not clearly define the
semantics of a Visual Language Plan. The Planning Tool allows students to mark cards
as started or finished without checking any rules. At the moment, the semantics for
Visual Language Plans is only given as informal description [
These rules overlap and interfere. For example there is a clash of rule (b) and (d) for the joining card of an xor-split. The meaning of before in rule (b) and (c) is different. Through the different detail level of cards it depends on their neighborhood if they can change their state. The occurrence rule for cards of a Visual Language Plan is a complicated logical formula which is expensive to test. To avoid this, we decided to define the semantics of a Visual Language Plan with the help of a Petri net. For our mapping, we consider the starting and finishing of cards as events. In the Petri net to a Visual Language Plan transitions represent this events. If we only consider the starting of cards, the Petri net roughly looks like the Visual Language Plan. If we only consider the finishing of cards, the Petri net roughly looks like the Visual Language Plan, too. Places and arcs which control the learnflow connect these parts. In the following we will give step by step a mapping for a Visual Language Plan P = (C, Rnext, Rneed, Rin, Rlink) to a Petri net N = (S, T , F, m0). The Petri net N defines the semantics of the plan P . The following steps lead to the corresponding Petri net N :
Step 1: Choose a fixed enumeration for all cards c 2 C, i.e. a bijection M : C ! N0, and add for each card c 2 C two transitions tM(c),s and tM(c),f to the net N . For a card c 2 C, the transition tM(c),s represents the starting of c and the transition tM(c),f represents the finishing of c. To make sure that the finishing event of a card can only occur after the starting event, add for each card c 2 C a place pM(c) between tM(c),s and tM(c),f , i.e. add a place pM(c) and the two edges (tM(c),s, pM(c)) and (pM(c), tM(c),f ) to N . All places pM(c) are not marked, i.e. 8 pM(c) 2 P : m0(pM(c)) = 0. their start and finish events and add a places p11.
Fig. 4. This figure shows the bijection M : C ! card c 2 C we wrote the value M (c) on that card.
N0 which we use for our example. For each already occurred.
Activity Stage.
Step 2: To transfer the is next to relation, add for each arc (c, c0) 2 Rnext a new place pnext,M(c),M(c0),s between tM(c),s and tM(c0),s, i.e. add pnext,M(c),M(c0),s and the edges (tM(c),s, pnext,M(c),M(c0),s) and (pnext,M(c),M(c0),s, tM(c0),s) to N . This ensures that the students can only start the succeeding card c0 if they started the preceding card c before. Further, add for each arc (c, c0) 2 Rnext a place pnext,M(c),M(c0),f between tM(c),f and tM(c0),f to the net, i.e. add pnext,M(c),M(c0),f and the edges (tM(c),f , pnext,M(c),M(c0),f ) and (pnext,M(c),M(c0),f , tM(c0),f ) to N . This ensures that the finish event of the succeeding card can only occur if the finish event of the preceding card with exlpore, M (c) = 1, and the card c0 labeled with build model, M (c0) = 2, to the Petri net. The place pnext,1,2,s make sure that c starts before c0. The place pnext,1,2,f make sure that c finish before c0.
Step 3: If students use the is next to relation with an XOR split, they can only start one successor card because of rule (d). To fulfill this rule we add for each card !7
CGxor join a place pxor,M(c),s between the tM(c),s and the starting event transitions for all cards labeled with an Activity Stage or a Gate in the postset of c, i.e. add pxor,M(c),s, (tM(c),s, pxor,M(c),s) and for each card c0 2 c • \ (CAS [ (pxor,M(c),s, tM(c0),s) to N . Through pxor,M(c),s the places {pnext,M(c),M(c0),s | c0 2 CG) an edge c • \ (CAS [
CG)} are superfluous and we removed it. If we would only want to fulfill rule (d) we could stop now but we want to keep the symmetry of the Petri net and avoid useless marked places. Add pxor,M(c),f , (tM(c),s, pxor,M(c),f ) and for each card c0 2 c • \ (CAS [
CG) an edge (pxor,M(c),f , tM(c0),s) to N . labeled with logic gate, M (c) = 9, the card c0 labeled with refine model, M (c0) = 4, and the card c00 labeled with find hypothesis, M (c00) = 5, to the Petri net.
Step 4: If students use the is next to relation with a XOR join, they can choose only one path. Due to property (III) there are two preceding cards before this XOR join. Because of those two preceding cards, we added two places to N in Step 1. The students can only execute one path before this XOR join. This cause a deadlock. To solve this problem melt those two places into one place. For each card c 2 CGxor join remove all places {pnext,M(c0),M(c),s | c0 2 • c
\ (CAS [ CG)} and add a place pxor,M(c),s, an arc (pxor,M(c),s, tM(c),s) and arcs {(tM(c0),s, pxor,M(c),s | c0 2 • c also do this for the finish event part of our net. For each card c 2
CG)}. We
all places {pnext,M(c0),M(c),f | c0 2 • c
\ (CAS [ CG)} and add a place pxor,M(c),f , an arc (pxor,M(c),f , tM(c),f ) and arcs {(tM(c0),f , pxor,M(c),f | c0 2 • c \ (CAS [ CG)}. labeled with convergence, M (c) = 10, and the cards c0 labeled with refine model, M (c0) = 4, and c00 labeled with refine model, M (c00) = 6.
Step 5: To transfer the is needed for relation, add for each arc (c, c0) 2 Rneed a new place pneed,M(c),M(c0),s between tM(c),s and tM(c0),s, i.e. add pneed,M(c),M(c0),s and the edges (tM(c),s, pneed,M(c),M(c0),s) and (pneed,M(c),M(c0),s, tM(c0),s) to N . This ensures that students can only start the succeeding card c0 after they started the preceding card c. Further, add for each arc (c, c0) 2 Rneed a place pneed,M(c),M(c0),f between tM(c),f and tM(c0),f to the net, i.e. add pneed,M(c),M(c0),f and the edges (tM(c),f , pneed,M(c),M(c0),f ) and (pneed,M(c),M(c0),f , tM(c0),f ) to N . This ensures that the finish event of the succeeding card can only occur if the finish event of the preceding card already occurred.
This mapping is similar to the mapping of the is next to relation in Step 1.
Step 6: If students use the is needed for relation to model subordination, the places added with the last step enforce that the starting events of the subordinated cards occur before the starting event of the card labeled with an Activity Stage can occur. This {pneed,M(c0),M(c),s | c0 2
Sc}. For each card c 2 is wrong and we remove those places, i.e. for each card c 2 only allowed to start after c. We enforce this by adding places between c and all to c subordinated cards, i.e. for each c 2
CAS and each c0 2
Sc add a place psub,M(c),M(c0),s
CAS remove all places
CAS , all to c subordinated cards are and edges (tM(c),s, psub,M(c),M(c0),s) and (psub,M(c),M(c0),s, tM(c0),s). Rule (h) raise the requirement that for each card c 2
CAS all subordinated cards finish before the finish event of c can occur. We make this sure by adding places between the to c subordiand edges (psub,M(c),M(c0),f , tM(c),f ) and (tM(c0),f , psub,M(c),M(c0),f ). nated cards and c, i.e. for each c 2
CAS and each c0 2 Sc add a place psub,M(c),M(c0),f with PiKI, M (c) = 23, and the card c0 labeled with reflect, M (c0) = 21, to the Petri net. The place pin,23,21 make sure that the students finished c before they can start c0.
Step 8: Finally, two convenience places pinitial and pend are added. For the unique initial card ci add a place pinitial and an edge (pinitial, tM(ci),s) with m0(pinitial) = 1. information, M (c) = 11, and c00 labeled with brainstorm, M (c00) = 12, to the card c labeled with explore, M (c) = 1.
Step 7: To transfer the is input for relation, add for each arc (c, c0) 2 Rin a new place pin,M(c),M(c0) between tM(c),f and tM(c0),s, i.e. add pin,M(c),M(c0) and the edges (tM(c),f , pin,M(c),M(c0)) and (pin,M(c),M(c0), tM(c0),s) to N . This ensures that the succeeding card c0 can only start after finishing the preceding card c. The marking of the initial place pinitial is 1 if the students did not start executing the Visual Language Plan P . For the unique end card ce add a place pend and an edge (tM(ce),f , pend, ) with m0(pinitial) = 0. The marking of this place is 1 if the students finished the Visual Language Plan P .
The is linked to relation does not restrict starting or finishing of cards and we do not need to translate it. The language L of this Petri net N is the language of P , i.e. for each transition sequence 2 L starting and finishing of cards according to this sequence is valid for P with respect to the rules given above.
For our example Visual Language Plan we have chosen the mapping shown in Figure 4. Figure 10 shows the Petri net corresponding to this Visual Language Plan which results from the mapping described above. The upper part of the net consists of the transitions which control the starting sequence of the cards labeled with an Activity Stage and has a similar structure as the cards labeled with an Activity Stage in our example. The starting of a card labeled with an Activity Stage enables the start event transitions of their subordinated cards. The Petri net has more places than required and an algorithm for deletion of implicit places could remove psub,3,14,s. It is difficult to decide if a place is an implicit place and we need a fast mapping from the visual language plan to the Petri net so we keep those places. The middle part of the Petri net models the grey, yellow and green sequence. The place pin,23,21 for the is input for relation from the PiKI card to the reflect card is also in the middle part. This is the only connection form the lower part of the Petri net to its upper part. The finishing event of the refined cards can only occur after the finishing event of all their refining cards.
With the help of the formal syntax, shown in Section 3, we can automatically check if a Visual Language Plan is valid while students are modeling it. The Metafora learnflow engine we develop will listen to the logs of the Planning Tool, analyze the events done by the students and send feedback messages to the students. It will send affirmative feedback messages if the students fulfill desired properties, like refining cards labeled with an Activity Stage. If the students violate syntactic rules it will send corrective feedback messages. For example, this is the case if students connect cards labeled with an Activity Stage with an is linked to relation. The feedback messages help the students to create a meaningful and selfregulated learnflow model. Besides all this, we need the formal definition of a syntax for Visual Language Plans to define a formal semantics.
The Petri net mapping for a Visual Language Plan, shown in Section 4, defines a formal semantics for Visual Language Plans. The Metafora learnflow engine will create the Petri net for each Visual Language Plan and use it to analyze the starting and finishing events, done by students to generate helpful feedback messages. The feedback messages are affirmative, corrective or informative. The learnflow engine send an affirmative feedback message if students respect the execution rules, e.g. if a student finished the card labeled with the Activity Stage explore. If students violate the execution order of the Visual Language Plan it sends corrective feedback messages. For example, if students start the card labeled with the Activity Stage test model before they start the card labeled with the Activity Stage build model all students will get a corrective feedback message telling them to build the model first. We use informative feedback messages to tell students working on the same Visual Language Plan about meaningful actions. If Bob and Alice work on the same Visual Language Plan the learnflow engine will send Alice the informative feedback message ‘Bob finished build model.’ when Bob changes the state of the card labeled with the Activity Stage build model to finished. With these feedback messages we intend to help the students planning and executing their learnflow. We want to shorten the training phase and help the students to concentrate on their learnflow instead of think about occurrence rules for cards. With the help of informative feedback messages we try to help the students keeping track of current state of their learnflow while they use microworlds.
In Metafora, our learnflow engine is not able to enforce the syntax or semantics of a Visual Language Plan. Furthermore, the pedagogical case studies of the Metafora project showed that the students often use their Visual Language Plan for reflecting about their actions and rearrange specific elements to document how the learning actually took place. Reflection is one of the L2L2 behaviors which we support to grant more flexibility on the students side and enable a tight engagement in the planning and execution phases. To do this, we have to change a learnflow during the execution and transfer a state from a Visual Language Plan to its Petri net. The changing of the learnflow or faulty starting and finishing of cards can cause an invalid state of the Visual Language Plan. In case of a faulty state of the Visual Language Plan, a direct mapping would cause a not reachable marking of the Petri net and result in unwanted behavior.
In the following we will describe an approach to transfer a state from a Visual Language Plan to a marking of the corresponding Petri net which can handle faulty states and calculates valuable information to generate useful feedback. In case of a faulty state change of a card or a change of the learnflow model, we collect the state change events which caused the current state of the Visual Language Plan. This means for a Visual Language Plan P = (C, Rnext, Rneed, Rin, Rlink) with its state s : C ! { 1, 2, 3} and the corresponding Petri net N = (S, T , F, m0) we calculate a set E of transitions which occurred to reach this state. We do this by checking the state of each card c 2 C and get the transition set E = {tM(c),s 2 T | c 2 C ^ s(c) 1} [ { tM(c),f 2 T | c 2 C ^ s(c) = 2}. Next, we calculate for the net N a valid sequence of the transitions contained in E by occurring all enabled transitions, adding them to and removing them from E. We do this iterative until E is empty or has no more enabled transitions. For Visual Language Plans, we can do this because we have the state information for joining and splitting cards no conflicts can happen. Now, we have a maximal valid sequence of transitions of E, a subset E0 ✓ E of faulty transitions and can easily get a set A ✓ T of enabled transitions. With this information we can tell the students about the cards with faulty states by analyzing E0. We can recommend possible cards to the students by analyzing A. Moreover, we can calculate a minimal sequence 0, with prefix , which enable all transitions t 2 E0 and recommend steps leading to a valid state of the Visual Language Plan with the help of 0.
Figure 11 shows our example plan with annotations for the current state of the plan and Figure 12 shows the corresponding Petri net to this plan with a marking corresponding to the current state.
If a student starts the card c labeled with present (M (c) = 22) the Metafora learnflow engine evaluates this event as occurrence of the not enabled transition t22,s. Because of this faulty state change, it calculates the sequence of transitions which cause the marking of Figure 12, the set E = {t22,s} and the set A = {t21,f , t20,f , t19,f , t24,f , t8,s}. Now, it unfolds the Petri net with this marking and find the minimal sequence 0 = , t 8,s. 0 enable all transitions in E = {t22,s}. Finally, the learnflow engine sends a feedback message recommending to start the card labeled with prepare presentation. 6
The Metafora project developed the Visual Language Plans for learnflow modelling. Visual Language Plans support the pedagogy of L2L2. Metaora is a web-based computer supported collaborative learning platform implementing this Visual Language Plans and using Web 2.0 features. The Metafora project did not develop a formal syntax or semantics for this Visual Language Plans.
We develop a Metafora learnflow engine for automatic support of students using the Metafora system. In this paper we give an overview of Visual Language Plans for modeling learnflows. Further, we extracted consistent rules for the syntax and semantics of Visual Language Plans from the available publications and developed a formal syntax and semantics for this plans. To define the semantics of Visual Language Plan we presented a mapping to a Petri net.
The Metafora learnflow engine will analyze events done by students and support
them while planning and executing Visual Language Plans. With the syntax for Visual
Language Plans the Metafora learnflow engine can generate feedback messages
supporting the students in modeling their Visual Language Plan and with the semantics it
can generate feedback messages supporting the students while editing and executing
their plan. This feedback messages are affirmative, corrective or informative [