ogg dev - Sep 2007 - The use for an XML based metadata format

Daniel,

these are all good ideas and worth progressing. However, it may be
better not to merge too many goals in one format (MPEG-7 did that and
ended up as a big mess). So, I suggest to start by structuring the
types of things you want - then finding out which parts belong where
into existing formats such as vorbis comment, Skeleton and CMML, and
only then start to develop a new format.

For example: the relationships between the logical bitstreams is a
very semantic description - it needs to be broad enough to enable
different types of applications to do different things with it. E.g. a
video editor will need to know that there are 3 audio channels in a
file and how they overlap each other and also the video channel, while
in contrast a speech recognizer might just want to be able to know
about the one audio channel in there that is speech and a music player
would be totally ignorant of the video channel. Just solving this
generically would be a big feat. It would possibly need to find a
place in skeleton.

A similar argument goes for the encoding quality description and digital 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.

All I ask for is *not* to reinvent the wheel when there are already
working, semi-complete metadata formats for Ogg that have been
carefully prepared to fit with the existing Ogg framework. It would be
a sheer nightmare to create another new one that does not fit with any
of the existing ones and is not supported by any media application.

OTOH, we could. undertake this cleaning exercise also at the end of
your process when you have all the fields together that you're after.
We would then sit down and discuss where they are best suitable, if
you prefer that. This should be made clear though.

Regards,
Silvia.


 than the artist and or organisation descriptions.



