W3C home > Mailing lists > Public > public-xg-emotion@w3.org > January 2008

Re: draft RE my action item (was Re: Agenda for phone meeting 31 January 2008)

From: Bill Jarrold <jarrold@AI.SRI.COM>
Date: Wed, 30 Jan 2008 17:48:58 -0800
Message-Id: <BA4A484D-C7D1-45E8-80F7-BE2B8BB0F6C8@ai.sri.com>
Cc: EMOXG-public <public-xg-emotion@w3.org>
To: Marc Schroeder <schroed@dfki.de>

On Jan 30, 2008, at 7:23 AM, Marc Schroeder wrote:

>
> Bill,
>
> I agree with Ian that the current exercise, from my point of view,  
> was about getting a "feel" of the "syntax" associated with various  
> representations, not about immediately designing a "meaningful"  
> structure within any given framework. The various ad hoc choices in  
> the other examples illustrate that, and raise interesting questions  
> worth discussion.

Okay, I am guessing that actual owl code will serve this need the best?

(Note that I am not a good person (yet at least) to say much about  
the plusses and minuses of XML vs RDF vs OWL syntax.)

Attached is a simple taxonomy that contains both the Scherer and the  
Douglas-Cowie taxnomy.



But a simple taxonomy is probably too simple to really be useful for  
your purposes.  I need to run now but hopefully will have a little  
owl example based on my diagram below.

>
> On the other hand, you are asking very interesting and relevant  
> questions, so let me briefly reply.
>
> Bill Jarrold schrieb:
>> How in the world will we deal with all these differences of opinion?
>> With changes in the field as affective science evolves....The key to
>> me seems to be to (a) allow people to continue to debate what is the
>> correct taxoomony and yet (b) still let people who need to use some
>> term set at least make some headway and leverage *something* without
>> having to wait for the people in (a) to reach conssensus.
>
> Exactly. So even though there is no chance to have a unified  
> emotion theory any time soon, there is *some* consensus among  
> *some* people, and we should provide a flexible mechanism for  
> encoding that, without deciding for a camp ourselves. And if  
> engineers decide they need to build bridges between camps that  
> theorists would never endorse as valid, but for which there is an  
> application need, we should let them. Actually, maybe, just maybe,  
> the experience of what works and what doesn't in practice can  
> inform theory...!

Sounds good.

>
>> Okay, I have provisionally assumed that allowing for multiple
>> taxonomies (or even more complex -- multiple theories) is a  
>> requirement.
>
> Yes. BUT in order to avoid complete chaos, there should be clearly  
> defined ways of saying that one is "using Ekman's six basic  
> emotions" or "the concept of mood dimensions as in Gebhard 2007" or  
> "the distinction of types of affective states as in Scherer 2000"  
> etc. So the idea is, let them use what they want *if* they make  
> their choices explicit.


(a) One way to do this is give each term belonging to a given point  
of view a suffix to its name.  This is what I did in my attached owl  
example.  There is -S2002 for the terms originating from Scherer 2002  
and -DC2006 for the terms originating from -DC2006.

(b) Another way to do this is with namespaces.

(c) Another way to to this is with separate files and importing one  
(e.g. Douglas-Cowie 2006) versus the other (Scherer 2002).

(d) Yet another way is using the notion of a microtheory as defined  
in Cyc.  I can dig out a good reference if you'd like.  Not sure how  
microtheories might be implemented in semantic web but there must be  
lots of discussion on this somewhere.

(e) There are probably other ways.

Probably best to allow many of the above approaches with guidance as  
to when to use which one.

And yes, as you say, "here should be clearly defined ways of saying  
that one is "using Ekman's six basic emotions" or "the concept of  
mood dimensions as in Gebhard 2007" etc...Exactly how to do this for  
(a), (b), (c) etc is a topic for more discussion.

>
> In EARL, we did this using a separate namespace for each  
> configuration of annotations [1] -- not very modular (you could not  
> simply refer in the document itself to the various label sets you  
> were using, but needed to create a new Schema for every specific  
> combination), but OK it was a start.
>
> [1] http://emotion-research.net/earl/schemadesign#SchemaDialects

Wow, I have a lot to catch up on.

I also need to grok SMIL as per Ian's email.

>
>> TECHNICAL QUESTION: Any sense as to what kinds of tools
>> might actually do that markup? Something pre-existing? protege?
>> Something custom created?)
>
> This is another really good question. We should talk about it. For  
> machine recognition and generation, of course both the generation  
> and the interpretation of the markup will be done by software  
> components; but for manual labelling of data, what would one use? I  
> know that for annotating videos, colleagues in Paris and Belfast  
> are using Anvil [2], but that labelling tool has its own data  
> formats, so getting an Emotion Markup from Anvil may need effort.
>
> [2] http://www.anvil-software.de/

