Re: [clue] Participant info/type followup

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:
> 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
>
> On 4/1/14 7:13 PM, Christian Groves wrote:
>> 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:
>>> 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
>>>>>>>>>> clue@ietf.org
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/clue
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> clue mailing list
>>>>>>>>> clue@ietf.org
>>>>>>>>> https://www.ietf.org/mailman/listinfo/clue
>>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> clue mailing list
>>>>>>>> clue@ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/clue
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> clue mailing list
>>>> clue@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/clue
>>>>
>>>
>>>
>>
>> _______________________________________________
>> clue mailing list
>> clue@ietf.org
>> https://www.ietf.org/mailman/listinfo/clue
>>
>
> _______________________________________________
> clue mailing list
> clue@ietf.org
> https://www.ietf.org/mailman/listinfo/clue
>