[EMOXG] Roles and links thoughts

Dear all,

some thoughts on the links and roles:

I would like to argue for the role information being optional. I 
think it is not necessary for simple apps and makes it more 
cumbersome to use links.

Imagine a student who wants to use our language to write his very 
first emotion sensing application. He wants to read out the web cam 
of his PC, feed the video stream to a facial feature recognition 
software and use the output to animate a comic face.

He would like to use the <link/> element to point to the annotated 
video stream provided by the facial feature recognizer.

I don't think he should need to ponder about if that stream actually 
contains an "experiencedBy" information (from the user's 
perspective), or a "triggeredBy" info (from the cartoon's 
perspective), or even an "expressedBy" info (when he plans to use it 
as a training tool for actors).

Let's give him the chance to just point to the source and go on with 
his job.


Oh, just realised another thing:
When setting up ambient environments and connecting all those 
sensors, you don't really know which e.g. camera delivers what 
information at which time. And you don't really want to pre-define 
this. You just want to direct data streams to a database. You do 
need the link information, but the role information changes over 
time and needs to be added dynamically by the environment.
So the role would be undefined first and set to specific value later.

Might this be a compromise? having a role="unspecified" value?


Just what came into my mind when reading the minutes.
Or did I get you wrong?

Christian

Schuller schrieb:
> Hi all,
> 
> here are my minutes from session 2 of Friday's F2F in Cannes.
> 
> Best,
> 
> Bjoern
> 
> 
> 
> 
> 25.10.2008 11:00 AM - 01:00 PM
> Present: Marc Schröder (chair), Felix Burkhardt, Myriam Lamolle, Björn Schuller (scribe), Enrico Zovato, Alain Giboin (observer)
> 
> General topic Links to the "rest of the world":
> 
> Topic1: Links 1. Links to media and Links 3. The semantics of links to the "rest of the world"
> Topic2: Links 2. Position on a time line in externally linked objects
> 
> TOPIC1: Links 1. Links to media and Links 3. The semantics of links to the "rest of the world"
> ##############################################################################################
> 
> (Scribe's Summary: it is suggested to merge links 1+3 to one. There shall be 4 possible values for "link" with the role attribute thinking of "expressedBy" as default value and "experiencedBy", "triggeredBy", and "targetedAt":
> <emotion>
> <link uri="http:..." role="expressedBy"/>
> <link uri="http:..." role="triggeredBy"/>
> </emotion>)
> 
> Protocol:
> 
> Marc: let us focus on relation between links and semantics
> All: agreed
> Marc: there seems to be more or less agreement that URI should be the name of the link.
>       In Links 3 there is also a URI found.
>       Is it possible to define a fixed set of semantic roles?
>       Links must have a semantic meaning.
> All: agreed.
> Felix: with semantics giving the link "a name" is meant?
> Marc: yes.
> Felix: could we merge Links 1 and Links 3 to one?
> Marc: let's discuss having a link to media w/o semantic role of it.
> Felix: always having Links 3 defined seems complicated.
> Marc: trigger and target are less obvious and need additional info?
> Marc: I could also have a video of the cause of the emotion.
> Alain: in the media there is a trigger to the emotion?
> Marc: it is not always a media file, but e.g. text, a picture, etc.
> Marc: maybe we need only 4 roles?
> Felix: is this truly sufficient?
> Marc: the emotion induced in the annotator might be needed.
>       that is: the observed emotion and "what that does with me"
> Felix: more openness might be favourable?
> Enrico is in favour to fix it to the four.
> Bjoern: we can fix it in a respect of "it will be fixed" but leave the number open.
> Felix: for my use-case (annotation of phone calls) this feels like a work-around.
> Marc: let's not vote yet, but discuss.
> Bjoern: what about multimedia content like paintings or music? Do the four terms fit there?
> Marc: behaviour might be strange in that context.
> Myriam: let's assume it is a countryside. Than it would be trigger not behaviour.
> Felix: this seems not scientifically grounded. Simple things should look simple.
> Marc: maybe we have to allow for links w/o explicit semantics, but they have to carry implicit such.
> Marc: default values can be used.
> Myriam: agrees.
>         You can add another word/noun.
> Marc: that is what I want to avoid.
> Marc: from a recognition point of view would expression instead of behaviour work?
> Bjoern: I was thinking of "expressedBy"
> Marc: we could have this as default value.
>       we could alter the others equivalently: experiencedBy, triggeredBy
> Bjoern: and "targetedAt"
> Marc: those would be 4 possible values for the role attribute.
>       So we would have optional role attributes with default expressedBy.
>       Optionally also the MIME-type.
> Felix: I guess we cannot have synonyms?
> Marc: "context" was once suggested.
> Felix: why not call it "link"?
> Marc: yes...
>       this means that we have optionally several link tags (up to 4)
> Felix: I dislike "expressedBy"
> Enrico: is it possible  to have more links inside? (e.g. one to an audio file, one to a video file)
> Marc: that is not nice. But I do not disagree.
> Bjoern: I think it is necessary.
> Marc: this means we have a unlimited length of potential links. We could directly have the tag name.
> Felix: we could also use sub-classing (media:audio, media:video, etc.)
> Marc: what I don't like in this respect is the name "link".
>       If we want to have a generic name like link than having a role attribute is more consistent.
>       <link uri="http:..." role="expressedBy" mime-type="video..."/>
> Felix: <expressedBy uri="http:..."/>
> 
> Alternatives:
> 1)
> <emotion>
> <link uri="http:..." role="expressedBy"/>
> <link uri="http:..." role="triggeredBy"/>
> </emotion>
> 
> 2)
> <emotion>
> <expressedBy uri="http:..."/>
> <triggeredBy uri="http:..."/>
> </emotion>
> 
> Marc: would you find this elegant enough for your use case, Felix?
> Myriam: should this be used in another container, if expressedBy, triggeredBy are used directly?
> Marc: no. The (only) container is emotion.
> Felix: could we also mix these two variants?
> Marc: no.
> Marc: in the first case (using link) the default would be expressedBy
> Felix: now I would opt for the first solution.
> Bjoern: that's good. So would I as it is more consistent.
> Marc: Summarization: an attribute link with an optional "role" with default expressedBy.
> Alain: does this feel most natural for most users?
> Bjoern: alternative one seems to allow more easy extension.
> Marc: I disagree.
> Alain favours alternative 2 from an onthology/usability point of view.
> Bjoern: was it agreed that we merge link 1 and 3?
> Marc: yes.
> Felix: more or less.
> Marc: it is a pragmatic decision to call it link.
> All: we unite link 1 and link 3. We choose link as attribute (alternative 1) and implicitly always attach a semantic to a link, as the default value is "expressedBy".
> Marc: so let's now shift to link 2 - timing.
> 
> TOPIC2: Links 2. Position on a time line in externally linked objects
> #####################################################################
> 
> (Scribe's summary: we suggest to stick to "start/end" without "duration". It is not sufficient to have only absolute timing. "Onset/hold/decay" will not be foreseen at the moment. Felix formulates concrete level of detail before next Thursday.)
> 
> Protocol:
> 
> Marc: should there be an anchor wrt. absolute and relative times?
> Felix: absolute and relative is very important.
> Marc: people have different understandings of these two. So we need to specify these.
>       1) Absolute vs. relative?
>       2) How to syntactically define this?
>       2) Onset/hold/decay or even more fine?
>       4) We need to see where we have timing (where may it occur?)
> Felix: where it may occur is part of whether it is an element or an attribute?
> Marc: I do not appreciate having both choices.
> Felix: this is related to the use-cases.
> Bjoern: do we actually provide "onset/hold/decay"?
> Marc: we could see "trace" of intensity for that.
> Enrico: maybe "hold" would be sufficient?
> Marc: we also need an end.
>       This reminds me of gesture annotation in BML.
> Myriam: it is not necessary to have start and duration.
> Marc: four points would describe it.
> Bjoern: it should definitely be only four points.
>         I prefer implicit modelling by intensity.
> Marc: intensity names maximum in the hold phase.
> Felix: let's start with a simple restrictive approach.
> All: agreed.
> Felix: is duration an attribute on its own or an element.
> Bjoern: why do we need "duration"?
> Felix: for convenience.
> Marc: the anchor might be important. But start might then be set to zero.
> Bjoern: I dislike "duration"
> Marc: we could ask to use either start/duration or start/end exclusively.
> Felix: end is shorter than duration. so let's keep that.
> Marc: let's be radical and stick to start/end w/o duration.
> Marc: start/end. That's it?
> All: agreed.
> Marc: what about anchors?
> Felix: it seems very important. EMMA was very complicated about it.
> Marc: (quotes Ian) is absolute time a requirement? ...we could have an anchor instead.
> Bjoern: I opt for absolute time.
> Felix: absolute time could be a "political" issue: which calendar to use?
> Felix: is there a formal date format?
> Marc: date is not sufficient for absolute time: date+clock
> Marc: so how about having anchor points?
> Marc: we need to distinguish timing wrt. media (always rel. to beginning), timing wrt. emotion feels weird.
> Marc: one as timing of behaviour, the second as timing of the emotion itself.
> Myriam: there is a parallel time tag in SMIL e.g. if the video is shorter than the emotion.
> Felix: position on a time line should always be relative wrt. media. When was the emotion felt is always absolute.
> Marc: "Frank" gets upset 5sec after "Anna" makes her comment. How to encode this?
>       This will not work with Felix's suggestion.
>       It is not "expressedBy" and it is not relative.
>       It is not sufficient to have only absolute timing.
> Alain: example: the fear someone is having when taking a plane and watching a video on board.
> Marc: using samples is too system centric.
> Felix: agreed.
> Marc: onset/hold/decay will not be persued at the moment.
>       Felix will circulate examples.
>       We identified that wrt. media only relative time makes sense.
> Bjoern: we also need pointers to regions in images, word indeces in texts, etc.
> 
> ACTION ITEM: Felix to formulate concrete level of detail wrt. above statement DUE before next Thursday.
> 
> 
> ___________________________________________
> 
> Dr. Björn Schuller
> Lecturer
> 
> Technische Universität München
> Institute for Human-Machine Communication
> 
> Arcisstrasse 21
> D-80333 München
> Germany
> 
> Fax: ++49 (0)89 289-28535
> Phone: ++49 (0)89 289-28548
> 
> schuller@tum.de
> www.mmk.ei.tum.de/~sch
> ___________________________________________
> 
> This message is confidential. It may also be privileged or otherwise protected by work product immunity or other legal rules. If you have received it by mistake please let us know by reply and then delete it from your system; you should not copy it or disclose its contents to anyone. All messages sent to and from our institute may be monitored to ensure compliance with internal policies and to protect our business. Emails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. Anyone who communicates with us by email is taken to accept these risks.
> 
> 
> 
> 

-- 
------------------------------------------------------------------------
Christian Peter
Fraunhofer Institute for Computer Graphics Rostock
Usability and Assistive Technologies
Joachim-Jungius-Str. 11, 18059 Rostock, Germany
Phone: +49 381 4024-122, Fax: +49 381 4024-199
email: christian.peter@igd-r.fraunhofer.de
------------------------------------------------------------------------
Problems with the electronic signature? Please load the current root
certificate of the Fraunhofer-Gesellschaft into your browser!
(http://pki.fraunhofer.de/EN/)
------------------------------------------------------------------------