W3C home > Mailing lists > Public > public-media-annotation@w3.org > February 2011

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

From: Evain, Jean-Pierre <evain@ebu.ch>
Date: Thu, 10 Feb 2011 09:45:40 +0100
To: 'David Singer' <singer@apple.com>, "public-media-annotation@w3.org" <public-media-annotation@w3.org>
Message-ID: <7D1656F54141C042A1B2556AE5237D60010EAF92EF53@GVAMAIL.gva.ebu.ch>
David, all,

I was busy yesterday and didn't check the final version but certainly the example should use the # and not a comma.

Otherwise, The new proposal using an 'identifier' or 'indicator' is a global question of modelling. What I mean by this is that it shouldn't apply only to compression (but also e.g. to genre). The question is do we keep only one attribute accepting two possible values or do we split each attribute with a URI/string pair into two attributes.

In the xml representation of EBUCore, genre or compression would be defined through three attributes: a label (corresponding to Dave's indicator), a definition (a string for the definition of the term and / or of the issuing entity), and/or a link (a URI corresponding to Dave's Identifier).  I can therefore very well understand this logic.

The use of an object property with a non-defined range (URI by default being used if available) and a label was the subject of a specific discussion before we adopted this design for RDF.  Even is the ontology table was modified to separate all URI/string pairs into two attributes with one possible value, I am not sure that this would change our approach for an RDF implementation. The RDF as currently defined actually suggest (as mentioned above) that you use a link or label (identifier or indicator).

Best regards,

Jean-Pierre 



-----Original Message-----
From: public-media-annotation-request@w3.org [mailto:public-media-annotation-request@w3.org] On Behalf Of David Singer
Sent: jeudi, 10. février 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.


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

Received on Thursday, 10 February 2011 08:46:20 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 10 February 2011 08:46:21 GMT