Re: RE : Recapitulation of ma:format vs. ma:compression.

I think that the advantage of splitting it is that the pair of names actually establishes a framework for interop.

"These are names as defined in XXXXX"
"Name"
"Name"

and so on.  OK, if I understand the label XXXXX, then I know that, if I want a codec I implement, then its name (in that space) will be the one I recognize as being defined for it in that space.  I.e. the spec. label establishes (or not) a terminology space.  Someone publishes a document that says "the identifier for this namespace is XXXX" which then goes on to say "and the names defined ar X, Y, Z".

Single labels do not have this characteristic of establishing a domain of discourse.

On Jan 21, 2011, at 4:09 , Pierre-Antoine Champin wrote:

> On 01/19/2011 08:51 PM, David Singer wrote:
>> My suggestion is, if we don't want to define the names, then allow the attribute to indicate who does:
>> 
>> 'codec called pthublthu by urn:ebu:committees:codecs-naming:2011'
>> 
>> telling people to give URIs to the committee/authority/group/organization who invented the names is reasonable.
> 
> sounds reasonable indeed;
> although in that case I would be tempted to coin a URI derived from the URI of the organization, like
> 
>  urn:ebu:committees:codecs-naming:2011:pthublthu
> 
> :)
> 
>  pa
> 
>> 
>> On Jan 19, 2011, at 2:26 , Pierre-Antoine Champin wrote:
>> 
>>> David,
>>> 
>>> first, for the record, I have no strong opinion about ma:compression, having not the technical/practical knowledge about the subject.
>>> 
>>> I understand your point about not having a well defined value space, and how it hinders interoperability, but I think we are reaching the limit of the scope of the group.
>>> 
>>> Our ontology defines a mapping of the *properties* in various legacy formats, which is a first step. Even if it does not solve all the interoperability problems, it goes in the right direction.
>>> 
>>> What you suggest implies that we define a mapping of all the *possible values* in those legacy formats, which would be a huge task, and probably a mistake:
>>> 
>>> * this would make it much more costly to implement the API. It is better to have a less-interoperable API implemented, than a highly-interoperable API specified but that no one wants to implement.
>>> 
>>> * once the API is implemented and actually *used*, good value-spaces will be used and bad value-spaces will be abandoned. After a while, when the Media Ontology 1.1 is specified, we will have more feedback to constrain the values in a way that makes sense to the users.
>>> 
>>> Of course, this is a delicate trade-off. But the fact that there is no clear consensus in the group regarding the preferred value-space, it seems that specifying one at this stage would be premature.
>>> 
>>> regards
>>> 
>>>  pa
>>> 
>>> 
>>> On 01/18/2011 06:54 PM, David Singer wrote:
>>>> so, you're saying its use is a private field, that there is no interoperable behavior?  I can do what I like, and you can either ask me or guess or hope?
>>>> 
>>>> 
>>>> On Jan 18, 2011, at 9:34 , Evain, Jean-Pierre wrote:
>>>> 
>>>>> Very last comment...
>>>>> 
>>>>> This is not the point.
>>>>> 
>>>>> You can do what you want and other can do what they want. The ontology allow different approaches.
>>>>> If you can convince a community to do it your way, fair enough.
>>>>> If others wnat to use a different approach using e.g. classification schemes and URI pointing to termIds fair too.
>>>>> 
>>>>> The proposal was to have everything mixed up in ma:format (using extended Mime types as a possible implementation) and there was no agreement to remove ma: compression.
>>>>> 
>>>>> We decided to keep ma:format and ma:compression.
>>>>> 
>>>>> How you use these attributes is actually secondary. And there is no one way.
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> ________________________________________
>>>>> De : David Singer [singer@apple.com]
>>>>> Date d'envoi : mardi, 18. janvier 2011 17:38
>>>>> Ā : Evain, Jean-Pierre
>>>>> Cc : Joakim Söderberg; 'Bailer, Werner'; public-media-annotation@w3.org
>>>>> Objet : Re: Recapitulation of ma:format vs. ma:compression.
>>>>> 
>>>>> OK, so you seem to think an undefined value space for this attribute results in something useful happening.  Perhaps I am failing to see what.  Can you explain, or perhaps answer my previous question as to what the value of this attribute is in some common or less common cases?
>>>>> 
>>>>> How about, again, in an unknown container format:
>>>>> 
>>>>> * uncompressed 8-bit-per-sample audio
>>>>> * uLaw audio
>>>>> * aLaw audio
>>>>> * Intel Indeo video
>>>>> * Cinepak video
>>>>> * Theora video
>>>>> * IMA 4:1 audio
>>>>> 
>>>>> Or, you could even answer the question where the mime type of the container format is identified, but it has no definition of a codecs parameter.
>>>>> 
>>>>> I want to know what useful, interoperable, meaningful use of this attribute there might be, and so far, no-one has suggested even the inkling of one.  Without that, it does not belong in a specification.
>>>>> 
>>>>> 
>>>>> On Jan 18, 2011, at 8:29 , Evain, Jean-Pierre wrote:
>>>>> 
>>>>>> Don't make this personal. Ridiculous
>>>>>> 
>>>>>> There were several voices against the removal of ma:compression.
>>>>>> 
>>>>>> I am just trying to make sure that only one position is not being enforced, i.e. the one of the two companies to have authored the incriminated RFC.
>>>>>> 
>>>>>> I won't add anything to that silly discussion.
>>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: David Singer [mailto:singer@apple.com]
>>>>>> Sent: mardi, 18. janvier 2011 17:27
>>>>>> To: Evain, Jean-Pierre
>>>>>> Cc: Joakim Söderberg; 'Bailer, Werner'; public-media-annotation@w3.org
>>>>>> Subject: Re: Recapitulation of ma:format vs. ma:compression.
>>>>>> 
>>>>>> No, happily it is the working group's job, and the w3c's, to make sure that the specifications issued by the w3c make sense, not yours.
>>>>>> 
>>>>>> On Jan 18, 2011, at 8:24 , Evain, Jean-Pierre wrote:
>>>>>> 
>>>>>>> Your choice.
>>>>>>> 
>>>>>>> -----Original Message-----
>>>>>>> From: David Singer [mailto:singer@apple.com]
>>>>>>> Sent: mardi, 18. janvier 2011 17:24
>>>>>>> To: Evain, Jean-Pierre
>>>>>>> Cc: Joakim Söderberg; 'Bailer, Werner'; public-media-annotation@w3.org
>>>>>>> Subject: Re: Recapitulation of ma:format vs. ma:compression.
>>>>>>> 
>>>>>>> Our job is to write a useful specification where interoperability is achieved.
>>>>>>> 
>>>>>>> Without any definition of the value space of this attribute, it is meaningless, non-interoperable, and useless. I do not want my name associated with such poor work. You may differ.
>>>>>>> 
>>>>>>> On Jan 18, 2011, at 7:57 , Evain, Jean-Pierre wrote:
>>>>>>> 
>>>>>>>> And only professional standardisers have the time to register all this.
>>>>>>>> 
>>>>>>>> I am in any case not a MIME type enthusiast when you see on going practice developing as many private extensions as industries or groups of interest.
>>>>>>>> 
>>>>>>>> In any case. Nobody in the media annotation prevents you from using it e.g. in format. And if others prefer to use ma:compression, so they can.
>>>>>>>> 
>>>>>>>> For me, the discussion is over anyway. Both is allowed and one can do what he prefers.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> -----Original Message-----
>>>>>>>> From: David Singer [mailto:singer@apple.com]
>>>>>>>> Sent: mardi, 18. janvier 2011 16:44
>>>>>>>> To: Evain, Jean-Pierre
>>>>>>>> Cc: Joakim Söderberg; 'Bailer, Werner'; public-media-annotation@w3.org
>>>>>>>> Subject: Re: Recapitulation of ma:format vs. ma:compression.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Jan 18, 2011, at 6:49 , Evain, Jean-Pierre wrote:
>>>>>>>> 
>>>>>>>>> And extended MIME type don't solve this issue either.
>>>>>>>> 
>>>>>>>> absolutely not true.  Extended mime types have definitions;  anyone is free to write an extension of, or an RFC similar to, the buckets RFC for MP4 files.  And it's clear that at the moment, this is the only documentation of an extended mime type for codecs.  It's clear that it does work for this one case, and does not for any other.
>>>>>>>> 
>>>>>>>> On the other hand, there are precisely zero definitions of names of codecs independent of their container type, as far as I know.  Which is why I insist that if you retain this attribute, you define what its value-space is.  Or else it is useless and there is no interoperability.
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: David Singer [mailto:singer@apple.com]
>>>>>>>>> Sent: mardi, 18. janvier 2011 15:43
>>>>>>>>> To: Evain, Jean-Pierre
>>>>>>>>> Cc: Joakim Söderberg; 'Bailer, Werner'; public-media-annotation@w3.org
>>>>>>>>> Subject: Re: Recapitulation of ma:format vs. ma:compression.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On Jan 18, 2011, at 0:15 , Evain, Jean-Pierre wrote:
>>>>>>>>> 
>>>>>>>>>> All the names listed e.g. in the mpeg classification schemes of audio and video codecs are of course eligible for use in compression.
>>>>>>>>> 
>>>>>>>>> I don't think that answers the question.  I repeat, what is the namespace?  Who defines the names?  Where is the registry?
>>>>>>>>> 
>>>>>>>>> The identifier used for H.264 in mpeg-2 transport is quite different from the one used in MP4, and quite different from the one used in ASF.  Which one do you use, or something else?
>>>>>>>>> 
>>>>>>>>> This field is completely pointless if its contents are undefined, which is the current state, as far as I can tell.
>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: David Singer [mailto:singer@apple.com]
>>>>>>>>>> Sent: mardi, 18. janvier 2011 00:41
>>>>>>>>>> To: Joakim Söderberg
>>>>>>>>>> Cc: Evain, Jean-Pierre; 'Bailer, Werner'; public-media-annotation@w3.org
>>>>>>>>>> Subject: Re: Recapitulation of ma:format vs. ma:compression.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On Jan 17, 2011, at 0:48 , Joakim Söderberg wrote:
>>>>>>>>>> 
>>>>>>>>>>> I'm sorry, I forgot that there was a vote about the name for "ma:compression" in April 2010. So to clarify, the present suggestion is:
>>>>>>>>>>> format
>>>>>>>>>>> compression
>>>>>>>>>>> 
>>>>>>>>>>> We should add "recommend practice of RFC4281 whenever possible" to description text for "format", and explain that ma:compression, can be used to describe the encoding of a track rather than a complete file.
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> I still don't understand what the names of compression formats are.  I am unaware of a uniform namespace.
>>>>>>>>>> 
>>>>>>>>>> Can you tell me what I would put in there, if format is left empty, if I want to express:
>>>>>>>>>> 
>>>>>>>>>> * Cinepak video
>>>>>>>>>> * Theora video
>>>>>>>>>> * IMA 4:1 audio
>>>>>>>>>> * uLaw audio
>>>>>>>>>> * Intel Indeo Video
>>>>>>>>>> 
>>>>>>>>>> ?
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>> Ok?
>>>>>>>>>>> 
>>>>>>>>>>> /Joakim
>>>>>>>>>>> 
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: Evain, Jean-Pierre [mailto:evain@ebu.ch]
>>>>>>>>>>> Sent: den 17 januari 2011 09:13
>>>>>>>>>>> To: 'Bailer, Werner'; Joakim Söderberg
>>>>>>>>>>> Cc: public-media-annotation@w3.org
>>>>>>>>>>> Subject: RE: Recapitulation of ma:format vs. ma:compression.
>>>>>>>>>>> 
>>>>>>>>>>> Dear all,
>>>>>>>>>>> 
>>>>>>>>>>> I second the position of Werner to keep ma:compression for the same reasons.
>>>>>>>>>>> 
>>>>>>>>>>> Additionally, I have a problem with the methodology used. This is now a very old subject. Several changes to the ontology have been discussed two telcos ago (and I'll come back in another mail about things agreed and not implemented yet).  The use of MIME types had been discussed before the time of this call and the issue wasn't raised. And here it comes again.
>>>>>>>>>>> 
>>>>>>>>>>> The way the issue is (re-re-re-) presented is also weird. Why say we are back to where we started? There was a proposal. There was motivated disagreement. Hence, no consensus, no change.
>>>>>>>>>>> 
>>>>>>>>>>> End of the story.
>>>>>>>>>>> 
>>>>>>>>>>> Regards,
>>>>>>>>>>> 
>>>>>>>>>>> Jean-Pierre
>>>>>>>>>>> 
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: public-media-annotation-request@w3.org [mailto:public-media-annotation-request@w3.org] On Behalf Of Bailer, Werner
>>>>>>>>>>> Sent: lundi, 17. janvier 2011 08:49
>>>>>>>>>>> To: Joakim Söderberg
>>>>>>>>>>> Cc: public-media-annotation@w3.org
>>>>>>>>>>> Subject: RE: Recapitulation of ma:format vs. ma:compression.
>>>>>>>>>>> 
>>>>>>>>>>> Dear Joakim, all,
>>>>>>>>>>> 
>>>>>>>>>>> Thanks for the summary, I'd like to add two points here:
>>>>>>>>>>> - We should recommend the use of RFC4281 whenever possible, but we cannot rely that they exist for a particular format.
>>>>>>>>>>> - There is a second reason to keep ma:compression (or codec), which is to describe the encoding of a track rather than a complete file.
>>>>>>>>>>> 
>>>>>>>>>>> Best regards,
>>>>>>>>>>> Werner
>>>>>>>>>>> 
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: public-media-annotation-request@w3.org [mailto:public-media-
>>>>>>>>>>>> annotation-request@w3.org] On Behalf Of Joakim Söderberg
>>>>>>>>>>>> Sent: Montag, 17. Jänner 2011 08:36
>>>>>>>>>>>> To: public-media-annotation@w3.org
>>>>>>>>>>>> Subject: Recapitulation of ma:format vs. ma:compression.
>>>>>>>>>>>> 
>>>>>>>>>>>> Hello,
>>>>>>>>>>>> 
>>>>>>>>>>>> Some advice on the mailing list suggested that the rfc4281 mime-type
>>>>>>>>>>>> extensions should be in ma:format, and to delete ma:compression or use
>>>>>>>>>>>> it for the case there are no codec parameters, and rename it to
>>>>>>>>>>>> "ma:codecs".
>>>>>>>>>>>> 
>>>>>>>>>>>> However, the group consensus was that it's not a way forward, since
>>>>>>>>>>>> extended mime-types are not widely in use. So I would say we are back
>>>>>>>>>>>> where we started; with ma:format and ma:compression. Unless we want to
>>>>>>>>>>>> rename ma:compression to ma:codec?
>>>>>>>>>>>> 
>>>>>>>>>>>> /Joakim
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> David Singer
>>>>>>>>>> Multimedia and Software Standards, Apple Inc.
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> David Singer
>>>>>>>>> Multimedia and Software Standards, Apple Inc.
>>>>>>>>> 
>>>>>>>>> -----------------------------------------
>>>>>>>>> **************************************************
>>>>>>>>> This email and any files transmitted with it
>>>>>>>>> are confidential and intended solely for the
>>>>>>>>> use of the individual or entity to whom they
>>>>>>>>> are addressed.
>>>>>>>>> If you have received this email in error,
>>>>>>>>> please notify the system manager.
>>>>>>>>> This footnote also confirms that this email
>>>>>>>>> message has been swept by the mailgateway
>>>>>>>>> **************************************************
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> David Singer
>>>>>>>> Multimedia and Software Standards, Apple Inc.
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> David Singer
>>>>>>> Multimedia and Software Standards, Apple Inc.
>>>>>>> 
>>>>>> 
>>>>>> David Singer
>>>>>> Multimedia and Software Standards, Apple Inc.
>>>>>> 
>>>>> 
>>>>> David Singer
>>>>> Multimedia and Software Standards, Apple Inc.
>>>> 
>>>> David Singer
>>>> Multimedia and Software Standards, Apple Inc.
>>>> 
>>>> 
>>> 
>>> 
>> 
>> David Singer
>> Multimedia and Software Standards, Apple Inc.
>> 
>> 
> 
> 

David Singer
Multimedia and Software Standards, Apple Inc.

Received on Saturday, 22 January 2011 02:23:21 UTC