From: AAAI Technical Report SS-93-07. Compilation copyright © 1993, AAAI (www.aaai.org). All rights reserved.
Howto Use Cases for Information Seeking Processes
Anne TiBen
Integrated Publication and Information SystemsInstitute (IPSI)
GeseUschaft fOr Mathematik und Datenverarbeitung mbH(GMD)
Dolivostr. 15, D - 6100 Darmstadt
tissen@darmstadt.gmd.de
Abstract
faces to information systems should enable the end user, to
retrieve the data without help from an intermediary expert.
Information seeking activities, whether in databases,
knowledgebases, or any kind of information system are
highly interactive processes. User interfaces to information
systemsshould enable the end user, to retrieve the data without help from an intermediary expert. Knowledgeabout informationseeking tasks and strategies of the user, as well as
the related system’sfunctionality are starting points to build
up cases of information seeking dialogues and to adapt cases
to a newinformation need. Weuse a case for two purposes:
first, for controlling the interaction, that meansgoing forward and backwardin the dialogue plan or history, and second, as a meansto guide the user through the information
space and throughthe interaction with the system. In contrast
to most domainsof case-based reasoners, our domainis underconswained and highly interactive.
Therefore, the
adaptation of cases can be done only with mixedinitiative of
user and system. Our approach is implementedin a prototype
of a f, ase-based dialogue manager(CADI), applied in the
MERIT
interface system to the CORDIS
databases. Currently, we are implementingCAIRO
(.C.,ase-Based Dialogues for
Information Retrieval Objectives), a further interface system to CORDIS
data, nowfocusing on case-based user guidance according to information seeking strategies.
Keywords:case-based dialogues; information retrieval
tasks and strategies; intelligent user interfaces;
Modeling information seeking processes come across
typical problems in knowledge-based systems: the user’s
knowledgeabout the system and the stored data is incomplete, it is vaguelyformulated,and it is neither consistent nor
persistent during a dialogue session. The best match between
the user’s informationneeds and the system’scapabilities to
f’mdand to present informationaccordingto the user’s intention and accordingto the dialogue situation is often not obvious. For this reason, a top-downdialogue, starting with a
global goal and solving all subgoals, is not realistic in information seeking.
Case-based Reasoning techniques are supposed to overcome those modeling problems [cf. Kolodner/Simpson86],
if the problemsolving domain, here information seeking, is
adequate to a data-driven, not a goal-driven, technique.
Instead of solving problem~ using a general task model,
case-based reasoners start with a set of previous cases, and
adapt a selected case to the new problem [cf. Riesbeck/
Schank89]. The basic idea is to use positive experience,
rather than solving a problemfrom scratch. Most important
aspects in adaptive planning [cf. Alterman 86/89, Hammond
89] are the treatment of plans specific to the application and
situation matchingto use an old plan to interpret the current
situation. Casesin our context are instantiations of dialogue
plans [cf. Carberry 88], describing a sequence of dialogue
steps, whichare related to an informationseeking task. In an
interactive system, case adaptation takes place with mixed
initiative of user and system.In order to developcases to start
with in our application, we extracted information needs by
guided interviews with potential users.
Introduction
Information seeking activities, whether in databases,
knowledgebases, or any kind of information system are
highly interactive processes. Mostly,in the beginningof the
interaction the information seeker does not have a strong
plan of how to find the information she is looking for.
Instead, the responseto each single request for data mayinfluence the next or future actions in her search. Traditionally,
this process is a human-human
interaction between an information seeker and an information provider, whooffers
support and access to the information system. User inter-
120
Weuse a case for twopurposes: first, for controlling the
interaction, that means going forward and backwardin the
dialogue plan or history, and second, as a meansto guide the
user through the information space and through the interaction with the system. For guiding the user in an information
seeking dialogue with an information systemwe need different kinds of backgroundknowledge[cf. TiBen93]. The partition into several knowledgesources is necessary to makethe
interface system portable into multiple dimensions: according to the task in the domain,accordingto the user, or to other
database systems. During interaction, we combineall kinds
of knowledgein order to adapt to current situations: (1)
knowledgeabout the dialogue structure, represented as a
dialogue plan; the expectedsteps, represented in the selected
case, as well as the executed steps, represented as states in
the history; (2) knowledgeabout the domain, makingthe
structure of the information systemtransparent and supporting query formulation; (3) knowledgeabout the user, in particular, the possibility of makingdialogue knowledgeuserspecific.
Weimplemented the case-based dialogue manager
CADI[cf. TiBen 91; Stein/Thiel/Ti6en 92] as a submodule
1 interface system to information systems.
of the MERIT
Both were tested in the domain of the CORDISdatabase
about research programs,projects, and project partners. This
version of CADIalready contained the main functionality
for dialogue control, and retrieving/storing of cases in the
case library. Case indexing and adaptation was mainlydetermined by object perspectives. The concept of object perspectives is derived from research on the focus of attention
in coherent conversation or discourse [cf. McCoy/Cheng
90,
see also Reichman89] and adapted for controlling dialogues
containing information seeking and information presentation actions. Perspectives are used as meansto build cases
from a thematically structured point of view. However,it
was difficult to make the system’s behavior, suggesting a
next step, transparent to the user. modelinga case as a discourse of themes needs means to make the discourse coherent. In our domain,in whichthe information need of the
user is vague and mayoften change during the interaction,
thematical progression on the basis of object perspectives as
the only meansfor case adaptation, seemsto be too weak. We
need additional knowledgeabout the user’s goals.
To overcome this problem in the new version, called
2 (".Cdlse-Based Dialogues for Information Retrieval
CAIRO
Objectives"), we makeuse of information seeking tasks for
modelingthe functionality of the systemand we makeuse of
information seeking strategies for describing user goals.
1. MERIT
("MultimediaExtensionsof Retrieval Interaction
Tools") has a SYBASE
interface to the CORDIS
data.
TheCordisdatabasesare offeredby ECHO,
the official host organization of the Commission
of the EuropeanCommunity
(CEC).For MERIT,
weuse subsets of the original databasescoveting about180programswithca. 900projects fundedby different researchprograms.About6000organizationsare involvedin
projectconsortia.
2. CAIRO
(as well as CADIand MERIT)runs on SUNcolor
workstations(SPARC
stations) and is written in CommonLISP.
Its knowledge
bases are basedon CRL,a framerepresentation
languageof Knowledge
Craft [cf. KC89]. TheCordis data were
transferredinto a LISPintermediaterepresentationandthen automaticallyconvertedto a netlike framestructure in CRL.Forthe
graphical interface, CAIRO
uses HyperNeWS,
a NeWS-based
graphicsenvironment
developedat the TuringInstitute in Glasgow[cf. vanHoff89].
121
This way, user goals are used in the case-based dialogue
managerfor indexing and adapting cases.
In this paper, we start with a catalogue of information
seeking tasks and strategies and a short overviewon a casebased dialogue manager. Then, we describe how information seeking tasks and strategies can be mappedto dialogue
structures and be used for case indexing, and howwe control
the interaction and guide the user through the information
space. Beforethe paper finishes with conclusions and an outline to future work,we present the current state of the implementations of the new prototype, the CAIRO
system.
Information Seeking Tasks and Strategies
Information seeking tasks
The cognitive view of informationretrieval as well as the
demand
for intelligent, interactive interfaces of retrieval systems are presented comprehensivelyin [cf. Ingwersen 92].
Belkin and Marchetti [cf. Belkin/Marchetti 90] examined
the information seeking (IS) process and presented a cognitive task analysis, containing tasks as searching,specifying,
and selecting in information sources. Althoughthey suggest
a task model, they even stress that the information seeking
process is inherently interactive and that intelligent interfaces need moreinteraction functionality. For that reason, in
the BRAQUE
system [cf. Belkin/Marchetti/Cool 93] they
extend their task analysis and add browsing, recognizing,
and learning in information and meta information sources to
the set of informationseeking tasks.
Informationseeking strategies
In order to relate IS tasks and strategies, in BRAQUE
they arrange these cognitive tasks in four dimensions: the
methodof interaction (browsing/searching), the goal of interaction (learning/selecting), the modeof retrieval (recognition/ specification), and the resource considered (information items/meta information). They term combinations of
those factors as ’information seeking strategies’, describing
behavior like, e.g. "searching for items similar to some
knownitem; ...; looking aroundfor somethinginteresting...;
inspectingitems and their content; ...".
Belkin3 took the strategy determinedby ’searching’, ’selecting’, and ’specifying’ in information sources and developeda script describing the interaction process [cf. Belkin et
al. 93b]. He suggested scripts of interaction behavior containing conversational roles of speaker and hearer. This approachis influenced by the research on a conversational dialogue modelfor information seeking done by Sitter and Stein
[cf. Sitter/Stein 92]. Ascript contains dialogue steps related
to IS functions for the user’s request, for the system’sdisplay
of the results, and a step for feedbackof the user. Then, we
3. Personaldiscussionswith NickBelkinduringa collaborationat IPSIin July 1992.
Store
Information 1
System
User’s
Information Need
I
Display retrieved data I
Fig. 1 : Schema
of Case-based
Dialogues
for Information
Seeking
took the results of the interviewwith potential users of our
applicationsystem,andinstantiated the scripts with domain
knowledge
to solve specific informationseeking tasks. In
this paper,I suggestthat a script describingthe interaction
followinga specific strategycan be mapped
to parts of cases
of dialogueplans, the dialoguesequencesand cases can be
build froma looselyorderedset of dialoguesequences.
Let megive an exampleof the first two dialogue sequencesof a case about’Lookingfor proposedprojects on a
known
topic’. Here,the user maystart witha search,specifying a list of known,relevant researchprograms.In a second
dialoguesequenceshe maychangeto anotherstrategy in order to browsethroughthe projectsof the specifiedprograms.
Here,she can choosebetweenagainspecification,e.g. specify the relevant projectsby attributes like the durationof a
project, projectfunding,substringsin the projecttitle, etc.,
or, in an interaction modeof browsingand recognition,she
mayselect project acronymsfromthe display of retrieved
data andask for a displaywith moredetailed information.
This exampledemonstratestwo importantrequirementsfor
interfaces to informationsystems.First, they shouldhavea
flexible set for informationseekingfunctionalityaccording
to cognitive tasks of the user. Combining
the four dimensions BRAQUE
distinguishes up to 16 strategies of information seeking. In CAIRO,
they can be parameterizedby domainspecific data or perspectivesand listed or aligned.
Second,interface systemsshouldbe able to offer guidance
throughthe spaceof IS strategies and their instantiation.
Therefore, wesuggest a dialoguemodeland choosea casebasedapproachfor dialoguecontrol.
Informationseekingfunctionality
Now,cognitivetasks andstrategies of the user haveto be
mapped
to the functionalityof the interface systemto the informationsources.Belkin, Marchetti,andCoolpresenta set
of functions,influencedby the functionalityof the Hyperline
system[cf. Agosti/Gradiengo/Marchetti
1992]. Theylist a
set of systemcapabilities for displayinginformation,selection and storageof items, search formulation,selection of
122
initial points fromdisplays for browsingactivities, etc.
Movements
on functionsets are a fin’st step to cometo a process model.Bythe next step, the formulationof scripts [cf.
Schank/Abelson
77], the process has to becomeinteractive
with mixedinitiative of both, user andsystem.
In the newCAIRO
system,werealized relevant subset of
those functions. See chapter 5 for the description of the
CAIRO
implementationsin order to realize a dialogue control in twodifferent control modes:in the non-guided,usercontrolledmode,the IS functionsare called by the user directly, or in the guidedcontrol modefunctionsare parts of
cases of dialoguesandthey will be suggestedto the user as
dialogue steps. For the second modeCAIRO
needs a dialogue managercomponent
whichis able to operate on cases.
The Case-Based Dialogue
Manager
Casesare representedas instantiationsof dialogueplans,
describinga typical working
contextin the domain,see fig.1.
Adialogueplanconsists of a sequenceof dialoguesteps, extendedby a descriptionof user inputs andsystem’soutputs.
This explicit representation of the dialogue and various
knowledgebases about dialogue, domain,and user knowledgeenablethe interface systemfor adaptation[cf. Til3en
93]. In order to developcases for our application to start
with, weextracted informationneedsby guidedinterviews
withpotential users. Casesin our domainaboutresearchprogramsandprojects describe dialoguesto solve typical informationneedsof the user like e.g. ’Looking
for partnersfor
a newproject about a knowntopic’, ’Lookingfor contact
personsfor an ongoingproject’, ’Overview
on proposedresearchprograms’,etc.
To operate on cases, the case-based dialogue manager
CADI
[for moredetail see Tilden91] has functionslike retrieve a dialogueplanfromthe caselibrary, store the ongoing
dialogueas a planin the caselibrary, andmod/fy
a planto the
current goals of the user. In a first dialoguephase, the
introductionphase,a case will be selected accordingto the
current informationneed. Then,duringthe wholedialogue,
the systemoffers the user the selected case as a meansfor
guidingher in multiple dimensions:(1) navigatingthrough
the informationspace, (2) focusinginformation,(3) switching the information
seekingstrategies, or (4) switchingto alternativepresentationforms[cf. Kerner/Thiel
9 I]. In a final
phase,the user maypermanently
store the dialoguewith all
the modifications.This will be representedas a newcase and
storedin the caselibrary.
Aswell as the dialoguemodel,the case library is known
beforestarting an interaction. Thecase library mayincrease
fromsession to session, and needs an ownmanagement
for
retrieving and storing cases. Thecontent is domaindependent, andin addition,it maybe user specific.
Integrating Information Seeking Tasks and
Strategies into Cases of Dialogues
Mapping
tasks andstrategies onto the dialoguemodel
In the dialoguemodel,a dialogueplanis describedas sequencesof dialoguesteps. In MERIT,
cases of dialoguesare
modelledaccordingto a thematicalprogression,that means
that eachdialoguesequenceis related to a theme,described
by a perspective, and that. there are links betweenthose
themes,whichmakethe dialoguecoherent. Duringtests with
users unfamiliarwith the system,wegot the experiencethat
the topical coherenceis not alwaysobviousto the user. To
overcome
this problem,wemakeuse of results of the cognitive tasks analysis andstarted a newimplementation.
In the
newCAIRO
system, a dialogue step describes perspectives
to the databaseandthe interaction behaviorfor a specific
task. Thereare twokindsof dialoguesteps: requests(of the
user to the system)and informsteps (of the systemto the
user) accordingto dialogueacts at the maindialoguelevel of
the conversationalroles modelof [cf. Sitter/Stein 92]. We
canenrichthe interactionwithIS functionalityandadaptit to
the workingcontext of informationseeking.
Strategies will be mapped
to sequencesof dialoguesteps
of request andinformacts. Thedimensionsof the selected
strategy are mapped
to user goals whichare usedto indexthe
sequence,andconsequently
they are usedto indexthe case.
Modesfor dialoguecontrol
In orderto offer the IS functionsdirectlyat the interface,
weare implementing
twodifferent modesfor dialoguecontrol: a guided,case-basedmodeanda user controlled, nonguided mode.In the case-based, guided modethe system
guides the user throughan informationseeking dialogue,
that meansthat the interactiontakes placeaccordingto apreviously stored successful dialogue, a case, going forward
step by step in this case. Weprovidedifferent instantiations
of ’continue’ and ’go back’ operationsin dialoguecontrol
123
andmakethemtransparentto the user at the interface level.
’Continue’and’go back’can be specifiedaccordingto characteristic pointsin the dialogueplan(for continue)or in the
dialoguehistory (for go back). Duringan ongoingdialogue
CADI
creates a history of the interaction in forma stack of
dialoguestates. Fromthis history the CADI
storer can generate a newcase automatically.That means,that the newcase
is developed
from(the) old case(s) andIS tasks, the user
insertedin the non-guided
mode.In additionto the control of
dialoguesteps initiating related informationseekingfunctions, the systemcontrols in the guidedmodethe wholeinterface layout (popup/hide, positioningof windows).
In the user-oriented, non-guidedmodethe user choosesthe
informationseekingfunctionsdirectly at the system’sinterface. There are pulldownmenuswherethe user can select
search, browse,displayandfeedbackactivities andcontrols
specification of dialoguesteps, e.g. choosingperspectives
for a search formulation, switching betweeninformation
seekingstrategies, andinformationdisplays. Thecontrol of
the wholeinterface has to be doneby herself, includingthe
control of the layout of the screen with multiplesimultaneous openedwindows.Switchingbetweenboth interaction
modesat the interface providethe feasibility to evaluate
comparativelythe guideddialoguecontrol vs. a direct manipulative, user controlled interaction andto examineand
improvethe modelingof the dialogueandthe cases.
CAIRO
proposesthe guidedmodeas the major dialogue
mode.The non-guidedmodewill be handled as the minor
mode,whichshould only be used if the cases are too restricted to a specifictask, or if a single information
seeking
task shouldbe insertedinto the ongoing
case. Thatis possible
at anytime duringthe dialogue.
Adaptationof cases
Let us reflect on user goals in informationseekingprocesses. Examples
can be formulatedinformally,like: I know
<x>and want to knowmoreabout <y>(which implies that
thereis a relationbetween
x andy!); I wantto see data similar
to <x>;I wantto specifywhatkindof data I’mlookingfor; I
wantto lookaround,I wantto lookaroundon a specific subset; I wantto learn aboutthe database;I wantto select data
for later use; etc. It is obviousthat they are not independent
fromeachother andthat a hierarchicalclassificationof user
goals is not possible. Therefore,wefollowthe approachof
spacesof informationseekingstrategies, build upby four dimensionsof informationseekingbehavior.Wetake these dimensions, to index dialogue sequences according to informationseeking behavior.
If welook again to the examplesof user goals given
above,wecan differentiate kindsof adaptation.First, as we
already did in MERIT’s
version of CADI,the perspectives,
focusingona partition of the database,can be flexibly modified. Perspectivesare organizedin a hierarchicalstructure,
so that a shift, e.g. fromorganizationalaspectsto a thematic
searchof projects(’Looking
for projectsabout...’), as well
as zoominginto moredetail, or zooming
out to an overview,
canbe realized easily by a single dialoguestep. Now,in the
Information
eseking
requests
Findknown
data
Search
Browse
byspecification
orrecognition
ofthename
byspecification
onattributes
userelations
between
concepts
Displays
and
display
requests
Show
I item
Show
n items
Show
overview
Show
next/parlous
item
Compare
items
indetail
inalistortable
asetoflists
ofthelistindetail
indetail
Fecdbeck
Select
item(e)
Delete
item(=)
Store
item(a)
forsubset
from
list
onhistory
Fig. 2 : information
seekingtasks in CAIRO
new CAIRO
version of CADI,we use some more adaptations ontop of that. Anothertypeof adaptationcan reflect to
whatthe user knowsand whatthe user wantsto knowby selecting adequateinformationseekingstrategies or by replacing strategies that are suggestedin a case accordingto the
user’s goals. In addition, the user modifiesthe suggested
case during the ongoingdialogue: she can replace search
terms, attributes or perspectives, skip suggestedsequences
of dialoguesteps, mixcases to a newcase, etc. Thenewgenerated caseis different fromanyother case. In orderto find
this case for later use, it has to be indexedwith user goals
about the strategy howto find informationand goals about
the requestedinformationin termsof object perspectives.
The CAIRO System
Implementinga newversion of an interface system to
CORDIS
data aims at investigating the conceptof a casebased dialogue managerfor informationseeking dialogues
and to improvethe CADI
system. Thenewsystemfocuses on
the integration of informationseekingtasks and strategies
into the interface system.Therefore,westudiedresults from
cognitivetasks analysisof informationseekingprocesses,as
done by Belkin, Marchetti, and Cool, and implemented
most
functions they proposed. WemodifiedMERIT’s
interface
features anddesignedmoreflexible input formsfor user requests andinteractive displays for the presentationof retrievedd a!a~see an overview
in fig. 2.
Theusers’ requestfor information
Findknowndata is a special formof a search. Because
the user knows
the data itemshe canrecognizeit on a display,
or she canspecifyit bya nameor a uniqueattribute specification. Usuallyonedata itemwill be found,that candirectly be
presentedbythe detailedpresentation.
124
Search.If the user wantsto searchfor data, she usually
knowssomethingaboutthe data she is interested in, but the
specification maybe vagueand/or incomplete.For this kind
of user request weimplemented
a flexible input form. The
input formis titled by the mainconceptof the search, e.g.
’searchingfor projects’, andis restricted to a specific perspective onto the mainconcept,e.g. the project partners.
This perspectivedeterminestwolists of search attributes
whichwill be suggestedto the user, a first onewithattributes
that are closelyto the themeof the perspective,e.g. in the
project partner perspective’nameof partner organization’,
anda secondlist withattributesto limit the dataset, e.g. the
countryof a partner organization,or a program,the partner
shouldhaveexperiencewith: Therefore,the input formis dividedinto twoareas, onthe left side for gatheringdata(internally that is translated to an ’or’ combinationof search
terms),the other oneonthe right side for reducingthis data
(combined
by ’and’). This is an attemptto hide the logical
operators’and’and’or’ at the system’sinterface andto simplify the reformulation
of searchspecifications.
When
the user has acceptedthe suggestedsearch attributes,
she can formulateoneor moresearchtermsin a text field, or,
she selects searchtermsfroma list of suggestionsofferedby
the system.Then,a querywill be generatedanda simpleinformationretriever component
will start a substring search
in the informationspace.This kindof searchformis flexible
in that sense,that it presentsa wellpreparedpartitionof the
informationspace by the conceptof perspectives. However,
all suggestionscan be modifiedby the user interactively.
Browse.If the user wantsto browsethroughan information spacethe informationneedis onlyvague,is hard to formulateas a searchterm, or the user exploresthe information
space arounda specific knowndata item. In this case, the
goalof interactionis a kindof ’learning’. At fast, the user
needsa specification of the informationspace and then a
starting point for browsing.Theinformationspacecan be the
complete
data, or it canbe restricted to a specificsubsetlike
the currentretrieveddata, or a subsetstoredpreviouslyin the
ongoingdialogue. Thestarting point is alwaysa known
item,
that really exists in the database.Theinteractioncanbe done
without input forms. Browsingis a morepresentation orientedactivity than other types of requestsfor information.
Thesystempresentsinformationto the user andthe user only
selects an item to ask for moredetailed information.Consequently, browsingfunctionality is determinedby the functionality of interactivedisplaysof an interface system.
Onthe implementation
level, browsingmakesuse of the semantic net of domainconcepts in the domainknowledge
base, whichis implemented
in the framerepresentationlanguageCRL[cf. KC89]. Using’CRLrelations’, navigational
steps fromonedata item to related data items wereeasy to
realize. Browsing
is hard to handleat the system’sinterface.
Eachbrowsingstep maycreate a newwindow
and the screen
will soonbe overloaded,the well-known
problemof ’being
lost in hypertext’.Toavoidthis, wehaveonly oneoverview
andonelist display, onedisplayof details for eachconcept.
Anadditional display will only be generatedfor comparing
twoitemsof the samekind.
Thepresentationof retrieved information
Retrievedinformationcan be displayedin three different
kindsof interactivedisplays:a list displaypresentingall retrieved data, e.g. all retrievedprojects;an overview
display,
with requesteddata andall. related data presentedsimultaneously;a detaileddisplaywith detailedinformationabouta
single data item. Interactive displaysneedsomespecification of the interactiontakenplace directly on the presented
items. In CAIRO,
on overviewand detailed displays the
selection of an itemsmeansa requestfor detailed information. Onlists wehavevariousadditionalfunctions,so that
the user can manipulate
the list for later (re-)use duringthe
followinginteraction. Now,let us havea closer lookat each
kindof display.
Thelist displaypresentsall dataof the concept,the useris
lookingfor, in a list of interactiveitems.For example,
if the
user has specifieda searchfor projects, she will get a list of
project names.For the list, the systemoffers special functionality:to sort the list, to deleteitemsfromthe list, to mark
or unmark
itemson the list to create a subsetfor further operationslike storing in a subsetor on the historyof data. The
default for selectingan itemwith the mouseis to presentthe
detaileddisplayfor the chosendata item.
This kindof displaycan be easily extendedto a table presentation, presentingthe nameof the data conceptin the first
column,andattributes in further columns.Usingtables data
items can be presented according to object perspectives
whichdescribei.e. situationspecificsets of attributesof the
concept, e.g. the thematical perspective on programscontains attributes like title, generalinformation,andsubprograms,describingwhatthe programis about. A modification
of a perspectivecan easily be doneandpresentedto the user.
Themainproblemof presentingtables is the optimizationof
the table layout. For this reason, at the moment
wepresent
125
perspectiveswithouttables anduse lists of structureditems
instead.
Theoverviewdisplaypresentsall data sorted by the concept class they belongto. In our domainconceptsare e.g.
project, program,organization,person. Eachretrieved data
is presentedby a short namewhichis interactive, that means
that it canbe selectedbythe userto see details. It canbe used
as a starting point for browsing
in the informationspace.The
overview
displaycanbe usedto presenta specific set of data,
as the set of currentretrieveddata, the previousdata set, the
completedata set, or anyother data set whichcan be specified by the user. If the overviewis usedto displaythe retrieveddata, it canbe seenas an extensionof the list display,
wherethe retrieved data of the requestedconcept,e.g. projects, are presentedtogetherwithall the relateddata, the programof the project, the project partnerorganizations,andthe
contactperson.
Detaileddisplays. For each relevant conceptof the domainthere is onedetaileddisplay. It canbe filled automatically with informationabout a single data item. Someexamples: for the domainconcept’organization’CAIRO
presents
nameandaddress,andcountry, the projects in whichthe organizationparticipates in as a partner or primecontractor.
For the domainconcept ’program’the system presents the
acronym,the title, the number
of projects in the program,a
list of all projects that exist in the databasewith moredetailed information,a contactperson,anda descriptionof the
programandits objectives.
This kind of display providesseveral starting points for
browsing
activities. Interactive displayitemsare visualized
by specific boxesso that the user can easily recognizepossible starting points for browsingsteps. Toenablebrowsing
throughthe list of retrieveddata, the systemoffer buttonsto
go forwardor backward
directly withoutleavingthe display.
In additionto the browsingfunctionality, there are twonew
features, oneto compare
itemsanda secondto read longtext.
Tocompareitems CAIRO
presents two detailed displays in
two simultaneouslyvisible windows.
Askingthe user for feedback:Doyoulike it?
CAIRO
offers somechoicesto the user to formulateher
feedback,’I like it!’ or ’I don’tlike it!’, according
to the two
polarities selectingandlearningof the IS dimension
’goal of
interaction’. In eachpolaritythe user’soverall goalis quite
different.
In the ’selectionmode’,duringthe dialogueand, in particular, at the endof the dialogue,the user wantsto havea
kindof a result, usuallyin formof a set of dataitems.Different modifor the presentationof the result are conceivable:
directly on the screen, or as an electronic or printed document.Wewill supportthe ’selection’ modeat the user interface byan interactive history of retrieveddata, the user has
selectedfor intermediatestoringor storingas a result.
In the ’learningmode’,weassumethat the user is mainly
interested, to get a feelingwhatkind of information
is in the
database, for the granularity of stored information,howto
find relevant information,etc. Frommypoint of view,feedbackof the user makessense mainlyin the selecting mode.
At the moment,
there is no active user supportfor ’learning’.
Therefore,in this modeweonlyhide the data history to avoid
a cognitiveoverloadingduringthe learningprocess.
I like it! Let us assume
that the userwantsto ’select’ data
fromthe database, and that the user has answeredto a system’srequestfor feedbackthat ’she likes it’; ’it’ meansthe
list of - eventuallymanipulated- retrieved data. For this
case, CAIRO
places those items, whichare markedfor selection, ona history of selecteddata. Although
the data history
is part of a historyof dialogue
states [cf. Tilden91],it is visualized at the system’sinterface separatelyon a data stack.
There,the conceptnameis interactive anda click meansthat
the itemwill be presentedin detail again.Lateron, this history displayshouldbe manipulatable
as well as the list display
for retrieveddata.
! don’tlike it/If the user doesn’tlike the retrieveddat~,
the systemprovidessomesuggestionsfor modification,like
a reformulationof the search formulation,skippingthe current dialoguephase,switchingto the ’learn mode’to inspect
the database,thenformulatea newquery,etc.
Conclusions
Acknowledgements
I wouldlike to thankNickBelkinfor fruitful discussions
duringhis stay at IPSI, AdelheitStein for valuablecomments
on a previousdraft of this paper.
References
Agosti, M., Gradiengo,G., &Marchetti,P. G. (1992).
Ahypertextenvironment
for interacting with large textual databases. Information Processing & Management,
Vol.28, No3, 1992,p. .
Alterman,R. (1986).
AnAdaptivePlanner. in: Proc.of the 5th NationalConference on Artificial Intelligence, MenloPark, California. American
Associationof AI., 1986,pp. 65-95.
Alterman,R. (1988).
AdaptivePlanning. Cognitive Science, 12, 1988, pp.
393-421.
Belkin,N.J., andMarchetti,P. G. (1990).
Determining
the FunctionalityandFeaturesof an IntelligentInterface to an Information
RetrievalSystem.In: Vidick, J.-L. (ed.): Proc.of the 13thInt. Conference
on Research and Developmentin Information Retrieval
(SIGIR’90), Brussels/Belgium,1990,pp. 151-178
and Future Work
Belkin,N.J., Marchetti,P. G., Cool,C. (1993a).
BRAQUE"
Designof an Interface to SupportUserInterI havepresented CAIRO,
an interface systemto CORDIS
action in InformationRetrieval. InformationProcessing
d~!a,that is designedanddeveloped
as a dialoguesystem.In& Management,
Special Issue on Hypertext(in press),
formationseekingtasks andstrategies are integratedinto the
1993.
dialoguemodelandrelated to sequencesof dialoguesteps.
Belkin,N.J., Cool,C., Stein, A., &Thiel, U. (Belkinet al.
Usingknowledgerepresentation techniques, sequencescan
1993b)
be arrangedin a flexible wayandadaptedto user goals. For
controllingthe interaction, guidingthe user throughthe inScripts on InformationSeekingStrategies. to be presformationspace, andfor adaptationto user goalsI suggested
ented at" CBR-IR
workshop’93.
a case-basedapproach. Thenewimplementationprovidesa
CarberryS., (1988).
lot of flexibility for the interfacedesignandinteractionbeModelingthe User’s Plans and Goals. Computational
havior.
Linguistics(14/3), 23-37.
Mostimplementationsfor the newsystem are already
McCoy,
K. F., & Cheng,J. (1990).
done. Storer and retriever of the CADI
systemhave to be
Focusof Attention: Constrainingwhatcan be said next.
adapted to newcase indexes. Basic cases whichdescribe
In" NaturalLanguage
Generationin Artificial Intellivery typical tasks in our domaincan be taken from MERIT
gence
and
Computational
Linguistics. Paris, Swartout,
andextendedwith IS tasks andnewindexes.Individualcases
Mann
(Eds.).
Kluwer
Academic
Press, Norwell, MA.
can be generatedautomaticallybythe CADI
storer. It is still
an openquestion, howto handlethe interaction about user
Hammond,
K. (1989).
goals at the system’sinterface. This is a kind of metadiaCase-BasedPlanning. ViewingPlanning as a Memory
logue, whichis concernedwith the dialogueitself and not
Task.(Perspectives
in Artificial Intelligence;Vol.1), San
withdat~or the retrieval process.In particular,this is an imDiego, CA:AcademicPress.
portant issue for modeling
the introductiondialogue.This is
the dialoguephase,generalto all dialogues,to retrieve and
Hoff, A. van(ed.) (1989).
select a case fromthe case library whichmayhelp to solve
HyperNeWS
User’s Guide. The Turing Institute, Glasthe current informationseekingproblem.
gow, UK, 1989
126
Ingwersen, P. (1992).
Information Retrieval Interaction. Taylor Graham,London, UK. 1992.
Schank, R, and Abelson R. (1977).
Scripts, Plans, Goals, and Understanding. Lawrence
ErlbaumAssociates, Hillsdale, N.J.
Kerner, A., and Thiel, U. (1991).
Graphical Support for Users’ Inferences within Retrieval
Dialogues. In: Proc. of IEEE Workshopon Visual Languages, Kobe/Japan. Los Alamitos, CA: IEEE Computer Society Press, 1991, pp. 211-216
Sitter, S., and Stein, A. (1992).
Modeling the Illocutionary Aspects of InformationSeeking Dialogues. Information Processing & Management, Vol. 28, No2, 1992, pp. 165-180
Stein, A., Thiel, U., and Tilden, A. (1992).
KnowledgeBased Control of Visual Dialogues in Information Systems. In: Proc. International Workshopon
Advanced Visual Interfaces, Rome, Italy, May27-29,
1992.
KC(1989).
KC- Knowledge Craft Manual, version 4.0, Carnegie
Group Inc., 1989
Kolodner, J. L., and SimpsonR. L. (1986).
Problem Solving and DynamicMemory.In: Kolodner, J.
L., and Riesbeck, C. K. (eds.): Experience, Memory,and
Reasoning.Hillsdale, NJ., 1986, pp. 99-114
Reichman, R. (1989).
Integrated Interfaces Based on a Theoryof Context and
GoalTracking. In: Taylor, M.M.,et al. (eds.): TheStructure of Multimodal Dialogue. Amsterdam: North-Holland, 1989, pp. 209-228
Riesbeck, C. K., and SchankR. C. (1989).
Inside Case-BasedReasoning. HiUsdale, N J: Lawrence
Erlbaum, 1989.
T~en, A. (1991).
A Case-Based Architecture for a Dialogue Managerfor
Information-SeekingProcesses. In: Bookstein, A., et al.
(eds): Proc. of the Fourteenth AnnualInt. Conference
Research and Development in Information Retrieval
(SIGIR ’91). NewYork: ACM
Press, 1991, pp. 152-161.
TlBen, A. (1993).
Knowledge Bases for User Guidance in Information
SeekingDialogues.in: Wayne,D. G., et al. (eds.): Proc.
of the 1993 International Workshopon Intelligent User
Interfaces (IWUI ’93). Orlando/Florida, U.S.A., New
York: ACM
Press, 1993, pp. 149-156.
127