[alt-media-res] Fw: Metadata Digest, Vol 4, Issue 11
zoe
zoe at esemplastic.net
Thu Nov 16 17:17:53 GMT 2006
yeeehaw!
something worked...
ta
x
>
> 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
> Message-ID:
> <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
the
> comments and tried to arrange them for the sake of accessibility. Your
issues
> should be addressed, if they're not, sorry! We can add them in the next
round.
>
> We have also spent some time looking at different clients out there and
even
> hacked some changes to a couple of them (e.g. Democracy Player). More in
the
> body of the responses.
>
> We updated the Recommendations file somewhat to reflect the discussion so
far.
> 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
document, i.e.
> that rights issues are best decided at the point of markup by the
individual or
> 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
normative or
> 'merely technical' :)). While for example our own V2V.cc has taken a clear
view
> on such issues, we think that a metadata schema allowing *choice* at the
point
> of markup is the best way forward.
>
> This does not in any way prevent CMS and service designers writing
defaults into
> their systems according to their proclivities and/or those of their
communities.
> The schema is agnostic and broad-church precisely so that
_implementations_ of
> it can be partisan and specific.
>
> While our position hasn't changed with regards to licensing, we would like
to
> make clear that we personally very much support licenses and or statements
that
> encourage sharing, re-use and so forth. Our personal practices in this
direction
> are probably well known by now!
>
> b. actual implementations of metadata
>
> (i) should we allow multiple types of rights and multiple stakeholders to
be
> represented?
>
> We see no issue with this if no one else has objections. We welcome other
input
> on the matter.
>
> (ii) use of metadata fields in media containers such as Ogg, AVI and
Quicktime.
>
> 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
the
> file was referenced by its hash, as with many peer2peer network -- the
file may
> 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
be
> used,
>
> 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
notation is
> 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
will be
> easier to translate to any format if we have a common way of describing
our data
> today.
>
> 2. USE CASES
>
> Two correspondents (Andy, Dongwon) wanted to see use-cases that would
exemplify
> potential and likely uses of the proposed video metadata standard.
>
> There are many uses cases. In general, however, we think this comes down
to an
> important change in media which we are quite sure people here understand
very
> well. Put simply, providing good, standardised metadata will allow people
to
> find content; not doing it costs visibility, revenue and valuable feedback
from
> a critical audience.
>
> As for marking up data according to individual imperatives, the advantages
of
> 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
hurt.
> And if we do decide to follow it as individual information producers, we
can
> expect to enjoy nice effects like clean display in Democracy Player,
others'
> CMSes and so on.
>
> 3. RELATIONSHIP TO EXISTING STANDARDS
>
> Some questions were asked in this area. Our starting point for this
document
> was, of course, to review past and ongoing attempts to create video
metadata
> standards. We did not however provide what would amount to a 'review' of
these,
> given our mandate was not a research document but rather a working 'rough
and
> dirty' recommendation.
>
> It seems to us that a proper, thoroughgoing review would take between 5
and 7
> days to complete. We thus cannot complete this work within the budget
given
> here. If further funds become available, and there is will to go forward
with a
> review as a necessary part of the documentation for this standard, we do
however
> 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
typifies
> other projects in the area, we do think there are valuable lessons learned
here.
>
> In summary, Bill said:
>
> - SOMA was based on Dublin Core and EBU Tech3293. - There has been no
further
> 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
contemporary
> 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
end
> and that one should not get hamstrung by an unwieldy metadata framework if
it
> doesn't work.' - e considers this a 'weakness of the SOMA framework which
was
> our first foray into this arena.'
>
> Bill offers to post details of the SOVA (Shared Online Video Archive)
metadata
> schema which was a refinement of SOMA 1.0. We would be keen to see this as
SOMA
> is rather good.
>
> 4. COMPATIBILITY AND INTEROPERABILITY
>
> First some clarification. The standard we proposed is indeed expressed in
our
> recommendation in: Atom, with elements of Yahoo's MediaRSS (which we use
for
> keywords, thumbnails and credits.) The mediaRSS namespace is used to
describe
> things that are missing within the Atom namespace, and we are quite happy
to
> 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
two
> standards: we really selected this option because it seemed likely to work
in
> most circumstances and do everything we wanted.
>
> But as to other important questions that came up in the feedback period:
what
> readers would be compatible currently with this standard? 'Are there any
> projects that already fit the bill [presumably, of producing feeds with
the
> agreed information?] Emerge Media platform? Broadcast Machine?' (Saul)
>
> While we know there are no markup agents that can produce metadata
according to
> the standard here (though as Zoe and Szczym show, they can be modified to
do
> 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
generally, many
> feed readers have support for Atom 1.0. (Perhaps And can tell us more
about
> Plone?)
>
> * 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
feeds, and
> hence with the standard we proposed here, which is Atom with a bit of
MediaRSS.
> (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.
(OS X).
>
> * Microsoft Internet Explorer 7, quite suprisingly, though it looks
horrible,
> supports Atom 1.0.
>
> However, seeing that some services / softwares probably don't accept Atom,
and
> aren't so easily fixable, we note that
> <http://blogs.feedburner.com/feedburner/archives/001340.html> Feedburner
offers
> 'SmartFeed'.
>
> Quote from FeedBurner on this service:
>
> 'Publishers that use FeedBurner's free SmartFeed service can side-step all
of
> these format concerns. Here's how it works: if you have an Atom 1.0 feed
and
> burn it with the SmartFeed service, then when your feed is requested,
we'll take
> 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
Atom
> 0.3)
> * Convert it on-the-fly to an RSS 2.0 feed (if the reader doesn't support
any
> Atom variant)
>
> The upshot is that publishers can just concentrate on publishing.
FeedBurner
> will use its database of hundreds of readers, aggregators, and bots to
ensure
> that the feed is universally readable.'
>
> We think this answers sufficiently the concern that producers should know
the
> information they need to 'not only create an Atom feed as outlined in the
report
> 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
of
> simplicity and 'just-works'-ness, but there is no reason that the standard
could
> not be expressed in RSS 2.0 and for now, FeedBurner can be used to do
this. (It
> sure doesn't look as if that service would disappear overnight but rather
will
> be bought by Google for $20m or so.)
>
> Anna asked 'Should we firstly come up with our list of fields then
consider
> producing our data model in [a variety of different formats/].' Saul
brought up
> the question of 'translating or 'smushing' between different existing
> standards.' Boris at Global Voices suggested not bothering to 'choose
between
> formats' -- 'Define namespaces for all of 'em.'
>
> Our point is that we don't really need to. We suspect that our Atom feed
will be
> accepted by most, if not all of the services we want to interoperate with,
and
> of course by each others' since we will likely agree to implement it. But
that
> 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
projects
> 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
with
> existing or new namespaces. The standard is just a basic common set of
elements
> that should be understood by many clients; elements not in the standard
are just
> 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,
so
> that everybody uses the same notation.
>
> One of the advantages of working together on a standard is that, if we
decide on
> namespace extensions, adding them to the standard has a normative power.
> Softwares that pay attention to the standard will then as a whole update
to
> accept the new namespace. Smaller individual providers haven't this
normative
> power.
>
> 6. SUBTITLES
>
> 'It seems likely that video files will be distributed with several
different
> 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
version
> of the doc. (And in giving an example 2 different languages can be
included, so
> 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,
such as
> 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
here. We
> took it as a starting point that we were referring to *online* video
> distribution with this standard. For us, those who have offline catalogues
would
> better spend their time digitising them, or putting them online, than mark
them
> up with metadata. We think in terms of discovering offline material, that
there
> are traditional cataloguing systems that could work better. Something like
> CiviCRM?
>
> In short, we do not support a namespace for description of offline media,
but we
> 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
have
> 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
now we
> would like to move on ASAP to updating the actual recommendations.
>
>
> Author
>
> "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
(this is
> in Atom. For example content may be added by a Publisher/Contributor but
the
> 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.
There
> currently is no common definition of quality (e.g., Low, High, HD), which
might
> be something to define and implement in clients like Democracy Player/
websites
> etc.
>
> Country
>
> Referrring to country in which the film was produced. Information
concerning
> 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
is no
> element for country in either Atom or MediaRSS so we might need to put one
in
> some namespace.
>
> Keywords
>
> 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
metadata is
> rather limited but used by many people and that more comprehensive
information
> stays optional. With Atom one can have summary and content as two forms of
short
> and long description.
>
> Genre
>
> We suggest not going with a hard list, but keeping it open while referring
to a
> list of recommended or widely-used fields.
<http://imdb.com/Sections/Genres/>
>
> Language
>
> 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
can
> have an xml:lang attribute to describe its language.
>
> Publisher
>
> Within feed metadata, the publisher could be user name of whoever
publishes it
> 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?
>
> License
>
> 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
Extension
> http://ietfreport.isoc.org/idref/draft-snell-atompub-feed-license/; we
updated
> 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
film. In
> an Atom feed, an entry describes such a film, with one or more files
attached.
>
> Questions were asked about metadata relating to the physical/technical
qualities
> of files. In addition to the existing information length, mime-type, we
came up
> with the following fields that might be useful if we are going to be
completist
> 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
implement
> them in the standard. There is currently no namespace available that we
know of
> that could serve as a readymade, since the information is related to the
file
> referenced by an enclosure link, the information should be inside of the
link,
> 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>
>
> --
> ______________________________________________________________________
>
> 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
>
> *VOICE*
>
> 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
> additions
> To: metadata at transmission.cc
> Message-ID:
> <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
qualities
> > of files. In addition to the existing information length, mime-type, we
came up
> > with the following fields that might be useful if we are going to be
completist
> > 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
implement
> > them in the standard. There is currently no namespace available that we
know of
> > that could serve as a readymade,
>
> I disagree: MediaRSS <http://search.yahoo.com/mrss> has at least these:
>
> <media:content
> url="http://www.foo.com/movie.mov"
> fileSize="12216320"
> type="video/quicktime"
> medium="video"
> isDefault="true"
> expression="full"
> bitrate="128"
> framerate="25"
> samplingrate="44.1"
> channels="2"
> duration="185"
> height="200"
> width="300"
> 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
link,
> > 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
> url="http://www.scripting.com/mp3s/weatherReportSuite.mp3"
> length="12216320" type="audio/mpeg" /> in RSS 2.0
>
> and with:
>
> <link rel="enclosure" type="audio/mpeg" length="1337"
> href="http://example.org/audio/ph34r_my_podcast.mp3"/>
> 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
options.
>
> I also thought of this diagram to illustrate the mechanism for an
> alternative feedburner+gspot subsystem:
> http://alteree.hardcore.lt/atom/rss_aggregator.gif
> More explanation later if it's needed.
>
> Cheers,
> Zaczek
>
>
> ------------------------------
>
> _______________________________________________
> Metadata mailing list
> Metadata at transmission.cc
> http://lists.transmission.cc/mailman/listinfo/metadata
>
>
> End of Metadata Digest, Vol 4, Issue 11
> ***************************************
More information about the alt-media-res
mailing list