Re: [mawg] Re: ACTION-177: API at client/server side (was: Call for Test Cases)

OK. I understand your opinion, and agree to some extend. The burden of
implementing the appropriate APIs can be very high. But some people, maybe
Silvia, may expect such APIs.

Best,

Felix

2009/11/11 Bailer, Werner <werner.bailer@joanneum.at>

> As we discussed from the beginning on, we consider the development of these
> API not in scope of our group, but we use whatever existing APIs are
> available for extracting metadata from a media resource or parse a metadata
> format, and integrate these into our API implementation.
>
> I'm not sure if there should be a common interface between an API
> implementation and all the format specific APIs. I think this is just
> deferring the problem one layer, because such an interface would not be so
> different from the API we are defining. So an implementation that deals with
> format X has to take the burden of integration an appopriate API for
> accessing format X.
>
> This is my opinion on that issue, other comments are welcome.
>
> Best regards,
> Werner
>
> ________________________________
> Von: felix.sasaki@googlemail.com [felix.sasaki@googlemail.com] im Auftrag
> von Felix Sasaki [felix.sasaki@fh-potsdam.de]
> Gesendet: Mittwoch, 11. November 2009 12:39
> An: Bailer, Werner
> Cc: Pierre-Antoine; public-media-annotation@w3.org
> Betreff: Re: [mawg] Re: ACTION-177: API at client/server side (was: Call
> for Test Cases)
>
> Many thanks for the explanation, Werner. Another question: you wrote in a
> reply to Silvia about access to metadata:
>
> "Yes, that's why there are 2 paths in the diagram: from the metadata
> document via a format specific API, and/or from the media resource via an
> extractor and possibly also a format specific API."
>
> Who is working on the format-specific extractors, or to put it differently:
> how is the "common interface to all of these!" being realized?
>
> Best,
>
> Felix
>
> 2009/11/11 Bailer, Werner <werner.bailer@joanneum.at<mailto:
> werner.bailer@joanneum.at>>
> Hello Felix,
>
> we have created an action for Chris to propose a WebIDL notation for the
> function. Probably the arguments of the function will not change much to
> what we have, only that there is a first mandatory argument with the
> property name. As we need now a more general return type, this change would
> probably resolve some of our issues with the return types, as we will always
> get back a more or less self descriptive list of values.
>
> The idea is then to request further feedback from browser vendors before we
> go ahead and implement the changes in the API document.
>
> Best regards,
> Werner
>
> ________________________________
> Von: felix.sasaki@googlemail.com<mailto:felix.sasaki@googlemail.com> [
> felix.sasaki@googlemail.com<mailto:felix.sasaki@googlemail.com>] im
> Auftrag von Felix Sasaki [felix.sasaki@fh-potsdam.de<mailto:
> felix.sasaki@fh-potsdam.de>]
> Gesendet: Mittwoch, 11. November 2009 12:18
> An: Bailer, Werner
> Cc: Pierre-Antoine; public-media-annotation@w3.org<mailto:
> public-media-annotation@w3.org>
> Betreff: Re: [mawg] Re: ACTION-177: API at client/server side (was: Call
> for Test Cases)
>
> Hello Werner,
>
> sounds all very reasonable arguments to me. Is there a proposal for the
> structure of the function, and how will it relate to the API descriptions we
> have already? Maybe you can answer the question on a prototypical example
> like the "creator" property
> http://www.w3.org/TR/mediaont-api-1.0/#creators
>
> Thanks,
>
> Felix
>
> 2009/11/11 Bailer, Werner <werner.bailer@joanneum.at<mailto:
> werner.bailer@joanneum.at><mailto:werner.bailer@joanneum.at<mailto:
> werner.bailer@joanneum.at>>>
> Dear Pierre-Antoine,
>
> we had a discussion about this issue at the F2F, triggered by comments from
> Doug Schepers. The arguments for having one function are
>
> - browser vendors only need to implement one function to support the API
> - it might be convenient for web developers to query several properties by
> defining an array with property names and iterate over it
> - extensibility, both to new properties, but also wrt to subtypes, e.g.
> when we define a subtype "albumTitle" of title one could directly query for
> it, instead of using a filter on getTitle
>
> Best reagrds,
> Werner
>
> ________________________________________
> Von: public-media-annotation-request@w3.org<mailto:
> public-media-annotation-request@w3.org><mailto:
> public-media-annotation-request@w3.org<mailto:
> public-media-annotation-request@w3.org>> [
> public-media-annotation-request@w3.org<mailto:
> public-media-annotation-request@w3.org><mailto:
> public-media-annotation-request@w3.org<mailto:
> public-media-annotation-request@w3.org>>] im Auftrag von Pierre-Antoine [
> pierre-antoine.champin@liris.cnrs.fr<mailto:
> pierre-antoine.champin@liris.cnrs.fr><mailto:
> pierre-antoine.champin@liris.cnrs.fr<mailto:
> pierre-antoine.champin@liris.cnrs.fr>>]
> Gesendet: Montag, 09. November 2009 21:36
> An: Silvia Pfeiffer; public-media-annotation@w3.org<mailto:
> public-media-annotation@w3.org><mailto:public-media-annotation@w3.org
> <mailto:public-media-annotation@w3.org>>
> Betreff: Re: [mawg]  Re: ACTION-177: API at client/server side (was: Call
>  for Test Cases)
>
> Le 08/11/2009 03:43, Silvia Pfeiffer a écrit :
> > BTW: re javascript API: It should be a small number of functions, not
> > one per property ("getTitle" seemed to indicate to me that there was a
> > particular API function for it). If it turns out you need more than
> > one, that's fine. Just not one per property (which, incidentally, is
> > also more extensible).
>
> except for the point of extensibility, which I understand, could you
> elaborate on the rationale for "Just not one per property"?
>
> Although there has to be a generic function for the sake of
> extensibility, I think the general feeling of the group was that it is
> more convenient for a developer to write
>  getTitle(...)
> than
>  getProperty("title", ...)
>
>  pa
>
> >
> > I will keep watching the progress of the group - I am also subscribed.
> >
> > Thanks,
> > Silvia.
> >
> >
> > On Fri, Nov 6, 2009 at 7:08 PM, Bailer, Werner
> > <werner.bailer@joanneum.at<mailto:werner.bailer@joanneum.at><mailto:
> werner.bailer@joanneum.at<mailto:werner.bailer@joanneum.at>>> wrote:
> >> Dear Silvia, all,
> >>
> >> thanks for your mail, you are asking a very good question. In fact, we
> discussed about that yesterday before you joined, resulting in an action to
> visualise the options we discussed.
> >>
> >> Attached is a sketch showing two options:
> >>
> >> 1. implementation as Javascript interface in the browser, requiring also
> all the functionality for extracting metadata from the source formats and
> for mapping there (I think this is the option you are discussing in your
> mail)
> >>
> >> 2. implementation as a web service, accessing either remote or local
> (e.g. database of a portal in proprietary format) media resources and
> metadata, there could be an (optional) Javascript library that provides the
> same API interfaces and handles the calls to the web service
> >>
> >> Feedback is of course highly welcome.
> >>
> >> Concerning the two proposals:
> >>
> >> - single function: no final decision, but it is very to likely
> >>
> >> - other formats: we have already done the mappings for QuickTime, we
> should do it for the others you mentioned
> >>
> >> Best regards,
> >> Werner
> >>
> >> ________________________________________
> >> Von: public-media-annotation-request@w3.org<mailto:
> public-media-annotation-request@w3.org><mailto:
> public-media-annotation-request@w3.org<mailto:
> public-media-annotation-request@w3.org>> [
> public-media-annotation-request@w3.org<mailto:
> public-media-annotation-request@w3.org><mailto:
> public-media-annotation-request@w3.org<mailto:
> public-media-annotation-request@w3.org>>] im Auftrag von Silvia Pfeiffer [
> silviapfeiffer1@gmail.com<mailto:silviapfeiffer1@gmail.com><mailto:
> silviapfeiffer1@gmail.com<mailto:silviapfeiffer1@gmail.com>>]
> >> Gesendet: Samstag, 07. November 2009 01:11
> >> An: Joakim Söderberg
> >> Cc: public-media-annotation@w3.org<mailto:
> public-media-annotation@w3.org><mailto:public-media-annotation@w3.org
> <mailto:public-media-annotation@w3.org>>
> >> Betreff: Re: Call for Test Cases
> >>
> >> Hi all,
> >>
> >> I was going to ask some questions that emerged over the last hour, but
> >> unfortunately it seems the group has finished meeting.
> >>
> >> I have a question about where you are going to use the API that you're
> >> defining. One suggestion that I heard was as a javascript interface to
> >> the metadata available in a video/audio file referenced in a <video>
> >> or <audio> element of HTML5.
> >>
> >> Is this indeed something you are contemplating?
> >>
> >> In this case, it would be great to have:
> >> * a single function and not multiple to access the metadata,
> >> and
> >> * analysis of the metadata used in to QuickTime, Ogg, MPEG4, FLV and
> >> whether it matches with the API.
> >>
> >> I'd be happy to help promote the generic function into HTML5 when the
> >> spec is finalised.
> >>
> >> Cheers,
> >> Silvia.
> >>
> >>
> >> 2009/11/6 Joakim Söderberg <joakim.soderberg@ericsson.com<mailto:
> joakim.soderberg@ericsson.com><mailto:joakim.soderberg@ericsson.com
> <mailto:joakim.soderberg@ericsson.com>>>:
> >>> Hello everyone,
> >>>
> >>> As a result of the 5th F2F meeting in Santa Clara we have started to
> define
> >>> our test suite
> >>> requirements (
> http://www.w3.org/2008/WebVideo/Annotations/wiki/TestSuite).
> >>> We kindly ask the workgroup participants for some more example test
> cases!
> >>> We came up with some example test cases:
> >>>
> >>> 1) getTitle
> >>> The API should deal with the situation that
> >>>  1) there is no title
> >>>  2) there are multiple titles (that all come from different metadata
> >>> formats)
> >>>  3) multiple types of title (such as Album title, Song title)
> >>>
> >>> 2) Make sure that the API can get additional metadata that are referred
> to
> >>> in the embedded metadata
> >>> ex. An XMP description referring to another metadata document ( a
> license
> >>> etc.)
> >>> 3) For the Ontology
> >>> Take two metadata resources that represent the same thing and make sure
> that
> >>> the API return the same values.
> >>>
> >>> 4) Write something in the wrong way, fake a metadata format that is not
> >>> valid with a metadata specification and see what the API should do with
> it,
> >>> return in anyway, or not return it at all.
> >>>
> >>> 5) Combination example
> >>> Get the value of the title and then filter
> >>>
> >>> Asking for a generic property like title, then filter the result to get
> just
> >>> the album title,
> >>> and second directly ask for Album title and compare the results.
> >>>
> >>> See more at:
> >>> http://www.w3.org/2008/WebVideo/Annotations/wiki/TestSuite
> >>> Regards
> >>> Joakim Söderberg
> >>>
> >>
> >>
> >
>
>
>
>