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

As you will see in my other response to David, if you do it for compression YOU MUST apply the same approach for all attributes using a pair URI/string. It is a matter of consistency.

See my point about the RDF design, which I believe is not impacted by this.

But what is the potential impact on the API??

Jean-Pierre

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

Thank you David for the observation, and your proposal. Is should solve the previous problems. I suggest we accept it for a new publication.

Regards
/Joakim

-----Original Message-----
From: public-media-annotation-request@w3.org [mailto:public-media-annotation-request@w3.org] On Behalf Of Bailer, Werner
Sent: den 10 februari 2011 09:24
To: David Singer
Cc: public-media-annotation@w3.org
Subject: RE: Moving the MA Ontology to 2nd LC, ma:compression, yet again

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:49:02 UTC