Re: Systematic access to media/plugin metadata

On 7 April 2011 09:42, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote:

> Let's also not forget the work of the W3C Media Annotations Working Group.
> http://www.w3.org/2008/WebVideo/Annotations/

Personally I'm not convinced of the appropriateness of this work to
the HTML effort, for two reasons:

Primarily - it defines what you (should) get in too rich a fashion.
While complexity is certainly a consideration, my main gripe is that
the API effectively constrains what is (made) available. I can
probably best explain what I mean alongside an example, below.

Secondarily - I personally believe the way the ontology is used here
is wrong-minded. It's certainly useful to have a mapping between terms
common to the numerous metadata standards, but as presented here it
goes beyond being a "pivot ontology" and more into the realms of
"upper ontology". Web-based vocabularies allow the data producer and
consumer to use models that are appropriate for their application
requirements e.g. if you want to refer to a film then in some
circumstances just the title will be adequate, at other times you
might want access to, say, the bitrate of a particular encoding. The
promotion of a single ontology to cover all (or at least most) cases
moves the emphasis back from the open, distributed world back into a
legacy centralized picture.

Ok, an example. From [1] :

[[
language = video.getMediaProperty(["language"]);

if(noErrorStatus(language[0].status) == true) {
    ...
}
 
/** Resulting in:
 * [ { "Language" : {
 *         "propertyName" : "language",
 *         "languageLabel" : "en-us",  
 *         "statusCode" : 200
 *         }
 * } ]
 */
]]

How to get the value is largely a matter of taste:

   language = video.getMediaProperty(["language"]);

is ok as it stands, though I quite like :

   language = video.meta("language");

(or even
   language = video.language
as long as the next point is taken into consideration)

Where my issues with it start is with the error check. I don't think
that's necessary at this point. Either a property-value pair is
available or it isn't, so it should be considered reasonable to ask
for *anything* and either a value will be returned or null.

The results? Most of what is returned above is redundant. Why not just:

   ["en-us"]

(returning an array seems the best bet as properties can have multiple values)

Note this doesn't preclude the use of the Media Annotations approach
as well - there's only a fairly simple transformation needed in either
direction.

>> (Even though my personal opinion is that we need only name-value pairs
>> for metadata.)

Right. But also name-value pairs can support richer structures when
the value is a pointer. In this particular case the obvious choice for
a pointer is a URI, which could be dereferenced to get more
information. It's arguable that this would suggest adding another
field to the result data to say whether it's a string or URI. I'm open
to persuasion, but I reckon a regex match would be adequate.

Cheers,
Danny.

[1] http://dev.w3.org/2008/video/mediaann/mediaont-api-1.0/mediaont-api-1.0.html#example-in-javascript-3

-- 
http://danny.ayers.name

Received on Friday, 8 April 2011 12:58:37 UTC