Information Technology Reference
In-Depth Information
Syntactically, the following key constructs
within this domain-specific language have been
realized. According to the example LISL script
in Figure 4, we differentiate between the follow-
ing statement types:
tion, the outcome, and the tool. Generally,
the first token, plainly or quoted, stands for
the (user-defined) action, while the second
one represents the outcome. The tool has
to be specified right after the keyword 'us-
ing', other tokens are ignored. If one of
the elements of such a statement can not
be resolved, an error with an explanation
is displayed.
•
'Define' statements (cf. lines 1 to 8) are
used to initialize the mash-up personal
learning environment, i.e., to declare ac-
tions, outcomes, and tools available in a
mash-up page. The actor is considered to
always be the current user. Each defined
entity stands for a variable in the 'pro-
gramme', whereby an action can have an
optional URL and a tool always must have
one. Outcomes (here 'objects') can refer to
an abstract goal or a concrete artefact and
can be used as placeholders in a URL (line
2), whereby a value must be assigned by
user input if such a URL is executed later
on (line 11). Defining one of these three
constructs always start with the command
'define' followed by the type of entity
('action', 'outcome', 'tool') and a unique
identifier. If a URL can be specified, the
keyword 'url' followed by the URL itself
is expected, for assigning a value to an out-
come the keyword 'value' has to be used.
Additional tokens are ignored, so that con-
structs like 'with the url http://[...]' or 'with
value peers' are valid.
•
'Learner interaction' statements (line 13)
materialize the user interactions with the
learning environment, i.e. they describe if
the learner navigates between two different
learning tools or she rearranges the appli-
cation on her screen.
The semantics expressed with LISL follow
a simplified learning activity model borrowed
from activity theory. Activity theory states that an
activity is shaped by its surroundings (Leont'ev,
1947; 1981; Engeström, 1987). For example,
tools do have certain affordances: a door knob
lends itself to opening. On the contrary, activities
do also shape their surroundings: they can result
in the construction of a tool. For our application,
a learning activity has been modelled to consist
of a set of (learner) actions bound to a particular
outcome and involving a particular tool (see
Figure 5). These actions specify typical learner
interactions envisioned for the activity. They are
defined directly by the learners. Templates (pat-
terns) provide scaffolds that are typically modified
by learners when instantiated into practice and
during the carrying out of the specified activity.
Action statements in LISL can have a spe-
cific URL going with them that, then, is typi-
cally used to perform a functional operation
within a learning tool, e.g., creating a new Wiki
page. An action without a URL launches the first
tool named in the 'using' section of the statement.
If a URL contains a placeholder an adequate
outcome with a value is required. If this outcome
is not specified (while executing earlier statements
•
'Connect' statements (line 9) are neces-
sary for interoperability reasons, thus tool
interactions can be made up by the user.
Syntactically, such a statement allows
combining two tools with each other, so
that data is sent from one to the other. What
this exactly means and how we are real-
izing these tool interactions, will be clari-
fied when explaining the semantics of this
statement.
•
'Action' statements (lines 10 to 12) com-
prise the actions to be performed by a
learner and consist of three parts: the ac-
Search WWH ::
Custom Search