W3C home > Mailing lists > Public > www-multimodal@w3.org > May 2011

[emo] Response to your comment on the W3C EmotionML LCWD (ISSUE-175)

From: Marc Schroeder <marc.schroeder@dfki.de>
Date: Mon, 30 May 2011 16:56:29 +0200
Message-ID: <4DE3B01D.5060407@dfki.de>
To: Renato Iannella <ri@semanticidentity.com>
CC: www-multimodal@w3.org, w3c-mmi-wg <w3c-mmi-wg@w3.org>
Hello Renato,

this is to reply to your comment to the EmotionML Last-Call Working 
Draft of 12 April 2011 [1], which we internally track as ISSUE-175.

After careful consideration of the suggestion, we think we should not 
use namespaces to identify vocabulary terms instead of the current 
category-set mechanism. Please find our reasoning below.

Do you agree this is a reasonable choice, or do you have some other 
thoughts on this matter?

Thanks again for the suggestion, and best regards,
Marc Schröder, EmotionML Editor

[1] http://lists.w3.org/Archives/Public/www-multimodal/2011Apr/0001.html


Details
-------

1. Pro

The idea of using namespace declarations to identify emotion 
vocabularies is appealing in the sense that it would allow users more 
freedom where to declare the vocabularies used. The current 
"category-set" mechanism allows for this declaration only on the 
top-level <emotionml> and the individual <emotion> elements.

2. Con

We see a number of problems with using namespaces for identifying 
emotion vocabularies.

a) No within-document referencing

There is an important limitation with respect to the use of namespaces: 
XMLNS-1.1 declares [2]:

"The use of relative IRI references, including same-document references, 
in namespace declarations is deprecated."

This is in conflict with our aim, described in [3], to allow for custom 
vocabularies to be defined in the same document:

"It is possible to refer to a vocabulary defined in the same or in a 
separate EmotionML document,..."

[2] http://www.w3.org/TR/xml-names11/#iri-use
[3] http://www.w3.org/TR/2011/WD-emotionml-20110407/#s3.1.1


b) Automatic verification of conformance would require additional complexity

On top of identification of vocabularies, the "category-set" mechanism 
serves the purpose of referring to an XML document (fragment) defining 
the emotion vocabulary used in a machine-readable format. This is to 
allow for processor validation of EmotionML documents [4]:

"It is the responsibility of an EmotionML processor to verify that the 
use of descriptor names and values is consistent with the vocabulary 
definition."

If we used namespaces for identifying the emotion vocabularies, we would 
have to follow the W3C policy for XML namespace allocation in W3C 
Technical Reports [5], which does not forsee namespaces starting with 
"www.w3.org/TR".

As a result, an additional mapping mechanism would be required, which 
allows to match the namespaces used for identifying the emotion 
vocabulary with the actual vocabulary definition. This is true in 
particular for the vocabularies defined in Vocabularies for EmotionML 
[6], but the same issue arises for user-defined vocabularies.

In summary, the apparent simplification seems to lead to substantial 
additional machinery required to achieve the same functionality as in 
the current draft.

[4] http://www.w3.org/TR/2011/WD-emotionml-20110407/#s4.3
[5] http://www.w3.org/2005/07/13-nsuri
[6] http://www.w3.org/TR/2011/WD-emotion-voc-20110407/


c) Risk of confusion

The current mechanism makes it easier for users to see the intentional 
limitations we imposed on the use of emotion vocabulary items. In line 
with the four types of emotion descriptor -- <category>, <dimension>, 
<appraisal> and <action-tendency> -- there are matching definitions of 
vocabularies: "category-set", "dimension-set", "appraisal-set", and 
"action-tendency-set". These groups are not to be mixed, i.e. a 
vocabulary item from a category set must not be used with a <dimension> etc.

Furthermore, for a given <emotion> only one vocabulary per descriptor 
type can be used: it is not meaningful to combine dimension x from set A 
with dimension y from set B in the same <emotion> annotation.

Both types of constraint are supported by the current self-explaining 
attribute names. If we use generic namespace definitions instead, and 
prefix the vocabulary names with a namespace prefix, it may be easier to 
mix things up. For example, users may use an appraisal item with a 
dimension tag, or they may throw together category labels from different 
vocabularies. This would counteract the aim of promoting a well-defined 
use of emotion vocabularies.


On 12.04.11 14:30, Renato Iannella wrote:
> In the Emotion Markup Language (EmotionML) 1.0 (W3C Working Draft 7 April 2011) - why don't you use namespaces for vocab terms? (which is the more common approach, with QNAMES, or even CURIES)
>
> So the example (just before section 2.2.2) would be:
>
> <emotion xmlns:big6="http://www.w3.org/TR/emotion-voc/xml#big6">
>      <category name="big6:sadness" value="0.3"/>
>      <category name="big6:anger" value="0.8"/>
>      <category name="big6:fear" value="0.3"/>
> </emotion>
>
> And, of course, that namespace can be defined at the top-level and reused elsewhere...
>
> Cheers...
> Renato Iannella
> Semantic Identity
> http://semanticidentity.com
> Mobile: +61 4 1313 2206
>
>

-- 
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 Monday, 30 May 2011 14:56:58 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:06:36 UTC