Re: RE : Metadata access

I don't like cross-posting so just a quick reply to the last question.

At the W3C, HTML5 is about to go into LC. I don't think there are any
predictions on when it will reach the next maturity levels.

At the WHATWG there is no versioning on HTML any more and development
will just continue.

Silvia.


On Thu, Apr 28, 2011 at 6:04 PM, Evain, Jean-Pierre <evain@ebu.ch> wrote:
> Hello,
>
> I couldn't have said it more clearly. Let's not waste more of our time on this.
>
> Actually this is an issue I raised during the W3C web&TV workshop when I felt there was something lacking coordination in the kingdom of W3C.
>
> This is certainly very much highlighted in this discussion but extends to the problem of overlap and complementarity between all the attributes developed in e.g. the video tag and their relationship to the work on RDFa, hence MAWG's RDF, etc.
>
> Even on RDFa, it seems that many people are now looking forward to publish more data in RDFa with limited knowledge if not interest for RDF ;-(
>
> There would certainly need to be a serious discussion on the W3C aims and purposes here.
>
> When is HTML5 due? 2014 or 2015?
>
> Regards,
>
> Jean-Pierre
>
>
>
>
> ________________________________________
> De : public-html-request@w3.org [public-html-request@w3.org] de la part de Silvia Pfeiffer [silviapfeiffer1@gmail.com]
> Date d'envoi : jeudi, 28. avril 2011 09:51
> Ā : Florian Stegmaier
> Cc : David Singer; Joakim Söderberg; public-html@w3.org; public-media-annotation@w3.org; lrosenth@adobe.com; danny.ayers@gmail.com; schepers@w3.org
> Objet : Re: Metadata access
>
> Hi Florian,
>
> I don't think it matters for HTML if this interface is not in the
> Media Annotations spec. What matters is what will eventually go into
> the HTML spec and I don't think that needs to be developed by the
> Media Annotations WG. So, do not stress over LC issues there - you
> should just leave it as it is IMHO.
>
> Regards,
> Silvia.
>
> On Wed, Apr 27, 2011 at 11:29 PM, Florian Stegmaier
> <stegmai@dimis.fim.uni-passau.de> wrote:
>> Dear Silvia, Leonard, David, all,
>>
>> since the API for Media Resource [1] is right before 2nd LC, it would be the right time to include this into our current specification in easy fashioned way. Please let me explain the idea:
>>
>> Currently, we only have MediaAnnotation as a super type of all properties defined in the Ontology of Media Resource [2] holding attributes valid for each property. Taken this into account, we could split up into two layers of conformance at this point:
>>
>> - MediaAnnotation (attribute supportedMode)
>> - - SimpleMediaAnnotation implements MediaAnnotation (attribute propertyName; attribute value;)
>> - - DetailedMediaAnnotation implements MediaAnnotation (attribute propertyName; attribute value; attribute language; ...)
>> - - - <PropertySpecificSubInterfaces_1> implements DetailedMediaAnnotation
>>      ...
>> - - - <PropertySpecificSubInterfaces_n> implements DetailedMediaAnnotation
>>
>> Here, Silvias proposal for only having key-value pairs would be implemented in "SimpleMediaAnnotation", whereas "DetailedMediaAnnotation" would implement the specific attributes as we have defined them yet. This would also follow the (a)sync design approach. There could be also a translation between these two forms of representing properties since "SimpleMediaAnnotation" is somehow a subset of "DetailedMediaAnnotation". I think DetailedMediaAnnotation could be also modeled to implement SimpleMediaAnn. Following this proposal, someone can implement the simple key-value API as a "thin layer".
>>
>> Please let me ask you another question, which could be a interesting things for us to know: Do you have a preference for one of the two modes of operations (synchronous or a synchronous) of the API? At the moment we assume to have the asynchronous mode as default.
>>
>> Feedback on this more than welcome!
>>
>> Best regards,
>> Florian
>>
>> [1] http://dev.w3.org/2008/video/mediaann/mediaont-api-1.0/mediaont-api-1.0.html
>> [2] http://dev.w3.org/2008/video/mediaann/mediaont-1.0/mediaont-1.0.html
>> _____________________________
>> Dipl. Inf. Florian Stegmaier
>> Chair of Distributed Information Systems
>> University of Passau
>> Innstr. 43
>> 94032 Passau
>>
>> Room 248 ITZ
>>
>> Tel.: +49 851 509 3063
>> Fax: +49 851 509 3062
>>
>> stegmai@dimis.fim.uni-passau.de
>> https://www.dimis.fim.uni-passau.de/iris/
>> http://twitter.com/fstegmai
>> _____________________________
>>
>> Am 27.04.2011 um 00:50 schrieb David Singer:
>>
>>>
>>> On Apr 26, 2011, at 4:30 , Silvia Pfeiffer wrote:
>>>
>>>> 2011/4/26 Joakim Söderberg <joakim.soderberg@ericsson.com>:
>>>>> Dear all,
>>>>> Recently the Ontology for Media Resources and API has been discussed in your forum. On behalf of the Media Annotations WG, I would like to share our response below.
>>>>>
>>>>> 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 addressed 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 convinced 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 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).
>>>>
>>>>
>>>> Indeed. And my continuous feedback was that IMHO a name-value-pair
>>>> interface would be the most complexity that would be required. I don't
>>>> like the complexity of the return structures - never have.
>>>
>>> would it hurt to define both APIs?  After all, the simple one is trivially (if not optimally) implemented on top of the 'complex' one...
>>>
>>> David Singer
>>> Multimedia and Software Standards, Apple Inc.
>>
>> _____________________________
>> Dipl. Inf. Florian Stegmaier
>> Chair of Distributed Information Systems
>> University of Passau
>> Innstr. 43
>> 94032 Passau
>>
>> Room 248 ITZ
>>
>> Tel.: +49 851 509 3063
>> Fax: +49 851 509 3062
>>
>> stegmai@dimis.fim.uni-passau.de
>> https://www.dimis.fim.uni-passau.de/iris/
>> http://twitter.com/fstegmai
>> _____________________________
>>
>>

Received on Thursday, 28 April 2011 08:29:00 UTC