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

Hi Marc,

Thanks for your clarification about the vocabularies.

Yes, I will write examples of EmotionML for the "manual annotation" use case
by next Tuesday.

Apologies for having missed today's meeting (I was travelling).
I will be able to attend the meeting planned on Novembre 13th.

Best,

Jean-Claude



> 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 21:57:44 UTC