We used the above reasoning for feedback
generation to student from his/her student model.
For detecting authoring problems, we used Schema
analysis. Schema analysis techniques are based,
amongst others, on mathematical results about fixed
points. Since these results are not widely known, we
will explicitly show how to use them in the context
of schema analyses. Schema analyses will be
expressed in the functional, declarative,
programming language Haskell; since this allows us
to stay close to the mathematical results we use
(Haskell, 2005). We give some examples of schema-
analyses that determine whether or not certain
properties hold. The results of these analyses form
the basis of feedback to the author. The analyses
take the schemata as input. In this paper we perform
two types of analyses: 1) the analysis of structural
properties of a schema, for example the recursive
property, and 2) the comparison of a schema with
one or more other schemata, for example to test the
correctness of a definition.
6.1 Solving Authoring Problems
with Schema Analysis
In this section we describe six algorithms (four
briefly and two in more detail), which can be used to
signal the (possible) mistakes listed in section 5.
Completeness − we distinguish three kinds of
(in) completeness: (1) within a course, (2) within
domain ontology and (3) between a course and
domain ontology. If a concept is used in a course,
for example in a definition or an example, it has to
be defined elsewhere in the course. The undefined
concepts in a course are calculated in three steps: (1)
determine the set of concept id’s that appear in the
right- and left hand sides of concepts within
examples and all concept id’s that appear in the right
hand side of concepts within definitions (used
concepts), (2) determine the concept id’s that appear
in the left-hand side of concepts in definitions
(defined concepts) and (3) check that each of the
used concepts appears in the set of defined concepts.
A course is complete if all concepts used appear in
the set of defined concepts. Completeness can also
be applied to (domain) ontology, and between a
course and ontology. The first one check whether all
used concepts in the ontology are defined in the
same ontology, the second one if all used concepts
in a course are defined in the ontology. The same
three steps are performed in both functions.
Timely − A concept can be used before it is
defined. This might not be an error if the author uses
an inductive instead of a deductive strategy to
teaching, but issuing a warning is probably helpful.
Furthermore, there may be a large distance
(measured for example in number of pages,
characters or concepts) between the definition and
the use of the concept, which is probably an error.
We define the function timely to determine whether
or not concepts in a course are defined in time and a
function outOfOrderConcepts to list the concepts
that appear to be out of order.
timely::Course → Bool
timely = null.outOfOrderConcepts
In function outOfOrderConcepts, function
extractActivities returns for every activity in the
course the tuple (Strategy, [Extra_p]) and puts these
tuples in a list activities. Then, using functions inits
and tails every [Extra_p] list is split as follows: for
every element x in the list [Extra_p] the list is
subdivided into a left part (epl), which contains all
elements to the left of element x, and a right part
(epr), which contains element x as and all elements
to the right of x. For example, for the input list [e, d]
we get [([], [e, d]), ([e], [d]), ([e, d], [])], where e is
example and d is definition. Finally, function intime
tests the timely constrains for all tuples (es, (epl,
epr)): if the first element of epr is a definition and
the educational strategy is deductive, then: 1) a
related example appears after the definition, and 2)
no related example appears before the definition
(tested by elemBy eqConcept c in the code below).
In case of an inductive activity, a related example
appears before the definition and no related example
appears after the definition. Function intime is
always true if epr is empty or the first element of epr
is an example.
outOfOrderConcepts::Course → [Extra_p]
outOfOrderConcepts c =
let activities = extractActivities c
split = [(es, s) | (es, eps) <-
activities, s <- zip (inits eps) (tails
eps)]
in [head epr | (es, (epl, epr)) ←
split, not (intime (es, epl, epr))]
intime (_, _, []) = True
intime (_, _, Ex (j, c, cs, r) :_) =
True
intime (Deductive, epl, Def (j, c, cs):
epr) = elemBy eqConcept c epr && not
(elemBy eqConcept c epl)
intime (Inductive, epl, Def (j, c, cs):
epr) = elemBy eqConcept c epl && not
(elemBy eqConcept c epr)
eqConcept id (Def (i, c, cs)) = False
eqConcept id(Ex(i, c, cs, r)) = id == c
Recursive concepts − A concept can be defined
in terms of itself. Recursive concepts are often not
desirable. If a concept is recursive, there should be a
AUTOMATIC FEEDBACK GENERATION - Using Ontology in an Intelligent Tutoring System for both Learner and
Author Based on Student Model
121