A: and it would probably you wouldn't just sort of remember that they sell stuff and then deduce from that that it must be going on inside or something .
E: Well I think an entity maybe should be regard as a vector of several possible things ,
E: it can either em do s do sell things , fix things , service things , exhibit things , it can be a landmark at the same time as doing these things ,
A: Mm - hmm .
E: it 's not either or
E: mmm certainly a place can be a hotel and a famous site .
A: Mm - hmm .
E: Many come to mind .
E: Things can be generally um a landmark and be accessible .
E: IE a a castle
E: or can be a landmark a or not accessible , some statue
A: Mm - hmm .
E: you know can go inside .
B: OK .
B: Anyway so let me suggest you do something else .
B: Uh which is to get rid get rid of that l long link between who the user and the endpoint .
E: Could we just move it like this ?
B: No no , I don't want the link there at all .
E: Oh , OK .
B: Because what we 're gonna want is an intermediate thing
B: which is uh the endpoint decisi the endpoint decision based o on the user models ,
B: so what we we what we talked about is three separate endpoint decisions ,
B: so let 's make a new node
E: Yeah .
E: Yeah .
C: Just as a suggestion maybe you could " save as " to keep your old one nice and clean
C: and so you can mess with this one .
E: Mmm .
E: The old one was not that not that important , I think
E: but
C: OK , well , not a big deal then .
E: Let 's do it then .
C: Well the C: Isn't there a " save as " inside of java base ?
E: But I can just take this
C: OK .
E: copy it somewhere else .
E: This was user something
E: or
B: Well this was
B: uh let 's p put it this let 's do endpoint underbar - U .
E: end point ?
B: i endpoint , e end poi
B: this is sa
E: Ah .
B: it 's the endpoint
E: Gotcha , yeah .
B: let 's say underbar - U ,
B: so that 's the endpoint decision uh as seen through the
C: As related from the user model .
B: Right .
B: So let 's let 's actually
B: yeah so lin you can link that up to the
E: Should I rename this too ?
B: uh yeah , so that , I guess that 's endpoint uh
E: It 's underscore - E .
B: underscore - E for entity ,
B: and we may change all this ,
B: but .
B: Right .
B: And
E: OK , shouldn't I be able to move them all ?
E: No .
E: Or ?
E: Can I ?
E: Where ?
E: What ?
B: Oh I d eh I don't know .
B: Actually , I guess the easiest thing would move mo move the endpoint ,
B: well , go ahead .
B: Just do whatever .
E: Wasn't this possible ?
B: Well .
E: Yeah .
C: I think you have to be in move mode before
E: Uh - huh .
E: OK .
B: Good .
B: Right .
E: So now we 're looking for user related things that um
B: Yeah .
B: And uh maybe th maybe it 's just one who is the user ,
B: I don't know ,
B: maybe maybe there 's more .
A: Huh .
E: Well if he 's usi if he 's in a car right now
E: what was that
E: people with Harry drove the car into the cafe
B: Never mind .
B: Uh anyway , this is crude .
B: Now but the now so so but then the question is
B: uh
B: so and and we assume that some of these properties would come indirectly through an ontology ,
B: but then we had this third idea of input from the discourse .
E: Well let 's should we finish this ,
E: I mean but surely the user interests
B: Sure ,
B: OK .
C: The user thrift ,
C: the user budget .
E: yeah , yeah
B: Well , maybe ,
B: I again , I d
B: well , OK , put em in
B: but what we 're gonna wanna do is actually uh
C: Well is E: Here this was one of my problems
E: we have the user interest is a is a vector of five hundred values ,
E: so
E: um That 's from the user model ,
D: Oh you mean level of interest ?
E: mm - hmm ,
E: no not levels of interest
E: but things you can be interested in .
A: Well B: somebody else has built this user model .
E: Gothic churches versus Baroque townhouses versus
D: Oh I see ,
D: right .
D: So why is it
D: oh it , so it 's like a vector of five hundred one 's or zero 's ?
E: Yea - n is that
D: Like for each thing are we are you interested in it or not ?
E: yeah
E: uh I I think
D: I see .
A: Hmm .
B: OK .
B: So uh you cou and so here let me give you two ways to handle that .
B: Alright ?
B: One is um you could ignore it .
B: But the other thing you could do is have an B: and this will give you the flavor of the of what
B: you could have a node that 's that was a measure of the match between the object 's feature , you know , the match between the object the entity , I 'm sorry and the user .
E: Mm - hmm .
E: Uh .
B: So you could have a k a " fit " node
B: and again that would have to be computed by someone else
E: Mm - hmm .
B: but uh
B: so that uh
E: Just as a mental note
E: uh
B: Yeah , that 's all .
E: Mm - hmm .
E: And and should we say that this interests eh affects the likelihood of of entering ?
B: Yeah .
B: I mean , we could .
E: Yeah .
E: And also if it 's an expensive place to enter , this may also
B: OK .
D: Budget .
A: User schedule .
E: Schedule ?
A: " Do I have time to go in and climb all the way to the top of the Koelner Dome <comment> or do I just have to " " time to take a picture of the outside ? "
B: Right .
C: It seems like everything in a user model a affects B: Well that 's what we don't wanna do ,
B: see that se
C: Yeah .
B: cuz then we get into huge combinatorics and stuff like that
A: Mm - hmm .
B: an
C: Cuz if the , I mean , and if the user is tired , the user state ,
D: Well
C: right ,
C: it would affect stuff ,
C: but I can't see why e anything w everything in the model wouldn't be
B: Well , but
D: Right .
B: Well , that that 's we can't do that ,
B: so we we 're gonna have to
C: Yeah .
B: but this is a good discussion ,
B: we 're gonna have to somehow figure out uh some way to encapsulate that
B: uh so if there 's some general notion of for example the uh relation to the time to do this to the amount of time the guy has or something like that is is the uh compatibility with his current state ,
B: so that 's what you 'd have to do ,
B: you 'd have to get it down to something which uh was itself relatively compact ,
B: so it could be compatibility with his current state
B: which would include his money and his time and and his energy
C: Yeah , just seems like it 'd push the problem back a level .
D: Right .
B: It does .
C: Yeah , but
A: Mm - hmm .
D: No but , it 's more than that ,
D: like the the more sort of you break it up
D: like because if you have everything pointing to one node it 's like exponential
D: whereas if you like keep breaking it up more and more it 's not exponential anymore .
B: So it yeah , there are two advantages .
B: That 's tha there 's one technical one
C: Sh - sh
C: yeah , B: and the other is it it gets used
C: S so we 'd basically be doing subgrouping ?
C: Subgrouping , basically
D: Yeah .
C: into mo
C: so basically make it more tree like going backwards ?
D: Right .
A: Yeah .
B: Right .
B: But it there 's two advantages ,
B: one is the technical one that you don't wind up with such big exponential uh CBT 's ,
E: Bhaskara ?
B: the other is it can be it presumably can be used for multiple decisions .
A: Mm - hmm .
B: So that if you have this idea of the compatibility with the requirements of an action to the state of the user one could well imagine that that was u
D: Right .
B: not only is it sim is it cleaner to compute it separately but it could be that it 's used in multiple places .
B: Anyway th so in general this is the design , this is really design problem .
E: Yeah .
B: OK , you 've got a signal , a d set of decisions
B: um how do we do this ?
E: What do I have under user state anyhow
E: cuz I named that already something .
E: Oh that 's tired , fresh ,
E: yeah .
E: Maybe should be renamed into physical state .
B: Or fat user fatigue even .
A: Hmm .
E: That 's with a " G " ?
A: Mm - hmm .
B: Whatever .
E: Then we can make a user state .
B: What 's th what we 're talking about is compatibility .
B: Uh or something , I don't know ,
B: but .
C: I guess the the question uh is
C: It 's hard for me to imagine how everything wouldn't just contribute to user state again .
C: Or user compatibility .
B: Oh but the thing is that we uh uh we had some things that uh
E: That don't .
B: that don't
E: The user interests and the user who who who the user is are completely apart from the fact whether he is tired broke
C: Sure , but other I thought though the node we 're creating right now is user compatibility to the current action ,
C: right ?
B: the
B: right
C: Seems like everything in the user model would contribute to whether or not the user was compatible with something .
B: Uh maybe not .
B: I mean the that 's the the issue is um
B: would Even if it was true in some abstract general sense it might not be true in terms of the information we actually had and can make use of .
B: And anyway we 're gonna have to find some way to cl uh get this sufficiently simple to make it feasible .
E: Maybe um if we look at the if we split it up again into sort of um
E: if we look at the uh the endpoint again we we said that for each of these things there are certain preconditions
E: so you can only enter a place if you are not too tired to do so
E: and also eh have the money to do so if it costs something
E: so if you can afford it and perform it is preconditions .
E: Viewing usually is cheap or free .
E: Is that always true ?
A: Mm - hmm .
E: I don't know .
C: Well , with the way we 're defining it I think yeah .
B: W w
B: but that eh viewing it without ent yeah view w with our definition of view it 's free
B: cuz you
E: And so is approaching .
B: Yeah .
A: Well what about the Grand Canyon ,
A: right ?
A: No , never mind .
A: I mean are there are there large things that you would have to pay to get up close to
A: like , I mean
A: never mind ,
A: not in the current B: No we have to enter the park .
A: OK .
B: Eh almost by definition um paying involves entering ,
A: Yeah .
B: ge going through some
A: OK .
A: Right , sure .
B: Right .
B: Uh
B: So let me suggest we switch to another one ,
B: I mean clearly there 's more work to be done on this
E: Mm - hmm .
B: but I think it 's gonna be more instructive to to think about uh other decisions that we need to make in path land .
B: And what they 're gonna look like .
C: So you can save this one as and open up the old one ,
C: right
C: and C: and then everything would be clean .
C: You could do it again .
B: Why , I think it 's worth saving this one
B: but I think I 'd I 'd like to keep this one
D: Yeah .
B: cuz I wanna see if if we 're gonna reuse any of this stuff .
C: Mm - hmm .
E: Um
E: so this might be
E: What next ?
B: Well you tell me ,
B: so in terms of the uh planner what 's what 's a good one to do ?
E: Well let 's th this
E: go there or not I think is a good one .
B: Uh
E: Is a very basic one .
E: So
E: what makes things more likely that E: So
B: Well the fir see the first thing is , getting back to thing we left out of the other is the actual discourse .
B: So Keith this is gonna get into your world
B: because uh we 're gonna want to know you know , which constructions indicate various of these properties
A: Mm - hmm .
B: s
A: Mm - hmm .
B: and so
B: I I don't yet know how to do this ,
B: I guess we 're gonna wind up pulling out uh discourse properties like we have object properties
B: and we don't know what they are yet .
A: Mm - hmm .
B: So that that the Go - there decision will have a node from uh discourse ,
B: and I guess why don't we just stick a discourse thing up there to be as a placeholder for
E: We we also had discourse features of course for the endpoint .
B: Of of course .
E: Identified that
B: Yeah .
E: and so again re that 's completely correct ,
E: we have the user model , the situation model here ,
E: we don't have the discourse model here yet .
E: Much the same way as we didn't we don't have the ontology here .
B: Well the ontology we sort of said we would pull these various kinds of properties from the ontology like exhibiting , selling , and so forth .
E: Really .
B: So in some sense it 's it 's there .
E: Mm - hmm .
B: But the discourse we don't have it represented at all yet .
E: Yeah .
E: Um
E: This be specific for second year ?
E: Um
E: And and we probably will have uh something like a discourse for endpoint .
B: But if we do it 'll have the three values .
E: Hmm ?
B: It 'll have the EVA values
E: Yeah .
B: if if we have it .
E: Yeah .
E: OK just for starters
E: and here discourse um
B: For Go - there , probably is true and false , let 's say .
B: That 's what we talked about .
E: um
E: well , I think um we 're looking at the the little data that we have ,
E: so people say how do I get to the castle
E: and this usually means they wanna go there .
A: Mm - hmm .
E: So this should sort of push it in one direction
B: Right .
E: however people also sometimes say how do I get there
E: in order to find out how to get there
E: without wanting to go there .
B: Mm - hmm .
E: And sometimes um people say where is it
A: Mm - hmm .
E: because they wanna know where it is
E: but in most cases they probably
B: Yeah , but that doesn't change the fact that you 're you want these two values .
E: Oh yeah ,
E: true .
E: So this is sort of some external thing that takes all the discourse stuff
E: and then says here it 's either yep , yay , A , or nay .
E: Yeah .
E: OK ?
B: And they 'll be a y uh , a user Go - there
B: and maybe that 's all ,
B: I don't know .
D: Situation Go - there ,
D: I mean , because it 's whether it 's open or not .
E: Mm - hmm .
B: OK , good .
D: That definitely interes
B: Yep .
D: But that now that kind of
D: um what 's the word
A: Hmm .
D: um the that interacts with the uh EVA thing
D: if they just wanna view it then it 's fine to go there when it 's closed
D: whereas if they want to um
B: Right .
D: so
B: Right , so that 's that 's where it starts getting to be uh uh essentially more interesting ,
B: so what uh Bhaskara says which is completely right is if you know that they 're only going to view it then it doesn't matter whether it 's closed or not
A: Mm - hmm .
B: in terms of uh uh you know , whether whether you wanna go there .
D: The time of day ,
D: right
D: I well , right .
A: Mm - hmm .
C: It does matter though if there 's like a strike or riot or something .
B: Absolutely there are other situational things that do matter .
D: Right .
D: So
D: yeah , that 's what I said
D: just having one situational node may not be enough
D: because this that node by itself wouldn't distinguish
B: Well i i it can have di various values .
B: Yeah , but we eh you you 're right it might not be enough .
D: Yeah , I mean , see I 'm I 'm thinking that any node that begins with " Go - there " is either gonna be true or false .
A: Well , what A: Whoops .
B: Yeah .
A: Right .
B: Ah .
B: I see
B: that could be .
A: Also , that node , I mean the Go - there s S node would just be fed by separate ones for
E: Mm - hmm .
B: Could be .
A: you know , there 's different things , the strikes and the
B: Yeah .
D: Like situation traffic and so on .
B: N
B: Yeah .
A: Yeah , the time of day .
B: Yeah . So so now the other thing that Bhaskara eh pointed out is what this says is that uh there sh should be a link ,
B: and this is where things are gonna get very messy
B: from the endpoint uh decision
D: I guess the final
B: maybe the t they 're final re and , I guess the very bottom endpoint decision uh to the Go - there node .
B: And I don't worry about layout ,
D: Yeah .
B: I mean then we 'll go we 'll go nuts
E: Mm - hmm .
D: Mmm .
B: but
D: Maybe we could um have intermediate node that just the Endpoint and the Go - there S node sort of fed into ?
B: Could be ,
B: yeah .
D: Right .
D: Because that 's what we , I mean that 's why this situation comes up .
B: Yeah .
B: Well the Go - there , actually the Endpoint node could feed feed into the Go - there S
D: Yeah , right .
B: That 's right ,
B: so the Endpoint node ,
E: Mm - hmm .
B: make that up t t to the Go - there then
E: Yeah .
B: and again we 'll have to do layout at some point ,
B: but something like that .
B: Now it 's gonna be important not to have loops by the way .
E: I was just gonna
B: Uh really important in in the belief worl net world not to have loops
B: uh
D: Yes .
E: How long does it take you to to compute uh
B: No it 's much worse than that .
B: It if i loo it it it it it 's not def i it 's not well defined if you 're there are loops ,
D: It things don't converge , yeah .
E: uh R recursive action ?
B: you just you have to
B: there are all sorts of ways of breaking it up so that there isn't
B: uh
E: Uh but this isn't , this is this line is just coming from over here .
B: OK .
D: Yeah .
D: Yeah .
B: Yeah , no it 's not a loop yet , I 'm just saying we we , in no , in
E: Mmm .
D: Well , but the good thing is we we could have loopy belief propagation which we all love .
B: Right .
B: OK , so anyway , so that 's another decision .
B: Uh what 's what 's another decision you like ?
E: OK , these have no parents yet , but I guess that sort of doesn't matter .
E: Right ?
B: Well , the idea is that you go there , you go comes from something about the user from something about the situation and the uh the discourse is is a mystery .
E: I mean this is sort of
E: This comes from traffic and so forth , yeah .
E: Sh - Should we just make some
B: Sure , if you want .
E: um
E: if there 's parking maybe
E: Mmm
E: Oh who cares .
E: OK .
E: And if he has seen it already or not and so forth ,
B: Right .
E: OK .
E: Um
E: and discourse is something that sort of
E: should we make a Keith note here ?
E: That sort of comes from Keith .
B: Sure .
B: Mm - hmm .
E: Just sort of so we don't forget .
E: Oops .
E: Have to get used to this .
E: OK ,
E: whoops .
A: Um actually B: And then also the discourse endpoint ,
B: I I guess endpoint sub - D is if you wanna make it consistent .
C: Wh - ah .
E: Mm - hmm .
A: Um actually is this the the right way to have it
A: where um go there from the user and go there from the situation just sort of don't know about each other but they both feed the go there decision
B: I think so .
A: because isn't the , I mean
B: S
A: uh ,
A: hmm
A: OK .
B: Maybe not ,
A: But that still allows for the possibility of the of the user model affecting our decision about whether a strike is the sort of thing which is going to keep this user away from B: a
B: Right .
A: That all that that kind of decision making happens at the Go - there node .
B: Uh y you yeah you i you if you needed to do that .
A: Uh .
A: If you needed it to do that .
B: Yeah .
A: But uh OK I was just thinking
B: Yeah .
A: I guess maybe I 'm conflating that user node with possible possible asking of the user
A: you know
B: Ah .
A: hey there 's a strike on , uh does that affect whether or not you wanna go or something
B: Good point , I don't I don't know how we 're going to t uh
A: or
A: Yeah , so that might not come out of a user model
A: but , you know , directly out of interaction .
B: Right .
B: Uh I gu yes my curr you know , don't yeah yeah yeah that 's enough .
E: Yeah .
B: Uh My current idea on that would be that each of these decision nodes has questions associated with it .
A: Mm - hmm .
B: And the question wouldn't itself be one of these conditional things
B: you know , given that you know there 's a strike do you still wanna go ?
A: OK .
A: Yeah .
B: But uh if you told him a bunch of stuff , then you would ask him do you wanna go ?
A: Mm - hmm .
B: But I think trying to formulate the conditional question , that sounds too much .
A: OK .
A: Right , right .
A: Yeah .
A: Right , sure , OK .
B: To me .
E: Mm - hmm .
B: Alright , but let me let let 's stay with this a minute