W3C home > Mailing lists > Public > public-html@w3.org > April 2011

Re: Systematic access to media/plugin metadata

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Wed, 13 Apr 2011 11:45:26 +1000
Message-ID: <BANLkTi=S4pZgnWf6a_EFEJhbD8X7Gd7tFQ@mail.gmail.com>
To: Danny Ayers <danny.ayers@gmail.com>
Cc: Laura Carlson <laura.lee.carlson@gmail.com>, Eric Carlson <eric.carlson@apple.com>, Henri Sivonen <hsivonen@iki.fi>, "public-html@w3.org" <public-html@w3.org>
Hi Danny,

last year, after lengthy discussions about metadata at the Open
Subtitles Summit I wrote a blog piece called "My metadata is not your
metadata", see http://blog.gingertech.net/2010/10/01/your-metadata-is-not-my-metadata/.

I think there are at least 3 different types of metadata and thus far
we are exposing some technical metadata and preparing means for timed
semantic metadata. What we really haven't got - and where Henri says:
show me the use case - is an interface for semantic, non-timed

We could just have such semantic non-timed metadata in video as part
of a WebVTT file in the header and expose it to JavaScript through
text tracks. That makes us independent of media formats, but requires
servers to extract metadata from within media resources into text
files. Not sure that's a good and acceptable solution.


On Wed, Apr 13, 2011 at 6:14 AM, Danny Ayers <danny.ayers@gmail.com> wrote:
> A couple of observations in passing.
> At least in the case of audio & video media elements, some access to
> metadata is already supported in the spec. However, from a developer's
> point of view it seems somewhat convoluted, and arbitrarily limited.
> For example, let's say the media object has embedded copyright
> information. If I understand correctly, accessing such information
> would involve steps including -
> * obtaining the text tracks and selecting those of kind "metadata"
> * processing the discovered material according to the specification of
> the media object
> I suppose the first part isn't a huge amount of work, but I would
> posit that it'll involve a few more lines of code than accessing, say,
> media.getMetadata("license").
> But the second part is something of a blocker, decoding the metadata
> is left to the developer - irrespective of whether or not the
> browser/media plugin has access to the content. (I'm by means
> suggesting that browsers should support every kind of metadata
> encoding, just suggesting that it's possible that in many cases such
> support is already available internally, but with the way the spec
> currently stands, unavailable to the developer). By the same token,
> might it not be reasonable to access an image's embedded metadata (if
> available) through a call like: image.getMetadata("license")?
> The other thing that came to mind, after looking at the page Laura's
> posted [1] is that there are two general groups of metadata detail
> potentially available: material that corresponds to some kind of
> alternate representation, such as alt="text" and transcript kind of
> things; material that describes other features of the resource, e.g.
> timestamp and geo coords embedded in Exif in a photo. Not sure of the
> value of this observation, beyond maybe it suggests two varieties of
> use cases.
> Cheers,
> Danny.
> [1] http://www.w3.org/html/wg/wiki/Metadata
> --
> http://danny.ayers.name
Received on Wednesday, 13 April 2011 01:46:14 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:36 UTC