- 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