[EMOXG] comments to proposal for Core 1

Hi all,

in preparation for Thursday's phone meeting, here are my comments 
regarding Björn's proposals for Core 1 [1].

[1] http://lists.w3.org/Archives/Public/public-xg-emotion/2008Jul/0013.html


Björn Schuller schrieb:
> Core 1:
> Type of Emotion related phenomena:
> ==================================
 > [Variant 1]
> <emotion-related-state>
>   <category set="Scherer" name="mood" />
>   <emotion>
>     <category set="everyday" name="relaxed" confidence="0.8" />
>   </emotion>
> </emotion-related-state>

> [Variant 2]
> <affect>
>   <category set="Scherer" name="mood" />
>   <affect>
>     <category set="everyday" name="relaxed" confidence="0.8" />
>   </affect>
> </affect>

These two suggestions add an explicit level above "emotion" to make it 
clear what type of emotion-related phenomenon is being annotated, and 
the set of types that is being assumed. The two crucial elements here are:

* the possibility to indicate the type of emotion-related phenomenon;
* the possibility to indicate the set of valid types of em.-rel. ph. 
assumed in the current markup.

Insofar, the requirement indeed looks very similar to naming an emotion 
category and indicating the set of categories used, which must include 
the presently named category.

I also agree with the comment on Variant 1 that using <emotion> to 
annotate e.g. a "mood" may easily be confusing.

I wonder if the same may be reached in an even simpler way, as follows:

[Variant 4]

<mood>
     <category set="everyday" name="relaxed" confidence="0.8" />
</mood>

We could use the name of the element to indicate the emotion-related 
state being annotated. Allowable values would have to be specified 
somewhere, either on the same or a higher level:

<mood emotion-related-state-types="Scherer">
     <category set="everyday" name="relaxed" confidence="0.8" />
</mood>

<emotionML emotion-related-state-types="Scherer">
     <mood>
         <category set="everyday" name="relaxed" confidence="0.8" />
     </mood>
</emotionML>


[Variant 5]

Alternatively, we could stay closer to the example for emotion categories:

<emotion type="mood" emotion-related-state-types="Scherer">
     <category set="everyday" name="relaxed" confidence="0.8" />
</emotion>

or using a more fuzzy word for the markup element,

<emotion-related-state type="mood" emotion-related-state-types="Scherer">
     <category set="everyday" name="relaxed" confidence="0.8" />
</emotion-related-state>

or

<affect type="mood" emotion-related-state-types="Scherer">
     <category set="everyday" name="relaxed" confidence="0.8" />
</affect>


Personally, I think Variant 4 seems most elegant and simplest. How to 
specify this in an XML schema is a separate question that we can safely 
leave unanswered at this stage ;-)


[Tree-like embedding structures]
> <affect>
>   <category set="Scherer" name="emotion" />
>   <affect>
>     <category set="posneg" name="positive" />
>     <affect>
>       <category set="everyday" name="pleasure" confidence="0.9" />
>     </affect>
>   </affect>
> </affect>
> 
> [Variant 3a]
> <affect>
>   <category level=0 set="Scherer" name="emotion" />
>   <category level=1 set="posneg" name="positive" />
>   <category level=2 set="everyday" name="pleasure" confidence="0.9" />
>   <modality name="voice" />
>   ...
> </affect>

> <affect>
>   <category0 set="Scherer" name="emotion" />
>   <category1 set="posneg" name="positive" />
>   <category2 set="everyday" name="pleasure" confidence="0.9" />
>   <modality name="voice" />
>   ...
> </affect>

> [Variant 3b]
>   <category set="Scherer:posneg:everday" name="emotion:positive:pleasure" />


I strongly disagree with this kind of structure.

First, I am convinced that there is a very clear-cut distinction in 
theories of emotion and affect that gets blurred here. "Type of 
emotion-related phenomenon" is a fundamentally different thing from 
"emotion category".

On the one hand, we have the kind of emotion-related state: they share 
certain properties and not others, and are more or less well defined, 
e.g. using the design feature approach by Scherer -- see attached 
graphic, taken from [2].

[2] http://emotion-research.net/projects/humaine/deliverables/D3c.pdf

On the other hand, we have a certain emotion-related state that we want 
to describe -- either using categories, or dimensions, or appraisals, or 
action tendencies, or any combinations of these.

The proposal, in my understanding, combines the generic distinction of 
different types of states with one of the available descriptions of 
these states. I see a risk that this causes confusion.

Secondly, the proposal seems to address an issue that is not one of our 
requirements: how to represent a hierarchical structure of emotion 
categories. Some emotion descriptions do indeed propose this kind of 
structure, so-called prototype approaches; others don't.

I actually see a relevance for this kind of "emotion ontology", namely 
in our optional requirement "Onto 2: Relationships between concepts in 
an emotion description" [3]; here, I think it should be avoided.

[3] 
http://www.w3.org/2005/Incubator/emotion/XGR-requirements/#RelationsWithin

I'll send comments to Core 6 separately, otherwise the email is getting 
too long.

Cheers,
Marc

-- 
Dr. Marc Schröder, Senior Researcher at DFKI GmbH
Coordinator EU FP7 Project SEMAINE http://www.semaine-project.eu
Chair W3C Emotion ML Incubator http://www.w3.org/2005/Incubator/emotion
Portal Editor http://emotion-research.net
Team Leader DFKI Speech Group http://mary.dfki.de
Project Leader DFG project PAVOQUE http://mary.dfki.de/pavoque

Homepage: http://www.dfki.de/~schroed
Email: schroed@dfki.de
Phone: +49-681-302-5303
Postal address: DFKI GmbH, Campus D3_2, Stuhlsatzenhausweg 3, D-66123 
Saarbrücken, Germany
--
Official DFKI coordinates:
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Trippstadter Strasse 122, D-67663 Kaiserslautern, Germany
Geschaeftsfuehrung:
Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender)
Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313

Received on Wednesday, 3 September 2008 12:38:30 UTC