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

RE: Systematic access to media/plugin metadata

From: Leonard Rosenthol <lrosenth@adobe.com>
Date: Mon, 11 Apr 2011 18:35:25 -0700
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>, Henri Sivonen <hsivonen@iki.fi>
CC: Danny Ayers <danny.ayers@gmail.com>, "public-html@w3.org" <public-html@w3.org>
Message-ID: <D23D6B9E57D654429A9AB6918CACEAA98059A5FB5A@NAMBX02.corp.adobe.com>
I wouldn't want/expect a defined structure such as you show below.  

Instead, I think you need/want a more query-like API where the caller specifies a known "key" and is presented (if it exists) a known "value".  This would fit well into the Media Annots WG work, where common sets of "keys and values" for various media types have already been defined AND MAPPED to standard metadata formats.


-----Original Message-----
From: Silvia Pfeiffer [mailto:silviapfeiffer1@gmail.com] 
Sent: Monday, April 11, 2011 3:20 AM
To: Henri Sivonen
Cc: Danny Ayers; Leonard Rosenthol; public-html@w3.org
Subject: Re: Systematic access to media/plugin metadata

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 Tuesday, 12 April 2011 01:35:59 UTC

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