On 9/9/07, Daniel Aleksandersen <aleksandersen+xiphlists@runbox.com>
wrote:
> On 2007-09-09, Silvia wrote:
> > Daniel,
>
> Hi Silvia,
>
> I realise I should have started with this. I got a little carried on with
my
> ideas. Apparently I am no good when it comes to sharing an idea.
>
> Short answer: The format should describe media content and relation between
> them in an Ogg stream. Intended usage is media management and sorting
> trough search and media manager software.
>
> Long answer: See below.
>
> > before you step over everything that has been done before, we need to
> > determine what exactly is the use case for your new specification.
> >
> > What concerns metadata, we currently have:
> >
> > * vorbiscomment - this is a header at the beginning of a logical
> > bitstream which has metadata that refers to the complete file; there
> > is a specification, which has been public for a long time and is the
> > de-facto standard that is (or should be) used by all software (see
> > http://xiph.org/vorbis/doc/v-comment.html)
> >
> > * cmml - this is a logical bitstream for time-continuous textual
> > annotations (metadata) for ogg files (see
> > http://wiki.xiph.org/index.php/CMML)
> >
> > * skeleton - this is an extension to the ogg bitstream format, which
> > has all the encapsulation-specific low-level metadata (see
> > http://wiki.xiph.org/index.php/Ogg_Skeleton)
> >
> > All of these are supported by xiph and may need further
> > work/extensions or potentially a replacement if they are not fit to
> > provide what is required.
> >
> > Before throwing out more random specifications, could we please look
> > at what you are trying to achieve with the new format? Can you tell us
> > where the existing technologies are lacking?
>
> What I want is a format to give a detailed description of the content in an
> Ogg stream. The usage would be improved searchability on local machines
> (possibly even on the web and file sharing clients too) and sorting in
> media management software such as Apple iPhoto, Amarok, and WinAmp.
>
> Currently only Vorbis comment describe the content. What I aim to is to
> replace Vorbis comments. Vorbis comments are very limited to a few field
> names for describing content. There is only a poorly developed look-a-like
> standard for describing audio files; and all other media formats are left
> alone. End users may indeed slap on additional field names, but no media
> management software no search engine know to look for them.
>
> Another thing this format describes is relations between media in an Ogg
> stream. See the audio:collection:artwork element for instance. (Imagine an
> audio:lyrics element too.)
>
> This random specification was intended to start development for a real
> metadata/content description format. This XML based thing I have put
> together in a few hours might not be the best. But it does provide a better
> way to detail describe
>
>
> I have no doubt that others can do this better. But as no one seamed to be
> working on a description format; I took it upon myself to start working on
> *something*.
>
> Hope this clarifies things.
> --
> Daniel Aleksandersen
>

Hi Silvia,

I really have to ask you: Have you even tried to describe media using the 
excising solutions? I don't mean adding subtitles and editing stuff. I mean 
really say what a Ogg file contins. There is no working wheels for this. 
Vorbis comments--used in FLAC too--can describe content with a very limited 
field names (and badly enforced standards).

I said from the start that I have no idea of what I am doing. This was an 
initiative to make a broad metadata format for describing content. I have 
no doubts others can do it better. This was just a suggestion to make the 
actually developer types on this list think about how it could be done 
better.

More below.

On 2007-09-09, Silvia wrote:
> Daniel,
>
> these are all good ideas and worth progressing. However, it may be
> better not to merge too many goals in one format (MPEG-7 did that and
> ended up as a big mess). So, I suggest to start by structuring the
> types of things you want - then finding out which parts belong where
> into existing formats such as vorbis comment, Skeleton and CMML, and
> only then start to develop a new format.
>
> For example: the relationships between the logical bitstreams is a
> very semantic description - it needs to be broad enough to enable
> different types of applications to do different things with it. E.g. a
> video editor will need to know that there are 3 audio channels in a
> file and how they overlap each other and also the video channel, while
> in contrast a speech recognizer might just want to be able to know
> about the one audio channel in there that is speech and a music player
> would be totally ignorant of the video channel. Just solving this
> generically would be a big feat. It would possibly need to find a
> place in skeleton.
>
> A similar argument goes for the encoding quality description and digital
> rights.
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.
> 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>
> All I ask for is *not* to reinvent the wheel when there are already
> working, semi-complete metadata formats for Ogg that have been
> carefully prepared to fit with the existing Ogg framework. It would be
> a sheer nightmare to create another new one that does not fit with any
> of the existing ones and is not supported by any media application.
> 
> OTOH, we could. undertake this cleaning exercise also at the end of
> your process when you have all the fields together that you're after.
> We would then sit down and discuss where they are best suitable, if
> you prefer that. This should be made clear though.
I have just tried working on the audio (music, speeches, farting sounds, 
whatever, ...) part. Think about subtitles in the text element and such. 
The person who wrote the text could actually be attributed. Media manager 
softwares could search for movies by subtitle author, for instance.

I do apologise for my tone in this email. I think I got -a little- very 
upset by you not seeing how limited the existing solutions are.
> On 9/9/07, Daniel Aleksandersen <aleksandersen+xiphlists@runbox.com> 
wrote:
> > On 2007-09-09, Silvia wrote:
> > > Daniel,
> >
> > Hi Silvia,
> >
> > I realise I should have started with this. I got a little carried on
> > with my ideas. Apparently I am no good when it comes to sharing an
> > idea.
> >
> > Short answer: The format should describe media content and relation
> > between them in an Ogg stream. Intended usage is media management and
> > sorting trough search and media manager software.
> >
> > Long answer: See below.
> >
> > > before you step over everything that has been done before, we
need to
> > > determine what exactly is the use case for your new
specification.
> > >
> > > What concerns metadata, we currently have:
> > >
> > > * vorbiscomment - this is a header at the beginning of a logical
> > > bitstream which has metadata that refers to the complete file;
there
> > > is a specification, which has been public for a long time and is
the
> > > de-facto standard that is (or should be) used by all software
(see
> > > http://xiph.org/vorbis/doc/v-comment.html)
> > >
> > > * cmml - this is a logical bitstream for time-continuous textual
> > > annotations (metadata) for ogg files (see
> > > http://wiki.xiph.org/index.php/CMML)
> > >
> > > * skeleton - this is an extension to the ogg bitstream format,
which
> > > has all the encapsulation-specific low-level metadata (see
> > > http://wiki.xiph.org/index.php/Ogg_Skeleton)
> > >
> > > All of these are supported by xiph and may need further
> > > work/extensions or potentially a replacement if they are not fit
to
> > > provide what is required.
> > >
> > > Before throwing out more random specifications, could we please
look
> > > at what you are trying to achieve with the new format? Can you
tell
> > > us where the existing technologies are lacking?
> >
> > What I want is a format to give a detailed description of the content
> > in an Ogg stream. The usage would be improved searchability on local
> > machines (possibly even on the web and file sharing clients too) and
> > sorting in media management software such as Apple iPhoto, Amarok, and
> > WinAmp.
> >
> > Currently only Vorbis comment describe the content. What I aim to is
to
> > replace Vorbis comments. Vorbis comments are very limited to a few
> > field names for describing content. There is only a poorly developed
> > look-a-like standard for describing audio files; and all other media
> > formats are left alone. End users may indeed slap on additional field
> > names, but no media management software no search engine know to look
> > for them.
> >
> > Another thing this format describes is relations between media in an
> > Ogg stream. See the audio:collection:artwork element for instance.
> > (Imagine an audio:lyrics element too.)
> >
> > This random specification was intended to start development for a real
> > metadata/content description format. This XML based thing I have put
> > together in a few hours might not be the best. But it does provide a
> > better way to detail describe
> >
> >
> > I have no doubt that others can do this better. But as no one seamed
to
> > be working on a description format; I took it upon myself to start
> > working on *something*.
> >
> > Hope this clarifies things.
-- 
Daniel Aleksandersen

Hi  Daniel,,
> I really have to ask you: Have you even tried to describe media using the
> excising solutions? I don't mean adding subtitles and editing stuff. I
mean
> really say what a Ogg file contins. There is no working wheels for this.
> Vorbis comments--used in FLAC too--can describe content with a very limited
> field names (and badly enforced standards).
I have and I know they are. I am not saying your work is not needed. I
am just trying to be careful how to integrate it. Don't get  me wrong:
I like what you do and it is necessary!

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. :-)
> On 2007-09-09, Silvia wrote:
> > Daniel,
> >
> > these are all good ideas and worth progressing. However, it may be
> > better not to merge too many goals in one format (MPEG-7 did that and
> > ended up as a big mess). So, I suggest to start by structuring the
> > types of things you want - then finding out which parts belong where
> > into existing formats such as vorbis comment, Skeleton and CMML, and
> > only then start to develop a new format.
> >
> > For example: the relationships between the logical bitstreams is a
> > very semantic description - it needs to be broad enough to enable
> > different types of applications to do different things with it. E.g. a
> > video editor will need to know that there are 3 audio channels in a
> > file and how they overlap each other and also the video channel, while
> > in contrast a speech recognizer might just want to be able to know
> > about the one audio channel in there that is speech and a music player
> > would be totally ignorant of the video channel. Just solving this
> > generically would be a big feat. It would possibly need to find a
> > place in skeleton.
> >
> > A similar argument goes for the encoding quality description and
digital
> > rights.
>
> 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.

> > 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>
So we're looking at replacing vorbiscomment with a xml version? 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.

Regards,
Silvia.

Hi Daniel,


On 9/10/07, Daniel Aleksandersen <aleksandersen@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:
<!-- 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?

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

On Monday 10. September 2007 01:10:44 Silvia Pfeiffer
wrote:
> Hi Daniel,
>
> On 9/10/07, Daniel Aleksandersen <aleksandersen@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

On 09/09/2007, Silvia Pfeiffer <silviapfeiffer1@gmail.com>
wrote:
> Daniel,
>
> A similar argument goes for the encoding quality description and digital
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.
>
There are arguments against simply using vorbiscomment for this,
beyond simply the fact that the Vorbis spec says it should only be
used for short 'jotted on the CD' type notes.  First it is based on
value pairs, this makes it hard to describe relationships in detail;
you must either choose a field name that will not be widely
understood ('drummer', 'sound engineer', even 'composer'
won't
get you far) or use a funny way of refining it in the value (such
as artist=(composer) Beethoven), I think cast lists for films present
a similar problem.  There is consistency and indexability to be
addressed (Ludvig van Beethoven; Beethoven, Ludvig van;
Beethoven).  Finally complex relationships are even harder to
handle such as specifying a resource's relationship to the rest
of a collection.
> All I ask for is *not* to reinvent the wheel when there are already
> working, semi-complete metadata formats for Ogg that have been
> carefully prepared to fit with the existing Ogg framework. It would be
> a sheer nightmare to create another new one that does not fit with any
> of the existing ones and is not supported by any media application.
>
Yes, any attempt to add a metadata format should leverage
what exists already.  I see it like this: Skeleton describes the
technical aspects of the stream, CMML splits it into temporal
parts, but describing the contents is left to Vorbiscomments,
which were by design only sufficient for simple descriptions
(and are tied to a logical stream).  Looking back through
the list archives it was always intended there should be a
metadata format to go beyond what Vorbis comments
could do.

I suppose I should draw attention to some of the stuff I did
before I discovered I didn't have enough time to get some
kind of working application together:
<http://www.imalone.co.uk/omd_background/index.html>
<http://www.imalone.co.uk/omd_questions/index.htm>
<http://wiki.xiph.org/index.php/Metadata>
I got a bit sidetracked by the multiplexed streams
compatibility stuff at the time, that and trying to learn XPCOM
to produce a FF plugin (something which was going to take
far more time than I had).  A Rhythmbox plugin is probably the
easiest target, though something Windows based would get
a wider audience, Songbird might be good as it's built on
top of a platform which is designed to handle XML.

P.S. does anyone know what XMP actually does?  Whenever
I look at it all I can find are descriptions of how the embedding
is done.

-- 
imalone

What I've gotten out of this discussion so far:

1) we need to introduce a means in which to do captions; this could be
done through adding a "caption" element to CMML, or in another
time-continuous annotation format; so far I am not sure which would be
the better way

2) we need a XML annotation format for audio - in particular for music
- that is more structured than vorbiscomment (and this probably
applies to video, too)

3) we need a means to describe relationships between different logical
bitstreams; we had a discussion about this years ago, but never got to
a proper specification of this

4) we need a means to address logcial bitstreams by name; this should
be an ID attribute to be added to skeleton


These four things are all very different and separate things - number
2 may even need further structuring IMO. Yes, they interrelate and
there should be means to address one from the other. But IMO they all
need a different approach.

Silvia.

On 9/10/07, Ian Malone <ibmalone@gmail.com> wrote:
> On 09/09/2007, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote:
> > Daniel,
> >
>
> > A similar argument goes for the encoding quality description and
digital 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.
> >
>
> There are arguments against simply using vorbiscomment for this,
> beyond simply the fact that the Vorbis spec says it should only be
> used for short 'jotted on the CD' type notes.  First it is based on
> value pairs, this makes it hard to describe relationships in detail;
> you must either choose a field name that will not be widely
> understood ('drummer', 'sound engineer', even
'composer' won't
> get you far) or use a funny way of refining it in the value (such
> as artist=(composer) Beethoven), I think cast lists for films present
> a similar problem.  There is consistency and indexability to be
> addressed (Ludvig van Beethoven; Beethoven, Ludvig van;
> Beethoven).  Finally complex relationships are even harder to
> handle such as specifying a resource's relationship to the rest
> of a collection.
>
> > All I ask for is *not* to reinvent the wheel when there are already
> > working, semi-complete metadata formats for Ogg that have been
> > carefully prepared to fit with the existing Ogg framework. It would be
> > a sheer nightmare to create another new one that does not fit with any
> > of the existing ones and is not supported by any media application.
> >
>
> Yes, any attempt to add a metadata format should leverage
> what exists already.  I see it like this: Skeleton describes the
> technical aspects of the stream, CMML splits it into temporal
> parts, but describing the contents is left to Vorbiscomments,
> which were by design only sufficient for simple descriptions
> (and are tied to a logical stream).  Looking back through
> the list archives it was always intended there should be a
> metadata format to go beyond what Vorbis comments
> could do.
>
> I suppose I should draw attention to some of the stuff I did
> before I discovered I didn't have enough time to get some
> kind of working application together:
> <http://www.imalone.co.uk/omd_background/index.html>
> <http://www.imalone.co.uk/omd_questions/index.htm>
> <http://wiki.xiph.org/index.php/Metadata>
> I got a bit sidetracked by the multiplexed streams
> compatibility stuff at the time, that and trying to learn XPCOM
> to produce a FF plugin (something which was going to take
> far more time than I had).  A Rhythmbox plugin is probably the
> easiest target, though something Windows based would get
> a wider audience, Songbird might be good as it's built on
> top of a platform which is designed to handle XML.
>
> P.S. does anyone know what XMP actually does?  Whenever
> I look at it all I can find are descriptions of how the embedding
> is done.
>
> --
> imalone
> _______________________________________________
> ogg-dev mailing list
> ogg-dev@xiph.org
> http://lists.xiph.org/mailman/listinfo/ogg-dev
>

On Mon, Sep 10, 2007 at 01:19:05PM +0100, Ian Malone wrote:
> as artist=(composer) Beethoven), I think cast lists for films present
> a similar problem.  There is consistency and indexability to be
> addressed (Ludvig van Beethoven; Beethoven, Ludvig van;
> Beethoven).
ID3 has a concept of "sort" tags, which provide a string for sorting 
purposes which is different from the (presumedly full name) of the usal 
tag. TSOP="Beethoven", TCOM="Ludwig van Beethoven".

