RE: Moving the MA Ontology to 2nd LC, ma:compression, yet again

I don't see it as an objection but as a late contribution. ;-)

I can agree with this as this is the approach EBU is following with EBUCore, but if applied consistently across the ontology and not only to compression -> genre, etc..

Please look at my different mails.

JP

-----Original Message-----
From: public-media-annotation-request@w3.org [mailto:public-media-annotation-request@w3.org] On Behalf Of Thierry MICHEL
Sent: jeudi, 10. février 2011 09:29
To: Bailer, Werner
Cc: David Singer; public-media-annotation@w3.org
Subject: Re: Moving the MA Ontology to 2nd LC, ma:compression, yet again

Due to David's objection, I have stopped the Publication of the document.

We will discuss this at our F2F in Cupertino.

Thierry

Le 10/02/2011 09:23, Bailer, Werner a écrit :
> Hi David,
>
> Thanks for your comment, I agree that the current definition text is inconsistent (and does not correctly reflect the consensus discussed in the call).
>
> Basically I agree to the definition you proposed, with the following comments:
> - Splitting into two attributes makes it clearer to know whether the value is a URI or free text, and is useful for applications that know which type of value they expect. Others need to check the content both values.
> - I'm not sure if we should include the suggestion to include the date in the URI: typically, these will already exist, and someone using this spec does not have control over them.
> - typo: " Either _one_ or both ..."
>
> Best regards,
> Werner
>
>> -----Original Message-----
>> From: public-media-annotation-request@w3.org [mailto:public-media-
>> annotation-request@w3.org] On Behalf Of David Singer
>> Sent: Donnerstag, 10. Februar 2011 01:09
>> To: public-media-annotation@w3.org
>> Subject: Re: Moving the MA Ontology to 2nd LC, ma:compression, yet
>> again
>>
>> Hi guys
>>
>> I have reviewed the ma:compression documentation, and we're in a
>> strange state;  what's there is the semantics I suggested using a
>> comma, not the revision following Jean-Pierre's suggestion using a "#";
>> and the syntax doesn't match.  We need to fix this before we send the
>> document for review.
>>
>> I just read through and found as many of the references for deriving
>> the compression value, from as many formats as I could.  It wasn't
>> possible for all of them, alas.
>>
>> Here is another suggestion for this attribute;  it preserves both the
>> possibility of a controlled vocabulary URI, and an uncontrolled
>> vocabulary string, but by keeping them distinct we allow them to have
>> precise syntax and semantics.  I believe that this (a) supports all the
>> mappings -- at least the ones I can verify -- in the document and (b)
>> supports all the expressed needs and use cases I have heard of.  We may
>> the value a tuple of the two parts, both optional.
>>
>> (Obviously we could fiddle with the formatting, documentation, names
>> used here, and so on.)
>>
>> * * * * *
>>
>> compression
>>
>> { (attName="identifier", attValue="URI" )?, (attName="indicator",
>> attValue="String")? }
>>
>> The compression type used. For container files (e.g., QuickTime, AVI),
>> the compression is not defined by the format, as a container file can
>> have several tracks that each use different encodings. In such a case,
>> several compression instances SHOULD be used. Thus, querying the
>> compression property of the track media fragments will return different
>> values for each track fragment.
>>
>> Either or both of two values may be supplied, an identifier and an
>> indicator. The indicator is a free-form string; this can be used when a
>> string is desired for user-display, or when the naming convention is
>> lost or unknown.
>>
>> The identifier is a URI that consists of a absolute-URU (RFC 3986,
>> section 4.3)  and fragment (RFC 3986, section 3.5), that is, in the
>> form absolute-URI#name. The absolute-URI identifies the naming
>> convention used for the second parameter, which is a string name from
>> that convention.  A URL is preferred for the URI, and if it is used, it
>> (a) should contain a date in the form mmyyyy, indicating that the owner
>> of the domain in the URL agreed to its use as a label around that date
>> and (b) should be de-referencable, yielding an informative resource
>> about the naming convention.
>>
>> Note that this use of URIs with fragments also closely matches RDF (see
>> <http://www.w3.org/TR/rdf-concepts/#section-fragID>).
>>
>> Note that for some container files, the format parameter can also carry
>> an extended MIME type to document this; see [RFC 4281] for one such
>> instance.
>>
>> * * * *
>>
>> Hypothetical examples:
>>
>> compression={"urn:example-org:codingnames2010#ITU-H264", "Advanced
>> Video Coding"}
>> compression={"http://example.net/012011/standards/codecs.htm#G711"}
>> compression={, "Raw audio"}
>>
>> where ITU-H264 and G711 are defined by example.org (who also defined a
>> URN to identify their naming conventions), and by example.net (who use
>> a URL to identify theirs). The second example gives only an identifier,
>> and the third example has no identifier, only an indicator.
>>
>> More concrete examples:
>>
>> compression={ , "/3" }
>>    -- layer 3 compression in an ID3 block in an MP3 file
>> compression={"urn:x-ul:060E2B34.0401.0101.04020202.03020500", "MPEG
>> Layer II/III"}
>>    -- layer 2 or 3 compression, SMPTE
>>
>> compression={ , "AVC MP@L42" }
>>    -- AVC compression, Cablelabs
>> compression={ , "c125" }
>>    -- AVC compression, IPTC
>>
>> compression={ , "34712" }
>>    -- JPEG 2000, TIFF
>>
>>
>> David Singer
>> Multimedia and Software Standards, Apple Inc.
>>
>
>

Received on Thursday, 10 February 2011 08:51:07 UTC