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

Re: [EMOXG] Gauging the degree of consensus over <emotion>

From: Marc Schroeder <schroed@dfki.de>
Date: Thu, 06 Nov 2008 17:06:24 +0100
Message-ID: <49131600.7040406@dfki.de>
To: martin@limsi.fr
CC: EMOXG-public <public-xg-emotion@w3.org>, "Burkhardt, Felix" <Felix.Burkhardt@t-systems.com>

Dear Jean-Claude,

thanks for your reply, and thanks for offering your help. The issue of 
plug-in vocabularies will have to be dealt with carefully, but in the 
next group -- between now and the end of the group's lifetime (20 
November) there is only just enough time to write the final report. I 
will happily come back to your offer when we are at the stage of 
defining default vocabularies...!!

At this stage, your help would be very appreciated in writing examples 
of EmotionML for the "manual annotation" use case. If you are familiar 
enough to write EmotionML directly, that would be perfect; else, you 
could write some "pseudo-code" and send it to Felix, who has volunteered 
to translate into EmotionML in case you would be willing to write some 
examples.

As time is really short, do you think you can do that by Tuesday at the 
latest?

Thanks a lot, and best wishes,
Marc


Jean-Claude MARTIN schrieb:
> Dear Marc,
> 
> The new format of the "emotion" tag is fine for me
> and I can understand it can be prefered to "affect" for practical reasons.
> 
> It leaves some open questions to "plug-in vocabularies".
> Is there anything planned to this respect?
> What will be the format of these vocabularies? (eg a raw text file with
> one label per line ?)
> Would it be relevant to host some on the HUMAINE portal?
> They will be of importance to ensure consistent use of the Emotion language
> and re-usability.
> 
> Would this be relevant, I could contribute to the report
> by writing some examples of vocabularies (eg basic emotions, occ).
> 
> Best,
> 
> Jean-Claude MARTIN
> LIMSI-CNRS
> 
> 
> 
>> Dear all,
>>
>> I would like to pick out one issue from the minutes of the face-to-face
>> meeting, to see if the group as a whole agrees: the discussion and
>> consensus over Core 1 "Type of emotion-related phenomenon". See the
>> minutes of f2f session 4 at [1].
>>
>> In summary, there was consensus at the face-to-face to use a simple
>> <emotion> element, with no attribute "type" and no
>> "emotion-related-states-set" either. Instead, the type of
>> emotion-related state would be encoded in the set of descriptors used.
>> For example:
>>
>> <emotion>
>> 	<category set="myMoods" name="depressed"/>
>> </emotion>
>>
>>
>> There are two kinds of reasons for this choice, practical and conceptual.
>>
>> Practical reasons for the simplified format
>> -------------------------------------------
>>
>> Practically, it seems cumbersome to write, every time that we want to
>> give an annotation of a mood,
>>
>> <emotion type="mood" set="some-set-of-affective-types">
>>      <category set="myMoods" name="depressed"/>
>> </emotion>
>>
>> or
>>
>> <affect type="mood" set="some-set-of-affective-types">
>>      <category set="myMoods" name="depressed"/>
>> </affect>
>>
>> There seems to be a real danger to be drowned in "scientific overhead"
>> to an extent that inhibits everyday adoption of the format.
>>
>> The reason why <emotion> seems more appropriate than <affect> or <state>
>> is the plugin nature of the EmotionML. Users will have an intuitive
>> understanding of what an <emotion> is; for <affect> or <state>, that is
>> less clear.
>>
>>
>> Conceptual reasons for the simplified format
>> --------------------------------------------
>>
>> Conceptually, the definition of affective state was actually happening
>> at two levels independently: on the one hand, the affect type; on the
>> other hand, the set of categories or dimensions to use.
>>
>> It seems very easy to do nonsensical things with the combination of
>> affect type and plugin set. For example, an affect type of "mood" could
>> be combined with <appraisals> and <action-tendencies>, which does not
>> appear scientifically meaningful if mood is defined as a feeling state
>> with no strong relation to specific events.
>>
>> Similarly, it would be possible to mix up vocabularies intended for one
>> type of affective state with the annotation of another type of affective
>> state, such as:
>>
>> <affect type="interpersonal-stance" set="some-set-of-affective-types">
>>      <category set="myMoods" name="depressed"/>
>> </affect>
>>
>>
>> Only in the hands of very careful experts who know what they are doing
>> is this kind of tool "safe" -- for our intended users, most of whom will
>> not be experts in emotion theory, this amount of expressive power seems
>> just too much.
>>
>>
>> Benefits of the simpler model
>> -----------------------------
>>
>> The advantages of the simpler format, unanimously preferred at the
>> face-to-face meeting, appear to be:
>>
>> * simple form
>>
>> * tag name understandable for the non-expert
>>
>> * different types of affective states can still be described by using
>> plugin vocabularies.
>>
>>
>> I would like to invite, in particular, those in the group who have
>> expressed their preference for one of the options for Core 1 previously
>> to consider the above arguments and to state whether they could live
>> with the simpler model.
>>
>> There is no time at this stage for a lengthy discussion, as efforts in
>> the remaining 2 1/2 weeks do need to be focused on writing the final
>> report (of which I will circulate a draft on Monday). However, I feel it
>> is important to know if the f2f result can be considered a "consensus"
>> in the group as a whole, or if an issue note should be added explaining
>> the different points of view.
>>
>> Thanks, and best regards,
>> Marc
>>
>>
>> [1]
>> http://lists.w3.org/Archives/Public/public-xg-emotion/2008Oct/0018.html
>>
>>
>> --
>> 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
>>
>>
>>
> 
> 
> 

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

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 Thursday, 6 November 2008 16:07:11 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 6 November 2008 16:07:11 GMT