- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Mon, 11 Apr 2011 20:19:54 +1000
- 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 something. 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 script. 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. Cheers, Silvia.
Received on Monday, 11 April 2011 10:20:42 UTC