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

Re: [W3C Media Annotation WG] Request for Expert Review (API)

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Fri, 16 Apr 2010 10:52:09 +1000
Message-ID: <i2s2c0e02831004151752xefb2674aq71fb398a4502c0a2@mail.gmail.com>
To: Chris.Poppe@ugent.be
Cc: public-media-annotation@w3.org
Hi Chris,

Thanks for the clarification of how the interface seems to have been designed.

I can now see how you have designed the interface to associate
multiple metadata resources with one media resource through the
  boolean setContext(in DOMString mediaResource, in optional Object[]
metadataSources );

>From what you are describing, the order in which the metadataSources
are given in the second parameter will be important, since getProperty
will return for every one of these resource the value of the requested

I must admit I am uncomfortable with an API that chunks all the
possible metadata formats together in one return object. I would
rather that the list of metadata resources is administrated at a
higher level and not within the Media Annotations API.

Thus, my approach to your examples would be:

1. Set up a handler to handle the relationship between the media
resource and a metadata resource:

MAObject setMAResource ( in DOMString mediaResource, in MetadataSource

maobject = setMAResource ("video1.ogv", "DC_creator.rdf");
maobject = setMAResource ("video1.ogv","MPEG-7_technical.xml");
maobject = setMAResource ("video1.ogv", "MPEG-7_creator.xml");
maobject = setMAResource ("video1.ogv", "MPEG-7_technical1.xml");
maobject = setMAResource ("video1.ogv", "MPEG-7_technical2.xml");

Note that these resources only have a value for a single one of all
the dimensions of the maobject. I would rather think that there is a
DC_video1.rdf or MPEG7_video1.xml which has all the dimensions and
then getProperty will return something on all of these dimensions.

The getProperty function would then do something like:

<propertyClass> getProperty(in DOMString propertyName, in optional
DOMString fragment);

e.g. in your example let's say we have three DC descriptions in 3
different languages: DC_video1_hu.rdf, DC_video1_fr.rdf,
DC_video1_en_us.rdf and created a handler for them as above:

maobject1 = setMAResource ("video1.ogv", "DC_video1_hu.rdf");
maobject2 = setMAResource ("video1.ogv", "DC_video1_fr.rdf");
maobject3 = setMAResource ("video1.ogv", "DC_video1_en_us.rdf");

It is then quite clear that
maobject1 has as property {language:"hu", sourceFormat:"DC"}
maobject2 has as property {language:"fr", sourceFormat:"DC"}
maobject3 has as property {language:"en-us", sourceFormat:"DC"}

and these properties do not have to be replicated for the individual properties.

Then you can get the properties with:

title1 = maobject1.getProperty("title");
  returning a json object: {value:"A Majmok bolygója"}

title2 = maobject2.getProperty("title");
  returning a json object: {value:"La planete des singes"}

title3 = maobject2.getProperty("title");
  returning a json object: {value:"Planet of the apes"}

In my opinion, this would be a cleaner API that just helps to expose
any given metadata in a standard way.

Of course, how your standardised metadata structure will actually be
included into another language is ultimately not something that can be
predefined here. So our discussion may ultimately be void anyway.


On Thu, Apr 15, 2010 at 6:11 PM, Chris Poppe <Chris.Poppe@ugent.be> wrote:
> Dear Silvia, all,
> To clarify some aspects I want to present following thoughts about the api,
> more specifically on the getProperty method:
> MAObject[] getProperty(in DOMString propertyName, in optional DOMString
> sourceFormat, in optional DOMString subtype,
>                                                                   in
> optional DOMString language, in optional DOMString fragment );
> Imagine our MediaResource is a movie (Planet of the Apes).
> Some annotations are available for this movie. With "annotation" I mean a
> metadata instance. With "some annotations" I mean that metadata can be
> available in:
>        * different formats (DC, MPEG-7, ...), either describing different
> properties (DC_creator.rdf, MPEG-7_technical.xml) or the same properties
> (DC_creator.rdf, MPEG-7_creator.xml)
>        * multiple instances of the same format (MPEG-7_technical.xml,
> MPEG-7_creator.xml) describing different properties (first file describes
> technical               metadata, second file describes author)
>        * multiple instances of the same format (MPEG-7_techical1.xml,
> MPEG-7_technical2.xml) describing the same properties (e.g., two
> independently                   created MPEG-7 files, both having values for
> resolution, titles, descriptions, creators and so on)
> So I can imagine that our movie has 3 DC annotations (for example one made
> by a Hungarian, one by a French guy and one English). In fact, all of these
> could have a title in there and a description.
> getProperty("title") would return an array with 3 titles (or more correct, 3
> MAObjects implementing the title interface) each in a different language,
> - title[0] (value:"A Majmok bolygója",    language:"hu",
> sourceFormat:"DC")
> - title[1](value:"La planete des singes", language:"fr",
> sourceFormat:"DC")
> - title[2](value:"Planet of the apes",    language:"en-us",
> sourceFormat:"DC")
> getProperty("title", "", "en-us") would return an array with only one
> element, being the English title.
> - title[0](value:"Planet of the apes", language:"en-us", sourceFormat:"DC")
> Moreover, in my point of view the annotation could be from different
> metadata formats (e.g., Hungarian used DC, French and English guys used
> MPEG-7). So note that I assume here that there can exist different metadata
> instances from equal or different metadata formats, created by different
> authors, and in different languages.
> This means that for different properties there could be multiple instances.
> This is why we allow to filter in the getProperty operation on the
> sourceFormat.
> getProperty("title") would again return an array with 3 titles (or more
> correct, 3 MAObjects implementing the title interface):
> - title[0](value:"A Majmok bolygója",     language:"hu",
> sourceFormat:"DC")
> - title[1](value:"La planete des singes", language:"fr",
> sourceFormat:"MPEG-7")
> - title[2](value:"Planet of the apes",    language:"en-us",
> sourceFormat:"MPEG-7")
> getProperty("title", "", "MPEG-7") would only return the titles which can be
> retrieved from the MPEG-7 annotation of this content.
> - title[0](value:"La planete des singes", language:"fr",
> sourceFormat:"MPEG-7")
> - title[1](value:"Planet of the apes",    language:"en-us",
> sourceFormat:"MPEG-7")
> This would allow for instance to get the creation date only if it is
> originally mapped from an EXIF annotation (since this can be assumed to be
> more correct), or the creator only if it comes from MPEG-7 (since here we
> can assume that more information on the creator is available) and so on.
> The same occurs for the subtype, e.g, if alternative titles are available
> for instance "Monkey Planet" (just making this up).
> getProperty("title) would return an array with 2 titles (or more correct, 2
> MAObjects implementing the title interface) (let's disregard the other
> arguments and languages):
> - title[0] (value:"Planet of the apes", type:"Main title")
> - title[1] (value:"Monkey Planet",      type:"Alternative title")
> getProperty("title", "", "", "Alternative title") would yield an array of
> one element.
> - title[0] (value:"Monkey Planet", type:"Alternative title")
> This is at least how I understood the current API.
> Additionally, some remarks can be found inline ([CP2]) below.
> Kind regards,
> Chris
> -----Original Message-----
> From: public-media-annotation-request@w3.org
> [mailto:public-media-annotation-request@w3.org] On Behalf Of Silvia Pfeiffer
> Sent: donderdag 15 april 2010 2:19
> To: Chris.Poppe@ugent.be
> Cc: public-media-annotation@w3.org
> Subject: Re: [W3C Media Annotation WG] Request for Expert Review (API)
> Hi Chris,
> Thanks for your feedback on the review. I will put some more comments
> inline where there needs to be clarifications.
> Group feedback will indeed be of value!
> On Thu, Apr 15, 2010 at 1:43 AM, Chris Poppe <Chris.Poppe@ugent.be> wrote:
>> 2. Section 2.1: Language
>> I would not define Language as a part of the return value of some of
>> the properties - it is very unlikely that a annotation uses different
>> languages for different properties. I would only manage the language
>> on the level of the metadata source level.
>> [CP] It could be the case that different annotations are available for one
>> media resource (e.g. 3 MPEG-7 files). I agree that within one annotation
>> typically the language remains the same, but I would not be surprised to
> see
>> multi-lingual annotations appear in the future (e.g., a review by a French
>> man on a Hungarian movie).
> Even in this case, your annotation will be, e.g. a title and an author
> and a genre and a publisher - these will all be given in the same
> language, e.g. all in English. It seems we are mixing two different
> uses of "language" here - one that describes the language in which the
> metadata is given and one that is actually metadata about the content.
> You might want to separate these.
> [CP2] Maybe I did not make myself clear, we do separate the language of the
> content from the language of the metadata. The language interface is purely
> on metadata level. To get the language of the content we can use the
> language property (
>> Also, I believe that the API should be independent of a format and
>> thus the sourceFormat and the subtype parameters are not useful.
>> [CP]The idea was that in some cases an application might want to get back
>> metadata of a specific format only. In any case, when not including a
>> sourceformat you get back the metadata regardless the underlying format.
> The
>> subtype allows to refine a search for metadata (e.g., requesting for the
>> contributors gives both producers and actors. Using the subtype you could
>> ask for only those contributors that are actors).
> IIUC the idea of Media Annotations API is to provide an API
> independent of the source format. If you wanted to directly use an
> existing format, you'd use an API that is provided for that particular
> format. Is is impossible to return in a MAObject data in the unmapped
> format of the underlying media resource - all you can do is return a
> text string of all the annotations. If that is really desired, that
> should be a different API call, something like
> getMetadataResource(file).
> [CP2] I hope my examples above have clarified this.
> I have now understood the use of "subtype" - but you will need to
> register a lot of default strings there for all the elements.
>> Also, I believe the API should be independent of the language in use -
>> if you really wanted language selection to be made on the metadata
>> files, then this should be handled at a different level.
>> [CP] If nothing is filled in for the language argument it is in fact
>> language independent. Do you think that the optional language argument is
>> really an issue?
> See above - we need to be clear which use case we are satisfying with
> the "language" argument and rather than making it an argument, I would
> make it a part of the return struct from the function calls.
> [CP2] It is part of the return struct for those properties that can have
> multi-lingual values. The argument allows to filter on the language during
> the function call itself.
>> However, in the current state it would rather be:
>> id[0].value =
> "http://www.w3c.org/2008/WebVideo/Annotations/wiki/Image:MAWG-Stockholm-2009
>> 0626.JPG"
>> id[0].type = "URI"
> What is id[0] supposed to be?
> "video" is the video resource.
> "video.getProperty" provides the media annotations information for
> that resource for the specified dimension, which is "identifier".
> "identifier" returns a struct consisting of value and type. There can
> only be one such struct. Thus, it's id.value and id.type that address
> the elements in the struct.
> [CP2] I hope my examples above have clarified this.
>> 6. Section Contributor
> <..>
>> * in this example, you have a set of return values, so the spec needs
>> to look different:
>> interface Contributors {
>>    attribute DOMString value;
>>    attribute DOMString type;
>> }
>> interface Contributor: MAObject {
>>    attribute Contributors[] contributor;
>> }
>> * JSON reply thus looks something like:
>> {    "Contributor": {
>>           // This first lot is inherited from MAObject, though I am
>> unclear what the values should be
>>            "unstructuredValue": ???,
>>            "uri" : ???,
>>            "sourceFormat": ???,
>>            "fragmentIdentifier": ???,
>>            "mappingType": ???,
>>            "contributor": [ {
>>                     "value":
> "http://individuals.example.com/Contributor1",
>>                     "type": "editor"
>>                     },
>>                     {
>>                     "value":
> "http://individuals.example.com/Contributor2",
>>                     "type": "producer"
>>                     }]
>>     }
>> }
>> [CP] As mentioned before we could always have a set of return values.
> I would recommmend against a set of MAObjects be created as a return
> value for a single function call.
>> 22. Section 2.5.3 getOriginalData
>> * the return value should not be a DOMString list - it's simply a
>> single, very long string for the requested source format - not for all
>> possible formats
>> [CP] We assume that for one format multiple annotations can be available
>> (e.g., different MPEG-7 files). So this is the reason for the list of
>> DOMStrings
> Parsing of those formats and presentation of their content in native
> form is not the aim of the Media Annotations API. Rather, an abstract
> API to deal with all formats is the goal. So, you should not provide
> helper functions for every possible media format. That should be
> provided through a custom library for those formats.
> [CP2] I hope my explanation above has clarified the return of the array of
> strings. If there are 2 MPEG-7 annotations or files, the result would be 2
> strings, each holding the content of one MPEG-7 file.
> Cheers,
> Silvia.
Received on Friday, 16 April 2010 00:53:02 UTC

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