RE: HM.interactions: initial questions: messaging

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

If this bounces, please resend it to the list.  I'm 
not sure what my subscription status is right now
given the message bounces this morning automatically 
unsubscribing me.

I brought it up in the context of defining what is 
explicit about a human object.  Some theories 
define a human purely as a set of seneses.  In essence, the 
channels (aka) senses by which it communicates. 
Representation influences effective actions, 
that is, for some tasks a pereptual (say 
visual or audio) presentation is best.  For 
others (verbal), a text presentation is best. 
This affects the uncertainty oscillation for 
action selection (system punts to procedural 
means because declarative selection is 
ambiguous).  Services for that might be 
provided using the human object that can 
process a stereotype.

One service might read the authoritative profile 
(eg, something the real human asserts is their 
approved profile) and create a suitable HCI 
for a given task or set of tasks.  

Note the following:

From: COSITUE: TOWARDS A METHODOLOGY FOR CONSTRUCTING SCENARIOS
Tove Klausen & Niels Ole Bernsen
June 1993
UM/WP13
Centre for Cognitive Informatics
Roskilde University
Denmark

'scenario' - representative instance of an interaction between user and
system 
(Campbell 1992). representativity of a scenario depends on its purpose:

An interface should be designed in such a way that the actions and
operations which 
have to be performed for a satisfactory interaction with the system
correspond to 
our natural ways of thinking and acting (Berentsen 1993).

A study of types of user problems in the design of a spoken language
dialogue system 
showed that users' background and domain knowledge played an important role
for the 
types of problems they had in interacting with the system (Bernsen 1993b).
We want 
to extend our concept of users beyond the notions of novice / intermediate /
expert 
users and take individual differences between users into account. The
suggestion is 
to develop a set of user stereotypes through ascribing different personality
traits 
to different classes of users. An advantage of working with stereotypes is
that 
they are well known and hence easy to communicate and share in a scenario.
Stereotypes 
are cultural phenomena which embody a set of pre-conceptions about groups of
people. 
Stereotypes can be at the levels of nationalities, sub-cultures,
professions, sexes, 
etc. The interesting point in this context is that they are shared
representations 
and can be referred to."


Len Bullard
Intergraph Public Safety
clbullar@ingr.com
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:50 PM
To: humanmarkup-comment@lists.oasis-open.org
Subject: Re: HM.interactions: initial questions: messaging


>
>
> > -----Original Message-----
> > From: Mark Brownell [mailto:gizmotron@earthlink.net]
>
> [...]
> > So would the semantic web function as a portal to a contextual data
> resource,
> > or would
> > this SOAP/HumanML data function as a portal to a selected part of the
> semantic
> > web?
>
> Both, depending on your scope. Without the SW framework, this knowledge
> interchange would be custom-made and extremely difficult to establish.
> But at the same time, this "service" will operate as a portal to this
> specific piece of information.
>
> [...]
> > So at this point
> > I find myself desiring to gain a greater understanding of XML/SOAP.
>
> Although SOAP and/or XML-RPC are very handy as "semi-protocols", I don't
> really find a reason to focus on them while building our framework; They
> are just a distributed computing "API". Essentially, it's just a way of
> messaging. Shouldn't we be neutral towards these?
>

Regarding SOAP:

The primary reason to investigate SOAP, or other Internet messaging
protocols,  as a means of sending messages is to make explicit the process
of channeling messages.  We are so far investigating the 'human' contextual
information _within_ a message itself, but also what is important is the
actual _conveyance_ or _delivery_ of the message.  For a deaf, an
emotionally distraught, for an intellectually underdeveloped person, for a
naive person, for a suave person, an auditory person--the messaging
considerations involved in routing and delivery are certainly worth making
explicit and embedding within our technology infrastructure.

That touches on what Len had mentioned earlier about our investigating the
'channels' of human communication.  I don't recall if it was you (Len) or
someone else who mentioned it or brought this point up, but the web services
directly correlate to how we could explicitly and functionally represent
channels through an XML infrastructure......it would be a data model for
reprenting how message packets could be developed which take into account
factors which could let an application appropriately route a message to the
appropriate person or target.

Since we are creating a methodology of dealing with the dynamic back and
forth state of human communications itself (not necessarily a set of data we
are storing away), we have to take into account how human information is
channeled.

Questions:
Reapproaching this topic again (it's been discussed during Phase 0)--what
other considerations do you think should 'messaging' should entail?

Would 'messaging' be considered a HumanMarkup 'Interaction' or a 'Domain'
(or both)?  We are still working out our nomenclature...
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>