Re: HM.applications-Profiling-Level of Details/Abstraction

[Kurt Cagle <cagle@olywa.net>]

If my children are any indication, the Bugs Bunny avatar would probably be
more authoritative <sigh/>

I'd caution everyone here that we need to insure that we're not trying to
make HumanML to expansive in scope. Real world scenarios: the auto industry
will likely end up adopting its own schema for representing automotive
information (telematics is a very highly evolved area in its own right).
Effectively, HumanML here makes sense relative to the passengers, but even
here you need to take into account the interfaces necessary to notify the
car of this information. Let me give you a few interface scenarios to chew
on -

Scenario 1: Mom, Pop, Katie (8) and Jennifer(1 1/2) all get into the car.
Each have assigned seats (primarily because of the fact that the kids have
car-seats, which limits the amount of movement that can take place). Each
seat has two sensors, one in the seat bottom itself that measures the weight
being put on it (to within maybe 10 kg), the second sensor being one in the
belt that indicates that the person is strapped in. A small (let's say SVG)
diagram on the dashboard can be set to show each person that's expected to
be there, if the weight sensors are picking up demonstrably more weight than
they would in the empty state. The car can configure its options based upon
which seat sensors indicate they are occupied -- the onboard rear
entertainment unit dials into a list of options for Katie (her homework,
approved entertainment packages (books, websites, games), etc.), and plays
music for Jennifer to help her get to sleep; the units for mom, on the other
hand, would include a more advanced selection of entertainment units as well
as a control center for the back end entertainment units. The information
passed back and forth here could concievably be SOAP wrapped HumanML, though
it could just as easily be RDF linkages. The important thing is that the car
can determine based upon a standard configuration who is actually in the
car.

Scenario 2: Switch the kids in the back. The HumanML system now has to
recognize that not only have conditions changed, but still make an educated
guess about what happened. Thus, there is a need for an inference engine at
play here (objKatie no longer registers a weight and her belt buckle has
disengaged, but no doors have opened and no undue accelerations have been
felt. Inference: Katie is moving. This should notify the drivers monitor of
course, but when objJennifer seat also returns an empty value, then both
seats then register knew weights, the system, must be able to perform
another set of inferences: if objKatie.weight=seatKatie.expectedWeight then
Katie has returned to her seat, while if
objKatie.weight=seatJennifer.expectedWeight then Katie has moved into
Jennifer's seat (of course, if seatJennifer.expectedWeight=objKatie.weight +
objJennifer.weight then both kids are in there, and things can get mighty
confused in inference land).

Scenario 3: You give a ride to a friend of yours. The friend weighs roughly
as much as your wife. the HumanML interfaces will indicate that it is in
fact your wife unless you indicate that its not. The driver should then be
able to create a generic HumanML profile, though heor she could assign
permission for the person in that seat to edit their profile if they ride
frequently with the friend. Thus interface becomes a critical part of the
scenario for both authentication (your wife probably doesn't want your
friend to have access to her profile, for instance) and for personalization
(your friend likes the seat in a different position than your wife), and
additionally, ACLs tend to descend from the administrator (the driver) on
down.

Scenario 4: You put a couple of boxes of books in the back seat, which way
approximately the same as Kate. The only thing that the car will know unless
you explicitly tell it is that her seatbelt is unbuckled.

Scenario 5: The information that the car has is being sent to a central
nexus periodically, as an agreement between the automobile manufacturer and
direct marketers, which means that your car is in many ways a marketing
dream -- people who are completely identified, that have a readily
retrievable profile (either the one in the car or the one to be achieved by
inference through the marketer's own database), that are captive, and that
typically are bored.Children especially make very tempting targets in this
respect.

Scenario 6. This information can also be subpoena'd by the police, or used
for surveillance. This means that when the car indicates that the driver is
Joe Smith and his vehicle is currently going 68 miles in a 65 mile an hour
zone then local authorities now have extremely high circumstantial evidence
of a correlation between driver and speeding. It also means that a traffic
cop could effectively identify a speeder, correlate that speeder with his
records based upon HumanML, retrieve a listing of all previous traffic
violations, and charge him with another one, all without leaving the donut
shop. Neither of the last two scenarios are exactly palatable.

I raise the last two to bring up another point. Security and safety are
often used as reasons to get profile information, but there are almost no
examples I can think of where this information didn't ultimately end up
being used, and abused, either by marketers or governments.

This is somewhat meandering, so I'll try to summarize what I'm trying to
say: HumanML is fundamentally tied to identity. In essence what HumanML
tries to do is to attempt to envision at least one facet of the real world
through a model it has created -- the HumanML is a human from the machine's
standpoint. The richer the sensory mechanism used to retrieve information
about the outside world, the better the model, but additionally the easier
it is for the model to be abused.

I'll go into quiet mode now.

-- Kurt Cagle


----- Original Message -----
From: "Bullard, Claude L (Len)" <clbullar@ingr.com>
To: "Sean B. Palmer" <sean@mysterylights.com>;
<humanmarkup-comment@lists.oasis-open.org>
Cc: <raytrace@smtp.cs.curtin.edu.au>
Sent: Friday, September 07, 2001 12:07 PM
Subject: RE: HM.applications-Profiling-Level of Details/Abstraction


> An interesting scenario because it can use a lot
> of recent topics the more I think about it:
>
> o  SOAP message is created and sent to 911 dispatch
> center
>
> o  SOAP message is used to activate alert on driver's
> cell phone (might be dad)
>
> o  Car loaded with HumanML data sends ID (VIN) to
> 911.  911 dipatches and sends SOAP plus VIN onto
> Motor Vehicle Check to confirm.  Car was loaded
> with HumanML when purchased and in fact, that
> data and datatype matches the public safety
> records and other e-gov systems.
>
> Can't simply turn on engine or roll down windows
> (dangerous - these are children).
>
> Can't simply unlock doors but that would be last
> option.  Why:
>
> o  Children are young and unsupervised
>
> Requires very enabled-car and manufacturer
> might not build it and owner might not own one
>
> so a communications solution is cheap and available.
>
> Same computer that displays avatar might be entertaining
> the children so system might stop that one and put
> up one that is authoritative (eg, kid laughs at Bugs
> Bunny no matter what, but an avatar of Mom or Dad
> would be recognizable).
>
> So it has to reason out the set of alternatives.  The
> optimum is to get the adult back to the car, but should
> quickly send the 911 message.  Use of the avatar is optional
> but it could pacify the child or prompt the child to action,
> and anyway, we have the need to demonstrate emotional
> message controls and VHML is a good way to do that because
> it has facial, gestural and voice inflection attributes.
>
>
> Len
> http://www.mp3.com/LenBullard
>
> Ekam sat.h, Vipraah bahudhaa vadanti.
> Daamyata. Datta. Dayadhvam.h
>
>
> -----Original Message-----
> From: Bullard, Claude L (Len)
> Sent: Friday, September 07, 2001 1:33 PM
> To: Sean B. Palmer; humanmarkup-comment@lists.oasis-open.org
> Cc: raytrace@smtp.cs.curtin.edu.au
> Subject: RE: HM.applications-Profiling-Level of Details/Abstraction
>
>
> **including Sean's realization of the example here***
>
> Beautiful Sean!
>
> To make that a little easier, the authors summarize
> analogy as "deliberate analogy" and it works like
>
> "Given a task with an item Y that is a member of a specific category,
recall
> how to perform the same task with another member, X, of the same category,
> then do what you would do for X, except replace all occurrences of X by
Y."
>
> The implication of course is that the system matches and tries
> a similar action.  If it works, it adds that fact to the knowledge
> base.  If it doesn't, it tries something else.
>
> There is an old rule of thumb about analogical systems that
> says "don't play zero-sum games", or by example, don't play
> Russian/American roulette.
>
> We're getting example bound, but the idea is to show
> that the levels of detail are hard to come by without
> a working example, and the example can be chosen from
> scenarios.
>
> To complete this for a proto-prototype, we might
> try to show how this information would be used
> by the VHML avatar to demonstrate or explain
> to a car user how to turn on the air conditioner.
> More specific and a bit tougher
> given a hot car with children in it, how to show the children.
> (let's say they do have the key and we don't want them
> to get out of the car.  This isn't realistic but
> I don't want to make a harder example.).
>
> For VHML to be more than static presentation,
> it requires an interface back to a sensor-active
> system with a contextual knowledge base.  Now,
> children shouldn't be scared into doing something
> and might be panicked, might be strapped in, etc.
> So the VHML capability to control emotion given
> a situation, a context, and a particular human
> with particular characteristics would be a very
> effective communicator.
>
> Car detects temperature, children in children's
> seats.  Knows children's names, weights, ages
> (humanML facts) and has a set of vocabularies
> it can select from given these facts.  Also
> knows mother's cell phone and local public
> safety systems numbers (child might fail to
> act and/or temperature is increasing fast).
>
> An example more useful than a refrigerator
> telling an oven the temperature to cook
> pizza at is useful.
>
> Len
> http://www.mp3.com/LenBullard
>
> Ekam sat.h, Vipraah bahudhaa vadanti.
> Daamyata. Datta. Dayadhvam.h
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>