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