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

[Rex Brooks <rexb@starbourne.com>]

I'm actually not snipping this because this is essentially what I was
getting at, although I would like to hear from a few more voices on
their takes... As we move from the general to the specific with
profiling, we need to reach consensus on the most useful common
general categories. I'd just like to collect some enumerations for
our core documents, as a place to start.

Ciao,
Rex

At 2:21 PM -0500 9/6/01, Bullard, Claude L (Len) wrote:
>Yes. 
>
>Some data aspects of a human profile will be
>the same across all applications (eg, physical
>descriptors, addresses, locations, etc.).  It is
>when we get into a theory (gestalt, cognitive,
>behavioral, etc,), and a policy of an organization or
>agency (police, school, medical, etc.)  that
>we should see mixed namespaces (think relational
>views where ontologies are used to select the
>WHERE conditions).   
>
>This is almost orthogonal to services and yet not.  A
>service has to advertise what kinds of tasks
>it can perform and these can be creation or
>modification of certain document types based
>on the policies/rules that govern the processes
>for that kind of document.  
>
>So it is possible
>(in fact exactly what is done) for a school
>system to access data in the police database
>and get a restricted and task appropriate set
>of documents/reports.   This isn't HumanML but
>how any cross-agency database works.  HumanML
>standardizes and extends some of the kinds of
>information collected (eg, cultural).  On the
>other hand, a "gang" is a kind of culture and
>police databases do collect that kind of information.
>They don't collect it to the level of detail
>some other database might.  In fact, part of the
>use of services is to enable a system or user to
>collect data from multiple services to product
>some kind of report.
>
>So it comes back to communication and how to
>detect failures or to enhance communication.
>HumanML should work for both ends of that
>spectrum.  Not only to help with miscommunication,
>but to help construct a successful communication.
>Take the example we used in Phase 0 of selecting
>the greeting.  Given a cultural dictionary, it
>is just as easy to ask for the right greeting
>in advance as to have to correct the wrong one.
>Given a profile and stereotype (not the same
>thing), a lot of this could be done automatically
>and would be part of training an agent for
>some goal-directed task or creating a task-specific HCI.
>
>Len
>http://www.mp3.com/LenBullard
>
>Ekam sat.h, Vipraah bahudhaa vadanti.
>Daamyata. Datta. Dayadhvam.h
>
>
>-----Original Message-----
>From: Ranjeeth Kumar Thunga [mailto:rkthunga@humanmarkup.org]
>Sent: Thursday, September 06, 2001 1:52 PM
>To: humanmarkup-comment@lists.oasis-open.org
>Subject: Fw: HM.applications-Profiling-Level of Details/Abstraction
>
>
>
>----- Original Message -----
>From: "Ranjeeth Kumar Thunga" <rkthunga@humanmarkup.org>
>To: "Rex Brooks" <rexb@starbourne.com>
>Sent: Thursday, September 06, 2001 2:18 PM
>Subject: Re: HM.applications-Profiling-Level of Details/Abstraction
>
>
>>  >
>>  > A quickie: We've already had quite a bit of work done here on
>>  > Profiling, and since that thread is fairly easy to get hold of for
>>  > our core topics purposes, I won't start from scratch on it.
>>  >
>>  > So, given what we have already said, and given that we have an actual
>>  > functional beginning in the Schema Toolkit, I would like to see what
>>  > folks think about establishing Levels of Details or Abstraction for
>>  > Human Object Profiles.
>>
>>  > How do we provide for this in a sensible way. Be aware that this is
>>  > fraught with pitfalls.
>>  >
>>
>  I do think that there would be infinite levels of detail (reductionist) or
>abstraction (holistic) ways of combining different types of information in
>different ways inherent in the schema design.  Of course, a police profile
>would be different from a psychotherapist's profile, different from a
>certain religious order's profile--different sets of often the same Human
>modules, all along. 
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>


--
Rex Brooks
GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth
W3Address: http://www.starbourne.com
Email: rexb@starbourne.com
Tel: 510-849-2309
Fax: By Request