If you want something more precise, you have to link to unique 
identifiers for a particular artist, like a musicbrainz id. I
gather that's not what you're interested in here?
> Finally complex relationships are even harder to
> handle such as specifying a resource's relationship to the rest
> of a collection.
Stepping back a bit, there are three levels of metadata models.

1) The first is just untyped attributes. This includes folksonomy[1]
   tag systems like flickr tags, as well as older systems like 
   "keywords" or "PACS numbers"[2] used for subject indexing
by
   some scientific communities.

   "Beethoven", "Moonlight", "Piano"

2) The second level adds typing to the attributes. This covers all 
   (key, value) pair schemes, including Vorbis comments, EXIF and 
   PNG metadata, and XML attributes.

   Composer="Beethoven", Title="Moonlight Sonata"

3) The third level is what is usually called the RDF model, where
   the metadata is described by a graph. The nodes are items that
   and the labelled edges describe a relationship between nodes.

   Audio title is Moonlight Sonata.
   Moonlight Sonata composed by Ludwig van Beethoven.
   Ludwig van Beethoven has a short name Beethoven
   Moonlight Sonata was composed in 1801.
   Audio performed by Arthur Rubinstein.
   Arthur Rubinstein born in 1887.

I think we need to decide which of these models are implied by our
requirements. Once we know what we have to encode, it will be easier
to setting the encoding issues.

There are other axes, such as whether the categories are ad-hoc, like in 
flickr tags, or reference an absolute collection like musicbrainz ids.

 -r