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

Hi Silvia and all,

On 16/04/2010 01:52, Silvia Pfeiffer wrote:
> 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
> function:
>   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
> propertyName.

I'm not sure this was implied here. I don't remember us discussing the
*order* of multiple return values, but indeed, relating it to the order
of metadataSources seems like a reasonable default choice...

> 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.

with the proposed API, nothing prevents you from creating separate
MAResource for separate metadata sources, if you want to keep them
separate...
But you can also create one that aggregate them, if you do not care for
the provenance, e.g. if you equaly trust the different sources.

Furthermore, it seems to me that your examples below make the asumption
that we know in advance which subset of metadata is contained in each
metadata source, which may not always be the case.

As for the language attribute, it will not always be the case that a
metadata source will use a single language for all its properties. For
example, an RDF file may contain :

<video.ogg> dc:title
  "Planet of the apes"@en,
  "La planète des singes"@fr .

So you can't really escape the per-value language attribute, can you?

  pa

> 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
> metadataSources);
> 
> e.g.
> 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.
> 
> Cheers,
> Silvia.
> 
> 
> 
> 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 (2.3.1.3).
>>
>>
>>> 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 2.3.2.1 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 Monday, 19 April 2010 13:11:24 UTC