I've put together the first attempt to defining an RDF metadata vocabulary for use with the CD Index/MusicBrainz/OggVorbis. If you care about metadata issues, please take a look at: http://www.cdindex.org/MM I've included a section for video specific stuff, but everything that I originally had in there is being covered by the MM:Contributors section. The Contributors stuff will allow us to easily identify producers, directors, actors and other people who were involved with the creation of the video. However, I am sure that there are other things that I have not considered for the video case -- if there are things that you think need to get covered for video, please speak up! I've got support for Lyrics and time SyncLyrics. The examples section shows how to do specify the sync lyrics. However, there are no specific items that relate to how to implement them inside of Vorbis -- the RDF MM spec expects that the RDF data will get stuffed into an OGG stream. We may want to define a Ogg specific RDF vocabulary to be used in conjunction with the MM vocabulary. This vocabulary could then be used to specify format/layout of the timecoded/interleaved 'chunks' as we were discussing earlier. Another thing that was mentioned on this list a few days ago was the issue of the time synced picture slideshow. Are these images going to be stored inside another Ogg stream and the RDF should reference that stream? Alternatively, the RDF stream could specify URIs and the player can then download the data before it needs to be shown. What were the thoughts on this? - --ruaok Freezerburn! All else is only icing. -- Soul Coughing Robert Kaye -- robert@moon.eorbit.net http://moon.eorbit.net/~robert --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
On Wed, 02 Aug 2000 16:04:28 -0700 you wrote: > > I've put together the first attempt to defining an RDF metadata > vocabulary for use with the CD Index/MusicBrainz/OggVorbis. If you care > about metadata issues, please take a look at: > > http://www.cdindex.org/MM Awesome. It makes a whole lot more sense than ID3v2 ever did. Here's a list of suggested additons to the music section of the spec, in no particular order: Include a canonical list of contributor title that everyone can work with so I can search for all the tracks mixed by Alan Moulder in the next-gen audio player app :-) A glance at the back of a couple of CD's I have handy gives me this list straight up: Producer Co-producer Recording Engineer (who mixed it) Assistant Engineer Mastering engineer (who mastered it) Instrument Technicans (subtyped by various intruments if you care). The film industry has it's own detailed set of roles, too, and I suspect you could get a canonical list from the right place. RecordingInfo can be broken down into the places it was recorded at (studios and live locations), where it was mastered, and the rest (which could be..?) Artist could be an individual or a group, in which case we want another structure to tell us who is in the group and what they did on this track, so as to distinguish them from other 'outside the group' contributors. Complement RemixInfo with CoverInfo; they are really similar creatures. I'd prefer it if they both said that this track is a remix/cover _of_ the track stated in their info (hey! include a link here to the original song's metadata :-), as I expect that's how people are using id3 tags now. Both these tags are going to want their own Title/Artist/Album/Link tags, too. Also add a Remastered tag that includes who/where/when/what subtags to separate out remastered versions of songs and albums. How about tags to describe samples used in the track? Link Remix/Cover tags they'ed need to indicate the full vitals of the source of the sample. MemberOfSubPart should be usable for music other than classical pieces (I can't think of albums off hand that do this - maybe Antichrist Superstar by Marilyn Manson, as I seem to recall it being broken into three sections). We might need a complementry SubPart tag that indicates the subparts within this track ie various releases of Dark Side Of The Moon have Speak To Me and Breathe as one track on the album. Legal information often gets split between lyrics and music for some tracks, with multiple publishers holding copyright on some tracks (ie the publishing name of each member of the group, for example). A chunk of namespace for audio software to play with would be fairly useful. Of the top of my head I'd find storing min/av/max volume information, a flag to indicate that this track segues into the next one on the album, and some sort of 'run this piece of eyecandy while playing this song' tag to be particularly useful. Hope you find these suggestions useful. John --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
On Wed, 2 Aug 2000, Monty wrote:> I've put together the first attempt to defining an RDF metadata > vocabulary for use with the CD Index/MusicBrainz/OggVorbis.Cool! Thanks for including video.> If you care about metadata issues, please take a look at: > > http://www.cdindex.org/MMUm, you haven't made very extensive use of the Dublin Core. The point there is to use a standardized, cross-discipline set of elements so a search engine/catalog can understand the metadata to the largest extent possible *without* having been programmed with the specifics of our format. Our metadata should be able to "dumb-down" to the DC subset just by ignoring all the unknown elements. Particularly, using qualifiers I think it's possible to describe a lot of the metadata you've invented tags for within DC. Not as easy for the uninitiated to read, unfortunately, but IMO better. So I'd suggest: MM:Artist -> DC:Creator MM:Contributors -> DC:Contributor MM:Duration and MM:Size -> DC:Format (with extent or custom qualifiers) MM:Set, PartOfSet, PartsInSet -> DC:Relation (standard qualifiers) MM:Album, MM:Track -> DC:Relation (custom qualifier) MM:ReleaseDate -> DC:Date (standard qualifier) MM:*Info -> DC:Description (custom qualifiers) MM:Copyright, Trademark, Licensee, TermsOfUse, Signature -> DC:Rights (custom qualifiers, but we probably want to standardize these) MM:CDID, ISRC, UPC -> DC:Identifer (custom qualifiers) (all the database keys probably go here too) The others I'm not sure about. I think we might be able to work Role in as a qualifier on Contributor. I think there is a place for a Link attribute, but I'd only have one, and exploit the web structure or RDF to carry the association with Artist, Publisher, Copyrights, etc. SourceLink should be a Link attribute off a DC:Source element, which might also be the place to put the CDID, etc. My general idea is to be less flat; I suppose that might be harder in terms of db design? I still think lyrics should be a separate record. It's data in its own right, not metadata I'm not sure how to handle the case of non-synchronized lyrics, but am leaning toward treating them the same as synched lyrics (a separate ogg stream) only with no timecode tags. The player would display the whole text in that case.> I've included a section for video specific stuff, but everything that I > originally had in there is being covered by the MM:Contributors section. > The Contributors stuff will allow us to easily identify producers, > directors, actors and other people who were involved with the creation > of the video.Pretty much we want anything that shows up in movie credits. Something open-ended under Contributor makes sense to me. The list cab be staggering; I can work up something semi-comprehensive-for-today if that will help.> We may want to define a Ogg specific RDF vocabulary to be used in > conjunction with the MM vocabulary. This vocabulary could then be used > to specify format/layout of the timecoded/interleaved 'chunks' as we > were discussing earlier.I'm not sure what you mean here, but agree we probably want some Ogg-specific vocabulary. :-) My current model is to have each datatype in a separate substream (logical bitstreams interleaved into the physical steam), including a RDF header that holds both "kitchen-sink" metadata and a description of each substream. So what I envision is you have elements describing "the whole thing" among whom are DC:Relation elements that point to each substream, each of which can have their own specific metadata, but also important things for the player like "this is the primary audio track downmixed to r+l stereo and vorbis encoded" or "this is a mng stream containing the pop-up-video-esque annotative overlays in Telegu". I'd been thinking to us "#" as the URI for the whole file and "#stream-id" for each of the substreams. In a server index, those could be replaced, for example, with stream or download urls.> Another thing that was mentioned on this list a few days ago was the > issue of the time synced picture slideshow. Are these images going to be > stored inside another Ogg stream and the RDF should reference that > stream? Alternatively, the RDF stream could specify URIs and the player > can then download the data before it needs to be shown. What were the > thoughts on this?The plan is to support mng (libmng.com, libpng.org/pub/mng/) as the first graphic substream type, and use it for slideshows, associated still image collections, graphic overlays for the eventual video codec, and as a primary video format for source/editing and animation. This would be an entirely separate logical bitstream, interleaved with the audio (if any) on equal footing. mng files can have an embedded presentation timestamp, which the player would use for synchronization with the audio where that's desired. This is pretty much worked out, but Monty has told me he wants to get the stream-description metadata hammered out before blessing any additional stream types. Cheers, -ralph -- giles@ashlu.bc.ca *crackle* The director is a Humpback Whale. Hold all calls. *crackle* --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
On Wed, 2 Aug 2000, Robert Kaye (through our fearless leader) wrote:> I've put together the first attempt to defining an RDF metadata > vocabulary for use with the CD Index/MusicBrainz/OggVorbis. If you care > about metadata issues, please take a look at: > > http://www.cdindex.org/MMSorry I've taken so long in getting back to you about the second revision. Part of the problem is I've been wallowing in documentation; there's a lot more work and a lot less standard practice on this than I'd expected. As I said, the current proposal is much better. I've been wanting to work out the options for encoding our element set in xml before commenting in too much detail, but that's proved complicated. There are a bazillion ways to do it, even within RDF, and no recommended practice so speak of. I have been thinking that full-on RDF is a bit complicated (hello Michael! :) for the player interface and may suggest that we work with a stricter subset, at least for Ogg. settle down. Maybe something along the lines of the 'encoding unqualified dublin core metadata in xml' working draft: http://purl.org/dc/documents/wd/dcmes-xml-20000714.htm This would be upwards-compatible to the full standard, and just a limitation on what can be in a particular file standard until things settle down. This would mean, for example, just having a slew of <dc:contributor> entries, without the <MM:Contributors><rdf:bag> wrapper like in your 3rd example.> However, I am sure that there are other things that I have not > considered for the video case -- if there are things that you think need > to get covered for video, please speak up!The 'role' and 'roledetail' qualifiers are very clever. One issue with film (or any large production, rather) is that there are often subgroups under the credits, like "Malta Unit" or "Post Production". I'd suggest we just use 'roledetail' for this, but maybe other options are better: <dc:contributor role="Producer" roledetail="Executive"> Herman Mayer </dc:contributor> vs. <dc:contributor role="Artistic Director" roledetail="Post Production"> Laura NDualle </dc:contributor> I like the second better. Another issue is I don't think the x-DonutGopher thing makes sense. There are *a lot* of roles credited in film, and they change over time. We can try to maintain a canonical list with some mappings, but we'd always be playing catch-up with the x-SystemsWranglers. Better not to try and accept the chaos at the frontier. The industry itself will establish practice, and we can follow that after the fact. I suggest replacing MM:Album with a dc:relation link to a new resource. These have to be separate records in your database anyway, and I think it makes more conceptual sense to treat them separately in terms of metadata. I'd been thinking you'd just dump the album metadata into a second <rdf:description> section, but after writting the example below I think you could get away without it. <rdf:description about="http://cdindex.org/rdf/track.pl?id=6187"> <dc:title>Teardrop</dc:title> <dc:creator>Massive Attack</dc:creator> <dc:contributor mm:roll="Performer" mm:roledetail="vocals"> Portishead </dc:contributor> <dc:relation dc:refinement="is part of" mm:link="http://cdindex.org/rdf/album.pl?id=514"> Mezzanine </dc:relation> [...] </rdf:description> <!-- and optionally --> <rdf:description about="http://cdindex.org/rdf/album.pl?id=514"> <dc:title>Mezanine</dc:title> <dc:creator>Massive Attack</dc:creator> <dc:relation dc:refinement="has part" mm:link="http://cdindex.org/rdf/song.pl?id=6185"> Angel </dc:relation> <dc:relation dc:refinement="has part" mm:link="http://cdindex.org/rdf/song.pl?id=6186"> Risingson </dc:relation> <dc:relation dc:refinement="has part" mm:link="http://cdindex.org/rdf/song.pl?id=6187"> Teardrop </dc:relation> [...] </rdf:description> I'm not clear on how free we are in what we put as the content of the relation. Part of the point is to be human-readable, so I like having the URL as a link attribute and using the title, but the parser then has to know about the mm:link attribute (or perhaps a more general xpointer-based one). In my naive understanding of RDF, we're supposed to put the url as the content if we want to do this kind of cascading, and the parser is supposed to be smart enough to look for track->relation->title to get the album title. I did discover some parallel work, that might be interesting. The dc-implementors list archive has some good information (as I imaging do all the dc lists, but I haven't read them yet) http://www.mailbase.ac.uk/lists/dc-implementors/archive.html There have been a number of library-oriented efforts that should dovetail nicely. "An Indexing, Browsing, Search and Retrieval System for Audiovisual Libraries" http://archive.dstc.edu.au/RDU/staff/jane-hunter/ECDL3/paper.html "The Application of Metadata Standards to Video Indexing" http://archive.dstc.edu.au/RDU/staff/jane-hunter/ECDL2/final.html I also discovered that there are similar efforts going on as part of mpeg7, smpte and some others: http://drogo.cselt.stet.it/mpeg/standards/mpeg-7/mpeg-7.htm http://www.smpte.org/ http://www.tv-anytime.org/ Cheers, -ralph -- giles@ashlu.bc.ca Random acts of kindness are all very well, but one has to admire a well orchestrated, organised act of kindness. --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
Ralph Giles seyz:> As I said, the current proposal is much better. I've been wanting to work > out the options for encoding our element set in xml before commenting in > too much detail, but that's proved complicated. There are a bazillion ways > to do it, even within RDF, and no recommended practice so speak of. I have > been thinking that full-on RDF is a bit complicated (hello Michael! :) for > the player interface and may suggest that we work with a stricter subset, > at least for Ogg. settle down. Maybe something along the lines of the > 'encoding unqualified dublin core metadata in xml' working draft: > > http://purl.org/dc/documents/wd/dcmes-xml-20000714.htm > > This would be upwards-compatible to the full standard, and just a > limitation on what can be in a particular file standard until things > settle down. This would mean, for example, just having a slew of > <dc:contributor> entries, without the <MM:Contributors><rdf:bag> wrapper > like in your 3rd example.I don't know if I like this. Whenever I've done things that implemented a subset of features from a full standard, I've gotten bit by my non-compliance in the end. And in this case you are going to lose valuable information such as role and roledetail. So, any RDF data that goes into a vorbis file will become degraded and then if someone pulls that data back out and uses it elsewhere you have vorbis acting like a filter that filters out some of the most useful data. On the other hand, I understand the constrictions to not include the full kitchen sink as far as RDF and XML are concerned. I feel that if you cannot be fully compliant to a standard, its best not to attempt being compliant at all. Can you please elaborate on your hesitation with RDF? Are you trying to keep things simple (ie, a list of metadata key, value pairs) as opposed to having metadata that has lists of lists of metadata key, value pairs? Have you taken a look at the CD Index client library? (This will become the musicbrainz client library after burning man) I've managed to abstract out all aspects of RDF/XML from the user who might want to access the RDF data. The key is to use XQL-like-queries for pulling data out of an RDF object. The client lib will be released under the LGPL, and I would like to offer its use (or portions thereof) for Vorbis. The biggest problem is that the client lib is written in C++, but if we really wanted to use it for vorbis, we could bang it down to C in a matter of hours)> The 'role' and 'roledetail' qualifiers are very clever. One issue with > film (or any large production, rather) is that there are often subgroups > under the credits, like "Malta Unit" or "Post Production". I'd suggest we > just use 'roledetail' for this, but maybe other options are better: > > <dc:contributor role="Producer" roledetail="Executive"> > Herman Mayer > </dc:contributor> > > vs. > > <dc:contributor role="Artistic Director" roledetail="Post Production"> > Laura NDualle > </dc:contributor> > > I like the second better.I'm not sure that I clearly see the difference between these two. I think I like the first one better, where we have fewer defined canonical roles, and leave the definition of the roleDetail completely open. For instance, I could see pairs like these: Role: RoleDetail: Producer Executive, Malta Team Producer Executive, Hollywood Team Producer Assistant, Malta Team> Another issue is I don't think the x-DonutGopher thing makes sense. There > are *a lot* of roles credited in film, and they change over time. We can > try to maintain a canonical list with some mappings, but we'd always be > playing catch-up with the x-SystemsWranglers. Better not to try and accept > the chaos at the frontier. The industry itself will establish practice, > and we can follow that after the fact.I don't think this will be an issue if we define the Roles to be broad enough and leave roledetail completely open for people to add their own slant.> I suggest replacing MM:Album with a dc:relation link to a new resource. > These have to be separate records in your database anyway, and I think it > makes more conceptual sense to treat them separately in terms of metadata. > I'd been thinking you'd just dump the album metadata into a second > <rdf:description> section, but after writting the example below I think > you could get away without it.I've come to the conclusion that a seperate description for the album is the way to go: <?xml version="1.0" encoding="ISO-8859-1"?> <rdf:RDF xmlns = "http://w3.org/TR/1999/PR-rdf-syntax-19990105#" xmlns:DC = "http://purl.org/DC#" xmlns:MM = "http://cdindex.org/MM#"> <rdf:Description> <MM:Collection type="album"> <rdf:Description> <DC:Title>Corroded Path</DC:Title> <DC:Creator>Network</DC:Creator> <DC:Relation numParts="8"/> <DC:Identifier albumId="00003C7E@fuss@39A2D955" artistId="00003C7D@fuss@39A2D955"/> <rdf:Seq> <rdf:li> <rdf:Description> <DC:Identifier trackId="00003C7F@fuss@39A2D955"/> <DC:Relation track="1"/> <DC:Title>Hyperventilation</DC:Title> </rdf:Description> </rdf:li> . . . </rdf:Seq> </rdf:Description> </MM:Collection> </rdf:Description> </rdf:RDF> Note the use of MM:Collection. This element is intended to convey information about albums, playlists and other lists of lists of metadata that might be used outside of Vorbis. For instance, EMusic would like to publish the metadata of its entire collection for anyone to download. Using the MM:Collection (a more generic term for MM:Album) I can now describle playlists, (type="playlist") or any other collection that might have multiple levels (for instance, at emusic we may have a list of labels with a list of genres for each label, and then a list of albums for each genre, and of course a list of tracks for each album) Hmmm. Lots more of the complexity that you do not like. :-)> <rdf:description about="http://cdindex.org/rdf/album.pl?id=514"> > <dc:title>Mezanine</dc:title> > <dc:creator>Massive Attack</dc:creator> > <dc:relation dc:refinement="has part" > mm:link="http://cdindex.org/rdf/song.pl?id=6185"> > Angel > </dc:relation> > <dc:relation dc:refinement="has part" > mm:link="http://cdindex.org/rdf/song.pl?id=6186"> > Risingson > </dc:relation> > <dc:relation dc:refinement="has part" > mm:link="http://cdindex.org/rdf/song.pl?id=6187"> > Teardrop > </dc:relation> > [...] > </rdf:description> > > I'm not clear on how free we are in what we put as the content of > the relation. Part of the point is to be human-readable, so I likeAs stated above, using the relation for this is inappropriate. There is a ton of metadata that applies to a track (just as it does to an album) and a sub description is really called for. --ruaok Freezerburn! All else is only icing. -- Soul Coughing Robert Kaye -- robert@moon.eorbit.net http://moon.eorbit.net/~robert --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.