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

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

From: Chris Poppe <Chris.Poppe@ugent.be>
Date: Thu, 15 Apr 2010 10:11:23 +0200
To: <silviapfeiffer1@gmail.com>, <public-media-annotation@w3.org>
Message-ID: <098701cadc73$3d1d2370$b7576a50$@Poppe@ugent.be>
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 Thursday, 15 April 2010 08:11:53 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 15 April 2010 08:11:54 GMT