cc-metadata AT lists.ibiblio.org
Subject: discussion of the Creative Commons Metadata work
List archive
- From: Tim Olsen <tolsen718 AT gmail.com>
- To: discussion of the Creative Commons Metadata work <cc-metadata AT lists.ibiblio.org>
- Subject: Re: [cc-metadata] non-web embedding revisited
- Date: Fri, 23 Dec 2005 17:54:59 -0500
On 12/23/05, Tim Olsen <tolsen718 AT gmail.com> wrote:
> > WCOP (pointing to a license URL)
> > Definition: http://www.id3.org/id3v2.3.0.html#WCOP
> > Example value: http://creativecommons.org/licenses/by/2.0/
> >
> > WOAF (pointing to a web page describing a file, potentially including
> > license information/metadata)
> > Definition: http://www.id3.org/id3v2.3.0.html#WOAF
> > Example value: http://example.com/a_song_sung_by_me.html
> >
>
> I'd say go with WCOP. This way a publisher has the option of having a
> different link for WOAF.
>
> Where will the verification url go?
>
> > Note that these map to current use of licenses and metadata on web pages
> > -- the license notice points to a CC license URL, and describes the
> > current page (the current page is its own "official page").
> >
Nevermind. Now I understand that the proposal is for WCOP to be used
for the license url and the WOAF for the verfication url
-Tim
> > Comments? Suggestions for implementation in other formats? I'm
> > particularly interested in EXIF, MP4/QT and OGG at this point.
>
> Ogg has a LICENSE field which they say can be used for (among other
> things) a URL pointing to the license. See
> http://www.xiph.org/vorbis/doc/v-comment.html
>
> MP4 has a Copyright Atom. See pages 36 - 37 of
> http://mediaxw.sourceforge.net/files/doc/MPEG%204%20System.pdf
> It's exact format is not specified in that document. I wonder how, if
> at all, any MP4 files are using that atom.
>
> It might be difficult to persuade every file format owner to add a tag
> that is specifically for a license (and/or verification) url. The
> nice thing about the semi-readable/parseable license statement is that
> we can use any field that relates to copyright or licenses.
>
> Furthermore, I don't think the current license statement is so hideous
> for a machine to parse. Only the content after the words "verify at"
> is constrained - at least that's my reading of
> http://creativecommons.org/technology/mp3 and
> http://creativecommons.org/technology/ogg.
>
> What can be hideous though, is if some programs are becoming dependent
> on what may be becoming a de-facto format: <year> <copyright holder>.
> Licensed to the public under <licenseurl> verify at <verification url>
>
> A more specific specification as to what a "CC-compliant"
> publisher/reader should or should not depend on may help here. (a la
> RFC-style)
>
> -Tim
>
-
[cc-metadata] non-web embedding revisited,
Mike Linksvayer, 12/23/2005
-
Re: [cc-metadata] non-web embedding revisited,
Lucas Gonze, 12/23/2005
-
Re: [cc-metadata] non-web embedding revisited,
Mike Linksvayer, 12/23/2005
-
Re: [cc-metadata] non-web embedding revisited,
Lucas Gonze, 12/23/2005
- Re: [cc-metadata] non-web embedding revisited, Mike Linksvayer, 12/23/2005
-
Re: [cc-metadata] non-web embedding revisited,
Lucas Gonze, 12/23/2005
-
Re: [cc-metadata] non-web embedding revisited,
Mike Linksvayer, 12/23/2005
- [cc-metadata] Exif (was Re: non-web embedding revisited), Mike Linksvayer, 12/23/2005
-
Re: [cc-metadata] non-web embedding revisited,
Tim Olsen, 12/23/2005
- Re: [cc-metadata] non-web embedding revisited, Tim Olsen, 12/23/2005
- Re: [cc-metadata] non-web embedding revisited, Mike Linksvayer, 12/23/2005
- [cc-metadata] Ogg (was Re: non-web embedding revisited), Mike Linksvayer, 12/23/2005
-
Re: [cc-metadata] non-web embedding revisited,
Lucas Gonze, 12/23/2005
Archive powered by MHonArc 2.6.24.