W3C home > Mailing lists > Public > public-xg-emotion@w3.org > December 2006

Re: [EMOXG] Use Case 3 Requirements Analysis

From: Ian Wilson <ian@emotion.ai>
Date: Sat, 02 Dec 2006 05:41:03 -0500
Message-ID: <20061202042612.25376@web5.nyc1.bluetie.com>
Cc:
To: public-xg-emotion@w3.org


There are many points in Marc document so it would be great if all of the UC3
group could respond, especially to points that concern requirements that you
have specified.

In general - I agree that input and outputs are generally domain specific and
this is probably outside of the scope of this effort, however I do also think
that it is possible to find a small set of generic input and outputs that will
apply to most domains.

I see this format being used in two broad sets of applications;
  a. For storing data in a consistent and standard format for later retrieval.
  b. For passing data in a consistent and standard format between the nodes of a
system 
     (where that system is a general word and could for example be a network or
a stand alone application or a database etc)

for both of these applications if there is no notion of input or output then it
would seem that the format is limited to defining the state of an emotion system
(be it human, software or hardware). I wonder if this is enough? 

If we think of this format in terms of passing data around the Internet (as we
are a W3C group) then from where is the data being sent and to what types of
system? In the event based terminology of the Internet, a system (could be a
user) triggers an event or REQUEST, that event is encoded in a format like XML
and sent to a server where it is PROCESSED and then it outputs a RESPONSE. I am
sure most of us from varying domains are familiar with this cycle and it is
variously known as sense -> think -> act, sensor -> controller -> actuator, and
others.

If input and output / request and response / sense and act, are omitted from the
spec is what is remaining enough for its own language? Perhaps I am unclear some
important concepts?


Here are my comments to Marc's specific points where I can provide more insight:

Input Events: 
Being domain specific is problematic here, I agree. My approach is to reduce
system input to a generic "event" (which is why I use that terminology) that
has, nominally, 3 attributes; a reward value, a penalty value and a confidence
value. The event could be anything and can contain further attributes such as
ID, time stamp, category, type etc. I could use the same format for passing
information from game characters or for passing real time stock information.
Because I work across multiple very different domains I have looked at the
concept of generalizing input to a generic form. Not to say that it is right for
this language but I wanted to give a little more background as to where that
idea comes from as It might be possible to define a generic input and output
format that contains data common to most applications.

In my view if we are using confidence values they are tied to another specific
value or attribute but scope could be like variable scope in that it has
different scope depending on where it is declared?

Hierachy of representations;
Sorry, perhaps a confusing choice of labels here. I know EARL has the concept of
categories but I think this should be extended to define a hierarchy (perhaps it
already does?) and these terms (taken from the use cases) context/category/type
were meant to convey the idea of different levels of the hierarchy. They are
categories and meta categories. A concrete example would be a meta category of
"Arousal" then a sub category or "Social" then a final label (category/type) of
"Party Animal" ;)

Intensity;
Agreed, not required for scaled dimensions (which are themselves an intensity
value).

Internal State;
For me this is the current state of the processing system, it can be different
from the expressed, external state. I think this is an important element to have
and many systems I would imagine would want to pass around this data.

Mappings;
Conceptually it *should* be possible to map one representation onto another (as
they are all different representations of the same thing), although often not
one to one. I also think this will be a very useful aspect of the spec when one
system sends data in one format but the receiving system uses a different one.
For example system A sends out its internal state as 3 dimension values but the
receiving system B uses category labels then system B would want to know how
system A maps dimensions to categories rather than having to decide that for itself.

Other items I will leave to the other members to detail.

Best,

Ian
Emotion AI
Received on Saturday, 2 December 2006 10:41:08 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:21:16 GMT