Subject: Re: [clue] Participant info/type followup

From: Roberta Presta <[email-masked]>
Date: Tue, 01 Apr 2014 12:15:27 +0200

Hi Christian,

In section 7.1.1.X we are dealing with media capture attributes and in 
section 7.1.1.11 we want to define an attribute conveying information 
about participants.
I would say that here we can find both information (*references*, in the 
data model) about "who is represented in the capture" ("captured 
participants"?) and "who is the owner of the generating device" ("owner"?).

Maybe participant metadata, such as Participant Information and 
Participant Type as they are currently defined, should be treated in a 
separate section of the same level of capture scenes or media captures as.
Indeed we showed in London that repeating the vcard and the role of the 
participants in each capture, as if they were capture attributes,  
causes redundancy.

I know that I have a data model definition perspective, but I would 
propose to make a change that is more coherent with what we will 
describe formally.

Cheers,

Roberta

Il 01/04/2014 03:30, Christian Groves ha scritto:
> Hello Paul, all,
>
> If we follow the approach that there is a specific indicating of 
> whether the participant information is based on an explicit indication 
> then I would suggest the following text for the framework:
>
> Clause 7.1.11 Participant information
> (Under the 1st paragraph)
>
> The participant information contains an explicit indication of whether 
> it relates to a participant contained in the capture, from a 
> participants capture device or both. For example a video camera may 
> capture an image containing the participant, or a participant may send 
> a video capture with a presentation that does not depict the participant.
>
> Something similar would be needed under participant type.
>
> Thoughts?
>
> Regards, Christian
>
> On 20/03/2014 6:46 AM, Paul Kyzivat wrote:
>> On 3/18/14 11:18 PM, Christian Groves wrote:
>>> Hello Paul,
>>>
>>> "How" they differ is given by the example bullets below the 
>>> sentence. If
>>> you want something more normative we could remove the "For example".
>>
>> Yeah, I don't believe in specification by example. :-)
>>
>> IMO it is a bit dicey to base this distinction on the type of capture.
>>
>> I'm more comfortable with an explicit syntactic indication of the 
>> distinction, such as proposed by Roberta.
>>
>>     Thanks,
>>     Paul
>>
>>> Regards, Christian
>>>
>>> On 7/03/2014 4:46 AM, Paul Kyzivat wrote:
>>>> On 3/6/14 5:30 PM, Christian Groves wrote:
>>>>> Hello Paul,
>>>>>
>>>>> The text says media type and presentation attribute. Is that the
>>>>> relationship you're talking about?
>>>>
>>>> "How the generated content relates to the entity described in the
>>>> participant info is dependent on media type and and the presentation
>>>> attribute."
>>>>
>>>> I take that to mean that the relationship may be different for
>>>> presentation streams than non-presentation streams. But it doesn't say
>>>> *how* they differ.
>>>>
>>>>     Thanks,
>>>>     Paul
>>>>
>>>>> Regards, Christian
>>>>>
>>>>> On 7/03/2014 4:20 AM, Paul Kyzivat wrote:
>>>>>> Christian,
>>>>>>
>>>>>> I've read the quoted text several times, and I cannot figure out how
>>>>>> to *derive* your example conclusions from it. The text says the
>>>>>> relationship is dependent on the presentation attribute, but not 
>>>>>> how.
>>>>>>
>>>>>> AFAICT I could make a new definition where the a participant 
>>>>>> attached
>>>>>> to a presentation capture means that the participant is shown in the
>>>>>> presentation, and that would be equally compatible with the text.
>>>>>>
>>>>>> ISTM that more text is required to actually specify the 
>>>>>> relationships.
>>>>>>
>>>>>>     Thanks,
>>>>>>     Paul
>>>>>>
>>>>>> On 3/6/14 2:05 PM, Christian Groves wrote:
>>>>>>> Hello all,
>>>>>>>
>>>>>>> To follow up on Jonathon's comments on participant info/type and 
>>>>>>> the
>>>>>>> semantics and particularly how it relates to a presentation. 
>>>>>>> Here's a
>>>>>>> first stab at some text to stimulate some discussions.
>>>>>>>
>>>>>>>
>>>>>>> "The participant info attribute allows a provider to associate
>>>>>>> participant information with the capture source. When used in an
>>>>>>> individual capture it indicates that the captured content (e.g.
>>>>>>> video/audio/text etc.) as opposed to the actual media streams is
>>>>>>> generated from the entity described. How the generated content 
>>>>>>> relates
>>>>>>> to the entity described in the participant info is dependent on 
>>>>>>> media
>>>>>>> type and and the presentation attribute.
>>>>>>>
>>>>>>> For example:
>>>>>>> - a video capture with participant info would indicate that the 
>>>>>>> video
>>>>>>> contains a picture of the entity associated with the information
>>>>>>> provided.
>>>>>>> - a video capture with participant info and the presentation 
>>>>>>> attribute
>>>>>>> would indicate that the presentation video is associated with the
>>>>>>> participant but could contain any video content.
>>>>>>> - a text capture with participant info would indicate that the 
>>>>>>> text is
>>>>>>> generated from the actual participant.
>>>>>>> - a text capture with participant info and the presentation 
>>>>>>> attribute
>>>>>>> would indicate that the text is associated with the participant but
>>>>>>> could contain any text content."
>>>>>>>
>>>>>>> Comments?
>>>>>>>
>>>>>>>
>>>>>>> Regards, Christian
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> clue mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/clue
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> clue mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/clue
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> clue mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/clue
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>

---

From: Christian Groves <[email-masked]>
Date: Wed, 02 Apr 2014 10:13:03 +1100

Hello Roberta,

 From a data model perspective I agree that it makes sense to have the 
participant metadata "referenced" to minimize duplication in the 
messages. So I support your solution in the data model to the redundancy 
problem.

In general I think its good to maintain consistency between the 
framework and the data model. However in London I thought this was more 
of a syntax shortcut (like the captureID wildcarding) rather than 
something we'd need to formalize in the framework. I guess we could add 
it at a higher level in the framework (it would functionally be the same 
thing), it would just be more work for the editor...

I could go either way on this.

Regards, Christian

On 1/04/2014 9:15 PM, Roberta Presta wrote:
> I would say that here we can find both information (*references*, in 
> the data model) about "who is represented in the capture" ("captured 
> Indeed we showed in London that repeating the vcard and the role of 
> the participants in each capture, as if they were capture attributes,  
> causes redundancy.
>
>> whether the participant information is based on an explicit 
>> indication then I would suggest the following text for the framework:
>>
>> The participant information contains an explicit indication of 
>> whether it relates to a participant contained in the capture, from a 
>> capture an image containing the participant, or a participant may 
>> send a video capture with a presentation that does not depict the 
>> participant.
>>
>>>>>>>> To follow up on Jonathon's comments on participant info/type 
>>>>>>>> and the

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 03 Apr 2014 11:30:23 -0400

ISTM we have both a semantic issue and a syntactic/terminological issue:

- we have the semantic distinction between who is represented within
   the capture and who is responsible for sending the capture

- we have a terminology issue regarding what to call these two things

I think we now agree that the semantic distinction is real and should be 
identified in the advertisement.

Regarding terminology, IMO we should use two different terms to identify 
these. At most one of them should be called "participant". Given the 
conflict with xcon, perhaps *neither* of them should be called participant.

This is mostly a data model issue. Some of it might need to peek through 
into the framework. And what does should be consistent.

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Fri, 04 Apr 2014 10:55:44 +1100

Hello Paul,

I think its a framework issue as much as a data model issue. The data 
model issue is really just the syntactic issue of minimizing the 
repeating of the participant information through a reference.

In the framework I think there are two options:
1. A participant information attribute where the applicability of this 
attribute (e.g. a participant is depicted by the capture, and/or a 
capture is from a participant) is indicated.

2. Two separate attributes: "Captured Participant/s" and "Capture 
originating from participant"

I think either will work. From a data model perspective where a 
reference will be used and given the XML structure probably the 2nd 
option would allow most alignment between the two.

Regards, Christian

On 4/04/2014 2:30 AM, Paul Kyzivat wrote:
> I think we now agree that the semantic distinction is real and should 
> be identified in the advertisement.
>
> Regarding terminology, IMO we should use two different terms to 
> identify these. At most one of them should be called "participant". 
> Given the conflict with xcon, perhaps *neither* of them should be 
> called participant.
>
> This is mostly a data model issue. Some of it might need to peek 
> through into the framework. And what does should be consistent.
>
>     Thanks,
>     Paul
>

---

From: "Duckworth, Mark" <[email-masked]>
Date: Fri, 4 Apr 2014 08:46:09 -0700

> -----Original Message-----
> From: clue [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: Thursday, April 03, 2014 11:30 AM
> To: [email-masked]
> Subject: Re: [clue] Participant info/type followup
> 

[Duckworth, Mark] I agree, but I thought the intent of the participant attributes was to give information about "who is represented within the capture" and not about "who is responsible for sending the capture".  From the framework:

    "... information regarding the conference participants *in* a Capture."
    "... indicates the type of participant/s contained *in* the capture..."

[Duckworth, Mark] I think we don't need to add a way to indicate "who is responsible for sending the capture".  IIRC, this was not a goal of the original proposal and discussion about "roles".  But if the group agrees we should add this now, I wouldn't object too strongly.

> identified in the advertisement.

[Duckworth, Mark] I'm mildly against adding the ability to describe "who is responsible for sending the capture".

> these. At most one of them should be called "participant". Given the conflict
> with xcon, perhaps *neither* of them should be called participant.
> 
> This is mostly a data model issue. Some of it might need to peek through into
> the framework. And what does should be consistent.
> 
> 	Thanks,
> 	Paul
> 
> > messages. So I support your solution in the data model to the
> > redundancy problem.

[Duckworth, Mark] I agree too.

> > framework and the data model. However in London I thought this was
> > more of a syntax shortcut (like the captureID wildcarding) rather than
> > something we'd need to formalize in the framework. I guess we could
> > add it at a higher level in the framework (it would functionally be
> > the same thing), it would just be more work for the editor...
> >
snip

---

From: Christian Groves <[email-masked]>
Date: Mon, 07 Apr 2014 12:21:10 +1000

Hello Mark,

Please see below.

Regards, Christian

> [Duckworth, Mark] I think we don't need to add a way to indicate "who is responsible for sending the capture".  IIRC, this was not a goal of the original proposal and discussion about "roles".  But…
[CNG] I agree when I proposed it I was thinking about "who was in the 
capture" rather than who was sending the capture. The issue only came to 
life when Jonathon asked what it meant for a presentation capture. I'd 
be OK to drop "who sends the capture" but we would still need to clarify 
the presentation capture case.