- From: Marc Schroeder <schroed@dfki.de>
- Date: Wed, 03 Sep 2008 14:37:42 +0200
- To: EMOXG-public <public-xg-emotion@w3.org>
- Message-ID: <48BE8516.80405@dfki.de>
Hi all, in preparation for Thursday's phone meeting, here are my comments regarding Björn's proposals for Core 1 [1]. [1] http://lists.w3.org/Archives/Public/public-xg-emotion/2008Jul/0013.html Björn Schuller schrieb: > Core 1: > Type of Emotion related phenomena: > ================================== > [Variant 1] > <emotion-related-state> > <category set="Scherer" name="mood" /> > <emotion> > <category set="everyday" name="relaxed" confidence="0.8" /> > </emotion> > </emotion-related-state> > [Variant 2] > <affect> > <category set="Scherer" name="mood" /> > <affect> > <category set="everyday" name="relaxed" confidence="0.8" /> > </affect> > </affect> These two suggestions add an explicit level above "emotion" to make it clear what type of emotion-related phenomenon is being annotated, and the set of types that is being assumed. The two crucial elements here are: * the possibility to indicate the type of emotion-related phenomenon; * the possibility to indicate the set of valid types of em.-rel. ph. assumed in the current markup. Insofar, the requirement indeed looks very similar to naming an emotion category and indicating the set of categories used, which must include the presently named category. I also agree with the comment on Variant 1 that using <emotion> to annotate e.g. a "mood" may easily be confusing. I wonder if the same may be reached in an even simpler way, as follows: [Variant 4] <mood> <category set="everyday" name="relaxed" confidence="0.8" /> </mood> We could use the name of the element to indicate the emotion-related state being annotated. Allowable values would have to be specified somewhere, either on the same or a higher level: <mood emotion-related-state-types="Scherer"> <category set="everyday" name="relaxed" confidence="0.8" /> </mood> <emotionML emotion-related-state-types="Scherer"> <mood> <category set="everyday" name="relaxed" confidence="0.8" /> </mood> </emotionML> [Variant 5] Alternatively, we could stay closer to the example for emotion categories: <emotion type="mood" emotion-related-state-types="Scherer"> <category set="everyday" name="relaxed" confidence="0.8" /> </emotion> or using a more fuzzy word for the markup element, <emotion-related-state type="mood" emotion-related-state-types="Scherer"> <category set="everyday" name="relaxed" confidence="0.8" /> </emotion-related-state> or <affect type="mood" emotion-related-state-types="Scherer"> <category set="everyday" name="relaxed" confidence="0.8" /> </affect> Personally, I think Variant 4 seems most elegant and simplest. How to specify this in an XML schema is a separate question that we can safely leave unanswered at this stage ;-) [Tree-like embedding structures] > <affect> > <category set="Scherer" name="emotion" /> > <affect> > <category set="posneg" name="positive" /> > <affect> > <category set="everyday" name="pleasure" confidence="0.9" /> > </affect> > </affect> > </affect> > > [Variant 3a] > <affect> > <category level=0 set="Scherer" name="emotion" /> > <category level=1 set="posneg" name="positive" /> > <category level=2 set="everyday" name="pleasure" confidence="0.9" /> > <modality name="voice" /> > ... > </affect> > <affect> > <category0 set="Scherer" name="emotion" /> > <category1 set="posneg" name="positive" /> > <category2 set="everyday" name="pleasure" confidence="0.9" /> > <modality name="voice" /> > ... > </affect> > [Variant 3b] > <category set="Scherer:posneg:everday" name="emotion:positive:pleasure" /> I strongly disagree with this kind of structure. First, I am convinced that there is a very clear-cut distinction in theories of emotion and affect that gets blurred here. "Type of emotion-related phenomenon" is a fundamentally different thing from "emotion category". On the one hand, we have the kind of emotion-related state: they share certain properties and not others, and are more or less well defined, e.g. using the design feature approach by Scherer -- see attached graphic, taken from [2]. [2] http://emotion-research.net/projects/humaine/deliverables/D3c.pdf On the other hand, we have a certain emotion-related state that we want to describe -- either using categories, or dimensions, or appraisals, or action tendencies, or any combinations of these. The proposal, in my understanding, combines the generic distinction of different types of states with one of the available descriptions of these states. I see a risk that this causes confusion. Secondly, the proposal seems to address an issue that is not one of our requirements: how to represent a hierarchical structure of emotion categories. Some emotion descriptions do indeed propose this kind of structure, so-called prototype approaches; others don't. I actually see a relevance for this kind of "emotion ontology", namely in our optional requirement "Onto 2: Relationships between concepts in an emotion description" [3]; here, I think it should be avoided. [3] http://www.w3.org/2005/Incubator/emotion/XGR-requirements/#RelationsWithin I'll send comments to Core 6 separately, otherwise the email is getting too long. Cheers, Marc -- 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
Attachments
- image/png attachment: scherer-designfeatures.png
Received on Wednesday, 3 September 2008 12:38:30 UTC