#!text
    H(X,Y) -- if X hates Y?

    meh. Can predicate logic do do R(X, Y) and get the 'relationship value'? or is it simply limited to boolean predicates (you'd think so given the name ;))

    There exists an x such that X hates TOM

    How would "I was at <the market> at <time>" be stored?

    First order logic would allow us to bust out random implication operators
    though...

    Do I want anything prolog like, or is it just a big database of facts?

    a maximum of 1 unknown?
    if no unknowns the person can still agree/disagree (or learn a new fact...)

    what about multiple matches? e.g.:
    "list all the people you know that hate X"
    if you've found out that TOM loves JANE, you might want to also find out who
    else loves JANE

    or maybe you've found out that TOM and JOHN are rivals, maybe they love the
    same person. You need to be able to ask "which multiple things match this",
    i.e.

        TOM loves JANE
        TOM loves SANDRA
        JOHN loves JANE
        JOHN loves BLOSSOM


        ? loves ?
    is not a valid query
        TOM loves ?
        JOHN loves ?

    are both valid, but it will take a while for the player to cross reference.
    How about some kind of multi query:

          TOM loves  ?:1
        + JOHN loves ?:1

    where ?:1 is the same entity. So facts are only returned if they satisfy
    that.

    obviously asking someone "do you know of multiple people who like the same
    person?" is not a single wildcard



    not/negation

    <A> <location> at <time>
    <A> <location> at <time> : WHERE A IS PERSON?
    <A> <location> at <time> : WHERE A IS SUSPICIOUS?
        # or have a separate:
        # see anything suspicious at <location/time> ?
        # see <person> at <location/time> -- but then that rules out seeing a door open?
        # hear <person> at <location/time>
        #     need a 'suspicious' function

    <A> relationship <B> = <relationship>       # is this employer/employee or
                                                #   likes/dislikes?
                                                # maybe that should be
                                                #'relation'?
    <A> <relationship-time> <B>                 # how long have you known?
                                                #   maybe a full history of
                                                #   status -change?
                                                #   i.e. a butler might go:
                                                #   meet, interview,
                                                #   hired, friend+employer etc?

    <A> <like/dislike> <B>                      # really just a partial
                                                #   application of
                                                #   relationship/feelings


    "what colour hair did <the person> have?" (where the person is the person
    that replied with, drag 'n' dropped into this question somehow to create a
    reference)

the first python prototype used reference to actual People objects to create the fact-queries. I don't know if this is a great idea.....

you either have to always do a DNS style "what person-object does this name resolve to?"  before talking to anyone, which is pretty robot and mundane (though the gui would probably do all of this behind the scenes?). But what happens if the person knows multiple Toms? I guess even then we have actual Person objects to reference to query about, so maybe it's not a problem.

However: Imagine:
    asking person A who tom is and getting a reference to person T
    asking person B if person T has red hair

how is person B meant to know who person T is??! This is basically a hack on the player's part, as player B might be a confidont of person T and deny all knowledge, but eventually give in if we demand information using an exact name etc. So if we have the actual person object easily obtained from elsewhere, then what happens here?

Interestingly, all of this needs to work with psuedo people. i.e., let's say there IS:
       a person @0x1234. Coachman/Thief
       a person @0x5678. Butler

 the butler knows the coachman and builds a 'fact base' about that coachman. But at nights the coachman leads a double life, goes by a different name, and possibly dons all sorts of disguises!  How is the butler meant to hold information about both projections of people?

I guess we need to model actual people and perceived-people as different things?
each actual person also needs some kind of cache of perceived people, so when being interviewed by the player the people a) know which Tom is being talked about b) if the player has reached any kind of information tipping point on a subject that prevents the person being candid and c) to know when to reject requests about random person objects that the player obtained from elsehwere and hasn't asked THIS person about.

Tom loves suzy.

I don't know their name, but the person has Green hair.

# todo: all facts should be tagged with:
#    origin(time, person/object, location)
# probably need some way to fuzz them, i.e. list the time and person
# as unknown. also, might want to store ACTUAL value and PERCIEVED
# value. i.e. WAS 10:00, thoguht 9:00. WAS geoff, thought june.
# or should that always be derived from fuzzing when being spoken to?
# arguably this origin tag is a space/time fact... though that
# creates a strange dependency, as all facts will need one.
# perhaps a space time fact is simply an fact with nothing but
# an origin?

# also need to support no origin, i.e. from queries
# and also the ability to modify queries with time? i.e. not just
# "who has brown hair" but "who has brown hair in the last week?"
#
# which also raises: Is "I saw X and they had these features"
# difference from "I know X has these features". I would guess so.

# will we need a way to hash/compare just the non-origin-tagged
# parts of the fact? Or possibly even some way to bucket them in the
# store together based on these things?

# What about slight differences in value? e.g. if someone's love/hate
# for someone grows over time:
#    (now-4 month) Goeff loves-value 0.2 June
#    (now-3 month) Goeff loves-value 0.4 June
#    (now-2 month) Goeff loves-value 0.6 June
#    (now-1 month) Goeff loves-value 0.8 June
#    (now   month) Goeff loves-value 1.0 June
#
# How do we store this? how do we group this? How do we get
# asked questions about this and know how to respond to questions
# about the current value and the historical value
# (e.g. "when did geoff first fall in love with june"
#
# some kind of clever grouping span object based on the speed of
# increase? "Geoffs love for june grew [rapdily|slowly|]"
# (speed is based on the normal growth of love-value)
#


# exact duplicates due to repeated observation in simulation

# one value can corrupt another, depending upon emotional impact
# i.e. when adding "(now) geoff hates june" to geoff, that might want to
# completely delete "(year ago) goeff loves june"? Or maybe just
# "deny" that fact at ask-time.

first glance: old/middle/young
older than me? mid-40s?
maybe they refer to you being younger/older than them
maybe they refer to the fact they had a 40th birthday no so long ago
    (so you learn now, that this person previously had a 40th birthday, and that previously wasn't that long ago. getting a bit prologgy here)

maybe they tell you their age
maybe they tell you their birthday (but not age? and also with age)

# todo: we can't just have a global god-fact time.
# each person needs to track their own time, and that tracking is
# prone to corruption.
# e.g. scatterbrains will track time more poorly than others

# therefore there needs to be a god-fact time, and watches etc
# and people to track time. and important during  scenario creation
# we need to .tick() people, and when they learn facts they need to
# tag god-fact time, their-own time, etc.
#
# If they've just looked at a watch, for instance, (assuming the
# watch is set correctly), then they calibrate their own internal
# time.
#
# this might also imply we need a PersonX class for scenario creation
# that is mutated and time-ticked, and that pops out a Person
# class on completion. (or maybe that's not required, who knows? :))