OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

humanmarkup-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


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


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.  


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC