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

["Bullard, Claude L (Len)" <clbullar@ingr.com>]

Public safety systems already have all of that 
information.  If it is abused, that is already a 
problem.   But it is much worse if that is not in a 
standard form because then when it can be used for 
the right thing, it is much harder.   

Automotive manufacturers have VIN numbers. Public 
safety systems use them for such things as generating a 
notification to an owner that their car has been recovered after a theft. 
A VIN number is used because it is on multiple parts on the 
car including some hidden from chop shop specialists. 
VIN data is sold, not given away, but is a reasonable candidate 
for a web service.  Checking VINs via mobile systems is 
something done usually after car tags.  It can be a fallback 
for a tag switch.  Tags are used along with other physical 
descriptors given a driving stop.  

A second problem is knowing if the driver 
is the owner.  And so it goes until enough 
facts are established to get a probable certainty 
which really means "legal certainty".  Consider that 
your city may already be using photographs to catch 
you running a red light.  Because we are "accuser 
must prove" society, your lawyer gets you out of that 
by inferring (doesn't have to prove) you weren't 
the driver.  Comes down to the judge.

That is the right thing.  The wrong thing is to live in a 
state where if an owner does not respond quick enough, the tow and impound 
agency has the right to sell the car to recover costs.  Since 
the car has higher value than the tow/impound fee, they use 
all means possible to delay sending a notification.  So would 
you rather the tow/impound or the police to be responsible for 
the notification?  They have identical information.  (That is 
not made up.  It is a real condition in a real state.)

The information in your car IS sent to a central nexus, typically 
when you have it serviced.  Other examples exist.

The fact is, data is being collected about you by every 
means possible and by multiple agencies.  They don't pool 
it today.  In the very near future, they will and are. 
That is the dilemma of the web.  Shall we disconnect? 
Or shall we try to make sure we can at least follow 
the trail as best as we can?   The SW is a nightmare 
and that is why I wrote the Golem paper, to point 
out that the SW implementors have responsibilities. 
It is one thing to have the ontologies; it is quite 
another to assert that they are true.  The best we 
can do is constrain their authority.

The idea of the scenario real or imagined is to explore the 
domains and see which of our current applications could be 
applied.  A simpler scenario with multiple interfaces to 
other systems is demonstrative.  We can caveat it out of 
relevance but that won't help us.

Because of stereotyping, HumanML is about more than identity.  
Bugs Bunny can have multiple instances.  Kurt Cagle can't.  
There can be many persons named Kurt Cagle and that is why 
identification is a process, not a name.  In PS systems, 
we always assume the person giving the name is lying because 
they often are.   A bank does too but not as much.  A grocery 
check out counter does too but not as much.  The question 
of how much we are willing to endure to achieve security is 
perennial in open societies.  I don't have an answer for that. 
I also don't have any credit cards. (True.)

Oddly enough, because he is trademarked, Bugs is always Bugs.  
For some of us, the fun application is enabling artificial 
personalities.  I mix that into the scenario because it is 
the one some of us like and is reasonably straightforward 
to apply without invoking all the paranoias HumanML is 
certain to invoke, but really, over conditions that 
already exist.  Big Brother was already in place by 1945. 
I am more afraid of Big Blabber.  So, Bugs it is.

Len
http://www.mp3.com/LenBullard

Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h


-----Original Message-----
From: Kurt Cagle [mailto:cagle@olywa.net]
Sent: Friday, September 07, 2001 3:23 PM
To: Bullard, Claude L (Len); 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


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>
>


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>