Re: Systematic access to media/plugin metadata

On Fri, Apr 8, 2011 at 10:58 PM, Danny Ayers <danny.ayers@gmail.com> wrote:
> 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.

I agree on all accounts.

The main learning that I personally got from the media annotation WG's
work is the actual fields that should be made available for metadata
of audio and video. Maybe we can have a mediaMetadata struct that has
those (if available) plus an additional type field (e.g. XMP) similar
to what you suggested, so it would be possible for an author to use
another means to extract that more specific metadata.

Cheers,
Silvia.


>
> 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 Saturday, 9 April 2011 11:05:34 UTC