[vorbis] RDF Metadata Specification

[Ralph Giles]

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/MM

Um, 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 at 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 at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.