[alt-media-res] Fw: Metadata Digest, Vol 4, Issue 11
zoe at esemplastic.net
Thu Nov 16 17:17:53 GMT 2006
> Message: 2
> Date: Thu, 16 Nov 2006 13:29:11 +0100
> From: "jamie king" <jk.jamie at gmail.com>
> Subject: [Metadata] towards tx metadata 0.2 -- responses and additions
> To: metadata at transmission.cc
> <9a987a760611160429t1d9c6aa6v74a7b3f773484278 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> Dear Metadaters (apologies :))
> Thanks for all the responses to the few suggestions we made in our working
> document. Now that the 'response guillotine' has fallen we've looked over
> comments and tried to arrange them for the sake of accessibility. Your
> should be addressed, if they're not, sorry! We can add them in the next
> We have also spent some time looking at different clients out there and
> hacked some changes to a couple of them (e.g. Democracy Player). More in
> body of the responses.
> We updated the Recommendations file somewhat to reflect the discussion so
> New URL for that: www.shiftspace.cc/j/meta/tx_report_0.2.pdf.
> 1. RIGHTS & LICENSING
> The comments about rights fell into two categories:
> a. legal/social stance & approach
> We think the discussion here bears out the suggestion made in our
> that rights issues are best decided at the point of markup by the
> group doing the work.
> With respect to Jo Walsh's valuable comments, we consider a formal
> social/political/legal stance on rights outside the domain of the metadata
> schema proposed here (and note we do *not* say this is not socially
> 'merely technical' :)). While for example our own V2V.cc has taken a clear
> on such issues, we think that a metadata schema allowing *choice* at the
> of markup is the best way forward.
> This does not in any way prevent CMS and service designers writing
> their systems according to their proclivities and/or those of their
> The schema is agnostic and broad-church precisely so that
> it can be partisan and specific.
> While our position hasn't changed with regards to licensing, we would like
> make clear that we personally very much support licenses and or statements
> encourage sharing, re-use and so forth. Our personal practices in this
> are probably well known by now!
> b. actual implementations of metadata
> (i) should we allow multiple types of rights and multiple stakeholders to
> We see no issue with this if no one else has objections. We welcome other
> on the matter.
> (ii) use of metadata fields in media containers such as Ogg, AVI and
> This has pros and cons. It is possible to use the container to store hard
> metadata that will not change; but with more fluid information, a problem
> occurs. By changing the metadata in the file, the hash changes and -- if
> file was referenced by its hash, as with many peer2peer network -- the
> no longer be found.
> Some asked about a common way of creating unique identifiers (e.g. Gavin,
> Exequo). In our view the unique id should be a URL that is redirecting or
> displaying information about the video. If there is a need for further
> specification, something like "domain.com/2006-11-13/VideoOfTheDay" could
> The standard could suggest this, and could suggest placing it in the media
> container metadata header. We seek other opinions on this.
> There are no further technical limitations, so agreeing on a common
> mostly a question of picking up a schema.
> Relatedly, the question was raised whether the standard is going to be
> compatible with the MPEG-7 Metadata standard. The answer is no -- but it
> easier to translate to any format if we have a common way of describing
> 2. USE CASES
> Two correspondents (Andy, Dongwon) wanted to see use-cases that would
> potential and likely uses of the proposed video metadata standard.
> There are many uses cases. In general, however, we think this comes down
> important change in media which we are quite sure people here understand
> well. Put simply, providing good, standardised metadata will allow people
> find content; not doing it costs visibility, revenue and valuable feedback
> a critical audience.
> As for marking up data according to individual imperatives, the advantages
> agreeing a standard together rather than acting alone are clear. Working
> together to agree a standard should mean we make less mistakes. Having a
> standard we can adhere to -- or at least differ from consciously -- can't
> And if we do decide to follow it as individual information producers, we
> expect to enjoy nice effects like clean display in Democracy Player,
> CMSes and so on.
> 3. RELATIONSHIP TO EXISTING STANDARDS
> Some questions were asked in this area. Our starting point for this
> was, of course, to review past and ongoing attempts to create video
> standards. We did not however provide what would amount to a 'review' of
> given our mandate was not a research document but rather a working 'rough
> dirty' recommendation.
> It seems to us that a proper, thoroughgoing review would take between 5
> days to complete. We thus cannot complete this work within the budget
> here. If further funds become available, and there is will to go forward
> review as a necessary part of the documentation for this standard, we do
> not see any issue with undertaking this.
> We were grateful for the comments from Bill Best of the Community Media
> Association who participated in SOMA. While we do not suggest SOMA
> other projects in the area, we do think there are valuable lessons learned
> In summary, Bill said:
> - SOMA was based on Dublin Core and EBU Tech3293. - There has been no
> funding available to take it forward. - SOMA would be much improved by
> converting to strict RDF. - The benefits of bottom-up 'tagging' of content
> rather than imposed taxonomies are increasingly understood. 'Any
> metadata standard must be able to accommodate this.' - Bill 'came to the
> realisation that a metadata standard is only a useful tool, a means to an
> and that one should not get hamstrung by an unwieldy metadata framework if
> doesn't work.' - e considers this a 'weakness of the SOMA framework which
> our first foray into this arena.'
> Bill offers to post details of the SOVA (Shared Online Video Archive)
> schema which was a refinement of SOMA 1.0. We would be keen to see this as
> is rather good.
> 4. COMPATIBILITY AND INTEROPERABILITY
> First some clarification. The standard we proposed is indeed expressed in
> recommendation in: Atom, with elements of Yahoo's MediaRSS (which we use
> keywords, thumbnails and credits.) The mediaRSS namespace is used to
> things that are missing within the Atom namespace, and we are quite happy
> propose extensions to the Atom namespace if there is a will to do so.
> Definitions we might want are:
> * Hashes
> * Thumbnails
> * Credits
> We hope this addresses And's question and as to the interoperation of the
> standards: we really selected this option because it seemed likely to work
> most circumstances and do everything we wanted.
> But as to other important questions that came up in the feedback period:
> readers would be compatible currently with this standard? 'Are there any
> projects that already fit the bill [presumably, of producing feeds with
> agreed information?] Emerge Media platform? Broadcast Machine?' (Saul)
> While we know there are no markup agents that can produce metadata
> the standard here (though as Zoe and Szczym show, they can be modified to
> it!) we didn't conduct extensive investigations into which popular
> services/clients supported the standard.
> We have now conducted an initial review and found that, speaking
> feed readers have support for Atom 1.0. (Perhaps And can tell us more
> * Democracy Player did not support Atom, but this was a bug, and we
> fixed it. The
> next version of Democracy player will therefore 'just work' with Atom
> hence with the standard we proposed here, which is Atom with a bit of
> (See <https://develop.participatoryculture.org/democracy/ticket/4858>)
> Other important examples:
> * Drupal Aggregator 4.7 'just works' with Atom.
> * Google is one of the initiators and supporters of Atom 1.0 and it
> supports Atom very nicely.
> * iTunes supports Atom too, at least in the latest version we have here.
> * Microsoft Internet Explorer 7, quite suprisingly, though it looks
> supports Atom 1.0.
> However, seeing that some services / softwares probably don't accept Atom,
> aren't so easily fixable, we note that
> <http://blogs.feedburner.com/feedburner/archives/001340.html> Feedburner
> Quote from FeedBurner on this service:
> 'Publishers that use FeedBurner's free SmartFeed service can side-step all
> these format concerns. Here's how it works: if you have an Atom 1.0 feed
> burn it with the SmartFeed service, then when your feed is requested,
> a look at the client that's requesting your feed and do one of following:
> * Leave it as is (if the reader supports Atom 1.0)
> * Convert it on-the-fly to an
> Atom 0.3 feed (if the reader doesn't support Atom 1.0, but does support
> * Convert it on-the-fly to an RSS 2.0 feed (if the reader doesn't support
> Atom variant)
> The upshot is that publishers can just concentrate on publishing.
> will use its database of hundreds of readers, aggregators, and bots to
> that the feed is universally readable.'
> We think this answers sufficiently the concern that producers should know
> information they need to 'not only create an Atom feed as outlined in the
> but also to create an RSS 2.0 feed that is compatible with democracy
player as a
> short term solution'. (We already fixed that but we take the point :-)) We
> continue to recommend Atom with minimal MediaRSS extensions for the sake
> simplicity and 'just-works'-ness, but there is no reason that the standard
> not be expressed in RSS 2.0 and for now, FeedBurner can be used to do
> sure doesn't look as if that service would disappear overnight but rather
> be bought by Google for $20m or so.)
> Anna asked 'Should we firstly come up with our list of fields then
> producing our data model in [a variety of different formats/].' Saul
> the question of 'translating or 'smushing' between different existing
> standards.' Boris at Global Voices suggested not bothering to 'choose
> formats' -- 'Define namespaces for all of 'em.'
> Our point is that we don't really need to. We suspect that our Atom feed
> accepted by most, if not all of the services we want to interoperate with,
> of course by each others' since we will likely agree to implement it. But
> doesn't stop anyone from doing this if they want to.
> 5. EXTENSIBILITY
> 'How extensible will the standard be? What will be the capacity for
> to add their own custom fields, with what kind of limitations (if any)?'
> With Atom, it's possible to add more elements to the feed by extending it
> existing or new namespaces. The standard is just a basic common set of
> that should be understood by many clients; elements not in the standard
> not likely to be understood by existing software 'out of the box'. If more
> common optional fields are required or used often, those should be added,
> that everybody uses the same notation.
> One of the advantages of working together on a standard is that, if we
> namespace extensions, adding them to the standard has a normative power.
> Softwares that pay attention to the standard will then as a whole update
> accept the new namespace. Smaller individual providers haven't this
> 6. SUBTITLES
> 'It seems likely that video files will be distributed with several
> subtile files.' (Mick Fuzz)
> Though not explicitly mentioned in version 0.1 of the doc, it is
> possible to have more than one link, with the proper "hreflang" attribute
> indicating the language of the subtitle. This will be fixed in the new
> of the doc. (And in giving an example 2 different languages can be
> that producers know that this is an option.)
> 7. QUESTION OF OFFLINE CONTENT
> 'Should this metadata standard be used to refer to offline content too,
> DVDs in order for us to be able to share our databases of hard-copies or
> physical archives?'
> For us, the question of offline content is the most contentious raised
> took it as a starting point that we were referring to *online* video
> distribution with this standard. For us, those who have offline catalogues
> better spend their time digitising them, or putting them online, than mark
> up with metadata. We think in terms of discovering offline material, that
> are traditional cataloguing systems that could work better. Something like
> In short, we do not support a namespace for description of offline media,
> are curious how others feel about this.
> 8. NOTES AND CLARIFICATIONS ON SUGGESTED FIELDS
> Attached are some notes on the suggested fields in the draft. Again we
> tried to respond to all the suggestions and questions. This might be a bit
> scruffy, but we are conscious that our response has taken some time, and
> would like to move on ASAP to updating the actual recommendations.
> "mentioned in the example feed and in the ATOM / RSS 2.0 comparison,
> but not in the fields list in the draft." Right, this was a mistake in the
> original doc. Publisher and author are different, and we may need both
> in Atom. For example content may be added by a Publisher/Contributor but
> main Author credit may be somebody else.)
> Video link
> "should be able to list multiple streams / encodes Video format".
> This is possible: one can have more than one enclosure link in Atom feeds.
> currently is no common definition of quality (e.g., Low, High, HD), which
> be something to define and implement in clients like Democracy Player/
> Referrring to country in which the film was produced. Information
> what/where the video is about should go in the descriptive field/s. I.e.,
> description and possibly keywords should point to Tuvalu. However, there
> element for country in either Atom or MediaRSS so we might need to put one
> some namespace.
> We would encourage projects to output both their user-generated tags
> and their project-defined topics/categories list here.
> Short Description / Long Description
> In our experience it is more important that the amount of required
> rather limited but used by many people and that more comprehensive
> stays optional. With Atom one can have summary and content as two forms of
> and long description.
> We suggest not going with a hard list, but keeping it open while referring
> list of recommended or widely-used fields.
> We do not mention it in the standard but "hreflang" can be used to
> describe the language of linked elements like video or subtitle files. Any
> element, including but not limited to feed, entry, content, title, summary
> have an xml:lang attribute to describe its language.
> Within feed metadata, the publisher could be user name of whoever
> in the CMS (i.e., the author of the posting). Within video metadata,
> publisher indicates whoever published the video itself. This might require
> further discussion though?
> Szczym and Zoe: "How do we encode license information?" We have to
> have clear way
> to pass license information across websites. Based on the Atom License
> http://ietfreport.isoc.org/idref/draft-snell-atompub-feed-license/; we
> the standard to be more clear on this point.
> "Format" (a new suggestion)
> Gavin wrote about the separation of record and file metadata.
> Files are seen as attachments or enclosures possibly instances of the
> an Atom feed, an entry describes such a film, with one or more files
> Questions were asked about metadata relating to the physical/technical
> of files. In addition to the existing information length, mime-type, we
> with the following fields that might be useful if we are going to be
> about this:
> Runtime (# of frames) e.g., 01:38:11 (141240 frames)
> Video Codec e.g., XviD
> Frame Size e.g., 640x480 (4:3) [1=1] [1=1.337] w x h
> (aspect ratio) pixel aspect / display aspect
> FPS e.g., 23.976
> Video Bitrate e.g., 955 kb/s Bits per
> Pixel e.g., 0.229 bpp
> Audio Codec e.g., MPEG-1 Layer 3
> Sample Rate e.g., 48000
> Hz Audio bitrate e.g., 32 kb/s [1 channel(s)] CBR audio
> No. of audio streams e.g., 1
> Sha1 hash e.g., f1da229780e39ff6511c0fc227744b2817d122f4
> We need to decide which of these to include, and then decide how to
> them in the standard. There is currently no namespace available that we
> that could serve as a readymade, since the information is related to the
> referenced by an enclosure link, the information should be inside of the
> assuming we define a new namespace "format" it could loook like this:
> <link rel="enclosure" type="application/ogg" length="1337"
> <format:samplerate>48000</format:samplerate> ... </link>
> am i not answering your emails? you may find it easier to contact me
> in one of these ways:
> *TEXT CHAT*
> MSN Messenger: jjr_king
> ICQ: 335452203
> YAHOO Messenger: jamie_j_king
> AOL Messenger: iamth30th3r
> IRC: jamie_jk, server IRC.FREENODE.NET, channel #shivers
> SILC: jamie_jk, SILC.KEIN.ORG, channel #bunker
> Skype: jamie_jk
> Mobile / SMS: 00 44 (0) 7931 537717
> Land: 00 44 (0) 20 7254 6435
> Message: 3
> Date: Thu, 16 Nov 2006 15:18:19 +0100
> From: Zaczek <zaczek at gmail.com>
> Subject: Re: [Metadata] towards tx metadata 0.2 -- responses and
> To: metadata at transmission.cc
> <8cc0b3f50611160618vdda017et3f2b7e4ee989974 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> Hi Jamie and transmitters,
> > Questions were asked about metadata relating to the physical/technical
> > of files. In addition to the existing information length, mime-type, we
> > with the following fields that might be useful if we are going to be
> > about this:
> > Runtime (# of frames) e.g., 01:38:11 (141240 frames)
> > Video Codec e.g., XviD
> > Frame Size e.g., 640x480 (4:3) [1=1] [1=1.337] w x h
> > (aspect ratio) pixel aspect / display aspect
> > FPS e.g., 23.976
> > Video Bitrate e.g., 955 kb/s Bits per
> > Pixel e.g., 0.229 bpp
> > Audio Codec e.g., MPEG-1 Layer 3
> > Sample Rate e.g., 48000
> > Hz Audio bitrate e.g., 32 kb/s [1 channel(s)] CBR audio
> > No. of audio streams e.g., 1
> > Sha1 hash e.g., f1da229780e39ff6511c0fc227744b2817d122f4
> > We need to decide which of these to include, and then decide how to
> > them in the standard. There is currently no namespace available that we
> > that could serve as a readymade,
> I disagree: MediaRSS <http://search.yahoo.com/mrss> has at least these:
> lang="en" />
> OK, no codec info, but that's a good start. Maybe "type" can carry the
> codec as well as the container? Or just another attribute named
> "codec" in the same tag? This added attribute won't break existing
> parsers, as it will just be ignored if it is not known by the consumer
> application (hopefully, anyway!)
> since the information is related to the file
> > referenced by an enclosure link, the information should be inside of the
> > assuming we define a new namespace "format" it could loook like this:
> > <link rel="enclosure" type="application/ogg" length="1337"
> > href="http://example.org/video/ph43r_my_podcast.ogg">
> > <format:video_codec>Theora</format:video_codec>
> > <format:audio_codec>Vorbis</format:audio_codec>
> > <format:framerate>25</format:framerate>
> > <format:samplerate>48000</format:samplerate> ... </link>
> This seems a bit artificial to me.
> The enclosure element doesn't fit with the <media:content> markup. But
> the mediaRSS has it's own mechanism for pointing to the file:
> <media:content url="http://www.foo.com/movie.mov" >
> These seems to overlap with <enclosure
> length="12216320" type="audio/mpeg" /> in RSS 2.0
> and with:
> <link rel="enclosure" type="audio/mpeg" length="1337"
> in ATOM.
> Why not make a standard list of attribute names and use them for RSS
> 2.0 enclosures, ATOM enclosures and mediaRSS metadata?
> Our aggregators can then produce any of those based on user-selected
> I also thought of this diagram to illustrate the mechanism for an
> alternative feedburner+gspot subsystem:
> More explanation later if it's needed.
> Metadata mailing list
> Metadata at transmission.cc
> End of Metadata Digest, Vol 4, Issue 11
More information about the alt-media-res