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

Re: ACTION-410: Proposal for response to HTML WG

From: Thierry MICHEL <tmichel@w3.org>
Date: Thu, 28 Apr 2011 09:54:33 +0200
Message-ID: <4DB91D39.9040201@w3.org>
To: Pierre-Antoine Champin <pierre-antoine.champin@liris.cnrs.fr>
CC: "Bailer, Werner" <werner.bailer@joanneum.at>, "public-media-annotation@w3.org" <public-media-annotation@w3.org>
Same for me, sorry for my late answer, +++1 . Please send.

Thierry.

Le 26/04/2011 19:09, Pierre-Antoine Champin a écrit :
> Sorry for my late answer, but a big +1 to this proposal.
>
>    pa
>
> On 04/19/2011 03:27 PM, Bailer, Werner wrote:
>> Dear all,
>>
>> Please find below a proposal for the response to the HTML WG's discussion about issues with the MAWG specs for access to media metadata in HTML.
>>
>> Best regards,
>> Werner
>>
>> -------8<------------
>>
>> We are following the discussion on access to media metadata with high interest, as this problem is central to the scope of the Media Annotations WG. From your discussion, it seems that you are aiming for a simple and flexible solution. This is also what MAWG has in mind, and thus we would like to understand better which of your requirements are not satisfactorily adressed by the MAWG specs.
>>
>> First of all, as some of you probably know, MAWG is working on two specs: an Ontology for Media Resources and an API for Media Resources. The ontology is defined informally as a set of basic properties of media items, together with mapping to a number of standards and formats. We are covinced that this approach (what Danny called "upper ontology") is necessary to establish interoperability, i.e., enable the use of the metadata without knowing about the specifics of the source format. Note that the metadata properties defined by MAWG are not at all a required set of properties to be provided - depending on the source format only few of them may be available. In addition, the ontology is defined formally as an RDF ontology. The ontology can be thus be used without the API, e.g., included in HTML using RDFa.
>>
>> The API builds on top on the ontology, providing a way of querying the set of properties in a homogeneous way independent of the source formats. It seems that most of the criticism in the your discussion actually targets the API, i.e., the fact that getMediaProperty is called with a set of parameters and the complexity of the return structure. Actually, our first draft was more like the .language example in Danny's post, but we got the feedback that (i) browser manufacturers would prefer an API with as few functions as possible and (ii) web developers would rather get a result list and iterate through the results of the different properties than calling distinct functions for each of them (Silvia attended this discussion back at TPAC 2009). If an application is just interested by the value of the property, just accessing the .value of the result and ignoring the other atrributes would do. Also, implementing a simpler flavour of the API that just offers a function to get a
 p
> roperty without parameters (except for the property name, they are all optional) and returns just the value would be quite straight forward.
>>
>> We are of course interested that the MAWG specs are suitable for use in HTML, thus we would like to understand which are the obstacles for using in the view of the HTML WG in order to consider appropriate adjustments to our specs.
>>
>> -------8<------------
>>
>> -----------------------------------------------------------------------
>>    Werner Bailer
>>    Audiovisual Media Group
>>
>>    DIGITAL - Institute of Information and Communication Technologies
>>
>>    JOANNEUM RESEARCH Forschungsgesellschaft mbH
>>    Steyrergasse 17, A-8010 Graz, AUSTRIA
>>
>>    phone:  +43-316-876-1218            personal fax: +43-316-876-91218
>>    mobile: +43-699-1876-1218            general fax: +43-316-876-1191
>>    web:    http://www.joanneum.at/digital
>>    e-mail: mailto:werner.bailer@joanneum.at
>> -----------------------------------------------------------------------
>>
>>
>>
>
>
Received on Thursday, 28 April 2011 07:54:56 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:41 UTC