Re: EmotionML comments from WAI_PF

Hello Janina,

thank you very much for these comments. I can assure you that they are 
still timely.

We internally track your comments as the following issues:

ISSUE-184 Accessibility use cases for EmotionML
ISSUE-185 Easier-to-use emotion markup using attributes
ISSUE-186 Make explicit the relationship between different emotion 
vocabularies

The emotion subgroup of MMI will discuss these and respond to each of 
them separately.

Thanks again for taking the time to review the Emotion Markup Language 
specification, and best regards,

Marc Schröder, Editor EmotionML

On 21.06.11 01:13, 'Janina Sajka' wrote:
>      PF were invited by the MMI WG to review the Emotion Markup Language 1.0 specification:
>
> http://www.w3.org/TR/2011/WD-emotionml-20110407/
>
> PF appreciates this opportunity, and apologizes for forwarding these
> comments late. We hope they are still helpful.  We thank Lisa Seman and
> Leonie Watson for their work preparing and leading PF's review of this
> specification.
>
> Our Comments
>
> We believe that Emotion ML is a positive step towards interoperability. The
> emotion behind speech is very much part of the content, so Emotion ML has
> terrific potential for accessibility. To build on this, we've put together the
> following points for consideration by the MMI WG.
>
> 1. Use cases.
>
>      It would help people understand the accessibility potential for Emotion ML if some specific accessibility use cases could be included. Although there might be some overlap with existing use cases, the author/user requirements are quite distinct. Some possible use cases might be:
>
> - Emotion ML is used for media transcripts and captions. Where emotions are marked up to help deaf or hearing impaired people who cannot hear the soundtrack, more information is made available to enrich their experience of the content.
>
> - Emotion ML is used for content that's translated into synthetic speech. This would make more information available to blind and partially sighted people, and enrich their experience of the content.
>
> - Emotion ML is used to make the emotional intent of content explicit. This would enable people with learning disabilities (such as Asperger's Syndrome) to realise the emotional context of the content.
>
> 2. Ease of use.
>
>      It's often easier to encourage people to think about accessibility if the author requirements are as minimal as possible. Adding accessibility into some of the examples provided within the specification would make the code quite verbose, and would therefore add a burden onto the developer.
>
>      One possible solution might be to change some of the Emotion ML tags into attributes that could be applied to any element. For example:
> <span emotion-category="irritation">Well of course, you would do that!</span>
>
>      Could be used instead of:
>
> <emotion>
>
> <category name="irritation"/>
>
> <span>  Well of course, you would do that</span>
>
> </emotion>
>
>      Another example (using SMIL) might be:
>
> <s>
>
> <emo:emotion>
>
> <emo:category name="doubt"/>
>
> <emo:intensity value="0.4"/>
>
> </emo:emotion>
>
> Do you need help?
>
> </s>
>
>      Could become:
>
> <s em- category-set=http://www.example.com/emotion/category/everyday-emotions.xml em-category"doubt"  em-intensity value="0.4">
>
> Do you need help?
>
> </s>
>
>
>      Or alternatively could become:
>
> <s>
>
> <emo:emotion em- category-set=http://www.example.com/emotion/category/everyday-emotions.xml em-category"doubt"  em-intensity value="0.4"/>
>
> Do you need help?
>
> </emo:emotion>
>
> </s>
>
>      It might also be helpful to change the name of the attributes, to clarify the fact they relate to emotions. For example, the category attribute could become emotion-category or even em-category (although this is slightly less clear). ARIA uses this approach to good effect for example.
>
> 3. New vocabularies and extensions.
>
>      Emotion ML indicates that user defined custom vocabularies do not need to relate to existing vocabularies (although redundancy should be avoided). To some extent this could put the interoperability of the specification at risk.
>
>      One solution might be to create a requirement that user defined custom vocabularies make the relationship with existing requirements explicit. For example, if you wanted to define a new term "contentment", the author of the custom vocabulary would need to say something like:
>
> contentment is a type of happiness
> contentment  overlaps with satisfaction by 80%
> contentment  overlaps with relaxed 70%
> contentment  excludes anger
> contentment  excludes excitement by 90%
>
>      Our definition of contentment might not be exactly right, but the aim is to make the term machine understandable (and hence interoperable).
>
>      This suggestion isn't something that would be necessary at this stage in the lifecycle of the specification. It may be something for consideration in the future though.
>

-- 
Dr. Marc Schröder, Senior Researcher at DFKI GmbH
Project leader for DFKI in SSPNet http://sspnet.eu
Team Leader DFKI TTS Group http://mary.dfki.de
Editor W3C EmotionML Working Draft http://www.w3.org/TR/emotionml/
Portal Editor http://emotion-research.net

Homepage: http://www.dfki.de/~schroed
Email: marc.schroeder@dfki.de
Phone: +49-681-85775-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 Tuesday, 21 June 2011 06:47:25 UTC