![](bg6.png)
It is easy to see that all of the above constraints
can be represented not only as a TCSP, but also as a
Simple Temporal Network. However,there is an addi-
tional kind of constraints that is fundamental for com-
puting an admissible schedule of the tasks: the non-
overlapping constraints. A typical non-overlapping
constraint states that a task T cannot overlap with
another task. For example, the fact that the Library
meeting (LM) cannot overlap with the Prog2 class
(P2) is expressed as:
P2
s
− LM
e
≥ 0∨ LM
s
− P2
e
≥ 0
i.e., either LM ends before P2 starts, or vice versa.
Clearly, there must be one of these constraints be-
tween each pair of tasks T, T
′
in the calendar.
There may be additional non-overlapping con-
straints. For example, in our scenario of section 2,
the Library meeting must not take place at lunch time
(i.e. from 13.00 to 14.00) or after 17.00; to express
this constraint on Monday, we write:
LM
e
≤ 5∨ LM
e
≥ 8
LM
e
≤ 9∨ LM
e
≥ 14
similar constraints must be added for each day of the
week under consideration.
4.3 The Scheduling Module
Given the set of tasks to be allocated in the user’s cal-
endar, the scheduling module (developed by exploit-
ing the JaCoP Constraint Solver (JaCoP, 2011)) gen-
erates a schedule by handling the task definitions as
constraints to be solved in a Constraint Satisfaction
Problem. This type of activity has been largely ex-
plored in the research on Constraint Satisfaction; thus,
we briefly describe it, leaving space for the temporal
reasoning process, which is peculiar of our work.
If a task is not a precise appointment, its start and
end times are time windows during which the task has
to be executed (unless its duration is the same as the
distance between such time points). The scheduling
module thus represents the start and end time of each
task as time intervals themselves, defining them as Fi-
nite Domain Variables whose domains represent the
eligible time instants for starting/ending the task. For
instance, if a task T must start after t0, end by t1 and
its duration is d, its starting time window is [t0, t1-d].
Given the start and end Finite Domain Variables
of the tasks to be scheduled and the existing non-
overlapping constraints, the scheduling module per-
forms a domain reduction on such variables in order
to restrict their domains to the feasible values. If a
solution exists (i.e., for each Finite Domain Variable,
the domain is not null), the scheduling module ex-
plores the solution space for setting such variables to
specific values, which represent the proposed alloca-
tion time. Otherwise, the scheduling module returns a
“no solution” value, which describes the fact that the
set of considered constraints is not satisfiable, i.e., a
schedule addressing all the requirements specified by
the user cannot be generated.
Different strategies could be applied in the ex-
ploration of the solution space, leading to different
schedules. As previously described, we have selected
two alternative strategies: allocating earlier tasks be-
fore or allocating more urgent tasks before. Techni-
cally, such policies are implemented by selecting the
order of the variables to set during the exploration of
the solution space (i.e., the set of possible configura-
tions of the variables). In the Schedule start policy,
the variables having the smallest minimum values in
their domains are set before the others, which results
in an early allocation of the tasks that can start ear-
lier. In the Schedule end policy the variables having
the smallest maximum values in their domains are set
before the others, which results in an early allocation
of the tasks that must end earlier.
In order to supportan incremental mixed-initiative
scheduling of tasks, and the possibility of reason-
ing on a subset of all the tasks to be considered, the
scheduling module operates on a constraint set that
is a clone of the original task specification. In this
way, at each instant of time, the set of constraints to
be considered can be reset or modified as needed. It
is thus possible to create a history of the generated
scheduling solutions and allow the user to navigate it
and choose the preferred alternative.
It should be noticed that the constraints to be
solved in the generation of a schedule might con-
cern personal and shared tasks. Scheduling a shared
task means allocating it in the calendar of all the in-
volved actors, which are known thanks to the infor-
mation available in the Collaborative Task Manager
in which our mixed-initiative scheduler is integrated.
The scheduling module fully supports the allocation
of shared tasks because the constraints belonging to
the calendars of the involved users can be fused to
search for a global solution by merging their con-
straints: in fact, even though each actor is committed
to several tasks, those to be performed by different
actors can overlap in the overall schedule; thus, task
constraints can be merged to represent the complete
set of activities to be scheduled.
2
If the overall set of
constraints is not satisfiable (because there is no free
slot where the involved actors can perform the shared
2
If more than one actor is involved in a task to be re-
scheduled, the task instances present in the various calen-
dars are unified by imposing that their start and end times
are equal.
MIXED-INITIATIVESCHEDULINGOFTASKSINUSERCOLLABORATION
347