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

Sun Sep 9 17:22:09 PDT 2007

On Monday 10. September 2007 01:10:44 Silvia Pfeiffer wrote:
> 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.

I doubt I will ever make anyone other than this open source format ever 
adopt my ideas. Though MP3s can be places inside an Ogg container? There 
you go! Problem solved. (Ha-ha.)

Since the URI attribute can describe locations (URLs), the format could work 
as a RDF document; being an external resource describing external content. 
But of course the metadata would be in the Ogg stream-container-thingy 
(...somehow. help. input?) in the case of the Ogg format.

> > > 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.

Yeah, I tried that. I must admit I was much smarter before killing all those 
brain cells trying to understand CMML. But I got a potted version from 
someone one the email list earlier! Think I get the basics from Wikipedia's 
article too.

And responding to all your arguments on CMML: It simply is not good enough.
* There is no way to extend it. (That would have required a version number 
and name space. According to everything I know about any XML based format.)
* The current version is hard to change. (Again because there is no version 
number and name space. Changing the format would break all earlier adoption 
because they could not tell the new and old versions appear.)
* Format intended for movies. (At least I have not seen it be very friendly 
towards audio recordings yet)
* Format fails to provide methods for describing resources in any great 
extent. Suffers from same limits/boundaries as Vorbis comment. Though it is 
much better than Vorbis comment, it is not ‘thinking big enough’.

> > > > 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.

These parent elements (audio, video, text, image, ...) are intended to say 
what kind of media the resource being described is. Another thing of 
creating separate elements for various media types where that it would be 
much easier to create media type specific elements. I just thought of 
images as media resources.I did not know images could not be store in Oggs.

> 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:
> <!-- Creative Commons License -->
> <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>.
> <!-- /Creative Commons License -->
>
> <!--
>
> <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?

Simple:

<rights date="2009-04" uri="http://creativecommons.org/licenses/by/4.0/">℗ 
2009 Rights holder. Some Rights reserved.</rights>

Of course the data could be represented as child elements of the parent 
rights element. The idea I had was to make it quite simple. I personally 
believe a much simplified version of the RDF method could prove useful. 
(Please keep in mind that sample description I sent using many different 
name spaces and how cluttered it was.)
<entities>
        <organisation role="rightsholder" uri="http://somecompany.com/" 
id="somecompany">Some Company</organisation></entities>
<rights>
        <date>2019-05-03</date>
        <human-readable>℗ 2019 Some Company. Some Rights 
reserved.</human-readable>
        <license uri="http://flf.org/licenses/whiteHouseLawn" /></rights>

> > > > > 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.

I did not think it would be necessary, but sure. Here is what you get with 
Vorbis comments:
Artist=Person Peopleson

> > 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!

See above reply

> > 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 :)

(REALLY good point.) ^^

> 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.

Well, CMML would be the subtitle. M3F would be the format describing the 
subtitle and the video it is shown below.

> 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.

Most replies in this emailing list have not been constructive. I 
think ‘destructive’ would be a better word for it. But I see your point as 
I hope you see mine.

The right person would be able to read RFCs and understand their gibberish, 
lawyer-like language. (What ever happen to plain English, people?) I am 
talking from experience with the XMPP and various URI RFCs. But I am doing 
the best I can.

I got to remember to thank the people at irc://irc.freenode.net/#annodex. 
Their advise on how to get responses from email lists really paid off. ;-)
-- 
Daniel Aleksandersen