Learning in the Time Manager
A key characteristic of the Time Manager is its ability to adapt its assistance to individual users. This
document provides a general overview of the learning components that support this adaptive behavior.
The document also illustrates how diverse learning components can be used within a large system such
as the Time Manager, with the interface details serving as illustrative examples. For the larger picture of
how these learning components are integrated into the Time Manager and for details on the feature
engineering process and some of the algorithms used for these learning components, please refer to the
relevant technical papers, a list of which is provided at the end of this document.
Overview and Preliminaries
Given a set of meeting constraints, the Time Manager generates a set of candidate schedules, which
vary in how well they satisfy the meeting constraints.1 For example, one candidate might be outside the
time window specified, another might be at a different location, and yet another might not include one
of the specified participants. Based on the user’s feedback over such candidates, the Time Manager
acquires the user’s preferences for meeting scheduling.
LEAPTIME, the Time Manager’s learning core, comprises four different learning modules:




PLIANT (Preference Learning through Interactive, Adaptive, Non-intrusive Training): learns the
user’s meeting scheduling preferences
PIEL (Person Importance Learner): learns a person’s importance to a meeting, according to the
user
MIEL (Meeting Importance Learner): learns a meeting’s importance to the user
LOCAL (Location Preference Learner): learns the user’s preferences for meeting locations
Each of these modules is designed to acquire an individual user’s individual preferences for one or more
aspects of meeting scheduling. A key characteristic of all these modules is that they acquire preferences
in context: preferences learned are relative to the particular meeting requests, given the individual
user’s current schedule. As shown in Figure 1, these learning modules are built on top of various other
learning components. FBCRANKER and SVMRANKER are specialized interfaces to FBC and SVMLIGHT
respectively. They are designed to facilitate integration with these components and they provide
specialized functions for use by LEAPTIME in learning and applying ranking models. FBC provides a
simplified interface for learning classifiers using the algorithms in MINORTHIRD, a learning suite designed
primarily for text-based applications of learning. FBC, FBCRANKER, and SVMRANKER come bundled with
LEAPTIME; MINORTHIRD is a third-party framework component available through this website; and
SVMLIGHT is a free implementation of Support Vector Machine (SVM) learning,2 available through
http://svmlight.joachims.org/ .
1
As part of CALO, the Time Manager’s primary focus was the busy office worker with an oversubscribed schedule.
Joachims, T. (1999). Making large-scale SVM learning practical. In B. Schölkopf, C. Burges, & A. Smola (Eds.),
Advances in Kernel Methods: Support Vector Learning. MIT-Press.
2
Source and Object code: DISTAR 14509 - Approved for Public Release, Distribution Unlimited
Figure 1. Learning modules of the Time Manager.
LEAPTIME is an OAA (Open Agent Architecture)3 agent and, as such, provides an OAA API. In the
discussion that follows, we present the interface calls to LEAPTIME in terms of these OAA calls. Briefly, in
LEAPTIME, a call is of the form:
FUNCTION(Param1, …, Paramn, -Paramout)
where {Param1, …, Paramn} are the input parameters and Paramout is the (optional) output
parameter (its output status indicated by the prefix ‘-’). A parameter may sometimes be of the form
[Param, …, Param], which indicates that the expected parameter value is a list. It may also be of the
form functor(Param), which indicates that the expected parameter value must be given as an
argument to a specific functor. Nesting of parameter forms may be arbitrarily deep.
PLIANT: Scheduling Preferences
PLIANT learns the user’s primary scheduling preferences in the form of a ranker that can be used to order
the candidate schedules for a meeting. The Time Manager learns meeting scheduling preferences both
explicitly, from specification by the user through a preference elicitation interface, and implicitly, from
user feedback on suggested meeting candidates. PLIANT is the module responsible for learning from user
feedback.
PLIANT supports three types of feedback on these schedules: selection, pinning, and rating. Selection
occurs when the user chooses as the solution one of the set of candidates presented. Pinning occurs
when the user indicates one or more other candidates as equally preferred to the solution. And rating
occurs when the user explicitly indicates a preference rating (within a predefined range) on a particular
candidate.
3
Cheyer, A. and Martin, D. (2001). The Open Agent Architecture. Journal of Autonomous Agents and Multi-Agent
Systems, Vol. 4 , No. 1, pp. 143-148. (See also http://www.ai.sri.com/~oaa)
Source and Object code: DISTAR 14509 - Approved for Public Release, Distribution Unlimited
All three types of feedback are transmitted through the call:
update_schedule_preferences(SchedId,ContextFeatures,CandList,PrefId)
SchedId is the unique identification tag for this particular meeting request. ContextFeatures is the
set of candidate-independent features describing the meeting request and search space for candidates;
an overview of these features is shown in Table 1.
Table 1. Candidate-independent context features defining a meeting request.
Attribute Groups
properties of the meeting request (e.g., host, type, project)
meeting request constraints (e.g., start/end time, duration, location, participants)
second-order properties of the meeting request (e.g., whether the host’s supervisor is
one of the participants, whether the requested participants includes a visitor)
second-order properties of the meeting request constraints (e.g., degree of constrainedness of the user’s existing schedule, #conflict-free solutions for this request)
CandList is a list of Solution, each of the form:
solution(Schedule,FeatureVector,Cost)
For the purposes of learning, only FeatureVector is relevant; it consists of features that capture the
properties of the meeting candidate as well as its relation to the rest of the user’s schedule. Schedule
is an alternative, more complete representation of the meeting candidate used solely by the caller; and
Cost is used for ranking candidate schedules, discussed later in this section. An overview of the meeting
candidate features is shown in Table 2.
Table 2. Attributes for capturing a candidate schedule for a meeting request.
Attribute Groups
temporal properties of the meeting candidate (e.g., start time, end time, duration)
properties about the participants of the meeting candidate (e.g., #attendees
collaborating on some project with the host, whether the project leader is attending,
#senior managers attending)
satisfaction of other participants’ preferences (i.e., how well the others’ day/time
preferences are satisfied)
properties about meeting candidate relative to schedule (e.g., #work meetings
before/after, #social meetings before/after)
properties about meeting candidate’s impact on the schedule (e.g., #overlaps with other
work meetings, #appointment meetings bumped)
Finally, PrefId is the unique identification tag for the particular meeting candidate (one of CandList)
selected as the solution by the user. Pinning and rating feedback are incorporated as additional features
Source and Object code: DISTAR 14509 - Approved for Public Release, Distribution Unlimited
(specifically, a Boolean attribute pinned, and an Integer attribute rating) on the individual candidate
feature vectors of CandList.
PLIANT utilizes two different preference learners: one for learning a ranking function over schedules
(SVMRANKER) and one for learning a rating predictor over schedules (FBCRANKER). The ranking function
targets predicting relative preferences over candidate schedules while the rating predictor targets
predicting absolute preferences over candidate schedules. The predictions of the two are combined
through a simple linear weighted function parameterized as follows:
fSVM and fFBC are the predictions of SVMRANKER and FBCRANKER respectively.  determines the relative
weight to be placed on these predictions, and  is an empirically determined scaling factor for
normalizing the rankers’ predictions.
In addition, PLIANT combines the predictions of the learned model with the predictions of the elicited
model in a scheme that gradually shifts the predictions from the elicited model to the learned model.
The basic combination function is once again a simple linear weighted function:
The parameter  is set to decay to 0.5 every  iterations. These four parameters , , , and  are set
through the call:
set_learner([[initfile(ModelFile), alpha( ), beta(), gamma(), delta(),
svmdir(SvmDir), svmlearn(SvmExec)])
ModelFile specifies the name of the file in which the SVMRANKER model should be saved; SvmDir, the
directory into which the intermediate output of SVMRANKER/SVMLIGHT should be saved; and SVMExec,
the command-line executable for SVMLIGHT.
PLIANT is asked to rank a set of candidate schedules through the call:
rank_schedules(SchedId,ContextFeatures,CandList,ModelId,-RankedCandList)
As in the learning call, SchedId refers to a specific meeting request; ContextFeatures, to the
candidate-independent properties of the meeting request and solution space; and CandList, to the set
of candidate schedules generated. ModelId is the unique identification tag for the user. Finally,
RankedCandList is a copy of CandList with a value set for the cost of each candidate. Recall that
each candidate is of the form:
solution(Schedule,FeatureVector,Cost)
A call to rank_schedules sets the Cost parameter of each candidate according to the learned model;
the lower the cost, the more preferred the candidate.
The final major API call is one to retrieve the preference model according to SVMRANKER:
retrieve_sched_pref(PrefId,-Profile)
Source and Object code: DISTAR 14509 - Approved for Public Release, Distribution Unlimited
As before, ModelId is the unique identification tag for the user. Profile is the learned model
returned; it is of the form:
profile(type(Type),form(Form),Prefs)
SVMRANKER returns models with Type=‘cost’ (i.e., lower is more preferred), Form=‘linear’, and
Prefs as a list of weights for the meeting candidate attributes used by SVMRANKER—effectively, a linear
evaluation function for candidate schedules. In the Time Manager, these weights are utilized during
constraint reasoning for the generation of candidate schedules.
Note: Although the existence of two schedule preference learners is primarily an internal issue, ideally
hidden from the caller, the historical and integration picture is more complex and the two learners are
generally invoked through a parallel set of corresponding calls. Specifically, the learning call involves an
update_schedule_preferences call for SVMRANKER and an update_schedule_preferences_y4
call for FBCRANKER; and the ranking call involves a call to retrieve_sched_pref, which basically sets
cost according to the SVMRANKER during schedule generation, and a call to rank_schedules_y4,
which updates with FBCRANKER according to the specified weighting between the two predictions. The
primary API classes for PLIANT are com.sri.calo.leaptime.OaaProxyPliantY3 and
com.sri.calo.leaptime.OaaProxyPliantY4.
PIEL: Person Importance
PIEL learns a binary classifier for determining a person’s importance to a meeting. It utilizes the decisiontree learning algorithm in MINORTHIRD through FBC. PIEL learns pseudo-incrementally: training examples
are added one at a time and a new classifier is learned whenever a classification call is made, just prior
to classification.
Before any training or classification calls, PIEL must be called to define the user-specific set of projects:
define_feature_values_for_piel(User,FeatName,FeatVals)
User is the unique identifier for the user, FeatName is the attribute being defined (in this case,
‘project’), and FeatVals is the list of valid values for the attribute (in this case, the names of the
user’s projects).
A training example consists of the features defining a person in the context of a meeting, and an
importance label (Table 3). The learning call to PIEL is:
add_training_example_for_piel(User,FeatureVector,Importance)
where User is the unique identifier for the user, FeatureVector is the person being classified for
importance (i.e., all but the label feature in Table 3), and Importance is the importance of the person.
The classification call is similar:
classify_person_importance(User,FeatureVector,-Importance)
the only difference being that the importance argument is an output rather than an input.
The primary API class for PIEL is com.sri.calo.leaptime.OaaProxyPiel.
Source and Object code: DISTAR 14509 - Approved for Public Release, Distribution Unlimited
Table 3. Feature vector for learning person’s importance to a meeting. Features in italics (and
corresponding value domains) are derived by PIEL from the original feature.
Feature
HOST_IN_MEETING
PERSON_IS_PROJECT_LEADER
PESRON_IS_SENIOR_MANAGEMENT
PERSON_IS_VISITOR
PERSON_IS_EXPERT4
PERSON_HAS_TO_DO4
REQUEST_NUM_PARTICIPANTS
(numParticipants)
PROJECT
CATEGORIES
LABEL
Feature Value Domain
Boolean
Boolean
Boolean
Boolean
Boolean
Boolean
Integer
(String: {“1”, “2”, “3-5”, “6-10”, “11-20”, “21-50”,
“>50”})
user-specific set of Strings
{“other”, “work”, “talk”, “socialMeeting”, “travel”}
{“important”, “notImportant”}
MIEL: Meeting Importance
MIEL learns a (one-vs.-all) classifier for determining a meeting’s importance to the user. Like PIEL, it
utilizes the decision-tree learning algorithm in MINORTHIRD through FBC. It also learns pseudoincrementally, adding training examples one at a time and learning an updated classifier whenever a
classification call is made, just prior to classification.
Before any training or classification calls, MIEL must be called to define the user-specific set of projects
as well as the domain-specific set of locations:
define_feature_values_for_miel(User,FeatName,FeatVals)
User is the unique identifier for the user, FeatName is the attribute being defined (‘project’ or
‘location’), and FeatVals is the list of valid values for the attribute (the names of the user’s
projects or the room names for the user’s office building).
A training example consists of the features defining a particular meeting relative to the user, and an
importance label (Table 4). The learning call to MIEL is:
add_training_example_for_miel(User,FeatureVector,Importance)
where User is the unique identifier for the user, FeatureVector characterizes the meeting being
classified for importance (i.e., all but the label feature in Table 4), and Importance is the importance of
the meeting to the user.
The classification is similar; it also provides a meeting but instead returns a predicted importance label:
classify_importance(User,FeatureVector,-Importance)
4
PIEL provides for the definition of this feature but the Time Manager did not actually use it.
Source and Object code: DISTAR 14509 - Approved for Public Release, Distribution Unlimited
Table 4. Feature vector for learning meeting’s importance to the user. Features in italics (and
corresponding value domains) are derived by MIEL from the original feature.
Feature
HOST_IS_USER
HOST_IS_PROJECT_LEADER
HOST_IS_SENIOR_MANAGEMENT
REQUEST_NUM_PROJECT_LEADER
(projectLeaderIsAttending)
REQUEST_NUM_SENIOR_MANAGEMENT
(seniorManagementIsAttending)
REQUEST_NUM_EXTERNAL
(visitorIsAttending)
REQUEST_NUM_PARTICIPANTS
(numberOfParticipants)
PROJECT
CATEGORIES
LOCATION
LABEL
Feature Value Domain
Boolean
Boolean
Boolean
Integer
(Boolean)
Integer
(Boolean)
Integer
(Boolean)
Integer
(Integer: {0=0, 1=1, 2=2, 3=3-5, 4=6-10, 5=11-20, 6=2150, 7=51+)
user-specific set of Strings
{ “other”, “work”, “talk”, “socialMeeting”, “travel”}
domain-specific set of Strings
{“extremelyImportant”, “veryImportant”, “important”,
“somewhatImportant”, “notImportant”}
Optionally, MIEL can also be called to define a mapping from meeting types to importance values:
init_importance(User,TypeImportList)
where TypeImportList is of the form
[[Type,Importance],…,[Type,Importance]]
However, MIEL is currently limited to the meeting types (Categories) and importance labels in Table 4.
The primary API class for MIEL is com.sri.calo.leaptime.OaaProxyMiel.
LOCAL: Location Preferences
LOCAL learns a (one-vs.-all) classifier for determining the user’s location preferences for a particular
meeting. Like PIEL and MIEL, it utilizes the decision-tree learning algorithm in MINORTHIRD but it does so
directly, as it predated FBC. LOCAL also learns pseudo-incrementally, adding training examples one at a
time and learning an updated classifier whenever a classification call is made, just prior to classification.
Before any training or classification calls, LOCAL must be called to define the user-specific set of projects
as well as the domain-specific set of location labels:
define_feature_values_for_local(User,FeatName,FeatVals)
User is the unique identifier for the user, FeatName is the attribute being defined (‘project’ or
‘location’), and FeatVals is the list of valid values for the attribute (the names of the user’s
Source and Object code: DISTAR 14509 - Approved for Public Release, Distribution Unlimited
Table 5. Feature vector for learning preferred location for a meeting. Features in italics (and
corresponding value domains) are derived by LOCAL from the original feature.
Feature
HOST_IN_USER
(hostIsMe)
HOST_IS_PROJECT_LEADER
HOST_IS_SENIOR_MANAGEMENT
REQUEST_NUM_PROJECT_LEADER
(projectLeaderIsAttending)
REQUEST_NUM_SENIOR_MANAGEMENT
(seniorManagementIsAttending)
REQUEST_NUM_EXTERNAL
(visitorIsAttending)
REQUEST_NUM_PARTICIPANTS
(numberOfParticipants)
PROJECT
CATEGORIES
LABEL
Feature Value Domain
Boolean
Boolean
Boolean
Integer
(Boolean)
Integer
(Boolean)
Integer
(Boolean)
Integer
(String: {“1”, “2”, “3-5”, “6-10”, “11-20”, “21-50”,
“>50”})
user-specific set of Strings
{“other”, “work”, “talk”, “socialMeeting”, “travel”}
domain-specific set of Strings representing rooms
projects or the room names for the user’s office building). Note that the location attribute defines the
class labels for LOCAL.
A training example consists of the features defining a particular meeting and a preferred location (Table
5):
add_training_example_for_local(User,FeatureVector,Location)
where User is the unique identifier for the user, FeatureVector is meeting being scheduled (i.e., all
but the label feature in Table 4), and Location is the user’s preferred location for the meeting. A
location is of the form:
location(LocId)
where LocId is the unique location identifier. This training example serves as positive feedback for the
preferred location (LocId) and negative feedback for all other locations.
LOCAL provides two performance calls. The first is the classification counterpart of the learning call:
get_location(User,FeatureVector,-Location)
For this call, LOCAL returns the most preferred location for the given meeting (FeatureVector).
The second is a ranking call:
rank_locations(User,FeatureVector,Locations,-ScoredLocations)
Source and Object code: DISTAR 14509 - Approved for Public Release, Distribution Unlimited
Here, Locations is the list of the locations (each of the form Location(LocId)) to be ranked
according to the user’s preferences given the meeting. LOCAL returns ScoredLocations, which is copy
of Locations with scores attached and sorted according the scores (most preferred first), i.e.,
[locationWithScore(LocId1,Score1),…,locationWithScore(LocIdn,Scoren))
where Score1 ≥ Score2 ≥ … ≥ Scoren.
The primary API class for LOCAL is com.sri.calo.leaptime.OaaProxyLocal.
Source and Object code: DISTAR 14509 - Approved for Public Release, Distribution Unlimited
Time Manager Papers5
Berry, P., Donneau-Golencer, T., Duong, K., Gervasio, M., Peintner, B., & Yorke-Smith, N. (2009).
Evaluating user-adaptive systems: lessons from experiences with a personalized meeting scheduling
assistant. Proceedings of the Twenty-First Conference on Innovative Applications of Artificial Intelligence
(IAAI-09). Pasadena, CA.
Berry, P., Donneau-Golencer, T., Duong, K., Gervasio, M., Peintner, B. & Yorke-Smith, N. (2009). Mixedinitiative negotiation: facilitating useful interaction between agent/owner pairs. Proceedings of Eighth
International Conference on Autonomous Agents and Multiagent Systems (AAMAS-09) Workshop on
Mixed-Initiative Multiagent Systems. Budapest, Hungary.
Berry, P., Donneau-Golencer, T., Duong, K., Gervasio, M., Peintner, B. & Yorke-Smith, N. (2008). Emma:
an event management assistant. Proceedings of the Eighteenth International Conference on Automated
Planning and Scheduling (ICAPS-2008), System Demonstrations. Sydney, Australia.
Peintner, B. and Venable, K. B., & Yorke-Smith, N. (2007). Strong controllability of disjunctive temporal
problems with uncertainty. Proceedings of the Thirteenth International Conference on Principles and
Practices of Constraint Programming (CP'07), pp. 856-863, Providence, RI.
Berry, P., Gervasio, M., Peintner, B. & Yorke-Smith, N. (2007). A preference model for over-constrained
meeting requests. Proceedings of the AAAI 2007 Workshop on Preference Handling for Artificial
Intelligence. Vancouver, Canada.
Myers, K., Berry, P., Blythe, J., Conley, K., Gervasio, M., McGuinness, D., Morley, D., Pfeffer, A., Pollack,
M. & Tambe, M. (2007). An intelligent personal assistant for task and time management. AI Magazine,
28(2), 47-61.
Berry, P., Peintner, B., & Yorke-Smith, N. (2007). Bringing the user back into scheduling: two Case
Studies of interaction with intelligent scheduling assistants. Proceedings of AAAI 2007 Spring Symposium
on Interaction Challenges for Intelligent Assistants, Stanford, CA, March 2007.
Berry, P., Gervasio, M., Peintner, B. & Yorke-Smith, N. (2007). Balancing the needs of personalization and
reasoning in a user-centric scheduling assistant. Technical Note 561. Menlo Park, CA: Artificial
Intelligence Center, SRI International.
Moffitt, M. D. and Peintner, B. & Yorke-Smith, N. (2006). Multi-Criteria Optimization of Temporal
Preferences. Proceedings of Twelfth International Conference on Principles and Practice of Constraint
Programming (CP’06) Workshop on Preferences and Soft Constraints, pp. 79-93. Nantes, France.
Berry, P., Conley, K., Gervasio, M., Peintner, B., Uribe, T. & Yorke-Smith, N. (2006). Deploying a
personalized time management agent. Proceedings of the Fifth International Joint Conference on
Autonomous Agents and Multiagent Systems (AAMAS-06), Industrial Track. Hakodate, Japan.
Berry, P., Albright, C., Bowring, E., Conley, K., Nitz, K., Pearce, J., Peintner, P., Saadati, S., Tambe, M.,
Uribe, T., & Yorke-Smith, N. (2006). Conflict negotiation among personal calendar agents. Proceedings of
5
Many of these papers are also available on the same website as this document.
Source and Object code: DISTAR 14509 - Approved for Public Release, Distribution Unlimited
Fifth International Joint Conference on Autonomous Agents and Multiagent Systems (AAMAS'06),
Demonstration Track. Hakodate, Japan.
Berry, P., Gervasio, M., Peintner, B., Uribe, T. & Yorke-Smith, N. (2006). Multi-criteria evaluation in usercentric distributed scheduling agents. Proceedings of the AAAI 2006 Spring Symposium on Distributed
Plan and Schedule Management. Stanford, CA.
Berry, P., Gervasio, M., Peintner, B., Uribe, T. & Yorke-Smith, N. (2005). Mixed-initiative issues for a
personalized time management assistant. Proceedings of International Conference on Automated
Planning and Scheduling (ICAPS’05) Workshop on Mixed-Initiative Planning and Scheduling (pp. 12-17).
Monterey, CA.
Gervasio, M. T., Moffitt, M. D., Pollack, M. E., Taylor, J. M., & Uribe, T. E. (2005). Active preference
learning for personalized calendar scheduling assistance. Proceedings of the 2005 International
Conference on Intelligent User Interfaces. San Diego, CA.
Berry, P., Gervasio, M., Uribe, T., Myers, K. & Nitz, K. (2004). A personalized calendar assistant.
Proceedings of the AAAI Spring Symposium on Interaction between Humans and Autonomous Systems
over Extended Operation. Stanford, CA.
Source and Object code: DISTAR 14509 - Approved for Public Release, Distribution Unlimited