[ogg-dev] The use for an XML based metadata format

Sun Sep 9 16:10:44 PDT 2007

Hi Daniel,

On 9/10/07, Daniel Aleksandersen <aleksandersen at runbox.com> wrote:
> It is indeed necessary. I hope this format will be a huge leap in metadata
> descriptions for media content. Not only for music, but any media found in
> Oggs.

You are thinking too small. Such standards should not be made to just
work with Ogg, but rather possible to work with any media format out
there. If it doesn't, we'll get a clash in future with some other
format that does and we won't get real standardisation. Don't get
daunted by the task though. Just focus on Ogg and keep in the back of
your mind not to do anything that would inhibit it from being used by
other formats.

> > All I did was propose a process that can lead to an integration into
> > Ogg. Replacing vorbiscomment is one big request that requires a lot of
> > software to change. So, you will need a lot of support from the
> > community to go down that path. Only if everybody agrees that this is
> > necessary will it happen. So, pushing you to the edge and forcing you
> > to defend why is a constructive way for the community to learn. Don't
> > give up. :-)
>
> I just though you were practising the Jante Law (look it up in Wikipedia).
> Sorry. ^^

That was your interpretation. When in fact: I was only trying to help.
And from reading your reply, I can assume with 99% certainty that you
have not read up on CMML
(http://www.annodex.net/TR/draft-pfeiffer-cmml-03.html). Go read up on
it and come back and we can have a better discussion.

> > > The rights element was taken directly from the Atom 1.0 specification,
> > > but with an added 'date' attribute to make this stand data stand out
> > > from the text.
> >
> > Good. So the rights element is in pretty good shape. Now we need to
> > figure out what the atomic element of attribution of the rights
> > element should be and then put it in the right location. In today's
> > age of mash-ups, should there be a rights element on a file section
> > basis? Or just on a per-track basis? Atom does it only on a per-file
> > basis IIRC.
>
> As I have intended it, the rights element would appear on audio, video,
> text, image elements. Though there is no limit to how many audio elements
> you have and how many rights children those elements have. So I guess this
> example would explain everyting better:
>
> <?xml ...><metadata ...>
> <audio type="audio/flac+lossless" oggserial="somethingsomething">
>         <rights date="2019">℗ 2019 Harvey the Wonder Hamster</rights></audio>
> <audio type="audio/flac+lossless" oggserial="somethingelse">
>         <rights date="2020">℗ 2020 Your Mother</rights></audio></metadata>

First of all: there are no "image elements" in Ogg. There is a draft
specification of how to create a logical bitstream with MNG and one
with images - but none of these are currently adopted.

Then: IIUC you are suggesting to attach rights to logical bitstreams.
(BTW: I'd also suggest reading the Ogg RFC so you understand the Ogg
format better http://www.ietf.org/rfc/rfc3533.txt). That could make
sense - in particular if we assume that in a mash-up the different
pieces that get mashed together stay in separate logical bistreams -
they just start at different time offsets into the file. In this way
we can attach rights to sections in the file.

Now, more concretely: I don't think this "rights" tag is sufficient -
even though it is taken out of Atom. There are others which are more
complete - e.g. Dublin Core does rights like this:
<dc:rights>
  <Agent rdf:about="http://me.yoyo.dyne.name/">
    <dc:title>Yo-Yo Dyne</dc:title>
    <dc:date>1001-10-01</dc:date>
  </Agent>
</dc:rights>
 <cc:license rdf:resource="http://flf.org/licenses/whiteHouseLawn" />

And creative commons recommends a specification like this:

<a href="http://creativecommons.org/licenses/by-sa/1.0/">
<img alt="Creative Commons License" border="0"
src="http://creativecommons.org/images/public/somerights.gif" /></a><br />
This work is licensed under a
<a href="http://creativecommons.org/licenses/by-sa/1.0/">Creative
Commons License</a>.

<!--

<rdf:RDF xmlns="http://web.resource.org/cc/"
    xmlns:dc="http://purl.org/dc/elements/1.1/"
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<Work rdf:about="">
<license rdf:resource="http://creativecommons.org/licenses/by-sa/1.0/" />
</Work>

<License rdf:about="http://creativecommons.org/licenses/by-sa/1.0/">
   <requires rdf:resource="http://web.resource.org/cc/Attribution" />
   <requires rdf:resource="http://web.resource.org/cc/ShareAlike" />
   <permits rdf:resource="http://web.resource.org/cc/Reproduction" />
   <permits rdf:resource="http://web.resource.org/cc/Distribution" />
   <permits rdf:resource="http://web.resource.org/cc/DerivativeWorks" />
   <requires rdf:resource="http://web.resource.org/cc/Notice" />
</License>

</rdf:RDF>

-->

We will need to make it possible to cover at minimum creative commons.
How would you suggest doing so?

> > > > In contrast, the improved description of the content as in: artist,
> > > > band name, title, organisation involved, and people involved are
> > > > things that improve upon vorbiscomment and should probably be
> > > > included there directly.
> > >
> > > No. I have though *a lot* about this. You can improve Vorbis comment to
> > > some extent. But it is way to limited. Try describing this with Voribs
> > > comments and you will see my point:
> > > <person role="vocal instrument" uri="http://person.no/"
> > > xml:lang="nb-NO">Person Peopleson</person>

BTW: have you tried it yourself? If yes, and you have come up with a
very terrible way of doing so, pasting it here for reference and as a
good argument against using vorbiscomment for what you're after is a
good thing. It supports your argument. Otherwise you are just waving
your hands in the air saying everything that exists is bad and needs
to be replace, but not explaining why it is bad.

> To me, Vorbis comments are insufficient. Ask anyone playing in an ensamble
> if they would like recognition. Ask the record label holding the rights to
> a song. Ask the music geek that wants his music collection sorted by
> something other than artist, album, or release year.

Agreed.

> They would all prefer this to Vorbis comments.

Not agreed - "this" has to be defined sensibly first and be
implemented and taken up. Then I am prepared to agree to this
statement. :) And I am also prepared to help you get there.

> > How  intensively have you looked at improving/extending CMML? Subtitles
> > for one would definitely be better off being added to CMML than any other
> > place.
>
> The idea is to describe the content in a way useful to software like media
> management suites (iTunes, iPhoto, Amarok, Banshee, ...) and players (VLC,
> KMPLayer, QuickTime, ...), to search engines (any kind of desktop search,
> Google, on the Gnutella network, ...), and so on. Basically: Pure metadata.

That's a good aim - and also part of the aim of CMML, so checking out
CMML would be really helpful!

> For subtiles, the goal would be to describe that the text with
> oggserial/oggid this and that is a subtitle; and describe who made it, what
> language it is written in, if it's friendly to death people, and so on.

(deaf ppl :)
Yes, these are all good goals. Subtitles are time-continuous textual
annotations towards a piece of video/audio, so they should be
encapsulated in a time-continuous text codec, which is what CMML is.
Thus the suggestion to include this data with CMML - create a new
"subtitle" tag.

In contrast, author, artist and rights information is per content
piece only, so they are more "header"-style, more vorbiscomments
style. This is the differentiation in type that I am talking about and
where we need to make sure the metadata that you create gets added in
the right places.

> I am probably not the right person to lead this. But I am apparently the
> only one motivated enough to do it. So if anyone else is unemployed at the
> time...do help. Anyone else are free to contribute as well! ;-)

There is no such thing as the "right" person. The person who does it
and drives it is the "right" person. This is how open source and open
communities work. So, you are the right person. :-) Go lead it and
help will be given. Just be open to criticism - it's not always
negative, but often constructive. You just need to keep an open mind.

Regards,
Silvia.