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: Mon, 11 Apr 2011 20:19:54 +1000
Message-ID: <BANLkTinJYBCUnvF=hn8LyrEfxxDo8abSUg@mail.gmail.com>
To: Henri Sivonen <hsivonen@iki.fi>
Cc: Danny Ayers <danny.ayers@gmail.com>, Leonard Rosenthol <lrosenth@adobe.com>, "public-html@w3.org" <public-html@w3.org>
On Mon, Apr 11, 2011 at 5:16 PM, Henri Sivonen <hsivonen@iki.fi> wrote:
> On Sat, 2011-04-09 at 21:04 +1000, Silvia Pfeiffer wrote:
>> 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.
> Do you mean the API would give the caller the source text of the XMP
> blob and the implementation of the API (a browser) wouldn't include an
> RDF processor? (Even so, getting this close to XMP looks like a slippery
> slope towards including various RDF machinery next.)
> I think any work in this area should be firmly grounded in use cases.
> (So far, the Danny's use case of building a content indexer for a
> client-side search engine or catalog doesn't seem compelling enough to
> me to bother extending the platform, because content indexing seems to
> be an area that is distinctly well-suited for the *server* side.)

Hi Henri,

I don't think we were talking about RDF - I certainly wasn't. I was
thinking about exposing one struct, such as

mediaMetadata {
  readonly attribute DOMString language;
  readonly attribute DOMString title;
  readonly attribute DOMString creator;
  readonly attribute Date creationDate;
  readonly attribute DOMString copyrightHolder;
  readonly attribute DOMString license;

as this data can be extracted from the media resource oftentimes.

You are right wrt  XMP and other such things, though, that they would
probably be better suited to a different solution. RDF of Microdata or

However, there is indeed the question about what this would be used
for. After all, we do not expose the metadata stored in image formats
either. I can only see a use case in that exposing the metadata from
within a media resource on screen without having to go through a
server-side database is easier if you don't want to actually develop a
media application and just publish a few videos. OTOH it can also
potentially be undesirable by the content owner to expose this
metadata, so maybe it's indeed not something that should be exposed to

Note that my comment was merely saying that if there was something
like an approach required to expose media metadata, I would prefer
having a name-value list rather than hierarchical structures.

Received on Monday, 11 April 2011 10:20:42 UTC

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