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

On Feb 10, 2011, at 0:23 , Bailer, Werner wrote:

> 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.

Yes.  These examples 
  compression={ , "/3" }
  compression={ , "c125" }
  compression={ , "34712" }
should probably have a note saying that though these are valid results, it would be more helpful to provide an identifier by either (a) mapping the compression type into a controlled vocabulary, such as the EBU and SMPTE provide or (b) defining a controlled vocabulary for these names (e.g. urn:org:iptc:codecs:c125).

> - 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.

I was encouraged to do this in a previous specification, and so now I copy it into each place I write that a URI is used as a label. In this case, I am not sure it's needed, but as it's a suggestion, it's probably not harmful either.  I don't mind.

> - typo: " Either _one_ or both ..."

"Either one or both", "Either or both", -- either or both are correct in english, but you are right, putting the "one" in makes it easier to read for an international audience.


I also notice that SMPTE URIs do not have a fragment part, so I need to revise the text to allow that.  And "URU" should be "URI", sorry, typo.

Here is the fixed up text again:

* * * * *

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 one 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 starts with an absolute-URI (RFC 3986,
section 4.3)  and should normally contain a fragment (RFC 3986, section 3.5), that is, be in the
form absolute-URI#name. In this form, the absolute-URI identifies the naming
convention used for the second parameter, which is a string name from
that convention.  If a URL is used for the absolute-URI, 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.

* * * *

> 
> 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.
>> 
> 
> 

David Singer
Multimedia and Software Standards, Apple Inc.

Received on Thursday, 10 February 2011 18:54:55 UTC