Okay, but it sounds clear that annotators will not be using Protege.   
Maybe the annotation language designers might use Protege but the  
people fulfilling the role of "annotator" will not.

>
>> Given the potential ugliness of namespaces perhaps we just need to
>> have everything be in one namespace but use different owl files.
>
> One important aspect is extensibility: we will not be able to  
> preview all the sets of emotion categories, for example, that our  
> users will want to use in their annotations. Often, these are quite  
> application-specific, so users will want to "plug in" their own  
> label set.

Right.

And as the possible sets of emotion categories proliferate they will  
want tools to minimize the pain of navigating through this space.

>
>> At first blush, my approach is to have a representation of that  
>> object
>> that we wish to makup.  Let me consider a specific real world case
>> that I hope is a decent exemplar of Alexander's use case?
>> Specifically I consider the point in Macbeth where Lady M says "Out
>> damn spot!"  How might I go aobut ontologizing this.
>> I will first do this diagramatically to give as easily grokable
>> description.  Then, hopefully, if time, will spell out the owl --
>> which I lament is not very human readable.
>> Now, some diagramatic notation conventions:
>> Slots or relations are have a name that begins with a lowercase
>> character (e.g. annotationTextIs)
>> Individuals (as opposed to classes) have a name that begins with a *
>> followed by an uppercase character, e.g. *Alexander.
>> Primitive Data types (e.g. strings, time instants, numbers, booleans)
>> are put in quotations.
>> *"Out damn spot!"
>> 	^
>> 	|
>> 	annotationTextIs
>> 	|
>> *Annotation24601
>> 	|
>> 	|--- annotationAuthor: *Alexander
>> 	|
>> 	|--- annotationTime: "2008-01-23T13:36"
>> 	|
>> 	|-- annotatedEmotion: *FearInstance35
>> 				|
>> 				|--instanceOf: *DC-2006-Fear
>> 				|
>> 				|--valence: "-0.8"
>> 				|
>> 				|--
>> <sstopping here>
>
> So if I understand you correctly, this is a stub of a graphical  
> representation of an OWL document containing a concrete emotion  
> annotation. "annotatedEmotion" is where the Emotion Markup really  
> starts, right? The line from *"Out damn spot!" to *Annotation24601  
> is an answer to our requirement 'Links to the "rest of the world":  
> Links to media'.

Yes, I think so.

*Annotation24601 is an instance of the class Annotation.  Instances  
of this class should be able to point to all kinds of things.  Some  
might point to video clips, others might point to books, websites etc.

Hrm, in my example above I had it point to a bare string.  It should  
probably point to an object that represents a part of the script of  
the conceptual work which is the play written by Shakespeare...blah  
blah.  I am gettting too focused on correct model right now I  
suspect.  High time to write some owl!!

>
> I am not very firm in ontological theory, so I am uncertain about  
> the status of *FearInstance35: is this the specific emotion  
> annotated in this case, never to be used again, or is it an  
> "instance" in the sense that it is one particular kind of  
> combination of a categorical label and other annotations?

The way I wrote it is is so far underspecified.

When I wrote it I thought of it as specifically an event in which a  
particular person (Lady M) was feeling an instance of the DC-2006- 
Fear class.  Ug, I should not have written it as *DC-2006-Fear but  
rather DC-2006-Fear to indicate we are dealing with a class not an  
instance.

But, by contrast I suppose you could validly view it as you second  
alternative, i.e. to put it another way as one particular point in  
emotion space.  I would almost use your language exactly, i.e......

	 "one particular kind of combination of a categorical label and  
other annotations"

....but would prefer to say it this way....

	one particular *instance* of a combination of a categorical label  
and other annotations

....anyway,  My knee jerk at the moment is to view it in the former  
(event) way as opposed to the later (point in emotion space) way but  
I think it would be an unwarranted digression to decide that now.   
That is because I think I am again getting too model focused and not  
enough syntax focused.

>
> Also, the way that you structure it, *FearInstance35 being an  
> "instanceOf" *DC-2006-Fear, doesn't that imply you are giving more  
> fundamental reality to the categorical representation compared to  
> the "valence" dimension (which is not, in the example, derived from  
> any particular theory)?

Hrm, I am not sure I understand this point.  But first, as I said  
above I should have written it as...

*FearInstance35 -- instanceOf --> DC-2006-Fear

...rather than as....

*FearInstance35 -- instanceOf --> *DC-2006-Fear

....So, if you want me to answer the above question ask again via  
email or during the call.

Thanks,

Bill

>
> So much for now, best regards,
> Marc
>
> -- 
> Dr. Marc Schröder, Senior Researcher at DFKI GmbH
> Coordinator EU FP7 Project SEMAINE
> Chair W3C Emotion Markup Language Incubator Group 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 Thursday, 31 January 2008 01:51:02 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 31 January 2008 01:51:03 GMT