RE: [humanmarkup-comment] HMU.newmedia: Emotion

[Rex Brooks <rexb@starbourne.com>]

No, I don't think you are contradicting the original models, and I
think the notion of testing is important.

This brings up the notion of a standard methodology for obtaining
requirements from application areas, testing the schemata to see how
what we have fills the requirements. I know I'm drifting afield of
the specific topic of emotions. I think we may want to test our
schemata to see if we can produce a viable process model for each set
of requirements that are brought in.

I'm just thinking out loud here. Does this sound reasonable?

Following up: Emotions are processed in a number of different ways
over time, both as a single emotional response to a specific
stimulus, and how that response is viewed or reviewed later, or how
it is viewed in context, say, if it is embedded as a tagged anecdote
in a report, when a summary of a set of similar reports is digested,
containing a number of instances of such tagged anecdotes. Do we need
to accommodate weights of collective emotional responses?

Ciao,
Rex

At 10:26 AM -0600 11/5/01, Bullard, Claude L (Len) wrote:
>I am aware.  That is in the codelists.  These are
>organized under abstract types to enable event
>routing to proceed by application type.  So far
>I don't think I am contradicting the original
>models using an S/R paradigm.
>
>However, as we continue to layer in more systems
>with diverse requirements, we are not necessarily
>adding new requirements.  We are testing the old
>ones.   We should be creating
>use cases to determine when the schema needs new
>types.  For example, markup that organizes a
>process is applicable only to applications that
>view and process events as inputs, outputs,
>controls and mechanisms.  To simulate chronemic
>properties, we have to add time, and so forth.
>In VRML, this is easy.  In HTML, it's a little
>less easy (HTML + Time, a subset of SMIL2).
>
>So take a use case and see if it can be first
>organized by the current schema, then ask what else
>is needed if we can't.  Try what the author suggests
>for the process model. 
>
>I think first we discover that without
>a basic, easy to use process model, we don't have a
>means to show a single human object emoting in a
>much less two objects with a context of communication. 
>One could easily do that with a HumanML aware VRML
>object as long as it has a proto with a script
>node for dispatching events to the VRML nodes
>upon receipt of an event from an XML processor
>through the SAI/EAI. 
>
>Take a simple case:  a sphere that color cycles
>given HumanML selects and external events.
>
>len
>
>-----Original Message-----
>From: Rex Brooks [mailto:rexb@starbourne.com]
>
>I have to study this further, but, just a reminder: we are building a
>markup language that needs to account for use in scene graphs, and
>plain text, and messaging, and voiceXML, if possible, as well as a
>host of other applications. How we embed, or encode emotion is one of
>our tasks.
>
>It is important to keep the requirements of the applications/uses in
>mind as we develop the tags, the schemata, the document models, the
>scene graph models, the streaming models/protocols, the adaptations
>of artificial intelligence which use chaos and game theory, the
>psychological models which are informed by that set of schools of
>thought, and of course, informing us overall, semiotics.


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