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

[EMOXG] Requirements UseCase 1+2+3

From: Hannes Pirker <hannes@ofai.at>
Date: Thu, 23 Nov 2006 23:05:50 +0100 (CET)
Message-Id: <200611232205.kANM5ojJ027786@rose.ofai.at>
To: EMOXG-public <public-xg-emotion@w3.org>

Dear Jean-Claude, Christian, Ian

apologize for me de-compartmentalizing the discussion on the different
UCs.  I had a look at each of the tables you sent out, and I will try
to comment on some of the specific labels below.

But on the other hand there are also some 'global' observations.

I tried to evaluate the amount of overlap between the different
collections - simply by gluing the three UCs together on an single
sheet of paper ;-)

The interesting part of the whole discussion seems to be the point on
how "broad" or "narrow" the annotation scheme should be.

In EARL we went for the "narrow" approach, i.e. try to concentrate on
the topic of describing Emotion-entities and not much else.

In the current UCs we see more 'broad' approaches to a different

In UC1 there are e.g. attempts to provide labels for
describing the communicative setting: the individual, the
interactional situation, the target of the emotion etc.

In UC2: labels for describing the technical environment: sensors, the
application, etc.

In UC3: there are labels for Input Events and Output Events. 


There are differences in the way these (in my opinion) more peripheric
information is to be encoded: JeanClaude & Christian heavily rely on
'simply' using pointers to external entities. That's also the approach
we undertook in EmoLang, because it helps to keep the
'core'-representations tidy... and we do not face the problem of
ending up with the problem to come up with a representation-format
that has to be able to specify 'the whole world', as virtually
'everything' can have an influence on our emotions and the way we
express them!

On the other hand Kostas already put the finger to it: while pointers
help us to 'export' the problems of finding common representations,
they on the other hand diminish the value of the language, because
there is no "standard" left on which an application can rely.

The good news, on the other hand is, that there already is a big
amount of agreement on the necessary labels for describing emotions
themself, the differences are mainly terminological I think. Emotion
Categories, Emotion Dimensions, Intensity, Regulation, Mixture of
Emotions... we all seem to agree on these. 

(On Dimensions I would like to point to the current work of Etienne
Roesch, Geneva, who is conducting the GRID study, were emotional terms
in English, French & Flamish are carefully related / located in the
dimensional space. And he is using an additional dimension
"Expectedness/Unpredictability", which seems to play an important
role. So we should keep in mind, that the 3 dimensional approach is
not 'God given').

If I understand Kostas' point on 'pointers' correctly
he is warning us: "what is a standard good for, if it (almost only)
consists of bits that are NOT standardized"? We should keep the same
point in mind when it comes to the discussion of the
core-of-the-core-elements such as emotion-categories. Up to now we are
carefully avoiding any discussion on what categories are to be
used. In fact in EMOLANG we defenitely left this open to each
individual user of EMOLANG to define his/her own 'dialect'. Probably
this is the only way to cope with the split-up of emotional theories &
different application scenarios. But we should keep this topic in mind
for future discussion: are there ways to ensure the *usability* of the
language if we mostly impose restrictions on its syntax and not so
much on its content.

o.k. here are some remarks to the specific UCs

UC1 JeanClaude

I do not fully understand the distinction between "Requirements" and
the items listed under "And for each emotion segment". Is
"Requirements" to be specified only once for each episode or

if this is so then I wonder:

i) 'acting' and 'single or complex emotion' : why are these not
mentioned under "And for each emotion"

ii) media-type: why not to move this up to "requirements"?
 (btw. some lines seem to have wandered off in the table: media types
 (text, audio,...) are mentioned under "confidence"...

UC2 Christian

I do not fully understand the following items:

i) super categories ?? -> is this a matching of an emotion-category to
another, broader one? Maybe this should be done externally?

ii) "time-span the emotion last" vs. "time stamp" ?? I think you
yourself were not comletely sure on whether there are some
redundancies in this?

iii) "purpose of classification" : I also would like to see more
concrete examples for this.

UC3 Ian

You already got some remarks concerning the representation of "Output
Events", Catherine pointed out BML for this purpose. I have to commit
that while I tend to be slightly more 'tolerant' when it comes to the
demands of UC1 and UC2 to include ways to encode additional
information (e.g. pointers to recording situations or to
person-descriptions) I am rather unhappy with the inclusion of "output
events" in the EMOTION-representation language itself, if this turns
out to become another attempt to specify a 'Behaviour Representation
Language' for avatars/ECAs. I am at least superficially familiar with
the numerous attempts to do so (e.g. BML), and I would definitely not
advise the EMOXG group to go for the 're-invention of the flat tire'!

For the topic of "Input Events" I have not yet found out whether they
are not just another way to talk about appraisals?? I do not really
know enough about appraisals & how they should be made part of the
EMO-lang to be really pre-occupied about this topic.


Hannes Pirker  -- Austrian Research Inst. for Artificial Intelligence     --
hannes(DOT)pirker~AT~ofai.at +43/1/532 4621-3  www.ofai.at/~hannes.pirker --
Received on Thursday, 23 November 2006 22:06:41 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:52:14 UTC