- From: Marc Schroeder <schroed@dfki.de>
- Date: Sun, 02 Nov 2008 04:07:13 +0100
- To: EMOXG-public <public-xg-emotion@w3.org>
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 Sunday, 2 November 2008 03:07:57 UTC