draft document on CC metadata in SMIL
lgonze at panix.com
Wed Oct 29 16:57:22 EST 2003
On Wednesday, Oct 29, 2003, at 16:14 America/New_York, Mike Linksvayer
> Lucas Gonze wrote:
> > <smil>
> > <head>
> > <metadata id="meta-rdf">
> I guess you didn't need the skip-over attribute because you put
> <metadata> as a child of <head>?
Actually because I reread the relevant portions of the the SMIL 1.0
spec and realized that we didn't need skip-content unless there was a
chance of SMIL being embedded within the CC metadata, which is not
>> xmlns:rdfs = "http://www.w3.org/TR/1999/PR-rdf-schema-19990303#"
>> xmlns:dc = "http://purl.org/metadata/dublin_core#"
> (the smil2.0 metadata example is a bit outdated)
>> <!-- Question: what is this namespace URL? Shouldn't the
>> namespace URL for SMIL metadata be something real? -->
>> xmlns:smilmetadata =
>> "http://www.example.org/AudioVideo/.../smil-ns#" >
> I'd say chuck it. It is only used in the smil2.0 metadata example,
> nowhere else AFAIK, CC has no requirement for it, and the use in the
> example is kind of silly -- for the most part it duplicates
> information in the actual SMIL directives.
> One person commented to me along the lines of "what's the point of
> licensing a playlist/can a list of tracks even be copyrighted". I
> think it is key to point out as a motivating factor someplace in the
> document that SMIL can do much more than simple playlists. The first
> term that comes to me is client-side remixing, but maybe someone can
> think of a cooler phrase.
Um. Well, I could go into that, but I'd rather not do evangelism.
> However, the individual components of a SMIL playlist most certainly
> are copyrightable, and the example needs to demonstrate how SMIL
> metadata can denote the license each component is under, e.g.,
> <Work rdf:about="http://example.com/mp3/first.mp3">
It doesn't really make sense to me to put assertions about external
resources in the SMIL container. It's replicated data that will get
out of sync. If the author of the container isn't the author of the
external resource, the container author shouldn't speak for the
external resource author. It creates a horrendous amount of work to
maintain the metadata for every contained resource -- managing the list
of URLs itself is itself not so easy. SMIL is like HTML with an
additional time dimension for layout, and CC licensing of HTML doesn't
Next up is to set up the writing in a format that makes sense for
typical CC users. It probably needs to be simpler, more readable, and
in HTML instead of plain text.
By the way, we've already gotten a bit of buy-in for this CC SMIL
project -- Alf Eaton added support for it to Facil-O-Smil. See
More information about the cc-metadata