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 00:09:25 UTC