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

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

Received on Thursday, 6 November 2008 15:42:51 UTC